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

[Anders Hellstrand]

URL:
  <http://savannah.gnu.org/bugs/?22278>

                 Summary: Nib reading issues with System fonts and button
borders
                 Project: GNUstep
            Submitted by: qmathe
            Submitted on: Sunday 02/10/2008 at 16:19
                Category: Gui/AppKit
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

GNUstep core and Gorm r26014

As you can see in the attached screenshot, when reading a nib system fonts
aren't decoded properly and therefore most labels and titles have their fonts
hardcoded. In the present case, the font is also two points bigger (14 instead
of 12 iirc) than what is expected.
Decoded buttons consist of a thin black and Aqua-shaped border instead of the
expected GNUstep button look. I'm also unable to restore the GNUstep look with
the NSButton inspector.

The nib is available here:
<http://svn.gna.org/viewcvs/etoile/branches/qmathe/Container/English.lproj/Inspector.nib>

Quentin.



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Sunday 02/10/2008 at 16:19  Name: nibReadingIssues1.png  Size: 14kB  
By: qmathe

<http://savannah.gnu.org/bugs/download.php?file_id=15011>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22278>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Anders Hellstrand]

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
initWithCoder:.

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.

G.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22278>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Anders Hellstrand]

Update of bug #22278 (project gnustep):

                  Status:                    None => In Progress            

    _______________________________________________________

Follow-up Comment #2:

I added a fallback in NSFont to handle requests for LucidaGrande that fail
due to a missing font, as requests for the default font. Hope this helps with
your problem.

Could you please describe which special cases are still open?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22278>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Anders Hellstrand]

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

Thanks for adding this new fallback. However I just tested it and I observe
no differences. Inspector.nib looks identical after updating gui. I get the
following logging (iirc the output was the same before updating):

// Launching Gorm
2008-02-15 01:24:22.775 Gorm[23749] Font not found Courier
2008-02-15 01:24:22.777 Gorm[23749] The font specified for
NSUserFixedPitchFont, Courier, can't be found.
// Opening a nib
2008-02-15 01:24:29.128 Gorm[23749] Font not found LucidaGrande
2008-02-15 01:24:29.228 Gorm[23749] Font not found LucidaGrande
2008-02-15 01:24:29.233 Gorm[23749] Font not found LucidaGrande

Helvetica is the only installed font on my test system, may be this can
explain why the fallback doesn't work in my case?

Thanks.



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22278>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Anders Hellstrand]

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

Oh yes, the warnign message will stay the same. This gets produced on a lower
level, in the backend. And of course this change wont help you to get any
other font displayed that you did not install :-)

I am not sure, what you are expecting. What is it that GNUstep should be
doing? When a font isn't installed we need to use a proper replacement, as you
only have one font installed there isn't much choice for GNUstep, what it
should be doing.

The patch I added should help in the case, where in the NIB file a bold
system font was saved on a Mac. In that case the available bold system font
will be chosen.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22278>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Anders Hellstrand]

Update of bug #22278 (project gnustep):

             Assigned to:                    None => FredKiefer            

    _______________________________________________________

Follow-up Comment #5:

Is it OK to close this bug report?
There is another open bug report on font size and I am not that sure what
else is still unresolved here.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22278>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Anders Hellstrand]

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

Yes, it's okay to close it.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22278>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Anders Hellstrand]

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

Unless Gorm/AppKit have recently changed, the button look issue isn't yet
fixed, so I would suggest to keep it open.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22278>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Anders Hellstrand]

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

I was thinking about this the other day.  The buttons should be drawn with
rounded edges, but in the next shading style not aqua but with a light border
on the top and shaded below, but still round.    

This is an "issue" in the sense that the button with rounded borders is
currently drawn with a solid border and not a properly shaded.

Additionally a "style" drop down needs to be added to Gorm to allow the use
of the various buttons styles that are now available.

G.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22278>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Anders Hellstrand]

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

It seems to me that the correct behaviour would be to:
- handle the different button styles, in that they have to be recognised by
the nib loading mechanism and by -gui (that's the case at the moment), and
their drawing delegated to the proper UI theme method
- in the theme code, have different methods for the different styles that a
theme can implements. By default all style simply call the square button theme
method (with the appropriate margin difference as iirc there is a margin with
NSRoundedBezelStyle buttons while there is no margin with
NSRegularSquareBezelStyle buttons)
- for the NeXT theme, there is NO rounded button. Therefore I think it would
make more sense to, basically, discard the rounded buttons and draw them
square, using the method exposed above. Other themes may or may not implement
a different look between square buttons and rounded buttons.

Make sense ?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22278>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Anders Hellstrand]

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

All styles should be expressed in all themes.   Cocoa actually supports many
different button styles, but the most used is the Aqua style.

The rounded buttons should be drawn in a more NeXT-ish way.  Currently, the
problem with them is that they're quite ugly and not shaded properly.

