pywxrc

Eli Golovinsky wrote:

The original goal of the pywxrc tool was to be a replacement of wxrc, so
that is why it is able to handle the C++ related options as well as the
Python ones. So I'd prefer to keep all of that functionality in place.
  Also, even if it was removed there is still a need for the --gettext
option, as that is how you get the translatable strings extracted from
the XRC in a form that can be fed to xgettext.

I know that pywxrc is a rewrite of wxrc. But when I regression tested
it against wxrc for generating C++ code I've found that it doesn't
produce the same results. If I recall correctly there was a bug there
and also wxrc has changed a bit since you converted it. I think that
in its current state it's not very usable for C++ people and it any
case, why would they - they have the original (and probably more
fluently maintained) wxrc version.

I can put the C++ functinality back in (I've redone the code to use
string templates, so it shouldn't be hard), I just feel it's an
unnecessary bloating of the tool.

I think it would be worth it to leave it in. See below.

I now understand the importance of --gettext and will put that right back in.

By the way, some time ago you asked whether it could put all the
resource related things (both the XRC itself, the files it needs and
the generated classes) in the same file. It does that now.

Thanks.

Maybe it would be best for my version to be called in a different way,
say pywxrc2. That will keep the old functionality available for
whoever wants to use it and will also allow for changes to be made.

1. Handling the "unknown" controls is a smart way.

Meaning?

I was thinking about creating a CreateXXX overridable function for
each unknown control. You'll only have to override it and put the
Create(...) code inside. The AttachUnknownControl will be called by
the generated code. I don't know if this makes things clearer.

Yes it does. That seems like a good idea.

2. Event handling code generation.

How would you specify which events should have bindings and handlers
generated?

I've proposed a while ago to enhance the XRC format to include a list
of events for each widget. It seems that wxGlade does this already,
but the guy maintaining it said to me that it was a bug.

It would then be possible to hack XRCed to let you choose the events
you want for each control and generate the code for it.

Ok, makes sense. The C++ code for xrc will probably need to be modified to allow this, even if it is just to ignore the list of events when loading the resource. However, that may run into some resistance if the runtime loader is not able to do anything with the events... Anyway, when you decide how you want to proceed with this please bring it up for discussion on the wx-dev list.

I started thinking about it when I tried to image what it would take
to simplify the work with MVC/MVP. I think it would be cool for the
generated class to delegate the events to a Controller automatically.

3. Patching XRCed to create a compiled version of the XRC each time the
XRC file is saved.

Keep in mind that non-Python people also use XRCed, so anything that is
Python specific should be optional and not get in the way of those users.

Quite naturally the generation of compiled resources will be optional.

Also, if I put the C++ code generation back in, XRCed will be able to
generate both types of code for the benefit of both communities.

I think that this is a very good idea, especially if you could also generate code for the event bindings and other new capabilities like you do for Python. Then XRCed would have some unique features that the other tools for C++ don't have and that may help to being some C++ folks over to XRCed and then to wxPython! :wink:

···

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

I'm afraid my knowledge of DTD and xsd is very limited.
Don, can you hack something up based on tn0014?

···

On 3/25/06, Robin Dunn <robin@alldunn.com> wrote:

Don Dwiggins wrote:
> Robin Dunn wrote:
>> Ok, makes sense. The C++ code for xrc will probably need to be
>> modified to allow this, even if it is just to ignore the list of
>> events when loading the resource. However, that may run into some
>> resistance if the runtime loader is not able to do anything with the
>> events...
>
> Just a data point here: for one app, I wound up adding my own attributes
> and content tags to an XRC file (using good old Emacs), to be
> interpreted on loading by my resource handler. XRCed handled the file
> quite gracefully, politely ignoring the extra stuff and even more
> politely writing it back out after I'd made some edits. Also, there was
> no problem loading it into the app (once I got the resource handler
> right).

Ah, thanks. Good to know.

> Based on this, I'd venture that you could add event-related
> stuff to the XRC document with minimal hassle. (It'd be nice to be able
> to choose from a list of events, and provide the name of the method to
> be called right there.)
>
> This raises another question in my mind: is there a DTD or schema for
> XRC? If not, it's probably worth starting to think about, as more tools
> begin to be written to work with the format.
>

Nope. I think that all we've got is in the TechNote at
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/docs/tech/tn0014.txt, and
I think that it is not a complete specification.

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

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