XRC vs. writing wxPython

John_Salerno1 · October 3, 2006, 6:22pm

I understand the benefit of something like XRC (i.e., it keeps display separate from logic), but after using it for a few days I noticed that a necessary side effect of it is that it also prevents you from actually writing wxPython code, and I was wondering if this was really a good thing or not.

I know GUI programming can get tedious after about 10 minutes but it feels kind of strange to me to completely abandon all the wxPython I learned (such as creating widgets, adding them to parents, passing all the arguments, etc. etc.) in favor of an XML format that does all of this behind the scenes.

Now, I suppose XRC is much better than having all your GUI and logic code tangled together in a single module, but it seems like a separate option to put your GUI code in another module, then import that module and call the frame and widgets from there. That keeps display separate but still preserves the use of wxPython code.

Or am I just being silly in actually *wanting* to write wxPython code? It's definitely a necessity to learn how it all works before moving on to XRC, but is it such a big deal (as I seem to be making it) to then leave it all behind and let XRC do it for you?

Just curious about people's opinions on using XRC instead of writing the code manually. I'm also curious to know how many people actually do use it, or if they still write the wxPython code instead.

Thanks.

Robin · October 3, 2006, 6:43pm

John Salerno wrote:

Now, I suppose XRC is much better than having all your GUI and logic code tangled together in a single module, but it seems like a separate option to put your GUI code in another module, then import that module and call the frame and widgets from there. That keeps display separate but still preserves the use of wxPython code.

Either way works. It just depends on what works best for you. XRC is an easy way to manage doing the tedious things, or the complex things, but it's not as flexible as doing things in straight code. Fortunately it is fairly easy to mix the two approaches as needed.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Josiah_Carlson · October 3, 2006, 11:02pm

Or am I just being silly in actually *wanting* to write wxPython code?
It's definitely a necessity to learn how it all works before moving on
to XRC, but is it such a big deal (as I seem to be making it) to then
leave it all behind and let XRC do it for you?

The XRC editor is a very nifty tool. Having played around with both Boa
Constructor and XRCed, I personally prefer XRCed. What I have been
thinking would be nice for a while is if one had an XRC file that
produced a single module with a set of classes that derived from the
base classes (except for sizers). For example, simething simple like a
Frame with a sizer that has two panels would produce something like
this:

import wx

class Frame1(wx.Frame):
    def __init__(self, parent=None, id=wx.ID_ANY, ...):
        wx.Frame.__init__(self, ...)

        self.Panel1 = Panel1(self, ...)
        self.Panel2 = Panel2(self, ...)

        self.Sizer1 = ...
        self.Sizer1.Add(self.Panel1, ...)
        self.Sizer1.Add(self.Panel2, ...)

class Panel1(wx.Panel):
pass

class Panel2(wx.Panel):
pass

Now, this is somewhat similar to what Boa produces, but my thoughts are
that one wouldn't modify the above directly, one would subclass and
"monkey patch" as necessary...

import xrc_py_output

class newPanel1(xrc_py_output.Panel1):
    def __init__(self, ...):
        super(newPanel1, self).__init__(...)
        ...
        self.Bind(...)
    def evtHandlerX(...):
        ...

xrc_py_output.Panel1 = newPanel1

if __name__ == '__main__':
    a = wx.App()
    b = xrc_py_output.Frame1(...)
    b.Show(1)
    a.MainLoop()

Then again, maybe the 'name the class' mechanism of XRC is better and
I'm just uncomfortable with relying on raw XRC (which is impossible to
read).

Just curious about people's opinions on using XRC instead of writing the
code manually. I'm also curious to know how many people actually do use
it, or if they still write the wxPython code instead.

I write all of my GUI code by hand.

- Josiah

···

John Salerno <johnjsal@NOSPAMgmail.com> wrote:

Christian1 · October 4, 2006, 3:03am

John Salerno <johnjsal <at> NOSPAMgmail.com> writes:

Just curious about people's opinions on using XRC instead of writing the
code manually. I'm also curious to know how many people actually do use
it, or if they still write the wxPython code instead.

I completely abandoned writing GUI by hand. I recently converted a project from
hand-written GUI to xrc based and I'm very happy. At some few points I hook in
some hand-written code, e.g. for dynamic content but 99% is XRC. Especially when
you are still experimenting to find the best arrangement of the controls xrced
is great. In addition, the possibility to have XRC nodes which subclass custom
classes is very convienient. Like this this static xrc tree is filled with live
and the only thing you have to do is to load the top-level xrc element.
Great stuff.
Christian

