mindwrapper-users Mailing List for Mindwrapper
Status: Alpha
Brought to you by:
donnal
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
(2) |
Apr
(10) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Donnal W. <don...@ya...> - 2009-01-28 02:32:44
|
wondering if this user list is still active |
From: <ben...@id...> - 2004-05-22 13:50:50
|
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 _______________________________________________________________________ |
From: Donnal W. <don...@ya...> - 2003-04-25 16:17:12
|
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 |
From: Donnal W. <don...@ya...> - 2003-04-22 05:12:51
|
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 |
From: Donnal W. <don...@ya...> - 2003-04-20 13:22:46
|
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 |
From: Donnal W. <don...@ya...> - 2003-04-19 14:55:51
|
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 |
From: Donnal W. <don...@ya...> - 2003-04-17 20:38:38
|
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 |
From: Donnal W. <don...@ya...> - 2003-04-12 04:09:12
|
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 |
From: Toni B. <ton...@sw...> - 2003-04-10 17:54:01
|
> 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 |
From: Donnal W. <don...@ya...> - 2003-04-10 16:38:55
|
--- 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 |
From: Toni B. <ton...@sw...> - 2003-04-10 15:13:25
|
> 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 |
From: Donnal W. <don...@ya...> - 2003-04-04 22:12:54
|
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 |
From: Donnal W. <do...@do...> - 2003-03-30 23:17:31
|
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 ================================================================== |
From: Donnal W. <don...@ya...> - 2003-03-23 22:43:32
|
"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 |