mindwrapper-users — Open discussion of Mindwrapper

[Mindwrapper] this is a test

[Donnal W. <don...@ya...>]

wondering if this user list is still active

[Mindwrapper] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

[Mindwrapper] newborn (patient) registration

[Donnal W. <don...@ya...>]

This morning I checked-in the most recent changes (0.1.11) which
include the patient registration sample. You can find it under

samples/newborn

It is only a preliminary version without protections against user
error and so on, but nevertheless it demonstrates how I understand
a database will work in MW.

Also included is the start of a test suite for the PL:

samples/testsuite

Enjoy,

=====
Donnal Walter
Arkansas Children's Hospital

[Mindwrapper] 'text' in Choice presenter as a controller

[Donnal W. <don...@ya...>]

When a Choice presenter is used to enter data into a Text cell, the
list of choices is determined by the 'choices' parameter for the
cell in the *abstraction layer* like so:

    def Assemble(self):
        self.Add(node=mw.Text, name='sex',
                 choices=['Unknown', 'Male', 'Female'])

But when a Choice presenter is used to control other aspects of the
user-interface (with no direct connection to the abstraction layer)
it might be more appropriate to define the list of choices via some
parameter in the *presentation layer*. The logical name would seem
to be 'choices', but the Choice presenter is one of the few
presenters that would need this parameter, and when it does, the
'text' parameter would never be used in that situation.

So here is my suggestion. Would it seem too awkward to use the
'text' parameter for a list of choices?

    def Assemble(self, db=al.AL(), pt=al.PtInfo()):
        self.Add(
            node = self.ListBySelector,
            text = ['Sort list by last name',
                    'Sort list by first name',
                    'Sort list by bed number',
                    'Sort list by time of birth'],
            size = (200, -1),
            margin = 10,
            ref = [db.sortby, db.ptlist])

    class ListBySelector(mw.Choice):
        ...

Any problems with this syntax?

Cheers

=====
Donnal Walter
Arkansas Children's Hospital

[Mindwrapper] issues update (Sun 04/20)

[Donnal W. <don...@ya...>]

In ten days (04/30) I will be leaving town for a few days, and the
day after I return (05/05) I go back "on service", so I'd like to
work through as many issues this week (and early next) as possible.

==============
Today's topics
  1. Notifying observers
  2. Passing references to presenters
  3. Revised (or new) Tree presenter
  4. Revising wx.TextCtrl-based presenters
  5. MultiColumnList presenter
  6. Models and composite presenters

==============
1. Notifying observers

The current version of MW uses a "pull" technique for notifying
observers that a change has occurred in an abstraction layer (AL)
node (especially a cell). The notification code sends no direct
information to the observers, so each observer must pull the
information it needs from the relevant nodes (cells). IMO this has
worked fine for dependent cells and component observers in the
presentation layer (PL), but we have had some recent discussions
regarding presenters such as ListBox and Tree needing more
information about the initiating node.

Except for breaking MW notation written up to now (and it is still
early), I don't see much disadvantage in modifying the observer
notification code so that the initiating node is passed to the
observer. The observer is free to ignore this information, of
course, but it would be available if needed.

    def _notifyObservers(self):
        for w in self._observers:
            w().Update(self)
                       ^^^^
                       "self" here is the initiating node.

Then the Update signature becomes:

    def Update(self, node):
        pass

The main motivation for considering this change is not that I think
the pull technique is inadequate for individual nodes, but Tree
presenter, for example, might need to know when a given node is
changed in order to update its display state. This requires sending
the notification (including the identity of the originating node)
down the tree toward the root. I plan to integrate the _smudge()
method into the implementation.

As I said above, this would break existing code, but since we are
still pre-alpha I would rather do it now.

==============
2. Passing references to presenters

I won't repeat yesterday's posting about this topic, but I am
adding it to the active issues list. Having slept on it, however, I
now see that sending the event as well as the list of references
should be a given. It will often be ignored, but it is easier to
disregard unneeded information than to manufacture unknown
information.

    def _onEvent(self, event):
        self.OnEvent(event, *self._ref)
        event.Skip()

    def OnEvent(self, event, model, arg1, arg2):
        # this method overridden to do something
        #   with model, arguments and event

