[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.allWindows
GUIWindow.viewSourceClass = JSCWindow;
GUIWindow.allWindows
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!).
hjh
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);
w.front;
)
changing to the JSC platform would simply imply changing the factory
to JSCGUIFactory:
(
var factory;
factory = JSCGUIFactory;
w = factory.createWindow;
factory.create(\Button, w);
w.front;
)
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.
2c
Till