Re: [gtk-list] Re: GtkWidget::set_style proposal (was: [bug, v0.99.3] frame->label_width)

[Tim Janik <timj gimp org>]

first, big thanx to yosh
for setting up a gtk-list proxy for me.

for everyone at redhat.com:
*please* add Tim.Janik@Hamburg.Netsurf.DE to the receipient list
of gtk-list@redhat.com, my subscription requests disappeared silently.

On 20 Feb 1998, Owen Taylor wrote:

> 
> Tim Janik <timj@gimp.org> writes:
> 
> > now, there would be an easy solution, that is to move the size computation
> > of the frames label out of gtk_frame_set_label into gtk_frame_paint.
> > but this will introduce a performance impact on every expose event (of which
> > there are quite a lot coming from the x server during normal program
> > operation), and it would only be a fix around the real problem, that is:
> > widgets don't get informed when their style changes.
> > 
> > so i'm herewith proposing the need of yet another widget signal,
> > run_type==GTK_RUN_FIRST as follows:
> > 
> > void	(*GtkWidget::set_style)	(GtkWidget *widget,
> > 				 GtkStyle  *previous_style);
> > 
> > the new style will be already set if this signal is emitted.
> > 
> > objections?
> 
> From my TODO list:
> 
>  * Need to be able to make small alterations in the widgets style.
>    1) gtk_style_copy
>    2) A function to force the style to be set, _without_ realizing
>       the widget. (And/or a way of telling widgets that the style has
>       been changed so they can change their window's bg color)

hm, i'm not too sure how you would want to set the style on a widget
without telling the widget->windows colormap and depth.
would full notification be sufficient, so that we can stick to
the scheme of attaching styles during widget realization?

> So, yes, it is a good idea. Further thoughts:
> 
> - I would call it "style_set" though, because it is notification,
>   not a command. 

hm, what about the recently implemented GtkWidget::set_parent signal,
that should be renamed GtkWIdget::parent_set to adhere to your
idea of notification naming.

> - I don't see much point to having the previous_style argument -
>   it may be harmless, but it also IMO useless.

i've similarly implemented previous_parent for the GtkWidget::set_parent
signal. providing the old values might not be usefull if you are
changing label sizes from e.g. (double)6 to (double)5 on a
label_changed_size signal but as soon as structure references
are concerned, especially such as
GtkWidget or GtkStyle that do actual reference counting, the
old values might come extremely in handy if you are keeping track
of inter widget relationships from outside of the toolkit, like e.g.
an interface builder or even a clever interpreter would do it.
omitting previous_parent or previous_style would lead to
gtk_object_set_data (widget,
                     "xxx-private-key-old-parent-hint,
                     widget->parent)
in callbacks of GtkWIdget::set_parent just for the sake of
later remebering the old parent, where the old value can just
too easily by supplied by the signal emission code.

> - Are you planning to emit it when the style is initially set
>   or only later? I would tend to say that it it only needs to
>   be emitted after the widget has been size_requested for the
>   first time, though that isn't really flagged now.

kind of like the reasonings above, if i want to keep track of this
from outside the toolkit, but even if i just want to put my
label width calculation code only into gtk_*_style_set()
the emission will be needed on any occasion where a style is
attached to a widget. so i the emission is needed on the initial setting
and on all subsequent changes (something that doesn't actually happen
too often).

> - Implementing it fully will require quite a bit of work - since
>   almost every widget that isn't NO_WINDOW should in theory have
>   a handler. 

hm, i think we can have an easy start by providing a default handler
that will set the window background and perform a size request.

> - It probably is a good idea to do the style initialization that
>   is now done at the time of "realize" before the initial
>   "size_request", because a lot of widgets will change their size
>   depending on the style.

hm, you just gave a reason why GtkWidget::style_set should
be emitted on the initial setting also. i seem to loose the point
of your third argument ("- Are you planning to emit it when..").
widgets need to be informed on subsequent changes anyway, now
you gave the reasonings for the emission on the initial setting.
seems like it should be emitted always as i state above, no? ;)

> 
> - There _should_ be a command that says "set the style now", 
>   other than gtk_widget_realize(). Maybe we should add another
>   widget flag as well...


>   So people can do:
> 

i assume you mean, one can do
      g_assert (!GTK_WIDGET_REALIZED (widget)); /* here... */
>     if (!GTK_WIDGET_STYLE_SET (widget))
>       gtk_widget_set_default_style (widget); 
>     new_style = gtk_style_copy (widget->style);
>     new_style->fg_color[GTK_STATE_NORMAL] = my_color;
>     gtk_widget_set_style (new_style)

now, assume people are not going to modify
new_style->fg_color[GTK_STATE_NORMAL], but
new_style->fg_gc[GTK_STATE_NORMAL], because they want
dotted lines or what the heck.
now the depth of the widget window is required that you need to
know *before* actual realization. this is pretty much an
impossibility, e.g. consider quartics GtkPixmap needs an own
XWindow problem.

owen, i know it would be nice to set this stuff in advance,
and we might even be able to achive this for the style colors,
since they can be parsed later on.

but it would only be a half working solution since the gc portion
of styles cannot be set in advance since the depth is unknown.

actually there is a reason that people can connect to GtkWidget:realize
(it is emitted RUN_FIRST). some stuff just can't be done in advance.

>   Adding the flag means that we can solve the problem mentioned
>   above - the "style_set" would only be emitted _after_ the
>   first time the style is set. Since that would be guaranteed
>   to be before the first size_request, everything would work
>   out fine. Until we run out of flags...

after the recent split up there's prettymuch room for flags now ;)

>   Note that people will still get into trouble if they do:
> 
>     if (!GTK_STYLE_SET (widget))
>       gtk_widget_set_default_style (widget); 
>     my_color = widget->style_color;
> 
>   Because the style isn't _attached_ yet. For that usage, you
>   will still have to realize the widget.

hm, are you also proposing to have individual styles for all widgets,
or do you want to copy the style of one out of two widgets, that
have the same style set prior to realization but going to realize
with different depths?


> 
> Regards,
>                                         Owen
> 

---
ciaoTJ