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!
···
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!