[Tutor] Long post: How to design a Python program to generate GUI elements in a proprietary scripting language.

[Alan Gauld]

On 29/04/13 03:57, boB Stepp wrote:

>> I'd suggest building a Python program that reads a resource file (maybe
>> using the configparser module and data format?
>
> I am not familiar with this module. I will have to look up its
> documentation. Does it exist in Python 2.4?

Yes, the format is essentially that used in Windows config files

[section1]
label1=value
label2=value2

[section2]
label3=value

etc

> my situations, it would have to result in the proper window generation
> with no tweaking.

Thats going to be really hard given the limits of your Proprietary 
Scripting Language(PSL). How do you link actions to widgets? For example 
when you create a button how do you define what that button does? A 
short example of that would be helpful to understand the limits.

> And the desired behavior at times would depend on
> how a particular field's value compares to different ranges of
> possible values. This would be unique to each patient's plan.

OK, So now we need to map the plan data to a set of widgets and the 
widgets to a set of template code. Provided we can identify the widget 
type from the plan data then it can still be done with a config file

[PlanWidgets]
monthly=slider
oneoff=button
choice=radiobutton
etc...

[slider]
geometry=landscape
position=$LOCATION
label=$TEXT
name=$NAME
action=$SCRIPT

[button]
position=$LOCATION
label=$NAME
etc...

where $XXX is data obtained at runtime from your script or from a second 
config file that is project specific. (Or even a database!)

> Alas, there is no GOTO within a script capability. The best that can
> be done is to conditionally run another script file and then return to
> the calling script.

OK  So we can name a script as the action to be executed.
Can you retrieve the results of the called script?(via a file maybe?)

> AttachTop = ScrolledWindow1; AttachRight = DrawingArea; AttachLeft =
> DrawingArea; and AttachBottom = DrawingArea. These would give a window
> where the two scrolled windows would entirely filled the available
> DrawingArea and give their spatial relationships in the window to each
> other and other elements of the window.

OK, Thats what I suspected, its a form of anchor specification.

> Unfortunately in most instances the window would have to be generated
> at runtime.

The whole window? Or just a panel within it?
If its only for display could you use formatted text to display the plan 
data? Or is there user interaction with the dynamic data?
Formatting text is a lot easier than dynamically building a
GUI in a crippled scripting language! But only if you aren't interacting 
with it!

> program I have just written. It takes about 30 seconds, plus or minus,
> to populate all of the fields in the displayed window and make the
> necessary comparisons. But for the planning dosimetrist to manually
> generate this data and do the comparisons manually can take most of 30
> minutes at times, while wondering if he had made any mistakes.

Yes, but once they get used to your program they will forget that and 
just notice how long they have to wait for the GUI! Its the nature of 
users...

I think you need to maximise commonality here. Try to define a common 
structure for the GUIs and isolate the dynamic areas to a minimal area - 
preferably a single panel within the GUI. You can then statically create 
the outer framework using the kind of config template idea I first 
suggested then insert into the output of that the dynamic elements
just where they are needed.

But at this point we go beyond abstractions and need real use cases and 
data samples and work flows to be able to give any more sensible advice.


-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/