[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] Re: cross-platform gui wrappers - draft
Hey all, sciss, jh, stefan,
On 13 Jan 2006, at 12:19, contact@xxxxxxxx wrote:
hi till,
i agree widely with your approach ; i think the factory thing is
the best and easiest to do. i suggest however that the *create
methods are not class methods that use strings and interpete.
instead you create an instance of a factory. this solves the
problem of switching between GUI kits at runtime and you can easier
use different GUIs at the same time (nice for debugging ;-). my
suggestion is a separate .SC attachment.
I like your approach, especially the subclassResponsibility thingy I
didn't kow about before ;-)
What I do not like is the "implements" array, which has to be filled
by the developer by hand...
Is there a way to automate this?
(e.g. by scanning the list of methods implemented by the specific
subclass for methods named create*, substituting creat from it and -
voila: the name.)
here's a small example code:
(
// this could go in the startup script
GUIFactory.default = JSCGUIFactory;
// we should add a default in the class itself...
f = GUIFactory.newDefault; // --> a JSCGUIFactory
// give me any factory that can handle windows and multisliders
g = GUIFactory.newFor([ \window, \multiSliderView ]); // --> a
SCGUIFactory;
w = f.createWindow( "Default", Rect( 100, 400, 300, 300 ));
w.front;
// my interpret-approach makes these methods obsolete... on the other
hand this one is faster and nicer
// and the user (is able to) know exactly which gui components are
there for the specific GUI-framework.
w = g.createWindow( "Specific", Rect( 500, 400, 300, 300 ));
m = g.createMultiSliderView( w, Rect( 30, 30, 240, 240 ));
w.front;
)
of course this *newFor is more a gimmick i guess.
Perhaps it's not for jh dewdrop-related gui-problem... apropos: what
are you thinking about this, jh?
i know really little about SCUM. but now that we are creating these
meta classes, it would be cool not to miss any of the strong points
of it ; so the question is if there are any gadget classes in SCUM
that would be worth to include in a factory, even if Cocoa GUI
doesn't support them (YET). there was some talk about a Bang class,
maybe one should add those extra classes as well.
i don't know if it's a more difficult thing, but i guess one should
also talk about layout managers (all the SCCompositeView
subclasses). maybe there are some alternatively concepts in SCUM
that one could adapt, too (for automatic box resizing or alignments
for example).
best, -sciss-
<GUIFactory.sc>
btw: do you use DoxyGen for API Generating sc-code?
is there a special parser needed?
have a nice day
Till