[TransWarp] TransWarpGUI .. first success

[Ulrich Eck]

>
> I would recommend this approach in favor of __class_init__, because it
> means all the "active" components of a class can be found and activated
> with a single loop in the ActiveDescriptors metaclass.
>

Yep .. did that and works fine :)

> It should work.  Now, if the issue here is that at __init__, the
> component doesn't know who its 'getSEFparent()' is, then I understand.
> Still, you can use SEF.bindToNames() and SEF.Service to do most of the
> above, you would just move the loop to the setup method.
>

it is the getSEFparent() that would be needed.


> I probably should take a look and see if I can just let DynamicBinding
> objects take their parent as an __init__ parameter, as I've thought
> before this might be an issue.  At one time, though, I had Service being
> used as a mixin with classes that needed a different init signature...
> but I think it might be safe now to require a parent object to be passed
> in.

this would help a lot in this case...


>> - There is an ordering problem .. which Panel will be first in
>> newClass.__dict__.items() ?
>>   i will probably use the attribute guiObjects
>>   =['TreePanel','ListPanel']  to fix this.
>
> Use SEF.bindToNames('TreePanel','ListPanel').  This is a Once attribute
> that maps the names to a tuple of the actual objects.  It keeps you from
> needing an extra level of lookups at runtime.

the current use of the attribute 'childGUIObjects' (the actual name)
is only to define a list of names that should be initialized first
to maintain the order of several Notebook-Panels for example.

all other GUIObjects (attrName) are appended to the list through the
.activate() method. the .setup() method then walks through the list once
and initializes its childs.

this could all be done in __init__ if parent would be avaliable.
none of the .setup() methods have any necessary parameters.


>
>> after coming that far .. I'ld like to hear your comment.
>
> I like what I've seen so far.  I'd be *very* interested in looking at
> your code as a possible starting point for TW's "official" GUI framework
> at some point in the future, although I don't have a lot of time for GUI
> stuff right now.
>
thanks .. i like it too :))

I have set up a public cvs-server that is ready to go online tomorrow.
i called the package TransWarpGUI(TWGUI) .. hope this is ok.
I'll send the details, if everything is running smoothly.

>
> Well, I have some ideas for this, but they're not real specific as yet.
> Here's what I do know.
>
> First, windows can be Elements.  They're views onto Elements, and have
> the same dynamic of being created and destroyed by the application,
> rather than being part of the "application object" the way the main
> window and app components like Specialists are.  A view element needs to
> know its data element.  Field bindings can use standard SEF binding
> elements and capabilities to access features of an element, using a trick
> something like this:
>
> class aField(whatever):
>
>      DataOwner = SEF.bindToParent()
>
>      def fieldChanged(self):
>          element = self.DataOwner.Element
>          getattr(element.__class__, self.featureName).getMethod(element,
> 'set')(self.value)
>
> This assumes that 'aField' is placed directly inside an item that has an
> 'Element' attribute which is the element the form is bound to.

I have two sorts of Windows: a MainWindow and DialogWindows (could be a 
Document-
Windows as well). the first is base on GUIService, the second is based on
GUIElement.

A MainWindow has a WindowManager (what you suggested above with the 
Specialist)
that has very little functionality yet: it can open a new window and adds
a reference to a list of open windows.

DialogWindows as well es curtain sorts of Panels can have Elements.
There may be situations where one DialogWindow handles several,
different Elements...

there must be a very flexible way in mixing DataManagers and GUIObjects
to ensure that it coops with most GUI-Apps.
this should then probaly done by mixing the aspects through module-
inheritance.

perhaps one can achieve this through looking up a well-known-name
e.g. 'DataManager' or 'ElementManager' within the Object-Tree to get the
responsible DataManager .. i do the same to lookup EventDispatcher's.

>
> In practice, writing this example shows me that the framework really
> needs some kind of "more than once" attribute that is bound each time you
> use it, or that can be partially bound and leave some part of it dynamic.
> This would provide the necessary flexibility for something like a GUI
> where things "move around" more than in other application types.

could you give an example here ??


>
> However, until such time as I add those notions into TW proper, you can
> roll your own quite easily.
>
> First, dynamic binding.  Just use a Python 2.2 property object, e.g.:
>
> def computedBinding(self):
>      # compute it and return
>
> computedBinding = property(computedBinding)
>

everytime the "computedBinding"-property is __get__, the result
is computed (e.g. lookup Service, get-some-value).. right ??

> And to do a partially dynamic binding, just define an intermediate Once
> attribute for the static part, and then use a property to get it the rest
> of the way.
>

I cannot completely follow here.
What do you mean by: "define an intermediate Once attribute?

> So that leaves notification.  For that, you have to have an object that
> can hold a value, such as a form holding a data Element.  You could
> define it as a Feature, adding "subscribeTo" and "unsubscribeFrom" verbs
> to the Feature class, which would give the form "subscribeToElement" and
> "unsubscribeFromElement" methods.  You could then create a Once binding
> which subscribes to its targeted feature, with a callback that updates or
> deletes the binding when its targeted feature changes.

do you mean:
a DialogWindow or Panel has an feature called "Element" that exports
it's 'subscribeTo','unsubscribeFrom' methods to the Window/Panel ??

I have again here the problem that i cannot bring together the Feature
with the Once class .. could you give an abstract example here ?

>
> It's a bit more work, but the result is quite nice.  Heck, at this point
> I'm tempted to add an "SEF.ObservableFeature" class to the framework to
> support observable features like this in general...  it would really come
> in handy for GUI frameworks.  You could make your data elements have
> observable features themselves, so that your GUI would update whenever
> the underlying objects change.
>

yep .. this would be really nice.

> It almost makes me dizzy sometimes, thinking about the power of the
> TransWarp meta-framework, now that it's so close to being usable.  I knew
> in principle that all these things were possible with it, but it seems
> now like the reality is going to be so much more powerful than I really
> believed was possible.
>

:)) yes I'm fascinated too .. this is really a new style of coding ...

thanks for your help


Ulrich Eck
---------------------------------------------------------------------------
net-labs Systemhaus GmbH
Ebersberger Str. 46
85570 Markt Schwaben
fon:   +49-8121-4747-11
fax:   +49-8121-4747-77
email: ueck at net-labs.de
http://www.net-labs.de