Thank you very much for your kind support Tristan, those hints are very much appreciated.
While I understand that the template actually is a definition of the class hierarchy, I was thinking about it as a description of the UI, and in that sense it would have been nice to have some way to define different states of a widget and be able to change between those changing the layout. One last question regarding widgets that are not displayed. What should be the best approach, add and remove the widgets to the header bar depending on what should be shown or have all the widgets packed in the header bar and just show/hide them? I was thinking on the latter approach as it involves only one widget, the one that is going to be shown or hide, versus the former one that involves two, the container and the widget to be added/removed. Best regards, 2017-03-07 5:51 GMT+01:00 Tristan Van Berkom <tristan.vanber...@codethink.co.uk>: > On Mon, 2017-03-06 at 22:26 +0100, Iñigo Martínez wrote: >> Recently, I started moving UI code from bare C to Glade XML files, so >> the UI definition gets split from the UI logic. >> >> One of the widgets I have been moving is a GtkHeaderBar. The >> application uses a GtkStack to move between diferent windows, and the >> code creates, adds and destroys the buttons on the header everytime >> it >> moves through those window states. All is done in the same class, >> derived from GtkHeaderBar. >> >> The first challenge here is that, as far as I know, I can only >> init/load one template per class. This solves only part of the >> problem, as I can create a template file for the most used/common >> window state, and create and change the buttons while they change, >> although I feel that I'm not taking any of the advantages from Glade. >> Here goes my first question: Is there any possibility of using more >> than one template on the same class? > > No. > > A template is the definition of the class's hierarchy, this is static > and is that way by design. > >> I have been looking at some GNOME applications code, and none of them >> do this, so I think that its probably not possible. I've been >> thinking >> about other approaches, but I don't know what could be the proper >> one, >> or even if I could be doing some weird things. >> >> One approach could be to define all the possible widgets/buttons of >> the header in the template file. They would be created but I should >> add and remove them continuously which doesn't look very >> efficient/clean. >> >> Another approach would be to create different classes for every >> possible header, each with their different template file, loading >> them >> on every window state and adding and removing the full header to/from >> the window. The idea is similar to what GtkStack does with windows, >> but applied to headers. >> >> Is there any reasonable answer for this or has anyone encountered a >> similar problem? > > Either of the above approaches are valid ones, I would probably opt for > the former since in this case you are only talking about some buttons > in a headerbar, which _should_ be ridiculously inexpensive. > > Some things to keep in mind: > > o Using templated classes keeps your business logic encapsulated > into an object type, this is the win you take home from using > templates rather than old fashioned manual usage of GtkBuilder > > The older approach tends to make your code hard to debug and > understand as your application gains complexity, as you would > traditionally just handle GSignals in callbacks which in turn > call other GTK+ apis, triggering more signals, this is what I've > referred to as "implicit invocation hell". > > o Based on the above, I would opt for declaring one widget class > for anything which serves a specific and identifiable purpose > in an app (whether or not the thing is complex enough to merit > a template, you might have some stand alone widget types with no > children, custom buttons or controls, which dont need templates at > all, but its cleaner to make widgets out of these than to handle > "draw" and event signals on a GtkDrawingArea). > > o Widgets should be assumed to consume very little resources when > they are not mapped and visible. > > Class methods, class-wide template XML, is all class data that is > in memory exactly once; for every widget you instantiate that > is not on screen (i.e. a button in a stack page that is not shown), > we are talking about some data structures allocated in memory to > track widgets visible/realized/mapped state, and some state about > whether a button is currently pressed etc. > > So just remember, instantiating a widget that is not displayed > should not consume any resources associated with drawing or > receiving events and whatnot. > > o As with any modular code, when a widget starts to have very many > features and gets overly complex, or when a widget hierarchy starts > to become huge, it's better to separate those features into > separate widgets (components of a larger program, either serving > different purposes or implementing a common interface differently). > > Interestingly, when we are talking about "smart" widgets which > manage their own business logic, code complexity and widget > hierarchy tends to scale hand in hand (bigger hierarchies are > both more difficult to reason about, and also consume more > resources). > > Cheers, > -Tristan > > >> >> Best regards, >> _______________________________________________ >> gtk-app-devel-list mailing list >> gtk-app-devel-list@gnome.org >> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list >> > _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
