I've a Parker Vector in stainless steel (actually, it's a resin barrel with a stainless steel jacket around it, but it prevents me from destroying the barrel) that I really, really like. It's probably not as nice as a $300 dollar pen, but the Vector doesn't retail for more than $20, and I think I've gotten a very good pen for my money.
That really depends. When I was shopping around for colleges during high school, I was told in no uncertain terms that CMU almost never accepted graduate students whose undergrad wark had been done at CMU. That was specifically in reference to their science and engineering programs, though.
If everyone charges their flywheels during off-peak hours, but the flywheel provides power during the normal peak usage period, doesn't that effectively change the power consumption such that peak and off-peak usage periods reverse?
Window Maker takes care of everything but the colors/textures I mentioned. All the bevels are handled automatically. Button glyphs are the same color as the text on that titlebar. I don't have to worry about any of the intermediate colors in the gradients, just the ones I want faded to.
If I wanted to tint a pixmap for a Window Maker texture, I can use one of the t*gradient options a specify the same color for both ends of the gradient, or I can tint it before time (which is more likely). Past that, I don't think that you're accomplishing much besides shifting all the work I would normally do in, say, the GIMP into runtime. While interesting in its own way, none of those seem like features I need or want in a windowmanager.
Well, typically I don't need very many. One for the text and one for the background in the focused, unfocused and parent titlebars. One for the text and background of menu items, and one for the text and background of selected menu items, and another pair for the menu titlebar. One for the caption text and background for appicons, and one for the background of the appicons/dock icons. And one for the resize bar. WM automagically handles the bevels on the edges, so that's not my problem at all.
Usually, I reuse the focused titlebar colors for the menu title, and the selected item colors fit well for the appicon caption (which I always disable at compile time, anyway). The unfocused titlebar background is also reused as the menu background and the resizebar. That's still several different textures (plus a background), but nothing really taxing: 5 text colors (focused, unfocused, parent titlebars, selected and unselected menu items), and 5 background textures (three titlebars, icons, and a wallpaper).
As regards the XML functionality, this sounds an awful lot like the t*gradient functionality provided in Window Maker, which tiles a pixmap and overlays a gradient on top of the resulting pixmap at a particular opacity. Unless you're actually swapping out the entire palette of the pixmap, but I should think that would only work with things like gifs or other indexed-color image types. I'll have to check it out later, and see what you're talking about. Probably won't happen before tomorrow evening, however.
What, you mean like themes? I used to use themes under WindowMaker. Used them for a long, long time.
2)Window edge snapping while moving/resizing windows
WM has this feature already. I remember distinctly playing around with the edge affinity setting.
3) better virtual desktop implementation
Which is immaterial if I don't use virtual desktops. Or hate the pager. It's a personal thing, but I really don't care about it overmuch.
4) Menus adjusting to your use pattern, by propping up recently used ubitems into higher level menus
Would you believe that this particular feature is one of those things that I happen to positively loathe? Maybe it's a personal thing, but I like things to stay where I left them.
5) XML images
Not to rain on your parade, but I don't see how this is exceptionally better than the functionality provided in Window Maker (specifically the t*gradient functionality). I don't see XML as a selling point by itself.
In a practical sense, what does that buy me as a user? Better GNOME/KDE support? Anything?
In the meantime, does it "feel" the same as it did in the 1.6 (1.16?) series? (and if it does, that's not a good thing to me). Because it always felt cludgy. I wish I could elaborate that a bit and make it clearer what I mean, but I don't know how else to say it, or exactly what caused it (I'm sure it had some to do with seeming very busy in comparison).
Are the configuration files any easier to deal with? Last time I looked at AS, they were still using the fvwm-style flat files for everything, and it was a comparative pain in the ass to find something and change it, because the various configuration settings weren't especially consistent (this is not entirely something that "Our config files are in XML" will answer).
All that work to get a NeXT-like window manager to look nothing like NeXT!. Bravo, I say, bravo.
Seriously, if I don't give a rat's ass about eye-candy, what makes AfterStep 2 any better than Window Maker.80.2? (and AFAIK, Window Maker is under development, they're apparently just very quiet about it).
So this pretty much all hinges on whether or not SCO owns any and all code that was derived from the original UNIX source, since they state that the code in question was originally written by Sequent (and, therefore, not SCO).
Nah. K5's been having server problems for weeks. This won't help, but I doubt it really has much to do with it. K5's certainly survived past slashdottings.
Have someone else do it for you. There are companies around that do mail filtering and so forth; they use Postini here. Costs a couple bucks per month per mailbox, but they also hold onto mail if the server here becomes unavailable, and it's never your headache to keep up with.
Don't second-guess yourself so much. You'll do no worse than anyone else and better than most.
Learn to let your failures go. Learn from them when possible, and cheer on others at all times. You can't and won't win everything you try to do, so don't worry about it.
Take some form of martial art. You need the exercise and the discipline.
That girl you'll be hung up on in a few years? You may not believe this, because you got jerked around some earlier, but she actually likes you: ask her out, or you'll regret it when she gets married later.
Computer Science, not Engineering. And skip that special curriculum thing as a college freshman: it's a mistake.
When you go to college, you'll see a young woman at a dance. If you're single again at this point, ask her out. If you're not, get to know her anyway. You'll like her.
Finally: your parents and teachers are right, you're wasting your potential. Stop that.
A buddy of mine gave out screwdrivers (as in hand tools, not mixed drinks), but he's a mechanical engineering geek, so that sort of thing might not be totally to your taste.
My very earliest memory is probably when my sister was born. I'd have been about two and a half, and I can remember (but not very well) looking through the glass at the hospital. May have been manufactured, but there's at least one more from roughly the same time period that I can still remember which I know wasn't manufactured. So I'd have to say that memory is good at least as far back as the age of two and a half years old.
I recently replaced my m105 for a Sony NX-70V, purely for the whiz-bang factor. I can live without the keyboard, but the other capabilites strike me as handy. I mgiht have to give up and buy a cradle for the office, though.
I used my first Palm extensively at my first job, where *everybody* had one. Meetings, deadlines, contact information, *everything* went into the Palm. And then I got laid off. My current office is big on Blackberries, but they haven't issued me one.
I would like to respectfully disagree: the problem is not that a thing seems obvious to you, the problem is that you can't assume on the experience or intelligence of those who have to maintain your code later.
Your example seems obvious to you because you're used to concepts like memory (de)allocation and you're used to the C language. Someone without the same background won't immediately recognise that you're deallocating memory because they won't know that free() deallocates memory. Suppose they learned Java in college and not C or C++ (I know of at least one school which started teaching Java as the primary language in the curriculum).
A comment like/* deallocating used memory */ or something to that effect doesn't strike me as troublesome. If you can't skim over something on your screen, perhaps the problem is with you? Code lives a long time. Write it with the assumption that the next person knows nothing about the system the program models, that the next person knows nothing more than the basics of the language.
It's not like you need to comment everything you do. But explaining the purpose of a loop in brief statement won't kill you and shouldn't bother anyone else, either.
As one of my university professors said, "Use comments to tell me something I don't know."
Well, you need to write to your audience. Your professor doesn't want to read comments like that because he uses comments as a signal that something relevant to the class assignment just happened. The next guy who gets your code in a work environment, however, might be the idiot man-child in the cubicle next to you. You know, the one that can't figure out how to plug in his ethernet cable?
Well... some of us just want something that will run what we need it to run without having to pay an arm and a leg for something that will do the same job with twice as much overhead and half as much stability. I find the ability to fix someone else's code to be fairly unmotivating: I've enough to do already, without doing someone else's job.
Having client identifiers is a Good Idea for the same reason that having protocol identifiers is a Good Idea: different clients handle things differently. Even the W3 standards allow room for interpretation and allow different implementations of the same thing. Since this means that things can be presented differently on one client and platform than on another (whether it's a bug or not), it can be important to be able to tell the difference between one client and another to provide a consistent presentation and to handle any known bugs. I doubt Netscape 4 will be the last buggy software application based on an open standard. That's just the way it goes.
Slashdot Mirror
I've a Parker Vector in stainless steel (actually, it's a resin barrel with a stainless steel jacket around it, but it prevents me from destroying the barrel) that I really, really like. It's probably not as nice as a $300 dollar pen, but the Vector doesn't retail for more than $20, and I think I've gotten a very good pen for my money.
That really depends. When I was shopping around for colleges during high school, I was told in no uncertain terms that CMU almost never accepted graduate students whose undergrad wark had been done at CMU. That was specifically in reference to their science and engineering programs, though.
You know, if I'm wrong, I'd like to hear the explanation why.
If everyone charges their flywheels during off-peak hours, but the flywheel provides power during the normal peak usage period, doesn't that effectively change the power consumption such that peak and off-peak usage periods reverse?
*sigh*
Window Maker takes care of everything but the colors/textures I mentioned. All the bevels are handled automatically. Button glyphs are the same color as the text on that titlebar. I don't have to worry about any of the intermediate colors in the gradients, just the ones I want faded to.
If I wanted to tint a pixmap for a Window Maker texture, I can use one of the t*gradient options a specify the same color for both ends of the gradient, or I can tint it before time (which is more likely). Past that, I don't think that you're accomplishing much besides shifting all the work I would normally do in, say, the GIMP into runtime. While interesting in its own way, none of those seem like features I need or want in a windowmanager.
How do I come up with colors in my themes?
Well, typically I don't need very many. One for the text and one for the background in the focused, unfocused and parent titlebars. One for the text and background of menu items, and one for the text and background of selected menu items, and another pair for the menu titlebar. One for the caption text and background for appicons, and one for the background of the appicons/dock icons. And one for the resize bar. WM automagically handles the bevels on the edges, so that's not my problem at all.
Usually, I reuse the focused titlebar colors for the menu title, and the selected item colors fit well for the appicon caption (which I always disable at compile time, anyway). The unfocused titlebar background is also reused as the menu background and the resizebar. That's still several different textures (plus a background), but nothing really taxing: 5 text colors (focused, unfocused, parent titlebars, selected and unselected menu items), and 5 background textures (three titlebars, icons, and a wallpaper).
As regards the XML functionality, this sounds an awful lot like the t*gradient functionality provided in Window Maker, which tiles a pixmap and overlays a gradient on top of the resulting pixmap at a particular opacity. Unless you're actually swapping out the entire palette of the pixmap, but I should think that would only work with things like gifs or other indexed-color image types. I'll have to check it out later, and see what you're talking about. Probably won't happen before tomorrow evening, however.
WM has this feature already. I remember distinctly playing around with the edge affinity setting.
Which is immaterial if I don't use virtual desktops. Or hate the pager. It's a personal thing, but I really don't care about it overmuch.
Would you believe that this particular feature is one of those things that I happen to positively loathe? Maybe it's a personal thing, but I like things to stay where I left them.
Not to rain on your parade, but I don't see how this is exceptionally better than the functionality provided in Window Maker (specifically the t*gradient functionality). I don't see XML as a selling point by itself.
In a practical sense, what does that buy me as a user? Better GNOME/KDE support? Anything?
In the meantime, does it "feel" the same as it did in the 1.6 (1.16?) series? (and if it does, that's not a good thing to me). Because it always felt cludgy. I wish I could elaborate that a bit and make it clearer what I mean, but I don't know how else to say it, or exactly what caused it (I'm sure it had some to do with seeming very busy in comparison).
Are the configuration files any easier to deal with? Last time I looked at AS, they were still using the fvwm-style flat files for everything, and it was a comparative pain in the ass to find something and change it, because the various configuration settings weren't especially consistent (this is not entirely something that "Our config files are in XML" will answer).
Seriously, if I don't give a rat's ass about eye-candy, what makes AfterStep 2 any better than Window Maker .80.2? (and AFAIK, Window Maker is under development, they're apparently just very quiet about it).
So this pretty much all hinges on whether or not SCO owns any and all code that was derived from the original UNIX source, since they state that the code in question was originally written by Sequent (and, therefore, not SCO).
Nah. K5's been having server problems for weeks. This won't help, but I doubt it really has much to do with it. K5's certainly survived past slashdottings.
What about the inevitable guy whose password will always be 'mother'?
Have someone else do it for you. There are companies around that do mail filtering and so forth; they use Postini here. Costs a couple bucks per month per mailbox, but they also hold onto mail if the server here becomes unavailable, and it's never your headache to keep up with.
ESR wrote a foreword. Forward is a direction, foreward is piece of writing at the front of a book.
Way to go guys. There's no article there. Swift.
A buddy of mine gave out screwdrivers (as in hand tools, not mixed drinks), but he's a mechanical engineering geek, so that sort of thing might not be totally to your taste.
My very earliest memory is probably when my sister was born. I'd have been about two and a half, and I can remember (but not very well) looking through the glass at the hospital. May have been manufactured, but there's at least one more from roughly the same time period that I can still remember which I know wasn't manufactured. So I'd have to say that memory is good at least as far back as the age of two and a half years old.
I recently replaced my m105 for a Sony NX-70V, purely for the whiz-bang factor. I can live without the keyboard, but the other capabilites strike me as handy. I mgiht have to give up and buy a cradle for the office, though.
I used my first Palm extensively at my first job, where *everybody* had one. Meetings, deadlines, contact information, *everything* went into the Palm. And then I got laid off. My current office is big on Blackberries, but they haven't issued me one.
So, which one is Slashdot? Porn, spam, or fraud?
I would like to respectfully disagree: the problem is not that a thing seems obvious to you, the problem is that you can't assume on the experience or intelligence of those who have to maintain your code later.
Your example seems obvious to you because you're used to concepts like memory (de)allocation and you're used to the C language. Someone without the same background won't immediately recognise that you're deallocating memory because they won't know that free() deallocates memory. Suppose they learned Java in college and not C or C++ (I know of at least one school which started teaching Java as the primary language in the curriculum).
A comment like /* deallocating used memory */ or something to that effect doesn't strike me as troublesome. If you can't skim over something on your screen, perhaps the problem is with you? Code lives a long time. Write it with the assumption that the next person knows nothing about the system the program models, that the next person knows nothing more than the basics of the language.
It's not like you need to comment everything you do. But explaining the purpose of a loop in brief statement won't kill you and shouldn't bother anyone else, either.
Well, you need to write to your audience. Your professor doesn't want to read comments like that because he uses comments as a signal that something relevant to the class assignment just happened. The next guy who gets your code in a work environment, however, might be the idiot man-child in the cubicle next to you. You know, the one that can't figure out how to plug in his ethernet cable?
So... Your music would be discretely bad instead of continuously bad. I suppose that's an improvement.
Bring on the catgirls!
Well... some of us just want something that will run what we need it to run without having to pay an arm and a leg for something that will do the same job with twice as much overhead and half as much stability. I find the ability to fix someone else's code to be fairly unmotivating: I've enough to do already, without doing someone else's job.
Having client identifiers is a Good Idea for the same reason that having protocol identifiers is a Good Idea: different clients handle things differently. Even the W3 standards allow room for interpretation and allow different implementations of the same thing. Since this means that things can be presented differently on one client and platform than on another (whether it's a bug or not), it can be important to be able to tell the difference between one client and another to provide a consistent presentation and to handle any known bugs. I doubt Netscape 4 will be the last buggy software application based on an open standard. That's just the way it goes.