The Dot reports that while Qt/Mac has been GPLed since Apple’s World Wide Developer Conference 2003, which let everybody think that KOffice and the whole KDE stuff would quickly become native Aqua applications. However, the KDE on Darwin project is not really active and needs more developers.
Qt/Mac Development Needs You
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I mean it is already SWEET on Linux, but if it was aquafided….and HIGified for the mac (there are so many OSS apps that are never HIGified to the mac so they look like crap) then there will be not other Office app needed…Koffice is better than anything avalable on the Mac right now because of kparts.
Who really wants Qt stuff on Mac? Especially an “office” package? It’s not that I don’t appreciate Qt as a cross-platform graphical toolkit – but, as a Mac user/developer I would rather put time into native GPL apps.
Looks like they have konsole ported. It would be nice to get the new Kdevelop ported. For those that haven’t tried it, the new Kdevelop(aka the artist formely known as Gideon) absolutely rocks. It’s at beta2 but has been pretty stable for me. It’s got a full c/c++ parser so you get code completion on the fly and all sorts of other goodies. The IDEALI mode is like a tabbed mode on steroids. It’s really efficient with screen real estate. The documentation browser is first rate. It looks like it has support for many languages(including parsers!) for code completion for those languages. I think I’ve finally finally found an IDE on linux that is on par with Visual Studio.
P.S. You can embed kvim into it too!
It built, and I could start it (like in the screenshot), but it didn’t actually work.
The KDE-on-windows guy suggested it was because of konsole’s funky pixmap junk it does to be able to do background images and transparent images, so if we disable that it might actually run right. Haven’t had the chance to try it yet.
I must say this would be sweet. If my time wasn’t swamped…
No. Linux has not even passed Windows 95. Maybe soon!
http://www.google.com/press/zeitgeist.html
Wow i didn’t know about QT for Mac OS X. I’ll have to try this out, I was originally just going to stick doing Cocoa apps, but I like KDE when I use Linux and if I can make an app that runs on Mac OS X & Linux easily then i’ll have to start learning how to develop apps with QT.
Anyone know of some good sites to get started on learning how to make QT apps?
Here is a good start:
http://doc.trolltech.com/3.0/tutorial.html
http://www.digitalfanatics.org/projects/qt_tutorial/
And note that these aren’t C++ tutorial per se, they expect you to know C++ pretty well already.
[I’m saving money (hard part) and convincing myself (even harder) that it’s worhty to buy a G5 1.6 (instead of a dual Xenon/serverworks for the same price)…]
If Qt and KDE apps could run nativelly that’s a real nice thing to add (OS X has a pretty nice version of LyX/Qt already, but with Kate and KOffice that would be ven better).
May I say that the free Qt version for Windows is a rather OLD version ? Do not expect better/newer versions on OS X.
but, as a Mac user/developer I would rather put time into native GPL apps.
As a developer yes, but you could try to port many (nice) KDE applications with 50% of the effort.
Finally, the power of Konqueror the file manager will be coming to my Mac.
That should read “KDE/Mac Development Needs You”. I’m sure that both Qt/Mac development and maintenance is doing fine thanks to Trolltech.
Actually it doesn’t. A lot of Qt app ports I’ve seen (e.g. QCad) looks really bad on OSX. You open a drop-down menu and it opens about 100 pixels on the left, and other funny stuff like that. The Qt/Mac port needs some love as well before people port KDE apps in it. Also, the Qt widgets all look like OSX 10.1, while Apple has updated the look since then to look more clean.
A lot of Qt app ports I’ve seen (e.g. QCad) looks really bad on OSX.
Apple features QCad on their site:
http://www.apple.com/downloads/macosx/imaging_3d/qcad.html
It looks fairly good in this screenshot (albeit low res):
http://a2032.g.akamai.net/7/2032/51/956546e53b74cf/www.apple.com/do…
It’s notable that the “What’s New in this Version” mentions “Mac OS X GUI related bug fixes”
Also, the Qt widgets all look like OSX 10.1, while Apple has updated the look since then to look more clean.
Not to provoke a flame war, but this is one reason why I prefer wxWindows over Qt. wxWindows is using native widgets, Qt is imitating them. However, as Eugenia noticed, imitated widgets are often not exactly the same as the hative ones, they look slightly different and act slightly different, giving those applications an awkward feel to them. And you always have to stay up-to-date with the current host platform and it’s UI evolution.
May I say that the free Qt version for Windows is a rather OLD version ? Do not expect better/newer versions on OS X.
—————-
The Windows version is old, but the Mac version is the latest one and is fully GPL.
> The Qt/Mac port needs some love as well before people port KDE apps in it.
That is your opinion and you maybe have valid points. Still that is not what the dot story states and with forging the title you play politics.
i don’t see why the OSS community should be expected to jump up and rally round to support QT on the proprietry OSX, i’d far rather see people concentrate on a good native port of GTK2, since it’s already a nice toolkit on both *nix/X and Win32, oh, and the developers wouldn’t have to pay trolltech if they want to use their own contributions for commercial apps.
if QT were LGPL’d i wouldn’t mind at all, but i’ve often wondered just how TT can sell you a license that lets you dodge the GPL and link your GPL’d win32 app to a non-compatible closed lib, or whether it’s legal to link a commercial app to the KDElibs with a license from TT, or does that depend just how much of what you’re utilising is part of stock QT, and how much comes from community contributions.
Safari uses QT libraries, or i’m wrong?
I may be speaking out of my *ss, but as far as I know Safari is only using khtml-QT for Mac was not available when work on Safari began…..
You’re wrong.
May be… But: I’ve downloaded the WebCore, and there are many header files, begins with ‘q’…
May I say that the free Qt version for Windows is a rather OLD version ? Do not expect better/newer versions on OS X.
I just checked the “About Qt” window on my Qt Designer on my iMac, and it tells me:
“This program uses Qt version 3.2.2”
I believe that is either the latest release of Qt, or just one release old (it takes a while to compile Qt on my iMac, so I don’t upgrade it on a whim!).
In other words, the free version of Qt on the Mac is the same as the free version on Linux.
I love developing with that.
For any and all interested, there is a new Qt programming book coming out in February titled:
“C++ GUI Programming with Qt 3” By Jasmin Blanchette and Mark Summerfield.
While I find the Qt programming guides and tutorials from TrollTech to be quite superior, I also like a good book on the subject (I find it hard to read HTML books in bed 🙂
You can find the book at Amazon.com and at Barnes & Noble.com (I just ordered my copy from http://www.bn.com)
Anyway, I just thought I’d pass that little bit of news around.
May be… But: I’ve downloaded the WebCore, and there are many header files, begins with ‘q’…
Well, with the q issue. What they have done is created a bridge between cocoa and qt calls meaning that they can directly use the code from the khtml tree without needing to re-write parts. The Webcore itself, if QT was used, would like back to qt library, but instead, those calls are translated to Cocoa hence the nice look ‘n feel one see’s.
“wxWindows is using native widgets, Qt is imitating them. However, as Eugenia noticed, imitated widgets are often not exactly the same as the hative ones, they look slightly different and act slightly different, giving those applications an awkward feel to them.”
Imitation widgets are often slower than native widgets. After all, native widgets are very ingrained into the OS.
But the main reason I prefer wxWindows over QT is that wxWindows is LGPL, and QT is GPL. And a GPL toolkit just isn’t something I want to mess with. (And neither did HP, or IBM, or SUN, or any other companies that chose GNOME over KDE for the standard UNIX desktop).
“i’d far rather see people concentrate on a good native port of GTK2, since it’s already a nice toolkit on both *nix/X and Win32,”
It is? Have you actually used GTK2 on Win32? It sucks. The widgets are ugly, it’s a major pain to program with, its buggy, and and it still has threading problems.
QT produces far nicer looking apps, but I ain’t paying QTs outragious prices.
So I use wxWindows, which uses native widgets, runs on tons of platforms, and produces great looking GUIs.
Oh yeah. And wxWindows has bindings for tons of languages too. Even Java. So I can use the same toolkit, with the same class set, for many different languages.
That’s one of the appeals of .NET afterall. Visual Basic, C#, and Visual C++ all have the same GUI toolkit. wxWindows extends that even further so I have the same GUI toolkit across platforms, and even across languages.
You are probably thinking of Opera, which does use QT. Though I do not know if Opera is available on Mac or not. But both the Windows and Linux versions use QT.
Imitation widgets are often slower than native widgets. After all, native widgets are very ingrained into the OS.
————
Sigh. And being very ingrained into the OS automatically makes a widget faster? This is a Microsoft fallacy — gluing everything to the OS does not automagically make things faster. In any case, all widget-drawing in OS X is in client-side shared libraries. The OS doesn’t even know widgets exist — it just manages window buffers. It has no clue what gets drawn to them. Thus, Aqua widgets and Qt widgets are draw *in exactly the same way* on OS X.
> wxWindows is using native widgets, Qt is imitating them.
Sometimes this is exactly what you need, because sometimes a client wants a certain look across all platforms he is deploying the software on.
I don’t say that’s the usual case, but sometimes there is even a strict specification how something should look. A client of our company had such a request and we could easiy adopt ou software by just creating our own QWidgetStyle
Anyway, for wxWindows I wish there were better ports for Linux/Unix.
Something like wxGNOME or wxKDE, i.e. desktop level not only toolkit level ports
“Sigh. And being very ingrained into the OS automatically makes a widget faster? This is a Microsoft fallacy — gluing everything to the OS does not automagically make things faster.”
That’s true. It doesn’t automagically make things faster. But usually the widgets that come with the OS are faster because they are highly optimized for the OS in question.
They have two other benefits as well. They allow smaller distributions because you don’t have to ship DLLs with your application. And they are more memory efficient because they are shared across applications. Using a third party DLL means you have to load an extra DLL into memory.
One more problem with third party toolkits (and GTK2 in particular). They often don’t integrate well with other applications that do use the native API. Example, try copying a picture from a Web page and then pasting it into GIMP for Windows. Nope. Can’t do it. Because GIMP for Windows doesn’t implement the Native Windows clipboard. Instead, it implements its own clipboard.
Also, the most efficient way to program a GUI app (as far as performance and size), is to use the API directly. For example, if I can program a fully functional Windows application that is quite complex, but will fit on a single floppy disk with tons of room to spare. How? By using the native Win32API.
Now granted, direct GUI programming with the API is a bit of a lost art these days. Most people use toolkits such as Microsoft Foundation Classes. And programming the API directly does require a lot more work, and give you more opportunities to shoot yourself in the foot. But for the ultimate in performance, minimum resource requirements, and small binaries, using the API directly is the way to go.
Sigh. And being very ingrained into the OS automatically makes a widget faster? This is a Microsoft fallacy — gluing everything to the OS does not automagically make things faster. In any case, all widget-drawing in OS X is in client-side shared libraries. The OS doesn’t even know widgets exist — it just manages window buffers. It has no clue what gets drawn to them. Thus, Aqua widgets and Qt widgets are draw *in exactly the same way* on OS X.
————–
That may be true, but because Qt draws its own widgets, when the look and feel of widgets change (as in the case of Panther), the Qt application will stick out, while another application that makes use of native widgets won’t.
Speed isn’t the only benefit of using native controls. Sure, Qt will catch up eventually, but a library using native widgets will reflect that change right away.
That’s true. It doesn’t automagically make things faster. But usually the widgets that come with the OS are faster because they are highly optimized for the OS in question.
———————–
Its really hard for a widget to be “highly optimized” for an OS. The only performance-sensitive part of the widget is the drawing code, and we’ve already established that the drawing code for Qt and MacOS X operate in the same way. It is possible that the code that handles user interaction is more optimized for a given OS, but that’s hardly a performance-sensitive area anyway.
Also, performance really isn’t affected by using abstraction libraries. In a well-designed abstraction library (and Qt is one of these), the library just does stuff that you would have had to write into your application anyway. There is an additional penalty for the cost of a few extra function calls between the library and the native API, but function calls are so cheap that the difference is negligable. Now, if there is a lot of redundancy between what the native API does and what the toolkit does, then there is a performance hit because the same things are done twice, but Qt accesses OS X’s services at a very low level, so there is no redundancy. Also, using an abstraction library ends up using less memory overall. If an app programmed directly to the API and an app using a toolkit has the same level of features, the app using the toolkit will be smaller, because it will be taking advantage of a tremendous amount of shared code. Meanwhile, the app programmed to the native API will be wasting tons of memory reinventing features that come automatically in the toolkit.
@Win Jin Goh
————-
You’re correct, but I wasn’t talking about integration, but rather speed
That’s true. It doesn’t automagically make things faster. But usually the widgets that come with the OS are faster because they are highly optimized for the OS in question.
Obviously you never deal with the buggy listview control (including, among others, speed problem).
“Obviously you never deal with the buggy listview control (including, among others, speed problem).”
There is nothing wrong with the Windows API listbox class, except for users who don’t know how to program for the Windows API correctly.
And I would rather deal with that then GTK for Windows dropped messages where it doesn’t recognize that a button has been clicked until after the window loses and regains focus.
“There is an additional penalty for the cost of a few extra function calls between the library and the native API, but function calls are so cheap that the difference is negligable.”
It’s not negligable when you are doing something that requires painting several times a second. A few extra function calls add up to a lot of extra function calls when doing painting intensive things like video.
For most things, I would agree with you. You aren’t going to notice the difference. But for some tasks, you are going to notice it. And when performance is critical, programming the API directly is still going to give you the best performance.
“Also, using an abstraction library ends up using less memory overall. If an app programmed directly to the API and an app using a toolkit has the same level of features, the app using the toolkit will be smaller, because it will be taking advantage of a tremendous amount of shared code.”
I disagree. Because the app programmed directly to the API is using a shared library that every single other window is also using. Only one copy of user32.dll gets loaded in Windows and it serves all windows on the system. THAT is shared code.
So how can you say that the app using the toolkit will be smaller by taking advantage of shared code? All of the code used by programming the API directly is shared.
“Meanwhile, the app programmed to the native API will be wasting tons of memory reinventing features that come automatically in the toolkit.”
You do realize that the Windows API is a class based system right? So you aren’t programming from scratch. You are using pre-defined window classes for everything. Even a button is created from a window class and you simply modify it to suit your needs. And if you have to, you can even subclass the window classes that Windows gives you.
This gets into some interesting stuff because it involves object oriented programming in C. Yes, you can do object oriented programming in C. (A lot of people don’t know that).
So where do you see the performance hit? You aren’t reinventing features. You are using pre-defiend classes that the Windows API gives you, and you are subclassing those classes when they don’t behave quite as you would like.
It’s not negligable when you are doing something that requires painting several times a second.
>>>>>>>>>>
Yes they are. A function call takes about 10 clock cycles on a P4. Only for the simplest of functions (something like PutPixel) is this cost significant. The cost of even something as simple as drawing a 20-pixel line dwarfs the cost of a function call.
A few extra function calls add up to a lot of extra function calls when doing painting intensive things like video.
>>>>>>>>>>>>
Video isn’t paint-intensive, at least not for the toolkit. Video is almost never drawn using the toolkits usual graphics routines. Rather, specialized APIs like Xv are used to shove the frames to the graphics card. Let’s use a different example that is actually paint-intensive: a 2D game. In such cases, if you can’t afford the cost of two function calls, you can’t afford the cost of one function call. Instead, you’re better-off generating some sort of display list and rendering all the graphics in one go. In Qt, you’d use QPicture or QCanvas depending on the level of dynamism in your scene. For all the other stuff the toolkits do (drawing widgets, creating windows, etc), the cost of each operation is so high that the function call doesn’t even factor in.
I disagree. Because the app programmed directly to the API is using a shared library that every single other window is also using. Only one copy of user32.dll gets loaded in Windows and it serves all windows on the system. THAT is shared code.
>>>>>>>>>>>>>
The API is very low level. If your application is going to support all the high level features of a toolkit like MFC or Qt, you’re going to have to write a lot of unshared, custom code to implement those features. That code will take up lots of memory. I think you’re confusing wrappers and toolkits. A toolkit build high-level functionality on top of a low-level API. A wrapper just wraps high-level functionality over an existing high-level API. A wrapper doesn’t offer you anything beyond translation, which means that it is more memory efficient to just not use it. In contrast, a toolkit offers you high level features that you’d just have to rewrite anyway.
“Yes they are. A function call takes about 10 clock cycles on a P4”
Which adds up fast if you are calling WM_REPAINT several times a second, as occurs during rapid scrolling for example, especially if what you are repainting is a high resolution image.
“A toolkit build high-level functionality on top of a low-level API.”
But the toolkit builds this functionality by calling the API. Look at the source code for the MFC classes.
But the toolkit builds this functionality by calling the API. Look at the source code for the MFC classes.
————-
I don’t think MFC was ever billed as a toolkit, but as a set of wrapper classes around the Win32 API. That’s why its so easy for Win32 programmers to pick it up. But then again, I would rather code straight Win32 over MFC because MFC doesn’t provide much benefits.
Now try porting a Win32 app to other platforms and you’ll see why toolkits like Qt, wxWindows are great.
A few extra function calls add up to a lot of extra function calls when doing painting intensive things like video.
———-
When doing graphic intensive apps, you won’t use something like the Win32 API either. Know how slow BitBlt is? On Windows, I guess you’d be using DirectX that allows direct access to the video hardware. The drawing functions in toolkits in general aren’t suitable for high performance graphics. That’s why all the toolkits I’ve used have a component that provides OpenGL functionality to allow developers to easily integrate OpenGL into their applications.
@Rayiner
Speed of GUI toolkits is rarely the issue for the majority of applications. What’s more important is how well they integrate with the current platform they are running under.
That said, Panther brought a lot of improvements to the speed of drawing GUI components. I don’t know how this came about, but if they optimized the way Cocoa apps drew components, the speed increase wouldn’t be seen in an app that made use of a toolkit like Qt. But if the speed up was because they optimized QuartzExtreme, then this point is pretty much moot 🙂
“I don’t think MFC was ever billed as a toolkit, but as a set of wrapper classes around the Win32 API.”
Have you looked at the GTK source code? At its lowest level, it is also just a wrapper around the API drawing functions. That’s one reason it is easily portable to other platforms. You only have to re-write the low level calls to the GDI. The rest of it is automatically portable.
“On Windows, I guess you’d be using DirectX that allows direct access to the video hardware. The drawing functions in toolkits in general aren’t suitable for high performance graphics.”
For animation or video intenstive stuff yes, but generally not for still images.
“Now try porting a Win32 app to other platforms and you’ll see why toolkits like Qt, wxWindows are great.”
That is one problem of using the API directly. But toolkits aren’ going to completely solve it either. In the typical GUI app, there is still a substantial amount of code that will not be portable across platforms.
<em>There is nothing wrong with the Windows API listbox class, except for users who don’t know how to program for the Windows API correctly. </em>
—
True. But there wasn’t mentioned about the problem of the API. This is merely that even if you use the native implementation of Win32 listview, that would not guarantee you will get the correctness, speed, and optimized behaviour. Refer to source code of wxWindows (which you like so much), somewhere like src/msw/listctrl.cpp and see the introduced workarounds there.
And not let this be forgotten, at least Qt widget style on Windows XP actually uses native controls, even when you use some funny XP skin (yes, it loads and makes use of uxtheme.dll for widget rendering, so to speak).
“This is merely that even if you use the native implementation of Win32 listview, that would not guarantee you will get the correctness, speed, and optimized behaviour.”
It’s guranteed to behave however you program it to behave. Is the listbox poorly designed? Maybe. But being difficult to program well is not the same as being buggy. The listbox does do what you tell it to do, which might not be what you want it to do.
“And not let this be forgotten, at least Qt widget style on Windows XP actually uses native controls, even when you use some funny XP skin (yes, it loads and makes use of uxtheme.dll for widget rendering, so to speak).
Qt is a nice toolkit, but I doubt that it will ever be a serious contender on the Win32 platform. The main reasons for that are its license, and its price.
The GPL simply hasn’t caught on in Windows programming, and most programmers don’t like being told exactly how they have to license their application. But if you don’t want to use the GPL with Qt, you have to buy a commercial license. And at $2,000 per seat, they aren’t going to get a lot of bites. (I can buy Visual Studio Enterprise for less than that, and that even comes with a compiler. QT is just a toolkit).
But also, one other reason I like working with the Windows API directly, is because I prefer programming in C rather than in C++. And most toolkits are C++ based.
GTK is the exception. It does let you program in C. But unfortunately, GTK is still pretty buggy on Win32, so I can’t use it for serious development yet. (And the GTK widgets are really ugly on Windows unless you skin it).
It’s guranteed to behave however you program it to behave. Is the listbox poorly designed? Maybe. But being difficult to program well is not the same as being buggy. The listbox does do what you tell it to do, which might not be what you want it to do.
Not to be confused, I was talking about listview control, which is completely different as listbox. And yes, it’s considered buggy when it doesn’t do what I tell it to do, right ?
Qt is a nice toolkit, but I doubt that it will ever be a serious contender on the Win32 platform. The main reasons for that are its license, and its price.
Looks like Trolltech is just fine with selling commercial license for Qt for Windows. But I won’t elaborate this even more….
The GPL simply hasn’t caught on in Windows programming…
Don’t mix things up. Official Qt for Windows is not available under GPL. There’s no option else then going to the commercial license.
“And yes, it’s considered buggy when it doesn’t do what I tell it to do, right ?”
It DOES do what you tell it to, which may be different than what you want it to do. Difficult to program is not the same as buggy.
“Looks like Trolltech is just fine with selling commercial license for Qt for Windows. But I won’t elaborate this even more….”
Well, considering I can count on one hand the number of applications I have seen for Windows that use Qt, and still have four fingerws left over, I think that says something about how successful it has been on Windows.
GTK has been more successful, even though it is still buggy. I’ve seen several Windows applications written with GTK.
It DOES do what you tell it to, which may be different than what you want it to do. Difficult to program is not the same as buggy.
I don’t get it. For example, when you delete a listview control (e.g using to SendMessage), Windows will send LVN_DELETEALLITEMS message. If I’m nice and want to release memory used by hundreds (or more) items in that listview at once, I need to respond to this message and free that memory space. On the other hand, I also need to tackle LVN_DELETEITEM message, only when one item in the listview is deleted. If I handle only one of this, I might have memory problem (some objects will not be freed).
According to MSDN documentation, after LVN_DELETEALLITEMS there won’t be any LVN_DELETEITEM anymore. Makes sense, because that’s what LVN_DELETEALLITEMS for (you don’t want to have hundred of messages only for each item’s LVN_DELETEITEM). But note that some version of comctl32.dll has the known bug that after LVN_DELETEALLITEMS, it will still send LVN_DELETEITEM, leads to possible double deletion problem. The listview control doesn’t behave as it should be (as written on the documentation). Result ? Memory fault.
Well, considering I can count on one hand the number of applications I have seen for Windows that use Qt, and still have four fingerws left over, I think that says something about how successful it has been on Windows.
Looking at success stories in Trolltech website, seems that the customers of Qt for Windows don’t produce widely available software, rather tailor it to their own use. So, in term of popularity, you’re right, Qt is still away behind the aged MFC and friends.