discuss-gnustep
[Top][All Lists]
Advanced

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

Re: NSMenu* and NSPopuUp* issues


From: Nicola Pero
Subject: Re: NSMenu* and NSPopuUp* issues
Date: Tue, 15 Apr 2003 08:48:15 +0100 (BST)

> > -gui should provide one (and only one) DEFAULT standard, good, and
> > consistent interface style.  Other interface styles are welcome with the
> > clause that they should be off by default, and the code reasonably good,
> > maintainable, well-integrated and non-destructive of other parts.
> 
> No, -gui should provide one, and only one, good and consistent
> interface. Anything else is a non-standard theme, and while we shouldn't
> deliberately prevent people from using themes (and should keep
> themability in mind when designing things internally, although it's a
> relatively low priority), the themes should not be part of -gui.

We seem to be inconsistent in our usage of the words "interface style"s,
"theme"s, etc.

To clean up things a little, given the default interface, we have two main
ways of changing it:

1 - changing the logic/semantics (eg, horizontal menus instead of
vertical, or drawing directories using a different font in the save panel)

2 - changing the look/appearance (eg, using a different texture pixmap for
button backgrounds).

I call a change as in 2 a 'theme', but I do *not* call a change as in 1 a
'theme'.

While I agree stuff like 2 can and should be regolamented into an API, and
you should be able to load (and turn on/off) bundles which implement
different themes/looks as per 2, I very much doubt it is a good idea to
load stuff like 1 from bundles.

It is difficult to set up a general framework for stuff like 1 - there is
no general framework.  It is easy to say you load a bundle which overrides
whatever -gui internals it needs to implement some stuff like 1 - but in
practice it looks like quite a horrible practice - if bundles override
parts of -gui internals, that might be difficult and ugly, they might mess
up things, or require the bundle to be rewritten every time a new -gui
version is out, or different bundles might override parts of -gui
internals in conflicting ways.

The good news is that the options in stuff such as 1 are much more limited
- we got very few requests for such changes in the past.  Horizontal menus
is probably one of the few requests.  We can try to filter down those
requests and only keep a very small and limited set of options.  That also
allows us more control on the possible semantics.

So, I'd say setting up things so that themes (as in 2) can be loaded from
bundles, and trying to limit and simplify the interface options (as in 1)
to a few options, and building those in -gui, so that you can switch
between them using user defaults, seems the best approach.





reply via email to

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