==============
3. Revised (or new) Tree presenter

The original Tree presenter was designed to traverse the AL object
tree for easy display. That is why the node names were given. But
in all likelihood, the MW user will rarely use the Tree presenter
for this purpose. We need to think about the actual use cases for
this presenter and come up with a notation that will best
facilitate this use. In particular, I am interested in whether this
presenter needs an Assemble() method or not. Then, of course, we
will implement the notation that we decide upon, whatever that is.

It is not clear to me whether or not we can get by with a single
presenter for this purpose (with different input parameters) or
whether it might not be desirable to have separate presenters for
different purposes.

This brings up the whole philosophical debate of when to use
special purpose presenters of any kind versus adding specialization
parameters for general presenters. TextField and NumberField are
natural, for example, but is TextArea necessary or could we simply
let TextField know that it is supposed to be mulit-line? More to
the point, is TextReader a good idea, or should we simply use the
READONLY style?

==============
4. Revising wx.TextCtrl-based presenters

All of which brings up the task of revising the presenters based on
wx.TextCtrl. I plan to keep TextField, NumberField, TimeField, and
DateField, but I am inclined to drop TextReader and add a
mw.READONLY style parameter. OTOH, I believe that TextArea
(*without* adding a mw.MULTILINE parameter) would still be
appropriate.

==============
5. MultiColumnList presenter

The MultiColumnList MCL is supposed to wrap the wx.ListCtrl.
Although I may not try to implement it this week, the reason I
bring it up here is to bring up the possibility of folding it into
the ListBox presenter. What if MCL could be a ListBox with cols =
n, for example. Just something to think about while working on
ListBox.

==============
6. Models and composite presenters

In the "traditional MVC architecture" (if there is such a thing)
the models are supposed to be "pluggable", meaning that you can
remove a given model (instance) from its view and replace it with a
different instance. In MW's MVP architecture it would be feasible
to do the same for Text cells and TextFields, for example, but a
major feature of the MW approach is creating composite presenters
(Panels, for example) with complex underlying data models. The
relationships between presenters and models are defined in the
nested Assemble() methods, and created during initialization. This
powerful technique of establishing intricate interconnections
between presenters and models promotes an evolutionary development
strategy and simplifies code maintenance. IOW it is intended to
make design-time tasks easier. The weakness of this approach,
however, is that *at runtime* the connections are rather "tightly
coupled". This means that there is no easy way to plug a new
instance of a complex model into an existing composite presenter.

My way of thinking about this issue has been to accept the fact
that after initialization the model is a permanent fixture in the
presenter and simply move the data to and from persistent data
objects using the Inform() method. It has now occurred to me that
either I need to formalize this mechanism to make it more obvious,
or perhaps reconsider the whole MVP architecture (which I am
somewhat loathe to do).

==============
Active Issues:
  - Notifying observers
      - 2003-04-20 Topic 1
  - Passing references to presenters
      - 2003-04-20 Topic 2
  - Revised (or new) Tree presenter
      - 2003-04-20 Topic 3
  - Revising wx.TextCtrl-based presenters
      - 2003-04-20 Topic 4
  - MultiColumnList presenter
      - 2003-04-20 Topic 5
  - Models and composite presenters
      - 2003-04-20 Topic 6

Regards,

=====
Donnal Walter
Arkansas Children's Hospital

[Mindwrapper] proposed changes in presenters

[Donnal W. <don...@ya...>]

This is just to give everyone a heads up that I intend to make
significant changes in how references are used by presenters in the
near future. The current way that component presenters (like
TextField and SpinButton) work is that they accept a single 'ref'
argument to be the model (from the abstraction layer) for that
presenter.

The proposed change is to allow all presenters (both components and
composites) to accept a list of references, the FIRST of which will
act as the model for the presenter. Other references in the list
will form the arguments for event handlers, so that it will be
easier to write event handlers. The prototype for this technique: 

        ...
        wx.EVT_XXX(self, self.GetId(), self._onEvent)

    def _onEvent(self, event):
        self.OnEvent(*self._ref)
        event.Skip()

    def OnEvent(self, model, arg1, arg2):
        # this method overridden to do something
        #   with model and other arguments

An alternative would be to pass the event to OnEvent() as well:

    def _onEvent(self, event):
        self.OnEvent(event, *self._ref)
        event.Skip()

    def OnEvent(self, event, model, arg1, arg2):
        # this method overridden to do something
        #   with model, arguments and event


Regards,

=====
Donnal Walter
Arkansas Children's Hospital

[Mindwrapper] sorting listnodes

[Donnal W. <don...@ya...>]

I probably won't check in the revised branch module today, because
I want to change the observable mechanism for listnode first, but
today I added two new methods to listnode: 

    def Sorted(self, apath=''):
        temp = [(_getapathval(o, apath), o) for o in self]
        temp.sort()
        return [t[1] for t in temp]

    def Sort(self, apath=''):
        self[:] = self.Sorted(apath)

The Sorted() method returns a list that is sorted on any arbitrary
attribute path in each item, while Sort() sorts the listnode in
place using the same criteria. Usage would be like this:

    x.Sort('id.name.last')
or
    y = x.Sorted('id.name.last')


The _getapathval() function returns the value of the node specified
by the attribute path (apath) string. It is defined as:

def _getapathval(obj, apath):
    if apath:
        for attr in apath.split('.'):
            obj = getattr(obj, attr)
    return obj.Get()

The sort methods use the "decorate-sort-undecorate" (DSU) idiom
found in PythonIAN pp 400-401. This provides an efficient way of
sorting on any arbitrary components of the list items.

Regards,

=====
Donnal Walter
Arkansas Children's Hospital

[Mindwrapper] GetParent, GetRoot, dirt flag

[Donnal W. <don...@ya...>]

OK, I've made a few of the requested changes. I thought it would be
simple to start with GetParent(). The first problem, though, is
that the self._parent attribute is a node, so every recursive
function that looks for nodes in the tree tries to act upon this
attribute as well, and the result is infinite recursion. No
problem: just test to see of the name is '_parent', and if so
ignore it, right? But this is an ugly hack IMO, so I changed all
occurrences of:

  isinstance(attr, node),
to
  name[0] != '_'.

This is still not elegant, but neither was type testing, and it is
cleaner this way. This approach means that every attribute of a
branch object that does NOT begin with '_' is assumed to be another
node.

At first I was going to put a set of unittests for GetParent() in a
separate file, but it was easier (and probably more appropriate, as
well) to add the various tests to existing files. I may not have
thought of every contingency, but all the initial tests passed.

At the same time I added GetRoot(). I don't know if this needs to
be part of the public API, but the user-developer might need this
as much as GetParent() so I put it in. In any case,
Document.Retrieve() does need self._root.  GetParent() and
GetRoot() are not only necessary for the public API, they should be
used in subclasses, too.

One complication that took me awhile to figure out is that
initially I made a root node have parent == self and root == self.
This is a self-reference, which in and of itself would be no
problem. BUT, this does mean that the object doesn't get garbage
collected immediately, so my weak referencing scheme for observers
gave me an error in the regression tests. The eventual solution was
to set make the parent equal to None in the root node and then
RETURN self if parent (or root) is equal to None.

I also added the dirty flag which gets set whenever a value is
change and then sends it back down the tree toward the root. The
relevant methods are _smear(), _clean(), IsClean().

I believe that all the changes are now in CVS on Sourceforge.

Regards,



=====
Donnal Walter
Arkansas Children's Hospital

[Mindwrapper] Re: issue list

[Toni B. <ton...@sw...>]

> Yes, it may be overkill, but even when I was doing ALL of the
> development myself for months, using an issue tracker, as crude as
> it may have been, was helpful. We shall see.

I do think personal issue tracker are essential. But for that
is my whiteboard or a textfile. What I meant with overkill is
to use a webbased tool. Since I think it is much more cumbersome.
Even if we would start to use rebound or some other tool, I would
mainly use my whitheboard or textfiel for my daily work.
The main advantage with a central issue tracker I think is that
you can keep track of who is responsible of an issue. Not a problem
if you are 2 persons. Also that you can assign an issue to somebody
else and you have automatic mail going out. And so on.
But i feel that all of those advantages are not a problem if you
are 2 people as long as you have any personal tracker.

