I guess we can't give it the "slowest toolkit on Linux" award. Now to come up with a new award will be challenging, but I'm sure the GTK+ team hasn't forgotten the Slashdot whiners,
Re:QT GTK
by
Anonymous Coward
·
· Score: 0, Flamebait
Ah, but QT is not 'truely free', so GTK has it beat, unless you don't care about GPL!
Re:A lot of stuff in Gtk is replacing Gnome widget
by
ari_j
·
· Score: 0, Flamebait
Sir, it is truly morons like you that give Slashdot a bad name. That you post anonymously only does a disservice to more intelligent and insightful GNFOS trolls who use that name. If you have a point to make, I'm waiting for it, but you'll really need to make it both coherently and logically, because thus far you have done little but pretend you know that which you must not.
I've written more millions of lines of code than you have lived years on this earth. I did general-purpose distributed computing before it was cool. I wrote a Lisp interpreter in 6 hours. In short, I know a thing or two about writing code.
And you, sir, are wrong. Gnome and KDE are desktop environments. That they include thousands of googaws that make building applications easier is a disadvantage, and it's just that disadvantage that moving such googaws into the appropriate location, such as the upstream widget toolkit (in this case, Gtk+) can alleviate.
Right now, to get even one googaw or trinket out of Gnome for use in an application (the GtkHTML widget comes to mind as a past example of this, but as I haven't done any GUI development in several yearsI won't specify precisely which widget I am presently referring to), you end up installing the entirety of the Gnome libraries in an effort to ensure you meet the dependencies. Oftentimes, application programmers don't even know what their applications depend upon to build and/or run.
The disadvantage is that the line between widget toolkit and desktop is blurred and was blurred from shortly after the beginning of it all. Gtk+ and glib are a good example of two libraries with a unidirectional dependency and fine line of separation. If it's part of the graphical toolkit, it is in Gtk+. If it is a data structure or other non-graphical widget, it's in glib.
With Gtk+ versus libgnome*, though, the line is blurred. So many different libraries provide graphical widgets at the exact same level as Gtk+ provides them that an application developer often must choose between omitting functionality made possible by the Gnome widgets, implementing his own widgets to replace them, and writing code that depends upon higher-level Gnome libraries than it needs to.
If all the widgets were either consolidated into Gtk+ (as is the current trend) or consolidated instead into separate libraries with very well-defined territories, then application developers could get away from the type of bloat that is most annoying to many users: dependency bloat. There is nothing more obnoxious than finding a new piece of software (take, for example, mail-notification the project) and finding out that you have to install an entire desktop environment (here, Gnome) because it provides some minuscule piece of code that it depends upon.
The Gnome libraries could be rededicated to providing a functional and useful desktop environment and high-level IPC, and the applications that do not need those features could do just fine depending only upon specific libraries from a set of granular, well-defined libraries.
GTK+ is the only 100% free-of-cost open source industrial-strength GUI toolkit available today.
I'm suprised the gtk release notes actually say this, because it's fairly obviously false. It's a shame those reponsible didn't catch this and expunge the statement.
(I see www.gtk.org's "Introduction" section does not share this problem.)
You're right. QT is under the GPL and that really isn't `truly free'.
--
-If God wanted people to be better than me, he would have made them that way.
Re:A lot of stuff in Gtk is replacing Gnome widget
by
ari_j
·
· Score: 0, Flamebait
You certainly are dedicated to being an idiot. Somehow you've managed to agree with most of what I said without even realizing it, because your reading comprehension level is so low that you couldn't be bothered to figure out what I was saying. For example, you claim that I said 40 modularized dependencies of 1MB each is bad, which is not the case at all. Re-read what I said, but this time read each word and look it up in a dictionary if you have difficulty understanding it.
Why do you post anonymously? Did you have trouble understanding the account sign-up procedure, or are you just that certain that nobody likes you and the only way you can post at a non-negative initial score is by not having an account?
QT ist simply the better API, and the GUI it creates is much more flexible and convenient. The file selection dialog is a very good example: the file chooser in GTK is close to unusable, and makes me want to hit the developers whenever i am forced to use it (no, i have not yet tried the noew one). KDE's file selector is very nice and uses the same components as Konqueror does. The same thing is true for almost all the GUI components, including menus.
-- I have discovered a truly remarkable sig which this 120 chars is too small to contain.
Slashdot Mirror
I guess we can't give it the "slowest toolkit on Linux" award. Now to come up with a new award will be challenging, but I'm sure the GTK+ team hasn't forgotten the Slashdot whiners,
Ah, but QT is not 'truely free', so GTK has it beat, unless you don't care about GPL!
Sir, it is truly morons like you that give Slashdot a bad name. That you post anonymously only does a disservice to more intelligent and insightful GNFOS trolls who use that name. If you have a point to make, I'm waiting for it, but you'll really need to make it both coherently and logically, because thus far you have done little but pretend you know that which you must not.
I've written more millions of lines of code than you have lived years on this earth. I did general-purpose distributed computing before it was cool. I wrote a Lisp interpreter in 6 hours. In short, I know a thing or two about writing code.
And you, sir, are wrong. Gnome and KDE are desktop environments. That they include thousands of googaws that make building applications easier is a disadvantage, and it's just that disadvantage that moving such googaws into the appropriate location, such as the upstream widget toolkit (in this case, Gtk+) can alleviate.
Right now, to get even one googaw or trinket out of Gnome for use in an application (the GtkHTML widget comes to mind as a past example of this, but as I haven't done any GUI development in several yearsI won't specify precisely which widget I am presently referring to), you end up installing the entirety of the Gnome libraries in an effort to ensure you meet the dependencies. Oftentimes, application programmers don't even know what their applications depend upon to build and/or run.
The disadvantage is that the line between widget toolkit and desktop is blurred and was blurred from shortly after the beginning of it all. Gtk+ and glib are a good example of two libraries with a unidirectional dependency and fine line of separation. If it's part of the graphical toolkit, it is in Gtk+. If it is a data structure or other non-graphical widget, it's in glib.
With Gtk+ versus libgnome*, though, the line is blurred. So many different libraries provide graphical widgets at the exact same level as Gtk+ provides them that an application developer often must choose between omitting functionality made possible by the Gnome widgets, implementing his own widgets to replace them, and writing code that depends upon higher-level Gnome libraries than it needs to.
If all the widgets were either consolidated into Gtk+ (as is the current trend) or consolidated instead into separate libraries with very well-defined territories, then application developers could get away from the type of bloat that is most annoying to many users: dependency bloat. There is nothing more obnoxious than finding a new piece of software (take, for example, mail-notification the project) and finding out that you have to install an entire desktop environment (here, Gnome) because it provides some minuscule piece of code that it depends upon.
The Gnome libraries could be rededicated to providing a functional and useful desktop environment and high-level IPC, and the applications that do not need those features could do just fine depending only upon specific libraries from a set of granular, well-defined libraries.
I'm suprised the gtk release notes actually say this, because it's fairly obviously false. It's a shame those reponsible didn't catch this and expunge the statement.
(I see www.gtk.org's "Introduction" section does not share this problem.)
You're right. QT is under the GPL and that really isn't `truly free'.
-If God wanted people to be better than me, he would have made them that way.
You certainly are dedicated to being an idiot. Somehow you've managed to agree with most of what I said without even realizing it, because your reading comprehension level is so low that you couldn't be bothered to figure out what I was saying. For example, you claim that I said 40 modularized dependencies of 1MB each is bad, which is not the case at all. Re-read what I said, but this time read each word and look it up in a dictionary if you have difficulty understanding it.
Why do you post anonymously? Did you have trouble understanding the account sign-up procedure, or are you just that certain that nobody likes you and the only way you can post at a non-negative initial score is by not having an account?
QT ist simply the better API, and the GUI it creates is much more flexible and convenient. The file selection dialog is a very good example: the file chooser in GTK is close to unusable, and makes me want to hit the developers whenever i am forced to use it (no, i have not yet tried the noew one). KDE's file selector is very nice and uses the same components as Konqueror does. The same thing is true for almost all the GUI components, including menus.
I have discovered a truly remarkable sig which this 120 chars is too small to contain.