LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (https://www.linuxquestions.org/questions/programming-9/)
-   -   GTK+ vs. Qt (https://www.linuxquestions.org/questions/programming-9/gtk-vs-qt-820783/)

MTK358 07-19-2010 03:34 PM

GTK+ vs. Qt
 
I seriously started to wonder, which is better to write programs in?

Things I like about Qt:

First of all, is the language. GTK+ is in C, with this strange object-oriented system, and all the methods have such long, redundant names. Qt is written in an OO language, so it avoids this completaly.

Also, when learning how to use them I found that Qt code is cleaner and seems easier to work with, while GTK+ seems a bit messy, probably as a side effect of it's OO C code.

Qt itself doesn't seem to be strongly tied to a certain desktop environment (even though it's use is often associated with KDE), while GTK+ is developed as part of GNOME. Will GTK+ ever become somehow GNOME-biased?

Qt has signals and slots, I think it's a nice system. GTK+ uses callbacks.

Things I like about GTK+:

GTK+ is far more popular than Qt, and seems to be more customizable and have more themes.

I was always under the impression that GTK+ is more "FOSS-oriented" than Qt. AFAIK GTK+ is open-source all the way, while Qt was proprietary and was forced to be put under a FOSS license just because KDE used it. It just seems to have more of a "open-source hacker" that "big corporation" feel :)

It's just a plain, small GUI toolkit.

It has Perl bindings. I wasn't able to find a full, popular, supported Perl Qt4 binding.

Anyway, I wonder if any of my ideas above are wrong, and what should I probably use?

dugan 07-19-2010 03:35 PM

Quote:

Originally Posted by MTK358 (Post 4038535)
GTK+ is developed as part of GNOME.

Are you sure about this?

Quote:

I found that Qt code is cleaner and seems easier to work with
That should be the deciding factor. Maintainability should always be one of your top priorities.

Choosing a toolkit that you enjoy using less, for silly reasons such as a) it being used by projects you're not involved in, or b) the way its license was written before it was changed ten years ago, is not something you do unless someone forces you to.

MTK358 07-19-2010 03:47 PM

A lot of GTK+ development info is on GNOME's website, also this thread worries me somewhat:

http://www.linuxquestions.org/questi...-3-0-a-820085/

dugan 07-19-2010 03:57 PM

It's too early to start worrying about GTK 3. When you use any library at all, you always take the risk that a new version will contain API changes that will break your existing work. You deal with that when it happens.

Sergei Steshenko 07-19-2010 04:26 PM

Quote:

Originally Posted by MTK358 (Post 4038535)
...
GTK+ is far more popular than Qt, and seems to be more customizable and have more themes.
...

I don't think gtk+ has more themes - visit http://kde-look.org/ .

Sergei Steshenko 07-19-2010 04:27 PM

Quote:

Originally Posted by dugan (Post 4038537)
Are you sure about this?



That should be the deciding factor. Maintainability should always be one of your top priorities.
...

Yes.

Sergei Steshenko 07-19-2010 06:06 PM

Quote:

Originally Posted by MTK358 (Post 4038535)
...
It has Perl bindings. I wasn't able to find a full, popular, supported Perl Qt4 binding.
...

That's exactly the sad reason I have to use gtk+ rather than Qt.

exvor 07-19-2010 06:59 PM

One of the main issues with QT is that you have to have almost all of KDE installed to be able to use programs with it. GTK is not this way, many of the programs do not require you to have most of GNOME installed. I am able to write a GTK program that only requires gtk+ cairo and maybe 2 other libraries installed. Of course I am looking at this from a LFS or compiled source point of view and not a distro point of view. Last time I attempted to install qt from source it was a bit of a nightmare so I have yet to try and install it again. This is why I cannot run QT programs.

BTW I don't use gnome either as it is a nightmare of dependencies so I only install what is minimally required to get gtk programs to function. I will also admit I have only written small programs in GTK and have no experience with writing qt programs at all.

Kenny_Strawn 07-19-2010 07:04 PM

Quote:

Originally Posted by dugan (Post 4038537)
Are you sure about this?

Code:

git clone git://git.gnome.org/gtk+
This is ultimately where you would download GTK+ to develop it, and it's on the GNOME website!

Please note that there is a gtk3 branch already:

Code:

git clone git://git.gnome.org/gtk+ gtk3
GTK+ currently is at its 2.90 version, a.k.a. GTK3 Beta.

For more information:

http://live.gnome.org/TwoPointThirtyone

http://live.gnome.org/GTK%2B/Roadmap

MTK358 07-19-2010 07:25 PM

Quote:

Originally Posted by exvor (Post 4038759)
One of the main issues with QT is that you have to have almost all of KDE installed to be able to use programs with it. GTK is not this way, many of the programs do not require you to have most of GNOME installed.

That's because most Qt programs use KDE libs.

You can write a Qt app that doesn't rely on KDE just as easy as you can write a GTK+ app that doesn't rely on GNOME.

Sergei Steshenko 07-19-2010 07:31 PM

Quote:

Originally Posted by exvor (Post 4038759)
...I am able to write a GTK program that only requires gtk+ cairo and maybe 2 other libraries installed. ...

Well, it depends on how you interpret "couple".

Do you know that, for example. gtk+ depends on 'openssl' ? And on 'pcre' ?

Should I continue ?

MTK358 07-19-2010 07:36 PM

Quote:

Originally Posted by Sergei Steshenko (Post 4038797)
Do you know that, for example. gtk+ depends on 'openssl' ? And on 'pcre' ?

Really? Why would it?

Sergei Steshenko 07-19-2010 07:41 PM

Quote:

Originally Posted by MTK358 (Post 4038802)
Really? Why would it?

See the "unrolled" dependency tree:

Code:

