Hi level programming strategies

wxPython Users
1

Hi, I have some questions about high level programming strategies which have been bothering me for some time.
I'm interested in writing tools for technical design, such as vector drawing, mechanical, ee, etc. My first attempt is just a wxpython program that allows you to draw circles, boxes, etc. Of course this has been done a million times, but I want this as an exercise, and to see if I can do it "my" way.

However I keep coming across a few separate but related issues.
1. Constraints in user's data. Line A needs to be 30 degrees from line B, regardless of line B's rotation. A great commercial app that I know of that does this excellently is Solidworks. Other useful examples could be circuit design, text layout, or physical-declarative programming systems such as verilog-a or dymola, which generate equations and turn the "arrows" the correct way when needed.

2. Constraints in the application itself and its usability. The zoom window's extents must not cross the boundaries of the viewable portion, but also still allow you to control the zoom level by panning, drawing a new boundary box, or changing the zoom factor, and it must also maintain the same aspect ratio as the viewing window, with "push back" from the constraint system when something cannot be done, or when something other than what you're directly manipulating needs changing to maintain the relationship.

3. Sharing of parameters and propagation of intention from the user. For instance, if I have a modeless dialog open with grid options, and I change the grid from the dialog, the grid on the display should immediately change. However I should also be able to go to the display itself, issue whatever hot key to change the grid, and the value in the dialog should immediately change. In other words, a parameter changed from one part of the program should immediately be seen in other parts of the program, even inside open dialogs. This would also apply to pan/zoom where there are many places to manipulate this: boundary box, scroll wheel, right mouse click, zoom slider, strokes/gestures, etc. I believe this is called the observer pattern, but I'm not sure.
Most of the technical design programs I've used (ee, mechanical, illustrator/photo, TeX [ha!]), fail to provide the knobs and buttons to make it feel realtime and interactive, which is my ultimate goal here.

I read the degrees/fahrenheit constraints example in SICP and it made sense, but i'm not sure if this approach is overkill for what I want to do above, or perhaps underkill and I need more reading in constraints-based programming.

A google on constraints led me to some big commercial thing with a compiler and its own language, which is not what I want.

Any suggestions or guidance here please?

thank you
Michael

2

A google on constraints led me to some big commercial thing with a
compiler and its own language, which is not what I want.

Any suggestions or guidance here please?

Nearly everything you described is provided by Traits/TraitsUI

See http://code.enthought.com/projects/traits/

BC

3

ztwcozj02@sneakemail.com wrote:

My first attempt is just a wxpython program that allows you to draw circles, boxes, etc. Of course this has been done a million times, but I want this as an exercise, and to see if I can do it "my" way.

Please do check out wx.lib.floatcanvas and FloatCanvas2 (in SVN under 3rd party tools). There is a lot of learning value in doing things from scratch yourself, but there is also a lot of value in working with others to develop a general purpose tool. This is exactly the kind of thing we want FloatCanvas to support!

http://morticia.cs.dal.ca/FloatCanvas/

and

http://mail.mithis.com/cgi-bin/mailman/listinfo/floatcanvas

1. Constraints in user's data. Line A needs to be 30 degrees from line B, regardless of line B's rotation.

I've done this by simply providing references to the B from A -- in a "constrained line" class or something like that -- there is a Demo of this in the FloatCanvas Demos -- see the ConnectorObject in the MovingObjects.py demo

2. Constraints in the application itself and its usability. The zoom window's extents must not cross the boundaries of the viewable portion,

I'm not sure what this means..

but also still allow you to control the zoom level by panning, drawing a new boundary box, or changing the zoom factor, and it must also maintain the same aspect ratio as the viewing window,

FloatCanvas zooming and panning does all this.

> with "push back" from the

constraint system when something cannot be done,

I'm not exactly sure what this means, but I don't think FC can do that -- it would be part of a Document Model I think -- which FC doesn't really have, but FC2 does, and I think this kind of push-back could be added.

3. Sharing of parameters and propagation of intention from the user.

This could be done well with MVC and a pubsub like messaging system -- the model would keep track of the grid parameters, and when they were changed, it would send out a "grid changed" message, that would be subscribed to by both the dialog and the display window.

However, this brings up an interesting question for me:

What the heck is the "Model" here?

As a scientist/engineer -- I tend to think of the model as the cores data itself -- those circles and boxes, etc. represent things, so the data is going to have thinks like coordinates and values associates with the objects, and maybe some information about how they relate to each other.

Then there is the next layer - the color of the objects, how thick the lines are, maybe even the size of a circle (of the size represents the magnitude of some value)

Then there's a third (or more!) layer -- things like whether the grid is displayed -- that has nothing to do with the data, only with how the user sees to or interacts with it.

So I see at least three parallel or layer models:

The Data model -- the data itself

The Document model -- the picture the user sees and interacts with

The Interaction model -- stuff about how the user interacts with the data

What gets complicated for me is that each individual object can have all three of these models -- how do you nest all this?

modeless dialog open with grid options,

modeless dialogs pretty much require some kind of pub-sub mechanism.

> I believe this is called the observer pattern, but I'm not sure.

yup -- you can use either pub/sub or observer.

I read the degrees/fahrenheit constraints example in SICP

can you give a link to that? I couldn't find it with some quick browsing of the index and TOC.

Any suggestions or guidance here please?

Do also read an ongoing thread here titled:

"Simple Design question"

and other threads in this group about MVC.

I do hope you'll join the FloatCanvas list and discuss some of this there, too.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

4

Any suggestions [...] please?

For managing/propagating constraints between data, trellis[1] looks interesting.

Traits [2] provide nearly automatic interactive UI generation from data model introspection. When changing values in the UI other parts of the program can be notified of that.

[1] Trellis - The PEAK Developers' Center
[2] http://code.enthought.com/projects/traits/

Best regards,
Stefaan.

5

Bryan Cole bryan-at-cole.uklinux.net |wx-users/MainSpamAllow| wrote:


A google on constraints led me to some big commercial thing with a compiler and its own language, which is not what I want.
Any suggestions or guidance here please?


Nearly everything you described is provided by Traits/TraitsUI
See BC

Cool, thanks to all who responded. Traits looks like a very good
starting point.

michael

···

http://code.enthought.com/projects/traits/