workaround for generating gui tools

[flupke]

Hi,

i create my GUIs mainly via wxGlade. However when you start of to
program and want to do some rearranging to the gui, wxglade overwrites
your file and you've got to put your own code back in.

I think i can work around that (at least a bit) by making a second file
that imports the gui generated by wxglade and make classes that extend
the original ones.
For instance i could have a class MainForm that extends the wxFrame
class that wxGlade produces.

Are there other clever ways to work around this problem?

Thanks,
Benedict

[Harlin Seritt]

Re: workaround for generating gui tools

Benedict,

Best to hand-code your code ;-) -- even GUI. This is kind of why I like
Tkinter so much. Good luck.

Harlin Seritt

[Reinhold Birkenfeld]

Re: workaround for generating gui tools

Harlin Seritt wrote:[color=blue]
> Benedict,
>
> Best to hand-code your code ;-) -- even GUI. This is kind of why I like
> Tkinter so much. Good luck.[/color]

Have to disagree strongly.

It's evil anyway (for more complex applications) to put GUI construction
in your code. GUI should be described appropriately in data files.

Glade does this very good, and with pygtk it's no problem to use the XML files.

Reinhold

[flupke]

Re: workaround for generating gui tools

Reinhold Birkenfeld wrote:
[color=blue]
> Have to disagree strongly.
>
> It's evil anyway (for more complex applications) to put GUI construction
> in your code. GUI should be described appropriately in data files.
>
> Glade does this very good, and with pygtk it's no problem to use the XML files.
>
> Reinhold[/color]

So the GUI should be seperate from the code. Is the way i described
valid then? Extending from the gui class and putting event handlers in
the derived classes?
Or is there a better way to seperate the GUI from the code?

Benedict

[Fredrik Lundh]

Re: workaround for generating gui tools

Reinhold Birkenfeld wrote:
[color=blue]
> It's evil anyway (for more complex applications) to put GUI construction
> in your code. GUI should be described appropriately in data files.[/color]

why use data files when you have an extremely powerful programming
language in your toolbox? the advantage of building UI's in Python is
that you can quickly create "domain specific UI languages", and use them
to generate the interfaces for you. UI editors may be useful for trivial
applications, but if you're doing complex stuff, you sure want domain-
specific abstractions. Python gives you that, XML files don't.

</F>

[Diez B. Roggisch]

Re: workaround for generating gui tools

> why use data files when you have an extremely powerful programming[color=blue]
> language in your toolbox? the advantage of building UI's in Python is
> that you can quickly create "domain specific UI languages", and use them
> to generate the interfaces for you. UI editors may be useful for trivial
> applications, but if you're doing complex stuff, you sure want domain-
> specific abstractions. Python gives you that, XML files don't.[/color]

If you do some creative rearranging of widgets and play around with
different layouts and geometry managers, a good gui-designer becomes very
useful.
--
Regards,

Diez B. Roggisch

[Jeremy Bowers]

Re: workaround for generating gui tools

On Sat, 09 Apr 2005 19:59:18 +0200, Diez B. Roggisch wrote:
[color=blue][color=green]
>> why use data files when you have an extremely powerful programming
>> language in your toolbox? the advantage of building UI's in Python is
>> that you can quickly create "domain specific UI languages", and use them
>> to generate the interfaces for you. UI editors may be useful for trivial
>> applications, but if you're doing complex stuff, you sure want domain-
>> specific abstractions. Python gives you that, XML files don't.[/color]
>
> If you do some creative rearranging of widgets and play around with
> different layouts and geometry managers, a good gui-designer becomes very
> useful.[/color]

Domain-specific abstractions do that *faster* than GUI designers, not
slower. And better, too, since every iteration tends to be fully
functional and not just a "let's see what this looks like" prototype.

Heck, switch 'em out dynamically based on what day of the week it is and
how the user feels today. Let's see your GUI-designer do that.

And if you're not used to doing it that way, you'll be *stunned* at how
much stuff tends to factor out and get easily re-used.