$scalar_path=gtk+
$scalar_path=gtk+ -> atk
$scalar_path=gtk+ -> atk -> glib
$scalar_path=gtk+ -> atk -> glib -> gettext
$scalar_path=gtk+ -> atk -> glib -> gettext -> libiconv_pre
$scalar_path=gtk+ -> atk -> glib -> gettext -> libiconv_pre -> libtool
$scalar_path=gtk+ -> atk -> glib -> gettext -> libiconv_pre -> libtool -> automake
$scalar_path=gtk+ -> atk -> glib -> gettext -> libiconv_pre -> libtool -> automake -> autoconf
$scalar_path=gtk+ -> atk -> glib -> gettext -> libiconv_pre -> libtool -> automake -> autoconf -> texinfo
$scalar_path=gtk+ -> atk -> glib -> libiconv
$scalar_path=gtk+ -> atk -> glib -> libiconv -> gettext
$scalar_path=gtk+ -> atk -> glib -> libiconv -> gettext -> libiconv_pre
$scalar_path=gtk+ -> atk -> glib -> libiconv -> gettext -> libiconv_pre -> libtool
$scalar_path=gtk+ -> atk -> glib -> libiconv -> gettext -> libiconv_pre -> libtool -> automake
$scalar_path=gtk+ -> atk -> glib -> libiconv -> gettext -> libiconv_pre -> libtool -> automake -> autoconf
$scalar_path=gtk+ -> atk -> glib -> libiconv -> gettext -> libiconv_pre -> libtool -> automake -> autoconf -> texinfo
$scalar_path=gtk+ -> atk -> glib -> pcre
$scalar_path=gtk+ -> atk -> glib -> pcre -> readline
$scalar_path=gtk+ -> cairo
$scalar_path=gtk+ -> cairo -> fontconfig
$scalar_path=gtk+ -> cairo -> fontconfig -> freetype
$scalar_path=gtk+ -> cairo -> libpng
$scalar_path=gtk+ -> cups
$scalar_path=gtk+ -> cups -> libjpeg
$scalar_path=gtk+ -> cups -> libjpeg -> libtool
$scalar_path=gtk+ -> cups -> libjpeg -> libtool -> automake
$scalar_path=gtk+ -> cups -> libjpeg -> libtool -> automake -> autoconf
$scalar_path=gtk+ -> cups -> libjpeg -> libtool -> automake -> autoconf -> texinfo
$scalar_path=gtk+ -> cups -> libpng
$scalar_path=gtk+ -> cups -> libtiff
$scalar_path=gtk+ -> cups -> libtiff -> libjpeg
$scalar_path=gtk+ -> cups -> libtiff -> libjpeg -> libtool
$scalar_path=gtk+ -> cups -> libtiff -> libjpeg -> libtool -> automake
$scalar_path=gtk+ -> cups -> libtiff -> libjpeg -> libtool -> automake -> autoconf
$scalar_path=gtk+ -> cups -> libtiff -> libjpeg -> libtool -> automake -> autoconf -> texinfo
$scalar_path=gtk+ -> cups -> openssl
$scalar_path=gtk+ -> cups -> openssl -> bc
$scalar_path=gtk+ -> cups -> openssl -> bc -> flex
$scalar_path=gtk+ -> cups -> openssl -> bc -> flex -> bison
$scalar_path=gtk+ -> jasper
$scalar_path=gtk+ -> jasper -> libjpeg
$scalar_path=gtk+ -> jasper -> libjpeg -> libtool
$scalar_path=gtk+ -> jasper -> libjpeg -> libtool -> automake
$scalar_path=gtk+ -> jasper -> libjpeg -> libtool -> automake -> autoconf
$scalar_path=gtk+ -> jasper -> libjpeg -> libtool -> automake -> autoconf -> texinfo
$scalar_path=gtk+ -> libjpeg
$scalar_path=gtk+ -> libjpeg -> libtool
$scalar_path=gtk+ -> libjpeg -> libtool -> automake
$scalar_path=gtk+ -> libjpeg -> libtool -> automake -> autoconf
$scalar_path=gtk+ -> libjpeg -> libtool -> automake -> autoconf -> texinfo
$scalar_path=gtk+ -> libtiff
$scalar_path=gtk+ -> libtiff -> libjpeg
$scalar_path=gtk+ -> libtiff -> libjpeg -> libtool
$scalar_path=gtk+ -> libtiff -> libjpeg -> libtool -> automake
$scalar_path=gtk+ -> libtiff -> libjpeg -> libtool -> automake -> autoconf
$scalar_path=gtk+ -> libtiff -> libjpeg -> libtool -> automake -> autoconf -> texinfo
$scalar_path=gtk+ -> pango
$scalar_path=gtk+ -> pango -> cairo
$scalar_path=gtk+ -> pango -> cairo -> fontconfig
$scalar_path=gtk+ -> pango -> cairo -> fontconfig -> freetype
$scalar_path=gtk+ -> pango -> cairo -> libpng
$scalar_path=gtk+ -> pango -> glib
$scalar_path=gtk+ -> pango -> glib -> gettext
$scalar_path=gtk+ -> pango -> glib -> gettext -> libiconv_pre
$scalar_path=gtk+ -> pango -> glib -> gettext -> libiconv_pre -> libtool
$scalar_path=gtk+ -> pango -> glib -> gettext -> libiconv_pre -> libtool -> automake
$scalar_path=gtk+ -> pango -> glib -> gettext -> libiconv_pre -> libtool -> automake -> autoconf
$scalar_path=gtk+ -> pango -> glib -> gettext -> libiconv_pre -> libtool -> automake -> autoconf -> texinfo
$scalar_path=gtk+ -> pango -> glib -> libiconv
$scalar_path=gtk+ -> pango -> glib -> libiconv -> gettext
$scalar_path=gtk+ -> pango -> glib -> libiconv -> gettext -> libiconv_pre
$scalar_path=gtk+ -> pango -> glib -> libiconv -> gettext -> libiconv_pre -> libtool
$scalar_path=gtk+ -> pango -> glib -> libiconv -> gettext -> libiconv_pre -> libtool -> automake
$scalar_path=gtk+ -> pango -> glib -> libiconv -> gettext -> libiconv_pre -> libtool -> automake -> autoconf
$scalar_path=gtk+ -> pango -> glib -> libiconv -> gettext -> libiconv_pre -> libtool -> automake -> autoconf -> texinfo
$scalar_path=gtk+ -> pango -> glib -> pcre
$scalar_path=gtk+ -> pango -> glib -> pcre -> readline

I've been building gtk+ automatically since 2006.

dugan 07-19-2010 07:50 PM

Quote:

