Re: qt vs gtk
Michael Torrie schrieb: > jvette...@users.sourceforge.net wrote: >> I find that deriving classes in C++ is alot easier than going through >> the GObject type system. > > Yes this is true, in C. GTKmm makes things rather nice if you work in > C++. In fact I kind of like how GTKmm works without a preprocessor, > with type-safe callbacks. I wish Qt folks would compare Qt against > GTKmm rather than just GTK+, as they are looking at things from a C++ > point of view anyway. > >> When it comes to documentation, Qt really outshines Gtk. I have never >> had to dive through code to figure something out in Qt. I always have a >> copy of the Gtk source code untarred and ready, though. > > GTK is always in need of people willing to flesh out the documentation. > It is nice that one can refer to the source code in any open source > project. Also to kill a myth: > head docs/reference/gtk/gtk-undocumented.txt 93% symbol docs coverage. 5397 symbols documented. 116 symbols incomplete. 406 not documented. Its not that bad. What imho is needed, is to move the docs inline (into the soruces), fill the gaps and extend them. Also the tutorial could be merged and then benefit from the xrefs (but it would need a general overhaul most probably before). Stefan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: qt vs gtk
jvette...@users.sourceforge.net wrote: > I find that deriving classes in C++ is alot easier than going through > the GObject type system. Yes this is true, in C. GTKmm makes things rather nice if you work in C++. In fact I kind of like how GTKmm works without a preprocessor, with type-safe callbacks. I wish Qt folks would compare Qt against GTKmm rather than just GTK+, as they are looking at things from a C++ point of view anyway. > When it comes to documentation, Qt really outshines Gtk. I have never > had to dive through code to figure something out in Qt. I always have a > copy of the Gtk source code untarred and ready, though. GTK is always in need of people willing to flesh out the documentation. It is nice that one can refer to the source code in any open source project. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: qt vs gtk
Some of my thoughts on the matter: On Wed, Jan 14, 2009 at 10:10:42AM -0600, Thomas Stover wrote: > ... > -QT (last time I checked) is not even C++. It's C++ and a custom macro > language. building ouch. debugging ouch. C++ paradigm ouch. The Qt macros aren't very intrusive. Once you have your makefiles figured out, it's not building is not terribly painful, for either one. "Figuring out the makefiles" means automating moc for Qt, and glib-genmarshal for Gtk. I agree 100% that debugging with gdb is much easier for C than C++. I find that deriving classes in C++ is alot easier than going through the GObject type system. > -HUGE: glib and gtk are separate. glib can be used on it's own. so one > mental model to work with for gui and non-gui events. Qt4 has been split into different modules -- QtCore (think glib), QtGui (think Gtk), QtXml, etc. > -When you start getting into it, there is just no contest. I love GTK. I > have no doubt that if I started to read about qt, that I would > constantly be saying, "oh you can't do that", and "you mean you have to > that". Long live GTK! When it comes to documentation, Qt really outshines Gtk. I have never had to dive through code to figure something out in Qt. I always have a copy of the Gtk source code untarred and ready, though. JV ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: qt vs gtk
On Wed, Jan 14, 2009 at 6:05 PM, Jack wrote: > I believe the original question was gkt+ vs qt. I don't believe there was a question And this is all fairly offtopic for this list. So lets stop it now before it gets silly. iain ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: qt vs gtk
This is a whole different issue - Gnome vs KDE vs other desktops. I believe the original question was gkt+ vs qt. I use a number of gtk based apps on a KDE based desktop. (Isn't KDE based on QT? It shows how long it's been since I paid attention at that level.) There have been some interesting issues, but it is certainly possible. (See my other post on problems parsing rc files.) From: "Andersen, Jan" To: gtk-app-devel-list@gnome.org Sent: Wednesday, January 14, 2009 12:22:47 PM Subject: RE: qt vs gtk As someone who has recently stopped using GNOME, let me give my viewpoint, then, about why I have stopped using it. It isn't so much knee-jerk, I would hope, as simple, everyday usefulness. It was not an easy decision for me to leave and start using KDE - I have used GNOME from the beginning and preferred it over KDE. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: qt vs gtk
Andersen, Jan wrote: > 1. X used to display a small "label" containing the position and size > of a window when you moved it. That was one feature I found hugely > useful; I usually have 9 desktops and organise my applications with > fixed dimensions and positions different desktops - like Pidgin on > desk 1, thunderbird and firefox on desk 2, a number of xterms on desk > 3 etc, all started from scripts with positions and dimensions that I > have taken from the little "dimension label". I can't do that in > GNOME and find the right position and dimension takes a large amount > of trial and error. Not a huge thing, really, but why take it away? > > 2. All of a sudden, in the latest version of GNOME, you get a silly > warning about not logging on as root. Now one may dispute the wisdom > of working that way, but that is the way I work. I have considered > the implications and secured things in other ways, let's put it like > that; at the end of the day this is MY MACHINE and there MY DECISION > to make. One of the basic tenets in good software is that you don't > impose policy of any kind on your users. You provide options, you may > provide a selection of preset parameters that suggest a sensible > policy, but at the end of the day it is up to the owner of the > system. That is the way KDE does it - by default root is not allowed > to log on to the desktop, but there is a parameter. In GNOME I found > that it is hardcoded into gnome-session. I mean, show some respect > for your customers - we have already proven that we are intelligent > and thinking individuals by chosing Linux over Windows, haven't we? These are interesting as they illustrate that to a user, Gnome is the experience. Of course we know that in reality, things like positioning of the windows as they move and resize have absolutely nothing to do with Gnome. But perception is reality as they say. As for item 2, my biggest gripe with Gnome is that some distros use gtksu and others use a "sudo" like approach that mirrors OS X (ubuntu) for doing things that require root. Of course all of this is going away soon now that PolicyKit is hitting mainstream. This means root access simply isn't needed anymore for almost all desktop-originated actions. Now of course this is all off-topic since we're talking about "qt vs gtk" not gnome or even KDE. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: qt vs gtk
As someone who has recently stopped using GNOME, let me give my viewpoint, then, about why I have stopped using it. It isn't so much knee-jerk, I would hope, as simple, everyday usefulness. It was not an easy decision for me to leave and start using KDE - I have used GNOME from the beginning and preferred it over KDE. With any tool that provides as much functionality as a desktop, there will inevitably be a number of irritating issues; this is true for KDE as well. But I think what really did it for me, in the end, was the trend towards oversimplification - and what I feel is the complete lack of will to heed any call for change that I sense from the developers. In my view nothing would be lost to the GNOME community by not cutting away features that are actually useful to some users. The default values could still be set to "simple", the parameter file could even be well hidden if need be. And don't try to tell me that it is beyond the capabilities of the GNOME developers to make things this way; it wouldn't even make it harder to program or maintain, on the contrary, parametrising things generally makes it easier in my experience (25+ years). So it comes down to philosophy, if that is the right word, or choice - a conscious choice has been made to do it this way despite what a number of the expert users have had to say. So where is this trend going to stop? Nobody has been willing to say - in principle it could go all the way to where we have a system that goes squeek when you push the big plastic flower and can speak baby babble. A couple of examples of what I mean - they are not big, overwhelming issues, but small irritations that I remember because I have found KDE gives me what I wish in this respect: 1. X used to display a small "label" containing the position and size of a window when you moved it. That was one feature I found hugely useful; I usually have 9 desktops and organise my applications with fixed dimensions and positions different desktops - like Pidgin on desk 1, thunderbird and firefox on desk 2, a number of xterms on desk 3 etc, all started from scripts with positions and dimensions that I have taken from the little "dimension label". I can't do that in GNOME and find the right position and dimension takes a large amount of trial and error. Not a huge thing, really, but why take it away? 2. All of a sudden, in the latest version of GNOME, you get a silly warning about not logging on as root. Now one may dispute the wisdom of working that way, but that is the way I work. I have considered the implications and secured things in other ways, let's put it like that; at the end of the day this is MY MACHINE and there MY DECISION to make. One of the basic tenets in good software is that you don't impose policy of any kind on your users. You provide options, you may provide a selection of preset parameters that suggest a sensible policy, but at the end of the day it is up to the owner of the system. That is the way KDE does it - by default root is not allowed to log on to the desktop, but there is a parameter. In GNOME I found that it is hardcoded into gnome-session. I mean, show some respect for your customers - we have already proven that we are intelligent and thinking individuals by chosing Linux over Windows, haven't we? And so on - these far from the only gripes I have had over GNOME over the years. On their own these two wouldn't have made me change, but it all adds up. I think it is important that my tools don't work against me; GNOME did, KDE doesn't. -Original Message- From: gtk-app-devel-list-boun...@gnome.org on behalf of Thomas Stover Sent: Wed 14-Jan-09 16:10 To: gtk-app-devel-list@gnome.org Subject: qt vs gtk With the recent news that Nokia will be releasing QT under LGPL, I'm seeing allot of knee-jerk anti-GTK comments out there. I know I'm preaching to the choir on this list, but for the sake of moral I thought I would post my 2 cents on the matter. -I can't think of single QT application I even use. (although I admit I don't look for them) -Without getting into a C vs C++ debate, being able to use GTK straight from C really is the whole universe right there. Try returning GUI objects from dynamically loadable modules without C. In general, C libraries mix together far better than C++ ones. I use GTK together with all kinds of stuff. I'm younger and learned C++ in school. I had to unlearn the damage. The guys I know that still believe C++ always have this mental model that every library needs to be wrapped in some sort of all-encompassing toolkit, or you can't use it. -QT (last time I checked) is not even C++. It's C++ and a custom macro language. building ouch. debugging ouch. C++ paradigm ouch. -HUGE: glib and gtk are separate. glib can be used on it's own. so one mental model to work with for gui and non-gui events. -When you start getting into it, there is just no contest. I love GTK. I have n