[Top][All Lists]

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

[bug #22278] Nib reading issues with System fonts and button borders

From: Gregory John Casamento
Subject: [bug #22278] Nib reading issues with System fonts and button borders
Date: Mon, 11 Feb 2008 04:05:58 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv: Gecko/20080201 Firefox/

Follow-up Comment #1, bug #22278 (project gnustep):

The font issue is part of a larger problem in NSFont which causes the font
selected to fall completely back to the system font when the requested font
cannot be found.

In a lot of cases nibs encode the font name directly (usually Lucida-Grande).
  No matter if this is bold, italic, whatever size... if the font is not
located the current NSFont code simply returns the system font and doesn't
attempt to try to do any kind of substitution.   The problem is in

The other issue is due to the style, which is encoded in the nib.  Mac OS
X/Cocoa actually contains the code to render buttons in the NeXTSTEP/OPENSTEP
fashion, it's just not used that often.   My work on nib creation showed this,
since the style used in our buttons is NSRegularSquareBezelStyle and the style
used by the Mac OS X/Cocoa is (usually, but not always) NSRoundedBezelStyle or
something similar.

The dilemma here is... do we respect the interface encoding or do we respect
the theme?   That is to say... if the style of the button is consistent with
OS X, should we override it and force it to use the square style if that
doesn't fit with the current theme?

While the first part of this submission is definitely a bug (font
substitution is something we need) the second part is more debatable and is a
matter for further consideration.



Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]