Originally Posted by Kenny_Strawn (Post 4038771)
This is ultimately where you would download GTK+ to develop it, and it's on the GNOME website!

The GNOME project's repository is also hosting GIMP, and GIMP is not "developed as part of GNOME."

Tinkster 07-19-2010 08:30 PM

Quote:

Originally Posted by exvor (Post 4038759)
One of the main issues with QT is that you have to have almost all of KDE installed to be able to use programs with it.

Where did that one come from?

On Slackware64 13.1 no part of Qt is linked against
any KDE libraries. Why would I need "almost all of
KDE installed" to use any program?

Kenny_Strawn 07-19-2010 09:40 PM

Quote:

Originally Posted by exvor (Post 4038759)
One of the main issues with QT is that you have to have almost all of KDE installed to be able to use programs with it. GTK is not this way, many of the programs do not require you to have most of GNOME installed.

That's because most of the native Qt widgets that aren't KDE-specific are proprietary and used primarily in M$ WinBloze apps.

If you want something genuinely FOSS your best bet is GTK+.

Also: GTK+ absolutely must not depend entirely on GNOME, as the latest releases of Xfce also are based on GTK+ code.

dugan 07-19-2010 09:42 PM

Quote:

Originally Posted by Kenny_Strawn (Post 4038887)
That's because most of the native Qt widgets that aren't KDE-specific are proprietary and used primarily in M$ WinBloze apps.

That is absolutely false.

It amazes me that you would make up misinformation like that.

For one thing, none of Qt's widgets are KDE-specific. KDE's widgets are contained in the separate kdeui library, and all of them are subclassed from Qt's widgets. Which means they're obviously not any more "proprietary" than their superclasses. And to talk about "native" Qt widgets is meaningless.

Sergei Steshenko 07-19-2010 09:43 PM

Quote:

Originally Posted by Kenny_Strawn (Post 4038887)
That's because most of the native Qt widgets that aren't KDE-specific are proprietary ...


Where from did you take that info ?

Kenny_Strawn 07-19-2010 10:06 PM

<removed>

Kenny_Strawn 07-19-2010 10:12 PM

Quote:

Originally Posted by Sergei Steshenko (Post 4038892)
Where from did you take that info ?

http://en.wikipedia.org/wiki/Qt_(toolkit)

Quote:

Originally Posted by Wikipedia article on Qt
License: GNU LGPL 2.1, GNU GPL 3 with Qt special exception, Commercial developer license


dugan 07-19-2010 10:16 PM

Offering the option of a commercial license, as an alternative to the two open source licenses also offered, does not make Qt proprietary.

You should have looked into why Nokia offers that option, what the terms are, and why someone might want to pay for it.

http://qt.nokia.com/products/licensing

Needless to say, no part of Qt is proprietary.

Tinkster 07-19-2010 10:30 PM

Quote:

Originally Posted by Kenny_Strawn (Post 4038918)
That's because most of the native Qt widgets that aren't KDE-specific are proprietary and used primarily in M$ WinBloze apps.



Quote:

Originally Posted by Kenny_Strawn (Post 4038918)


Ummmm ... that article doesn't mention anything like
your statement above; where on earth did you learn to
make citations or quotes?


Cheers,
Tink

Sergei Steshenko 07-19-2010 10:46 PM

Quote:

Originally Posted by Kenny_Strawn (Post 4038918)

I think you have serious problems with understanding what LGPL and/or English in general.

Specifically, recheck you understanding of what "widget" means in GUI toolkit context.

Kenny_Strawn 07-19-2010 11:51 PM

Quote:

Originally Posted by Sergei Steshenko (Post 4038938)
I think you have serious problems with understanding what LGPL and/or English in general.

Specifically, recheck you understanding of what "widget" means in GUI toolkit context.

I know what 'widget' means. It's a visual piece of a GUI (such as a window, bar, or panel) that combines with others to make the whole GUI's visual appearance.

And I also know that the LGPL is a license that serves as a compromise between permissive licenses and copyleft licenses. That's why it is called "Lesser": It says that software that merely links with software licensed under it can be under another license, even a proprietary license, but software that actually uses its code may not.

Sergei Steshenko 07-20-2010 12:32 AM

Quote:

Originally Posted by Kenny_Strawn (Post 4038983)
I know what 'widget' means. It's a visual piece of a GUI (such as a window, bar, or panel) that combines with others to make the whole GUI's visual appearance.

And I also know that the LGPL is a license that serves as a compromise between permissive licenses and copyleft licenses. That's why it is called "Lesser": It says that software that merely links with software licensed under it can be under another license, even a proprietary license, but software that actually uses its code may not.

So, how do "most of the native Qt widgets that aren't KDE-specific are proprietary" come from your words above ?

MTK358 07-20-2010 07:56 AM

I also don't get where you got the idea that Qt is proprietary. It was, but not any more.

All I said was that GTK+ is FOSS all the way and is community-developed, while AFAIK Qt is developed by a corporation and just releases it under a FOSS license to keep KDE users from getting angry about the fact that they must install non-free software.

*** If you think Qt is connected to KDE, please read below ***

Also, there seem to be plenty of members that falsely believe that Qt is part of or dependant on KDE. Yes, there are KDE widgets, but they are all just subclasses of pure nothing-to-do-with-KDE Qt widgets. Also, people say that Qt is KDE because most Qt progrmas bring in KDE dependencies. But this is because most Qt programs are made specifically for KDE, because just about no-one but KDE uses Qt for some reason. This is no different than a GTK+ program made specifically for GNOME pulling in GNOME dependencies. Writing a Qt program that has nothing to do with KDE is just as simple as writing a GTK+ program that has nothing to do with GNOME.

If you really want examples of Qt programs with no KDE dependencies, check out "SpeedCrunch" and "VirtualBox". They don't even follow KDE's theme setting! To change "pure" non-KDE Qt settings, including the theme, run the command "qtconfig".

pixellany 07-20-2010 08:30 AM

Kenny;

Based on our discussion in another thread**, I concur that you need to be more careful with your facts and references. Please don't modify your enthusiasm---just slow down a bit....

thanks

**http://www.linuxquestions.org/questi...nux-os-819405/ (In this thread, you never posted a follow-up after the post from the company making the SW. )

MTK358 07-20-2010 09:11 AM

A long time ago in Qt Designer I made a complex GUI for fun. It was very easy, it Just Worked, and it looks perfect and professional.

Just to see, I decided to try recreating it in Glade. It's insane how difficult and frustrating it is. The main problem is the layouts. Somehow in Qt you just throw it together and it looks PERFECT. But in GTK+, you have to change all these little settings and even set hard-coded pixel values for spacings (yuck)!

Also, in Qt, they don't have these complicated packing boxes where things go in the front and in the back. They just have "spacers", which you can pretend are like invisible springs that push apart certain GUI elements in a box layout. So simple!

I can't believe how someone in their right mind would ever choose to write an app in GTK+ rather than Qt, having gotten a taste of both. I'm just thinking, maybe I'm doing something wrong? How could it be that GTK+ is so popular?!?

jf.argentino 07-20-2010 12:26 PM

My 2 pence.

Qt is far more than just GUI library, you've got thread, network ... os-independant wrappers. GTK+ is GUI only. Am i wrong there since nobody else tell that important point ?

The official Qt's documentation is really great, GTK+ official documentation is quite incomplete.

Not that much experencied with Qt (only a dozen of app), I've tried Qt-designer and I don't like it, especially because I never found a way to declare an array of identical widgets, Qt-designer output is a big unreadable source code you've got to compile. By the way, writing a "not that much" complicated GUI by hand only is really easy.

I've tried GTK+ only once, and without testing glade, but afaik glade output is an xml description of your widget that could be interpreted at runtime. There too, I found that writing gui by hand is quite easy, but i think that pure C object oriented coding can be disturbing for somebody not too experienced.

Sergei Steshenko 07-20-2010 12:28 PM

Quote:

Originally Posted by MTK358 (Post 4039484)
...How could it be that GTK+ is so popular?!?

A couple of reasons:
  1. Qt license used to be restrictive for a long time, i.e. there was no LFPL option;
  2. Folks in the US do not quite like things developed in Europe (Qt is a European creation), RedHat prefers Gnome, etc.

MTK358 07-20-2010 01:23 PM