Uwe_C_Schroeder · October 4, 2006, 3:37am

I'm using pretty much 100% XRC. I don't however use XRCed. I prefer
wxDesigner, which is well worth the couple bucks it costs. XRCed is richer
when it comes to the possible widgets you can use, but wxDesigner has a much
better user interface (IMHO).

My application has only one dialog coded by hand - and that's the login
screen.
I subclassed all controls with special xml handlers, because that allows me to
feed the logic behind the fields (i.e. it's mandatory, it only applies if
some other control is activated, it needs to be a phone masked text control
etc.) from a setup table in the database. My setup table also defines which
table and which column a specific field needs to be saved to, so I pretty
much have only 3 methods to handle loading and saving any control - and that
in an application with about 100 dialogs and panels and close to 700k lines
of code.
XRC also makes it possible to write a "dialog" or "panel" subclass that just
gets the dialog name as additional parameter and sucks it's definition in
from the xml file.

The login screen needed to be in wxPython, simply because the xrc file is
downloaded from the server after login (the server is twisted perspective
broker for those interested).

What is real magic with the xrc files is that you can change the dialogs while
the application is running. The XML handler automatically checks for a newer
version of the xrc file every time you open a dialog and uses that if there
is one. So the next time you open a subdialog it will be different - makes
for a bunch of ohhh's and aahhh's with my customers The only thing you
can't use it for is a change to the main frame - well, you usually just open
that one once

Over all the marriage between wxPython and Twisted was a bit troublesome, but
once you get the concept of XRC it's so much easier to maintain.

My $0.02

Uwe

···

On Tuesday 03 October 2006 11:22, John Salerno wrote:

I understand the benefit of something like XRC (i.e., it keeps display
separate from logic), but after using it for a few days I noticed that a
necessary side effect of it is that it also prevents you from actually
writing wxPython code, and I was wondering if this was really a good
thing or not.

I know GUI programming can get tedious after about 10 minutes but it
feels kind of strange to me to completely abandon all the wxPython I
learned (such as creating widgets, adding them to parents, passing all
the arguments, etc. etc.) in favor of an XML format that does all of
this behind the scenes.

Now, I suppose XRC is much better than having all your GUI and logic
code tangled together in a single module, but it seems like a separate
option to put your GUI code in another module, then import that module
and call the frame and widgets from there. That keeps display separate
but still preserves the use of wxPython code.

Or am I just being silly in actually *wanting* to write wxPython code?
It's definitely a necessity to learn how it all works before moving on
to XRC, but is it such a big deal (as I seem to be making it) to then
leave it all behind and let XRC do it for you?

Just curious about people's opinions on using XRC instead of writing the
code manually. I'm also curious to know how many people actually do use
it, or if they still write the wxPython code instead.

Thanks.

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

--
Open Source Solutions 4U, LLC 1618 Kelly St
Phone: +1 707 568 3056 Santa Rosa, CA 95401
Cell: +1 650 302 2405 United States
Fax: +1 707 568 6416

David_Pratt · October 4, 2006, 5:02am

Hi Uwe. Which reactor are you using for your app? I have been using threadedselectreactor myself. I have been looking at experimenting with xrc also since I rather like the flexibility I believe it will bring.

Regards
David.

Uwe C. Schroeder wrote:

···

I'm using pretty much 100% XRC. I don't however use XRCed. I prefer wxDesigner, which is well worth the couple bucks it costs. XRCed is richer when it comes to the possible widgets you can use, but wxDesigner has a much better user interface (IMHO).

