PDA

View Full Version : Qt vs. GTK+



grim918
March 3rd, 2006, 03:29 AM
I was wondering which one of this would be easier to learn. From what I have read Qt is used on KDE and GTK is used for GNOME. I have also read that Qt is based on C++ and that GTK uses mostly C. Which one would be easier to learn for a first time GUI programmer.

LordHunter317
March 3rd, 2006, 03:32 AM
Qt. GTK is mired by it's language choice and GTKMM can't get around that.

gord
March 3rd, 2006, 03:40 AM
i stick to WxWidgets, being restircted to one gui isn't great for a lot of programs. even if you can get qt and gtk for windows n mac n stuff.

moberry
March 3rd, 2006, 04:12 AM
Several things to consider, let’s look at the pros and cons.

QT Pros:

Written in C++ (Object orientation is significantly easier in C++ due to classes)


QT Cons:
Not GPL, QT is made by a commercial company called Trolltech. This is not necessarily a bad thing, it is only undesirable if you choose to market your work (License agreement states you must pay Trolltech royalties for “using” their software)

GTK Pros:
Released under the LGPL license, meaning you can market your software without paying the GTK crew royalties. GTK is also ported to windows meaning you can,with very little editing make soure software work in the Microsoft world also. QT might be ported, but I dont think it is.

GTK Cons:

Written in C, pain in the ***… nuff said. By they way.. in GTK every other statement is a typecast unless you “cast it globally” in the first lines of the function.

I personally use GTK I have always preferred C. There are some C++ wrappers for GTK, called gtkmm. But I have never used them. To answer your question, forthe first time programmer... Both API's extensively use pointers, and you must keep track of your memory pretty carefully (deleting old pointers, freeing data, etc). So as far as learning curve, they are similar. QT will make more sense because of its c++ language choice. GTK uses some "hacked" ways of doing things. E.g. piggybacking data onto objects, etc.

I hope this helps.

engla
March 3rd, 2006, 04:18 AM
You can also learn PyGTK first, that's what I am doing.

It's a python binding for GTK, so it's object-oriented and on a very high level; python is a nicer/easier language than c++. You can still do mostly anything in pygtk and the smallest working program is very small, so it should be a good fit for a learner.

I can post examples if you want.

doclivingston
March 3rd, 2006, 04:32 AM
Not GPL, QT is made by a commercial company called Trolltech. This is not necessarily a bad thing, it is only undesirable if you choose to market your work (License agreement states you must pay Trolltech royalties for “using” their software)

QT is double licenced GPL/commercial. If your software is released under the GPL, you don't have to buy a licence.


GTK is also ported to windows meaning you can,with very little editing make soure software work in the Microsoft world also. QT might be ported, but I dont think it is.

QT work under Windows.



Written in C, pain in the ***… nuff said. By they way.. in GTK every other statement is a typecast unless you “cast it globally” in the first lines of the function.

