On Sun, Apr 28, 2013 at 4:25 PM, Alan Gauld <[email protected]> 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 _______________________________________________ Tutor maillist - [email protected] To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
