In his blog, Aaron Siego reveals that in Q1 2006 Trolltech is going to release a technical preview of officially supported Java bindings for Qt 4, and that Qt 4.1 has built-in SVG support and PDF generation.
In his blog, Aaron Siego reveals that in Q1 2006 Trolltech is going to release a technical preview of officially supported Java bindings for Qt 4, and that Qt 4.1 has built-in SVG support and PDF generation.
If this is true then perhaps KDE will avoid most of the C# vs Java vs Python vs … language disputes taking place on the Gnome side.
KDE will avoid any language dispute since, unlike Gnome, the KDE people are almost all C++ programmers that are happy with their QT version of C++. Gnome on the other hand is camps of hardcore adherents to C, C++ (the standard version), Java (C# is a bloated Java), C# (Java is a broken C#), Python (it’s the only scripting language you should know), Ruby (we fixed Smalltalk) and lots of other, slightly more exotic programming languages (Lisp, Haskell, Ocaml and whatnot).
The KDE folks are also rather pragmatist and the Gnome rather purist and purists just like to argue about what is purer.
So if you use QT/KDE C++, that’s fine, if you use something else that’s fine too.
KDE will avoid any language dispute since, unlike Gnome, the KDE people are almost all C++ programmers that are happy with their QT version of C++
Oh, did you do a survey?
Gnome on the other hand is camps of hardcore adherents to C, C++ (the standard version), Java (C# is a bloated Java), C# (Java is a broken C#), Python (it’s the only scripting language you should know), Ruby (we fixed Smalltalk) and lots of other, slightly more exotic programming languages (Lisp, Haskell, Ocaml and whatnot).
They want to be productive. C is even more craptacular to write normal desktop applications than C++ because at least C++ can offer some abstractions. I’d be worried if everybody in the KDE camp was happy with C++. I bet they’re more happy with the KDE/Qt libraries than C++.
The KDE folks are also rather pragmatist and the Gnome rather purist and purists just like to argue about what is purer.
Completely meaningless since you are incapable of knowing such things.
> Oh, did you do a survey?
No, I figured that from the lack of programs not written in C++ (there aren’t that many).
>They want to be productive. C is even more craptacular to write normal desktop applications than C++ because at least C++ can offer some abstractions. I’d be worried if everybody in the KDE camp was happy with C++. I bet they’re more happy with the KDE/Qt libraries than C++.
I didn’t say that the QT/KDE people where happy with C++, I said they where happy with the version of C++ used by QT/KDE. It’s not really all that >>pure<<. So you are right to say they are happy with QT/KDE not with C++, that’s why they modified C++.
>Completely meaningless since you are incapable of knowing such things.
Elaborate.
No, I figured that from the lack of programs not written in C++ (there aren’t that many).
Are there really programmers out there dying to write applications in C++?
Are there really programmers out there dying to write applications in C++?
It depends on what you develop C++ with. C++ is, afterall, just a language.
No, Trolltech producing a “official” Java language binding changes nothing because the vast majority of people that are interested in Java on the desktop will just use Swing or SWT. Just look at how marginal JavaGnome is, and despite C++ being a fairly crappy language for normal app development, Java doesn’t really offer any new abstractions over it. Also, you have to have KDE bindings too. There might be some interest in the embedded space.
…and despite C++ being a fairly crappy language for normal app development,…
That part removed all credibility out of your post. You do realise KDE and KDE apps are pretty much 100% C++. Lots of windows software is MFC (yuck), which is C++. I don’t know what do you consider “normal app development”. I am not a C++ zealot or anything; pick the best tool for the job; but C++ is definitly relevant, and perfectly suited for any serious (and “normal”) software development.
You do realise KDE and KDE apps are pretty much 100% C++. Lots of windows software is MFC (yuck), which is C++. I don’t know what do you consider “normal app development”.
I should have clarified my post by saying “fairly crappy” in 2006 and beyond. I’m sure KDE will have lots of C++ apps for years to come, but the industry is moving towards managed code in general.
C++ is *alright*. I’ve written more C++ than any other language, but it has its warts. It’s at least better than straight C for apps. But as I said in an above post, it’s more about the KDE/Qt libraries than C++ itself.
>I’m sure KDE will have lots of C++ apps for years to come, but the industry is moving towards managed code in general.
Sun and Microsoft aren’t the industry and two languages don’t make a trend.
Sun and Microsoft aren’t the industry and two languages don’t make a trend.
Java and .NET are significant players in the industry and Java and C# aren’t the only managed languages.
>Java and .NET are significant players in the industry and Java and C# aren’t the only managed languages.
Name more, excluding languages like VB.Net, Boo, F# and other CLI based languages.
but the industry is moving towards managed code in general.
You might want to take a deep breath and put down that copy of Wired.
ROTFL.
>You might want to take a deep breath and put down that copy of Wired.
Wired? That’s a bit harsh, calling the guy a brainless shithead would have been nicer.
You might want to take a deep breath and put down that copy of Wired.
You might want to discard your KDE fanboyism for a second and wake up to the real world
ROTFL
You might want to discard your KDE fanboyism for a second and wake up to the real world
Why thank you for your usual, and consistently, insightful, interesting and helpful comments. You could at least do it with some grace, humour, or dare I say it, a touch of originality.
ROTFL
Well actually I wasn’t because a useless managed code comment (with no back up as to what managed code actually buys you – apart from hype) usually comes up sooner or later.
Why thank you for your usual, and consistently, insightful, interesting and helpful comments. You could at least do it with some grace, humour, or dare I say it, a touch of originality.
The truth will set you free.
Well actually I wasn’t because a useless managed code comment (with no back up as to what managed code actually buys you – apart from hype) usually comes up sooner or later.
Once you leave your mom’s basement and see what’s going on in the industry then maybe you’ll wake up to reality.
The truth will set you free.
Already has ;-).
Once you leave your mom’s basement and see what’s going on in the industry then maybe you’ll wake up to reality.
Reverse psychology – you live in your Mum’s basement! Really, you are going to have to actually learn to argue the statements you make before leaving first school.
What kind of alternative universe do you live in where Java and .NET don’t already dominate most business programming? And then if you extend the managed concept to languages like Ruby, Python, Perl or anything else that has an associated runtime then its nearly complete.
C++ is a systems/library language. It’s legacy for general-purpose app development, and GONE for web app development except for some very highend transactional stuff.
Well actually I wasn’t because a useless managed code comment (with no back up as to what managed code actually buys you – apart from hype) usually comes up sooner or later.
Jeepers… anonymity is beautiful, isn’t it? If you said something like that to a person’s face, you’d be viewed as a Grade-A Dick by all of your colleagues.
Back on topic, when I spoke of managed code, I was more referring to certain languages that happen to be very popular in industry presently, ie: Java and C#. I don’t need to go over the advantages because
1) we’ve heard them all before, and
2) it’s completely off-topic
-Mark
Jeepers… anonymity is beautiful, isn’t it?
Well no, because it’s me….
If you said something like that to a person’s face, you’d be viewed as a Grade-A Dick by all of your colleagues.
Doesn’t alter that they wouldn’t be able to give me a convincing answer though. There are times when managed code gives you certain advantages, particularly from a server point of view, but the notion that managed code is the way to do everything is just complete and utter bollocks. From a client perspective managed code is close to useless. It doesn’t make development easier, it doesn’t make your applications run better – in fact all it does is turn your applications into raving resource hogs for zero benefit. There are some alleged security benefits, but they all evaporate completely when you start writing everything as managed code. All you’re doing is running an environment within an environment.
It’s amazing how much people get carried away on a blanket of hype.
when I spoke of managed code, I was more referring to certain languages that happen to be very popular in industry presently, ie: Java and C#.
Languages don’t mean managed code.
1) we’ve heard them all before
Have we?
2) it’s completely off-topic
Hmmm, not really.
No, Trolltech producing a “official” Java language binding changes nothing because the vast majority of people that are interested in Java on the desktop will just use Swing or SWT.
Well no, because Swing and SWT can’t cut it. You’ll find very few Java client apps in companies now, and even less talk about them. They have their place, but having a sane development toolkit allied to a language that has a lot of traction in the corporate world (rightly or wrongly) is a big plus. I think Trolltech have hugely underestimated this. If they can bring their excellent development technology to the Java world (client and server side) they’ve got a whole market they didn’t have before.
You might think it changes nothing, but for Trolltech and Qt it does.
and despite C++ being a fairly crappy language for normal app development
You might want to do some development with Qt some time.
Well no, because Swing and SWT can’t cut it. You’ll find very few Java client apps in companies now, and even less talk about them. They have their place, but having a sane development toolkit allied to a language that has a lot of traction in the corporate world (rightly or wrongly) is a big plus. I think Trolltech have hugely underestimated this. If they can bring their excellent development technology to the Java world (client and server side) they’ve got a whole market they didn’t have before.
You might think it changes nothing, but for Trolltech and Qt it does.
Thank you! Finally someone realizes it… the aforementioned ideas that apparently nullify Trolltech’s technology all are missing something. Gtk is, unfortunately, less mature on Windows. Likewise, SWT just doesn’t completely match the look-and-feel of a Gtk/Gnome desktop.
Everyone already knows that Qt is great as a cross-platform toolkit- if they can appeal to some of the newer developers that are unfamiliar with unmanaged code, they might be in luck.
-Mark
Gtk is, unfortunately, less mature on Windows.
I’m not being negative about the GTK Windows people here, but it just flat-out isn’t up to the job. It needs a lot of investment as any sort of cross-platform toolkit. Where that investment comes from is anybody’s guess…..
Likewise, SWT just doesn’t completely match the look-and-feel of a Gtk/Gnome desktop.
Well it primarily uses GTK on Unix/Linux platforms, so it is in a fashion, but my God, SWT is absolutely unusable on anything but Windows – and basically enables Java for Windows. James Gosling was right there. However, Swing suffers problems coming from the other direction. At some point before the next ice age they’ll realise Trolltech’s approach to it is totally correct.
Trolltech really did their homework when they decided on the best way to do a cross-platform graphical toolkit and what to compromise on. You still get people even today who think it’s a good idea to support every native widget on every platform out there, or who have a completely alien looking graphical toolkit and don’t know what to do about it or people who get their kicks subclassing until the end of eternity using wxWidgets.
if they can appeal to some of the newer developers that are unfamiliar with unmanaged code
Managed code doesn’t matter – all you say is ‘Java’. It’s possible to compile Java to native code (and people have used VB for years) and it doesn’t make a blind bit of difference to developers. Managed code buys you certain things in terms of security and managability on the server side, but I really don’t know where this universal ‘managed code’ hype came from. On the client managed code of all kinds is simply terribly slow, consumes an awful lot more memory for absolutely no gain whatsoever (Mono anyone?) and when you run your .Net app on Windows it uses a lot of native libraries and code to make it somewhere near usable.
> SWT is absolutely unusable on anything but Windows
As an SWT software writer, I disagree.
The latest versions are getting there. Not everything is perfect, but what toolset is?
SWT is not perfect, but it is advancing fast enough for me to see a promissing future for it.
As an SWT software writer, I disagree.
The latest versions are getting there. Not everything is perfect, but what toolset is?
I can’t agree. Because SWT supports every platform out there natively there are always a very significant amount of bugs that crop up on some platforms and not others, and it also takes a really significant amount of resources to do. IBM puts a hell of a lot of developer time into it. It is a 24×7 job which could be made an awful lot more productive if they did things in a realistic way.
The problem is it’s also a neverending job. You can’t guarantee that changes and gremlins in the underlying platform will have no effect on SWT, because they will. SWT – nice idea in theory, but not in practice.
Well no, because Swing and SWT can’t cut it. You’ll find very few Java client apps in companies now, and even less talk about them. They have their place, but having a sane development toolkit allied to a language that has a lot of traction in the corporate world (rightly or wrongly) is a big plus. I think Trolltech have hugely underestimated this. If they can bring their excellent development technology to the Java world (client and server side) they’ve got a whole market they didn’t have before.
I’m not sure about the uptake of SWT that is independent of the Eclipse ecosphere, but Swing (craptastic as is) is fairly prevalent in the corporate world. http://weblogs.java.net/blog/hansmuller/archive/2005/10/official_sw…
And here are the survey questions – http://www.evansdata.com/n2/surveys/northamerican_toc_05_1.shtml
Now who knows how Swing really stacks up against Winforms, but we do know that Qt is a blip on the radar screen compared to these and always will be
Besides, how many apps are going to are already on the browser already.
Where is this big interest in Java-Qt or Java-KDE. Even in the Gnome world, very few people are using it.
You might want to do some development with Qt some time.
You might want to try reading some time. I stated in previous posts that it’s the KDE and Qt APIs that mitigates many of the warts of C++.
Now who knows how Swing really stacks up against Winforms
Neither of them stack up, so pray continue.
but we do know that Qt is a blip on the radar screen compared to these and always will be
Well you might want to inform their accountants of that, but that’s the reason for the Java support – increasing the market and reach. And no, it isn’t Swing or SWT that matters, but Java.
Since the vast majority of developers in these corporate environments are paying huge amounts of money for Java development tools, they might actually appreciate something that actually works for a change.
Where is this big interest in Java-Qt or Java-KDE.
None really, but that’s not what this Trolltech announcement is for.
Even in the Gnome world, very few people are using it.
Speaking of blips on radars…… Anyway, it’s going to take time for Red Hat and others to get the Java stuff they want rolling, but at least they have a decent IDE and framework they can use and get others involved with. Unlike some……
You might want to try reading some time. I stated in previous posts that it’s the KDE and Qt APIs that mitigates many of the warts of C++.
C++ is merely a language. In whatever form of C++ you choose you are still going to need development tools and libraries. It’s like taking C# away from the .Net framework, Java away from the class libraries, C++ away from MFC or C++ away from Qt. The two go hand in hand.
Err yer, if you develop in C#, Java or C++ without any of that stuff you’re going to find life a bit difficult regardless of the language.
Neither of them stack up, so pray continue.
In your opinion, but that doesn’t change the fact that Qt is virtually non-existant on those platforms.
Well you might want to inform their accountants of that, but that’s the reason for the Java support – increasing the market and reach. And no, it isn’t Swing or SWT that matters, but Java.
Swing attracts because it’s built in the libraries and has a flexibile API. SWT attracts because it looks native and works great on windows. Qt will probably look great and run well on multiple platforms but its a little late and then you factor in the licensing cost when there are free alternatives…
Since the vast majority of developers in these corporate environments are paying huge amounts of money for Java development tools, they might actually appreciate something that actually works for a change.
On the client? No, I don’t think so. Eclipse and Netbeans are free. And of course your assertion that SWT and Swing doesn’t work is completely ridiculous as always.
Speaking of blips on radars…… Anyway, it’s going to take time for Red Hat and others to get the Java stuff they want rolling, but at least they have a decent IDE and framework they can use and get others involved with. Unlike some……
Eclipse is already compiled with GCJ and SWT uses gtk+. But nobody is really interested in JavaGnome despite Sun and RedHat efforts. As far as IDEs, Eclipse has much better C/C++ (via CDT) than Kdevelop.
C++ is merely a language. In whatever form of C++ you choose you are still going to need development tools and libraries. It’s like taking C# away from the .Net framework, Java away from the class libraries, C++ away from MFC or C++ away from Qt. The two go hand in hand.
Uhmm, that was basically my whole point. C++ on its own isn’t exactly a developer’s dream application language. There are other considerations like speed, dependencies, libraries. But the writing is already on the wall for C++ as a general-purpose, “let’s write this new client app in C++” language.
In your opinion, but that doesn’t change the fact that Qt is virtually non-existant on those platforms.
What platforms?
On the client? No, I don’t think so. Eclipse and Netbeans are free.
Speaking of not knowing what is going on in these environments – yes they do. Free beer tools is a Mum’s basement comment. Besides, you have to add plugins, most of them commercial, to get Eclipse to do anything useful.
Swing attracts because it’s built in the libraries and has a flexibile API. SWT attracts because it looks native and works great on windows.
Both Swing and SWT are junk from a developer’s point of view – everyone knows that. That’s why many people have been stirring around for an adequate replacement, and as a result many people have continued to stir with .Net and Winforms. They’re still stirring.
And of course your assertion that SWT and Swing doesn’t work is completely ridiculous as always.
You might want to actually program with Swing and SWT, or look at the amount of WONTFIX bugs for SWT because they’re going native on every conceivable platform. Like I said, Trolltech got this right.
Eclipse is already compiled with GCJ and SWT uses gtk+. But nobody is really interested in JavaGnome despite Sun and RedHat efforts.
Fanboys sitting in their Mum’s basements are not Red Hat’s target people on this (can’t remember Sun being interested in JavaGnome). They are the enterprise people using Java. Once the classpath support, general quality and the development tools (a big sticking point) are there open source Gnome developers will take to it like ducks to water. Bye, bye Mono.
C++ on its own isn’t exactly a developer’s dream application language.
No one develops with C++ on its own.
In your opinion, but that doesn’t change the fact that Qt is virtually non-existant on those platforms.
What platforms?
.NET and Java
Speaking of not knowing what is going on in these environments – yes they do. Free beer tools is a Mum’s basement comment. Besides, you have to add plugins, most of them commercial, to get Eclipse to do anything useful.
Wrong again Sege. We’re talking about client-side apps here. Almost all the tools for building GUIs are free on Netbeans and Eclipse.
Both Swing and SWT are junk from a developer’s point of view – everyone knows that. That’s why many people have been stirring around for an adequate replacement, and as a result many people have continued to stir with .Net and Winforms. They’re still stirring.
Who are these many people? Are you talking about the many people in your fantasy world where Qt and KDE is somehow relevant on the client?
You might want to actually program with Swing and SWT, or look at the amount of WONTFIX bugs for SWT because they’re going native on every conceivable platform. Like I said, Trolltech got this right.
I’ve programmed in both. Swing has a complex, but more mature and flexible API. The SWT API is pretty raw on its own without JFaces and/or other Eclipse stuff, but it. That doesn’t change the fact that there will never be some great migration to Qt from Swing or SWT – except in a fanboy fantasy world.
Fanboys sitting in their Mum’s basements are not Red Hat’s target people on this (can’t remember Sun being interested in JavaGnome). They are the enterprise people using Java. Once the classpath support, general quality and the development tools (a big sticking point) are there open source Gnome developers will take to it like ducks to water. Bye, bye Mono.
Once again, you just show your ignorance on these matter. Enterprise customers don’t give a rat’s ass about GCJ and will just download Sun’s JDK. And you’re really a crack monster if you think Classpath will ever be relevant in the enterprise. Wake up to reality. And then you just show complete idiocy by your assertion that somehow RedHat working on Classpath and GCJ will make Mono just “go away”.
You are a hardcore basement dweller.
.NET and Java
I hardly think Trolltech needs to support .Net (although they integrate with it on Windows) or run Qt on .Net, and the Java support is just a way of getting into many environments. People want good development tools to get things done – supporting .Net or Java totally is irrelevant.
Almost all the tools for building GUIs are free on Netbeans and Eclipse.
And large companies don’t use tools for free. They will have a license agreement with BEA, Sun, IBM or some other. They may use free tools, but they don’t use them for free. You’re way out of your depth here.
That doesn’t change the fact that there will never be some great migration to Qt from Swing or SWT – except in a fanboy fantasy world.
Well, that’s what you’re wishing ;-). Java gives Trolltech a way into these environments, and given that Qt is quite a bit better than either Swing or SWT, well, we’ll see what happens. Plonking a good all-round toolkit in front of a Java developer that uses what he is used to is going to be like gold dust.
Enterprise customers don’t give a rat’s ass about GCJ and will just download Sun’s JDK.
Bollocks. Developers will use what came with the system, and in the case of Red Hat, that will be GCJ. They’re not going to download Sun’s JDK because it won’t be supported by Red Hat in the context of the whole set up.
And you’re really a crack monster if you think Classpath will ever be relevant in the enterprise.
Red Hat will make (and is making)this a reality, and when it’s bundled with their distribution that’s what people will use.
You see, Red Hat has realised that there is actually something called a market out there on non-Windows platforms for Java so they have a way of funding this development.
And then you just show complete idiocy by your assertion that somehow RedHat working on Classpath and GCJ will make Mono just “go away”.
It has a very good chance for the reasons I’ve stated. Where’s the IDE for Mono, apart from Visual Studio?
*Scratches head*
You really think people choose GCJ over IBM or Sun’s JDK because they’re RHEL customers? Well, it’s a nice dream anyway.
As an aside, I don’t see the point in this little flamewar. Neither of you knows what will happen in the future. I don’t see explosive growth in the future of Qt, Java support or not. But it’s entirely possible, because this is’t Delphi and I’m not the Oracle. Most Java development on the “enterprise client” is firmly in the hands of Swing. Outside of Unix, Qt already has a comparatively small fraction of the client market. Not because it’s a bad framework (it’s easily the best-documented and highest overall-quality toolkit of its kind that I’ve ever used), and I’m not confident-enough in my suspicions as to why this is to offer them for this pointless discussion, but it probably doesn’t matter what the reason is. There are a huge number of Swing components available both freely and commercially for which there aren’t Qt analogues outside of free software projects. No one wants to mine these projects for widgets to use in their Java software. There just isn’t time for this sort of stuff. They’re just going to use Swing and to a lesser extent SWT. Yeah, they’re both pretty crappy and irritating to develop with. That describes Java pretty well to me, but that has done little to hamper its success. MFC is probably one of the worst “toolkits” of its sort, and not only has it spawned design that’s adopted elsewhere (wxWidget for one example) but it’s also been the basis of Windows development outside of VB for years. Qt is comparatively nonexistent. It’s a niche platform, for whatever reason. It’s great that Trolltech has managed to create a thriving business in this niche, but it’s simply hubris to suspect that because of its quality it will see penetration. Development quality has shown to be of little value with respect to many development tools and practices.
We’ll see, though.
As for the IDE for Mono, that would be MonoSharp. That has to be the largest waste of time I’ve ever seen. Since it’s reimplemented to use Gtk# and specifically to target a Unix build environment, it basically entails rewriting enormous parts of SharpDevelop (already not all that great) and is mostly useless as a result. This whole build-all-of-your-tools-in-your-development-language fetish stuff people have is retarded. Putting energy into making Eclipse (or KDevelop) a first-class development tool for Mono would have seen much better returns for effort. But then it wouldn’t be coded in C#!111111
Sigh.
That’s MonoDevelop. Ever read your posts after you write them and wonder, “Where did that come from? Why didn’t you proof-read that before posting it?”
Qt 4 is looking better all the time
nice work trolltech
Gnome framework has many bindings than kde
c# java python c++ c ecc
Java, C++? Is this the 90s?
We can already do svg, pdf, and use numerous other language bindings in GNOME/Gecko/OpenOffice.
Holy shit it does exist. http://www.cse.unsw.edu.au/~chak/haskell/gtk/ man… a pureely functional language that gets hairy when you want side-effects for a gui? well it’s a free country where i am, so to each there own.
ps- not a troll, haskell fan but i don’t think it’s the right tool for tyhe job
Created and maintained by Richard Dale.
I guess the main different, besides possible implementation differences, is that official bindings maintained by Trolltech make them more visible for Trolltech customers.
The main reason for KDE not having the same language dispute does not have so much to do width the language or what the developers preffer. The main reason are Qt, pure and simple. The power lays in the framework.
To boost the productivity of developers several in the Gnome camp have decided they need a higher level language than C, Java and C# are a natural choices.
KDE on the other hand uses C++ with Qt, Qt giving lots of added benefits over plain C++. The combination of C++ and Qt are so powerfull that you only get minimal advantage by switching to Java/C#. And you don’t have to deal with the inherit weaknesses in Java/C#.
The advantage of even higher level languages like Python and Ruby, are much more apparent for application development. And you see proof of this in the thriving development comunity for those languages in KDE.
At least you get it.
i agree with Morty. The power of KDE isn’t c++, it’s Qt.
C++ can be really painful as you can see on gtkmm. I believe for the most “hardcore-c++-hacker” gtkmm is great, it does it all the c++ way with a lot of templates and so on, but the most people just don’t like/use it because it has to much “C++-edges”.
Qt have reached two important things:
1. Qt makes it easy to hack. Qt doesn’t force itself to do it all the c++ way but make it easier if possible (for example signal/slots, extra keyword for the .h files, foreach(),…) So with Qt you work around many edges of c++.
2. Qt offers everything you need: GUI, database access, network,… So with C++ && Qt you have a complete framework which you get otherwise only with Java, .Net or Mono.
I think this are the key facts for the success of KDE and Qt.
About Bindings. I think there will not be much use of Java Qt bindings. First because c++ and Qt is absolutely perfect (see my arguments on top) and second you can see it on GNOME/Gtk+. GNOME and Gtk+ is from the beginning a cross-language Toolkit and there are many language-bindings but in reality most software is written in C only a few are using python and C++ and since ~1year there are some c# programs but the most languages just doesn’t exist in the gtk+ software field.
If such a cross-language toolkit have problems to attract programmers who use other languages than a native and good c++ toolkit/framework won’t do a better job in this question.
“The power of KDE isn’t c++, it’s Qt.”
And the the power of Qt is C++
“C++ can be really painful as you can see on gtkmm. I believe for the most “hardcore-c++-hacker” gtkmm is great, it does it all the c++ way with a lot of templates and so on, but the most people just don’t like/use it because it has to much “C++-edges”.”
Well, I guess I am one of those “hardcore-c++-hackers” then. Honestly I fail to see what pain you feel when using Gtkmm. You talk a lot about C++ “edges” but deliver no facts. You mentioned templates but I can’t see how *using* templated code could feel like an edge. (Btw. Qt contains templates as well.) Your conclusions are therefore not warranted. There is not much that Qt adds to C++. The only thing is a little bit mor runtime introspection, but then I want my signals & slots typechecked at compile time as in Boost.Signals or Gtkmm’s SigC. I agree that Qt offers more functionality than Gtkmm but this is not the point.
I imagine Trolltech is putting development time into Java bindings because of customer requests. As much as I admire QT (but can’t use it at work because of licence issues – we don’t do GPL where I work), it’s hard to imagine anyone planning Java projects but then going off the Swing/Swt reservation. QT is nice indeed, but really so much nicer than the standard Java GUIs? I can’t see it myself.
In any case, it will be fun to try it. And as always I wish QT success.
Um, you do know it is possible to purchase QT with a non-GPL license for developing commercial applications. They are even quite reasonably priced from what I hear.
Since you find just about everything >>craptastic<< do enlighten us and tell what fantastic programming language and toolkit combination you propose is, well, not >>craptastic<<.
Since you find just about everything >>craptastic<< do enlighten us and tell what fantastic programming language and toolkit combination you propose is, well, not >>craptastic<<.
I didn’t propose any toolkit or language. I stated that for general-purpose app (not libraries) development, C++ is on its way out – at least for the non-shrinked app market. Most people in a corporate environment aren’t going around these days saying “great, let’s do this new client in C++”. And C++ is gone from web app development.
Java and .NET is big obviously. Personally, I’m not the greatest fans of either language. If I had my choice I would be doing a lot of programming in Ruby, but there’s lots of considerations beyond my personal preference.
So I at least halfway know where you stand. You know where I sand? I’ve tried lots of languages, believing there is one that doesn’t suck. Problem is I haven’t found it and I’m running out of contenders. My languages of choice are Python, Ruby, and Ocaml, since they do what I want, but they are not very particle. For practicality I have C, C++ and Java, I don’t have to argue that those are probably the biggest languages in use right now. But they suck, they suck bad and still I get no new language that is practical and sucks less. The same goes for GUI toolkits, they all have problems and always will. You can’t produce a good platform independent, self synthesizing Gui, that offers all of the features of its host platform and looks native too. That’s impossible.
That is why I am not happy about you calling something >>craptastic<<, that’s why I don’t appreciate you making predictions about the future of programming languages. You know what? The situation sucks now, the situation sucked yesterday and it damn sure will suck tomorrow. QT and C++ are just as good a choice as Java and SWT, just more expensive and if the programmers got the money and knows C++ better. I don’t give a shit if the industry what’s that programmer to use a managed language.
That is why I am not happy about you calling something >>craptastic<<, that’s why I don’t appreciate you making predictions about the future of programming languages.
Your appreciation and happiness are not my responsibility.
Like I mentioned in a previous post, I’ve written more lines of C++ than any other language – probably tens of thousands of lines. At the time this codebase was started, Java wasn’t even out yet, and even if it was out it wouldn’t have made any difference in its infant state.
But I stand by my statement that C++ for general inhouse application development in 2006 is craptastic. It’s too low level and too complex for rather mundane tasks. That’s not to say that something like Qt or KDE shouldn’t be written in C++. It makes more sense than straight C. But those are libraries and frameworks, which is a whole different ballgame.
I still stand by my statement that every language sucks, so dose every toolkit and singling one language out and labeling it >>craptastic<< is neither dignified for the language nor the programmer. If C++ is modern enough for application development today is irrelevant since LISP and Smalltalk are old languages and even with all the nice abstractions didn’t mater in comparison to say assembler. I’m not holding out for a better language, and even if one appeared tomorrow there’d still be all those libs in C, C++ and even Java that would make migration impossible.
Swing has a complex, but more mature and flexible API. The SWT API is pretty raw on its own without JFaces and/or other Eclipse stuff, but it. That doesn’t change the fact that there will never be some great migration to Qt from Swing or SWT – except in a fanboy fantasy world.
I’m not sure if it’s something that gives you mental blindfolds here(QT or segedunum, perhaps), or just plain stupidity. Great migration from Swing or SWT are not the issue, look at it the same way regular Qt has got migration from MFC. Even smaller percentages gives good business, it’s afterall not the game of monoply. Giving people who know Java a better toolkit will do this, the same way regular Qt did for C/C++. There are always some people who will insist on continuing to use subpar tools.
Great migration from Swing or SWT are not the issue, look at it the same way regular Qt has got migration from MFC. Even smaller percentages gives good business, it’s afterall not the game of monoply. Giving people who know Java a better toolkit will do this, the same way regular Qt did for C/C++. There are always some people who will insist on continuing to use subpar tools.
No, Sege was making these big claims (as he usually does). But go tell the java people that Swing and/or SWT are subpar. Do you claim that there is a sudden interest because Trolltech is doing it?
“when i informed them we are looking at a win32 and macos port of our libs which are all lgpl’d (or more permissive) eyes widened”
http://galaxy.osnews.com/email.php?blog_id=2397
Everything is somewhat easier to understand if you bother to read thing in context.
“interestingly, many people asked me how to use various kde technologies in their Qt apps. no less than 5 different companies did so, actually. a couple asked about khtml, one asked about katepart and the rest were inquiring about the topic in general. apparently ISV’s out there have been watching what we’re doing and wanting in on the action. when i informed them we are looking at a win32 and macos port of our libs which are all lgpl’d (or more permissive) eyes widened.”
http://aseigo.blogspot.com/2005/10/troll-tech-dev-days-05-in-san-jo…
Ahh, yeah you’re right. He seems to be talking about about KDE. Of course the OSGalaxy link doesn’t want to format properly and when he said “we” I assumed he was talking about Trolltech.
But go tell the java people that Swing and/or SWT are subpar.
Since lots of the Swing/SWT users(or people developing with it) already say the same, I think they already know.
Do you claim that there is a sudden interest because Trolltech is doing it?
Good professionals are always interrested in better tools. And having the better tools made by a supplier with over 10 years experience delivering a high quality crossplatform toolkit are noticeable too. The interest is already there, Troll Tech doing it will only focus it more.
Good professionals are always interrested in better tools.
That’s the crux of the matter. Even if someone was to agree that Qt is a better tool, then you have to ask is it so much better that we’re going to plunk down $1500 per developer seat per OS just so we can get something that looks a little better? And then there’s the whole issue of Swing already being in the library and IDEs already having Swing designers, as well as training and such.
This is something that Trolltech should have done years ago when Swing really sucked, but maybe they’re trying to target the mobile market. Who knows.
Even if someone was to agree that Qt is a better tool, then you have to ask is it so much better that we’re going to plunk down $1500 per developer seat per OS
$1500 just about buys you a week of developer time, and a well designed and documented toolkit can easily save you that.
That’s the crux of the matter. Even if someone was to agree that Qt is a better tool, then you have to ask is it so much better that we’re going to plunk down $1500 per developer seat per OS just so we can get something that looks a little better?
Yes.
Since you were talking about these things called enterprises, they plonk more money than that down all the time. You’re really going to have to get out of this “oh we don’t want to pay anything!”, “businesses pay nothing!” attitude you have. Until you do you have very little credibility – if any.
And then there’s the whole issue of Swing already being in the library and IDEs already having Swing designers, as well as training and such.
Swing has all but halted Java client usage in many organisations, although Java server usage is still very high. If you give Java developers good development tools to get away from these problems, and something they can push politically, they will be attracted to it like bees to honey.
“Even if someone was to agree that Qt is a better tool, then you have to ask is it so much better that we’re going to plunk down $1500 per developer seat per OS just so we can get something that looks a little better?”
Qt’s supposed superiority is not limited to “looking better.” It extends to things like easier and quicker development: things which many companies would find well worth the $1500/dev/platform, unlike your “looks better” strawman.
How do they map signals & slots map into Java?
And why do they need that signal & slot macro hackery anyway, could they really not have solved that problem with standard C++ ?
They needed the macros because when Qt was first created there weren’t many C++ compilers that supported (correctly) all of the C++ standard.
They needed the macros because when Qt was first created there weren’t many C++ compilers that supported (correctly) all of the C++ standard.
I beleive the time frame is even further behind than that. I think that when Qt was first developed the functionality for signals/slots wasn’t even proposed in any C++ standard, let alone separate compilers. If I remember correctly, the required functionality is now in the C++ standard (can’t actually remember what its called in C++ speak though), but it will probably be another couple of years before they can safely remove their moc stuff. Especially since they (only) use Microsoft compilers on Windows, and Microsoft is not well known for their standards compliance …. in any product they produce.
Borland’s OWL framework (version 2) had very elegant C++ event handling that would have been suitable for signals/slots.
In 1993!
The reason there are Moc extensions is for C++ reflection, not for signals/slots. RTTI didn’t make it into C++ for a long time and even now there are pieces of functionality which would be nice to have but aren’t there.
Of course Java and the .NET/Mono languages all have very nice reflection capabilities.
Qt would be great if it were ported to .NET/Mono and Java. I’m hoping this happens soon.
I find it rather strange how people filter information and which part of Aaron’s blog getting the most attention. Frankly Java bindings are not that interresting, other than for the Java coders when they get to use a great toolkit.
The Qt-coco thin client framework sounds really amazing, and much more exiting than the java part. But perhaps people would need to see a demonstration, like Aaron did to grasp the coolness. Or perhaps it did not have the buzzwords to genereate attention.
The built-in SVG support has a buzzword(SVG), but I don’t think people really thought about the implications. Perhaps thinking it only means that Qt can display SVGs now, not realizing the full meaning of built in. What about a SVG shaped widget, isn’t that cool or what? http://ktown.kde.org/~zrusin/cool2.swf
What is described by Aaron is important for the future of Linux. There is no real app framework development being done on Linux other than Qt. So it falls to Trolltech to lead the way.
Pretty soon now we will see, however, that Linux is irrelevant. So much energy and time for nothing.
The apps aren’t there. And likely will never be there.
Partially because of Qt’s raping prices for closed source (not all companies are ready to hop on board the Soviet-style open source bandwagon). Open source works on the principle of shipping low quality software and then making income on support. IBM loves this. Customers don’t. Small/medium ISVs don’t. Only if your core competency is support do you like open source.
Partially because there just are not any real tools for small/medium ISVs. Builing non-server apps in Java is dead in the water. Sun could not build a real dev framework… no matter how many companies they buy. IBM’s rich client framework / SWT is pretty much junk. For C++ there are a bunch of crappy free frameworks and $$$$$$$$$ Qt. And you know… there is nothing else.
So it is hard to say what will become of Qt-coco. The SVG support is nice, but Windows Vista has this and it will have massive development tool support. Where is the killer IDE for Qt? There isn’t one.
Ultimately, Qt will put some interesting tech on the market, but will not amount to anything serious. Enough for the upcoming IPO and the executives to cash out. So buy a round of drinks for people when you’ve got your money. You did earn it.
http://www.trolltech.com/products/qt/pricing.html
If you want to develop on two platforms, it’s $5K per developer to get started ($5.5K w/Qt solutions) and then $1500/year afterwards ($2K/yr with Qt solutions).
Over a three year project with 10 developers, you are looking at $55K of initial licenses and $40K afterwards. So over three years, $100K for your C++ framework.
Needless to say, this figure is absurd for any but the very largest companies. And that is why for closed source, Qt is mostly (close to only) used by the very largest companies.
Any other platform and the cost would be very low compared to $100K. And with Qt, you will get a framework revision (say Qt 4.0) but it will be so bugridden that you’ll waste a lot of time. Making the cost stupendously higher. Right now, Trolltech is working as hard as they can to get out *yet another* bug fix release for Qt4. So for a product that is a year late, plan on a year of bug fixes.
Only the very largest companies can afford to work with a company like Trolltech. Otherwise the only recourse is going with the free version of the software as there is no real value proposition for Qt closed source unless you are loaded with cash to burn and time to waste.