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/
_______________________________________________
Tutor maillist - [email protected]
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
