Post a Comment
I actually like GTK. In my limited experience, in GTK, more typing is involved, but things make more sense and it's easier to get things right. In particular, I like how containers (that provide layouts) are widgets themselves, meaning that you can put a complex layout with multiple widgets in it anywhere that you could put a single widget. That's not true in Qt (at least, not without a little extra work): there, layouts are a separate entity from widgets. This bit me recently trying to create a push-button in Qt that could accommodate arbitrary child widgets and layouts: that's just there in GTK, but I had to sub-class QFrame in Qt and override the mouseReleaseEvent (which got the job done, save for the minor quibble that the result doesn't look like a normal QPushButton).
Having said that, Qt is probably a much easier toolkit to use, and C++ facilities are pretty handy for adding new functionality to widgets. It kinda makes me want to try gtkmm.
I think you may be misunderstanding something here. You can instantiate a QWidget (not subclass, just instantiate), set a layout on it, then add your child widgets there. The resulting QWidget can be used as you would use the layout object in Gtk, i.e. you can add it as a "single" widget to a place that accepts a single widget (e.g. another layout).
You can find 2 source snippets that do just this here:
http://qt.nokia.com/doc/4.6/layout.html#laying-out-widgets-in-code
Of course you could trivially create your QVBoxWidget that does what you want (i.e. avoid the single setLayout call), but I think you'll agree that it wouldn't really help things :-).
QWidgets are containers are widgets. The layout (given by setLayout) just specifies how they should be sorted inside the container.
I don't know if either way is better/worse than the other. I guess the Gtk way involves one moving part less, but the difference is negligible (i.e. I feel like we are bikeshedding here ;-).
Qt 3.x series did support widgets that were both containers and layouts. They dropped the design because developers were finding it confusing and unnecessary.
Normally you would insert a widget and set the layout inside that widget to get the behaviour you describe.
I'm curious why you wanted this? A huge button with arbitrary widgets inside? How would that even work if those widget should interact with input? Push buttons accept images and text, I don't think you should be putting other widgets inside one.
Heh, well, partly because we didn't want them to look like QPushButtons: we just wanted images you could click on, without the border or background-gradient. (So, when I complained that they "didn't look like QPushButtons," what I guess I should have said was, "most of QFrame's borders where too ugly to use.") Also, for whatever reason, when I used QPushButtons, they didn't size themselves properly (I think: they didn't show up, and my theory at the time was that they where requesting a zero size allocation, for some reason).
Stylesheets can come in handy for cases like this:
http://doc.trolltech.com/4.6/stylesheet-examples.html#customizing-q...
Man how I wanted an elegant desktop environment written in Qt. It's kind of sad liking Gnome but hating Gtk, and loving Qt and hating KDE mentality of "complex is good" or "if doesn't have 451 buttons it isn't good"
Darn. Couldn't have said it much better myself; I love how smooth the animations are in KDE and how much more advanced Qt feels compared to GTK+, but I just really hate how every KDE app includes a gazillion menu entries, buttons, layouts, heck, they seem to be stuffing the whole kitchen sink in there, too.
Oh well, this isn't a KDE thread though. Good thing to see Qt getting improvements, might be worth learning to use it myself too someday.
Darn. Couldn't have said it much better myself; I love how smooth the animations are in KDE and how much more advanced Qt feels compared to GTK+, but I just really hate how every KDE app includes a gazillion menu entries, buttons, layouts, heck, they seem to be stuffing the whole kitchen sink in there, too.
"i dont use this feature so nobody else should!"
on a related note, i just really hate how everyone stuffs the world with their children(aka you), which i cant use for anything.. please.. have them go away...
this is what you are saying, you do realize this?
"i dont use this feature so nobody else should!"
on a related note, i just really hate how everyone stuffs the world with their children(aka you), which i cant use for anything.. please.. have them go away...
this is what you are saying, you do realize this?
Nope, it's not. To copycat you, I could just as well state: "on a related note, i just really hate how no one ever has enough stuff with them all time time, i really need first aid kit, full toolbox, kitchen sink, vacuum cleaner, 12 different screwdrivers, canister of gasoline and a toolshed with me every time i do something as simple as drink coffee"
Exaggerating things is fun, isn't it? Oh, and it _clearly_ makes my post look mature and well-presented, doesn't it?
Point of philosophy here: I like to have a toolshed. It could well include a "first aid kit, full toolbox, kitchen sink, vacuum cleaner, 12 different screwdrivers and canister of gasoline".
If I want to drink a cup of coffee, I don't go into the toolshed to do so.
That does not mean that I don't want a toolshed at all. I'm not one to just drink coffee all the time.
The problem isn't just having a tool-shed or not, it's how well-organized the tool-shed is, and how easy it is to find the tool you want at any given time. It's fine to have lots of advanced and powerful features, but they need to be presented in such a way that the application remains easy to use in the likely-more-common simple use cases. Advanced features shouldn't be in the way.
That, I suppose, is my biggest problem with KDE. All that complexity might not be a bad thing in and of itself but. typically, I find that the abundance of options and features are not managed well, which can make it difficult to get into KDE (and KDE apps) and start using them for simple tasks. I really dread having to wade through four or five long, similarly-named option panels trying to find the one setting that I actually want; that happens to me a lot, when I try to use KDE.
Edited 2009-12-02 16:00 UTC
Darn. Couldn't have said it much better myself; I love how smooth the animations are in KDE and how much more advanced Qt feels compared to GTK+, but I just really hate how every KDE app includes a gazillion menu entries, buttons, layouts, heck, they seem to be stuffing the whole kitchen sink in there, too.
"i dont use this feature so nobody else should!"
on a related note, i just really hate how everyone stuffs the world with their children(aka you), which i cant use for anything.. please.. have them go away...
this is what you are saying, you do realize this? "
Oh yes, that's obviously what he is saying. What a remarkable non sequiter. What are you, twelve?
I think people on open source community should starting studying design.
http://www.smashingmagazine.com/2009/10/07/minimizing-complexity-in...
My (quite limited) experience with QML is that it's easier to get blingy UI's (with lots of animations etc), but for doing simple things just using Qt "normally" (C++/python, QWidgets, normal layouts...) is much easier.
This is because QML provides a lower level access to the dynamic state of the UI, whereas with the classical Qt style you can just slap an UI together with a Qt Designer. The UI won't be quite as appealing, though.
Of course we are still to see how the UI designer for QML will be like; it might be as easy as using Qt Designer currently is.
Not really. XAML is more like the classical .ui file format that is emitted by Qt Creator. QML files contain behavior as well as presentation.
You can basically write your whole UI-heavy program as a set of QML files (which can contain javascript), event handlers and all.
Check out
http://kenneth.christiansen.googlepages.com/DUI.html
The benefits of using Qt Creator (esp. autocomplete) are greatly diminished when writing Python (or other dynamic languages).
OTOH, I can see some real benefit of providing entry-level python support (syntax highlight, autoindent, source navigation and possibly scintilla level autocomplete) in Qt Creator. Qt Creator has a plugin system, it's probably just a matter of someone picking up the slack and starting to build the support (which should be possible for people outside Nokia as well).
Frankly, I think it's just a matter of time before it happens.
http://arstechnica.com/open-source/news/2009/12/qt-gets-cuter-46-br...
Community:
The more inclusive development model has succeeded in boosting involvement. Nokia says that Qt 4.6 is the first major release of the toolkit to include a significant amount of code contributed by the third-party developers. In a post made today at the official Qt blog, Nokia expressed appreciation to the community for the role it played in building the new version of the toolkit.
"When we opened Qt up for easier contributions back in May we were unsure what to expect. Would anyone care? Would anyone contribute?" wrote Qt spokesperson Aron Kozak. "Well we are extremely pleased to say that indeed you did contribute. We have received roughly 500 contributions for Qt and Qt Creator since we launched this initiative, and of those, around half made it into the 4.6 release."
Performance & QtScript:
Another exciting improvement for WebKit integration in 4.6 is the availability of a new DOM access API that is modeled after the popular JQuery library. You can use CSS selectors to iterate over nodes in an HTML document. A small but very nice addition is the new clearMemoryCaches method for the QWebSettings class, which will make it possible to mitigate the massive memory overhead that typically comes with using an HTML renderer in a desktop or mobile application.
AFAIK that's because of the default theme being more complex. Change to a minimal theme without gradients, pixmaps and effects and it should be as fast as Qt 3.
A much better option is to use NX instead of plain old remote X or VNC though. It's so much faster it's not even in the same league.
Well, bringing up an image chip from a 4MP camera, selecting some lines and point measurements results in saturating a gigabit connection for .5s or longer bursts (~40mb/s). Doing the same thing in a fltk program I get acceptable performamce over a 1/4 T1 line internet connection (only image navigation is slow,measuring is faster). QT's problem: excessive chatting chatting between the server and client because of all the QGraphicsView stuff. Note this is a also problem with windows remote terminal.
Running vnc (or rdesktop) does help with this because all the composting is done on the server only and screen updates are transferred.
The easy answer has been to not use Qt but any number of non over engineered toolkits. Comments from customers is that the non qt stuff feels amazingly faster. And build management is much easier.
. In addition, community support is available for the real-time operating systems QNX and VxWorks.
I am confused, what is that supposed to mean? Isn't VxWorks for embedded systems only? I am not aware of a VxWorks with a GUI. Excuse my ignorance but can someone please clarify this?.
Edited 2009-12-02 10:45 UTC
VxWorks can have a GUI. Not every VxWorks system will have one, but it's possible. IMHO it's a good move to have QT available to embedded systems.
Yes, you may not need to recompile QtRuby when changing to Qt 4.6, but it wouldn't do any harm. It would certainly be a good idea to regenerate and rebuild the smoke bindings libraries that QtRuby uses.
Well as KDE 4.4 depends on Qt 4.6, and so it means that in can actually be released :-)
As far as QtRuby is concerned, the big change for the KDE 4.4 release will be that the Smoke libraries will be generated with Arno Rehn's C++ based generator, instead of the perl one that previous releases used.
Also the Smoke libs for Qt 4.6 and the corresponding Ruby extensions will be split up so that there is one per Qt module - ie one qtcore, qtgui, qtnetwork etc instead of everything being in a single 'qtruby4' extension. That will mean if you only want to write a ruby app using QtCore stuff it won't pull in all the Gui classes.