An approach that has more data to work with (some idea of what things are
doing and what they are for) will beat an approach with less data ("thing
at row 4, col 2" or, worst case, "thing at 233,144") any day.

GUI designers are like the regexs in the famous jwz quote: "Some people,
when confronted with a problem, think 'I know, I'll use a GUI designer'.
Now they have two problems." Both have a niche in the "quick fix"
department, both are typically over-used, but overall regexs are the more
useful of the two; at least there are cases where they are the undisputed
right answer (like defining tokens in a language parser).

Generally, over the first couple of weeks of a project, the
domain-specific language writer may seem to be behind the GUI designer
cranking out screen after screen of templated GUI widgets, but after a
couple of weeks the domain-specific language user will pull into the lead
and never give it up, and will be a lot happier to boot.

[flupke]

Re: workaround for generating gui tools

Jeremy Bowers wrote:

<snip>
[color=blue]
>
> Domain-specific abstractions do that *faster* than GUI designers, not
> slower. And better, too, since every iteration tends to be fully
> functional and not just a "let's see what this looks like" prototype.
>
> Heck, switch 'em out dynamically based on what day of the week it is and
> how the user feels today. Let's see your GUI-designer do that.
>
> And if you're not used to doing it that way, you'll be *stunned* at how
> much stuff tends to factor out and get easily re-used.
>
> An approach that has more data to work with (some idea of what things are
> doing and what they are for) will beat an approach with less data ("thing
> at row 4, col 2" or, worst case, "thing at 233,144") any day.
>
> GUI designers are like the regexs in the famous jwz quote: "Some people,
> when confronted with a problem, think 'I know, I'll use a GUI designer'.
> Now they have two problems." Both have a niche in the "quick fix"
> department, both are typically over-used, but overall regexs are the more
> useful of the two; at least there are cases where they are the undisputed
> right answer (like defining tokens in a language parser).
>
> Generally, over the first couple of weeks of a project, the
> domain-specific language writer may seem to be behind the GUI designer
> cranking out screen after screen of templated GUI widgets, but after a
> couple of weeks the domain-specific language user will pull into the lead
> and never give it up, and will be a lot happier to boot.[/color]

First time i hear about domain-specific abstractions.
Do you mean that instead of using a GUI designer, you make some sort of
engine that constructs a gui for you?

One thing i find repetitive to do is designing gui's that are just
simple views on a database tables where one can create,edit and delete
records. If one could construct a gui dynamically for these types of
things, that would be great.

Benedict

[Diez B. Roggisch]

Re: workaround for generating gui tools

> Domain-specific abstractions do that *faster* than GUI designers, not[color=blue]
> slower. And better, too, since every iteration tends to be fully
> functional and not just a "let's see what this looks like" prototype.[/color]

Can you show me some working, in-use example for that? I _seriously_ doubt
that the process of rearranging and tuning the layout can be done faster in
the text-world than with a good designer like qt-designer. But I'm all ears
for better solutions.

BTW, when I talk of gui designers, I _only_ have them for creating guis - no
attaching of event code or stuff like that (except from some trivial
signal-slot-connections, that is)

As a programmer, the only thing of interest to me are the certain widgets I
need my logic to bind to. The structure of the thing itself I don't care
about.
[color=blue]
>
> Heck, switch 'em out dynamically based on what day of the week it is and
> how the user feels today. Let's see your GUI-designer do that.
>
> And if you're not used to doing it that way, you'll be *stunned* at how
> much stuff tends to factor out and get easily re-used.[/color]

Well - stun me by example :)
[color=blue]
>
> An approach that has more data to work with (some idea of what things are
> doing and what they are for) will beat an approach with less data ("thing
> at row 4, col 2" or, worst case, "thing at 233,144") any day.[/color]

Hm. There certainly are cases where I take smaller building blocks and
rearrange them according to my current needs - all in python of course. But
that's only a comparably small part - at least to my current apps. It
could grow depending on the type of application - e.g. database driven
stuff - but so far, I'm pretty well with creating the larger
dialogs/widgets in the designer and when the functionality is working, the
rearranging of these widgets for better usability is pretty important and
certainly easier done in the designer.

To me the whole discussion is similar to generating html using python or
using templates - templates need only to conform to a certain interface for
the app writer to work. Sure, sometimes things get a little bit more
tedious compared to just printing out html fragments. But the more control
you want over the look of your results, the less powerful the generating
approach becomes - because you simply lack the features to control the
layout or you take deep steps into parameter hell - but then I see html as
a domain specific language and prefer to use that to control the layout.

I've seen such development in the java-world using struts, where people
introduced their own tags for displaying data objects - over time, some of
these grew 10 or more cryptic attributes for fine-controlling the layout.
Instead of just providing the necessary data and letting jsp do the layout.

--
Regards,

Diez B. Roggisch

[Dave Cook]

Re: workaround for generating gui tools

On 2005-04-09, flupke <flupke@nonexis tingdomain.com> wrote:
[color=blue]
> i create my GUIs mainly via wxGlade. However when you start of to
> program and want to do some rearranging to the gui, wxglade overwrites
> your file and you've got to put your own code back in.[/color]

How about generating XRC files instead of Python? I admit I've never tried
it with wxGlade, so I don't know how well it works, but with the original
Glade one only uses XML, you can't generate Python at all.

Dave Cook

[Jeremy Bowers]

Re: workaround for generating gui tools

On Sun, 10 Apr 2005 13:57:26 +0200, Diez B. Roggisch wrote:
[color=blue][color=green]
>> Domain-specific abstractions do that *faster* than GUI designers, not
>> slower. And better, too, since every iteration tends to be fully
>> functional and not just a "let's see what this looks like" prototype.[/color]
>
> Can you show me some working, in-use example for that? I _seriously_ doubt
> that the process of rearranging and tuning the layout can be done faster in
> the text-world than with a good designer like qt-designer. But I'm all ears
> for better solutions.[/color]

Regrettably, no. I have them but they are all unsharable, either because
the real owner would consider them proprietary, or because they are an
unreleased and at the moment unfinished product I can't give the code out
for.

But I can help some.

Part of the problem is the incredible cognitive disconnect between the
"layout" system of design and the system I'm advocating. You're looking at
your designer and saying something like, "well, if I want to re-order
these two options, it's three drags, even less if there's an 'exchange'
option, how can anything possibly be any easier?" (At least, that's my
guess.) But that is not where the advantage lies.

One of the things I can't show you at the moment is actually written as a
web application using Javascript and mod_perl. It's a bog-standard GUI app
that edits databases, from the surface. SOP for the forms designer
approach is to create a form for each thing that will be edited; in this
case in HTML, but that's not particularly different and you can get form
editors for that, too, if you try.

But even now, we have at least 20 different types of things to edit, and
the full power of databases is at play here; we have foreign keys that may
have an arbitrary number of certain things (customers may have an
arbitrary number of phone numbers, for instance; in practice of course you
won't have 20, but they may have "home", the may have "home + work", the
may have "work + fax", etc.), and a customer's address may actually be in
an Address table, rather than directly in their record. Add up all the
little pieces and at the moment we've got around 100 different types of
things that might need editing, many of which can have arbitrary links to
other things. (Some of these 100 things are just "link tables", SQL tables
that link an ID in one table to an ID in another for many-to-many
relationships and these will not directly be edited, but still there's a
lot of "things" in play here.)

We could try to create a form for each one, and in fact earlier versions
of the system did just that. But that solution sucked, for all of the
reasons I typically rant against these solutions; they rapidly got out of
sync with the database schema, a bug fix in one was a bug fix in no others
(copy and paste code tends to run rampant in this situation, though
technically that's just a tendency, not a requirement), and any but the
most critical enhancements are out of the question because they only
affect a small part of the system.

So, instead, with this new system (note I wasn't involved with the old
system), I do everything with metadata. (Credit where credit is due, the
other programmer was starting to do some of this, though he couldn't quite
take it down to the interface and there are some things I had to add
later.) Every "thing" (class) has a description of what it's made out of,
and what type each of those things are. When I go to edit an instance, the
Javascript pulls down that description, and a description of the instance
(and all of its associated sub-instances), and instead *generates* a form
to edit the object based on what it is made of.

Right now, I'm emulating the old two col approach, labels on the left,
values on the right, but I'll be changing that later. For now, though,
that makes it easy (and like I said, as nice as forms are, having to do
that many they bailed out and went with a standard design). And since I'm
putting these things in by hand, I can also create custom widget types and
use them. (For that, I'm using my XBLinJS library, so you can actually
think of the HTML widgets as having capabilities much like Tkinter
widgets, in that I can subclass from them and make them do domain-specific
things just like Tk.)

Integer value types get integer text boxes; these do not allow you to type
anything but numbers. Floating point is the same way, but adds the .
(although only one). All numeric fields do math within themselves, which
is something that should have been standard for a decade now but
programmers had to actually do something special in their forms to get
it; I get it for the same price as anything else, once I wrote the
code. (By that I mean, type "1+4" in and it will resolve itself to
"5".) That's one of the reasons I rant about this; there is *so much*
functionality like that that ought to be standard because done correctly
it's trivial to plunk the right text widget subclass down if you're
generating the screen, but form designers make this a lot of extra work.

How do I decide the order to create the fields? Classes carry a metadata
field called "order" that lists the fields it wants in order, the
remainder will by default be tacked on the end. What if I don't want a
certain field to display? There's a metadata field that lists the ones we
want to display for editing, there's another I can use to just filter a
couple out if the first isn't present. What if I want a particular widget
to do something special like be a certain width? I've created a metadata
"escape hatch" that lets me pass parameters directly to the <input> node;
it's "bad style", but sometimes useful. Everything I use is backed by a
database which has limited typing abilities, so I have a field called
"humantype" that declares the human type of the data, so I can then create
intelligent widgets for that, too. One of the things we can do, for
instance, is create an "image" widget that specifies a URL for an image,
and as validation, shows it there in the browser. We could also make it
accept uploads. Then, just by labelling a field as an "htmlImage" , we get
the image editor, no form redesign, no muss, no fuss.

Form designers give you small parts of this; you can create a text node,
say it's an int, and get automatic min/max, although... they don't pull it
from the database, they don't have any understanding of what's going on,
etc. In my design, every is some sort of intelligent field, not a
bog-standard text box, and the idea of a "field" includes the ability to
validate the value inside of it, depending on what kind it is. (Here, the
number fields for instance have a bit of code to check min and max. Other
fields make sure they reference something real in the database.)

By making smarter widgets, and intelligently assembling them in code
instead of plopping down stupid (in the programming sense, not the
derogatory sense) text widgets here and checkbox widgets there, I can
(and have) created entirely *new* objects, and the editor *just works*.

Semi-weakness: Vast, labyrinthine preferences dialogs can be a pain, if
your "core app" doesn't itself look like one. Still, you'd be surprised in
practice how that tends not to come up, especially if your app can already
support that sort of thing, in which case it's just another data source.
(All the prefs we have in this app fit right into the same model without
any hassle, so this isn't a stopper.)

The true and major weakness: You can't hire a guy off the street to draw
boxes in his designer, connect a couple of events, and call the form done.
(Although in practice it's rarely that easy...) You have to be a
programmer that can handle a level of abstraction above the raw fields.
But the benefits are...

....ultimately, *exactly* the same benefits you obtain from any other layer
of abstraction, and with exactly the same tradeoffs and costs, with
exactly the same result that *typically* the abstraction is a good thing
but every once in a while, mostly on small jobs, it's a loss. Indeed I see
this entire argument as isomorphic to "Why would I want to do OO when my
procedural code works just fine?", right down to the different programming
style it engenders, the difficulty of crossing the understanding gulf, and
the initial difficulties. (Regrettably, this style is unpopular and not
immediately supported by frameworks or anything, so initially you end up
constructing your own.) It even *feels* the same, with the way I don't
want to work on forms-based apps anymore because they feel so static and
concrete and immobile, just as non-OO procedural does, and the way it
takes so much work to do the same thing, over and over again.

If this thread is still going in a couple of days, I'll post a screenshot
with some labels on it so I can gesture a little more concretely, and I
might post some of the source data files, too, if it seems like it would
help. The screenshot won't help much, though, because it is in the
*behavior* of the resulting app that the true difference is felt.

I wish I could point at a consumer app to download, but I think this has
not penetrated the general consciousness yet, because in C or C++ this is
a *god awful nightmare*. The function signatures necessary to pull this
off would put most C programmers off their feed, and would challenge even
C++ programmers (God help you if you tried to template any of this...),
and the memory management becomes quite exciting. This is going to follow
behind the dynamic languages, which actually make it possible, by a few
years, and those are only now beginning to penetrate the mainstream
consciousness. I would expect that at least among the good programmers,
this will be SOP in about five to ten years, with better framework
support, but at the moment all I can say is the benefits in the code I
can't show you yet (sorry) are overwhelming, and the obvious problems
fully overcomable, once you get into the paradigm.

Cue the smalltalk "I did this in the 80's and it's been all downhill since
then" replies...

[Ken Godee]

Re: workaround for generating gui tools

Jeremy Bowers wrote:[color=blue]
> On Sun, 10 Apr 2005 13:57:26 +0200, Diez B. Roggisch wrote:
>
>[color=green][color=darkred]
>>>Domain-specific abstractions do that *faster* than GUI designers, not
>>>slower. And better, too, since every iteration tends to be fully
>>>functional and not just a "let's see what this looks like" prototype.[/color]
>>
>>Can you show me some working, in-use example for that? I _seriously_ doubt
>>that the process of rearranging and tuning the layout can be done faster in
>>the text-world than with a good designer like qt-designer. But I'm all ears
>>for better solutions.[/color]
>
>
> Regrettably, no. I have them but they are all unsharable, either because
> the real owner would consider them proprietary, or because they are an
> unreleased and at the moment unfinished product I can't give the code out
> for.
>
> But I can help some.
>[/color]

This guys gotta be a politician or english major or something! :)

155 lines, 1706 words, 9493 character reply, but his method is so simple
he still can't show us an example!

The original poster was just asking for an example of
how to sub class his code generated form into his program
for easy future updates, a "VERY STANDARD" way of doing it.

I tried at first to follow this "Great Way" of doing it,
but I guess I'm to simple minded, or just got to damed borded.

Hey, that's just me. I guess I'll just be stuck zapping out
forms with qt designer, the old fashion way.

[Jeremy Bowers]

Re: workaround for generating gui tools

On Sun, 10 Apr 2005 13:02:27 -0700, Ken Godee wrote:[color=blue]
> The original poster was just asking for an example of
> how to sub class his code generated form into his program
> for easy future updates, a "VERY STANDARD" way of doing it.[/color]

I recognize your sarcasm, and I recognize the poor attitude it shows, but
underneath it you do have a point. Continuing the (still IMHO very
good) OO vs. procedural metaphor, the problem is that posting a trivial
example of a dynamic interface, even were I to take the time to create one
for you for free, would meet with exactly the same response that posting
an OO snippet of some reasonable newsgroup size would receive from someone
skeptical of OO. "Well, heck, I can do that all in a procedural program,
and it would be a little shorter, too!" I am *particularly* not inclined
to post a trivial example because it would do nothing to blunt your
skepticism, or your sarcasm, and regardless, people who are genuinely
curious simply need to try it for themselves.

The advantages only start kicking in with large programs.

But I do recall a book with similar themes, though I do not endorse it
whole-heartedly: "Software Development On A Leash", which also gives you
sample code for his particular framework.

http://www.apress.com/book/bookDisplay.html?bID=29

My opinion of this book is like my opinion of XP: Every serious programmer
ought to be exposed to the ideas contained in it (even if not by exposure
to this book or the actual XP writings), and ought to give them serious
thought, but 100% acceptance is not necessary.

To address your sarcasm directly, there's 456 pages of examples in
professionally written prose and real code samples, which I don't entirely
agree with but they do serve to show the point, available for the price of
$39.95. I consider my "obligation " to you discharged on this point; if you
prefer sarcasm to investing anything into your personal development,
that's your problem, not mine. (If this were a private email, I would have
just deleted it, but the underlying criticisms, even if uncivilly phrased,
bore answering.) Even though you probably won't adopt this guys framework,
if you're paid anything at all for programming you'll recover the $40 in
no time with the ideas in that book.

[Bengt Richter]

Re: workaround for generating gui tools

On Sat, 9 Apr 2005 19:22:16 +0200, "Fredrik Lundh" <fredrik@python ware.com> wrote:
[color=blue]
>Reinhold Birkenfeld wrote:
>[color=green]
>> It's evil anyway (for more complex applications) to put GUI construction
>> in your code. GUI should be described appropriately in data files.[/color]
>
>why use data files when you have an extremely powerful programming
>language in your toolbox? the advantage of building UI's in Python is
>that you can quickly create "domain specific UI languages", and use them
>to generate the interfaces for you. UI editors may be useful for trivial
>applications , but if you're doing complex stuff, you sure want domain-
>specific abstractions. Python gives you that, XML files don't.
>[/color]
Suppose tkinter elements all had a standard python property called, say, textview,
and for any given element in a GUI hierarchy, you could get and set and delete
this textview property, with suitable side effects. If you wrote python like
print mywidget.textvi ew
You might see something like Delphi's representation of a nested "panel" widget
with a label, text entry slot, and button (excerpted from a full form representation) :

"""
object Panel1: TPanel
Left = 400
Top = 160
Width = 185
Height = 113
TabOrder = 0
object Label2: TLabel
Left = 24
Top = 16
Width = 65
Height = 13
Caption = 'Example label'
end
object Edit1: TEdit
Left = 24
Top = 32
Width = 121
Height = 21
TabOrder = 0
Text = ' (example text entry)'
end
object Button1: TButton
Left = 24
Top = 64
Width = 121
Height = 25
Caption = 'Example Submit'
TabOrder = 1
end
end
"""

(The parent form or GUI element specifies other things that are inherited (e.g. fonts etc),
so those aren't part of the widget representation unless you have locally
edited those attributes one way or another, in which case they would show up)

(I might add a standard TEXTVIEW_VERSIO N = ... line as the first line of output
in case you wanted to save a design for later (perhaps much later) but Delphi
doesn't seem to).

Anyway, with a textview property you could write

open('mywidget_ v2.txt','w').wr ite(repr(mywidg et.textview)

and if the textview property round-tripped, you could edit mywidget_v2.txt
with emacs or vim or a program, and then (just as an example) write

mywidget.textvi ew = open('mywidget_ v2.txt').read()

and see the changes. Creating or deleting mywidget would be modifying the textview
of the parent, if you were doing it via textview, except that del mywidget.textvi ew
might effectively delete mywidget from the parent. Not sure what would be most useful.

The textview is an alternate and fairly programming-language-agnostic representation
of a GUI design element. Obviously it would not be much of a transformation to convert
to nested python dict representation for the above (and for a python interface to tkinter
that might be better than text). It would not surprise me to find that someone has
done a tkinter walker (maybe it's built into tkinter, I haven't dug) that does something
like this for the read view, but I wonder about the round trip replacement write.

Anyway, I think this kind of programming-language-agnostic representation may be what
Reinhold is getting at, and the "evil" being non-programming-language-agnosticism
in GUI design representation (though textview representation syntax would be a language syntax too ;-)

Using Delphi's conventions might permit interesting interchange with the Delphi world, and I know
there is some Delphi/Python synergy being pursued, though I haven't looked into it, so I'd bet
there is python code somewhere translating between Delphi and tkinter. I just thought of this
textview property to help make my take on Reinhold's post clear, but I could see it making
GUI design interchange in general easier to have a standard representation for that purpose.

XML is too crufty for my taste, but the idea of a very broadly applicable definition of
useful pure abstractions with standard concrete representations appeals to me (I know of ASN ;-)
IMO XML has gotten a place in the world because it works well enough that people
who want to get other work done can't wait for it to be replaced with something better,
not because it's the best thing. Sort of like how MSDOS got its place in the world.

Alternatively, GUI elements could have registrable encode/decode methods with
some kind of UniGUIcode abstract core ;-) I kind of like that, off hand...

Regards,
Bengt Richter

[flupke]

Re: workaround for generating gui tools

Dave Cook wrote:[color=blue]
> On 2005-04-09, flupke <flupke@nonexis tingdomain.com> wrote:
>
>[color=green]
>>i create my GUIs mainly via wxGlade. However when you start of to
>>program and want to do some rearranging to the gui, wxglade overwrites
>>your file and you've got to put your own code back in.[/color]
>
>
> How about generating XRC files instead of Python? I admit I've never tried
> it with wxGlade, so I don't know how well it works, but with the original
> Glade one only uses XML, you can't generate Python at all.
>
> Dave Cook[/color]

That sounds like a good idea. I'm going to check how i can load stuff
from the resource file.

Thanks for the tip

Regards,
Benedict Verheyen