xrc vs c++

[djesus]

Hi all, firt of all thank you for your work!. I would like to know if is more faster to load a xrc file or insert in c++ and compile. I used the great wxSmith and I choose to generate xrc, but I don't know the advantages of xrc.

Can generate with wxSmith c++ code from a xrc generetated or if i choose xrc i can't any more to go back.

[thomas]

It is certainly faster to insert the C++ code, as this eleminates ZIP decompression and XML parsing. XRC still has to call the C++ functions to build the controls and add them to the dialog.

However... does it really matter? One takes one millisecond, and the other maybe takes two. A dialog is usually generated a few times and is open several seconds (or longer).
XRC, despite being slower, has one big advantage: it is easily extensible without the need to recompile anything (and without very painful code bashing).

I believe that XRC versus C++ is not the correct place to think about optimizing for speed.

[Game_Ender]

Using XRC does have overhead.  You incur a slight penalty for everything forc reating the dialog and referencing widgets that are XRC only.  The advantage of XRC is that there are many wxWidgets RAD tools that can load and save dialogs directly from XRC so you can use wxSmith, DialogBlocks, and wxDesigner all to work on the same set of Dialogs.  I really don't know how much slower XRC loading is than just creating the dialog in pure C++, but I wouldn't be surprised if took a 2 to 3 times as long to create a dialog from XRC than it did with C++.  It is important to note though, that a could design will have you just showing and hiding dialogs, not destroying them, so you don't really have to worry about the creation penalty.  From a design standpoint it is easier to understand the layout of a dialog from and XRC than code, so you have that advantage there too.

[thomas]

I wouldn't be surprised if took a 2 to 3 times as long to create a dialog from XRC than it did with C++.

True, but like I said... who cares. You don't load a dialog 20 times per second, but you load it once and display it for 20 seconds. No matter what, the user won't know whether it takes 1ms, 5ms, or even 20ms to load.

Editing the structure of a dialog when it is coded in C++ is a pain in the anus. On the other hand, in XRC it is a matter of a few seconds, even without using a RAD - any cheap text editor will do. You just move a few tags around, and you're fine. If you have it hardcoded in C++, then the same thing is a desaster (plus, you have to recompile). That is the most important thing in my opinion.

[Game_Ender]

has one big advantage: it is easily extensible without the need to recompile anything (and without very painful code bashing).

Now the ability to quickly make a layout changes is very useful, especially if you don't have a RAD tool like DialogBlocks or wxSmith.  The catch is you can't change the name of any components without a code update and a recompile, and you can't make new event handlers or change event handlers, which is the other half of GUI programming.  Those task require a recompile, but I still think XRC is pretty good at what it does:  Quick GUI layout changes, and data interoperability.  I am not trying to bash XRC, but it is not a complete widget marshaling tool.

[takeshimiya]

XRC all the way, for the reasons stated above.

-Recompile time
-Interoperability: you can pass your XRC to a programmer of other language. It is RAD-agnostic, Platform-agnostic, and Language-agnostic.

[byo]

In my opinion there's no simple answer for this question. I've been investigating XRC standard (and source code of xrc) for some time and in some cases XRC is better but in others c++ source.

One of biggest XRC adventages is that resource is separated from code. This can make development process little bit easier and organized better.
But... XRC doesn't handle everything - sometimes not all styles supported by widget can be used, sometimes there's no content-managment for widget, so You have to add it manually, and try to fetch pointer to sizer from resource . Ok, these things may change in near future since it's not hard to add support for in in xrc source code.
But there are some other things which need to be mentioned: XRC doesn't have support for event handling so it must be done in the code. And one more thing - usually source code assumes that resource has specified structure or that some widgets exist in resource. What if unexperienced user changes xrc file a little bit ? Application will usually break because instead of widget pointers there will be NULLs.

So IMO XRC is really god thing during development but it may not be a good option for releases where I suggest c++.

BTW. wxSmith currently doesn't allow switching between xrc and source code (it will be supported but there's easy way to switch - close C::B, open wxsmith/wxsmith.cfg in text editor and for resources You want change edit_mode attribute for "Source" or "Xrc" than open C::B and change anything in resource to reproduce source code. That should work
One warning: some things (like pointers to sizers) may be lost when switching from Source to Xrc.

[takeshimiya]

BTW. wxSmith currently doesn't allow switching between xrc and source code (it will be supported but there's easy way to switch - close C::B, open wxsmith/wxsmith.cfg

byo, now that you say, I have two questions I wanted to ask:

-The .wxs files are straight .xrc files (sometimes you add/could add another tags), but as it's xml, I think the wx xrc loader shouldn't have any problem ignoring your (very little) new tags compared to .xrc files.
Having both .xrc and .wxs may seems no big deal, but it confuses newcomers.
I actually once experienced a bug in wxSmith where the .xrc gone out of phase of the .wxs, and it took me more than two hours to understand why it wasn't working. This could never happen if the xrc is edited directly.

-The wxsmith.cfg file. A minor issue compared to the one above. It's kinda a little project file, but I see that there could be three options:
1) Integrate it in the .cbp of the current user project.
2) Create a new .cbp only for wxSmith things.
3) Leave as is now, but improving it with versionating (more or less trying to be like a small .cbp).

So basically the current layout generated by wxSmith is as:

Code

dialog1.xrc
dialog2.xrc
project.cbp
wxsmith\
    Dialog1.xrc
    Dialog1.xrc
    wxsmith.cfg

and I think it could be something like:

Code

dialog1.xrc
dialog2.xrc
project.cbp
dialogs.wxsproject

wxSmith is amazing.

[byo]

byo, now that you say, I have two questions I wanted to ask:
-The .wxs files are straight .xrc files (sometimes you add/could add another tags), but as it's xml, I think the wx xrc loader shouldn't have any problem ignoring your (very little) new tags compared to .xrc files.
Having both .xrc and .wxs may seems no big deal, but it confuses newcomers.
I actually once experienced a bug in wxSmith where the .xrc gone out of phase of the .wxs, and it took me more than two hours to understand why it wasn't working. This could never happen if the xrc is edited directly.

You're right, the content of generated xrc files is almost equivalent to wxs and duplicated data has always came with troubles sooner or later . And xrc loader doesn't have any problems with loading wxs files. Actually when You click preview button id loads wxs file using xrc loader and shows it.
But I've noticed that other editors have some problems when additional info is added to xrc. I'll think about the solution. My current idea is to have one strict xrc file and one other for additional stuff

-The wxsmith.cfg file. A minor issue compared to the one above. It's kinda a little project file, but I see that there could be three options:
1) Integrate it in the .cbp of the current user project.
2) Create a new .cbp only for wxSmith things.
3) Leave as is now, but improving it with versionating (more or less trying to be like a small .cbp).

I vote for option 1 . But AFAIK there's no support in cbProject for this currently. So currently I'll leave it as is and maybe after some feature request cbProject will support this


Thx for all suggestions

[mandrav]

I vote for option 1 . But AFAIK there's no support in cbProject for this currently. So currently I'll leave it as is and maybe after some feature request cbProject will support this

Actually this is something I wanted to add for a long time now.
Good thing you reminded me. You can find it in revision 2052

[byo]

Actually this is something I wanted to add for a long time now.
Good thing you reminded me. You can find it in revision 2052

Wow, that was fast

Old wxsmith.cfg files will be removed as soon as I finish recoding wxSmith

[takeshimiya]

Old wxsmith.cfg files will be removed as soon as I finish recoding wxSmith

Great! If you need suggestions or anything else, I have them

Just something, with the recode it will be possible to target other languages, like Python or Lua?