Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

C++ GUI Programming with Qt 4

samzenpus posted more than 8 years ago | from the read-all-about-it dept.

148

Ravi writes "When somebody talks about the Qt Framework, the first thing that comes to mind is KDE one of the most popular Desktops which is built using the Qt library. Qt is a C++ GUI framework created by the Norwegian firm Trolltech which can be used to build applications for a variety of OSes and platforms. The latest version of Qt (Ver 4.0) contains huge improvements over its earlier versions such as advanced modal/view functionality, easy to use template containers and better Unicode support just to name a few. I have been excited about the ease with which one can build GUI applications using Qt. Trolltech provides the library in two licences - the free licence which mandates that the applications developed be released under GPL and a commercial non-free licence which allows one to develop closed source applications using Qt." Read the rest of Ravi's review.

I found the latest book on Qt titled "C++ GUI Programming with Qt 4" authored by Jasmin Blanchette and Mark Summerfield and brought out by Prentice Hall to be a remarkable book in that it takes the readers through the basics of creating applications using the latest version of Qt and gradually shifts to explain the more advanced concepts of GUI programming using this C++ framework.

The book, all of 540 pages is divided into three parts - the first part containing 5 chapters dealing with Basic Qt, the second part titled Intermediate Qt which contains 11 chapters and the final part titled Advanced Qt containing an additional 5 chapters.

The major work in picking up skills in a new GUI framework revolves around getting to know all the classes and their member functions. And learning Qt is no different. In the first five chapters (Part I of the book), one gets to know the rudimentary concepts behind creating GUI applications using the Qt toolkit. And remarkably, instead of boring the readers with the different Qt classes, the authors take a hands on approach and introduce the concepts via examples.

In chapters 1 through 5, the readers are introduced to rapid dialog design using the Qt Designer, introduction to the main Qt classes such as QApplication, QObject, QWidget and its child classes as well as a good understanding of the concept of Signals and Slots which form the meat behind communication between different objects in Qt. Apart from that the 5th chapter also introduces to the reader the concept of Double buffering - one which is used popularly by the programmers in eliminating flicker in the GUI interface.

The sixth chapter titled "Layout Management" falls in the second part namely "Intermediate Qt". Here one gets to know and tryout the different layout classes that are available in Qt using which one can easily design sophisticated GUI applications. This chapter also gives the reader an introduction to Multiple Document Interface by way of an example.

Event Processing forms the basis of the seventh chapter where the authors explain how to catch events such as key presses and timers. Apart from that the authors also explain the five levels at which events can be processed and filtered in Qt.

Qt has an excellent collection of classes for creating 2D and 3D graphics. And from version 4, the classes are grouped into modules which need only be plugged in on a need to use basis. The primary class which deals with the 2D graphics engine in Qt is the QPainter class. The use of this class has been explained in detail in the eighth chapter titled "2D and 3D Graphics". Other than that, one also gets to know about the OpenGL module in Qt which makes it very easy to integrate OpenGL code into Qt applications as well as the classes which implement printing.

It is really interesting to see that the entire subject of Qt is apportioned into separate chapters with each chapter dealing with a particular topic. For example, if in the 9th chapter, the authors dwell on explaining the classes which implement drag and drop support, the succeeding chapter elaborates on the Model view controller architecture which forms the basis for most item view classes which implement tables, tree views and lists.

Another thing worth noting is that each chapter is explained with a complete stand alone example which makes it easy to try out what one has learned and also get a better idea of the concepts behind the classes that are explained. So while learning say about the container classes in Qt, the reader can actually try out an example and the code is accompanied by step-by-step explanations which makes it much more simpler to grasp the concepts.

All object oriented languages contain what are known as container classes - those which are responsible for creating sorted and unsorted data arrays, vectors and lists. And C++ has a couple of them in the Standard Template Library (STL). Qt has its own wide array of container classes which sport a number of improvements over STL in that they support implicit sharing (Copy on Write) which gives the applications a significant performance boost. In the 11th chapter titled Container Classes, the authors explain the concept of containers and the Qt classes that can be used for the same.

The next two chapters deal with writing and reading data from files as well as databases. And in each case, the concepts are explained with the aid of examples which makes the narration much more interesting to follow.

Qt has good support for Networking as well as XML which is evident from the 14th and 15th chapters which elaborate on the classes responsible for these. Even though these two short chapters do not cover all the networking or XMl concepts, I found them to impart a good idea of the use of a couple of important Qt classes related to networking and XML.

The 17th chapter titled "Internationalization" falls in the Advanced section of the book. I found this chapter to be an eye opener in that, with Qt's robust use of Unicode, it is possible to create applications which support a wide variety of non-english languages.

But one of the very important concept of multi-threading is explained in the next chapter titled what else "Multithreading" where the authors teach how to create threads easily in Qt.

If one looks at any KDE application, it will be evident how the parent application can be extended by use of plugins. A plugin is a dynamic library which implements a particular interface to provide extra functionality to the user. In the 19th chapter, one gets to know how to create dynamic libraries using Qt which can then be plugged into the parent application.

In the penultimate chapter, the authors explain all the platform specific features and tweaks such as using ActiveX in Windows and handling session management in X11. There are also four pages - which I believe to contain the shortest chapter I have ever come across and where a couple of classes which can be used in programming for embedded devices such as mobile phones are listed. By including this tiny chapter, perhaps, the authors were sending a signal to the developer community that Qt is fully ready for use in embedded development.

From start to finish, I found the book immensely enjoyable. The style of narration of the authors which interleaves the example code with the explanation is ideally suited to pick up skills in using any toolkit without getting bored, especially since the bulk of the learning involves acquiring a fine understanding of the classes the toolkit provides. As a bonus the book also provides an appendix which gives an introduction to C++ for programmers who use Java or C#.

The single CD accompanying the book contains Qt library in the source form for the Linux platform as well as for Windows and Mac platforms. I did not have any problems in compiling the source and installing the library in Linux using the instructions provided in the book. And within a little more than an hour (the time taken to compile the source code), I was able to start coding and compiling the examples given in the book. All in all, I find this book to be an invaluable guide in picking up skills in programming in the latest version of Qt (4.0).

Ravi Kumar likes to share his experiences in programming and in using Linux through his blog on Linux."


You can purchase C++ GUI Programming with Qt 4 from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Sorry! There are no comments related to the filter you selected.

I am the very modal of a modern slashdot editor (4, Funny)

