Slashdot Mirror
New Desktop Features Of Next Java
bonch writes "Sun has posted the new desktop features of the next Java, codename Mustang. Improvements to Swing look and feel, OpenGL 2D renderer performance, AWT features such as the ability to add a tray/panel icon, and improved deployment capabilities."
First off, no one said it's what we need. And regardless if you or I feel there might be no need for it (I personally use it daily), there are plenty of shops out there that do.
And second, they're addressing a significant issue with Swing which is its pokyness. This is going head on with SWT , a 'feature' that Eclipse people have enjoyed for sometime. This also signifies Sun throwing in the towel on their whole Swing widget abstraction, abstraction, abstraction mantra in favor of using the native OS rendering widget facilities. This has been a major Java gripe for some time; why can't my Windows Java app look like a Windows app and why does it have to be do damned slow?!
Should be interesting to see how these features/additions play out. Also, looks like Swing apps are finally getting native aa font support. This will please many as the text rendering in Java apps is still in the Windwos 2k/GTK 1.x days..
but I like to position the elements where I want them, and not how some layout manager feeld they will will go best.
Thing is that "some layout manager" will know about the different conventions used for different human languages when it comes time to localize your software. Pixel layout is dead because different languages use different numbers of letters to spell the same thing. And in Israel and the Arab world, text in the local languages reads from right to left.
Also, Swing integrates well into the rest of Java, including Java2D, where SWT does not.
File under 'M' for 'Manic ranting'
Personally, I'd be happier if they completely dropped swing support on the Mac ,or at least removed aqua L&F.
There is a proliferation of really horrid java applications on the Mac because people don't understand that you cannot WORA and have GUI make sense. Users of different operating systems have different needs and expectations, even when they are equivalent 'types' of users with relatively equal computer experience.
I'm very excited with all the improvments Java is going through, but I'd hate to see it all being completely missed by the general public and web application developers if Microsoft won't include the JRE and Java Plug-in in Longhorn.
Anyone knows what going on with this issue?
If you didn't RTA, you may not have noticed that the *FIRST* thing on their list of improvements was improving the native look and feel for both the windows and gtk platforms.
But how close is it to the native Windows look? I've found that whenever someone does custom widgets that tries to emulate the native look, there's always something missing or slightly different that produces a disconcerting GUI feeling. Maybe a lot of people don't notice, but I'd rather it look completely different than almost the same but with quirks. Eclipse is good in this manner. It looks very nice and fits right in with other Windows apps.
Simple really-- some programmers are lazy. They can't be bothered with optimizing their code for individual platforms
Sorry, but that's a pretty ignorant attitude. Judging an application soley on being java-based is a poor method. Rather, you should ask if the developing language is appropriate for the task. If someone told me they wrote a graphically intense FPS in java I would be suspicious. But, if the app only needs to be light and portable java may be a good choice. It allows for very easy control of how the application looks on multiple operating systems. A good example of a nice-looking java app with no speed issues is Limewire. It runs quickly, works well and can be updated more efficiently than if they had used a graphical toolkit for python or C. Not that anything is wrong with chosing python or C either. It entirely depends on your application requirements and development resources. Brushing off all apps written for the JVM (or any development kit) will cause you to miss out on a good app sometime.
It does, on linux and Solaris, I believe. No 64 bits on windows, perhaps because windows doesn't support it?
First, it seems like KDE/Qt has more momentum than GTK on the desktop. Qt apps look better and are more integrated with eachother. Suse is the dominant desktop Linux distro and Suse is KDE-oriented. I'm glad that Java is going to be using native GTK for rendering, but what I would really like to see is native Qt. Maybe they could create some kind of interface to make it easier to plug in different rendering systems? Maybe they could open source Java and let the community take care of it? Maybe they don't care because desktop Linux is only about 5% of the market anyway? But still, it's something I would like to see.
The second thing they need is a "SwingLite", or some easier way to do common things. For example, it is very common to need a text field that allows the user to enter a number, but not text. Should be easy, right? This is the code I have to use to do it:
That's just wrong. I should be able to say:or maybe:The above example, involving two different factory classes to just get the field to accept integers only, puts a high burden of knowledge on the programmer, and Swing is full of stuff like that. It's great that the power is there because I can write my own hierarchy of text formatting factories and objects that enforces correctly-entered Sandhi rules, but that doesn't come up very often, and what does come up very often is having to enter a plain old number, date, currency value, that kind of thing. And I'm just using this one example, but this kind of over-design is all over the place in Swing.The final problem that they have is putting emphasis on plugable look and feel. Application developers shouldn't get to decide the look and feel of their apps. That should be determined by the desktop environment. Pluggable look and feel is not a feature; it is a bug. It should be deprecated and removed.
----------
Educational software
and suggest Eclipse or IntelliJ as a better java IDE.
"Look Lois, the two symbols of the Republican Party: an elephant, and a fat white guy who is threatened by change."
"Dear China,
I am inexperienced with the Chinese language. I am having difficulty learning it because I find it ridiculously complicated. Please simplify it.
Signed,
VolciMaster"
As for the layout managers, you just need practice with them. My suggestion is to stick with BorderLayout, FlowLayout, and BoxLayout (with some widgets from the Box class). You can easily nest panels using those layout managers to get what you want, 99% of the time.
Do you know what frustrates me about Windows development (using C++ Builder)? Absolute positioning. I place things where I want them, run the app, resize the window, and nothing moves! Only the window gets bigger. Once you get the hang of layout managers you'll see how easy they are to use and how much nicer your UIs will be.
Well, when there's a replacement for C++ that 1. has RAII, 2. allows allocation of objects on the stack (probably required for 1), 3. has operator overloading, and 4. doesn't force user code to distinguish between user-defined and "primitive" types, I'll consider it as an upgrade. As it is, Java is a step backwards in all of the above areas.
About time they started thinking about the desktop. Java rules the server, why not the client?
You can use the MacMetrics Metal theme I wrote to get an approximation of how things will be laid out under the MacL&F