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?