Re: Getting rid of old home-grown FontSelector

[Lars Clausen <lrclause cs uiuc edu>]

On Tue, 25 Jun 2002, Cyrille Chepelov wrote:
> Le Mon, Jun 24, 2002, à 04:57:16PM -0500, Lars Clausen a écrit:
> > On Mon, 24 Jun 2002, Hans Breuer wrote:
> > > After fidling half the last night in widgets.c to make our home-grown
> > > FontSelector work with the recent DiaFont changes I've given up.
> >
> > I am thinking now that making style 0 be normal obliquity/normal weight
> > was a really bad decision.  It's better to have a linear scale for them
> > all.  (Argh!  Another change in font.h!).  The hack in
> > dia_font_selector_set_styles is an easy way to sort and remove
> > duplicates for styles.  A few fixes, and it seems quite workable.  I'll
> > commit after I'm done compiling (and making dinner, I'm afraid:)
> >
> > > Is there any reason we shouldn't use the standard GtkFontSelector and 
> > > integrate it into Dia like the GtkColorSelector ?
> >
> > The main reason I see is that we can avoid a complex window popping up
> > every time we want to change font.
>
> Could we add a [...] button to the right of the style combo (or stack them
> differently :
>       [ family combo     \/][...]
>       [ Style  \/][ size up/down])
>
> This [...] button would invoke a GtkFontSelector.

Maybe... though the size is a separate entry, so it would be difficult to
add there, unless we combine the two.  Which we really could -- I don't
think anybody allows one but not the other.

> Another suggestion: when there are more than $THRESHOLD fonts (like,
> twenty or thirty), is it possible to switch to an alphabetical
> menu/submenu thing ?
>
>  a --> arial
>  b     arial black 
>  c     avantgarde     
>  d
>  e
>  f
>
> (unavailable letters being simply hidden to avoid clutter).

Hmmm... not pretty either.  I for one lean towards allowing the user to
choose how many to see:  Just the sans, serif, etc, just the 'standard'
postscript fonts, just fonts that cover a certain range of chars, all
fonts... but that's an awful lot of choice to put on the user.

> > > If the answer is no, I'm ready to apply the new version which works,
> > > but needs some more graphical sugar (currently it only has a button 
> > > with the font description, but it could even draw this in the 
> > > respective font :-)
> >
> > Drawing it with the respective font is a bad idea -- some fonts
> > (e.g. dingbats) aren't readable as font names.
>
> What about drawing the button only with the respective font, and if the
> button is clicked, then drawing the menu with the regular font ?
>
> In case of a dingbat font, the selected entry will give the name. Or
> maybe we could interrogate the font for coverage of Roman script, and if
> not,...  no, wrong idea. Dingbat fonts lie about their coverage map.

Look, much as this is a fascinating idea to ponder, we have enough other
things to fix right now.  We should be happy that it works and look at
other stuff that doesn't -- such as non-left alignment in zoom != 100%.

I for instance just noticed that the standard Text object ignored the
settings from its defaults dialog -- change it to use the stdprops dialog,
and it works just fine.

-Lars


-- 
Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| Hårdgrim of Numenor
"I do not agree with a word that you say, but I   |----------------------------
will defend to the death your right to say it."   | Where are we going, and
    --Evelyn Beatrice Hall paraphrasing Voltaire  | what's with the handbasket?