Slashdot Mirror

Well, you can just use Vibrotactile belt to get north direction.

Download Extension here

Mirror

But, since Swing ALREADY has the GTK theme, I have to disagree that writing all the peers is any easier than calling a single line of code to switch themes.

This is misleading for two reasons. First, what Swing has already is NOT what I want. Since it is necessarily written in pure Java, the best it can do is emulate the look and feel of GTK. Perhaps it can do a reasonably good job, but it seems unlikely to be perfectly correct in all cases and even a small visual inconsistency can be distracting. Swing is less likely still to quickly adjust to GTK theme improvements over time. Of course, having a Swing theme that emulates the *default* GTK theme and one that emulates the *current* GTK theme whatever it may be are different things. I very much doubt that Swing does or will ever do the latter. (I notice that gtkswing clearly states that only the default theme is supported. Is that the theme you are referring to?) Remember that new GTK themes are created all the time, just as Swing themes are. How could Swing possibly have support for all of them, and why would the developers even bother trying? Using AWT peers will give complete and correct support for the current -- not just the default -- GTK theme no matter when it was created or where it came from, for no additional effort.

Second, much of the work needed to write such peers has already been done. Perhaps the GCJ team is reusing work done for java-gtk in which case the heavy lifting is already finished. Either way, from my perspective it's just a matter of waiting. Meanwhile my AWT applications, while terrifically ugly, are quite functional and will get better looking with no code changes when the GTK peers appear.

Starting a new process for every incoming request is insane regardless of language. Otherwise, Thread Pools wouldn't exist.

Not so. Starting a new process for every incomming request is perfectly sensible if performance requirements are within a certain range (this depends on the hardware in use and what other applications need to run on the same machine). Clearly a persistent approach such as mod_python or servlets will give better performance, but this is not always needed and is always more complex. That means more time consuming to create and debug. Consider a company that needs a prototype of a web application, for instance. A few simplistic Python scripts can be put together easily and will likely be more than fast enough to get the point across. Doing the same thing with Java is not likely to be a good idea, because the syntax is more complex, because there is a separate compile step (Python compiles to byte-code as it runs) and because performance is sure to be dire.

I think it more likely that the Apache mod is the problem, rather than the Java VM. Pure java apps from the command-line seem to run very fast on both Windows and BSD. It is only from Apache that they seem slow.

I think it is impossible for Apache to be the problem, because it has no idea what language a CGI script is written in and therefore would have to deliberately introduce delays to slow down Java. In my experience the overhead required to bring up a Java virtual machine is considerable, and this makes command-line performance unacceptable for many purposes where Python does fine. This point of view is seconded by engineers at Sun Microsystems in the internal memo I linked to last time.

Personally, I have installed a few different applications that installed their own JRE, and I submitted bug reports to those companies because A) They were installing JDK 1.2 when I already had 1.4.2 on my system; B) They were ILLEGALLY installing the JRE (which gets back to your original point).

Point A is quite deliberate and I expect your bug reports don't get far before being stamped WILL-NOT-FIX. These vendors want a JRE that they can depend on to behave pre

mirror of pdf

temporary screenshot mirror

In a Windows environment, cut/copy and paste just plain work, using the same key shortcuts and options from the pull-down menus, on every single app.

Two important points:

1) Of course, continuity in user interfaces is important. But let's not forget about the advantages of diversity. If *every* system works the same way, how will we ever discover new (and potentially better) ways of interacting with machines? The best example is the QWERTY keyboard: Everybody uses it (and that is the only reason for its existence), although it has been shown many times that there are much better keyboard layouts (e.g. Dvorak).
Think about evolution.

2) I'm pretty sure that copy'n'paste doesn't work in windows' "command line" the same way it does in windows-gui-apps. Tried pressing c-v or c-c there? I don't think it works. Also, you cannot highlight text in windows' command-line and right-click it to get a context menu (like everywhere else in windows).

I honestly can't think of any recent linux gui app where c-c and c-v doesn't work as expected.

quick google search:
Java-GTK
QTJava