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

[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