I guess Qt is better then :)

Also, this led me to KDE-Look.org, where I found that there really are a lot of nice Qt themes!

Just one more thing: what about Perl?

And I still wonder, why are non-KDE Qt apps so rare?

dugan 07-20-2010 01:26 PM

Quote:

Originally Posted by MTK358 (Post 4039755)
And I still wonder, why are non-KDE Qt apps so rare?

Because there's really no benefit in not taking advantage of KDE, unless your app needs to run on platforms where KDE isn't available. Combining Qt with KDE gives you a richer API and access to KDE's theme engine.

My MPD client is a KDE app because I wanted access to KDE's icons (for the toolbar). and because I wanted it to be KDE-themed.

http://www.vcn.bc.ca/~dugan/quetzalcoatl.html

Sergei Steshenko 07-20-2010 01:30 PM

Quote:

Originally Posted by MTK358 (Post 4039755)
...
Just one more thing: what about Perl?
...

C++ is harder to bind than "C" - regardless of Qt specifically. There are some Qt4 bindings, haven't tried them.

Alas, the same sad story with OCaml - Qt3 bindings exist, but I haven't found Qt4 bindings. gtk+ bindings exist.

MTK358 07-20-2010 01:30 PM

What if someone wants a lightweight low-resource desktop using Qt apps but doesn't want to pull in KDE dependencies?

Also, why are KDE and "pure" Qt themes separate?

MTK358 07-20-2010 07:55 PM

I'm checking this out:

http://qt-apps.org/content/show.php/...?content=69748

Sergei Steshenko 07-20-2010 08:30 PM

Quote:

Originally Posted by MTK358 (Post 4040122)

Yep, that's the Qt4 bindings I meant. Even if you manage to compile, the question is completeness. Though I'm not familiar in detail with Qt4 and these bindings, but somehow the question arose.

jf.argentino 07-21-2010 02:25 AM

Quote:

What if someone wants a lightweight low-resource desktop using Qt
Qt embedded uses the frame buffer, no X needed

MTK358 07-21-2010 06:34 AM

I just meant what if someone wants a KDE-less desktop using Qt apps?

Still, the main thing that puzzles me now it why Qt themes and KDE themes are separate?

MTK358 07-21-2010 07:06 AM

It tried Perl Qt4, it failed to compile. I also tried converting the RPM packages to pacman, they installed without an error, the files in the hard drive went where they were supposed to in the original RPM, but Perl says it can't find the modules when I try one of the examples.

Kenny_Strawn 08-17-2010 01:57 AM

Quote:

Originally Posted by Sergei Steshenko (Post 4039698)
A couple of reasons:
  1. Qt license used to be restrictive for a long time, i.e. there was no LFPL option;
  2. Folks in the US do not quite like things developed in Europe (Qt is a European creation), RedHat prefers Gnome, etc.

Yes... Very good point Sergei: Even though Torvalds likes Qt doesn't mean that other FOSS users will. I am American (from California) but actually really prefer Qt Designer over Glade as well -- You don't need as many widgets (e.g. Layout) on top of the MainWindow class, You can develop complex GUIs with it without much difficulty, etc and in most cases without even knowing how to code -- you just plug in widgets and go, compiling when you're done. Even though you can also do this with Glade, in GTK most widgets depend on others, which makes for a messy experience.

MTK358 08-17-2010 07:30 AM

Also, how can you even lay widgets out in GTK/Glade? They seem to be smooshed right together by default and the only appearant way to have some space between them is to hard-code pixel values <shiver>. OTOH, Qt makes it beautiful on its own! It sacrifices flexibility for actually being able to do what you always want. Am I misunderstanding something, or is there really no way to change this behavior in GTK?

