In addition, running it through a PostScript interpreter won't work. Consider the following code which prints a "random" number of pages between one and ten:
statusdict begin pagecount
10 mod {showpage} 1 add repeat
In addition, I believe it would be possible to write a PostScript program that could figure out if it's running under an interpreter and behave accordingly (requires some research).
So, if you have any PostScript hackers, your best bet is to rely on a hardware page count. If you don't have any hackers, on the other hand, you can simply count the "%%Pages:" DSC comment that PostScript-generating programs put in:)
About three months ago I got sick of all other window managers, so I wrote my own. Writing a window manager was the most fulfilling software project I've ever undertaken.
My window manager now does all the things I want it to do, none of things I don't want it to do, and I'm running it full-time. Running your own software full-time is an experience every programmer should have - you learn to write solid code, as it would really suck if my window manager crashed while I was writing this into Netscape.
I won't go into a diatribe about why I wrote it, but needless to say, it does a number things that all the other window managers I've tried get completely wrong (and yes, I've tried a lot of window managers, including the "configurable" ones like sawfish and scwm).
At some point, I might release my code, but that would probably require putting in hooks for a configuration file (since it's MY window manager, all the configuration I need to do is 'vi main.c'). If there's enough interest, I can go into details about what it does differently and at some point, I might even release some code. I really couldn't care less if anyone else uses this, however. This is MY window manager, and it does everything I want (this is why you should write your own, saying that feels really good).
Anyway, if you know any C, you should try writing your own window manager (think about it - what would be more satisfying, writing another GNOME/KDE applet, or writing software that you'll be using 100% of the time?). Here are the resources you'll need:
Xlib manual
You'll need to know Xlib. You can get the xlib manual in troff from XFree86 CVS, or you can read it online at the link above. I found the greppable, linked html much nicer than a big PostScript file.
ICCCM manual
You'll need to follow the ICCCM recomendations if you want your window manager to play nice with other apps.
Extended Window Manager Hints manual
The KDE and GNOME people say this is the standard for their desktops. Most of the stuff here is pretty simple, but you should look it over first, as it assumes quite a bit about how you implement your window manager (so you should implement it a certain way in order to support the KDE/GNOME stuff).
For reference, it took me about three weeks and 6000 lines of code to get something I could use full-time. You might also want to look at other window managers' code: there's a window manager called '9wm' that's very small and whose code is extremely legible. Trying to read code from Enlightenment or WindowMaker is not the best way to go as these are very large codebases and use multiple levels of indirection (which makes understanding how some detail is implemented very difficult).
I can supply more information for the potential DIY-er if needed.
While we're on the subject, does anyone know of a reference for Motif hints? I would rather not use someone else's code (licensing restrictions, etc), and would like the definitive reference, if such a thing exists.
More interesting than the computer were the books on the shelf - Design Patterns, Applied Cryptography, Programming Perl - I doubt many windows users read those.
Networking -- Having an entire network to myself would be really nice, but unfortunately, I don't always have that at my disposal. With VMWare, I boot up two or three virtual machines running various OSs and then see how my program fares when running on something close to a real network, not just loopback.
OS Development -- I recently started messing around with writing my own kernel, and VMWare has been indispensible. Having to dd to a floppy and rebooting some machine every time I change a line of code gets old really fast. VMWare has this neat feature that it can use any file as your floppy device, not just/dev/fd0, so I can muck around in my VMWare window and at the same time see where exactly in my code things are going bad.
I really don't see any sensible way to write a bootloader and kernel without VMWare.
It lets me play around with other OSs that I really don't want to run, but I would like to see how they work, like the various BSDs, x86 Solaris, etc.
I guess some people still need to run bl0ated windows software for some reason, but VMWare lets you do a whole lot more than that. As for your point about developing in a simulated environment, yes you probably wouldn't want to release code that you never ran on a real machine, but in some instances VMWare just saves a lot of time -- you don't lose your editor when your machine goes down (happened a lot to me in Visual Dev.) and you don't have to keep jumping from keyboard to keyboard when writing a network application in an environment where ssh is not an option.
This has not been a paid endoresement, I just really like this program.
All these add are gui *front ends*. Meaning that nothing changes.
This is not always true.
Sometimes, the front-end ends up being the only way to configure whatever it's supposed to configure, or the front-end is the only one with the documentation.
For example, look at OS X Server. Yes, it's a real unix, but everything is handled by gui-front ends, or by some java application that you access through netscaping to some port. The problem is that you can't really do something non-trivial (like add a user) without a java-capable browser (which OSX doesn't have), or by actually sitting down at the machine (so you need at least two machines handy to do any work). When things go bad, you have to go to the machine to change something (you can't just ssh in and mess with some config file). The man pages that came with it were a joke, and you couldn't change anything about the appletalk sharing or the Macintosh Manager authenticator through the console. I had a list of about 30 users I wanted to add -- I couldn't do any sed/awk magic with/etc/passwd and be done with it, I had to type in each name/passwd individually (and mess with the mouse in between adding each name to change groups, etc.). Sure, it was easy to add a user if you'd never done it before, but if you wanted to do any maintenance/configuration, you had to sit at the computer (no X server), with another machine nearby (no java browser). Altogether, it was a big mess.
Fortunately, this happens only rarely in Linux -- I can just copy my config files over to a new machine when I set it up and I can change whatever I want about the system with an ssh session from anywhere in the world. The point is that if new tools start being developed with gui configuration in mind rather then textfile configuration, people need to make sure that instead of just saying "to change xyz, click here," also saying "to change xyz, edit/etc/foo.conf; see foo.conf(5) for details." OSX didn't provide the textfile configuration I needed (and as a result, I haven't touched our OSX server in months).
This is already starting to happen to Linux. For example, I use WindowMaker for my windowmanager, and to configure it, you can use WPrefs, which just writes some config files. Unfortunately, I couldn't find the documentation for those config files (and they didn't have any comments at the top to help me), so I was stuck using WPrefs to change things. At one point, I wanted to get rid of all icons entirely, but there was no way of doing this with the front-end. I needed to edit the files, and the only way I could work was by changing something, restarting windowmaker, and seeing if it did anything (and config files would be overwritten at points so I would lose all my work). I finally did it, but it was a slow and tedious process, whereas if I had a manpage for the config file, I could have had it done much more quickly. This was a simple task, but imagine if there were no manpage for/etc/sshd_config or/etc/smb.conf. The only way I was able to get X initially working on my machine was to edit XF86Config, and I wouldn't have been able to do that without a manpage.
My point is that gui front-ends (like xf86configurator or WPrefs) are replacing my emacs, and I don't like it. People are starting to put more thought into writing front-ends for editing a file rather than documenting the file's format.
One important thing that you didn't mention -- you can configure windowmaker to launch arbritary commands by any keyboard combination. The way I have it set up, I hit C-M-E for emacs, C-M-T for a terminal, C-M-L for xlock, C-M-R for a run dialog and so on (much faster than removing my hands from the home keys to hit F12 then using the arrows). I keep my mouse in my desk drawer, and I never take it out except for netscape, xfig, etc. (And you can also turn off the dock, clip and all icons since they're useless if you're not using the mouse -- also, there never is the problem of screen real-estate as I keep all apps maximized (found a nice big legible font for xterm and emacs), and I simply use the keyboard (all without removing my hands from the home keys) to switch applications/workspaces.) Best of all, you can configure this from a very straightforward interface, so you don't waste too much time messing with silly little widgets or cryptic configuration files rather than getting to work in your applications (which is the entire point of a windowmanager, I think).
Of course, this all ties into the point made earlier which is that interface design can be vastly improved. By this, I mean that if I'm going to make heavy use of an application (like my text editor), I should be able to change every miniscule detail about its operation--for a keyboard person like me, that means I set up all my own key bindings, using any keys that I wish (I don't use any of the bindings for my emacs keys which are intercepted by the windowmanager, like M-tab for ispell), and for the mouse-oriented person, that means that all menus/mouse clicks should be configurable. More at the core of the problem is that people noways think an application is usable if it allows access to all of its commands from a menu, and this is wrong. An application is configurable if I can combine its commands in ways that I think are useful. Every application that I'm going to spend a lot of time in should have some sort of powerful scripting language built into it. Emacs is a good example of this; if I see that I'm doing a lot of things repeatedly, I should be able to script those things and make them available as a command, either via keyboard or mouse (that's what computers are good at, automating repetitive tasks). To me, that's what seems to be the whole idea behing the unix shell--you combine a bunch of commands together and end up with something suited to your own tastes. When I use an application written without this in mind, I feel like George Jetson at his job, where he spent all day pushing a button; look at netscape for instance. I spend a lot of time hitting escape to continue loading a page when some advertisement banner linked from a slow server pops up. I should be able to right-click on these banners whenever I see them and say "Don't ever load any animated gifs from this server again." I would be willing to spend the time to learn whatever scripting language to get this simple feature (but I would not be willing to go through tens of megs of C that I don't have a hope of understanding). By the same token, I want a powerful scripting language which gives me access to all features of the application, not like the little javascript toolbar buttons you can set up in netscape which are deliberately watered-down (and whose documentation is not readily available, rather hidden away on netscape's site, as if it would confuse new users if there was an "advanced configuration" item under the help menu).
This idea has been said before--look at Guido van Rossum's current project, Computer Programming for Everybody. (Guido van Rossum is the creator of Python.)
Don't feel bad. I'm only 19 and I also don't understand any of this nonsense. Case in point: I downloaded a theme. The actual background in the download has a bunch of C code (perhaps an exploit of some sort?) with the rendered letters "31337" in the foreground. This troubled me. What was the significance of this number? There must be some meaning behind this number if someone was going to take the time to render it so nicely. Unfortunately, the only interesting thing I was able to find about 31337 is that it is a prime number, not a fibonacci or a marconi or anything else. I was rather disappointed. Later, someone told me the significance of my desktop background. That wasn't exactly the image I was trying to portray.
Slashdot Mirror
Of course, I got the program wrong (I was messing with the interpreter as I was writing it, wasn't too careful).
:)
Instead of:
10 mod {showpage} 1 add repeat
It should be:
10 mod 1 add {showpage} repeat
PostScript is a beatiful language
In addition, running it through a PostScript interpreter won't work. Consider the following code which prints a "random" number of pages between one and ten:
:)
statusdict begin pagecount
10 mod {showpage} 1 add repeat
In addition, I believe it would be possible to write a PostScript program that could figure out if it's running under an interpreter and behave accordingly (requires some research).
So, if you have any PostScript hackers, your best bet is to rely on a hardware page count. If you don't have any hackers, on the other hand, you can simply count the "%%Pages:" DSC comment that PostScript-generating programs put in
http://tronche.com/gui/x/xlib/
About three months ago I got sick of all other window managers, so I wrote my own. Writing a window manager was the most fulfilling software project I've ever undertaken.
My window manager now does all the things I want it to do, none of things I don't want it to do, and I'm running it full-time. Running your own software full-time is an experience every programmer should have - you learn to write solid code, as it would really suck if my window manager crashed while I was writing this into Netscape.
I won't go into a diatribe about why I wrote it, but needless to say, it does a number things that all the other window managers I've tried get completely wrong (and yes, I've tried a lot of window managers, including the "configurable" ones like sawfish and scwm).
At some point, I might release my code, but that would probably require putting in hooks for a configuration file (since it's MY window manager, all the configuration I need to do is 'vi main.c'). If there's enough interest, I can go into details about what it does differently and at some point, I might even release some code. I really couldn't care less if anyone else uses this, however. This is MY window manager, and it does everything I want (this is why you should write your own, saying that feels really good).
Anyway, if you know any C, you should try writing your own window manager (think about it - what would be more satisfying, writing another GNOME/KDE applet, or writing software that you'll be using 100% of the time?). Here are the resources you'll need:
You'll need to know Xlib. You can get the xlib manual in troff from XFree86 CVS, or you can read it online at the link above. I found the greppable, linked html much nicer than a big PostScript file.
You'll need to follow the ICCCM recomendations if you want your window manager to play nice with other apps.
The KDE and GNOME people say this is the standard for their desktops. Most of the stuff here is pretty simple, but you should look it over first, as it assumes quite a bit about how you implement your window manager (so you should implement it a certain way in order to support the KDE/GNOME stuff).
For reference, it took me about three weeks and 6000 lines of code to get something I could use full-time. You might also want to look at other window managers' code: there's a window manager called '9wm' that's very small and whose code is extremely legible. Trying to read code from Enlightenment or WindowMaker is not the best way to go as these are very large codebases and use multiple levels of indirection (which makes understanding how some detail is implemented very difficult).
I can supply more information for the potential DIY-er if needed.
While we're on the subject, does anyone know of a reference for Motif hints? I would rather not use someone else's code (licensing restrictions, etc), and would like the definitive reference, if such a thing exists.
More interesting than the computer were the books on the shelf - Design Patterns, Applied Cryptography, Programming Perl - I doubt many windows users read those.
I guess some people still need to run bl0ated windows software for some reason, but VMWare lets you do a whole lot more than that. As for your point about developing in a simulated environment, yes you probably wouldn't want to release code that you never ran on a real machine, but in some instances VMWare just saves a lot of time -- you don't lose your editor when your machine goes down (happened a lot to me in Visual Dev.) and you don't have to keep jumping from keyboard to keyboard when writing a network application in an environment where ssh is not an option.
This has not been a paid endoresement, I just really like this program.
This is not always true.
Sometimes, the front-end ends up being the only way to configure whatever it's supposed to configure, or the front-end is the only one with the documentation.
For example, look at OS X Server. Yes, it's a real unix, but everything is handled by gui-front ends, or by some java application that you access through netscaping to some port. The problem is that you can't really do something non-trivial (like add a user) without a java-capable browser (which OSX doesn't have), or by actually sitting down at the machine (so you need at least two machines handy to do any work). When things go bad, you have to go to the machine to change something (you can't just ssh in and mess with some config file). The man pages that came with it were a joke, and you couldn't change anything about the appletalk sharing or the Macintosh Manager authenticator through the console. I had a list of about 30 users I wanted to add -- I couldn't do any sed/awk magic with /etc/passwd and be done with it, I had to type in each name/passwd individually (and mess with the mouse in between adding each name to change groups, etc.). Sure, it was easy to add a user if you'd never done it before, but if you wanted to do any maintenance/configuration, you had to sit at the computer (no X server), with another machine nearby (no java browser). Altogether, it was a big mess.
Fortunately, this happens only rarely in Linux -- I can just copy my config files over to a new machine when I set it up and I can change whatever I want about the system with an ssh session from anywhere in the world. The point is that if new tools start being developed with gui configuration in mind rather then textfile configuration, people need to make sure that instead of just saying "to change xyz, click here," also saying "to change xyz, edit /etc/foo.conf; see foo.conf(5) for details." OSX didn't provide the textfile configuration I needed (and as a result, I haven't touched our OSX server in months).
This is already starting to happen to Linux. For example, I use WindowMaker for my windowmanager, and to configure it, you can use WPrefs, which just writes some config files. Unfortunately, I couldn't find the documentation for those config files (and they didn't have any comments at the top to help me), so I was stuck using WPrefs to change things. At one point, I wanted to get rid of all icons entirely, but there was no way of doing this with the front-end. I needed to edit the files, and the only way I could work was by changing something, restarting windowmaker, and seeing if it did anything (and config files would be overwritten at points so I would lose all my work). I finally did it, but it was a slow and tedious process, whereas if I had a manpage for the config file, I could have had it done much more quickly. This was a simple task, but imagine if there were no manpage for /etc/sshd_config or /etc/smb.conf. The only way I was able to get X initially working on my machine was to edit XF86Config, and I wouldn't have been able to do that without a manpage.
My point is that gui front-ends (like xf86configurator or WPrefs) are replacing my emacs, and I don't like it. People are starting to put more thought into writing front-ends for editing a file rather than documenting the file's format.
Of course, this all ties into the point made earlier which is that interface design can be vastly improved. By this, I mean that if I'm going to make heavy use of an application (like my text editor), I should be able to change every miniscule detail about its operation--for a keyboard person like me, that means I set up all my own key bindings, using any keys that I wish (I don't use any of the bindings for my emacs keys which are intercepted by the windowmanager, like M-tab for ispell), and for the mouse-oriented person, that means that all menus/mouse clicks should be configurable. More at the core of the problem is that people noways think an application is usable if it allows access to all of its commands from a menu, and this is wrong. An application is configurable if I can combine its commands in ways that I think are useful. Every application that I'm going to spend a lot of time in should have some sort of powerful scripting language built into it. Emacs is a good example of this; if I see that I'm doing a lot of things repeatedly, I should be able to script those things and make them available as a command, either via keyboard or mouse (that's what computers are good at, automating repetitive tasks). To me, that's what seems to be the whole idea behing the unix shell--you combine a bunch of commands together and end up with something suited to your own tastes. When I use an application written without this in mind, I feel like George Jetson at his job, where he spent all day pushing a button; look at netscape for instance. I spend a lot of time hitting escape to continue loading a page when some advertisement banner linked from a slow server pops up. I should be able to right-click on these banners whenever I see them and say "Don't ever load any animated gifs from this server again." I would be willing to spend the time to learn whatever scripting language to get this simple feature (but I would not be willing to go through tens of megs of C that I don't have a hope of understanding). By the same token, I want a powerful scripting language which gives me access to all features of the application, not like the little javascript toolbar buttons you can set up in netscape which are deliberately watered-down (and whose documentation is not readily available, rather hidden away on netscape's site, as if it would confuse new users if there was an "advanced configuration" item under the help menu).
This idea has been said before--look at Guido van Rossum's current project, Computer Programming for Everybody. (Guido van Rossum is the creator of Python.)
Don't feel bad. I'm only 19 and I also don't understand any of this nonsense. Case in point: I downloaded a theme. The actual background in the download has a bunch of C code (perhaps an exploit of some sort?) with the rendered letters "31337" in the foreground.
This troubled me. What was the significance of this number? There must be some meaning behind this number if someone was going to take the time to render it so nicely. Unfortunately, the only interesting thing I was able to find about 31337 is that it is a prime number, not a fibonacci or a marconi or anything else. I was rather disappointed.
Later, someone told me the significance of my desktop background. That wasn't exactly the image I was trying to portray.