SystemSpecifyer, was Re: [ZODB-Dev] How to predict George Bailey?

[Magnus Lycka]

At 14:31 2002-11-03 -0200, Christian Reis wrote:
>Is holding object references over undo really a big issue for you?

I don't really know. I certainly want the GUI to remain the
same if it can while I perform undo, and I want the shortest
possible delay. But perhaps dropping everything and picking
it up again is faster than to check it I'm a affected by a
change. I doubt it though.

The big issues reagard functionality, not implementation. It
felt natural to code like this. For me, this isn't first of
all a ZODB application, it's an OO Python application that
happens to use ZODB for persistence.

I guess I could remember my application OID instead of
keeping an object reference in the GUI code, but then I'd
have to search and retrieve hundreds objects all the time.

>Is it
>because you are editing the same object as is displayed in other parts
>of the interface?

Yes, at least partly. But even if I only have one object in
one window, I might want to go on displaying and working with
it across transactions and undos.

Let's pretend this is a word processor. Should I drop and
reload my document every time I press Ctrl-S or Ctrl-Z?

>I am trying to get a use pattern clear from your
>issues, but I can't seem to - can you show a concrete example (i.e.
>window X presents object, window Y edits it, then Z happens, etc) so I
>can understand better the issue?

As I understand, my customer is presently setting up a
sourceforge project, so I guess it's no secret what we
do. :)

The system is used to describe systems: whether it is
software, process industries, armies or systems for
handling radioactive waste... It's typically used for
complex systems that have to be very well understood.

I hope that whoever is interested will be able to try
it out in a few days.

There are three important types of windows:
SystemMatrix windows, Detail windows and Tree windows.

Let's imagine we show the object tree, an SMX containing
the object "Wheel" etc and the detail views for the (so far
unrelated) objects "Wheel" and "Car". Lets mark the "Wheel"
object in the tree, and drag it to the consists-of list
in "Car" and drop it there. The text "Wheel" will show in
green in the list. Then press the 'Apply' button in the "Car"
detail window. The green text will turn black, and "Car" will
appear in the part-of list in the "Wheel" detail window. The
tree will also change, moving "Wheel" from the root to sit
below "Car". In the SMX window, the text "Wheel" has been
replaced with "Wheel < Car".

Later we realize that we need other kinds of wheels as well
in the system, and we prefer to use different names to avoid
confusion. Since we are currently working in the SMX window,
we go to the object catalog, and change "Wheel" to "Car Wheel".
When we press Enter, the text will change in the object tree
as well as in the two object detail windows mentioned above.

I imagine this wasn't very clear unless you read the long
story below...

The SystemMatrix (SMX) windows show what functions, objects
and conditions or states are relevant for a part of the
system, and how they relate to each other. Functions,
objects and conditions/states are shown in three "catalogs".
Relations between functions and objects (input, output etc)
is described in the "process matrix", and relations between
functions and conditions (think about program flow, in what
order do activities take place under different conditions?)
is described in the "control matrix".

Below, I sometimes use the term "element" to mean any of
object, function or condition.

A typical SMX holds references to several tens of elements,
and to the matrices that record their process and control
relations.

The tree windows will typically show the whole Function or Object
structure. (It's really a DAG, so duplicates can occur in the
tree.) They can also show a part of the function or object tree.

A typical tree window holds references to hundreds or maybe
thousands of objects or functions. All in the system. (I'll
do something eventually to make largely collaped trees faster
for large systems, but they can always be fully expanded...)

The detail views show the details for one element. Type, name,
change data, description, names of parents and children in the
DAG  (not for conditions--they are only values for properties of
an object. No structure there), and properties (if it's an object).

I make sure not to open duplicate windows, so if a detail
window for an object is opened from an SMX window, and then
a bit later, details for the same object are requested from a
tree window, I'll just raise that detail window instead of
opening a duplicate.

Everything isn't finished yet, but basically, many things can
happen in many windows, and it typically influences something
else.

Below, [S, D] means that an operations might change another [S]MX
and/or [D]etail window, but not any [T]ree.

SMX Window:
* Create new element (by typing a new name in a catalog). [S, T, D]
* Remove element from this module. [S, T, D]
* Remove element from the database. [S, T, D]
* Change type code and/or name of an element. [S, T, D]
* Move things around in the catalogs.
* Change the function structure (by adding or removing functions) [S, T, D]
* Change control and process matrices. [S]
* Open detail windows for element. [D]
* Move around in the function structure (switching SMX).
* Open new SMX windows for parent or child functions. [S]
* The SMX windows also have a menu bar where you can save
   and quit, open tree and empty detail windows etc. [S, T, D]

Tree widgets:
* Expand and collapse function or object strucures.
* Open detail windows or SMX windows. [S, D]
* Change structure with drag and drop. [S, D]

Detail windows:
* Open other windows of all sorts for related elements. [D, T, S]
* Change any attribute for element. [D, T, S]
* Structure can be changed by dropping elements into
   the part-of or consists-of list, or by pressing delete. [D, T, S]

As you see (if you managed to get through all this) names
and type code can be changed in two places, relations
between elements might change in all sorts of windows,
and obviously we want these changes to be reflected in
all relevant parts of the system.

Drag and drop will be used extensively. Today it's only
partly implemented. (I can currently drag from tree to
SMX or detail.) Full d'n'd support is sceduled for next
week.

This is a system you want a big screen for... Typcially
you have two trees with hundred of items, at least one,
but often two SMX windows and very possibly several detail
windows open at the same time. It has to be as smooth as
possible to change things. You shouldn't have to switch to
another windows if it's logically reasonable to perform an
operation in the active window.

Besides the editing features, the application will perform
checks on the system to see if it's complete, consistent
and correct. You can also "run" the control matrix by
single-stepping in it almost like in a debugger.


-- 
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/  mailto:magnus@thinkware.se