But I kind of agree with Kenny_Strawn about the licensing. It might be FOSS now, but it's not like it's community-developed or was designed with the FOSS spirit. In fact, I have the idea (whether it's true or not) that Qt was only made free because of the pressure of all those angry KDE users who had to get illegal copies of Qt, not because they like or support FOSS.

Sergei Steshenko 08-17-2010 08:23 AM

Quote:

Originally Posted by MTK358 (Post 4068869)
Also, how can you even lay widgets out in GTK/Glade? They seem to be smooshed right together by default and the only appearant way to have some space between them is to hard-code pixel values <shiver>.
...


AFAIR 'glade' has a notion of packing boxes.

...

Yes, it does: http://wingtk.sourceforge.net/ishan/glade.html .

Sergei Steshenko 08-17-2010 08:26 AM

Quote:

Originally Posted by MTK358 (Post 4068869)
...
But I kind of agree with Kenny_Strawn about the licensing. It might be FOSS now, but it's not like it's community-developed or was designed with the FOSS spirit. In fact, I have the idea (whether it's true or not) that Qt was only made free because of the pressure of all those angry KDE users who had to get illegal copies of Qt, not because they like or support FOSS.

It's a good thing Qt was designed by a commercial entity - that's why we have much less mess in it.

And sometimes I am sick and tired of ardent GPL3 proponents ideological stance.

MTK358 08-17-2010 09:41 AM

1 Attachment(s)
Quote:

Originally Posted by Sergei Steshenko (Post 4068916)
AFAIR 'glade' has a notion of packing boxes.

I know. I am talking about the distance between items in a packing box.

EDIT: see attached screenshot (in case you're wondering, the theme is QtCurve with a custom config. I wish I used a different theme for this screenshot that would better show the way the buttons are squeezed together with no gaps.).

Kenny_Strawn 08-17-2010 10:53 AM

Quote:

Originally Posted by MTK358 (Post 4068869)
Also, how can you even lay widgets out in GTK/Glade? They seem to be smooshed right together by default and the only appearant way to have some space between them is to hard-code pixel values <shiver>. OTOH, Qt makes it beautiful on its own! It sacrifices flexibility for actually being able to do what you always want. Am I misunderstanding something, or is there really no way to change this behavior in GTK?

But I kind of agree with Kenny_Strawn about the licensing. It might be FOSS now, but it's not like it's community-developed or was designed with the FOSS spirit. In fact, I have the idea (whether it's true or not) that Qt was only made free because of the pressure of all those angry KDE users who had to get illegal copies of Qt, not because they like or support FOSS.

You know, it's really up to the user whether to use Qt or GTK. If I had to choose, I would really choose Qt in some cases because it's cleaner (to design complex GUIs) and GTK for mainstream applications (i.e. Web browsers, office suites, terminal emulators, social clients, /etc). But it's your choice. I would say go with what you think is more practical.

Sergei Steshenko 08-17-2010 10:56 AM

Quote:

Originally Posted by MTK358 (Post 4069014)
I know. I am talking about the distance between items in a packing box.

EDIT: see attached screenshot (in case you're wondering, the theme is QtCurve with a custom config. I wish I used a different theme for this screenshot that would better show the way the buttons are squeezed together with no gaps.).

In this case I like gtk+ more :).

Anyway, there are HSeparator, VSeparator.

MTK358 08-17-2010 11:41 AM

1 Attachment(s)
Quote:

Originally Posted by Sergei Steshenko (Post 4069115)
In this case I like gtk+ more :).

Anyway, there are HSeparator, VSeparator.

Look at this:

http://www.youtube.com/watch?v=3JuvSobjMi4

Compare to this:

Sergei Steshenko 08-17-2010 04:43 PM

Quote:

Originally Posted by MTK358 (Post 4069172)
Look at this:

http://www.youtube.com/watch?v=3JuvSobjMi4

Compare to this:

Sorry, I do not watch 'youtube' on programming.

dugan 08-17-2010 06:07 PM

I hope that by "Youtube" you don't mean "webcasts in general", because there are a LOT of great programming webcasts. Most are aimed at professionals or university students.

Sergei Steshenko 08-17-2010 06:14 PM

Quote:

Originally Posted by dugan (Post 4069536)
... there are a LOT of great programming webcasts. ...

Unless I can copy-paste the code from the webcasts they are useless for me. I.e I won't even look.

At all, I prefer to work with texts. I.e. I want to be able to display a number of texts side by side (e.g. a programming language standard and a piece of code in the language) and to compare/confront the two items.

I want to be able to perform electronic search. I want to be able to reformat the code the way I like.


All times are GMT -5. The time now is 08:24 AM.