Submitted by Jambi ships as a single Java library, or JAR (Java Archive) file, plus a handful of tools, including an interface layout and design tool, and an Eclipse plug-in. Trolltech uses its vaunted Qt C++ library as the GUI engine and puts Java wrappers around it. This approach uses the JNI (Java Native Interface) to call the necessary functions from Java. More here.
Trolltech Pours on the Java Dev Goodness
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
This actually looks pretty sweet. I have always thought the SWT native mapping approach was better then the JFC pure java approach. Sure, you have minor inconsistancies, but there are minor inconsistancies anyways between platforms in both bugs and performance optimization. The other problem is SWT itself, as soon as you start moving out of the scope of widgets for eclipse, you quickly find yourself in rather unsupported areas.
This fixes both the problems. It is a native library, so you will get native performance, but it gives a consistent look across platforms. It is also very complete for whatever you would want to use it for.
I second that! I really enjoy QT. It puts the fun back into programming. Especially since I am a Java developer and are so sick and tired of all the Swing issues.
well I’m not sure how this is considered news when jambi has been around for over 6 months and was announced even earlier than that. It’s nice to get another GUI toolkit for Java but I am not sure how many companies would actually consider paying for it. The truth about java is that both of the major GUI libraries are free while this is not at all the case with c++. Also most of the java developers write server applications that usually do not require a GUI. So paying for a GUI library does not fit very well with the general Java atmosphere. That said i believe Qt to be one of the most mature and feature rich libraries atm … but I also hate wrapper classes
Anyways kudos to Trolltech for the effort.
The article was written yesterday. Deal with it.
Yeah it all depends on whether the classes are worth the money. As a C++ developer, Qt is easily worth the money. It is so far above any other C++ toolkit out there that I believe I get my money back in gained productivity very quickly.
In Java you already have classes for network/sql/xml/file/etc access in the standard class library so a lot of Qt is not strictly necessary.
Trolltech seems to realize this and charges significantly less for Jambi than the C++ version of Qt ($1780-$3560 vs $3300-$6600).
This is often missed by people who refer to Qt as “GUI Toolkit”.
Qt is to C++ what the Java Classlibrary is to Java.
So obviously on Java, where it basically is just a “GUI Toolkit”, there is a lot less need for it.
Interestingly, dispite only a small portion of Qt being of additional value for a Java developer, it is still considered for just its GUI portion.
http://www.eclipse.org/swt/
That to me is a some excellent work by the SWT Team.
Everything good and well, not counting the fact that QT Jambi runtime libraries are around ~30MB – so you can forget about using QT Jambi to write small desktop tools.
But apart from that, it’s awesome and I’m sure I’ll use it some day.
True, I guess. However, it being a runtime means that any number of “small apps” can use the same libs and therefore the argument lessens. What needs to happen is bundling ala DotNet. Love it or hate it, it is a classic example of a large runtime that doesn’t seem so large after you begin installing apps to use it.
EDIT:: woohoo!! OSNews doesn’t detect MicroB on the N800 is a mobile browser and so we don’t get stupid ass mobie pages with crippled login functionality!!! Stoked about that. Viva la revolucion!
Edited 2007-12-07 21:29
After downloading Jambi, having a look at the examples and their accompanying source code, I am unconvinced that it will go far.
1) The code looks similar to Swing. By that, I mean that it is almost as verbose. For example, something that takes 10 lines to accomplish in Swing is going to take you roughly the same to accomplish in Jambi. Perhaps my opinion will change if I coded in Jambi professionally, but the examples I’ve seen do not convince me of any worthwhile productivity gain over Swing.
2) GUI Fidelity. I know that many Java developers are whining at Apple right now for not releasing Java 6. But … one thing they have done right with Java as far as I’m concerned is Swing. Swing looks and feels native on OS X. The only giveaway is how components are spaced (i.e. they do not respect the Apple HIG). Jambi and Swing look pretty similar on OS X. They are so similar that they even have the same spacing problem. I don’t know the situation on other operating systems like Windows and Linux, but as far as OS X is concerned there is no reason to dump Swing because Jambi looks similar.
3) Custom components. A common criticism of Swing is how it lacks a wide variety of components. The most cited example, is the date picker. Ok, Jambi comes with a date picker (QCalenderWidget) and an analog dial (QDial). It provides some handy input widgets that take care of formatting of dates, but it’s not like you can’t do that with a few lines of code in a changeListener of a JTextEdit.
A visual guide to Swing Components: http://java.sun.com/docs/books/tutorial/ui/features/components.html
A visual guide to Jambi Widgets: http://doc.trolltech.com/4.3/gallery-macintosh.html
4) Price. Jambi costs a lot of money. From the pricing site:
License Pricing (per developer)
One Platform € 1420
Two Platforms € 2130
Three Platforms € 2840
You’re paying close €2840 for some custom components that Swing doesn’t have, similar visuals on OS X, perhaps slightly better visuals on Linux, can’t comment about the look on Windows. In comparison, Swing is free and if the looks aren’t that hot on Linux/Windows, you can always code in SWT which is free too. I need to point out too that the listed price is per developer. So if you have a team of developers the cost of licenses is going to sky rocket. Sorry for the use of hyperbole, maybe it doesn’t sky rocket since that implies exponential growth, but the cost is still going to grow linearly unless Trolltech implements some unpublished volume license scheme.
There are other miscellaneous things that I shall briefly mention. Qt-Designer is pretty cool, but the Java alternatives are getting there. Matisse is shaping up to be a very good GUI designer. Jambi could perform better since Qt is renown for its speed. But then this has yet to be demonstrated for Jambi.
In conclusion, the price tag coupled with the lack of any large improvement over the existing free Java GUI toolkits will make Jambi a hard sell to existing Java developers. They can get away with such pricing in the C++ world because C++ lacks a viable cross platform GUI development library. It remains to be seen whether the same holds true in Java land.
Of course, someone could point out some super-major-killer-feature of Jambi that I’ve left out that makes it all worthwhile in the end …
Edited 2007-12-07 08:39
Regarding GUI fidelity, Qt looks native both on OSX and windows (linux being of course a different topic since there is no such thing as a default toolkit)
Actually there are plenty of apps that are Qt based (for instance Opera, Skype) that many people don’t even know are Qt apps.
Edited 2007-12-07 10:58
Actually, Opera looks very obviously un-Mac-like and Skype… Skype on OS X looks and behaves perfectly as if it were a native app, even including Core Image transitions! Of course… that is because for Mac OS X they rewrote the GUI code using Cocoa
edit: spelling
Edited 2007-12-07 13:54
Opera is not Qt based. They use Qt for menus only. The actual theme engine is their own.
Yes, menus, but more importantly, printing support. Printing support is hard to do, and they didn’t want to reinvent the wheel. The rest of the UI is built on their custom in-house cross platform toolkit.
Actually, Qt is cheap and cheaper.
It is cheap because it boosts your development process. You are 3 or 4 times more productive using Qt than not using it.
And it is cheaper because those 1480 EUR/platform/developer are to buy, renewal is about 1/3 of that.
Did I say at my company we develop software using Qt and we do have commercial licenses?
Edited 2007-12-07 11:09
But you are using C++, right? The question is whether the productivity boosts that come with Qt-Jambi transfer to Java which already has GUI toolkits that appear to be similar.
I have no doubt that Qt is better than any C++ GUI toolkit (like wxWidgets, MFC or some other obscure toolkit). As I’ve said, just looking at the line count from the examples that come with Qt-Jambi, what jumps out at me is how similar the code looks to Swing.
But you are using C++, right? The question is whether the productivity boosts that come with Qt-Jambi transfer to Java which already has GUI toolkits that appear to be similar.
The reason why Trolltech thinks there will be a market for Jambi, particularly from the GUI point of view because Qt is a lot more than GUI libraries, is because Swing and SWT are crap – quite frankly.
Sun still haven’t sorted out Swing over the last ten years, and the code and development required for it is like swallowing a large breeze block as well as not fitting into the desktop environment right – even with Gnome!
SWT took the direction of reimplementing itself natively on every platform – Win32, GTK and Mac. The problem with this can be seen very clearly when you view the bugs list in Eclipse and SWT that a handful of IBM developers are going red in the face trying to squash. Bugs that don’t appear on Win32 but appear in GTK and Mac, and obscure bugs that mean that cross-platform apps aren’t very cross-platform at all. They also don’t integrate very well with the desktop either.
Certainly from a GUI point of view, Qt is light-years ahead of just about anything, but particularly in the Java world.
To be fair, any cross-platform toolkit is going to have some of these problems. You can’t guarantee 100% that a certain OS at a certain patch level won’t cause bugs in something as complex as a cross platform GUI toolkit.
That said, all my Qt apps are built for clients running Windows, and yet I do all my development on Linux. Then, when I’m ready to do a release, I reboot into windows, recompile (qmake, nmake release), and create the Windows version. So far I haven’t had any bugs on Windows that weren’t already identified on Linux.
> The reason why Trolltech thinks there will be a
> market for Jambi, particularly from the GUI point
> of view because Qt is a lot more than GUI libraries,
> is because Swing and SWT are crap – quite frankly.
Well, Swing is not crap. It does lack some advanced widgets. But, there are third party component libraries (both open source and commercial) that make up for that. And the commercial ones are significantly cheaper than Qt is.
> well as not fitting into the desktop environment
> right – even with Gnome!
You haven’t seen a Java 6 app running on GNOME recently have you? I’d be willing to bet you can’t tell the difference between a well written Swing app on GNOME and a native GTK app on GNOME. The last two updates to Java 6 have made the GNOME support extremely good in Java.
And as I said, the latest version of Java Swing looks and feels more native on Windows than the latest version of Qt does. It also looks and feels more native on GNOME than the latest version of Qt does, even with GNOME’s attempts at skinning a Qt app to look like a GNOME app.
No I haven’t. Probably because I don’t know of any useful Java 6 apps using Swing (doesn’t mean they don’t exist). The only Java apps I’ve used much are Azureus and Eclipse, both based on SWT.
Gnome has made no attempt to skin Qt apps. Trolltech has a Cleanlooks theme for Qt, perhaps that is what you mean.
3 to 4 times as productive eh? Care to substantiate that? At a certain level, object oriented GUI toolkits all work pretty much the same.
“””
Care to substantiate that?
“””
I can’t comment on QT. But I’ve been using PyGTK, and it made my teeth 37% whiter in just 2 weeks! 😉
I don’t know if you use OS X, but as a full time OS X user, swing applicantion can’t lie. They never look nativ and you can always spot a swing application without knowing it is in java. It behave differently, generic windows tools are completly foreign (like the file chooser) and they are slower (when you which between tab to diffent menu.) If you want a swing application to look good on each platform, a lot of work is required.
Anyway, SWT writes on their site that it look native on every plateform. First thing you notice, ugly tabs that make application looks odd.
Productivity:
Gui designer in swing are well done (netbeans), swt are a total disaster. Qt designer is an incredible productity booster and is fun to use.
Their tools are so good, I think trolltech could give Q for free, reach a higher marker share. Then base their business on support and developpement tools. But anyway, they probably already think about it.
“They can get away with such pricing in the C++ world because C++ lacks a viable cross platform GUI development library.”
Not true.
wxWidgets
and
Gtkmm
are both free, cross platform C++ GUI toolkits. Also, Gtkmm is essentially C++ wrapper classes on top of regular Gtk, which also can be used by itself in C++ applications.
So your point that Qt has been successful in the C++ world because a lack of cross platform C++ GUI toolkits holds less weight. IMO, Qt has been successful because of it’s dual licensing (free for open source projects), the fact that KDE uses it, and it’s overall excellence, which makes the propietary price tag easier to swallow (look at Google Earth, Skype, and Adobe Photoshop as great proprietary Qt programs).
Nonetheless, your point is well taken. I kind of doubt that Jambi will gain much traction, simply because Java devs already have Swing (which rapidly improving these days – after years of Sun neglect), and they have SWT (the Eclipse plstform is practically a de-facto standard for tools).
That said, I do think that Qt is a superior library to Swing or SWT. I just don’t think that Qt Jambi will gain much of a user base. But it is nice for Java desktop developers to have another viable choice.
wxWidgets and gtkmm (and other obscure stuff like FLTK) are hardly in the same league as Qt. GTK on OS X and Windows has been the butt of many jokes. Having a C++ wrapper around isn’t going to make it any better.
That leaves wxWidgets which is the most viable contender. I have tried to love wxWidgets. IMHO, it tries too hard to be MFC. Qt’s signal and slots mechanism is better than wxWidgets MFC style message maps. They have introduced signals and slots in recent versions but this feels like the red headed stepchild that nobody likes. Most of the examples and documentation still deal with the message map.
Another thing that is lacking for wxWidgets is a decent GUI designer. Qt-Designer on the other hand is awesome sauce. I used it for Java(thanks to http://uic.sourceforge.net/) and I have mostly praise for it. wxWidgets lacks something like this.
The documentation for Qt, the design and the tools are better than the competition. This is what makes it so successful. The dual licensing scheme just makes things sweeter, allowing you to experiment with it for free while writing open source applications and paying for a license when going commercial. Being free (both libre and gratis) has not helped gtkmm or any of the other obscure C++ libraries. wxWidgets is more popular mainly because it provides a much more viable alternative to Qt than the others.
wxWidgets has good GUI designers like wxFormBuilder or wxDevc++.
> Being free (both libre and gratis) has not helped
> gtkmm or any of the other obscure C++
> libraries. wxWidgets is more popular mainly because
> it provides a much more viable alternative to Qt
> than the others.
I wouldn’t say that gtkmm is obscure, and it provides a very nice alternative to Qt. In fact, gtkmm does a better job of “feeling” C++ like than any others in my opinion.
Also being free has definitely helped Gtk in general. It’s the main reason why all the commercial *nix vendors threw their support behind GNOME instead of KDE. None of them wanted to lock their commercial partners into paying huge licensing fees for Qt.
Yeah, but who cares about “feeling C++ like”? That’s not an advantage, that’s a detriment. I want productivity and intuitive APIs, not a C++ feel. GTKmm is not exactly a contender on any other platform than Linux anyway.
Absolutely, if it wasn’t free, why would you want to use it at all?
A common myth, but there really isn’t much evidence for that. SuSe supports both equally, Redhat does Gnome, Xandros does KDE (millions of installs on the EeePC alone), Linspire does KDE, and Ubuntu does Gnome (although they’re not really commercial). And running KDE doesn’t mean you’re locked into Qt at all. You can write apps with any toolkit/language just fine.
> A common myth, but there really isn’t much evidence
> for that.
There is plenty of evidence. You only mentioned Linux vendors. I wasn’t talking about Linux vendors. I was talking about companies like Sun, IBM, and HP. All of these companies have adopted GNOME and not KDE. And all of them have committed not only financial resources, but developer resources as well to enhancing and improving and contributing to GNOME. None of them care about KDE though. And again, licensing in the reason. The LGPL is much more commercially friendly than the GPL when it comes to development libraries.
> And running KDE doesn’t mean you’re locked into QT
> at all. You can write apps with any toolkit/language
> just fine.
Sure. But they don’t look or feel right, and don’t integrate fully with the DE. And part of creating a commercial GUI application involves polishing it very well when it comes to GUI and desktop integration.
Edited 2007-12-07 18:51
Yes, because the big unixes are not generally used as desktops. The three you mentioned actually still use CDE quite heavily. Basically there is not much need for a desktop, so the choice is not as important. HP also regularly sponsors hardware and conferences for KDE.
Not really. Look at something like Adobe Acrobat Reader on Linux (v8). They ship all the GTK libs themselves, and most of their UI is made of custom widgets. A lot of the high profile apps on Windows have custom UIs to differentiate themselves. Proprietary apps really don’t care much about integration. The file open/save dialog is about the only thing that needs to be consistent, and it is easy to write an app that uses the appropriate dialogs depending on whether it is running on KDE or Gnome. Look at Openoffice for example. They integrate equally well into KDE and Gnome, and they’re not based on GTK or Qt.
> The three you mentioned actually still use CDE
> quite heavily.
All of them have officially replaced CDE with GNOME though. And there are quite a few people running Solaris on workstations.
> Proprietary apps really don’t care much about
> integration.
I don’t agree with that. It might be true on *nix, mostly cause *nix has never really had a solid history of applications following any kind of HIG. But Windows and Mac have. In most cases, Windows users care about native look and feel. And when it comes to Mac users, they are practically militant about their applications looking and feeling exactly like Apple’s HIG says they should.
You’re kidding. Windows apps are terribly inconsistent. Compare MS Office to Nero to Photoshop to MSN Messenger to Internet Explorer to any antivirus app, to any firewall app etc etc etc. Apparently Windows users don’t care about consistency so much, and proprietary apps love differentiating their apps visually from others. I mean, just look at this OSNews story on the newly bundled photoshop apps. The UI is completely foreign, once again:
http://www.osnews.com/story.php/19021/Adobe-Premiere-Elements-4-and…
Mac users are more discerning, but even there there are a few different styles that are only being consolidated now with 10.5.
Edited 2007-12-07 19:47
I don’t agree with that. It might be true on *nix, mostly cause *nix has never really had a solid history of applications following any kind of HIG. But Windows and Mac have. In most cases, Windows users care about native look and feel. And when it comes to Mac users, they are practically militant about their applications looking and feeling exactly like Apple’s HIG says they should.
I disagree.
Adobes apps do not look native on Windows or Mac, they have custom UIs (despite HIGs).
Microsofts Office Mac software is very un mac-like.
Regardless of these facts, the software is still very popular.
> Adobes apps do not look native on Windows or Mac,
> they have custom UIs (despite HIGs)
This is a relatively recent trend though. It used to be that most productivity applications did follow the HIG.
> Microsofts Office Mac software is very un mac-like.
Well, actually, MS Office for Mac did a pretty good job of following the Mac HIG guidelines. Believe it or not, it’s actually Apple that isn’t following their own guidelines. Apple’s HIG, for example, said that the brushed metal look and feel was only supposed to be used on applications intended to emulate physical devices, such as media players. But then Apple quickly started violating their own HIG by using the brushed metal look and feel for everything they wrote.
Recent or not (major apps have been skinned for a LONG time) that is the reality.
‘Pretty good’ is subjective. MS use their own fonts, printing infrastructure, preferences panel, dialog style, etc. It’s not what I would call ‘pretty good’.
The metal look-and-feel thing is a frequently cited
argument to say that Apple don’t support their HIG, unfortunately, there are 100s of other pages in the Apple HIG that suggest otherwise, but yes the metal-thing does offer a cheap target. Unfortunately, since Leopard, this is no-longer even true.
> All of them have officially replaced CDE with GNOME
> though. And there are quite a few people running
> Solaris on workstations.
and quite a few people run KDE on those Solaris workstations, even though it’s not the official desktop. that’s pretty interesting.
Sun recently donated server hardware to the KDE project to help us ensure that KDE continues to work properly (and improve) on Solaris. there is a reason they did that =)
There is plenty of evidence. You only mentioned Linux vendors. I wasn’t talking about Linux vendors. I was talking about companies like Sun, IBM, and HP. All of these companies have adopted GNOME and not KDE.
Have they? Quite frankly, I haven’t noticed, and neither have many other people. HP and IBM have done nothing with Gnome. Zip, zilch, zero. They’re not improving it as a developer’s platform, or the desktop in general at all. There’s no vision and no political will there at all.
As far as Sun is concerned, they sell something call the ‘Java Desktop System’ that uses Gnome. Can I develop a Gnome application in Java where I can create a Gnome control panel applet? No. Can I create a Gnome system tray applet using Java? No. Do Swing applications adopt the right look and feel of the Gnome environment? No. Is Netbeans being geared towards Gnome development so that developers can create first-class Gnome applications in Java that fit into the ‘Java Desktop System’? No.
As for Red Hat and Novell, most of Novell’s Gnome developers have either left, or they’re concentrating on maintenance of their own desktop environment and Mono. Red Hat are concentrating on maintaining GTK as-is, and pie-in-the-sky project as as the online desktop.
At one time, I thought Sun, Red Hat and some people from Novell would have got together to map out a future architecture for Gnome, particularly from a development point of view. Due to inertia, people concentrating on their own projects and politics, that just hasn’t happened and it probably never will. A lot of the past contributors just seem to have disappeared from view.
Gnome has simply got bogged down between competing interests, politics and the extreme inertia of libraries such as GTK that is preventing it from moving forwards. The only interesting stuff being done at the moment within free desktops are being done by individual contributors and the KDE people.
And again, licensing in the reason. The LGPL is much more commercially friendly than the GPL when it comes to development libraries.
It’s funny that this keeps getting brought up, because no company has ever made any statement to that effect.
Sure. But they don’t look or feel right, and don’t integrate fully with the DE. And part of creating a commercial GUI application involves polishing it very well when it comes to GUI and desktop integration.
That’s just an exceptionally poor excuse that seems to get regurgitated every time. You can use different toolkits on Windows and Mac, right? People have no problem integrating GTK with Windows and the Mac, right? What’s stopping GTK, or Java, integration with KDE?
> Can I develop a Gnome application in Java where I
> can create a Gnome control panel applet? No.
Um.. Yes, actually, you can.
> Can I create a Gnome system tray applet using Java?
> No.
Um… Wrong again. Yes you can.
> Do Swing applications adopt the right look and feel
> of the Gnome environment? No.
You are batting a thousand here. Cause you are wrong again.
Both of your first things can be accomplished with something called JDIC, Java Desktop Integration Components, which are a part of SwingX, and are scheduled to be included in the actual Java distribution soon.
As for the third one, Java 6_01 and later pick up the GNOME loon and feel just fine. So well, that you almost certainly wouldn’t be able to tell the difference.
You really should get your facts straight about Java before you post this kind of stuff. It’s clear you haven’t used Java to do any desktop development in at least a couple of years.
Of course, you can also use the Java GNOME bindings. So not only can you do everything you claimed can’t be done in Java. But there is more than one way you can do it in Java.
Edited 2007-12-07 20:52
Um.. Yes, actually, you can.
Oh right. So I can open Netbeans or Eclipse or whatever, create a new project called ‘Gnome Control Panel Applet’ and it will give me a Gnome Control Panel Applet project with the UI designer and all the boiler plate code required?
Um… Wrong again. Yes you can.
Oh right. So I can open Netbeans or Eclipse or whatever, create a new project called ‘Gnome System Tray Applet’ and it will give me a Gnome System Tray Applet project with the UI designer and all the boiler plate code required?
Oh, and I can write all the Gnome Control Panel and System Tray Applet code completely in Java?
As for the third one, Java 6_01 and later pick up the GNOME loon and feel just fine. So well, that you almost certainly wouldn’t be able to tell the difference.
1. It’s taken them ten years to get anywhere near it.
2. They’re not Java Gnome applications, and you’re not using any of the desktop environment at all. They are Java applications with some inherited look and feel, which isn’t hard to do. Creating an application or applet on the ‘Java Desktop System’ goes a whole lot deeper than that.
3. I haven’t seen a Java 6 app yet.
You really should get your facts straight about Java before you post this kind of stuff.
No, you just don’t understand what I’m talking about.
Of course, you can also use the Java GNOME bindings. So not only can you do everything you claimed can’t be done in Java. But there is more than one way you can do it in Java.
So for the first couple of points in this comment, you’re confirming they’re both a no then?
Edited 2007-12-07 21:13
> Oh right. So I can open Netbeans or Eclipse
> or whatever, create a new project called ‘Gnome
> Control…
You are backpeddling and trying to change your requirements now though. You never said “Can I open my IDE and create it having a ready made framework for me”. You flat out said it couldn’t be done. And it CAN be done.
And actually, if you wanted to write a plugin for NetBeans or Eclipse that had support for that project type, you could even do it the way you want. Select “GNOME panel applet” as the project type and then just fill in the blanks.
> 1. It’s taken them ten years to get anywhere near
> it.
So? You are changing your story again. You never said “it took to long to get there” you said “It can’t be done”. And you were wrong. That’s all there is to it. You were wrong.
> They are Java applications with some inherited
> look and feel, which isn’t hard to do. Creating
> an application or applet on the ‘Java Desktop
> System’ goes a whole lot deeper than that.
I know it does. And that is where JDIC comes in. JDIC IS using the native desktop environment. That’s the point of JDIC.
> No, you just don’t understand what I’m talking
> about.
Yes, I do understand what you are talking about. But you haven’t ever heard of JDIC. That much is obvious. Because you are making technical claims about it now that aren’t correct. JDIC DOES use the native desktop environment. That is why you are able to write GNOME panel applets and such using it.
> So for the first couple of points in this
> comment, you’re confirming they’re both a no then?
No. I am saying YES. And I am telling you that you are the one who doesn’t understand. Not me. JDIC != Swing L&F emulation. JDIC is a different animal altogether, that actually does integrate with the native desktop environment to allow to to write things like panel applets in Swing that you could not otherwise write using just straight Swing.
Edited 2007-12-07 21:30
You are backpeddling and trying to change your requirements now though. You never said “Can I open my IDE and create it having a ready made framework for me”. You flat out said it couldn’t be done. And it CAN be done.
That’s exactly what I meant, and in your zeal to get in there and ‘prove me wrong’ you’ve made yourself look like an ejit. Too bad.
I asked if I could create a Gnome Control Panel Applet or a Systray Applet – in Java, meaning pure Java and Java tools, all-in-one. The answer is no.
And actually, if you wanted to write a plugin for NetBeans or Eclipse that had support for that project type, you could even do it the way you want.
Yer. It can’t be done. There’s only so many ways you can say this. If I’m writing a desktop application within a ‘Java Desktop System’ I’m not interesting in writing plugins Sun should be giving me anyway. As a developer I’m disinterested already.
You are changing your story again. You never said “it took to long to get there” you said “It can’t be done”.
Yawn. I haven’t actually seen any Java 6 apps yet, and not ones that use Swing. What’s going to be done for all the legacy applications, and people still developing with Java 2, 1.3, 1.5 etc.? Here’s a taster:
http://forums.java.net/jive/thread.jspa?messageID=227915
As far as I and many developers are concerned, that means ‘can’t be done’. That’s what you don’t understand. You can either do it there and then, or you can’t. You can’t keep saying “Well, upgrade to this version and use this add-on and if you write this plugin……”
But you haven’t ever heard of JDIC. That much is obvious. Because you are making technical claims about it now that aren’t correct.
JDIC is exceptionally poor and limited, and again, it’s not a part of Java as-is, and it’s something I have to go hunting around for as a developer.
In the real world of development, if you can’t do something like Project -> New Project -> Control Panel Applet, it can’t be done. The Java Desktop System, quite frankly, is not any kind of Java Desktop System.
No. I am saying YES.
You just told me I’d have to resort to JDIC and Java Gnome beyond that – and handle that in my deployment and installation.
Desktop integration. Sadly, few seem to get it apart from Microsoft.
> That’s exactly what I meant, and in your zeal to get
> in there and ‘prove me wrong’ you’ve made yourself
> look like an ejit. Too bad.
No. I have not. And all you are doing at this point is digging yourself a deeper hole. Cause you are trying to backpeddle even further.
> I asked if I could create a Gnome Control Panel
> Applet or a Systray Applet – in Java, meaning pure
> Java and Java tools, all-in-one. The answer is no.
No, the answer is still YES. All you have to write is Java code. You don’t have to write any non-Java code.
Now if you want to play this game, I’m going to argue that ultimately you can’t create anything at all in any language higher tham writing machine code directly.
The fact remains, you as a developer, can create a Gnome panel applet writing ONLY Java code. And nothing else.
> Yer. It can’t be done. There’s only so many ways
> you can say this. If I’m writing a
> desktop application within a ‘Java Desktop System’
> I’m not interesting in writing plugins Sun should
> be giving me anyway. As a developer I’m
> disinterested already.
So? I’m disinterested in writing code by hand in C that any good Java IDE will write for me automatically. Find me any C IDE that can even pretend to try to compete with Java in that department. If you want to play the “I have to write less code argument” and you want to pit C against Java? Trust me. You will lose.
> Yawn. I haven’t actually seen any Java 6 apps
> yet, and not ones that use Swing. What’s going to
> be done for all the legacy applications, and
> people still developing with Java 2, 1.3, 1.5 etc.?
Legacy applications will pick up the new theme automatically as long as you are running them under Java 6. It doesn’t matter whether I developed them on Java 5 or Java 4. As long as they are using the system look and feel, they will pick up the native look and feel in Java 6.
That thread you pointed out only proves that again, you know nothing about Java. It’s a non-fatal error. (and it was quite clear about that). However, take that same application, run it on Java 6, and it will work fine. With no recompile or anything required.
Once again, you prove you know almost nothing about Java, or how it’s byte code files work.
> JDIC is exceptionally poor and limited,
Says who? You? Ad-hominem. Logical fallacy. you haven’t even tried it. You didn’t even know what it was. Now you are just making an off the cuff remark you can’t even pretend to back up.
> it’s not a part of Java as-is, and it’s something
>I have to go hunting around for as a developer.
Oh come on… You have to hunt for a hell of alot more stuff to do development in C or C++ than you do in Java. I’m seriously starting to wonder if you have done development in any language at all much less Java.
> In the real world of development, if you can’t
> do something like Project -> New Project ->
> Control Panel Applet, it can’t be done. The
> Java Desktop System, quite frankly, is not any
> kind of Java Desktop System.
You don’t live in the real world. You live in a fantasy world. Development tools for Java are light years ahead of development tools for C or C++. So I guess since you can’t do “Project -> New Project -> New Word Processor”, it’s not possible to write a word processor huh? Can’t be done.
> You just told me I’d have to resort to JDIC.
You’ve already proven you don’t know what JDIC is, how it works, and then proceeded to make logical fallacy attacks against it.
> and handle that in my deployment and installation.
Oh wow… You have to bundle ONE .so file with your application… Whatever will you do?
Edited 2007-12-07 22:47
No, the answer is still YES. All you have to write is Java code. You don’t have to write any non-Java code.
1. Download JDK (I shouldn’t have to if we have a Java Desktop System).
2. Open Netbeans. Find a project where I can create a control panel applet, a systray applet, a system service, a desktop shared component or a desktop GUI embeddable component.
Nothing……..
I can just about write a systray applet if I really wanted, and you’re desperately trying to make this the point (oh, oh, oh, you can use JDIC!), but the desktop development integration is non-existant. Period. The desktop integration isn’t ‘more than good enough’. Sun and others in the Java world have literally had to be press-ganged into doing anything at all.
Repeat this until you get it:
“In the real world of development, if you can’t do something like Project -> New Project -> Control Panel Applet, it can’t be done. The Java Desktop System, quite frankly, is not any kind of Java Desktop System.”
This is what developers do. If you want to piss about for several hours, days or weeks, be my guest. Everyone else will find easier ways to do things, and laugh at your shitty UIs.
Legacy applications will pick up the new theme automatically as long as you are running them under Java 6.
Many people are not going to be running Java 6. For those where native look and feel was important, they left Java behind, oh I don’t know, about eight or nine years ago.
Says who? You? Ad-hominem. Logical fallacy. you haven’t even tried it. You didn’t even know what it was. Now you are just making an off the cuff remark you can’t even pretend to back up.
Sweetheart, do you know what JDIC does yourself?! You can get native access to the filesystem, do some stuff with screensavers, get system info, create some systray stuff and set wallpapers! That’s it.
Any bunch of Windows developers is going to laugh you out of the office. Seriously. You’re acting as if people should simply be using Java for this stuff……and they aren’t, for very good reasons.
Oh come on… You have to hunt for a hell of alot more stuff to do development in C or C++ than you do in Java.
Sun has something called a Java Desktop System, as well as a JDK. Desktop integration isn’t something you ‘hunt around for’. It’s a pre-requisite.
So I guess since you can’t do “Project -> New Project -> New Word Processor”, it’s not possible to write a word processor huh?
People don’t write word processors any more. Not exactly a developer, are you? However, an embeddable Open Office component and ODF output would be nice – but that isn’t going to happen because people are clueless about this. Eventually, in another ten or fifteen years some people might create an incubator Java project because they see that this might be important. Just as it took ten years to get any Java desktop integration of any description.
You’ve already proven you don’t know what JDIC is, how it works, and then proceeded to make logical fallacy attacks against it.
Telling me I don’t know what I’m talking about etcetera, etcetera, isn’t going to make any of this stuff untrue or make it go away. What can I say? You’re not a developer.
– You threw your credibility out of the nearest ten storey window when you proceeded to tell us all that Swing was the most popular desktop toolkit in the world. You can produce any non-existant report or set of figures you like, but nothing will make that true.
– You don’t understand that ISVs buy development tools – yes, even the micro ones. That whole argument seemed to peter out.
So forgive me when I say – bite me.
Oh wow… You have to bundle ONE .so file with your application… Whatever will you do?
Do what everyone else does, and did many years ago – use something else that makes deployment easier and we’re you’re not using unstable components. C’est la vie.
Edited 2007-12-08 02:37
Uhm … what exactly are you complaining about? Having to bundle an additional .so or .dll is a trivial task. I’d like to know what this amazing “something else” is? For any non-trivial task, you will be deploying more than one file.
To solve this problem, we came up with installers many years ago. Unless you’re referring to static linking?
Basically yes, because system tray does not have applets, but rather embeds windows created by another application using Xembed.
Thus a “system tray applet” is any application which has a system tray window component and Java can do those.
Basically yes, because system tray does not have applets, but rather embeds windows created by another application using Xembed…..Thus a “system tray applet” is any application which has a system tray window component and Java can do those.
Sigh….. I’m on to a losing battle trying to explain this one.
> Sigh….. I’m on to a losing battle trying to
> explain this one.
The only reason you are losing is because you have proven you don’t know what you are talking about. I can’t really say that any other way. But you’d rather just keep trying to dig yourself a deeper hole, and resort to off the cuff statements about things you know nothing about, then just admit you don’t know what you are talking about.
The only reason you are losing is because you have proven you don’t know what you are talking about.
It’s called development libraries and APIs that people can pick up and use today – not sometime in the next few days, weeks or years, or if I write my own plugin to create my own projects. If you don’t understand that then you fail miserably as a developer.
The parent was a naive and daft comment I have encountered many times that has no bearing on the real world at all:
Basically yes, because system tray does not have applets, but rather embeds windows created by another application using Xembed…..Thus a “system tray applet” is any application which has a system tray window component and Java can do those.
Errr, no self-respecting developer is going to do that when they have better ways of doing this, and better platforms to do it on. C’est la vie.
Care to explain why clarifying that system tray embedding is just a matter of using the respective system tray object is either naive or daft?
Better ways of doing it than using a standard API?
In case of Java java.awt.SystemTray, in case of Qt QSystemTrayIcon?
That’s because you are not a C++ programer, you are hardly a Visual Basic 6 programmer.
So that explains the thriving market for commercial gtk-based applications, I guess.
RH, Novell and Sun each had strategic business reasons behind selecting gtk, it has nothing to do with license pricing. Particularly considering that these are businesses that rely on providing high-value in order to generate support revenue from customers for a product they could otherwise get for gratis, it’s a little bit galling to suggest that they believe Qt isn’t viable under what is basically the same model.
At the end of the day, businesses have no issue paying for tools if they can be shown to make them more efficient. Price is only a single factor in the value equation, and if the cases of commercial organizations, it is often one of the least important ones.
If Qt with support from Trolltech can make a developer more efficient and cut down code development time, the company will see near immediate ROI. The equation can change dramatically in Qt’s favor when considering the cross-platform development capabilities, as well. That’s how they’ll make their decisions.
I will admit, though, that Gtk has an important role to play as a viable alternative to Qt, if only to offer choice.
Thats make perfect sense, as long as you’re in the field of building cross platform application.
But if you’re a OS/desktop maker, you want to give your customer a way to build application without any restriction to your target user/developper – Open or commercial. If you use QT, you’re somehow telling your customer: “well you paid for our product, but if you want to build closed source app, you must also pay XXXX$ to company Y”. Even if it has many advantage (ROI), it will be unwelcome by customer.
The way Trolltech business is, make them perpetual second alternative.
You’re probably right. I suppose that Trolltech thought about this and figured they would rather be the second alternative and sell their product to be quite profitable, than be the standard (which they could be if Qt was BSD licensed or some such) and make less money (and thus have less money to put into development of the toolkit).
If you use QT, you’re somehow telling your customer: “well you paid for our product, but if you want to build closed source app, you must also pay XXXX$ to company Y”. Even if it has many advantage (ROI), it will be unwelcome by customer.
On the contrary, that is exactly what development companies want to hear. They want to see quality development tools and libraries so that they can make money. ‘Free’ development tools come an extremely distant second if no one wants to use them.
Let’s put it this way: You either give them what they want to see or they will keep passing your platform by. If you have to sell licenses to fund and move your development platform, tools and desktop along, then so be it. The status quo of “You can develop everything for free!” cuts no ice in the real world.
This is true, but the other offerings limit the customer in doing multiple platforms with a single codebase.
It will depend on the product if doing a multi codebase development, probably with a different developer team for each platform will be more or less expensive than using a development framework that lets you do multiplatform with a single codebase and a single development team.
Unfortunately quite a lot of companies still do software development the 20th century way: separately for each platform.
> So that explains the thriving market for
> commercial gtk-based applications, I guess.
There isn’t exactly a commercially thriving horizontal market for *nix applications in general. Almost all *nix software that isn’t open source, is vertical market. And GTK does quite well there. (At least in the sectors of the vertical market that haven’t been completely taken over by Java and .NET)
> At the end of the day, businesses have no issue
> paying for tools if they can be shown to make them
> more efficient.
Sure. As long as the prices for those tools are reasonable. For many ISVs, QT’s prices are outrageously high.
And your evidence for this is? I have no evidence either, aside from my own personal experience developing vertical market apps using Qt.
And you’re basing this on what exactly? As an independent developer doing custom software development for niche markets, Qt is well worth the money. First of all, if you’re bringing in less than 200k a year, you qualify for the small business discount, so my Qt license cost me just over 1100.. That’s peanuts, even for me (and my software development is just a part time thing). Without Qt, I wouldn’t even have a business, because my limited time would not allow me to write the apps that I do without excellent toolkit support. I’ve looked at a lot of toolkits, and none of them come close to the developer efficiency that I get with Qt.
So I can only speak for myself, but for me, Qt is allowing me to code reasonably complex applications in my spare time, without having to worry about crazy bugs in the underlying libraries. I’ve tried that with other toolkits, and it just doesn’t work. GTKmm is not a serious option on Windows, and the last time I tried wxWidgets I found a bug in the libraries in the first day, not to mention the MFC style message maps that are really not pleasant to work with.
> And your evidence for this is?
Large companies where I am familiar with their tools.
> As an independent developer doing custom
> software development for niche markets, Qt is
> well worth the money.
Well, I’m in the same situation you are. I do software development for niche markets. And I don’t consider Qt to be worth the money.
> Qt license cost me just over 1100..
Per developer. And for a single platform license though right? The cross platform (*nix / Windows / Mac) license is normally $6,600. And I am sure Trolltech didn’t give you an 84% small business discount.
I have to develop for all three major platforms cause my software runs in mixed environments. And even with a small business discount, it would most likely still be over $4,000 per developer. That is not affordable. Not when there are very good tools out there that don’t cost anything.
Btw, license renewals and upgrades even for small businesses do not get a discount. So you only get to use that discount once. After that, you pay full price. So still not an acceptable option.
Edited 2007-12-07 19:17
Correct. At the moment my contracts have been Windows only.
65% actually.
$2310 actually.
Well I don’t know your financials, but if that is not affordable, your business must not be doing very well.
Such as? If you’re doing Java development, then sure, you can use Swing (for custom apps it doesn’t really matter that it’s ugly as sin and doesn’t integrate so well), but for C++ I haven’t found anything else. GTKmm is not stable cross platform (and is just a GUI lib), and wxWidgets is ok but ugly to program with and doesn’t have things like the advanced canvas library in Qt. And documentation on those projects is spotty as best.
By all means, if there was a free alternative out there for fast C++ development, I would go for it, but in my experience, there just isn’t.
> $2310 actually.
Plus over $2,000 every 12 months to renew if I want to be able to legally use the upgrades for commercial development. If it were a one time thing, sure. But $2,000 for 12 months of update maintenance? Per developer? Nope. Not gonna happen.
> Such as? If you’re doing Java development, then
> sure, you can use Swing (for custom apps it
> doesn’t really matter that it’s ugly as sin and
> doesn’t integrate so well)
Actually, Swing in the latest version of Java does a better job of looking and feeling native on Vista than the current version of Qt does. If you think it is ugly, you must be using the default ocean look and feel, instead of setting it to adopt the platform native look and feel.
Typically, I am using either Java or Python. I jumped off the C++ bandwagon quite a few years ago. And, yes, if you limit yourself to C++, wxWidgets is quite ugly. But it’s actually quite nice to work with in Python.
I’ve also been flirting with .NET a bit for Windows only development. They have some very impressive GUI development tools. But C++ is not an option I would ever want to go back to.
This all comes down to value proposition. For me, that is easily worth it (especially since I don’t need all three platforms). You are comparing Qt to some magical free alternative that you believe has equal features, whereas I’m comparing it based on it saving me a lot of development time. I am happy to pay for tools that save me time and thus save me more money than the cost of the tool.
Examples please? I haven’t had any trouble with Qt integration into Vista. See here for examples of widgets: http://doc.trolltech.com/4.3/gallery-windowsvista.html
Even with the platform integration LaF, I find Java apps are really ugly (haven’t tried it on Vista though so that might no longer apply there).
So why are you arguing based on the pricing of the C++ version of Qt?
I would never consider C++ without Qt. Java is a nice option with excellent IDEs, but once you get outside the Java world and have to interact with the underlying system, things get ugly fast. Performance and memory consumption is not fantastic either, but that’s getting better with time. I’ve played with C# and .NET, but that really limits you to Windows. At least with Java or C++ you have the option of supporting Mac/Linux (and no, mono does not count as an option). Haven’t used a scripting language like python yet, mostly because of problems with deployment and I don’t consider a weakly typed language suitable for complex app development.
> You are comparing Qt to some magical free
> alternative that you believe has equal features
Well, if you are going to limit yourself to C++. Then yes, there might not be anything out there with equal features.
> See here for examples of widgets:
> http://doc.trolltech.com/4.3/gallery-windowsvista.html
Those look ok. So maybe I just haven’t used an app built with the latest version of Qt on Windows. The current crop of Qt apps on Windows, for the most part, looks pretty awful. Apparently many of them haven’t been updated for Vista support.
> So why are you arguing based on the pricing of
> the C++ version of Qt?
Because it was the version in question. Qt Jambi is still pretty expensive. Considering what it is competing with.
> Java is a nice option with excellent IDEs, but
> once you get outside the Java world and have
> to interact with the underlying system, things
> get ugly fast.
Well, it depends on what you mean. if you mean for desktop integration? (things like system tray icons, popup messages, and such), than interacting with the native Windowing environment in Java is pretty easy using JDIC. If you mean calling underlying system APIs? Well, it’s possible in Java. But discouraged. Because once you start calling underlying system APIs, your cross platform capability becomes pretty much non-existent.
> Performance and memory consumption is not
> fantastic either.
Performance is on a par with C++ these days, and in some cases even exceeds C++. Java can do what are called speculative optimizations at runtime based on how an application is actually being used that are impossible for a static compiler to perform.
As far as memory consumption, most Java apps I write don’t consume any more memory than a complex C++ app would. And it’s not a big issue today anyway with RAM as cheap as it is.
> Haven’t used a scripting language like python
> yet, mostly because of problems with deployment and
> I don’t consider a weakly typed language suitable
> for complex app development.
The deployment problems can be solved with tools like freeze, and py2exe. As far as weakly typed, I agree with you on that point. I don’t use Python for complex applications because of the weak typing. I usually use Java then. But for smaller jobs, I will often use Python, and then just use py2exe on the app and package it up with a native installer. The end user never even knows the difference, or even that it is written in Python.
Yeah that’s pretty much what I mean (also more complex things like sending messages to other windows or launching default apps for certain filetypes). It seems things have been getting a lot better lately with Java 6. However it still seems like it’s an addon, rather than built-in functionality. Perhaps this perception is based on my lack of knowledge about updated versions of Java, but have a look at the screenshots on the JDIC page (under demos). https://jdic.dev.java.net/ They are all terribly ugly with no anti-aliased fonts, bad widget spacing and margin problems. I’m sure all of these things can be fixed, but it seems like it all requires work to make it look half decent, instead of just being good out of the box.
Yes, sometimes one has no choice
It’s just more complicated than it would be in C++.
I know the theory. But the reality is that complex Java applications tend to use a lot of RAM and act a big sluggishly. This is becoming less and less of a problem as time goes on, resources become cheaper, and Java gets faster (1.6 has made great strides here).
Overall though I’m not against Java. It is definitely a fine language and right now my second choice, and may eventually even become my first choice (especially now that it is starting to get open source goodness).
I’ll have to look into those. If they don’t impact the exe size too badly it would be great to try them out.
> a lot better lately with Java 6. However it still
> seems like it’s an addon, rather than
> built-in functionality.
It is an addon right now. It’s scheduled to become part of the the Java core at some future date. But right now, it’s a SwingLabs project. SwingLabs is always a good thing to watch. It’s sort of an open source community driven playground for new desktop development features that have a chance of becoming part of the Java core once they mature enough. There’s a lot of nice components and such you can get from from SwingLabs, things like tree tables, find/search components, etc.
As far as Java applications feeling sluggish, more often than not, that can be blamed on the programmer of the application not understanding the Swing threading model, or other things (not understanding that Strings are immutable for example, so they use a String instead of a StringBuffer (which is mutable) in a loop, and then end up creating and destroying thousands of objects for example).
> I’ll have to look into those. If they don’t
> impact the exe size too badly it would be great
> to try them out.
Well, they do impact the exe size significantly, because they bundle the interpretor within the exe. But then again, if you are currently statically linking Qt, your exe files are probably huge anyway.
Another thing to be aware of, is that py2exe doesn’t actually produce native code. It just bundles the Python source inside an exe with an interpretor that runs in. In other words, if keeping your source is a secret, it’s a problem. Cause anyone who knows how to take an exe apart can get at the original python source.
Yeah that’s more or less unavoidable. My install files tend to be on the order of 3 to 4mb for Qt apps on Windows.
Yeah that’s not a problem for me. For vertical markets that kind of stuff is usually less important (I’ve even done contracts with the open source version of Qt. Commercial does not necessarily mean closed source). Same with anti-piracy measures. It’s not worth my time to put a lot of effort into that.
Sure. As long as the prices for those tools are reasonable. For many ISVs, QT’s prices are outrageously high.
ISVs spend huge amounts of money on tools and software to support their business, which is creating software that they can sell. Tools are exceptionally important to ISVs, and you can see that from the size of the market. Yes we have Subversion, CVS and Git which are free, but even the source control software tools market runs into hundreds of millions, if not more.
If you believe the above then you know nothing about ISVs, and I say that in the politest manner possible.
> If you believe the above then you know nothing
> about ISVs, and I say that in the politest
> manner possible.
On the contrary, I know quite a bit about ISVs. And those source control tools are being sold to enterprises. NOT to small independent ISVs.
It’s quite clear though you know nothing about Java and Swing. Since all three of the points you said it cannot do in your previous post, it can in fact do. And it can do it relatively easily. And on a cross platform basis.
On the contrary, I know quite a bit about ISVs. And those source control tools are being sold to enterprises. NOT to small independent ISVs.
No you don’t. ISVs of any size spend an awful lot on development tools and software. They still spend money on MSDN licenses if they do Windows development, and they even buy source code management software. Why do they do this? Because they develop software for a living. The market is heaving with the stuff, and companies of all types buy this.
If you’re hinting at shareware developers then go away. Seriously. You don’t know what you’re talking about, and I say that as politely as I can. This refrain has been echoing around the open source world forever, and it’s what is holding free desktops back from attracting ISVs in any way – because they don’t understand customers. Read Eric Sink’s book ‘The Business of Software’ if you’re at all confused about any of this. It’s worth the money in itself:
http://www.amazon.com/Eric-Business-Software-Experts-Voice/dp/15905…
Eric coined the term micro-ISV, so he knows what he’s talking about. He runs SourceGear, which sells source code management tools to businesses of all sizes.
Read pages 172 – 173, about why someone would buy this stuff as opposed to using something like CVS for free (he was asked this question at Gnomedex). Many will, but for a lot, it just doesn’t fit their needs. As Eric would say, if you’re bewildered at this then ‘you might want to find a scroll of identify and see what gloves you’re wearing’ ;-).
It’s quite clear though you know nothing about Java and Swing. Since all three of the points you said it cannot do in your previous post, it can in fact do.
It amounts to just about reusing your GTK theme, fonts and icons, and approximating the feel. That’s it. Sadly, that isn’t good enough for developing desktop applications.
I laugh at people jumping up and down and telling me that I’m wrong because the Java 6 LAF has finally got around to inheriting the native theme, icons and fonts – after ten+ years! Believe me, that is the minimum that’s required from something that purports to allow you to develop desktop applications.
Dude. Chill the hell out. Qt rocks but there are other completely legitimate technologies you can use to develop software. Those others might not be as good for you (and they aren’t for me either), but for some people (like mikeurbandz here) they seem to work just fine. Stick to rational arguments instead of these thinly veiled insults.
Qt rocks but there are other completely legitimate technologies you can use to develop software.
Yes…….. And?
Those others might not be as good for you (and they aren’t for me either), but for some people (like mikeurbandz here) they seem to work just fine. Stick to rational arguments instead of these thinly veiled insults.
It might very well work for many people, and that’s great, but trying to claim that Java has the sort of reasonable desktop integration that makes developing desktop applications widely legitimate is well, well wide of the mark. It really is. It’s what has turned many people off developing client applications in Java.
I would have thought people would have heard this debate going on for the past ten years or so. Oh well………
> No you don’t. ISVs of any size spend an awful lot
> on development tools and software.
Not nearly as much as they used to. Because today there are more options. Part of the reason so many small shops have been able to open up these days is cause of all the free software out there that helps them get started for very minimal cost.
> If you’re hinting at shareware developers then go
> away. Seriously. You don’t know what you’re
> talking about.
I’m not hinting at shareware developers. That’s not the kind of developer I am talking about.
And yes, I am familiar with SourceGear.
> It amounts to just about reusing your GTK
> theme, fonts and icons, and approximating the
> feel. That’s it. Sadly, that isn’t good enough
> for developing desktop applications.
And once again, you are plain wrong. It doesn’t amount to that at all. Swing actually uses native peers for rendering these days. So it is doing more than just approximating the feel.
And you still haven’t even looked at JDIC have you? Are you just ignoring JDIC now because you don’t want to admit you were wrong? How many ways do I have to spell it out for you? JDIC does NOT simply use the GTK theme. It actually communicates to the underlying desktop environment. And this is why you can do things like write panel applets with it and such that you otherwise could not write using just plain Swing.
> That’s it. Sadly, that isn’t good enough
> for developing desktop applications.
Well, tell that to the vertical market application developers that have made Swing surpass even Microsoft’s latest offerings as the most popular desktop application toolkit. Yes, it really is. You don’t see that cause most of the desktop apps that are Java based are internal applications. But that’s also what the majority of desktop applications are.
It’s what powers many banking applications that tellers use. It’s what powers the ticketing system at many airlines, etc.
> I laugh at people jumping up and down and telling
> me that I’m wrong.
Well, stop laughing then. Cause as I said, by shear number of desktop applications written, Swing is the most popular toolkit in the world. And the main reason I told you that you are wrong is cause you obviously don’t understand Swing or Java. Since how you are claiming it does things, is not even remotely how it actually does do things these days. 5 years ago? Yes. Today? No. It’s very different today.
I’m actually the one who should be laughing here. Cause you are proving you are one of those “Java sucks, even though I really don’t know anything about it, I’m just repeating tired old arguments that I heard 5 years ago, or basing it on a bad experience I once had with Java” type of people.
Edited 2007-12-07 22:16
And once again, you are plain wrong. It doesn’t amount to that at all. Swing actually uses native peers for rendering these days. So it is doing more than just approximating the feel.
So does SWT, that people have felt compelled to use in favour of Swing’s inadequacy over the years. So what? SWT is by no means perfect either.
And you still haven’t even looked at JDIC have you? Are you just ignoring JDIC now because you don’t want to admit you were wrong?
JDIC is not a part of Java, is by no means anywhere near complete, you have to deal with deployment and installation and is so woefully inadequate I have to stop myself laughing. It’s absolutely fantastic that this is an improvement for Java developers, but let’s not kid ourselves on the wider desktop development front. A Windows developer will laugh at you.
…Swing surpass even Microsoft’s latest offerings as the most popular desktop application toolkit. Yes, it really is. You don’t see that cause most of the desktop apps that are Java based are internal applications. But that’s also what the majority of desktop applications are.
This is just exceptionally wishful thinking. Most Swing applications are the best part of ten years old, when everyone though Java was the greatest thing since sliced bread. Sadly, the reality then hit home, everyone realised they were deploying applications on Windows anyway and they went back to COM and VB Windows programming – or more likely, they started doing web applications. The vast majority of Java development these days takes place on the server in the form of J2EE, JSP and Beans.
Cause as I said, by shear number of desktop applications written, Swing is the most popular toolkit in the world.
Come on. You and I both know that this is akin to saying “The reason why we haven’t seen any weapons of mass destructions is because they’re so cunningly well hidden”. You don’t have to produce any evidence at all ;-).
Cause you are proving you are one of those “Java sucks, even though I really don’t know anything about it, I’m just repeating tired old arguments that I heard 5 years ago, or basing it on a bad experience I once had with Java” type of people.
It’s funny. People were saying exactly this sort of thing to me five years ago as well ;-).
> So does SWT, that people have felt compelled to use
> in favour of Swing’s inadequacy over the years.
SWT actually uses native widgets. It doesn’t just use native peers for rendering. And compared to Swing, SWT has a very small marketshare.
> So what? SWT is by no means perfect either.
SWT’s main problem is that without addons, it is a very primitive toolkit. Their table widget is very weak and such.
> you have to deal with deployment and installation a
> and is so woefully inadequate I have to stop
> myself laughing.
As I said… how hard is it to bundle ONE .so file with your application? If you consider that a deployment / installation problem, then again, I have to ask what world you live in? That is literally all you have to do. Bundle the .so file with your application.
> Most Swing applications are the best part of
> ten years old
Wrong again. As I said, Swing experienced a 27% increase in usage between 2004 and 2005. That would seem to suggest most Swing apps are on the order of only about two to three years old. And there is a lot of new development happening in Swing as well.
Call it wishful thinking if you want. But I’m gonna take Evans Data’s word over your word any day. By the way, I cited my claim. With a well respected company that specializes in reporting IT trends. Can you cite yours? All you have done is make off the cuff remarks. You haven’t cited any of your claims with any reliable source.
> Come on. You and I both know that this is akin
> to saying “The reason why we haven’t seen any
> eapons of mass destructions is because they’re
> so cunningly well hidden”. You don’t have to
> produce any evidence at all ;-).
I did produce evidence. A compiled survey by Evans Data Corporation (which as I said, is a very well respected reporter of IT trends that does scientifically conducted surveys). I haven’t seen you produce any evidence for even a single one of your claims yet though.
> It’s funny. People were saying exactly this sort
> of thing to me five years ago as well ;-).
It seems you haven’t learned anything in the last 5 years then.
Java has made enormous improvements in the last five years, and it is MORE Than competitive on the desktop today.
Oh. And since I know you will want a citation for that claim that Swing is now the dominant GUI toolkit, here it is.
a 2005 Evans Data Corporation report found that 47% of companies doing desktop application development were using Swing. That was an increase of just 27% from a year ago, and a surge in popularity that caused it to pass even Microsoft’s latest offerings for GUI toolkit design.
In fact, gtkmm does a better job of “feeling” C++ like than any others in my opinion.
I don’t think that qualifies as an ‘advantage’.
I agree with everything you say. Qt is head and shoulders, as an overall GUI (and other) library, and tool set, above wxWidgets, Gtk/Gtkmm, or MFC, or anything else out there.
I think Qt is superior to Swing or SWT, as well. It looks better, it blends with the native environment better, it’s faster (much faster in many cases), it’s tools are better (although Swing’s Matisse is pretty close to Qt Designer, I must say), and it’s overall easier to develop with than either Swing or SWT.
Whether that’s enough to get existing Java devs to use it in future desktop applications remains to be seen. Certainly, existing Qt/C++ programmers that want to use Java instead of C++ will want to use it.
Qt-Designer on the other hand is awesome sauce. I used it for Java(thanks to http://uic.sourceforge.net/) and I have mostly praise for it. wxWidgets lacks something like this.
Wow, I had no idea that a version of Qt Designer for Swing existed! Amazing!!
Of course, someone could point out some super-major-killer-feature of Jambi that I’ve left out that makes it all worthwhile in the end …
Well, Designer is pretty freaking sweet. That one’s pretty huge. It’s also pretty awesome that you will (in the future) be able to make Java applications that blend in with KDE themes. So that may make it popular in the open-source world, at least.
I’m not proud of this app. I made it when I was learning SWT and have since (for kicks and grins) ported it to Swint, KDEJava (dead) and QtJambi. Following are shots of each in Linux and OSX (no KDEJava in OSX though). Just posted for informational purposes so one can compare. Perhaps Windows shots later.
Linux
Qt: http://img152.imageshack.us/my.php?image=jukeboxlinuxqtux8.png
KDEJava: http://img155.imageshack.us/my.php?image=jukeboxlinuxkdegl4.png
SWT: http://img220.imageshack.us/my.php?image=jukeboxlinuxswtzv3.png
Swing: http://img513.imageshack.us/my.php?image=jukeboxlinuxswingmr1.png
OSX
Qt: http://img443.imageshack.us/my.php?image=jukeboxosxqtpz5.tiff
Swing: http://img139.imageshack.us/my.php?image=jukeboxosxswingmi0.tiff
SWT: http://img413.imageshack.us/my.php?image=jukeboxosxswtuy0.tiff
Just FYI: the Linux SWT shot is not as nice as it could be since I am using the Qt/GTK theme which uses Qt to draw GTK apps (but isn’t perfect). For Linux Swing there is the KDELAF I could have used but it seems abandoned and isn’t really done.
Here’s a slightly more recent project (a mini Konqueror of sorts, since I hate Finder). Unlike the last app, I didn’t code the tree and list views myself, but used Qt’s ListDirModel. Less work and more functional. These are posted just to show what jambi looks like on Linux and OSX. Again, not something I ever plan on releasing, but here’s what the toolkit looks like
OSX: http://img139.imageshack.us/my.php?image=keeperosxbm1.tiff
Linux (Plastique): http://img513.imageshack.us/my.php?image=keeperlinuxcl8.png
Linux (Polyester): http://img443.imageshack.us/my.php?image=keeperlinux2sn8.png
So jambi is nicely cross platform, but one still has to deal with issues. One can use the same action for toolbars and menus, and they each get the same icon. Great on Windows/Linux but not so much on OSX, as OSX menu items don’t usually have icons. Qt C++ has a property one can set to disable icons in menus for OSX but I haven’t discovered a way to use it for jambi, so I end up with another set of actions created without icons to put in the menus.
Also, for OSX I have to do additional stuff to get a proxy menu (what a user gets from right clicking on the icon in the titlebar) but with jambi I can’t get a right click in the titlebar to register so the proxy menu shows up on left click. That’s probably my problem, but the point is Windows/Linux don’t expect such a proxy menu in the first place
The Window menu is also added especially for OSX, and must be implemented onesself, though a premade version is available (in c++ I believe, but portable, and maybe only for paying customers rather than GPL edition users). Qt does take care of moving “about” from the help menu to the app menu, and “exit” from the file menu to the app menu when on OSX, which is nice.
Basically, a few of the things Qt does to make life on OSX easier don’t work (or the info on how to get them to work is very hard to find) with QtJambi. But overall it’s been fun to program with and has satisfactory results on the three major platforms. I also like using the signals/slots mechanism. It can be easier than firing and catching exceptions, or implementing observers and observables or whatever. Just another option.
Swing sucks in KDE. I will admit that. Their KDE support is awful unless you use a third party theme.
Load it up in GNOME though, and set the UIManager to use the system look and feel, and you won’t be able to tell the difference between a native GNOME app and the Swing app (presuming you are using a relatively recent version of Java 6.)
Of topic. As a fellow Finder hater I have to ask. Is anyone aware of an easy to install finder replacement?
Honestly segedunum, you are the most pathetic troll I’ve ever seen, you are not a C++ nor Java developer, you don’t understand the problem but here you are givin an “expert” opinion, I don’t know who is more pathetic or moronic, you or the ones modding you up.
You are more pathetic for giving a $hit about modding 🙂
Who ever value mod points is a retard, granted.
[i/]2. Open Netbeans. Find a project where I can create a control panel applet, a systray applet, a system service, a desktop shared component or a desktop GUI embeddable component. [/i]
gotta be the most retarded comment I’ve ever read in osnews.
Highly unlikely, unless you started reading about five minutes ago.