discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Clash of the Titans, GNUstep alongside GNOME


From: Richard Frith-Macdonald
Subject: Re: Clash of the Titans, GNUstep alongside GNOME
Date: Sat, 26 Nov 2005 19:14:29 +0000


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.








reply via email to

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