Re: style->font

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> >  * Rename style->font to something private, and accessors
> >    gtk_style_get_font(), gtk_style_set_font(). This causes
> >    a lot of breakage, but it's breakage that can be fixed
> >    very mechanically. And we get the advantages:
> >    
> >     - We can emulate the current non-multihead safe behavior
> > 
> >     - We avoid loading style->font if nobody uses it; currently
> >       we always load it even if there is no legacy code accessing
> >       the style at all.
> > 
> >     - We can cleanly mark gtk_style_get/set_font as deprecated
> >       and not-multihead safe, something we can't do with
> >       direct style->font access.
> 
> can you extend on why gtk_style_get/set_font will have to be deprecated
> once we have multihead? since a realized widget can't move between
> displays, using gtk_style_set_font() on an _attached_ (realized) style
> should still be ok.

It needs to be deprecated because GdkFont is deprecated.

I'd want to mark it not-multihead-safe because:

  - GdkFont is deprecated
  - You should generally be using gtk_widget_modify_font() 
  - people frequently modify the font it on non-attached styles, which
    isn't multihead safe
  - We can't clear the font for the style on detach, because that
    would cause more incompatibility.

We don't _have_ to mark it non-multihead-safe, but I believe most
people are going to be use it in non-multihead ways, and the best
replacement for that is using something else than trying to fix
the usage to be multihead safe.

> >  * Try to fix the two problems piecemeal:
> > 
> >     - Always keep widget->style realized for the colormap for the
> >       widget. When the colormap for the widget changes, unrealize
> >       and realize the widget again. 
> >    
> >     - we keep a separately refenced copy of widget->font in
> >       style->internal_font and only NULL out style->font when
n> >       unrealizing a style if style->font == style->internal_font.
> >  
> >    Unfortunately, this is expensive and still leaves problems; 
> >    in particular, making gtk_style_copy() produce a realized style 
> >    doesn't work since every realized style must have an "owner" for properly
> >    maintaining style->attach_count. But it's reasonable to:
> 
> > Of these options, I slightly favor the the second, but I'm not very
> > happy about the amount of breakage involved. I'd appreciate any
> > feedback people have on this subject and especially better ideas about
> > how to handle this.

I've gone ahead and implemented the add-accessors and rename approach.
I'm holding off on committing until I have the PangoFont changes
mentioned in my other mail done so I can break everything at once
than having several sequential commits that break things.

Regards,
                                        Owen

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers