Re: How to use glade with a GtkHeaderBar with different layouts

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

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 vanberkom 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