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

[Alan Gauld]

On 28/04/13 21:05, boB Stepp wrote:

> to do the useful things I desire. Recently I have discovered it is
> possible to use the proprietary scripting language to generate GUI's
> that allow for user interaction. However, to do so one must
> laboriously create the desired window in top-down fashion. Every
> widget must be hand-coded and placed using appropriate coordinates.
 > ...
> So I finally am coming to the Python point: I would like to write a
> program in Python to more easily build these windows and their
> elements. Whenever I need to construct a windowed interface, I want to
> be able to call this program and have it generate the needed
> proprietary scripting commands in a text file that I can run from
> within the planning software.

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

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.

Later on you could build a Python GUI that generated the data file
from a GUI builder type app. Then call the python script to generate the 
scripting code from there... Getting close to a full GUI builder then. 
But do it in stages.

> The way these windows are formed are 1) There must be a top-level
> construct, TempWindow; 2) Next there must be a FORM or DrawingArea
> element; 3) Then a variety of GUI elements can be added such as
> buttons, labels, scrolled windows, etc.

The common stuff can be a standard template within Python.
In fact you could probably put that in a file too in case
it changes in the future.

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.

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

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

>  And all elements have (x,y)
> positioning coordinates as well as heights and widths. BTW, the (x,y)
> coordinates are relative to the type of parent containing them. For
> instance, ScrolledWindow1 and ScrolledWindow2 would have coordinates
> relative to within TempWindow, but TempWindow would have coordinates
> placing it on the monitor display. Elements within ScrolledWindow1
> would have coordinates relative to the top left corner of
> ScrolledWindow1.

Thats not an issue in the config file, you just need to use
some squared paper (graph paper?) to draw your UI and plot
the relative coordinates before reating the data file.

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

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

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