Linked by Eugenia Loli on Fri 7th Dec 2007 06:25 UTC, submitted by poundsmack
Qt 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.
Order by: Score:
Sexy
by google_ninja on Fri 7th Dec 2007 06:47 UTC
google_ninja
Member since:
2006-02-05

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.

Reply Score: 6

RE: Sexy
by J.R. on Fri 7th Dec 2007 07:13 UTC in reply to "Sexy"
J.R. Member since:
2007-07-25

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.

Reply Score: 5

mixed feelings
by cg0def on Fri 7th Dec 2007 07:02 UTC
cg0def
Member since:
2006-02-12

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.

Reply Score: 4

RE: mixed feelings
by Moochman on Fri 7th Dec 2007 14:09 UTC in reply to "mixed feelings"
Moochman Member since:
2005-07-06

The article was written yesterday. Deal with it.

Reply Score: 4

RE: mixed feelings
by leos on Fri 7th Dec 2007 17:04 UTC in reply to "mixed feelings"
leos Member since:
2005-09-21

So paying for a GUI library does not fit very well with the general Java atmosphere.


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).

Reply Score: 5

RE[2]: mixed feelings
by anda_skoa on Fri 7th Dec 2007 18:00 UTC in reply to "RE: mixed feelings"
anda_skoa Member since:
2005-07-07

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.


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.

Reply Score: 2

SWT
by tyrione on Fri 7th Dec 2007 08:05 UTC
tyrione
Member since:
2005-11-21

http://www.eclipse.org/swt/

That to me is a some excellent work by the SWT Team.

Reply Score: 2

big thing
by antonone on Fri 7th Dec 2007 08:22 UTC
antonone
Member since:
2006-02-03

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. ;)

Reply Score: 1

RE: big thing
by memson on Fri 7th Dec 2007 21:25 UTC in reply to "big thing"
memson Member since:
2006-01-01

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

Reply Score: 1

Unconvinced
by evangs on Fri 7th Dec 2007 08:35 UTC
evangs
Member since:
2005-07-07

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

Reply Score: 9

RE: Unconvinced
by MORB on Fri 7th Dec 2007 10:58 UTC in reply to "Unconvinced"
MORB Member since:
2005-07-06

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

Reply Score: 2

RE[2]: Unconvinced
by PowerMacX on Fri 7th Dec 2007 13:53 UTC in reply to "RE: Unconvinced"
PowerMacX Member since:
2005-11-06

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.


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

Reply Score: 2

RE[2]: Unconvinced
by sappyvcv on Fri 7th Dec 2007 19:00 UTC in reply to "RE: Unconvinced"
sappyvcv Member since:
2005-07-06

Opera is not Qt based. They use Qt for menus only. The actual theme engine is their own.

Reply Score: 3

RE[3]: Unconvinced
by leos on Fri 7th Dec 2007 19:22 UTC in reply to "RE[2]: Unconvinced"
leos Member since:
2005-09-21

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.

Reply Score: 2

RE: Unconvinced
by pgquiles on Fri 7th Dec 2007 11:08 UTC in reply to "Unconvinced"
pgquiles Member since:
2006-07-16

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

Reply Score: 3

RE[2]: Unconvinced
by evangs on Fri 7th Dec 2007 11:18 UTC in reply to "RE: Unconvinced"
evangs Member since:
2005-07-07

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.

Reply Score: 5

RE[3]: Unconvinced
by segedunum on Fri 7th Dec 2007 20:07 UTC in reply to "RE[2]: Unconvinced"
segedunum Member since:
2005-07-06

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.

Reply Score: 4

RE[4]: Unconvinced
by leos on Fri 7th Dec 2007 20:18 UTC in reply to "RE[3]: Unconvinced"
leos Member since:
2005-09-21

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.


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.

Reply Score: 2

RE[4]: Unconvinced
by mikeurbandz on Fri 7th Dec 2007 20:18 UTC in reply to "RE[3]: Unconvinced"
mikeurbandz Member since:
2007-10-29

> 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.

Reply Score: 3

