Re: gnome-libs "rules of engagement"



>  1) Some of the changes required to get other modules to compile with
>  gnome-libs HEAD seems to be trivial(some, probably, not). Should the
>  task of fixing those compilation errors be left to modules
>  maintainers?

People should NOT depend on gnome-libs HEAD for their applications.
They should modify them ONLY when a stable/frozen version of the next
gnome-libs is released.  Otherwise we'll have the version creep and
instability problems we had before.

>  2) Is it time to start putting new stuff in the gnome-libs?  What I
>  have in mind is a solution to the hard coded fonts for canvas text
>  items.It is a bad practice, but it is especially bad for translations
>  to non Latin languages would. While the solution used in the
>  GnomeAbout box is not all that bad, in other programms we simply
>  replaced hard-coded fonts with hard-coded fontsets, which is not much
>  better!  At the time, I suggested a solution (which, accidently was
>  simular to what Changwoo Ryu had in mind as well):
>  
>   define a dummy Widget that will be getting set of standart fonts in
>  the same way as GnomeAbout widget does and use it inside yet another
>  gnome utility function, e.g.
>  
>  	GdkFont* gnome_font_style(const gchar *style);
>  
>  
>  Then you can have fonts defined for a set of standart styles in
>  gnome's gtkrc file e.g :
[snippety]

With respect to this I would prefer to do the right thing and wait for
Pango and GnomeFont.  On top of that we can build a GnomeStockFont
abstraction that gives you fonts for "normal text", "small titles",
"big titles", etc.

I assume Gtk+'s rc mechanism will change, too, when Pango is finished.

  Federico



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]