Trolltech releases second preview of Qt for Java

Discussions

News: Trolltech releases second preview of Qt for Java

  1. Trolltech has released a second preview of Qt Jambi - a prototype version of Qt that allows Java programmers to use the popular cross-platform development framework. This second release incorporates the feedback of over 1700 beta testers, and features new additions like Web Start functionality, improved integration with Eclipse and single JAR file deployment for Qt Jambi-based applications. More information is available in the Qt Jambi product alert with tech details in the Qt Jambi Whitepaper. To try it out, sign up for the preview license and download.

    Threaded Messages (50)

  2. ????[ Go to top ]

    We are using a popular cross-platform development framework, its called Java!
  3. !!!![ Go to top ]

    Ever tried to make crossplatform use of the system tray (including notification popups) etc. with plain java/swing? Ever tried to access clipboard contents from external applications in a sane way? QT offers really great desktop integration on all three major platforms, an area were Java/Swing really doesn't shine (maybe 1.6 will be the turn for the better). Furthermore i really prefer the signal/slot event handling mechanism, but maybe that's a matter of taste.
  4. JDIC?[ Go to top ]

    How does it compare to JDIC?
  5. Re: !!!![ Go to top ]

    Ever tried to make crossplatform use of the system tray (including notification popups) etc. with plain java/swing?
    Ever tried to access clipboard contents from external applications in a sane way?

    QT offers really great desktop integration on all three major platforms, an area were Java/Swing really doesn't shine (maybe 1.6 will be the turn for the better).

    Furthermore i really prefer the signal/slot event handling mechanism, but maybe that's a matter of taste.
    Good point. Proper integration with the desktop is a good enough reason for me to consider it. Some of these facilities are also available for Swing in JDesktop Integration Components https://jdic.dev.java.net/, and as you mention some are coming in Mustang http://download.java.net/jdk6/docs/api/java/awt/SystemTray.html.
  6. If people keep on releasing new Java GUI frameworks then soon Java won't be any different than C++. Well, it will be worse, because the "new frameworks" are really wrapped C++ frameworks, so we'll have C++ frameworks + Swing + AWT.
  7. Re: More Java GUI frameworks[ Go to top ]

    If people keep on releasing new Java GUI frameworks then soon Java won't be any different than C++. Well, it will be worse, because the "new frameworks" are really wrapped C++ frameworks, so we'll have C++ frameworks + Swing + AWT.
    Why would it matter? Rare people use swing/awt for desktop applications anyway (other than business softwares). If sun really wants to enter the desktop market, it should promote swt and throw away swing. Nobody likes a non-native GUI - it looks differently and works differently, even with best emulation. It's just inconsistent with everyone's desktop.
  8. Interesting, did anyone see this: http://doc.trolltech.com/qtjambi-1.0/qtjambi-deform.html I'd be interested so see how it compares with using Swing or SWT. I'd be very happy if we had an interface toolkit that competed with the Swing monstrosity.
  9. Vector Deformation[ Go to top ]

    Interesting, did anyone see this: http://doc.trolltech.com/qtjambi-1.0/qtjambi-deform.html I'd be interested so see how it compares with using Swing or SWT.
    That example really doesn't have anything to do with Swing or SWT. All the effects going on there would be handled in Java2D. In general, Sun has put tons of work into making Java2D very fast with hardware acceleration. Mustang, in particular, has all sorts of improvements with a new OpenGL-enabled pipline. Cheet Haase talks about a lot of these improvements on his blog: http://weblogs.java.net/blog/chet/
  10. Re: Vector Deformation[ Go to top ]

    Hi Toby Yes indeed, that is true. They were meant to be two seperate comments. 1-This is nice. 2-How does QTJambi compare with Swing/SWT. I'm aware of the changes in 6, I just don't think they will save Java on the desktop, too little too late. Java desktop apps look terrible when compared to native apps, especially on OS X where 3D effects, animations, transparencies, shadowing, drag an drop are the norm. Whereas in Swing you're just glad if you can get it to look less than embarassing ... let's not even talk drag and drop eh! And yes, it will be better in the next release, no really it will. I'm Ggad Trolltech have done this, even if for no other reason than upping the ante. Kind regards Neil
  11. Re: Vector Deformation[ Go to top ]

    I just don't think they will save Java on the desktop, too little too late.
    It is a myth that Java is not used much on the desktop. It is nice to see more choice for GUI development in Java, but in no way does it need saving. Tools for Swing GUI development like Matisse weren't developed just for the fun of it - there is a real demand for such things.
  12. Re: Vector Deformation[ Go to top ]

    Java desktop apps look terrible when compared to native apps, especially on OS X where 3D effects, animations, transparencies, shadowing, drag an drop are the norm. Whereas in Swing you're just glad if you can get it to look less than embarassing ...
    No offense, but I don't think you have any idea what you're talking about. I've written a very pretty GIS mapping interface in Swing myself (which was actually mostly powered by Java2D). Aerith is a great example of a beautiful Swing app. http://www.flickr.com/photos/romainguy/sets/72157594161003744/ https://aerith.dev.java.net/ I was there at JavaOne when it was demoed. The neat thing about Aerith is that it shows how easily Swing components can be integrated with OpenGL (via JOGL) for super neat effects. Not even the best toolkits in the world can prevent people from making ugly, frankenstein UIs. QT isn't going to change anything.
  13. Re: Vector Deformation[ Go to top ]

    Java desktop apps look terrible when compared to native apps, especially on OS X where 3D effects, animations, transparencies, shadowing, drag an drop are the norm. Whereas in Swing you're just glad if you can get it to look less than embarassing ...

    No offense, but I don't think you have any idea what you're talking about.

    I've written a very pretty GIS mapping interface in Swing myself (which was actually mostly powered by Java2D). Aerith is a great example of a beautiful Swing app.

    http://www.flickr.com/photos/romainguy/sets/72157594161003744/ https://aerith.dev.java.net/

    I was there at JavaOne when it was demoed. The neat thing about Aerith is that it shows how easily Swing components can be integrated with OpenGL (via JOGL) for super neat effects.

    Not even the best toolkits in the world can prevent people from making ugly, frankenstein UIs. QT isn't going to change anything.
    No offense, but unless you're talking about Mustang builds then yes, Swing apps have looked pretty crappy compared to native toolkits. There's a reason that SWT was developed.
  14. Re: Vector Deformation[ Go to top ]

    No offense, but unless you're talking about Mustang builds then yes, Swing apps have looked pretty crappy compared to native toolkits.

    There's a reason that SWT was developed.
    SWT was developed because of various issues regarding Swing years ago, and for other reasons too, which had nothing at all to do with Swing. Eclipse was a successor to IBM's VisualAge line, which had a history of using native look-and-feel widgets as against emulated - there was more than one reason that SWT was developed, and one of those was history - it followed the traditions of earlier approaches. Things change, and they have certainly changed with Swing and SWT. I have not evaluated the latest versions of SWT, but there certainly have been issues with SWT performance on Linux, and a lack of an up-to-date look-and-feel on Windows (with a Win2000 rather than XP look).
  15. Re: Vector Deformation[ Go to top ]

    SWT was developed because of various issues regarding Swing years ago, and for other reasons too, which had nothing at all to do with Swing.
    Mustang isn't out yet, so it isn't various issues regarding Swing years ago
  16. Re: Vector Deformation[ Go to top ]

    SWT was developed because of various issues regarding Swing years ago, and for other reasons too, which had nothing at all to do with Swing.


    Mustang isn't out yet, so it isn't various issues regarding Swing years ago
    My post was in response to:
    There's a reason that SWT was developed.
    The decision to develop SWT was obviously because of issues regarding Swing years ago, because of the age of SWT. Work on Eclipse started at IBM in the late 90s. They would have been evaluating the option of using the version of Swing that came with Java 1.3! Since that time, things have changed dramatically. Even before Mustang, Swing is now a far better looking and performing system that it was 6 or 7 years ago. I think it is fair to say that if a project like Eclipse was started now (even before Mustang), it is, I believe, unlikely that SWT would be thought necessary.
  17. Re: Vector Deformation[ Go to top ]

    Even before Mustang, Swing is now a far better looking and performing system that it was 6 or 7 years ago. I think it is fair to say that if a project like Eclipse was started now (even before Mustang), it is, I believe, unlikely that SWT would be thought necessary.
    Possibly, but I disagree that anything pre-Mustang really cuts it for desktop development, unless you're forcing it on corporate IT workers (which is where the vast majority of Swing apps are).
  18. Re: Vector Deformation[ Go to top ]

    Even before Mustang, Swing is now a far better looking and performing system that it was 6 or 7 years ago. I think it is fair to say that if a project like Eclipse was started now (even before Mustang), it is, I believe, unlikely that SWT would be thought necessary.


    Possibly, but I disagree that anything pre-Mustang really cuts it for desktop development, unless you're forcing it on corporate IT workers (which is where the vast majority of Swing apps are).
    I disagree. I have been developing user interfaces on a wide variety of platforms and with a range of GUI APIs and tools since the mid 80s. My experience is that conforming to a native look and feel is a vastly overrated quality for an application. What matters is good design of the application and reasonable performance of the GUI. The irrelevance of native look and feel is surely demonstrated by the ease which with users work with web applications. It is also shown by the range of popular applications, such as media players, which largely ignore such matters, yet users rarely find them problematic. The lack of importance of look and feel is surely also demonstrated by SWT and Eclipse, which only in the last release finally conformed to the new XP style; previously looking like a legacy Win98/2000 app. What has been a serious issue with Swing is performance, and that seems to have been largely dealt well before Mustang in my experience.
  19. Re: Vector Deformation[ Go to top ]

    I disagree. I have been developing user interfaces on a wide variety of platforms and with a range of GUI APIs and tools since the mid 80s. My experience is that conforming to a native look and feel is a vastly overrated quality for an application.
    It doesn't really matter if you think that native L&F is vastly overrated. The fact is that most people do desire it and Swing has had problems in that category.
    The irrelevance of native look and feel is surely demonstrated by the ease which with users work with web applications
    Web applications came about because of deployment issues, not because of ease of use.
    The irrelevance of native look and feel is surely demonstrated by the ease which with users work with web applications. It is also shown by the range of popular applications, such as media players, which largely ignore such matters, yet users rarely find them problematic.
    Media players tend to have skinning options and are not your run of the mill business applications.
    The lack of importance of look and feel is surely also demonstrated by SWT and Eclipse, which only in the last release finally conformed to the new XP style; previously looking like a legacy Win98/2000 app.
    But still used native fonts which have been far superior to Swing's.
  20. Re: Vector Deformation[ Go to top ]

    I disagree. I have been developing user interfaces on a wide variety of platforms and with a range of GUI APIs and tools since the mid 80s. My experience is that conforming to a native look and feel is a vastly overrated quality for an application.


    It doesn't really matter if you think that native L&F is vastly overrated. The fact is that most people do desire it and Swing has had problems in that category.

    The irrelevance of native look and feel is surely demonstrated by the ease which with users work with web applications


    Web applications came about because of deployment issues, not because of ease of use.

    The irrelevance of native look and feel is surely demonstrated by the ease which with users work with web applications. It is also shown by the range of popular applications, such as media players, which largely ignore such matters, yet users rarely find them problematic.


    Media players tend to have skinning options and are not your run of the mill business applications.

    The lack of importance of look and feel is surely also demonstrated by SWT and Eclipse, which only in the last release finally conformed to the new XP style; previously looking like a legacy Win98/2000 app.


    But still used native fonts which have been far superior to Swing's.
    I just don't think that most people do desire it. I think it is one of those things that is probably considered necessary in corporate environments or by marketers of software, but in practice it has little impact on users one way or the other. Further proof of this is how even Microsoft introduce new types and styles of controls in their Office suite, which can be quite different Do you hear mass complaints about lack of usuability of MS Office because the toolbar buttons look somewhat different in style, or because they have different highlighting on menus? My experience is that what people want is standard options on menus and standard layout of components in, for example, file dialogs, but the exact size, shape and colour of buttons is of not the slightest consequence. Your statement about web applications is irrelevant - it does not matter how they came about; people certainly do can find them easy to use, which shows how irrelevant precise following of native look and feel is. It is also irrelevant that media players are run-of-the mill business apps; again, what matters is that having controls and other options which don't conform to standard designs doesn't matter. You are right about the fonts, but that is by no means a substantial matter, unless you are actually writing a design app or word processor in Swing...
  21. Re: Vector Deformation[ Go to top ]

    I just don't think that most people do desire it. I think it is one of those things that is probably considered necessary in corporate environments or by marketers of software, but in practice it has little impact on users one way or the other.
    What you wish people to feel about it and what the reality is are two different things. The reality is that the implementation of Swing has been problematic and part of the reason why general consumer-oriented Java desktop apps just didn't happen. The failings of Swing are self-evident to developers and why they don't develop general desktop apps in it.
    Further proof of this is how even Microsoft introduce new types and styles of controls in their Office suite, which can be quite different Do you hear mass complaints about lack of usuability of MS Office because the toolbar buttons look somewhat different in style, or because they have different highlighting on menus?
    And even with different themes, invariably fit in to the desktop environment much better than Swing.
    Your statement about web applications is irrelevant - it does not matter how they came about; people certainly do can find them easy to use, which shows how irrelevant precise following of native look and feel is.
    You were the one that said that the prevalance of web apps are an indication that native integration isn't desired or necessary. That's just wrong. It's all about deployment.
    It is also irrelevant that media players are run-of-the mill business apps; again, what matters is that having controls and other options which don't conform to standard designs doesn't matter.
    No, I said that media players are not run of the mill business apps.
    You are right about the fonts, but that is by no means a substantial matter, unless you are actually writing a design app or word processor in Swing...
    Since text is generally still the most important part of an application, it's ridiculous to say that it isn't a substantial matter. And in these days of LCDs, it's probably the biggest part of what makes Swing apps stand apart from native toolkit apps. But generally, you might wish that the perception about Swing wasn't there and you might wish that people didn't care about the shortcomings of Swing. But your wishes don't jibe with what developers and end-users feel about Swing.
  22. Re: Vector Deformation[ Go to top ]

    What you wish people to feel about it and what the reality is are two different things.
    As both an everyday user of Swing apps, and as a developer who deploys Swing apps, I am not talking about what I wish people to feel, I am talking about what I have experienced that users say about apps. I admit this is only my experience.
    The reality is that the implementation of Swing has been problematic and part of the reason why general consumer-oriented Java desktop apps just didn't happen. The failings of Swing are self-evident to developers and why they don't develop general desktop apps in it.
    No, the failings aren't self evident, at least not with recent versions of Swing. The differences between current versions of Swing and Mustang versions are minimal - mainly cosmetic - qualitative improvements rather than dramatic changes. To claim that there is some 'quantum leap' here that is the difference between acceptance and the desktop and not is rather extreme. There are very good reasons why developers don't develop general desktop applications in Swing - most developers don't develop general desktop applications. Almost all applications are for very specific custom internal or vertical market use. There have been very successful desktop GUI development languages and systems which you almost never hear about because they are used almost entirely for internal apps, such as Delphi. But hold on - I am wrong. There are general desktop applications written in Swing, and some very succesful ones, such as Moneydance - one of the most highly rated personal finance manager products. Then there is JEdit. Yahoo SiteBuilder... General claims such 'as they don't develop general desktop apps in it' are almost always wrong..
    Further proof of this is how even Microsoft introduce new types and styles of controls in their Office suite, which can be quite different Do you hear mass complaints about lack of usuability of MS Office because the toolbar buttons look somewhat different in style, or because they have different highlighting on menus?


    And even with different themes, invariably fit in to the desktop environment much better than Swing.
    So we are now switching from look and feel issues to integration with the desktop (whatever that means)?
    You were the one that said that the prevalance of web apps are an indication that native integration isn't desired or necessary. That's just wrong. It's all about deployment.
    The deployment issue is neither here nor there for this issue. What matters is that in practice, users usually have little difficulty with them, in fact my experience is that users actually prefer web interfaces (they seem less afraid of them than of conventional apps). If your argument held, then users would reject web apps because their controls did not conform to native platform look and feel.
    No, I said that media players are not run of the mill business apps.
    I know - I missed out a 'not', but the point applies. Users aren't stupid. They can tell what a button is, and what a menu is. They really aren't put off apps being non-standard - what matters is good design.
    Since text is generally still the most important part of an application, it's ridiculous to say that it isn't a substantial matter. And in these days of LCDs, it's probably the biggest part of what makes Swing apps stand apart from native toolkit apps.
    It isn't a substantial matter. If we really are down to that level of trying to discriminate Swing apps from 'native' apps, Swing is doing well. Swing can use native fonts. I open up my font options under NetBeans, and I see a long list of fonts - virtually all that are installed on my XP system. There are rendering issues, but to claim that these are of major impact is extreme.
    But generally, you might wish that the perception about Swing wasn't there and you might wish that people didn't care about the shortcomings of Swing. But your wishes don't jibe with what developers and end-users feel about Swing.
    Following the history of Swing, almost all the issues have been to do with performance. Other issues have been largely dealt with by additional component libraries and pluggable looks and feels.
  23. Re: Vector Deformation[ Go to top ]

    Steve, your problem is that you can defend Swing until your blue in the face, but the reality is that you don't get to define what the perception of Swing is for developers and the general public at large. The lack of native fidelity has been problematic for Swing, whether you like it or not. But back on topic... Frankly, the Qt bindings seem a little late to the party considering the license costs, that many of Swing's weaknesses have finally been addressed in Mustang, and that Unix desktop developers have virtually ignored Java as a development technology.
  24. Re: Vector Deformation[ Go to top ]

    Steve, your problem is that you can defend Swing until your blue in the face, but the reality is that you don't get to define what the perception of Swing is for developers and the general public at large. The lack of native fidelity has been problematic for Swing, whether you like it or not.
    I am not attempting to define any such perceptions. I am simply questioning whether such perceptions are valid. There are certainly many perceptions that are held by a substantial number of developers that are wildly out of date, such the issue of Swing performance. I am also trying to question the issue of whether native fidelity is actually any sort of problem. It may well be perceived to be by a large number of developers, but is it really, in practise? The fact that there are at least a few well-respected mass-market Swing applications out there shows that Swing can certainly be used for the development of high-quality native apps, with quality user interfaces, and that there is good evidence that users of some of these applications find such interfaces not just acceptable, but pleasant to use (and which are used by 'the public at large'). These applications use versions of Swing which you claim to be problematic for mass acceptance. Well, this is proof that they can't be that problematic. I agree that things will become easier with Mustang, but I have clearly shown that this does not mean that you can't write quality applications for mass use right now. I am not saying that Swing is a great GUI toolkit as it is now, but there is so much wildly exaggerated and out-of-date criticism thrown at it.
    But back on topic... Frankly, the Qt bindings seem a little late to the party considering the license costs, that many of Swing's weaknesses have finally been addressed in Mustang, and that Unix desktop developers have virtually ignored Java as a development technology.
    I fully agree with you here. Mustang is part of a long series of improvements to Swing that make other options seem much less appealing. The move of Java to (hopefully) a flexible open source license will, I believe, make Qt with is licensing far less appealing for Java.
  25. Re: Vector Deformation[ Go to top ]

    I am not attempting to define any such perceptions. I am simply questioning whether such perceptions are valid. There are certainly many perceptions that are held by a substantial number of developers that are wildly out of date, such the issue of Swing performance.
    The validity is in the fact that there is a large number of people that have such perceptions. And it's not just people that are ignorant to the progress of Swing. The people on this thread have followed Swing's development closely and know the reality of it compared to other toolkits.
    The fact that there are at least a few well-respected mass-market Swing applications out there shows that Swing can certainly be used for the development of high-quality native apps, with quality user interfaces, and that there is good evidence that users of some of these applications find such interfaces not just acceptable, but pleasant to use (and which are used by 'the public at large'). These applications use versions of Swing which you claim to be problematic for mass acceptance. Well, this is proof that they can't be that problematic. I agree that things will become easier with Mustang, but I have clearly shown that this does not mean that you can't write quality applications for mass use right now. I am not saying that Swing is a great GUI toolkit as it is now, but there is so much wildly exaggerated and out-of-date criticism thrown at it.
    Given the widespread acceptance of Java as a development technology, you really have to question why there isn't more Swing apps. Sun definitely let Swing hang out to dry 4 or 5 years ago when it became apparent that "the server side" was going to be the bread and butter of Java. Sun has continually blundered regarding Swing. First there was the AWT problem, then they screwed up going around saying Metal was a good thing (which on my B89 or so Mustang build is still the freaking default), then there were performance issues, and now up to Mustang native fidelity issues. It's not that you couldn't write a quality app using pre-Mustang Swing. It's given choices, why do developers choose not to.
  26. Re: Vector Deformation[ Go to top ]

    I am not attempting to define any such perceptions. I am simply questioning whether such perceptions are valid. There are certainly many perceptions that are held by a substantial number of developers that are wildly out of date, such the issue of Swing performance.


    The validity is in the fact that there is a large number of people that have such perceptions. And it's not just people that are ignorant to the progress of Swing. The people on this thread have followed Swing's development closely and know the reality of it compared to other toolkits.
    Indeed. I fit that description - I have been following Swing since it first appeared. I know the reality of Swing and its development. I have my views based on that. Others will have their views.
    Given the widespread acceptance of Java as a development technology, you really have to question why there isn't more Swing apps.
    There are very good reasons why there aren't more Swing apps. Swing had a justifiable reputation for being a poor GUI for practical applications for some time. This was why SWT was developed. Swing has only become acceptable for serious general use in recent versions of Java. Then there is the plain fact that desktop development in general, no matter what the language or GUI toolkit, has become a minority practise because of the increasing use of web applications.
    Sun definitely let Swing hang out to dry 4 or 5 years ago when it became apparent that "the server side" was going to be the bread and butter of Java. Sun has continually blundered regarding Swing. First there was the AWT problem, then they screwed up going around saying Metal was a good thing (which on my B89 or so Mustang build is still the freaking default), then there were performance issues, and now up to Mustang native fidelity issues.

    It's not that you couldn't write a quality app using pre-Mustang Swing. It's given choices, why do developers choose not to.
    Again, you make sweeping generalisations which aren't borne out by fact. Obviously, many developers certainly do choose to do so. Swing use is not non-existent; in fact, some statistics show that it is, at least in some surveys, more used than many alternatives such as WinForms. There are certainly a reasonable number of jobs out there which demand Swing as a skill. Indeed, I have noticed such jobs increasing over the past year, perhaps as the result of the take-up of Java 1.5. Sun have not 'continually' blundered. They made serious mistakes at first; the whole approach of Swing was based on ideas from VisualWorks Smalltalk which worked fine on Smalltalk, but very badly on Java. Performance was terrible, as was the resource requirement. When I first saw Swing demonstrated, I could not believe anyone could take it seriously. It has taken a long time to deal with these issues, and at times, progress has not been as fast as it should have, but in recent versions of Java Swing has unquestionably improved. The Metal look was a major put-off, but could easily been replaced by far more appealing designs like Kunststoff and Alloy (I used the former to great effect). There has never been a need to accept the default L&F. Java 1.5 was a big step forward, with a far better cross-platform L&F and vastly better performance (with hardware acceleration option).
  27. Re: Vector Deformation[ Go to top ]

    There are very good reasons why there aren't more Swing apps. Swing had a justifiable reputation for being a poor GUI for practical applications for some time. This was why SWT was developed. Swing has only become acceptable for serious general use in recent versions of Java.
    Your claim is that recent versions are acceptable. Obviously, many others (including me) strongly disagree with that claim.
    Then there is the plain fact that desktop development in general, no matter what the language or GUI toolkit, has become a minority practise because of the increasing use of web applications.
    The browser is a piss-poor applications platform for anything other than rather unsophisticated needs. There are still lots of fat client development being done. I'm not buying your argument that web apps are the reason that there aren't more Swing apps. Swing has been and continues to be a poor toolkit and that's the reason why.
    Again, you make sweeping generalisations which aren't borne out by fact. Obviously, many developers certainly do choose to do so. Swing use is not non-existent; in fact, some statistics show that it is, at least in some surveys, more used than many alternatives such as WinForms. There are certainly a reasonable number of jobs out there which demand Swing as a skill. Indeed, I have noticed such jobs increasing over the past year, perhaps as the result of the take-up of Java 1.5.
    The context of most Swing apps is a internal corporate setting. That makes sense considering that business would want to leverage Java skills and that they can force the apps on information workers. Once you get out in the wider world, Swing apps are basically non-existant. Sun can't even get open source Unix developers to adopt it. Even those rare desktop developers that do use Java would prefer to use gtk+ bindings that fit in with the desktop. And the reason is that people have choice in these situations and they don't want something that looks like crap.
    Sun have not 'continually' blundered. They made serious mistakes at first; the whole approach of Swing was based on ideas from VisualWorks Smalltalk which worked fine on Smalltalk, but very badly on Java. Performance was terrible, as was the resource requirement. When I first saw Swing demonstrated, I could not believe anyone could take it seriously. It has taken a long time to deal with these issues, and at times, progress has not been as fast as it should have, but in recent versions of Java Swing has unquestionably improved. The Metal look was a major put-off, but could easily been replaced by far more appealing designs like Kunststoff and Alloy (I used the former to great effect). There has never been a need to accept the default L&F. Java 1.5 was a big step forward, with a far better cross-platform L&F and vastly better performance (with hardware acceleration option).
    Sun continually blundered and one of those blunders was not investing in Swing for a few years. It was "good enough" and the server side is where it was at. They got some improvements in Tiger and the performance issues were improved and now with Mustang there's something that can somewhat pass for a native application. The real problem is that very rarely do technologies make a comeback after being stale for so long, so it would be quite a feat for Swing to make a comeback.
  28. Re: Vector Deformation[ Go to top ]

    Your claim is that recent versions are acceptable. Obviously, many others (including me) strongly disagree with that claim.
    Sure, but you seem reluctant to provide evidence to back up such opinions. Repeated statement of disagreement alone is not useful debate.
    Then there is the plain fact that desktop development in general, no matter what the language or GUI toolkit, has become a minority practise because of the increasing use of web applications.
    The browser is a piss-poor applications platform for anything other than rather unsophisticated needs. There are still lots of fat client development being done. I'm not buying your argument that web apps are the reason that there aren't more Swing apps.
    You need to re-read what I wrote. You are responding to things I didn't say. I said that web apps are a reason why there is less fat client development in general than there used to be. I fully accept that Swing in the past has been poor.
    Swing has been and continues to be a poor toolkit and that's the reason why.
    Again, just opinion. For every reason you have put forward to back that, I have so far come up with a counter example.
    Again, you make sweeping generalisations which aren't borne out by fact. Obviously, many developers certainly do choose to do so. Swing use is not non-existent; in fact, some statistics show that it is, at least in some surveys, more used than many alternatives such as WinForms. There are certainly a reasonable number of jobs out there which demand Swing as a skill. Indeed, I have noticed such jobs increasing over the past year, perhaps as the result of the take-up of Java 1.5.


    The context of most Swing apps is a internal corporate setting.
    The context of almost all apps is an internal corporate setting.
    That makes sense considering that business would want to leverage Java skills and that they can force the apps on information workers. Once you get out in the wider world, Swing apps are basically non-existant.
    Why do you keep posting such statements when I have shown you real world examples that prove otherwise? And, to claim that Swing apps are 'forced' on information workers is really reaching...
    Sun can't even get open source Unix developers to adopt it. Even those rare desktop developers that do use Java would prefer to use gtk+ bindings that fit in with the desktop. And the reason is that people have choice in these situations and they don't want something that looks like crap.
    Again, more opinions posted as if they were fact, and they aren't. There is considerable work going in OSS Java to support Swing. Either you are wrong about the demand from OSS Linux developers, or a lot of people are wasting their time... The reason why there hasn't been much use of Swing by OSS Unix developers so far simple - there hasn't been an OSS version of Java that runs Swing completely.
    Sun have not 'continually' blundered. They made serious mistakes at first; the whole approach of Swing was based on ideas from VisualWorks Smalltalk which worked fine on Smalltalk, but very badly on Java. Performance was terrible, as was the resource requirement. When I first saw Swing demonstrated, I could not believe anyone could take it seriously. It has taken a long time to deal with these issues, and at times, progress has not been as fast as it should have, but in recent versions of Java Swing has unquestionably improved. The Metal look was a major put-off, but could easily been replaced by far more appealing designs like Kunststoff and Alloy (I used the former to great effect). There has never been a need to accept the default L&F. Java 1.5 was a big step forward, with a far better cross-platform L&F and vastly better performance (with hardware acceleration option).


    Sun continually blundered and one of those blunders was not investing in Swing for a few years. It was "good enough" and the server side is where it was at. They got some improvements in Tiger and the performance issues were improved and now with Mustang there's something that can somewhat pass for a native application.

    The real problem is that very rarely do technologies make a comeback after being stale for so long, so it would be quite a feat for Swing to make a comeback.
    Again, why do you keep posting ignoring facts in previous posts? Check for yourself - Swing does not need to 'make a comeback' - it never went away. There are a considerable number of Swing developers and jobs out there. For example, I have just looked at the UK 'Computing' magazine jobs section. There are some nice Swing jobs, with high pay. Lots of them. Hundreds. In fact, on that website there is more than 1 Swing job for every 10 J2EE jobs. There is a Swing job for every 2 PHP jobs. To claim that Swing is stale and needs to make a comeback is clearly not backed up by any evidence.
  29. Re: Vector Deformation[ Go to top ]

    Your claim is that recent versions are acceptable. Obviously, many others (including me) strongly disagree with that claim. Sure, but you seem reluctant to provide evidence to back up such opinions. Repeated statement of disagreement alone is not useful debate.
    What evidence do you need? Hell, you have experienced Swing developers in here telling you the reality of the situation but you continue to bury your head in the sand. Are the criticisms of Swing somehow new to you? Are you living in a cave?
    You need to re-read what I wrote. You are responding to things I didn't say. I said that web apps are a reason why there is less fat client development in general than there used to be. I fully accept that Swing in the past has been poor.
    And I and others are saying that the reason you don't see more Swing apps is because it's a poor toolkit and you can't just explain it away because of web apps. By your logic of "users don't care about how Swing performs/behaves/looks - just look at web apps", we should see more Swing apps. We got applets and webstart. It's just another sign of Sun's mismanagement of Java in that Flash is ubiqutous, but Sun could never figure out a decent deployment strategy.
    The context of almost all apps is an internal corporate setting.
    Maybe that argument makes you feel better about the absence of Swing apps, but we know that's there lots of consumer level apps and they aren't using Swing.
    Why do you keep posting such statements when I have shown you real world examples that prove otherwise?
    You haven't shown anything except your typical style of blind devotion, despite evidence to the contrary all around you.
    Again, just opinion. For every reason you have put forward to back that, I have so far come up with a counter example.
    Experienced Swing developers on this thread have shown you otherwise. And the reason that Sun is going to put another API layer on top of Swing is more evidence against your vapid arguments.
    And, to claim that Swing apps are 'forced' on information workers is really reaching...
    Do you think they have a choice in the matter? I don't think so.
    Sun can't even get open source Unix developers to adopt it. Even those rare desktop developers that do use Java would prefer to use gtk+ bindings that fit in with the desktop. And the reason is that people have choice in these situations and they don't want something that looks like crap. Again, more opinions posted as if they were fact, and they aren't. There is considerable work going in OSS Java to support Swing. Either you are wrong about the demand from OSS Linux developers, or a lot of people are wasting their time...
    There's a lot of people wasting their time. Mono has already taken the place of Java on the linux desktop.
    Again, why do you keep posting ignoring facts in previous posts? Check for yourself - Swing does not need to 'make a comeback' - it never went away. There are a considerable number of Swing developers and jobs out there. For example, I have just looked at the UK 'Computing' magazine jobs section. There are some nice Swing jobs, with high pay. Lots of them. Hundreds. In fact, on that website there is more than 1 Swing job for every 10 J2EE jobs. There is a Swing job for every 2 PHP jobs. To claim that Swing is stale and needs to make a comeback is clearly not backed up by any evidence.
    And once again, for in-house apps in order to leverage java skills where information workers have no choice on the crap that they have to use. Outside of that, where developers and users have choice, they are not using Swing crap.
  30. Re: Vector Deformation[ Go to top ]

    Your claim is that recent versions are acceptable. Obviously, many others (including me) strongly disagree with that claim.



    Sure, but you seem reluctant to provide evidence to back up such opinions. Repeated statement of disagreement alone is not useful debate.


    What evidence do you need? Hell, you have experienced Swing developers in here telling you the reality of the situation but you continue to bury your head in the sand. Are the criticisms of Swing somehow new to you? Are you living in a cave?
    Of course they aren't. But the What you are neglecting is that I am an experienced Swing developer as well. Anyone who bases anything on the comments of just a few people on one thread is unwise.
    By your logic of "users don't care about how Swing performs/behaves/looks - just look at web apps", we should see more Swing apps.
    Yet again you are responding to arguments I never made. I never said that users don't care about how Swing performs or behaves or looks. I said the precise opposite - that users require well-designed applications with reasonable performance. My argument is with the ideas like the requirement for close emulation of native GUIs.
    Maybe that argument makes you feel better about the absence of Swing apps, but we know that's there lots of consumer level apps and they aren't using Swing.
    How many times do we need to go over this? There are lots of consumer level apps and they also aren't Delphi, or any of a range of quality GUI development kits, but no-one would deny that Delphi (or other kits) don't produce good apps. There are also consumer apps that ARE Swing, but you seem to keep wanting to ignore this.
    Why do you keep posting such statements when I have shown you real world examples that prove otherwise?


    You haven't shown anything except your typical style of blind devotion, despite evidence to the contrary all around you.
    Please re-read what I write before posting. I made it clear that I have anything but blind devotion. I am on record on various forums as being extremely critical of Swing years ago. I have made similar comments in this thread. The point here is that I am against both blind devotion and blind rejection.
    Again, just opinion. For every reason you have put forward to back that, I have so far come up with a counter example.


    Experienced Swing developers on this thread have shown you otherwise. And the reason that Sun is going to put another API layer on top of Swing is more evidence against your vapid arguments.
    But that is my point - you haven't actually shown anything. Just repeated opinions.
    And, to claim that Swing apps are 'forced' on information workers is really reaching...


    Do you think they have a choice in the matter? I don't think so.
    Yes, I do. Developers get feedback. The idea that they work in isolation from their internal software users is absurd.
    Sun can't even get open source Unix developers to adopt it. Even those rare desktop developers that do use Java would prefer to use gtk+ bindings that fit in with the desktop. And the reason is that people have choice in these situations and they don't want something that looks like crap.



    Again, more opinions posted as if they were fact, and they aren't. There is considerable work going in OSS Java to support Swing. Either you are wrong about the demand from OSS Linux developers, or a lot of people are wasting their time...


    There's a lot of people wasting their time. Mono has already taken the place of Java on the linux desktop.
    I am sure the GNU Classpath people are interested to know that you think that. Mono may have some presence on some Linux desktops, but there are few packages available on my Ubuntu installation. Meanwhile, Java remains, not just with development apps like Eclipse, but with general apps like Azureus. So, yet again, the evidence is against you.
    Again, why do you keep posting ignoring facts in previous posts? Check for yourself - Swing does not need to 'make a comeback' - it never went away. There are a considerable number of Swing developers and jobs out there. For example, I have just looked at the UK 'Computing' magazine jobs section. There are some nice Swing jobs, with high pay. Lots of them. Hundreds. In fact, on that website there is more than 1 Swing job for every 10 J2EE jobs. There is a Swing job for every 2 PHP jobs. To claim that Swing is stale and needs to make a comeback is clearly not backed up by any evidence.


    And once again, for in-house apps in order to leverage java skills where information workers have no choice on the crap that they have to use. Outside of that, where developers and users have choice, they are not using Swing crap.
    I have already shown you generally available Swing applications that are not only chosen by users, but highly praised. Want some more 'real world' examples of developers and users choosing to use Swing? This is one of my favourites, as I have a background in Math (and had to use some awful command-like tools for the purpose): The current front-end of the very popular symbolic manipulation tool Maple is now Swing. The reviews have been great, comparing the interface favourably with Maple's competitors which are - wait for it - native GUI applications! The tool includes interactive 3D graphics and, of course, rich text editing features (which flatly contradicts your point that Swing's font handling is a major issue). In summary, one or two opinions on a forum don't constitute evidence for the state of things, no matter how experienced those posters are, especially when we are dealing with just opinions, especially when those opinions are flatly contradicted by the results of even the briefest research. What matters is facts, and the fact is that current versions of Swing are being used for well-reviewed popular general (non-crap) applications outside of corporations.
  31. Re: Vector Deformation[ Go to top ]

    Of course they aren't. But the What you are neglecting is that I am an experienced Swing developer as well.
    That explains a lot.
    Anyone who bases anything on the comments of just a few people on one thread is unwise.
    If it was just a few people on one thread then Swing's bad reputation wouldn't be so prevalent.
    Yet again you are responding to arguments I never made. I never said that users don't care about how Swing performs or behaves or looks. I said the precise opposite - that users require well-designed applications with reasonable performance. My argument is with the ideas like the requirement for close emulation of native GUIs.
    Close emulation is part of the look and something that people have wanted for years and years, but continue to ignore and insist that it's not an issue even though everybody knows otherwise.
    How many times do we need to go over this? There are lots of consumer level apps and they also aren't Delphi, or any of a range of quality GUI development kits, but no-one would deny that Delphi (or other kits) don't produce good apps.
    They aren't Delphi and they also aren't Swing. Other toolkits never had the problems that Swing continues to have.
    There are also consumer apps that ARE Swing, but you seem to keep wanting to ignore this.
    No, there's not many. Developers that have a choice have much pride in their work and so don't use Swing.
    Please re-read what I write before posting. I made it clear that I have anything but blind devotion. I am on record on various forums as being extremely critical of Swing years ago. I have made similar comments in this thread. The point here is that I am against both blind devotion and blind rejection.
    Your problem is that you're not recognizing the problems that are still in Swing with released version of Java.
    But that is my point - you haven't actually shown anything. Just repeated opinions.
    It is fact that Sun has recognized the problems with the Swing API and so are releasing utility classes to ride on top of it. It is fact that Sun continues to use more and more native APIs because they recognize that Swing looks horrible.
    Yes, I do. Developers get feedback. The idea that they work in isolation from their internal software users is absurd.
    There's nothing you can do unless you change toolkits, and in the typical corporate setting it would be a moot issue for a user to suggest a toolkit change.
    I am sure the GNU Classpath people are interested to know that you think that.
    The GNU people are just brain-dead, idiot followers of Stallman and so believe all that crap about "Don't fall into the Java crap".
    Mono may have some presence on some Linux desktops, but there are few packages available on my Ubuntu installation.
    I don't know about your Ubuntu installation, but there's a lot more desktop development going on with Mono than Java. And now the gtk# bindings have been accepted into Gnome, so we can only expect a lot more. The Java-Gnome bindings are largely ignored and Novell is funding desktop Mono development. Sun blundered around for years not recognizing that Gnome people don't want that Swing crap, but Sun wouldn't do anything with native bindings.
    So, yet again, the evidence is against you.
    You're blind to the reality of the situation. If you would do a little investigation you would see despite RedHat and Sun's antipathy towards Mono, nobody cares about Java desktop development, while Mono has popular support and usage.
    What matters is facts, and the fact is that current versions of Swing are being used for well-reviewed popular general (non-crap) applications outside of corporations.
    No it's not. As a devoted Swing developer you just don't want to recognize the reality of Swing antipathy and how it's a failed toolkit.
  32. Re: Vector Deformation[ Go to top ]

    What matters is facts, and the fact is that current versions of Swing are being used for well-reviewed popular general (non-crap) applications outside of corporations.


    No it's not. As a devoted Swing developer you just don't want to recognize the reality of Swing antipathy and how it's a failed toolkit.
    I enjoy a vigorous debate as much as the next fellow, but unless the debate is going to progress on the basis of arguments and facts put forward, and not on the basis of ad hominem attacks, and repeated challenges to statements I have never made, and re-assertions of the same domga in the face of contrary evidence, it is pretty pointless. For example, no amount of bluntly denying the existence of quality popular Swing apps, particularly when I have given specific examples for all to see, will actually make them disappear! Not my scene, sorry :)
  33. Re: Vector Deformation[ Go to top ]

    Further proof of this is how even Microsoft introduce new types and styles of controls in their Office suite, which can be quite different Do you hear mass complaints about lack of usuability of MS Office because the toolbar buttons look somewhat different in style, or because they have different highlighting on menus?
    Steve Swing's problem is not that it doesn't look native - it's that it doesn't feel native. MS Office may look different than other Windows applications but doesn't feel any different.
  34. Re: Vector Deformation[ Go to top ]

    Further proof of this is how even Microsoft introduce new types and styles of controls in their Office suite, which can be quite different Do you hear mass complaints about lack of usuability of MS Office because the toolbar buttons look somewhat different in style, or because they have different highlighting on menus?

    Steve
    Swing's problem is not that it doesn't look native - it's that it doesn't feel native. MS Office may look different than other Windows applications but doesn't feel any different.
    In what way does it not feel native? Opening up a Java 1.5 Swing application, I find I can use all the expected control characters and accelerators (even though the way most of these are set up is a matter of programming). I can tab between controls. I can copy and paste between Swing apps and others. I can even drag and drop between Swing and other apps. The only ways I can think of that Swing apps have not in the past felt like native apps is because of poor performance, and their poor implementations of things like File dialogues, but that is hardly the case with Java 1.5. If this really were the case, then general-purpose applications written in Swing, like Moneydance for example, would be cricised for such unfamiliarity. They aren't. To stick with Moneydance (not that I have anything to do with it, but it is a useful counter to such arguments), the Washington Post review of it stated: "This program manages to replicate much of Quicken's functionality -- but in some cases a bit more elegantly." Quicken is a native app. Does that sound like a review of a program that has interface issues? Other reviews praise the " graceful, simple interface". This is what Swing is capable of. The idea that it is not ready for desktop use is way, way out of date.
  35. Re: Vector Deformation[ Go to top ]

    In what way does it not feel native? Opening up a Java 1.5 Swing application, I find I can use all the expected control characters and accelerators (even though the way most of these are set up is a matter of programming). I can tab between controls. I can copy and paste between Swing apps and others. I can even drag and drop between Swing and other apps.
    Let's see... the only Swing application I have on my desktop is Netbeans, running on Java 1.5. Okay it's an IDE so it's allowed to take a long time to start up. But what do I see on startup as it loads my project - a grey screen! Ahh, finally, it's up. Let's open a file... File, Open. Hmmm, did I click it right. Yes I did, the File Open dialog shows up. Close the dialog... it leaves a little grey box behind as it leaves. Nice. Okay, let's play with the menus... Hmm, my mouse is over Build but it's still showing the menus of Versioning. I agree that 1.5 is better than before, but if Sun's own flagship Swing application still has these problems, what hope is there for us developers? I use plenty of non-native looking applications like MS Office, Firefox etc., but I never experience anything like this. I have seen plenty of good looking and even native looking Swing applications, but I have yet to see one that feels native. I still use Swing a lot. I would use SWT as well, but I find SWT to be mature enough only for Eclipse like applications. The less like Eclipse is your application, the harder it seems to be to develop with SWT. I'm still waiting for a general purpose Java UI toolkit that looks good and feels native.
  36. Re: Vector Deformation[ Go to top ]

    I checked on my Java 1.5.0_03, Win XP, Turion84 1.6 GHz, 1 GB RAM laptop. I have Netbeans 5.0.
    But what do I see on startup as it loads my project - a grey screen! Ahh, finally, it's up.
    Happens on my machine too, but for Let's open a file... File, Open. Hmmm, did I click it right. Yes I did, the File Open dialog shows up. Close the dialog... it leaves a little grey box behind as it leaves. Nice. Okay, let's play with the menus... Hmm, my mouse is over Build but it's still showing the menus of Versioning. Doesn't happen. I do agree with your earlier post on many-many classes, models, renders, editors, etc. Also, I still have trouble getting layouts right (I too produce those grey-area apps). Out of the box, Swing developers shouldn't have that many problems to produce a good looking app. WRT, another topic on this thread: I too am seeing quite a few Swing apps, esp end-user trading applications (FX/Equity/Derivatives) - either applets or Webstarted. Pretty impressive performance considering the number of ticks they need to display per second - I used to think C++ can't be beaten at that (it probably still can't be, haven't personally benchmarked; but Java/Swing do give acceptable performance). Finally, L&F is an issue, but the biggest problem of Swing in the past has been pathetic performance. This dicussion is being dominated by two points of view. We really should have a poll as tie-breaker, we can't seem to agree with opinions / experiences [and the fact that they can be different for different people].
  37. Re: Vector Deformation[ Go to top ]

    Let's see... the only Swing application I have on my desktop is Netbeans, running on Java 1.5. Okay it's an IDE so it's allowed to take a long time to start up. But what do I see on startup as it loads my project - a grey screen! Ahh, finally, it's up. Let's open a file... File, Open. Hmmm, did I click it right. Yes I did, the File Open dialog shows up. Close the dialog... it leaves a little grey box behind as it leaves. Nice. Okay, let's play with the menus... Hmm, my mouse is over Build but it's still showing the menus of Versioning. I agree that 1.5 is better than before, but if Sun's own flagship Swing application still has these problems, what hope is there for us developers? I use plenty of non-native looking applications like MS Office, Firefox etc., but I never experience anything like this. I have seen plenty of good looking and even native looking Swing applications, but I have yet to see one that feels native.
    Have you heard something about "on demand class loading" of Java? and the Just In Time JVM part? These things don't have anything to do with Swing, they are the small bill of the Java platform: running slow in the beginning performing very fast after. An example: put your mouse over the File menu and click, move quickly to the Help menu and return again and repeat again... it is absolutely fast, no difference with native applications. Jose M. Arranz JNIEasy : Java Native Objects
  38. Re: Vector Deformation[ Go to top ]

    Have you heard something about "on demand class loading" of Java? and the Just In Time JVM part? These things don't have anything to do with Swing, they are the small bill of the Java platform: running slow in the beginning performing very fast after.
    Then why don't I see these problems in Eclipse? And how does that change the fact that Swing applications still don't feel native? Besides, in my experience it gets worse the longer it runs. Unfortunately I don't write toy applications like Aerith, but apps that are used everyday 9-5 by end users. And every grey box, grey screen, and menu not refreshing gives them the impression that our app is slow, even tho' we use SwingWorker. Never mind that before they had access to one screen at a time with at most 10 records and now they can open multiple tabs and get thousands of records at a time. They still consider the app to be slow!
  39. Re: Vector Deformation[ Go to top ]

    Have you heard something about "on demand class loading" of Java? and the Just In Time JVM part? These things don't have anything to do with Swing, they are the small bill of the Java platform: running slow in the beginning performing very fast after.

    Then why don't I see these problems in Eclipse?
    Because Eclipse is more "lightweight" in the Java side, it relies in native OS code/widgets, this code is not Java (more insecure, inflexible, crashes...) and is loaded with the operating system. If the JVM going to run the NetBeans was loaded with the operating system and the Swing classes (and most of the JRE) preloaded, the NetBeans (and any other Java application) would be more responsive in the beginning (and would load faster).
  40. Re: Vector Deformation[ Go to top ]

    I forgot: repeat again the "File Open...", now is fast. Anyway the "File Open..." test is a bad Swing test because is not a "pure Swing" test: Java must access to the filesystem, and you know, the filesystem is a bit slow the first time you get a non-used part before (hard disk accesses, no caching etc). Second test: unload the NetBeans, execute again, it starts quicker and the first "File Open..." is performing fast now... why? the class loading is performing fast now because the jars are already cached on memory by the operating system. I'm sorry, is not about Swing. Perhaps the Swing fault is: a very well designed framework has many classes to load. Jose M. Arranz JNIEasy : Java Native Objects
  41. Re: Vector Deformation[ Go to top ]

    Perhaps the Swing fault is: a very well designed framework has many classes to load
    Apparently your criteria for a well designed framework is different from mine. Swing's architecture is only good in theory - the more you use it the more you realize how flawed it really is in practise. For example, say you want to prevent the user from clicking the little arrow button on the JComboBox. Is the arrow button in the Model, Editor, Renderer? Nope - it's in the Look And Feel!!! So the only way to handle someone clicking on the arrow button is to write my own LookAndFeel class for JComboBox. Right, that's well designed...
  42. Re: Vector Deformation[ Go to top ]

    But what do I see on startup as it loads my project - a grey screen! Ahh, finally, it's up. Let's open a file... File, Open. Hmmm, did I click it right. Yes I did, the File Open dialog shows up. Close the dialog... it leaves a little grey box behind as it leaves. Nice. Okay, let's play with the menus... Hmm, my mouse is over Build but it's still showing the menus of Versioning.
    Sorry, but I don't have those problems. I haven't had those problems with Swing applications for years. They undoubtedly did exist in the past.
  43. Re: Vector Deformation[ Go to top ]

    No offense, but unless you're talking about Mustang builds then yes, Swing apps have looked pretty crappy compared to native toolkits.
    When I wrote my GIS mapping UI, it was using Tiger (actually, the early release Tiger builds, through the CAP program). If you're talking about Aerith, it's important for you to understand that it can also run on Tiger. As Romain Guy said:
    Fortunately, Aerith does not rely on major new features of Mustang but mostly on small additions to the API that made development easier for us. A port to Tiger by the community should not require much work.
    Most people who say that "Swing sucks" haven't gone further than glancing at Metal and complaining. Swing is beautiful, both in design and presentation. If anything, Swing could be faulted for being so simple to use on the surface, that it attracts people who have no business developing user interfaces.
  44. Re: Vector Deformation[ Go to top ]

    Most people who say that "Swing sucks" haven't gone further than glancing at Metal and complaining.
    No, most people that say Swing sucks just had to open their eyes and look at it (even with platform L&F). Fortunately, Mustang finally has a decent Swing, but it's a little late.
  45. Re: Vector Deformation[ Go to top ]

    No, most people that say Swing sucks just had to open their eyes and look at it (even with platform L&F).
    It's obviously impossible for me to debate impunitive logic such as that.
  46. Re: Vector Deformation[ Go to top ]

    No, most people that say Swing sucks just had to open their eyes and look at it (even with platform L&F).

    It's obviously impossible for me to debate impunitive logic such as that.
    It's impossible to debate that Swing's visual aesthetics problems have been part of the reason why desktop Java has been largely irrelevant.
  47. Re: Vector Deformation[ Go to top ]

    Most people who say that "Swing sucks" haven't gone further than glancing at Metal and complaining. Swing is beautiful, both in design and presentation. If anything, Swing could be faulted for being so simple to use on the surface, that it attracts people who have no business developing user interfaces.
    I have years of experience programming in Swing, and I still say Swing sucks. I think that most people who say that Swing doesn't suck have never had to use it everyday for 5 years...
    Simple? You call having to create about 30 classes (including models, renderers, editors,...) to get even a trivial GUI application to not be embarassingly bad - simple? And how is that a beautiful design - it's more like a convoluted design and convoluted is never beautiful. Let's not talk about Swing's presentation because there's enough evidence out there that proves otherwise.
  48. Never expected such a lib from Qt. This can reanimate Java on the desktop!
  49. Re: Now that's a hammer![ Go to top ]

    This can reanimate Java on the desktop!
    Qt Jambi is probably targeted more at the Embedded than the desktop market.
  50. JEE 5.0[ Go to top ]

    It enables Java developers to take the advantage of Qt's features from within Java Standard Edition 5.0 and Java Enterprise Edition 5.0
    Given that someone will find some benefit in using Qt from Java, how exactly might it be used from within Java Enterprise Edition 5.0?
  51. Re: JEE 5.0[ Go to top ]

    It enables Java developers to take the advantage of Qt's features from within Java Standard Edition 5.0 and Java Enterprise Edition 5.0


    Given that someone will find some benefit in using Qt from Java, how exactly might it be used from within Java Enterprise Edition 5.0?
    Probably not at all from within a J2EE/JEE application, since at least I don't remember JEE being about client-side applications and desktop/mobile GUI's..