3 ms·

> I decided to use GTK and not Qt because in the 1990s, Qt, despite being written in C++, was incredibly non-C++-idiomatic. Yeah, but there were good reasons f

> I decided to use GTK and not Qt because in the 1990s, Qt, despite being written in C++, was incredibly non-C++-idiomatic. Yeah, but there were good reasons for Qt to do that, I think that is just a taste thing, when you want to make an application that works the fact that Qt has a sane string,vector, signals is a plus(you did not need boost or third party code) , coming from Java or .Net Qt feels right. For GUIs I did not hit cross platform related issues. I think I had to re-arrange some menus depending on OS but not to use native code. The only time I had to use some native stuff and I had to include windows.h was because I needed to on a multi screen setup to get each screen dimensions and at that moment this was not implemented or bugged(I do not remember). About GTK, I strongly dislike the fact they are using their own File Chooser dialog and not the native one and that you can't customize the sorting order in it, especially on GTK2. So I have a few GTK2 apps and I always find it hartd to find my files because n how them are sorted , though in GTK3 I found a config options to change it a bit. I would still use GTK if the problem to solve would require Python and a simple GUI like ask the user for a name, to chose a file, input some text. show an image and it is a Linux tool only. About GNOME I agree, it could be possible in future GTK won't officially support menus, tray icons and other things that GNOME does not want.

PaulDavisThe1st 7y ago
There were no reasons for Qt to do that back in the day. Its string class had just as many issues as std::string, and libsigc++ showed how to do signals without a pre-processor. They just didn't want to do the work (then) ... now they have, and it's all just fine. I contributed some significant fixes for GTK on macOS (OS X) support, all of them based on our experience with it. What's there now still has a few fundamental issues (often caused by fundamental differences in basic concepts within Cocoa versus X), but it's in much better shape than it was in 2004. My interactions with people doing Qt-on-macOS suggest a similar level of pain there too, which is to say "not much if your app is straightforward, but irritating if it has special needs".
- simion314 7y ago
  Was that string support cross compiler or only gcc and mingw ? AFAIK you can't do signals with standard c++ until after C++ 14 and you need to keep in mind that Qt is used in automotive industry too so they probably don't have latest features there. Nevertheless if you use QString then you can populate QVector with it and you can then assign the collection to a QList and you got lots of benefits, the only thing is if you have to use some external library you need to convert the string or char[] to a QString. I never had a case where I was thinking "damm I would like to use the native string or I would like the moc did not exist, who is bothered by moc ? distro packagers ? some mixed projects ? some standard c/c++ project that would like to consume Qt libraries? What I really missed in Qt is a builtin simple way to create installers for Windows and Mac and a builtin way to do self-updating for Win and Mac. File size for Mac was also a complaint the qt apps received (I do not remember exactly how I was bundling them). At my work they disliked Qt and I had to use Adobe AIR, I hated it at first but after a while I think at that moment in time it was the right choice, it was cross platform, easy to update, no more segfaults, good stacktraces that I can log and then use to fix bugs.
  - PaulDavisThe1st 7y ago
    Gtkmm was using libsigc++ when I started working on Ardour in late 1999. No C++14 required.
    - simion314 7y ago
      I still do not know why you object to moc? If is a practical or ideological reason. I also don't like magic in my tools, code that is generated behind me but with Qt I never had issues with it(not like other tools where the magic code crashes and you have to understand what happens under the hood to figureout the problems). I did not used GTK seriously so I don't know how it's introspection and signal/events compare with Qt, are those as safe and easy to use? Is it easy to have collections of objects/strings and then use them in list/tables/trees? Trying to find examples i see a lot of C pointers and C function calls that seem to me very unsafe and ugly, something that would work fine for a small project but a pain for larger projects. Anyway I am not trying to sell you anything , I want to understand better what is wrong with moc in your opinions(have you used Qt in a serious project?) and we can learn from others experience.

PaulDavisThe1st 7y ago

There were no reasons for Qt to do that back in the day. Its string class had just as many issues as std::string, and libsigc++ showed how to do signals without a pre-processor. They just didn't want to do the work (then) ... now they have, and it's all just fine. I contributed some significant fixes for GTK on macOS (OS X) support, all of them based on our experience with it. What's there now still has a few fundamental issues (often caused by fundamental differences in basic concepts within Cocoa versus X), but it's in much better shape than it was in 2004. My interactions with people doing Qt-on-macOS suggest a similar level of pain there too, which is to say "not much if your app is straightforward, but irritating if it has special needs".

simion314 7y ago
Was that string support cross compiler or only gcc and mingw ? AFAIK you can't do signals with standard c++ until after C++ 14 and you need to keep in mind that Qt is used in automotive industry too so they probably don't have latest features there. Nevertheless if you use QString then you can populate QVector with it and you can then assign the collection to a QList and you got lots of benefits, the only thing is if you have to use some external library you need to convert the string or char[] to a QString. I never had a case where I was thinking "damm I would like to use the native string or I would like the moc did not exist, who is bothered by moc ? distro packagers ? some mixed projects ? some standard c/c++ project that would like to consume Qt libraries? What I really missed in Qt is a builtin simple way to create installers for Windows and Mac and a builtin way to do self-updating for Win and Mac. File size for Mac was also a complaint the qt apps received (I do not remember exactly how I was bundling them). At my work they disliked Qt and I had to use Adobe AIR, I hated it at first but after a while I think at that moment in time it was the right choice, it was cross platform, easy to update, no more segfaults, good stacktraces that I can log and then use to fix bugs.
- PaulDavisThe1st 7y ago
  Gtkmm was using libsigc++ when I started working on Ardour in late 1999. No C++14 required.
  - simion314 7y ago
    I still do not know why you object to moc? If is a practical or ideological reason. I also don't like magic in my tools, code that is generated behind me but with Qt I never had issues with it(not like other tools where the magic code crashes and you have to understand what happens under the hood to figureout the problems). I did not used GTK seriously so I don't know how it's introspection and signal/events compare with Qt, are those as safe and easy to use? Is it easy to have collections of objects/strings and then use them in list/tables/trees? Trying to find examples i see a lot of C pointers and C function calls that seem to me very unsafe and ugly, something that would work fine for a small project but a pain for larger projects. Anyway I am not trying to sell you anything , I want to understand better what is wrong with moc in your opinions(have you used Qt in a serious project?) and we can learn from others experience.