Re: style->font

[Tim Janik <timj gtk org>]

On 7 Sep 2001, Owen Taylor wrote:

> Possible fixes:
> 
>  * Remove style->font entirely. Tempting, but I think it would
>    increase the burden of porting existing code to GTK+-2.0
>    substantially.

i think we at least need to rename that field anyways, so code
portions that do the current style->font hackery get cought.
basically, i think that API which requires users to modify
structure components is broken in the first place, and we should
get rid of any of those. style->font is a good example why still
supporting structure poking is a maintenance nightmare.

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

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

a quick find+grep on my current GNOME CVS tree indicates that the
amount of breakage here is definitely moderately handable.
fixing anything in gimp and gnome-libs should be none issues as they
should be ported to 2.0 as cleanly as possible anyways, that leaves:
- 2 places in evolution, which you identified as buggy anyways
- 2 places in balsa
- 2 place in gnome-applets (battery, you identified that as well)
- 1 place in gnome-perl
- 2 places in gnome-python
and a couple similar places. overall, the impacts of renaming/getting rid of
style->font is about 1-2 changes for each project maintainer, which i think
is definitely bearable and has far lesser impact than other 2.0 porting
changes they need to worry about.
so basically, take my vote for breaking style->font in one way or another,
i.e. rename or removal. your third option doesn't sound so appealing to
me either, esp. as it still leaves us with some problems.

> 
> Thanks,
>                                         Owen
> 

---
ciaoTJ




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