RE[5]: Unconvinced
by leos on Fri 7th Dec 2007 20:56 UTC in reply to "RE[4]: Unconvinced"
leos Member since:
2005-09-21

You haven't seen a Java 6 app running on GNOME recently have you?


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.

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.


Gnome has made no attempt to skin Qt apps. Trolltech has a Cleanlooks theme for Qt, perhaps that is what you mean.

Reply Score: 2

RE[2]: Unconvinced
by joshv on Fri 7th Dec 2007 13:36 UTC in reply to "RE: Unconvinced"
joshv Member since:
2006-03-18

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.

Reply Score: 4

RE[3]: Unconvinced
by sbergman27 on Fri 7th Dec 2007 15:44 UTC in reply to "RE[2]: Unconvinced"
sbergman27 Member since:
2005-07-24

"""
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! ;-)

Reply Score: 1

RE: Unconvinced
by sanctus on Fri 7th Dec 2007 13:42 UTC in reply to "Unconvinced"
sanctus Member since:
2005-08-31

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.

Reply Score: 3

RE: Unconvinced
by JeffS on Fri 7th Dec 2007 14:17 UTC in reply to "Unconvinced"
JeffS Member since:
2005-07-12

"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.

Reply Score: 2

RE[2]: Unconvinced
by evangs on Fri 7th Dec 2007 15:05 UTC in reply to "RE: Unconvinced"
evangs Member since:
2005-07-07

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.

Reply Score: 5

RE[3]: Unconvinced
by jgfenix on Fri 7th Dec 2007 16:07 UTC in reply to "RE[2]: Unconvinced"
jgfenix Member since:
2006-05-25

wxWidgets has good GUI designers like wxFormBuilder or wxDevc++.

Reply Score: 2

RE[3]: Unconvinced
by mikeurbandz on Fri 7th Dec 2007 16:40 UTC in reply to "RE[2]: Unconvinced"
mikeurbandz Member since:
2007-10-29

> 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.

Reply Score: 1

RE[4]: Unconvinced
by leos on Fri 7th Dec 2007 17:18 UTC in reply to "RE[3]: Unconvinced"
leos Member since:
2005-09-21

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.


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.

Also being free has definitely helped Gtk in general.


Absolutely, if it wasn't free, why would you want to use it at all?

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.


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.

Reply Score: 4

RE[5]: Unconvinced
by mikeurbandz on Fri 7th Dec 2007 18:44 UTC in reply to "RE[4]: Unconvinced"
mikeurbandz Member since:
2007-10-29

> 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

Reply Score: 1

RE[6]: Unconvinced
by leos on Fri 7th Dec 2007 19:20 UTC in reply to "RE[5]: Unconvinced"
leos Member since:
2005-09-21

You only mentioned Linux vendors.


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.

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.


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.

Reply Score: 3

RE[7]: Unconvinced
by mikeurbandz on Fri 7th Dec 2007 19:28 UTC in reply to "RE[6]: Unconvinced"
mikeurbandz Member since:
2007-10-29

> 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.

Reply Score: 2

RE[6]: Unconvinced
by segedunum on Fri 7th Dec 2007 20:39 UTC in reply to "RE[5]: Unconvinced"
segedunum Member since:
2005-07-06

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?

Reply Score: 4

RE[7]: Unconvinced
by mikeurbandz on Fri 7th Dec 2007 20:47 UTC in reply to "RE[6]: Unconvinced"
mikeurbandz Member since:
2007-10-29

> 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

Reply Score: 2

RE[4]: Unconvinced
by elsewhere on Fri 7th Dec 2007 17:21 UTC in reply to "RE[3]: Unconvinced"
elsewhere Member since:
2005-07-13

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.


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.

Reply Score: 5

RE[5]: Unconvinced
by sanctus on Fri 7th Dec 2007 18:16 UTC in reply to "RE[4]: Unconvinced"
sanctus Member since:
2005-08-31

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.


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.

Reply Score: 1

RE[6]: Unconvinced
by leos on Fri 7th Dec 2007 18:45 UTC in reply to "RE[5]: Unconvinced"
leos Member since:
2005-09-21

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).

Reply Score: 3

RE[6]: Unconvinced
by segedunum on Fri 7th Dec 2007 20:18 UTC in reply to "RE[5]: Unconvinced"
segedunum Member since:
2005-07-06

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.

Reply Score: 5

RE[6]: Unconvinced
by anda_skoa on Fri 7th Dec 2007 20:31 UTC in reply to "RE[5]: Unconvinced"
anda_skoa Member since:
2005-07-07

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


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.

Reply Score: 2

RE[5]: Unconvinced
by mikeurbandz on Fri 7th Dec 2007 18:41 UTC in reply to "RE[4]: Unconvinced"
mikeurbandz Member since:
2007-10-29

> 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.

Reply Score: 2

RE[6]: Unconvinced
by leos on Fri 7th Dec 2007 18:57 UTC in reply to "RE[5]: Unconvinced"
leos Member since:
2005-09-21

Almost all *nix software that isn't open source, is vertical market. And GTK does quite well there.


And your evidence for this is? I have no evidence either, aside from my own personal experience developing vertical market apps using Qt.

Sure. As long as the prices for those tools are reasonable. For many ISVs, QT's prices are outrageously high.


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.

Reply Score: 4

RE[7]: Unconvinced
by mikeurbandz on Fri 7th Dec 2007 19:06 UTC in reply to "RE[6]: Unconvinced"
mikeurbandz Member since:
2007-10-29

> 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

Reply Score: 1

RE[6]: Unconvinced
by segedunum on Fri 7th Dec 2007 20:45 UTC in reply to "RE[5]: Unconvinced"
segedunum Member since:
2005-07-06

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.

Reply Score: 4

RE[7]: Unconvinced
by mikeurbandz on Fri 7th Dec 2007 20:49 UTC in reply to "RE[6]: Unconvinced"
mikeurbandz Member since:
2007-10-29

> 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.

Reply Score: 1

RE[4]: Unconvinced
by segedunum on Fri 7th Dec 2007 20:11 UTC in reply to "RE[3]: Unconvinced"
segedunum Member since:
2005-07-06

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'.

Reply Score: 1

RE[3]: Unconvinced
by JeffS on Fri 7th Dec 2007 17:07 UTC in reply to "RE[2]: Unconvinced"
JeffS Member since:
2005-07-12

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.

Reply Score: 3

RE[3]: Unconvinced
by Moochman on Sat 8th Dec 2007 13:01 UTC in reply to "RE[2]: Unconvinced"
Moochman Member since:
2005-07-06

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!!

Reply Score: 4

RE: Unconvinced
by Moochman on Fri 7th Dec 2007 14:29 UTC in reply to "Unconvinced"
Moochman Member since:
2005-07-06

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.

Reply Score: 2

Toolkits
by MamiyaOtaru on Fri 7th Dec 2007 20:10 UTC
MamiyaOtaru
Member since:
2005-11-11

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.

Reply Score: 6

RE: Toolkits
by mikeurbandz on Fri 7th Dec 2007 20:22 UTC in reply to "Toolkits"
mikeurbandz Member since:
2007-10-29

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.)

Reply Score: 2

RE: Toolkits
by Boldie on Sat 8th Dec 2007 11:52 UTC in reply to "Toolkits"
Boldie Member since:
2007-03-26

Of topic. As a fellow Finder hater I have to ask. Is anyone aware of an easy to install finder replacement?

Reply Score: 1

v ...
by Hiev on Sat 8th Dec 2007 00:00 UTC
RE: ...
by Chicken Blood on Sat 8th Dec 2007 01:33 UTC in reply to "..."
Chicken Blood Member since:
2005-12-21

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 :-)

Reply Score: 1

v RE[2]: ...
by Hiev on Sat 8th Dec 2007 02:14 UTC in reply to "RE: ..."
v ...
by Hiev on Sat 8th Dec 2007 03:22 UTC
RE: ...
by Chicken Blood on Sat 8th Dec 2007 06:02 UTC in reply to "..."
Chicken Blood Member since:
2005-12-21

[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.

Reply Score: 2