Re: Which icon for GTK_STOCK_EDIT?

[zahlenmeer]

On Tue, 07 Mar 2017 07:40:59 +0100
Tilo Villwock  wrote:

> Hello,
> 
> I think when it comes to icons you're not supposed to use the stock
> item facilities anymore. 

Exactly. That's why I am porting away from using them.

> 
> and browse through the available icons. Once you found a suitable one

I was hoping for a recommendation. For example, the
"accessoires-text-editor" icon I mentioned looks good in Adwaita but
may fit not as well in other themes.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Gtk+ progress bar color

[Stefan Salewski]

On Tue, 2017-03-07 at 15:43 +, Rúben Rodrigues wrote:
> > 
> > Hi guys,
> > 
> > How can i change progress bar color?
> > 
> > Thanks
> > 
> 
> 

For GTK 3.20 and above you can do it, using CSS. I did a similar fix
for scrollbar width for my 27 inch 4 display. I think I wrote how I did
it here some months ago. Basically you grap the CSS file, search for
progressbar, copy that section to ~/.config/gtk-3.0/gtk.css and modify
the color entry with a text editor. When you restart your application
you should notice the new color.

But maybe you want to use GTK2, Windows or Mac, or change it only for a
specific app?

And of course generally it may be a bad idea to modify single colors,
because it may not really fit for arbitrary themes. And, not all
widgets have plain colors, some have gradients and more. But I think
for progressbar there is indeed a single color defined for GTK 3.20.
And for personal use it should be OK.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

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

Gtk+ progress bar color

[Rúben Rodrigues]

> Hi guys,
>
> How can i change progress bar color?
>
> Thanks
>

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

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