Not logged in
Log in now
Create an account
Subscribe to LWN
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
GNU virtual private Ethernet
That's not as good as Qt. It really doesn't make much sense to build a GUI toolkit on top of C, and a GUI toolkit is crying for object oriented designs, and then write a C++ wrapper around it.
Sobotka: Why GIMP is inadequate
Posted Jan 12, 2011 15:36 UTC (Wed) by Trelane (guest, #56877)
In what (concrete) way?
>It really doesn't make much sense to build a GUI toolkit on top of C
>a GUI toolkit is crying for object oriented designs
Yes, and that's why it's object-based (GObject is the root object).
Posted Jan 13, 2011 5:54 UTC (Thu) by romanfi (guest, #72329)
> In what (concrete) way?
- compatibility between platforms
- structure of GUI components
- the designer IDE (here I'm not 100% sure)
A GUI is composed of elements that in some natural way inherit from each other. E.g. there are push buttons, radio buttons, which are all buttons. And buttons and many other elements are widgets. The main windows, dialogs and so on are frames or windows.
Motif already had an object oriented design, implemented using standard C. They even had public and private data members, faked using two header files defining two structures for every element, one of them for Motif itself, including the private members, the other one with just the public part, layout compatible. They've got virtual functions, implemented with function pointer arrays, and so on. And I can see the same thing in GTK.
So why not using the right tool for the job?
Posted Jan 13, 2011 20:09 UTC (Thu) by daniel (subscriber, #3181)
Posted Jan 13, 2011 20:55 UTC (Thu) by Trelane (guest, #56877)
Posted Jan 18, 2011 17:56 UTC (Tue) by daniel (subscriber, #3181)
I meant pointer casts that attempt to simulate a C++ class hierarchy using C structs with casts.
Posted Jan 13, 2011 20:53 UTC (Thu) by Trelane (guest, #56877)
This is pretty nebulous. Please be specific in what ways Qt is better than gtkmm in this regard.
Again, this is very nebulous. Be specific.
> structure of GUI components
Yet again, this is not at all specific. What precisely is better about Qt's "structure" than gtkmm's? List examples where you can.
> the designer IDE (here I'm not 100% sure)
This is simply a laundry list of things that are "better" (and most of the items aren't concrete examples of anything; they're categories) and nothing more. Please be specific with your argument and back it up with examples.
I'm going to learn Qt for maemo, so I hope to be less ignorant of Qt in the near future, as time permits. I do have a degree of experience in gtk and gtkmm, so I want to know what you think is failing (and perhaps even fix it). I can't fix "documentation"; I can fix the fact that there aren't any tutorials on how to frob the critical blort property in gtk/gtkmm, though.
> A GUI is composed of elements that in some natural way inherit from each other. E.g. there are push buttons, radio buttons, which are all buttons. And buttons and many other elements are widgets. The main windows, dialogs and so on are frames or windows.
Honestly, right here you sound like you haven't even looked at gtk+/gtkmm documentation, let *know* anything at all about it.
How about looking at the "Object Hierarchy"
> So why not using the right tool for the job?
I think you've confused me for you. I'm wondering why you think gtk+ is inferior to Qt in all situations (implicit in the statement "[gtkmm is]That's not as good as Qt." which is without qualifications. I don't mind Qt at all, and would like to improve gnome/gtk.
Posted Jan 13, 2011 21:00 UTC (Thu) by Trelane (guest, #56877)
Posted Jan 12, 2011 20:51 UTC (Wed) by prokoudine (guest, #41788)
And yet the best free vector graphics editor, Inkscape, is written in GTKMM.
Posted Jan 13, 2011 6:08 UTC (Thu) by romanfi (guest, #72329)
> And yet the best free vector graphics editor, Inkscape,
> is written in GTKMM.
GTKMM is an object oriented wrapper using an object oriented programming language around an object oriented design using a non object oriented programming language. For me, that's a quirk or suboptimal workaround.
And, can you prove that GTKMM wouldn't have been better in terms of
- easier design
- faster design and/or coding
- better L&F (yes, I work with inkscape from time to time)
when using e.g. Qt instead of GTK(MM)? Because all the arguments I listed above in my answer to another posting still hold true, e.g. compatibility across platforms, documentation, stability, etc.
If Qt would already hade been GPL when the developers started writing Goll and Sodipodi, do you think they would have had selected this one instead of Qt?
Of course, one aspect must never be forgotten. Would be GTK(MM) as good as it is now without Qt, and would Qt be as good as it is now without GTK(MM)? I think you understand what I want to say with this last sentence.
Please forgive me my bad english, it's not my mother's language.
Posted Jan 13, 2011 6:16 UTC (Thu) by DOT (subscriber, #58786)
Posted Jan 13, 2011 20:17 UTC (Thu) by daniel (subscriber, #3181)
Big deal, its better than casts. Even the original QT developers agree SigC++ or similar would have been better solution but these didn't exist at the time. The practical impact on design is negligible.
By the way "dreaded" is inappropriate rhetoric in this context. You might as well say the same of the the C preprocessor.
Posted Jan 13, 2011 22:12 UTC (Thu) by DOT (subscriber, #58786)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds