many of those military personnel with the neighborhood smoking weapons will support the revolution rather than fire on American Citizens.

I agree, but what does that have to do with private gun ownership?

go tell that to all those terrorist cells and the vietcong

Yea they did great, they are now running the world and everybody loves them.

Also the vietcong had a bit of outside help, you may have forgotten about it but the same country is in the news right now for doing something similar in a country further west.

Studies done by the armed forces have already shown that some of those in the military will turn on their own government if it came down to revolution.

Wow! You really shot yourself in the foot on that one. Yes you have shown how a popular revolution may defeat the military. However that solution does not require private ownership of firearms! In fact there are some indications it may work better if there are no private guns (the military defector is more likely if the people he is going to join are not shooting at him).

Personally I don't see too much problem with guns, but I have to point out that you just made a really stupid statement if you are trying to argue for them.

That is not the same.

What I want is to be able to push a button in one application (or select text) and not have it raise above the other application. I also want to eventually raise that first application (perhaps by clicking the title bar). "layers" does not do this, and in fact "layers" are a very very bad idea.

This is finally causing serious problems with drag & drop (as you cannot drag from a window without it raising) so they are finally starting to get a clue. Unfortunately I am seeing the "windows solution" rear it's ugly head: there are proposals that an app must communicate to the window manager the "drag start target regions" so that raise is prevented.

The real solution is TRIVIAL: don't raise the window when there is a click, and allow the application to raise *if it wants to* in response to a click. Unfortunately slavish copying of Windows has made this actually be considered politically incorrect, including incredible bone-headed statements like "the user will be confused by not knowing if the action will raise the window" (use "standards" to fix that), or that "programs should not raise unexpectedly" (again, use "standards", or you can ignore raise requests if not attached to a click event).

The GP *was* using the proprietary drivers. He was complaining that they were broken, and to his surprise the FOSS driver worked better.

I agree that the open source versions are nowhere near the nVidia proprietary drivers, though.

Yes I would agree. Linux desktops have been broken like this forever.

If I launch a program from the desktop and it exits with an error, can you PLEASE put up a window containing whatever was printed to stderr? It is NOT user-friendly to have nothing to happen. And no, a user is not going to figure this out by "reading the logs".

To be honest, most of the problems with Windows Shell have been slavishly copied by the Linux window managers. Being able to click without raising windows disappeared years ago, and along with that any ability to actually use overlapping windows. Lots of other bad stuff also copied "because it is user friendly" but that is the big one.

Arnold is the real threat

I'm pretty certain RenderMan supports subdivision surfaces, same as Blender (although RenderMan may have more advanced ones).

Nurbs are pretty much obsolete for non-engineering models.

You are correct that it had to detect whether there was a value before the left square bracket. I worked on very early NeXT (when it ran on a Sun workstation as the hardware was not available yet), and I did try to fool it with gibberish. It appeared to depend on the last non-blank character: if it was any punctuation other than ')' or ']' then it was a method call. Comments could break it, "array/*comment*/[10]" would produce syntax errors.

What was really annoying is that it did not detect typos until run-time, since it simply put the message name in quotes and looked it up in a hash table when the call was done. I guess this is familiar to people using python today, but then it was a pretty annoying concept. I believe this was fixed by Apple, but it was true of every version of NeXT I used.

Oh come on. It is pretty obvious that you can add named parameters to a C-like syntax without having this weird square bracket stuff:

      someObject->setColor(red:0.4, green:0.3, blue:1.0, alpha:0.5);

The square brackets are there because the original Objective-C compilier was very primitive. It basically looked for the square brackets, did some manipulation of the text, and passed everything to the C compiler. Pretty much it turned this:

    [someObject method:x]

into this:

    callMethod(someObject, "method", x)

Yes they were copied from smalltalk, but in smalltalk all functions used the same syntax. In this case the unnecessary differences in syntax were to make this compiler simple to implement.

Nuke and a lot of other software used for computer graphics.

You are right that NeXTStep's DPS added PostScript commands to create windows. Still not as nice as NeWS as it did not use paths to describe the windows, they were rectangles only. Also NeXTStep itself strongly discouraged using these functions, at that level DPS was pretty much output-only and only into a subset of the windows.

I think there was an attempt at DPS on Windows which, like XDPS, did not supply any way to create or manipulate windows. I kind of doubt there are any other implementations.

The main advantage of NeWS is that it reused the PostScript path & transforms for defining the windows themselves.

DPS forced you to use a different api to the server (ie X) to make the windows, and some really ugly glue to make the agree on which window was which. I don't think it did anything with events at all so you could not run any widgets on the server.

Or NeWS which was a much better design.