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]

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]

Harlin Seritt wrote:

Benedict,

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

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]

Reinhold Birkenfeld wrote:

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

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]

Reinhold Birkenfeld wrote:

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

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]

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

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]

On Sat, 09 Apr 2005 19:59:18 +0200, Diez B. Roggisch wrote:

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.

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

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]

Jeremy Bowers wrote:

<snip>

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.

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]

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

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.
Well - stun me by example :)

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.

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]

On 2005-04-09, flupke <fl****@nonexis tingdomain.com> wrote:

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.

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