Re: Getting rid of old home-grown FontSelector

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     

(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 Clausen (| 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?

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