edittard (805475) | more than 8 years ago | (#15861004)

advanced modal/view functionality
That's a combination of model/view and modal dialog boxes, is it?

this article (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#15861018)

should be teabagged

http://en.wikipedia.org/wiki/Teabagging [wikipedia.org]

Re:this article (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15861738)

Right on... Qt fails when compare against the likes of gtk. GTK is far superior in terms of functionality, ease of programming, and flat out just better looking then Qt. So if you want a bad ass looking app with good looking widgets use gtk. If you don't care about looks and like the complexities of working and api that doesn't make sense and spening hours just trying to do simple things use qt. It's just that simple

Update on the link (1, Informative)

Anonymous Coward | more than 8 years ago | (#15861055)

Slashdot has linked to B & N here, but it seems that Amazon has it much cheaper [amazon.com] .

Re:Update on the link (0)

Anonymous Coward | more than 8 years ago | (#15861162)

But Amazon are more evil. (One-click patent, promising they were going to fight patent craziness then not doing so, etc.)

Re:Update on the link (1)

ryturner (87582) | more than 8 years ago | (#15861322)

If the choice is paying less at an "evil" store or paying more at a "good" store, then that is an easy choice for me. I am going to purchase from the "evil" store. This might not be the most popular choice on slashdot, but it definitely explains why Walmart is so successful.

Re:Update on the link (0)

Anonymous Coward | more than 8 years ago | (#15861362)

Pffft. I'd be willing to pay more at the evil store.

Being bad is more fun than being good.

Re:Update on the link (2, Informative)

rm999 (775449) | more than 8 years ago | (#15861308)

And your link doesn't have a referral tag (which I hate because I know those are the next popup windows of the internet).

It's hard to write a bad review when you know you will make money if people buy it...

Bookpool has it even cheaper (0)

Anonymous Coward | more than 8 years ago | (#15861653)

Re:Update on the link (1)

eviltypeguy (521224) | more than 8 years ago | (#15862786)

Bookpool has it even cheaper ($32.95 USD).

Interoperability (2, Insightful)

lkeagle (519176) | more than 8 years ago | (#15861060)

Does the book explain any methods for dealing with interoperation with other frameworks? Gnome, perhaps?

I've always found that the most useful books are the ones that provide direction on how to get your application to work well with others...

P.S. F.P.

Norway (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#15861068)

I hear that Norway's population is small because of extremely high levels of homosexuality in that country. Is this reflected at all in QT? I don't use linux...

Re:Norway (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#15861099)

god is a homo and so is allah in a sense
http://northway/ro.cx [northway] !

Re:Norway (0, Funny)

Anonymous Coward | more than 8 years ago | (#15861194)

Yes, as the current King of Norway, I can confirm this.

4.1 is the latest version (0)

fornwall (993770) | more than 8 years ago | (#15861081)

Not 4.0.

Re:4.1 is the latest version (1)

stupidfoo (836212) | more than 8 years ago | (#15861209)

Wrong. 4.1.4

Re:4.1 is the latest version (0)

Anonymous Coward | more than 8 years ago | (#15861574)

4.0 attow

gui and native code - bad combination (-1, Troll)

Speare (84249) | more than 8 years ago | (#15861102)

I've coded a lot of GUI code, in everything. Pascal, C, C++, Java, Tcl/Tk, Perl/Tk, HTML, you name it. One thing I've found is that C or C++ may be useful for problem-specific custom widgets, but after that, the higher-level the better. GUIs are a fluid, flexible, dynamic, change-on-the-fly, subject-to-change, feedback-driven kind of feature.

As such, you don't want to be saddled with a language which requires you to think about every malloc(), to manipulate strings of characters as bytes, to set up event handler callback routines, or to call methods on layout-bag-grid-column junk.

You want to build up that layout graphically, name the elements appropriately, and work with the highest-level language you can find to deal the behavior behind 98% of all GUI requirements.

Because you know some PHB is gonna tell you to make some widget mauve because it has more RAM. Again.

Re:gui and native code - bad combination (2, Informative)

gatkinso (15975) | more than 8 years ago | (#15861166)

Well, when I write C++ code, I rarely use malloc().

gui and native code - Mind Bender. (0, Funny)

Anonymous Coward | more than 8 years ago | (#15861176)

"I've coded a lot of GUI code, in everything. Pascal, C, C++, Java, Tcl/Tk, Perl/Tk, HTML, you name it."

Brainfuck?

Re:gui and native code - Mind Bender. (1)

YetAnotherLogin (534226) | more than 8 years ago | (#15862078)

"I've coded a lot of GUI code, in everything. Pascal, C, C++, Java, Tcl/Tk, Perl/Tk, HTML, you name it."
Brainfuck?
Whitespace? [dur.ac.uk]

Re:gui and native code - bad combination (1)

hubie (108345) | more than 8 years ago | (#15861191)

I know everyone has their favorites, but I'm curious that if you were given complete control over developing a basic multi-OS application (for arugments sake, something real simple with all the usual expected GUI boxes and features), what language combo would you use?

Re:gui and native code - bad combination (-1)

Anonymous Coward | more than 8 years ago | (#15861207)

VisualWorks Smalltalk. Any day, every time

Re:gui and native code - bad combination (0)

Anonymous Coward | more than 8 years ago | (#15862286)

C++ with MinGW and QT in the Eclipse IDE. Easy peasy

Re:gui and native code - bad combination (2, Insightful)

ardor (673957) | more than 8 years ago | (#15861213)

Indeed, GUI development is one of the areas where managed environments shine. However, it IS possible to deal with this in C++. I agree that if I want to put a label in a window, I dont want to have to handle its deallocation, i.e. I want a "fire-and-forget" feature. I accomplished this in my wrapper by letting the parent deal with its children. It is a very simple concept, but works very well. I can write "new Label(mainwindow,"Here is my label",22,11);" and do not ever have to worry about a delete call or about memory leaks.

IMO the best thing is to make the GUI purely data-driven, however. Stuff the entire layout in a XML, and the application only has to connect its event handlers to the named signals (assuming a signals-based event dispatching mechanism). AFAIK libglade does it like this. The huge advantage is that redesigning the interface no longer requires code modification. Don't like the button position? Move it down, you dont even have to recompile.

Re:gui and native code - bad combination (4, Informative)

Phisbut (761268) | more than 8 years ago | (#15861531)

I agree that if I want to put a label in a window, I dont want to have to handle its deallocation, i.e. I want a "fire-and-forget" feature. I accomplished this in my wrapper by letting the parent deal with its children.

Well, that is exactly what Qt does. Every time you create a widget, you pass a pointer to its parent, and then you can forget about the widget. When the parent dies, it'll kill all of its children, and then they'll kill their children too in cascade. I do tons of Qt programming (that's what we use where I work), and memory management of Qt widgets is a breeze, every widget is hierarchically created, and I just need to kill the window when I don't need it anymore to have it kill all its widgets and sub-widgets. No need for a custom-made wrapper, it's all in there already.

Re:gui and native code - bad combination (1)

dreamlax (981973) | more than 8 years ago | (#15861321)

What I sometimes do is write the performance-critical parts of my program in a low-level language, usually C or C++, and bind it with Python, and have pyGTK or pyWidgets for the GUI. It gets messy handling two languages, but doing a GUI in a high-level language like Python hugely reduces GUI development time. It can also be a little boring, if not tedious, to mix C++ and Python too...

Have you ever developed a GUI for a Windows app in C++? They may well have just invented their own C++ standard... it's crazy. I developed GUI apps in VB before going to C++, before finally wiping Windows and using Linux, and even writing a GUI in wxWidgets is by far easier than Windows. wxWidgets can even take care of the main() entry point (or WinMain or what have you). In Windows, I think you required about 50 or so lines of code for a "hello world" (wxWindows isn't many lines less but it is much easier to read and follow). Horrible. Wouldn't touch it again with a 40-foot pole.

I haven't tried Qt primarily because Gnome's always been the default desktop on the distro I installed, but instantaneously I can conclude it's better than Win32 GUI programming.

DirectX is another issue... woah! I wouldn't go there again either. Once was too much. It's like taking the mangled C++ code you wrote for a Win32 GUI, mangling it further, making sure pointers are passed around like free pizza, and somehow have it spit out some form of 3D graphics and sound. To try and follow DirectX code was to me like being blind and walking through a maze, you'll eventually get there, but only after much, much effort. Maybe it's just me, but I cannot believe I ever wrote programs like I did and thought I was doing it "right".

Not trying to belittle Microsoft's programming standards or anything... cough..

Re:gui and native code - bad combination (1)

PeterBrett (780946) | more than 8 years ago | (#15862168)

What I sometimes do is write the performance-critical parts of my program in a low-level language, usually C or C++, and bind it with Python, and have pyGTK or pyWidgets for the GUI. It gets messy handling two languages, but doing a GUI in a high-level language like Python hugely reduces GUI development time. It can also be a little boring, if not tedious, to mix C++ and Python too...

Check out PyQT [riverbankcomputing.co.uk] .

Re:gui and native code - bad combination (1)

BravoZuluM (232200) | more than 8 years ago | (#15861328)

You haven't used QT based on your comment. You don't use malloc. QStrings and QByteArray hide the inner workings of string manipulation, slots and signals make event handling trivial and the layout managers just work.

I've done alot of GUI development going back to System 7 on the Mac, OWL, MFC 1.0, MacApp, ET++, Starview..ect.

QT is by far the best C++ UI (and more) development environment for doing cross-platform development. And, it's a better ActiveX development than ATL or MFC.

M

Re:gui and native code - bad combination (1)

Henry V .009 (518000) | more than 8 years ago | (#15861373)

I agree with the higher the better approach. On the other hand, a person calling malloc while coding in C++ probably doesn't know C++. Nor are C++ strings like C strings. Handler and callback routine setup is generally handled by the library you use (QT has a nice slots and sockets implementation. Boost also has a library devoted completely to that which can be dropped into other projects.) The "layout-bag-grid-column" will depend on whatever library or API you are using, not the language.

C++ is not C by any stretch of the imagination. It's a multi-paradigm langauge (that's both the best and worst thing about it). If there is a programming methodology out there, C++ probably supports it. Although it'll be nice if functional programming gets some help with C++0x -- Boost Lambda doesn't really cut it.

Use composition instead of inheritance (1)

amightywind (691887) | more than 8 years ago | (#15861451)

As such, you don't want to be saddled with a language which requires you to think about every malloc(), to manipulate strings of characters as bytes, to set up event handler callback routines, or to call methods on layout-bag-grid-column junk.

You make a very good point. Most programmers do not make the effort to seperate UI elements from their callback infrastructure because they use inheritance to compose functioning widget heirarchies. So they combine program context with their UI. If you use composition you will be much better off, and it is easy. Create a "spineless" GUI mockup for your boss. The code should contain minimal dependencies beyond Qt or wxWidgets or whatever you are using. Implement your event handlers with minimal knowledge of the UI and attach them dynamically. With older toolkits in C you only have callback hooks so this is easy.

Re:gui and native code - bad combination (1)

iangoldby (552781) | more than 8 years ago | (#15861486)

As such, you don't want to be saddled with ... layout-bag-grid-column junk.

You want to build up that layout graphically...

The trouble with drag-and-drop UI designers is that the layout tends to break horribly when the window is resized or the font size changed. (I'm talking about VB, Delphi, and MFC here - there may be other frameworks that have found a way around this problem.) Designers who try to solve the problem by making their forms non-resizable should be taken outside and shot...

Re:gui and native code - bad combination (1)

vdboor (827057) | more than 8 years ago | (#15861959)

The trouble with drag-and-drop UI designers is that the layout tends to break horribly when the window is resized or the font size changed. (I'm talking about VB, Delphi, and MFC here - there may be other frameworks that have found a way around this problem.) Designers who try to solve the problem by making their forms non-resizable should be taken outside and shot...
that's something Qt has solved too, you can define the layout contraints in the designer directly. See it in action with this video: http://www.trolltech.com/trolltech/products/qt/lea rnmore/video/demos/browser [trolltech.com]

Re:gui and native code - bad combination (1)

Jerry (6400) | more than 8 years ago | (#15861535)

As such, you don't want to be saddled ith a language which requires you to think about every malloc(), to manipulate strings of characters as bytes, to set up event handler callback routines, or to call methods on layout-bag-grid-column junk.


It's obvious you've never used QT4.1.x/C++, or you wouldn't be mentioning malloc(), etc.


If I were to compare coding with the QT4 API to anything it would be Java on steroids. QT uses MOC, a meta-object compiler, to convert gui/api dependent coded to pure C++. Classes with the QOBJECT in it have automatic access to automatic memory management and garbage collection. Of course, if you use NEW its up to you to use DELETE before your method goes out of scope.

What is really nice is that I have written an app using Microsoft VC++ 2003/Qt on Windows against Oracle and compiled it on Linux against PostgreSQL with no code changes, using compiler defines to switch in and out the proper syntax at the appropriate places. It's an in-house app currently used in production. Saying it is lightening fast is an under statement.

Re:gui and native code - bad combination (1)

quintesse (654840) | more than 8 years ago | (#15862184)

"If I were to compare coding with the QT4 API to anything it would be Java on steroids"

You mean, that's why they implemented so many Java-like features in version 4, so they could call it Java on steroids?

Or is it maybe because they took a look at Java and went "hey, there's a lot of cool stuff i there, we can use that as well!" ;-)

Re:gui and native code - bad combination (1)

oopsdude (906146) | more than 8 years ago | (#15862850)

I agree with your assertion in general that high-level languages are better for GUI development, but:

GUIs are a fluid, flexible, dynamic, change-on-the-fly, subject-to-change, feedback-driven kind of feature.
You're absolutely right, despite being a bit redundant. As someone who has used many languages myself, I can tell you that I can implement just that kind of GUI in almost language that I know. But just because you might pick Python over C++ because it's a high-level language doesn't mean that Python can magically "adapt" better to varying user input. Nor is C++ worse at being dynamic, or more concrete, simply because it compiles to native code. Programming languages are not adaptable that way, because no language is sentient. The programmer still has to tell the language what to do in each situation the program might encounter. Building a dynamic, feedback-driven GUI has less to do with what language you choose and much more to do with your programming skill.

The rest of this is just semantics:

you don't want to be saddled with a language which requires you to think about every malloc()
I definitely wouldn't want malloc anywhere in a well-constructed GUI. But I might be wrong here.

to manipulate strings of characters as bytes
So use C++'s string class. As for C, well, you get used to it. It's really not that bad, if you know what you're doing. (I'd recommend against using C for GUI work, though.)

to set up event handler callback routines
I've never seen a GUI toolkit that doesn't use event handlers (although they may exist). Qt uses them, Tk uses them, GTK uses them, Swing and Awk use them, even Javascript uses them. You can't get much higher-level than that.

to call methods on layout-bag-grid-column junk
If you take the time to understand it (it's not hard, and there's plenty of documentation), container-based layouts work beautifully. Many high-level language GUI toolkits use them. Or you could use something like WinForms. To each his own.

You want to build up that layout graphically
Huh? You mean by drawing it out first? UML? Using one of those drag-and-drop GUI generators?

name the elements appropriately
That has absolutely nothing to do with what language you use.

Platform license. (1)

Anonymous Coward | more than 8 years ago | (#15861110)

"Trolltech provides the library in two licences - the free licence which mandates that the applications developed be released under GPL and a commercial non-free licence which allows one to develop closed source applications using Qt.""

Does the latter apply to Windows?

Re:Platform license. (4, Informative)

ardor (673957) | more than 8 years ago | (#15861167)

Sort of. The Windows version has the same license, but has no VisualC support - this is included in the commercial version only. The free one only supports MinGW.

How to get Qt to work with Visual C++ (2, Informative)

everphilski (877346) | more than 8 years ago | (#15861239)

It is possible ... and not too difficult instructions here [dyndns.org]

Re:Platform license. (0)

Anonymous Coward | more than 8 years ago | (#15861185)

> Trolltech provides the library in two licences -
> the free licence which mandates that the applications developed be released under GPL

Sorry but this is misinformation! The free license doesn't mandate applications released under the GPL but under an OPENSOURCE license.
This has been assured until Qt 4.1 by providing the library under two opensource licenses: QPL AND GPL.

> and a commercial non-free licence which allows one to develop closed source applications using Qt."

Since Qt 4 the 2 free licenses as well as the commercial license apply to X11 as well as native Windows.

Update for 4.2? (2, Informative)

Abby The Wonder Dog (993772) | more than 8 years ago | (#15861128)

It is too bad that this book couldn't have been based on version 4.2 coming out soon. There are some major new features in the upcoming release, most importantly (IMHO), QGraphicsView, the new canvas. http://doc.trolltech.com/4.2/qt4-2-intro.html [trolltech.com]

It also looks like they'll try to squeeze in some cool SVG related stuff. http://zrusin.blogspot.com/ [blogspot.com]

Man, Qt simply pwns GTK

Re:Update for 4.2? (-1, Troll)

swimmar132 (302744) | more than 8 years ago | (#15861498)

NO GTK IS BETTER THAN QT

Re:Update for 4.2? (1)

Almahtar (991773) | more than 8 years ago | (#15861875)

I was never a KDE fan - I always liked Gnome stuff better, until I programmed in Qt for a project at school. After working with Qt I got absolutely sold on it and KDE. I kind of wish that GTK was better than Qt because then I would use it on commercial products, but honestly I'd gladly pay the fee to use Qt.

Re:Update for 4.2? (1, Informative)

Anonymous Coward | more than 8 years ago | (#15861906)

"Man, Qt simply pwns GTK"

Yes, I agree, except for one thing. GTK has the nice feature of being able to switch input methods easily without having to install additional keyboard layouts or whatever. As someone who uses the transliterated Cyrillic input method frequently, I wish QT/KDE would add this.

Re:Update for 4.2? (0)

Anonymous Coward | more than 8 years ago | (#15862390)

Try to get themed icons in Qt. Or, for that matter, try to install any theme that doesn't come packaged with Qt (hint: you can't). You also can't set an SVG as an icon, or create resizable dialog windows.

Qt is easier to code with, but GTK+ is far more powerful.

Re:Update for 4.2? (1)

bhalo05 (865352) | more than 8 years ago | (#15862563)

I haven't looked into Qt themes, but regarding SVG...

>> The addition of a Scalable Vector Graphics (SVG) icon engine enables icons to be created from pictures in this vector graphics format.

http://doc.trolltech.com/4.2/qt4-2-intro.html [trolltech.com]

And of course, resizable dialog windows are possible in Qt since the dawn of time. Not only that, they work wonderfully. Trolltech has done quite a good job with its layout managers.

The truth is Qt 4 and specially Qt 4.2 are far, far ahead of GTK, like it or not.

Re:Update for 4.2? (0)

Anonymous Coward | more than 8 years ago | (#15863068)

And of course, resizable dialog windows are possible in Qt since the dawn of time. Not only that, they work wonderfully.


They do not work. A QDialog does not contain a central widget. You can't create a QDialog that will resize its contents - you must either code up your entire dialog from scratch using a window, or block the user from resizing the dialog so they don't realize what's really going on. Dialogs in general are handled badly in Qt - there ought to be a QWindow class, which has subclasses QMainWindow and QDialog.

By the way, you didn't respond to my theme statements. Gtk+ comes with a large variety of stock images [gnome.org] , which can be overridden by user themes at will. Almost every part of GTK+, from the colors to widget shapes, can be changed in user themes. Qt has no way to do either of these without linking in bloated external libraries [kde.org] .

Until Qt 4, there was no way to load .ui files at run time. This is a huge pain for those of us who must spend time in Qt 3 land, which is still the vast majority of the install base.

Qt still has no support for "recent documents", requiring the user to keep track of and build this list himself.

Qt has many good points. It's much easier to subclass a Qt class than a GTK+ class. There are no ugly GTK_HUGE_CLASS_NAME casts required in the code. But GTK+ has been, and remains, more capable than Qt for projects that need it.

Re:Update for 4.2? (1)

Mitchell Mebane (594797) | more than 8 years ago | (#15863104)

"They do not work. A QDialog does not contain a central widget. You can't create a QDialog that will resize its contents" You don't need a central widget. You just have to set a layout on the dialog. Actually, you have to do the same thing for a QMainWindow, too.

mysql-style licensing (0)

kpharmer (452893) | more than 8 years ago | (#15861150)

> Trolltech provides the library in two licences - the free licence which mandates that the applications developed be
> released under GPL and a commercial non-free licence which allows one to develop closed source applications using Qt.

So, I wonder if like MySQL people will always assume that it is free?

Re:mysql-style licensing (0)

Anonymous Coward | more than 8 years ago | (#15862338)

So, I wonder if like MySQL people will always assume that it is free?

That's why I don't use MySQL. I use PostgreSQL. Plus you get all of the features free and for free. Heck, you can use MS SQL Express edition, Oracle Express edition or DB2 (IBM) Express edition for free as well. Only MySQL cannot be used for free in commercial projects. But it is not a big deal thanks to PostgreSQL

subject (-1, Troll)

synx (29979) | more than 8 years ago | (#15861157)

This is exactly why I dropped Linux and went to OS X - the 4th major revision sports feature such as better basic-string handling (!!) and better programming APIs. What about overall user experience, look and feel, performance, desktop integration, printing, and so on. Things that real world people really care about. You know, those people, the USERS who are trying to accomplish tasks.

And this my friends is why Linux will never take over the desktop.

Of course, Unix already has taken over the desktop - it's called OS X.

Re:subject (0)

Anonymous Coward | more than 8 years ago | (#15861247)

Besides the fact that some of the things you have cited have been heavily focused on in qt development, it remains a developers tool; a toolkit if you would. Qt is not aimed at users, just like WinForms isn't.

Re:subject (1)

thsths (31372) | more than 8 years ago | (#15861297)

> This is exactly why I dropped Linux and went to OS X - the 4th major revision sports feature such as better basic-string handling (!!) and better programming APIs.What about overall user experience[?]

Qt is a toolkit, that means a tool for programmers. So it is only natural that is provides a better *programming* experience. If you want better user experience, you have to wait for an end user program. And I am sure that KDE 4 will deliver exactly that.

writing this from KDE4-WIN32 (0)

Anonymous Coward | more than 8 years ago | (#15861182)

I am writing this comment, using Qt4/KDE4 compiled natively for Windows.

With this build, you can use the KDE Desktop as the Windows Desktop.
The kconsoles have real scrollbars, history and resize.
You can't really tell that it is not Linux.

Oh wait..., I am using Linux.
Sorry. Let me reboot and see if I can run the unreleased windows build.

-ac

The free edition (2, Insightful)

ratta (760424) | more than 8 years ago | (#15861202)

does not require the application to be GPL, it requires it be open source (OSI), since the free edition is dually licensed GPL/QPL. The funny thing is that if Qt were QPL only, you could use almost all opensource licenses (eg. BSD) but not GPL, because the GPL require anythings you link with to be GPL compatible as well! So dual licensing is really necessary :)

Re:The free edition (1)

Almahtar (991773) | more than 8 years ago | (#15861895)

I thought your project had to be licensed under something GPL compatible. OpenSource.com has a few lists of GPL compatible licenses, btw. So that rules out BSD licensed projects using Qt, as far as I knew.

Re:The free edition (1)

fmoliveira (979051) | more than 8 years ago | (#15862768)

Its not proven in court that you cant dynamic link to anything. And copyright laws are not the same in every country anyway. Anyone big enough for trolltech to notice they exist and sue them would have no problem buying the license anyway.

The real problem is that, imagine trolltech stop licensing it, or if the distros just fork it. It would be rendered useless for commercial applications. If it were not for gnome it could be a major drawback for linux.

Qt is very nice. (1)

soft_guy (534437) | more than 8 years ago | (#15861226)

Aside from also being a very good cross platform library, Qt is also just a very nice programming API period. If you are just writing Windows applications, Qt is a pretty good choice. I highly recommend it. In fact, you are soaking in it now!

Re:Qt is very nice. (2, Informative)

Almahtar (991773) | more than 8 years ago | (#15861965)

In my senior design class my last year of college, the project was to build a Windows app that did X, Y, and Z - any extra features and polish were left to the students' imaginations. The 3 students that used Qt did substantially better than the others, and their stuff ran on Windows, Mac, and Linux. None of them reported having to change a single line of source code porting from one platform to the next. The 6 Java people didn't do as well as the .net people overall, but their stuff ran on Mac most of the time. They reported spending some time and effort to get the Mac version working. The 8 .NET people by and large got better ratings than the Java people as far as features, usability, and speed, but their stuff only ran on Windows. So while the populations weren't large enough for anything vastly conclusive, it is a tribute to Qt that the 3 students using it did noticeably better than the 14 others just on windows, but also ran on Mac and Linux.

Re:Qt is very nice. (1)

ragefan (267937) | more than 8 years ago | (#15862514)

The 6 Java people didn't do as well as the .net people overall, but their stuff ran on Mac most of the time. They reported spending some time and effort to get the Mac version working.

I call "Shenanigans" on this. I'm not a Java fanboy by any means but I would have to say that if they could not get it to run on Windows, Mac and Linux, then clearly they were not very good coders. The projects I did in Java for my programming classes ran on Windows and Linux with never a problem. My machines were Linux at home and Windows (sometimes dual-boot) at school and I constantly transported the project files back and forth and not once had an issue of running on one platform but not the other.

Re:Qt is very nice. (1)

Almahtar (991773) | more than 8 years ago | (#15862959)

I kid you not. First off, they had problems right off the bat loading large image files. There's some limit to the size of a jpg you can load in Java's standard libraries (at least with default settings), so most of them couldn't load say a 5000x5000 image. Not sure if any of them ever found a workaround for it. I watched 3 other students' final presentations: 2 used Java and 1 used VB.NET. One java guy chose java because he wanted to develop on his Mac and only use Windows machines for testing. He wasn't clear (wish I could give you details, but I don't know them) about what issues he ran into but during the last month or so of the project he ended up just staying on Windows machines because something broke badly enough (portability-wise) that it wasn't worth his time to figure it out. His version did not work on Mac anymore at the time of the presentation. He reported testing it in Linux using both the Sun VM and the free-as-in-speech VM and neither worked out for him. The other java guy didn't report the status of his program on any platform except Windows, so for all I know it could've worked flawlessly or it might just eat shit if you ran it on a Mac. No word on Linux either. Oh, and there were some pretty serious speed issues on his app, but he did implement some pretty fancy features... So yeah, sorry I don't have details about what exactly didn't work, but shenanigans it aint.

Re:Qt is very nice. (1)

thegrassyknowl (762218) | more than 8 years ago | (#15862522)

As someone who's used QT in it's non-free form, I can say that it is the bane of my existance. Trolltech do not provide licenses for a company. They provide developer-locked licenses.

If someone without a Qt license identifies a change in my code and I am off on a week of leave they are not legally allowed to make the change. Sure, they could log in as me, enter source control as me and do the work. But there is no way in hell I'm giving them my password so that screws all that up.

It also makes it hard as other users come along and want to develop plugin components for the application I am developing because they either need a license to Qt or they have to come to me every time they want to build.

The other things that bothers me is they sell different types of licenses - console and gui. With a mix and match of these licenses in the company it's a pain in the ass when someone with only the console license runs our build scripts (which build about a dozen gui/non-gui applications) and comes back to me when it fails and says "you are not licensed to use the GUI version of QT".

The framework itself is pretty good; I don't like the way it works, personally; I grew up on a wxWidgets style of programming which is somewhat different.

On that note, stick to wxWidgets. It's LGPL-derived license allows commercial or opensource development, and it's just as powerful.

Design flaws in QT? (4, Insightful)

Anonymous Coward | more than 8 years ago | (#15861264)

Has anyone using the QT API noticed that its behavior when it encounters an error isn't well-defined or easily detectable by the user of the library? For instance, look at QFileInfo's size member function [trolltech.com] .

Returns the file size in bytes, or 0 if the file does not exist or if the size is 0 or if the size cannot be fetched.


So, if it returns a zero, that could mean that there is a problem that your application may need to do something about or report, or the file does not exist, or the file exists but is zero bytes. How incredibly uninformative. But at least that member function documents its behavior it something bad happens. As I glanced through the other member functions, it became apparent that most of them do not bother to say what happens when the shit hits the fan. No return codes, no exceptions, no nothing.

Sadly, many of the classes in the library are like this. Sure, I could write an application using QT, but I wouldn't know how to handle failures simply because QT doesn't document the behavior in those cases. This is surprising, considering that QT is considered a quality library that is worthy of use in commercial applications. Granted, most of the time, we'll only execute the "happy path", and there will be no problems with this lack of documentation. However, we shouldn't throw caution to the wind and assume everything will be OK.

I can't help but think that this could have been avoided if QT would have embraced exceptions. Then, the API could avoid using C-like return codes and maintain its elegance but still report errors in a manner that is convenient for handling and documentation. QFileInfo::size() could be documented to throw QFileNotFoundException and QIOException, for example, making it easy for the user of the class to tell what happened. But they would have to rethink some of their code if they did this, because the naked-pointer-filled code that they have now would not be exception safe at all. I doubt that they will make the switch any time soon because everyone seems to be so happy with it the way it is today.

Re:Design flaws in QT? (2, Insightful)

Jerry (6400) | more than 8 years ago | (#15861655)

I've seen you post this question on QtCentre, too.

Use QFileInfo::isFile to determine if the file exists, then QFileInfo::size returns the file size in bytes, or 0 or if the size is 0 or if the size cannot be fetched.

What's so hard about that? You've never run into tri-states before?

Re:Design flaws in QT? (2, Insightful)

AuMatar (183847) | more than 8 years ago | (#15861808)

Returning a negative number for failure would have been better- you don't have to worry wether 0 means an empty file or an error, it would always mean an empty file, and < 0 would always mean an error. You could also then return different negative numbers for different error conditions. It may have a work around, but its a poor design.

Re:Design flaws in QT? (1)

kevin_conaway (585204) | more than 8 years ago | (#15862056)

Returning a negative number for failure would have been better- you don't have to worry wether 0 means an empty file or an error, it would always mean an empty file, and

If you're talking about C++, you should really be throwing an exception for errors (otherwise known as exceptional conditions). Return codes went out of style a long time ago and are considered poor design when you have alternatives

Re:Design flaws in QT? (1)

kevin_conaway (585204) | more than 8 years ago | (#15862076)

Returning a negative number for failure would have been better- you don't have to worry wether 0 ltmeans an empty file or an error, it would always mean an empty file, and < 0 would always mean an error. You could also then return different negative numbers for different error conditions. It may have a work around, but its a poor design.

If you're talking about C++, you should really be throwing an exception for errors (otherwise known as exceptional conditions). Return codes went out of style a long time ago and are considered poor design when you have alternatives

Re:Design flaws in QT? (1)

gnuman99 (746007) | more than 8 years ago | (#15862425)

Exceptions are bad for two reasons:
    * they are verbose - I don't want to write by try .. catch blocks all over the place.
    * they are used as a crutch

Anyway, this is not a design error. If you want to know what the size of a file is, first check that it exists, if it does, open it. Seek to the end and check your position. You are done. It is not a big deal.

Now I do use exceptions all the time in C++ and Ruby, I just don't want to have exceptions thrown by the library left and right and I have to handle all of them. I always see stuff in Java about unhandled exceptions. Exceptions thrown by libraries are good on paper, bad in practice. And no, Ruby exceptions are not the same as Java. I do not get an exception on non-critical failures (ie. can't open file, socket can't be allocated, etc.). I get exceptions for programming errors (bad input to functions, etc..). For everything else there are return objects. And this is how it should be.

So in summary, the function in question is not a design error in Qt. You can determine the souce of the failure with other calls.

Re:Design flaws in QT? (0)

Anonymous Coward | more than 8 years ago | (#15863035)

> Anyway, this is not a design error. If you want to know what the size of a file is, first check that it exists, if it does, open it. Seek to the end and check your position. You are done. It is not a big deal.

Wrong. This has a race condition: the file might be deleted, have its permissions changed, etc between when you execute the stat/existance check and when you open it. This will also fail on files where you don't have sufficient permissions to seek to the end. (Also, you should close the filehandle you opened, so you're not really 'done' despite the claim above).

In the particular example you give, you'd be better off using stat, which can tell you the file size, save you from the race condition, and save you from opening a file, seeking, and then closing it.

In general, trying to determine the cause of an error after it occured in an ad-hoc way is a doomed approach.

> Exceptions are bad for two reasons:
        * they are verbose
Exceptions are generally less verbose than explicitely checking return codes all the time. It's more verbose to write code that handles exceptions vs code that doesn't handle errors as indicated by return values, but that's hardly a fair comparison.

Re:Design flaws in QT? (0)

Anonymous Coward | more than 8 years ago | (#15863148)

In most good documentation that I've encountered for Java and C#, it usually says to use return codes for those sort of conditions that may be encountered but aren't really 'exceptional' - I'm on the fence whether problems in the opening of a file are really that exceptional. Certainly a problem while already having it open and reading it would be (except for EOF - always bizarre that the EOFException is used as a key part of lots of file reading in Java).

I will admit however that it can make code cleaner and easier to read to just use exceptions and avoid return codes altogether. I think it only really matters a lot to avoid exceptions if possible in code that's being executed often, in loops, etc.

Re:Design flaws in QT? (1)

whoop (194) | more than 8 years ago | (#15862317)

If only you could just have the source code to something like this, then you can "fix" it just how you like it. Ah well, just a dreamy afternoon for me...

Re:Design flaws in QT? (1, Informative)

Anonymous Coward | more than 8 years ago | (#15862636)

QFileInfo claims to (and appears to) use caching, so while "i.isFile();i.size()" looks like a race condition, it's really not, right?

But doesn't getting all the information about a file require more than one call? stat() will get you length and such, but not the value for readLink(), no? So isn't that still a race condition?

It's not at all obvious from the QFileInfo docs what is atomic, and when you're writing filesystem code that's kind of important.

(I've written large programs in Qt, and yes, they've made some rather, ah, "interesting" design decisions.)

Re:Design flaws in QT? (2, Informative)

bit01 (644603) | more than 8 years ago | (#15862675)

Use QFileInfo::isFile to determine if the file exists, then QFileInfo::size returns the file size in bytes, or 0 or if the size is 0 or if the size cannot be fetched.

This is buggy. It is a race condition. If the underlying file is deleted or renamed or is replaced by a named pipe in between those two calls the return from both calls is inconsistent.

This sort of error is unfortunately endemic in GUI code, not just qt, and is a large part of why GUI programs, are often flakey. GUI libraries usually have crappy kitchen sink API's that encourage bad programming practices; almost requiring numerous race conditions and potential security holes unless heroic programming efforts are made to avoid them. The kitchen sink API's are an attempt to improve productivity however a lot more care needs to go into their organisation to discourage bad programming practices, particularly race conditions. In this case they should've guaranteed the caching of all of QFileInfo so that all the information about the file is atomic, making race-free programming easier. Better, they should've had a handle to the file that guarantees that whatever operations are done on the file refer to the same file, including file operations outside of QFileInfo.

---

Don't be a programmer-bureaucrat; someone who substitutes marketing buzzwords and software bloat for verifiable improvements.

I know this maybe off topic (0)

Anonymous Coward | more than 8 years ago | (#15861368)

But are there any good books for GTK and libglade or am I behind the times? Also, I am not talking about gnome. I would like to stay out of the gnome api and just use gtk to build a small interface but I have never attempted this so I was looking for some pointers...

Qt: creating a larger commercial/libre wedge (1)

Anderlan (17286) | more than 8 years ago | (#15861382)

Trolltech provides the library in two licences - the free licence which mandates that the applications developed be released under GPL and a commercial non-free licence which allows one to develop closed source applications using Qt.

Does anybody know what the terms of the closed license actually are?

With LGPL'ed libraries (gtk, etc), I can make a program and flirt with selling it; that is, I guess, I can experiment with distributing something as shareware. With Qt, I might have to shell out something to Troll before I make the first penny, or at least I have to have a talk with them.

Wait a minute. Nevermind GTK. I don't even have to do that with Microsoft Windows libraries, either!! Also with GTK and Windows, I can go on past the shareware stage and sell the next big killer app and not pay anyone anything. (Well, MS will target me and destroy me on Windows, but I will have gotten farther without harrassment than I did with Qt.)

Re:Qt: creating a larger commercial/libre wedge (1)

Jerry (6400) | more than 8 years ago | (#15861705)

Does anybody know what the terms of the closed license actually are?


Our commercial license cost about $3,300 US for one developer and includes one year of email support and acess to the latest updates and releases at no charge. Which, I should add, is very good.
With that license you get connectivity to all the major databases, and a license to distribute binaries of your app for either Windows or Linux. In my experience QT is an excellent development library.

Re:Qt: creating a larger commercial/libre wedge (1)

Almahtar (991773) | more than 8 years ago | (#15862043)

I'd argue that it's improbable you'd write for windows and not spend a penny. Sure, you can develop .NET applications with nothing more than notepad and the command line, but it'd be a lot like building a 10 story card castle.

Re:Qt: creating a larger commercial/libre wedge (1)

Blakey Rat (99501) | more than 8 years ago | (#15862625)

The "Express" versions of the .net programming tools are free, and they are complete-enough to write full applications with. As far as I'm aware, there are no restrictions whatsoever on applications you write with (say) VB.net Express.

Now, the "Express" versions are missing some things, so you're correct in that developing with them would be harder than with the commercial versions, but it is certainly possible and a ton easier than Notepad.exe.

Your learning experience will not be a killer app (2, Insightful)

dbIII (701233) | more than 8 years ago | (#15863008)

Simple - you learn on the free version. If you are good enough you can then go commercial with a completely closed application and make money - but you have to feed the people who work at troll a bit too with some of this in the form of a licencing fee. If you are not sure it is good enough or you don't want to go through the hassle of convincing people to buy your stuff you release a completely open application. There is too much crap shareware in the world already - even if you write a gem how will people find it?

However, there may be some cut price licences out there for shareware or you probably can turn your software written on the GPL Qt into the commercial version if you have never released the software and you get a commercial licence. Perhaps look at their website - I've only looked at their GPL stuff.

gtk? (1)

edmicman (830206) | more than 8 years ago | (#15861402)

Not to stir anything up, but how does Qt compare to GTK? Could things like gaim or GIMP be redone in Qt (mostly gaim as I think GTK is a whole lot of the reason it takes up so much memory in Windows)? What kind of project would that be? Maybe I'll have to check it out and throw together a simple app or something.

Re:gtk? (1)

SirTalon42 (751509) | more than 8 years ago | (#15861651)

Of course. Skype is written in Qt (not sure if its Qt3 or Qt4 off the top of my head), Kopete is a KDE IM app similar to Gaim that is written using Qt/KDE, Psi is a Jabber client, I think GTalk is also written in Qt.

Lots of programs already use Qt (including Google Earth, and Opera).

Re:gtk? (1)

Dasher42 (514179) | more than 8 years ago | (#15861734)

It wouldn't be so eaasy to redo GAIM or Gimp in Qt. What you can do to force the essential features of GUI programming differs from what is considered good practice in C++. Besides, the Qt applications are often KDE-oriented, and it makes no sense not to leverage that framework when you can, and get a more consistent, interoperating environment. So, instead of rewrites, you have Kopete and Krita. Sometimes programming libraries get shared, as with Beagle, but that's about it.

I'm more of a C++ and Python guy, so I like what Qt has under the hood, but you're best off leaving programmers to use whatever they're most effective in, rather than try to tell them which is better.

Besides, I get a kick of using gtk_qt and making all my GTK apps draw with Qt without worrying about any inconsistency of themes. :)

Re:gtk? (1)

JabberWokky (19442) | more than 8 years ago | (#15862445)

You realize that Qt is far more than a GUI library, correct? It has database engines, multiprocess communication handlers and even fundimental components like a powerful string library. Non-GUI applications like daemons and CLI programs can use Qt.

--
Evan

Re:gtk? (1)

Dasher42 (514179) | more than 8 years ago | (#15862679)

Indeed I do. [slashdot.org] ;)

Re:gtk? (0)

Anonymous Coward | more than 8 years ago | (#15862227)

With the release of KDE4, kdelibs will be fully cross-platform. I expect that most core KDE programs will be recompiled for Win32, and the few Windows GTK programs will gradually fade away. In all likelihood, Kopete will fill the niche which Gaim does now. And no one uses The GIMP anyway. :P

(I don't mean to insult Gaim, of course -- Kopete itself is powered by the libgaim library. But as bad as GTK is on Linux, it's far worse on Windows... which is why no one in their right mind would write a GTK app for Windows when there's a far better alternative.)

Re:gtk? (1)

bcmm (768152) | more than 8 years ago | (#15862294)

Porting kdelibs doesn't really mean that all KDE apps can straight away be ported to Win32 because many of them depend on non-KDE libraries which may not be cross-platforum. The Amarok team, for example, have stated that they will not try to port Amarok, because Windows lacks the multimedia libraries that Amarok uses (imagine Amarok with WMP engine support *shudders*).

Re:gtk? (1)

Abby The Wonder Dog (993772) | more than 8 years ago | (#15862856)

Bad example. The Amarok guys stated very recently that they are going to do a port to Windows. Listen to Episode 151 of the Linux Links Tech show. One of the devs has to use Windows at work and wants to use Amarok while he is working :-)

http://tllts.org/archives/tllts_151-08-02-06.mp3 [tllts.org]

Qt for non-GUI apps (1)

Dasher42 (514179) | more than 8 years ago | (#15861412)

It's important to point out that the core libraries of Qt, with the signal/slot mechanisms and base containers and classes, are now decoupled from the GUI libraries. This is now a good general purpose thread-safe programming library. It strikes me that signals and slots supply the advantages of weak binding, much like in Objective C and Smalltalk, and you almost wish the language had had libraries like this all along.

I for my part am very interested in PyQt or some other approach of wrapping Qt into Python as such. This could make for some very rapid development, with Python prototyping and scripting, not to mention the way you can have either C++ or Python objects receive Qt signals. Has anyone experimented with this approach? Any comments on the overhead and ease of use?

Re:Qt for non-GUI apps (1)

Pseudonym (62607) | more than 8 years ago | (#15863217)

If this is what you want, you're better off using Boost [boost.org] than Qt. The GUI library is what makes Qt great. If you just want a foundation library for smart pointers, signals/slots, containers, threads and a bunch of stuff that it never occurred to you that you might need, Boost is far, far superior.

Not only is Boost exception-safe (which almost none of Qt is), but today's Boost library is tomorrow's C++ standard library. Boost prepares you for the future.

Qt in an Embedded (Non-Linux) Environment ? (0)

Anonymous Coward | more than 8 years ago | (#15861436)

Hi,

    Sorry for posting Anonymously, but I've always been more of a lurker.
    Hopefully someone will read this, think it's worthy of discussion, and mod it up.

    Anyway -

    As an embedded developer, I'm stuck with the OS that my company has historically used (AMX).
    We've used PEG for our UI work, thus far.

    I see this: http://www.trolltech.com/products/qtopia [trolltech.com] , but it seems very Linux-specific.

    I'd like to evaluate Qt for use in an embedded device, but I won't be able to run it on Linux.
    Is it portable? How difficult would it be to get it running on another (non-Windows) OS?

Thanks!

Re:Qt in an Embedded (Non-Linux) Environment ? (2, Funny)

Millenniumman (924859) | more than 8 years ago | (#15861748)

You'll have to enable the string parsing concatenation recompilation matrix kit, and possibly the array flattening engine libraries. If you want a GUI, you'll need to pass the build argument "QT_UNDECELERATE_FRAMEWORK". If your OS runs a non-57 bitrate clock register, you'll need to use type 874r function register matrix libraries. When you build you'll need to bypass kernel remapping protocol structures to endianize the unclock processor. Other than those steps, it shouldn't be too hard.

Re:Qt in an Embedded (Non-Linux) Environment ? (0)

Anonymous Coward | more than 8 years ago | (#15862751)

Thanks for the non-help, jackass. Anyone want to provide some real info?

Move over Qt (0)

Anonymous Coward | more than 8 years ago | (#15861680)

crosss-pltfrm MFC roolz !!!

Its too bad its not LGPL (1, Interesting)

DrDitto (962751) | more than 8 years ago | (#15862185)

The Linux desktop would be further along if QT were LGPL instead of GPL. Requiring a multi-thousand dollar license is fine for anything besides platform software, which is why QT can never be incorporated as a core Linux platform library (like glibc).

Case in point: I am at a university and we write software for research. We cannot release the source for various reasons, but we also do not sell the software and our goals are strictly academic. And I can't justify the license fee to the PI (principal investigator) given the alternatives. Heck, even Microsoft Visual Studio is substantially cheaper.

Flame away. I always get flamed for this argument.

Re:Its too bad its not LGPL (0)

Anonymous Coward | more than 8 years ago | (#15862291)

> Flame away. I always get flamed for this argument.

And rightfully so, as Trolltech has special license offers for universities.
Just contact Trolltech to find out more.

So... (1)

Pseudonym (62607) | more than 8 years ago | (#15862816)

So where's the chapter on exception safety? No, I didn't think so.

Qt does not play nice with C++. If all I want to write is a GUI, Qt is great. If I want to write a program with a GUI and other functionality that requires other C++ libraries, I'm stuck with a huge impedance mismatch.

"C++ GUI Programming with Qt 4" is a misleading title. You can either write a C++ program, or a Qt program. Not both.

Save $10.20 by buying the book here! (0)

Anonymous Coward | more than 8 years ago | (#15863265)

Save yourself $10.20 by buying the book here: C++ GUI Programming with Qt 4 [amazon.com] . And if you use the "secret" A9.com discount [amazon.com] , you can save an extra 1.57%! That's a total savings of $10.79, or 22.82%!
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?