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

[boB Stepp]

On Sun, Apr 28, 2013 at 7:47 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> On 29/04/13 06:05, boB Stepp wrote:
>>
>> At work I use a commercial program for radiation therapy planning.
>> This program has an extensive built-in, proprietary scripting language
>> that is accessible to the user.
>
>
> Does this have a name? It's a bit clumsy to refer to "proprietary
> scripting language" each time. I expect your program's documentation
> refers to the scripting language by name.
>
It felt clumsy as I was writing my post! But I did not think that
anyone would care about which specific software we use. The planning
software is "Pinnacle3" [The 3 is supposed to be a superscript]. It is
made by Philips. As far as I know the scripting language does not have
an identifying name. They call the scripts, "HotScripts", and people
that discuss the process of creating these call it (You guessed it.)
"HotScripting". The scripting as presented "officially" is meant to be
a macro recording facility, but users long ago figured out that they
could create their own custom script files to do more than mere macro
recording could accomplish. There is a users' group for the Pinnacle
software which I subscribe to, but to the best of my knowledge no one
has attempted what I am thinking about trying. The frustrating thing
about writing these custom scripts is that Pinnacle refuses to share
information about their scripting syntax unless you are an official
Pinnacle testing partner. The software was originally created and
owned by ADAC. In those days they had a class once a year that one
could go to to learn more about the scripting, or so I have been told.
Now on the Pinnacle list server people share what they have figured
out. This is what has led me to even trying to do GUI development work
within Pinnacle.

> A full-blown GUI designer written in Python would be a lot of work, but
> you might find that most of your GUIs follow a standard pattern, say:
>
> 1 window
> 1 heading
> 1 text field
> OK and Cancel buttons
> 3-5 radio buttons
> 3-7 checkboxes
> 1-2 pop-up menus
>
>
> in which case you can take such a script and turn it into a template.

I have only attempted three such GUI projects so far. The first one
was a HotScript organizer, which is a small window mostly made up of
buttons that either run a HotScript or take one to a new window with a
different category of scripts. The second one was a radio button
window that allows one to select which ROIs (Regions Of Interest)
should be generated for contouring by the dosimetrist (The person who
creates the treatment plans, which is what I am career-wise.). Both of
these were rather brief scripts and no problem. However, the third one
which I was referring to in my OP, is much more complex. It generates
a large window with potentially many fields which give numerical
information relevant to the current treatment plan. In fact how many
fields that the window might contain is unknown by the programmer
(me). It varies from patient to patient, dosimetrist to dosimetrist
and doctor to doctor. So I had to be very flexible. It compares the
plan's results with one of four tables of data to see if the plan
satisfies the clinical requirements of the appropriate table. If it
satisfies that requirement then the field containing the plan datum
will be color-coded green; if a minor deviation from the table yellow;
major deviation, red. The only possible user interaction with the
window is a dismiss button. So I do not see how a template approach
would be helpful, but I may be dense and/or unimaginative.

> You can turn that into a template:
>
>
> create new window $WINDOW_NAME
> add field $LABEL_NAME to window $WINDOW_NAME at 20, 40
> set the text of field $LABEL_NAME to $LABEL
> add field $TEXT_NAME to window $WINDOW_NAME at 20, 20
> ...

My thought was for the GUI module to use variables such as these to
which the calling program would pass this information to these
variables. But sometimes I might need radio buttons or label fields or
drop-down list boxes or  ... or any portion or combination of these,
depending on the new programming project, which is always customized
to specific planning needs.

>
> If that works well, it might solve your problem. If not, you can
> then take a few steps closer to a full-blown GUI builder by using
> a custom mini-language to describe the GUI you want. E.g. you might
> have something like this:
>
>
> win = window("Main Window")
> label = field(win, "Label", x=20, y=20, text="Heading")
> text = field(win, "Text", x=20, y=40, size=(300, 400), scrollbar=True)
> ok = button(win, x=text.right - 40, y=text.bottom + 30)
> win.generate("mygammascript.gs")
>

This is more like what I was considering.

> which then generates the GammaScript code shown above. Because it's
> Python, you can use normal Python constructs like for-loops:
>
> for name in ("Alpha", "Beta", "Gamma"):
>     x = checkbox(win, x=..., y=..., state=False)
>
>
> A text interface like this is still a lot of work, but it's much less
> work than a graphical interface, and nearly as useful.

The main difference with what I need is that the values for at least
some of these GUI elements would need to be generated dynamically
based on a combination of what is already in the plan along with any
needed user input. It could vary significantly plan to plan.

>
> But don't underestimate how much work this will be. This is a big
> project.
>
I already gathered that it would be a big project! But I would rather
do a multi-thousand line project once if it would save me doing a
similar amount of work multiple times in the future.

boB