> > I also think that we the open issues we have right now is more to
> > decide if and what to implement. The implementation in itself
> > would be quite quick i think.
>
> Yes, most of the open issues are fairly straightforward, but for
> the moment I would like to do the implementations: (1) so that I
> can run all of the regression tests against the changes, and (2) to
> add new unittests for the additions (and possibly (3) so I know
> what is going on.<grin>).

Ok, just inform me when you have implemented any of them
into cvs.

-- 
Toni Brkic  
ton...@sw...
Switchcore, Lund, Sweden 

[Mindwrapper] Re: issue list

[Donnal W. <don...@ya...>]

--- Toni Brkic <ton...@sw...> wrote:
> > more appropriate, but if others become interested at some
> > point, maybe we should have more of our discussions on the
> > Mindwrapper mailing list or on the forum.
> >
> > https://sourceforge.net/mail/?group_id=64929
> 
> I think this is a good idea. But a requirement for me is that
> I am able to use my own email client. So is there a email
> address for the sourceforge group? Actually I just found
> out that there is and I will cc this email there.
> >
> > Finally, I thought about trying out:
> > http://www.elementool.com
> 
> About the issue trackers I liked roundup best. Elementool seem
> quite good as well. But I think that it is overkill since it is
> only us two that develop right now.

Yes, it may be overkill, but even when I was doing ALL of the
development myself for months, using an issue tracker, as crude as
it may have been, was helpful. We shall see.

> ... So I would suggest that we
> right now use email but do a cc to the sourceforge group. I think
> it is enogh to convince other people that the project is alive
> and kicking. If there is more people joining we could then
> install a issue tracker.
> 
> I also think that we the open issues we have right now is more to
> decide if and what to implement. The implementation in itself
> would be quite quick i think. 

Yes, most of the open issues are fairly straightforward, but for
the moment I would like to do the implementations: (1) so that I
can run all of the regression tests against the changes, and (2) to
add new unittests for the additions (and possibly (3) so I know
what is going on.<grin>).  

> I am probably working with MW this weekend and maybe tonight.
> If you want me to implement any of the issues I would be happy
> to . 
> 
> Otherwise my plan is to wait with the addressbook until the issue
> with 'linking' is solved. Instead I might do a core for the demo,
> that is to do the startup where you traverse all subdirectories
> to find out the samples and create the AL from that and a
> corresponding PL treeview of all the samples.

That sounds like a good plan.

> Or I will maybe start on the AL/PL for my register file
> generator.

Or this too. :-)

Regards,


=====
Donnal Walter
Arkansas Children's Hospital

[Mindwrapper] Re: issue list

[Toni B. <ton...@sw...>]

> more appropriate, but if others become interested at some point,
> maybe we should have more of our discussions on the Mindwrapper
> mailing list or on the forum.
>
> https://sourceforge.net/mail/?group_id=64929
> https://sourceforge.net/forum/?group_id=64929

I think this is a good idea. But a requirement for me is that
I am able to use my own email client. So is there a email
address for the sourceforge group? Actually I just found
out that there is and I will cc this email there.
>
> Finally, I thought about trying out:
> http://www.elementool.com

About the issue trackers I liked roundup best. Elementool seem
quite good aswell. 
But I think that it is overkill since it is only us two that develop right 
now. So I would suggest that we right now use email but do a cc to
the sourceforge group. I think it is enogh to convince other people that 
the project is alive and kicking. If there is more people joining
we could then install a issue tracker.

I also think that we the open issues we have right now is more to decide if 
and what to implement. The implementation in itself would be quite quick i
think. 

I am probably working with MW this weekend and maybe tonight.
If you want me to implement any of the issues I would be happy
to . 

Otherwise my plan is to wait with the addressbook until the issue
with 'linking' is solved. Instead I might do a core for the demo,
that is to do the startup where you traverse all subdirectories to
find out the samples and create the AL from that and a corresponding
PL treeview of all the samples.

Or I will maybe start on the AL/PL for my register file generator.

/Toni

-- 
Toni Brkic  
ton...@sw...
Switchcore, Lund, Sweden 

[Mindwrapper] Web site down temporarily

[Donnal W. <don...@ya...>]

Due to a server change, http://mindwrapper.org may be temporarily
unavailable. It should be available again soon, but in the meantime
the site can always be found at:

http://mindwrapper.donnal.net

=====
Donnal Walter
Arkansas Children's Hospital

[Mindwrapper] 0.1.05 now in CVS

[Donnal W. <do...@do...>]

The changes for version 0.1.05 have been committed to the CVS
repository on SourceForge.

Donnal Walter
Arkansas Children's Hospital

Change Log:
==================================================================
Mindwrapper 0.1.05  2003-03-30
==================================================================
2002-03-27 -------------------------------------------------------
- Applied a patch submitted by Toni Prkic to field.py
  NumberField changes value when Return pressed, and
  fields do not update their value unless the model value changed

2002-03-27 -------------------------------------------------------
- adopted the new wx package for wxPython,
  so wx.wxFrame becomes wx.Frame

==================================================================
Mindwrapper 0.1.04  2003-03-26
==================================================================
2002-03-26 -------------------------------------------------------
- added samples.pkinetics.timing.py to the manifest

==================================================================
Mindwrapper 0.1.03  2003-03-26
==================================================================
2002-03-26 -------------------------------------------------------
- changed node._isFree to node._isData
- changed node._reset to node.Reset, node._inform to node.Inform

2002-03-25 -------------------------------------------------------
- added TimingPanel to samples.pkinetics
- fixed abstraction.branch._inform to allow copy from a dependent
  cell to an independent cell of the same name (within a branch)

2002-03-24 -------------------------------------------------------
- added __version__.py to Mindwrapper package
- changed "ref=[]" to "ref = None" in abstraction.cell.__init__()
- changed util.aslist(arg) to return [] if arg is None

==================================================================
Mindwrapper 0.1.02  2003-03-19
==================================================================

[Mindwrapper] [Ann] Mindwrapper 0.1.02

[Donnal W. <don...@ya...>]

"Python wrappers for the way(s) you think."

Announcing the first public release of Mindwrapper 0.1.02.
Mindwrapper is an experimental framework/notation for developing
custom clinical applications using wxPython 2.4.0 for Python 2.2.2.
The University of Arkansas has authorized a BSD-style open-source
license.

Of interest to the wxPython community may be the implementation of
a model-view-presenter (MVP) architecture similar to the MVP
pattern pioneered by Dolphin Smalltalk. Under Mindwrapper's MVP
framework, each wxPython 'View' is wrapped in a 'Presenter' that
takes care of linking to a 'Model' as well as event handling and
layout. This architecture makes sizers transparent and perfectly
painless.

Mindwrapper applications are single-tiered and bi-layered.

The *abstraction layer* consists of one or more structured data
documents. Documents are tree-graphs in which the leaf nodes
(called cells) are automatically observable. The framework
implements component binding and naming within a hierarchy of
cells, branches and run-time lists of branches. Cells, branches and
lists may be independent, or they may be dependent upon named cells
and/or branches within the document. Two or more lists may share
items (encapsulated branches). Mindwrapper Documents are persistent
(with support for inclusion in Cabinets and Folders).

The *presentation layer* consists of a tree-graph of Presenters,
which wrap Views and link to Models in the abstraction layer. The
framework implements component binding and naming within a
hierarchy of presenters. Each composite presenter (Frame, Panel)
handles layout by automatically adding components to a sizer using
parameters that are more intuitive than those in native wxPython
(IMHO). Component presenters handle event binding and setting up
bi-directional links to cells in the abstraction layer.

Mindwrapper is highly object-oriented, encouraging encapsulation
through extensive use of inheritance and polymorphism.

CAVEAT: Mindwrapper is a research project and should be considered
*experimental* in nature. Furthermore, in the spirit of 'release
early, release often', this version is pre-alpha. The API is not
yet stable, and the current documentation is incomplete.

Mindwrapper home page:
http://www.mindwrapper.org/

Mini-tutorial with screenshots:
http://www.mindwrapper.org/prelim/pretutorial.html

Download from SourceForge (FTP or CVS):
https://sourceforge.net/projects/mindwrapper/



=====
Donnal Walter
Arkansas Children's Hospital