Or you use GTK from a non-C language; Python, C++ and Mono (C#) are the big ones, but there are also binding for perl and others. I'm not sure if there are non-C++ bindings for QT.



GTK uses some "hacked" ways of doing things. E.g. piggybacking data onto objects, etc.

You mean qdata? You shouldn't really need to use that very often, and the places where you do, you need a "hacky" solution anyway.

LordHunter317
March 3rd, 2006, 04:33 AM
QT Cons:
Not GPL, QT is made by a commercial company called Trolltech.It's been GPLd for ages, for UNIX anyway.

LordHunter317
March 3rd, 2006, 04:34 AM
Or you use GTK from a non-C language; Python, C++ and Mono (C#) are the big ones, but there are also binding for perl and others. I'm not sure if there are non-C++ bindings for QT.And as I said, none of them truly get away from some of the limitations that GTK and GLIB bring to the table as being originally written in C.

moberry
March 3rd, 2006, 04:37 AM
You mean qdata? You shouldn't really need to use that very often, and the places where you do, you need a "hacky" solution anyway

I was refering to "g_object_set_data(GObject, const char* key,gpointer data)" I use it quite often to keep track of indexes in linked lists, etc.

It is not hacky at all from a C standpoint (quite normal) but from someone used to JAVA, or C#, it is quite hacky.

I could easily be mistaken about the KDE license. I got my new issue of Linux Journal the other day, and there was a column about that. KDE is free to use. But if you decide to charge for your software, things get complicated.

doclivingston
March 3rd, 2006, 04:53 AM
I was refering to "g_object_set_data(GObject, const char* key,gpointer data)" I use it quite often to keep track of indexes in linked lists, etc.

It is not hacky at all from a C standpoint (quite normal) but from someone used to JAVA, or C#, it is quite hacky.

What would you do in Java/C#, use a map? In most situations you can use a GHashTable (which is a map).

There are situations where you can't use a GHashTable to do the mapping, but those are also sticky in pretty much any language.

doclivingston
March 3rd, 2006, 04:59 AM
And as I said, none of them truly get away from some of the limitations that GTK and GLIB bring to the table as being originally written in C.

Yes, GTK has warts and limitation because it is written in C. QT has warts and limitations because it was written in C++. Which are bigger depends on the language you want to use, and both have some issues when beng used from their non-native language.

If you want to program in C++, then QT is probably best. If you want program in C, then GTK is the way to go. For other languages it varies depending on which warts you want to live with.

moberry
March 3rd, 2006, 05:07 AM
BTW. Im not arguing, in case you thought i was being difficult.

I did not want to use a hashtable the last time I did this because that would have involved another traversal of the LL. While storing the pointer to the node didnt.

although.. on a 3ghz processor, probably doesnt matter.

LordHunter317
March 3rd, 2006, 05:11 AM
I was refering to "g_object_set_data(GObject, const char* key,gpointer data)" I use it quite often to keep track of indexes in linked lists, etc.How can you be doing such a thing in the first place? A linked list doesn't have an index. They don't support such notations, except through artificial constraints.

moberry
March 3rd, 2006, 05:16 AM
Well, there is a way to access the data at an index using glib.. g_list_nth.

But that is bad to use because it traverses the list on every call. It is an abstract structure, but it is a list, and lists have numbered elements. I suppose i could have implemented it a totally different way, hashtables as you said. But i chose to use a list. and storing the pointer to a specific node is a pretty efficient way of doing something. Just as efficient as a hashtable.

doclivingston
March 3rd, 2006, 05:20 AM
I did not want to use a hashtable the last time I did this because that would have involved another traversal of the LL. While storing the pointer to the node didnt.

I understand that it can be easier to use qdata. I was just saying that you probably would have done it with a map in Java/C#/whatever, and you could do the same with glib.


(Using qdata is storing it in a hashtable anyway, since it's implemented with one. It's probably less efficient to use qdata than your own hash table, since there is a hash table per-object and one will have to be created for each object if the objects didn't already have any qdata).

moberry
March 3rd, 2006, 05:22 AM
I understand that it can be easier to use qdata. I was just saying that you probably would have done it with a map in Java/C#/whatever, and you could do the same with glib.


(Using qdata is storing it in a hashtable anyway, since it's implemented with one. It's probably less efficient to use qdata than your own hash table, since there is a hash table per-object and one will have to be created for each object if the objects didn't already have any qdata).


Keep in mind this conversation got started recommending QT, or GTK :-)

BTW, I saw you were using dapper on your side bar. Is that running nicely yet?

LordHunter317
March 3rd, 2006, 05:44 AM
Well, there is a way to access the data at an index using glib.. g_list_nth.And that is a linked list? If so, as I said, it's an artifical constraint on their implementation of a linked list.

Linked list don't support indexed lookup. How does that work on a circular linked list, for example?


It is an abstract structure, but it is a list, and lists have numbered elements.Some forms of lists, like arrays, do. Linked lists don not.


But i chose to use a list. and storing the pointer to a specific node is a pretty efficient way of doing something.Which isn't storing an index.

moberry
March 3rd, 2006, 06:06 AM
If I were to implement the linked list like it was designed in the 50's, every time I needed data out of it I would have to start at the head, and work my way down until I found what I needed. My program stores the position in the list the I need for a certain type of data. Other functions in the program do traverse the list, as it was intended. There is nothing wrong with implenting an "index like" system in a linked list. It extends the capabilities for which it was originally intended for. Your right linked lists do not have the C definition for an index. But it is a list, and lists, at least in theory have numbers for where they are in the list. Even if the numbers dont actually exist. But I agree, index was a bad word to use.

Circular linked lists can be thought of in this same manner, the only advantage of a circ. linked list is if you are closer to the end than the start, its quicker to just loop around, then traverse up. In some cases.

Single
March 3rd, 2006, 10:12 AM
It's been GPLd for ages, for UNIX anyway.

Qt4 Open Source edition supports Windows, Macs and X11.

LordHunter317
March 3rd, 2006, 04:24 PM
If I were to implement the linked list like it was designed in the 50's, every time I needed data out of it I would have to start at the head, and work my way down until I found what I needed.No, you wouldn't. You'd do the O(n) lookup once, and cache a pointer to the node you're looking for, just like you're doing now. Linked lists have always been used by that.


My program stores the position in the list the I need for a certain type of data.No, that's impossible. Linked lists don't support indexed look up. You might be storing a pointer to the node itself, but that's different, consider an array:
[ 4, 3, 2, 1]
The item at index 0 is 4. In C or C++, I can either store the base of the array and the index (0), or I could store a pointer to the value itself (4). With a linked list, you can only do the latter (ignoring artifical imposed constraints, like I said above).


There is nothing wrong with implenting an "index like" system in a linked list.Yes, there is. It artifically constrains your list: circular lists are now impossible, it forces you to retain a pointer to the same "start" node everwhere, and indexed lookup still requires O(n).

If you need indexed lookup, you use an array or some sort of map.


It extends the capabilities for which it was originally intended for.No, it wrecks them.


Your right linked lists do not have the C definition for an index.Show me one datastructures book that defines the structure of a linked list supporting indexed lookup. None do because it both artifically constrains the real definition and because it simply makes no sense.


But it is a list, and lists, at least in theory have numbers for where they are in the list.No, that's not true in the least. A set is a list, and by definition, a set has no ordering. As such, you cannot provide a deterministic index on a list.


Circular linked lists can be thought of in this same manner,No, they cannot. How do I define start? How do I define end?


the only advantage of a circ. linked list is if you are closer to the end than the start,They have neither. Draw a circle on paper. Now, point to me the start and finish.

raedbenz
July 17th, 2010, 09:08 AM
This is a topic we could keep talking about it infinitely.
My personal experience: at some point I wanted to learn a programming GUI library, and at that time i chose GTK because it uses C because i am coming from embedded background. later on i had the chance to tackle Qt and as a result improved my c++ skills.
in summary if you know only C use GTK, if you are confident in C++ only use QT if you know both of them or wish to learn C++ then QT.
Qt is superior in support and tools.

slavik
July 17th, 2010, 09:39 AM
the true way to decide: flip a coin

nvteighen
July 17th, 2010, 11:15 AM
the true way to decide: flip a coin

But people will insist in searching other ways, dear slavik...

Really, there's almost no difference these days... not even the "I want to use C++" argument because gtkmm is perfect. Maybe the differences are in the tools (QtDesigner, Glade, etc.) rather than in the libraries themselves.

splicerr
July 17th, 2010, 01:17 PM
This is a topic we could keep talking about it infinitely.
My personal experience: at some point I wanted to learn a programming GUI library, and at that time i chose GTK because it uses C because i am coming from embedded background. later on i had the chance to tackle Qt and as a result improved my c++ skills.
in summary if you know only C use GTK, if you are confident in C++ only use QT if you know both of them or wish to learn C++ then QT.
Qt is superior in support and tools.

Well, there are many people who prefer to use a higher language to code their GUI. And no not everybody considers C++ to be a high-level language.

SledgeHammer_999
July 17th, 2010, 01:35 PM
This is a topic we could keep talking about it infinitely.
My personal experience: at some point I wanted to learn a programming GUI library, and at that time i chose GTK because it uses C because i am coming from embedded background. later on i had the chance to tackle Qt and as a result improved my c++ skills.
in summary if you know only C use GTK, if you are confident in C++ only use QT if you know both of them or wish to learn C++ then QT.
Qt is superior in support and tools.

Don't forget you could use C++ with Gtk+(Gtkmm (www.gtkmm.org))


the true way to decide: flip a coin
+1

slavik
July 17th, 2010, 06:57 PM
But people will insist in searching other ways, dear slavik...

Really, there's almost no difference these days... not even the "I want to use C++" argument because gtkmm is perfect. Maybe the differences are in the tools (QtDesigner, Glade, etc.) rather than in the libraries themselves.
I solve problems, if they are looking for problems to not solve, that is their problem. :)

ravi.xolve
August 20th, 2010, 05:01 AM
Both are mature frameworks, however Qt looks good because its in C++. Now Qt is being pushed as de facto API for Nokia devices which makes it an attaractive option.

worksofcraft
August 20th, 2010, 05:12 AM
Use GTK because it works with Glade and Glade is an epic rad GUI tool for creating your own GUIs ;)