bugGNUstep - Bugs: bug #22278, Nib reading issues with System...

Group
 
 

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

Submitter:  Quentin Mathé <qmathe>
Submitted:  Sun 10 Feb 2008 04:19:17 PM UTC
   
 
Category:  Gui/AppKit Severity:  3 - Normal
Item Group:  Bug Status:  In Progress
Privacy:  Public Assigned to:  FredKiefer
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 21 Jul 2008 10:49:50 PM UTC, comment #16: 

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.

Gregory John Casamento <gcasa>
Group administrator
Mon 10 Mar 2008 04:28:33 PM UTC, comment #15: 


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

Nicolas Roard <rio>
Group Member
Mon 10 Mar 2008 04:07:21 PM UTC, comment #14: 

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

Gregory John Casamento <gcasa>
Group administrator
Mon 10 Mar 2008 12:00:50 PM UTC, comment #13: 

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

Nicolas Roard <rio>
Group Member
Mon 10 Mar 2008 08:14:52 AM UTC, comment #12: 


> 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 :-)

Fred Kiefer <FredKiefer>
Group Member
Mon 10 Mar 2008 02:36:12 AM UTC, comment #11: 

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.

Nicolas Roard <rio>
Group Member
Mon 10 Mar 2008 02:13:05 AM UTC, comment #10: 

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?

Gregory John Casamento <gcasa>
Group administrator
Mon 10 Mar 2008 01:16:34 AM UTC, comment #9: 

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 ?

Nicolas Roard <rio>
Group Member
Sun 09 Mar 2008 04:02:04 AM UTC, comment #8: 

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.

Gregory John Casamento <gcasa>
Group administrator
Sun 09 Mar 2008 01:41:00 AM UTC, comment #7: 

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

Quentin Mathé <qmathe>
Group Member
Thu 06 Mar 2008 12:47:56 PM UTC, comment #6: 

Yes, it's okay to close it.

Gregory John Casamento <gcasa>
Group administrator
Thu 06 Mar 2008 08:45:16 AM UTC, 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.

Fred Kiefer <FredKiefer>
Group Member
Sat 16 Feb 2008 03:34:09 PM UTC, comment #4: 

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.

Fred Kiefer <FredKiefer>
Group Member
Fri 15 Feb 2008 11:19:29 AM UTC, comment #3: 

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.


Quentin Mathé <qmathe>
Group Member
Mon 11 Feb 2008 11:14:21 PM UTC, 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?

Fred Kiefer <FredKiefer>
Group Member
Mon 11 Feb 2008 04:05:58 AM UTC, comment #1: 

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.

Gregory John Casamento <gcasa>
Group administrator
Sun 10 Feb 2008 04:19:17 PM UTC, original submission:  

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.

Quentin Mathé <qmathe>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #15011:  nibReadingIssues1.png added by qmathe (14KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rio (Posted a comment)
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by gcasa (Posted a comment)
  • -email is unavailable- added by qmathe (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-03-06 FredKiefer Assigned toNone FredKiefer
    2008-02-11 FredKiefer StatusNone In Progress
    2008-02-10 qmathe Attached File- Added nibReadingIssues1.png, #15011

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code