[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 4:25 PM, Alan Gauld <alan.gauld at btinternet.com> wrote:

>
> You could build a full GUI builder in Python but that will be a lot of work.
> Is there room for a half way house?
>

I sure hope so!

> I'd suggest building a Python program that reads a resource file (maybe
> using the configparser module and data format? Each section of config parser
> would specify the  unique elements of a window (or sub window).
> Python then uses that data to generate boilerplate code in your scripting
> language which you then manually tweak to add behaviour etc.
>

I am not familiar with this module. I will have to look up its
documentation. Does it exist in Python 2.4? But for this to work for
my situations, it would have to result in the proper window generation
with no tweaking. 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.

> It should be possible to define most widgets and colours etc in the data
> file relatively easily and have Python build the code for that.
>

Sounds potentially promising...

>
> The important bit to put in the config file is the data
> unique to a widget/panel. Name/Label/colour/location etc.
> You don;t say how the widgets are bound to actions
> (I assume they are) but you could maybe cover that too,
> although its hard without a function concept - I assume
> it has GOTO? But i suspect that may be the bit you have
> to hand craft after the boilerplate is created.
>

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.

>> I can almost visualize how I might do this, but am currently stumped
>> on how to automatically generate the various parent-child naming
>> relationships that must exist between these elements. For instance if
>> my top level construct is TempWindow, in which everything is placed,
>> my next level might be DrawingArea, whose ParentName would be
>> TempWindow.
>
>
> Parent would be a data attribute in the config file...
>
>
>> But if I added two scrolled windows to DrawingArea, then
>> ScrolledWindow1 and ScrolledWindow2 would have a ParentName of
>> DrawingArea. Et cetera.
>
>
> You need to build the parent tree in your Ptython code.
> So long as each widget definition tells you the parent
> it should work ok.
>

I am not 100% sure I am following what you mean here. I will have to
give this some thought.

>> A further difficulty is that as these things
>> get added, some of them have attachment commands, such as AttachTop,
>> AttachRight, etc. But some don't.
>
>
> Not really sure what that means... But again maybe an anchor attribute is
> needed?
>

Say I had DrawingArea, ScrolledWindow1 (within DrawingArea) and
ScrolledWindow2 (also within DrawingArea). ScrolledWindow1 would have
to be specified as: AttachTop = DrawingArea; AttachRight =
DrawingArea; AttachLeft = DrawingArea; and AttachBottom = "--".
ScrolledWindow2, which is to be below ScrolledWindow1 would be:
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.

>
>> What I am currently visualizing is ProprietaryScript calls external
>> PythonScript.
>
>
> I think that creating the GUI at runtime is probably going to be
> clunky and slow. I'd suggest you just write a Python pre-processor
> that creates the proprietary GUI code.
>

Unfortunately in most instances the window would have to be generated
at runtime. And any fields in it would be filled in depending on what
the plan's values were at runtime. But you are correct. I have been
giving some thought as to how to speed up the performance of the
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.

>> I have not delved into the OOP aspects of Python yet, but from my
>> current general understanding of OOP I am hopeful that it can handle
>> these issues.
>
>
> OOP will help but its not magic, you will need to define and build the
> classes. But there are lots of OOP GUI frameworks to use as a starter for
> your heirarchy...
>
> FWIW What I've suggested is quite similar to how the earliest Windows
> programs were built with a data resource file defining the look and a code
> file defining the actions and a compilation step linking the two. In this
> case you use Python to do the linkage plus a wee bit of hand coding to
> finish it off...

Thanks for the food for thought!
boB