On Tue, 2017-03-07 at 11:05 +0100, Iñigo Martínez wrote: > 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. >
In the old days, I would use a notebook without tabs. In the modern world, I think you can just use a GtkStack (you may even want to animate/fade them when it switches for extra giggles). This approach is more maintainable I think than showing/hiding widgets (or adding removing them, adding and removing them is even more of a headache, as you have to make sure you retain ownership while carrying them over, floating refs and all that noise). Cheers, -Tristan > 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 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
