Re: How to use glade with a GtkHeaderBar with different layouts
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 > > "draw" and event signals on a G
Re: How to use glade with a GtkHeaderBar with different layouts
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 hierarchy starts > to become huge, it
Re: How to use glade with a GtkHeaderBar with different layouts
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
How to use glade with a GtkHeaderBar with different layouts
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? 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? Best regards, ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list