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

[boB Stepp]

On Mon, Apr 29, 2013 at 4:08 AM, Alan Gauld <alan.gauld at btinternet.com> wrote:
> On 29/04/13 03:57, boB Stepp wrote:
>

[Major snip]

>
>> 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!
>

The first time such a script would be run, the entire window would
have to be generated. But if the user wished to rerun certain scripts,
it might be possible to do what you suggest. But this would not work
with all of them.

Alan, bear in mind that each script that I write tends to be rather
unique and rather dissimilar to earlier scripting. And as I learn more
of the hidden syntax of the Pinnacle HotScripting language and
learn/remember better programming practices, my scripting evolves
(There is no documentation other than what some ambitious users have
cobbled together.) As a dosimetrist, I typically imagine a way that
would make my planning life much easier and save me lots of time.
Also, I am constantly on the look for ways to automate common planning
processes in order to increase standardization and reduce the chances
of an uncaught error. When my work allows me time for programming,
then I attempt to implement my ideas.
Once my colleagues hear about something they like then I adapt these
scripts to their individual needs. Normally no one asks me to script
anything, though that has very recently started to change. I am mostly
self-directed in these endeavors. You'd think I would make things
easier on myself!
>
>> 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...
>

How true! If nothing else, it annoys me, so I will eventually figure
out ways to improve performance.

> 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.
>

This is surely doable for the outer framework.

For the dynamically generated areas if the script would be run more
than once, there is a possibility that I just now recalled. The
Pinnacle scripting language allows for the creation of dependencies.
For instance, if I were storing in one of the window's fields the
maximum dose that a particular region of interest receives, say the
heart, then if I successfully created such a dependency it should
update that field in my window. In these types of scripts I could
theoretically leave the window open (maximized or minimized) and any
data fields that I create dependencies for should refresh to the new
values upon the planner changing his plan.

> 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.

For sure. You and Steven have given much helpful information. I now
need to determine how to best apply these thoughts to my particular
programming problems. I especially need to improve my last script that
led to my OP. I have been asked if it would be too much trouble to add
more tabular data to make comparisons to and add it to the window. And
another of our centers has hinted that they would like their
customized version of the program. Unfortunately they use almost
totally different terminology for their ROIs. And the most unfortunate
thing of all is that I was so focused on making the GUI that I did not
give any thought to maintaining and updating my code! Horrors!! So I
am wanting to totally redesign this program anyway. So if I can
separate the GUI stuff and the tabular data from the bulk of the code,
this would be greatly beneficial to my future happiness!

And I do want to start making the switch to Python from Perl at work
now that it is finally available to me due to the recent hardware and
software upgrades. So I am sure that more questions will develop!

Thanks!
boB