Re: Clash of the Titans, GNUstep alongside GNOME

[Richard Frith-Macdonald]

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.