Just to mention, I'm now subscribed to the list, so there's no need anymore to Cc me (I prefer not). Scribit Murray Cumming dies 24/01/2006 hora 17:28: > > Here we go: I'm on the page of the radio buttons, and [...] > In future, please do include URLs of the parts of the manual that you > are discussing, so we don't have to guess. I was not sure if the URL of the resulting HTML page was the good thing to give. > The Group acts a bit like a smart-pointer. The underlying > implementation is shared. IIUC, operations on the Group in fact have an effect on the underlying GObject, haven't they? > That's not so unusual, and this is a very simple part of the API so I > think it's OK for the documentation to just say how it should be used, > without worrying about how it is implemented. The exact implementation is of little use for the average user of the library, but a global understanding of the idioms and design patterns involved would be valuable, though. And it should be easy for the curious one to find a comprehensive documentation about implementation and design decisions. > It's mentioned in the Basics chapter in the book. I guess that's how > you know that it has a memory management purpose. What more do you > need to know? The problem here is pedagogical: you can't expect a beginner to understand (i.e. make himself a global representation of how it works and how he should use it) when you suddenly add something that has been hardly explained and that doesn't even adhere to common idioms the beginner should expect. make_something(group, item1); make_something(group, item2); is far less object oriented and understandable than, e.g. group.add(item1); group.add(item2); the latter seems to me to be crystal clear. That should be a design goal of examples in the tutorial, IMHO. > I also recently added reference documentation for it, in case anybody > finds their way to this page: > http://www.gtkmm.org/docs/gtkmm-2.4/docs/reference/html/namespaceGtk.html#85d08eef743328ffebac2647a9c7f183 Much clearer, at least for me, with this piece of documentation! > At the moment, it should probably be: > > Gtk::Main::init(argc, argv); > Gtk::Window window; > Gtk::Main::run(window); > > because Gtk::Main::Main() actually does not allow a second instance to > be instantiated. If there is such a constraint, why not make it a Singleton? > That probably doesn't work at the moment, but probably could be made > to work. The following code compiles, links and works for me: ######################################################################## #include <gtkmm.h> int main(int argc, char *argv[]) { Gtk::Main kit(argc, argv); Gtk::Window window; kit.run(window); } ######################################################################## > > The latter syntax is more object oriented, and moreover enables one > > to enhance or adapt the event loop by using another object (probably > > derived from Gtk::Main). > I'm not sure about that. I don't see a need to initialize gtkmm or > GTK+ twice. This is not the goal. But you could use another event loop. For example, in the last snippet of code, just replace the kit initialization by: MyLib::GtkAdapter::Main kit(argc, argv); That one of the very purposes of encapsulation! Documentally, Nowhere man -- nowhere man levallois eu org OpenPGP 0xD9D50D8A
Attachment:
signature.asc
Description: Digital signature