3 ms·

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 wi

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
I don't like to have adjust my build systems to run an additional pre-processor over my code when there's no actual requirement for it. I don't want to have to deal with code I did not write appearing in the middle of code I did write. GTK is written in C. Gtkmm is written in C++. Totally different. Gtkmm's signal/slot system is better than the original one in Qt. I haven't looked at Qt's current system in quite some time. someButton.signal_clicked().connect (mem_fun (*this, &Handler::method); Many variations to allow binding, argument hiding, return value hiding and all the usual stuff. Gtkmm has several display widgets that use a model/view paradigm, and let you define your own model and then map that to the view. If you literally just have a bunch of strings, there's one specifically to handle that situation. I haven't used Qt myself but have worked in close collaboration with people who use it a lot.
- simion314 7y ago
  OK, so your problem is that moc is an extra build step. but is this for aesthetic reason or why? From my Qt experience you never see the moc code when you debug your applications. The only way to avoid moc would be to use heavy templates or macros and those also generate code behind your back. I did not heard of GTKmm so I will check it out to find out more, thanks.

PaulDavisThe1st 7y ago

I don't like to have adjust my build systems to run an additional pre-processor over my code when there's no actual requirement for it. I don't want to have to deal with code I did not write appearing in the middle of code I did write. GTK is written in C. Gtkmm is written in C++. Totally different. Gtkmm's signal/slot system is better than the original one in Qt. I haven't looked at Qt's current system in quite some time. someButton.signal_clicked().connect (mem_fun (*this, &Handler::method); Many variations to allow binding, argument hiding, return value hiding and all the usual stuff. Gtkmm has several display widgets that use a model/view paradigm, and let you define your own model and then map that to the view. If you literally just have a bunch of strings, there's one specifically to handle that situation. I haven't used Qt myself but have worked in close collaboration with people who use it a lot.

simion314 7y ago
OK, so your problem is that moc is an extra build step. but is this for aesthetic reason or why? From my Qt experience you never see the moc code when you debug your applications. The only way to avoid moc would be to use heavy templates or macros and those also generate code behind your back. I did not heard of GTKmm so I will check it out to find out more, thanks.