Do you feel strongly about pulling out the code that currently does this and
making them square?  Wouldn't it be acceptable to have NeXT-like
representations of things that didn't exist when NeXT was around, but that are
part of GNUstep?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22278>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Anders Hellstrand]

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

Well, what we need to have is mechanism to handle properly the different
styles, delegating the drawing to the current theme.

From that perspective, I agree that in general it would be good for themes to
implement all styles, so that UI explicitely using a specific style will look
ok using another theme; but in the case of the NeXT theme I don't think so, as
it would result in UIs rather different than what you'd have done by hand.

Let's see it that way -- the default buttons on OSX are rounded, so most
buttons use that style. The exact same UI, done manually on GNUstep, would
have square buttons, simply because the NeXT theme didn't have rounded buttons
as a default...

Using round buttons for the NeXT theme will simply give us UIs not looking
like NeXT, and that's the whole point of the NeXT theme !

Anyway, I believe this is something to be solved/decided in the theme, not in
-gui per se. -gui "only" have to handle the different style and delegate the
drawing.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22278>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Anders Hellstrand]

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

> Anyway, I believe this is something to be solved/decided in
> the theme, not in -gui per se. -gui "only" have to handle the
> different style and delegate the drawing.

Just to make this point clear: This is already decided in the theme not in
the NSButtonCell code of gui.

The method drawButton:in:view:style:state: of GSTheme does the border drawing
and has the special handling for round borders.
Are you now saying that the default theme is not NeXTish enough and we should
use square buttons all the time? This would be fine for me, although I would
prefer to see Gregs proposal being implemented, that is a nicer look for round
buttons.
But with that better drawing code in place it would be easy to come up with a
different theme :-)

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22278>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Anders Hellstrand]

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

Yes, I think the default theme should use square buttons all the time. The
only thing different we need to take into account is the margin (cf
http://www.webtogo.de/files/Stieber/Contacts-Linux.png vs
http://www.webtogo.de/files/Stieber/Contacts-Mac.png, the buttons touch each
other while on OSX there is a margin).

I'm not against having NeXT-ish round buttons, but that should go in another
theme :) ("Modern NeXT" ?). Take the sshots I link to above, the rounded
button is the default one on OSX, but the gnustep gui should be square,
really...

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22278>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Anders Hellstrand]

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

By this logic, we shouldn't have NSToolbar or NSOutlineView since neither of
them were present in OpenStep.  You only saw outline view in IB under OpenStep
because it was part of the NeXT private framework.

What we're really talking about is whether a theme which targets a given
environment should try to provide all widgets that are provided by GNUstep in
that environment, even when that environment may not have that given widget or
if the widget should be left out all together or replaced by something that is
in the target environment.

I believe that we should provide all widgets that GNUstep is capable of in
all themes.   That is to say, when a widget we have in GNUstep is not
something that was done by NeXT, then we should, in the NeXT theme, have
something which is it's "equivalent" which is done in the spirit of that
theme.

GJC

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22278>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Anders Hellstrand]

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

> By this logic, we shouldn't have NSToolbar or NSOutlineView
> since neither of them were present in OpenStep.

I disagree -- NSToolbar or NSOutlineView provide new functionalities, as such
we need to implement them. Different story, nothing to do with the way they
look (and actually NSToolbar does not look NeXT-ish and could certainly be
more integrated).

> What we're really talking about is whether a theme which
> targets a given environment should try to provide all widgets
> that are provided by GNUstep in that environment, even when
> that environment may not have that given widget or if the
> widget should be left out all together or replaced by
> something that is in the target environment.

A rounded button is a button, period. It's not a new widget -- it's purely an
appearance choice, there is no added functionality. As such it's entirely the
theme choice to decide what appearance should be displayed, and as the default
button on NeXT is square, not round, I really don't think we should have round
buttons *in the NeXT theme*, particularly if we take in account the rounded
style is the default one on OSX, so is used everywhere.

Other themes are more than welcome to use the added information to create
different appearances; but the NeXT theme should stick  to its own spirit.
It's important to not discard the added info, so that other themes can use it,
but that's all.

Again, check the two screenshots I added in the previous post; do you really
think those should be rounded buttons on GNUstep ? Even if we improve the
rounded look to be more "NeXT-ish" ? (and what's "more next-ish" when the
whole NeXT theme is about square blocks...). Would they have been rounded
buttons if done manually in Gorm ?

That's a theming issue, not a widget support issue.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22278>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Anders Hellstrand]

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

I believe that every theme should render every widget and style of that
widget in a way that is consistent within that theme.   That is to say that
the rounded button should render in a way that is consistent with the NeXT
look, but still obey the desire of the developer to make it rounded.

The current theme is the GNUstep theme, not the "NeXT" theme.  

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22278>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep