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

[Tristan Van Berkom]

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

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

[Iñigo Martínez]

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

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

[Tristan Van Berkom]

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