On 26 Nov 2005, at 17:16, Nicolas Roard wrote:
This is why I'm concerned that we should -
1. keep the current interface as default
2. provide themes for the other interfaces
3. make switching VERY easy
4. try to make things interoperate as well as possible even when we
are not using themes to make things match.
Yes. There's actually three levels for good integration though:
- the look -- that will be managed via gsdrawfunctions, not really
a problem
- the feel -- more difficult; under windows you want menu-in-
windows, etc
- integration with system services like pasteboard, etc
I'm not sure how we can manage #2 and #3 ... one possibility would
be to have
so-called "desktop bundles" that modify classes to properly
integrate... and/or
have specific gorms for the platform..
Well ... integration with pasteboards, drag and drop etc is, and long
has been, the responsibility of the backend ... and while it may not
be working wonderfully for all systems, the basic idea is that
pasteboard and DnD should operate seamlessly in conjunction with the
native versions while retaining any extra functionality that the
OpenStep API provides ... at least, retaining the extra functionality
between GNUstep apps, it's impossible to guarantee more than the
'native' functionality between gnustep and non-gnustep apps.
The feel is tricky ... there are certain things we may not want to
give up or we may consider too horrible to do (for instance, I think
focus-follows-mouse in X may be one of those unless we figure out a
new focus/activation strategy), but others can be dealt with on an
individual basis and built into the theme engine as loadable code in
theme bundles. The current gui/backend architecture is a good
example of how this can be done ... major classes can implement
chunks of their functionality as methods sent to the current theme
engine. The default theme object would be set up to point to the
built-in implementations always present in the gui library. I don't
think we can realistically plan ahead on this completely ... but will
have to release new versions of the gui with new themable features
when we find we need them.
I'm unsure about how these methods would be best managed, but one
possibility would be for the theme creators to write subclasses of
standard gui classes which add no ivars ... so the theme engine could
load those subclasses in the bundle, get the pointers to the method
implementations and use them when the standard gui classes call the
methods in the them engine.
I'd quite enjoy writing code to handle loading/switching of themes
like that.
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
