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

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

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.

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 ?

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

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.

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.

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.