My application has only one dialog coded by hand - and that's the login screen.
I subclassed all controls with special xml handlers, because that allows me to feed the logic behind the fields (i.e. it's mandatory, it only applies if some other control is activated, it needs to be a phone masked text control etc.) from a setup table in the database. My setup table also defines which table and which column a specific field needs to be saved to, so I pretty much have only 3 methods to handle loading and saving any control - and that in an application with about 100 dialogs and panels and close to 700k lines of code.
XRC also makes it possible to write a "dialog" or "panel" subclass that just gets the dialog name as additional parameter and sucks it's definition in from the xml file.

The login screen needed to be in wxPython, simply because the xrc file is downloaded from the server after login (the server is twisted perspective broker for those interested).

What is real magic with the xrc files is that you can change the dialogs while the application is running. The XML handler automatically checks for a newer version of the xrc file every time you open a dialog and uses that if there is one. So the next time you open a subdialog it will be different - makes for a bunch of ohhh's and aahhh's with my customers The only thing you can't use it for is a change to the main frame - well, you usually just open that one once

Over all the marriage between wxPython and Twisted was a bit troublesome, but once you get the concept of XRC it's so much easier to maintain.

My $0.02

Uwe

On Tuesday 03 October 2006 11:22, John Salerno wrote:

I understand the benefit of something like XRC (i.e., it keeps display
separate from logic), but after using it for a few days I noticed that a
necessary side effect of it is that it also prevents you from actually
writing wxPython code, and I was wondering if this was really a good
thing or not.

I know GUI programming can get tedious after about 10 minutes but it
feels kind of strange to me to completely abandon all the wxPython I
learned (such as creating widgets, adding them to parents, passing all
the arguments, etc. etc.) in favor of an XML format that does all of
this behind the scenes.

Now, I suppose XRC is much better than having all your GUI and logic
code tangled together in a single module, but it seems like a separate
option to put your GUI code in another module, then import that module
and call the frame and widgets from there. That keeps display separate
but still preserves the use of wxPython code.

Or am I just being silly in actually *wanting* to write wxPython code?
It's definitely a necessity to learn how it all works before moving on
to XRC, but is it such a big deal (as I seem to be making it) to then
leave it all behind and let XRC do it for you?

Just curious about people's opinions on using XRC instead of writing the
code manually. I'm also curious to know how many people actually do use
it, or if they still write the wxPython code instead.

Thanks.

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

--
Open Source Solutions 4U, LLC 1618 Kelly St
Phone: +1 707 568 3056 Santa Rosa, CA 95401
Cell: +1 650 302 2405 United States
Fax: +1 707 568 6416

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Uwe_C_Schroeder · October 4, 2006, 5:15am

I'm using the threadedselectreactor. Although all attempts - old wxreactor
which was based on a timer-scheduled mainloop I put up on activestate's
pythoon cookbook a long time ago, new wxreactor which is based on
threadedselectreactor and works much better - are kind of flawed,
threadedselectreactor does the job for me. Well, it will vanish unless
someone commits to maintain it and fix it so the unittests don't fail (see
"removing unmaintained reactors thread on the twisted mailing list). Right
now I don't have the time to get into all the buildbots and stuff, otherwise
I'd have signed up for the job.

XRC is just perfect to do the job. I never started coding the dialogs, that
was just too tedious to get things done when you're under pressure. XRC
solved most of my problems right away. The logic is the important part of an
application, the GUI is basically just the sugar to make it palatable
Thanks to XRC I spend little time on the GUI part and much more time on the
logic part.

Uwe

···

On Tuesday 03 October 2006 22:02, David Pratt wrote:

Hi Uwe. Which reactor are you using for your app? I have been using
threadedselectreactor myself. I have been looking at experimenting with
xrc also since I rather like the flexibility I believe it will bring.

Regards
David.

Uwe C. Schroeder wrote:
> I'm using pretty much 100% XRC. I don't however use XRCed. I prefer
> wxDesigner, which is well worth the couple bucks it costs. XRCed is
> richer when it comes to the possible widgets you can use, but wxDesigner
> has a much better user interface (IMHO).
>
> My application has only one dialog coded by hand - and that's the login
> screen.
> I subclassed all controls with special xml handlers, because that allows
> me to feed the logic behind the fields (i.e. it's mandatory, it only
> applies if some other control is activated, it needs to be a phone masked
> text control etc.) from a setup table in the database. My setup table
> also defines which table and which column a specific field needs to be
> saved to, so I pretty much have only 3 methods to handle loading and
> saving any control - and that in an application with about 100 dialogs
> and panels and close to 700k lines of code.
> XRC also makes it possible to write a "dialog" or "panel" subclass that
> just gets the dialog name as additional parameter and sucks it's
> definition in from the xml file.
>
> The login screen needed to be in wxPython, simply because the xrc file is
> downloaded from the server after login (the server is twisted perspective
> broker for those interested).
>
> What is real magic with the xrc files is that you can change the dialogs
> while the application is running. The XML handler automatically checks
> for a newer version of the xrc file every time you open a dialog and uses
> that if there is one. So the next time you open a subdialog it will be
> different - makes for a bunch of ohhh's and aahhh's with my customers
> The only thing you can't use it for is a change to the main frame - well,
> you usually just open that one once
>
> Over all the marriage between wxPython and Twisted was a bit troublesome,
> but once you get the concept of XRC it's so much easier to maintain.
>
> My $0.02
>
> Uwe
>
> On Tuesday 03 October 2006 11:22, John Salerno wrote:
>> I understand the benefit of something like XRC (i.e., it keeps display
>> separate from logic), but after using it for a few days I noticed that a
>> necessary side effect of it is that it also prevents you from actually
>> writing wxPython code, and I was wondering if this was really a good
>> thing or not.
>>
>> I know GUI programming can get tedious after about 10 minutes but it
>> feels kind of strange to me to completely abandon all the wxPython I
>> learned (such as creating widgets, adding them to parents, passing all
>> the arguments, etc. etc.) in favor of an XML format that does all of
>> this behind the scenes.
>>
>> Now, I suppose XRC is much better than having all your GUI and logic
>> code tangled together in a single module, but it seems like a separate
>> option to put your GUI code in another module, then import that module
>> and call the frame and widgets from there. That keeps display separate
>> but still preserves the use of wxPython code.
>>
>> Or am I just being silly in actually *wanting* to write wxPython code?
>> It's definitely a necessity to learn how it all works before moving on
>> to XRC, but is it such a big deal (as I seem to be making it) to then
>> leave it all behind and let XRC do it for you?
>>
>> Just curious about people's opinions on using XRC instead of writing the
>> code manually. I'm also curious to know how many people actually do use
>> it, or if they still write the wxPython code instead.
>>
>> Thanks.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
>> For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org
>
> --
> Open Source Solutions 4U, LLC 1618 Kelly St
> Phone: +1 707 568 3056 Santa Rosa, CA 95401
> Cell: +1 650 302 2405 United States
> Fax: +1 707 568 6416
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
> For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

--
UC

--
Open Source Solutions 4U, LLC 1618 Kelly St
Phone: +1 707 568 3056 Santa Rosa, CA 95401
Cell: +1 650 302 2405 United States
Fax: +1 707 568 6416

Robin · October 4, 2006, 5:34am

Josiah Carlson wrote:

···

John Salerno <johnjsal@NOSPAMgmail.com> wrote:

Or am I just being silly in actually *wanting* to write wxPython code? It's definitely a necessity to learn how it all works before moving on to XRC, but is it such a big deal (as I seem to be making it) to then leave it all behind and let XRC do it for you?

The XRC editor is a very nifty tool. Having played around with both Boa
Constructor and XRCed, I personally prefer XRCed. What I have been
thinking would be nice for a while is if one had an XRC file that
produced a single module with a set of classes that derived from the
base classes (except for sizers). For example, simething simple like a
Frame with a sizer that has two panels would produce something like
this:

It's not quite the same but the new pywxrc tool in 2.7 has an option to generate code that loads from the XRC file, including a class for each of the top-level items.

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

John_Salerno1 · October 4, 2006, 2:36pm

Christian Kristukat wrote:

In addition, the possibility to have XRC nodes which subclass custom
classes is very convienient.

Is this a slightly more advanced feature? How do you create custom classes with XRC? Or is pretty much everything you create in XRC basically a custom class?

Josiah_Carlson · October 4, 2006, 4:21pm

Hmmm. Looks like a good start to a full converter, though for most uses
it is probably fine as-is.

- Josiah

···

Robin Dunn <robin@alldunn.com> wrote:

Josiah Carlson wrote:
> John Salerno <johnjsal@NOSPAMgmail.com> wrote:
>> Or am I just being silly in actually *wanting* to write wxPython code?
>> It's definitely a necessity to learn how it all works before moving on
>> to XRC, but is it such a big deal (as I seem to be making it) to then
>> leave it all behind and let XRC do it for you?
>
> The XRC editor is a very nifty tool. Having played around with both Boa
> Constructor and XRCed, I personally prefer XRCed. What I have been
> thinking would be nice for a while is if one had an XRC file that
> produced a single module with a set of classes that derived from the
> base classes (except for sizers). For example, simething simple like a
> Frame with a sizer that has two panels would produce something like
> this:

It's not quite the same but the new pywxrc tool in 2.7 has an option to
generate code that loads from the XRC file, including a class for each
of the top-level items.

Robin · October 4, 2006, 7:21pm

John Salerno wrote:

Christian Kristukat wrote:

In addition, the possibility to have XRC nodes which subclass custom
classes is very convienient.

Is this a slightly more advanced feature? How do you create custom classes with XRC? Or is pretty much everything you create in XRC basically a custom class?

You create a custom class in Python and then tell XRC to use that class. See the XmlResourceHandler and XmlResourceSubclass samples in the demo.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!