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

Re: [sc-dev] cross-platform gui wrappers - draft

On 11 Jan 2006, at 04:56, James Harkins wrote:

On Jan 10, 2006, at 3:51 PM, Till Bovermann wrote:

Why not using an which is configurable at runtime?
With a classVar in GUIWrapper?

That seems risky, especially for methods that access class variables belonging to SCWindow and such.

GUIWindow.viewSourceClass = SCWindow;

GUIWindow.viewSourceClass = JSCWindow;

I don't want to have to track down those bugs!

It's a gui platform, you should use one at a time.

Since I'm working in a heterogene environment (osX, LinuX, Win32) with one big cvs-repository (including our sc3 extension classes), I would prefer to have the possibility to change easily between the different GUI approaches, e.g. by setting them in my startup.rtf...

so it would be nice to have a switch changing to different gui systems when no window is open...
(is it possible to check for this easily?)

Why not naming the classes just View, Window, TabletView... instead of GUIView...?

I'm open to whatever naming convention people prefer.

Why not creating abstract classes for all nessecary GUI elements, and then inherit the original methods classes?

Not sure I follow you. The thought was to create a layer between the user and the gui objects (was it cx or blackrain who mentioned it first?). The layer's interface would be exactly the same across all gui platforms so there's only one interface to learn and code doesn't have to be rewritten. For SCView/JSCView not much problem, but the SCUM interface is quite different.

I just thought the other way round... my fault...

My main objective is, I want the guis in my library to work in Linux or Windows without maintaining multiple versions (that requires the cx guis to work too).

But extending the cross-platform lib is kindof a nasty thing (as you see in your work now... ;-)...

Marije mentioned (correctly) that scum-specific functionality should not be taken away. This approach works for that -- you can always use the gui classes directly, but you have a way to write cross-platform if you want.

In my approach (see below), I think one still has to write a wrapper for the SCUM classes...

Any other comments/criticism before I slog through the ^this methods (not looking forward to it!).


Yet Another Idea (using object factories):

supposing the following class structure:

------------- snip ------------------------------------
View {} // abstract
Window {} // abstract
Button {} // abstract

SCView : View {} // implemented
SCWindow : Window {} // implemented
SCButton : Button {} // implemented

JSCView : View {} // implemented
JSCWindow : Window {} // implemented
JSCButton : Button {} // implemented

GUIFactory { // abstract
	classvar guiSystem;
	guiSystem {^guiType};

I do not like the 'interpret' here, but since it is only at creation time...
	Any better idea is very appreciated ;-)
*createWindow{arg name = "panel", bounds, resizable = true, border = true; ^((guiSystem++"Window").interpret.new(name, bounds, resizable, border));
	*create{|type ... args|
		^((guiSystem++type).interpret.performList(\new, args));

SCGUIFactory {
	*initClass {
		guiSystem = \SC;

JSCGUIFactory {
	*initClass {
		guiSystem = \JSC;
---------------- snap -------------------------

this way setting up a new GUI fronend is easy: just implement the necessary classes, and you're done.

When writing a cross-platform GUI, only use the GUIFactory:
var factory;
factory = SCGUIFactory;

w = factory.createWindow;
factory.create(\Button, w);

changing to the JSC platform would simply imply changing the factory to JSCGUIFactory:
var factory;
factory = JSCGUIFactory;

w = factory.createWindow;
factory.create(\Button, w);

This way, you _are_ native at any time...
The above inheritance from basic GUI classes makes sure, that the desired methods (such as onClose_, valueAction, etc.) are available in all different GUI systems.