About components

1) Can I access the components from Subversion ?

Sure! You just need a configured Subversion client, see this Sourceforge SVN doc. When reading the document, refer to the "About" and "Anonymous access" sections. Our suggested Subversion client is TortoiseSVN.

Please note that you can also browse the Subversion repository of a component online just following the links in the component list page.

2) What is the best way to get or use the wxCode components ?

It is recommended that you use SVN to get a copy of wxCode or just the individual components you use. Doing it this way places all the components in the same place, making it easier for you to use them in your own project.

If you find some issues with a component or just want to enhance it, you'll be able to provide diffs for sending patches (see question below) to the maintainer and then retrieve the updated version. We do however recommend that maintainers regularly create releases which can be downloaded from SourceForge and this is also a reasonable way to obtain the components you want. These releases should be considered stable versions.

As a last resort, you could copy the files into your own project, but you'll have to keep track of what you've got and manage your own build system. We strive to have each project have their own build files that will create a library to link to and using these is obviously recommended.

3) How can I submit my modifications back to the maintainer ?

In order to ensure a fast and easy processing of your modifications by the wxCode maintainers, you should strive to submit your modifications in the form of patches (a patch is something that we could apply with one command, not arbitrary text that we'd spend hours trying to understand):

  1. If you haven't already done so, get the SVN repository of the component. Look at FAQ #1 for more details.
  2. Under Windows you can tipically use your Subversion's "Patch" function (e.g. for TortoiseSVN you can right-click the component's folder from Explorer and choose "Make patch" or similar); save the patch somewhere (e.g. on the desktop) with a sensible name (possibly with extension .patch).

    Under Unix-like operating systems, open a "terminal" and type:
    svn diff --diff-cmd="diff" --extensions="-buw" >mypatch.patch
  3. Open the just-created file with any plain text editor and see if it looks correct (i.e. contains all modifications you want to sent to the maintainer).
  4. Submit your patch here (after logging in - i.e. you'll need a SourceForge user account - that's free and quick to create), attaching it and not copying-and-pasting.

    Also please describe up to a reasonable level of detail what the patch does and why and name the patch item as "[Component Name] subject of the patch" so that the relative maintainer can easily spot patches affecting his component.

4) How to submit a bug/feature-request for a specific component ?

See the support page.

About wxCode


5) Why should I host my component at wxCode when I can create my own Sourceforge project ?

You should create a separate SourceForge project if your component is very large and can sustain it's own community of users. If your component is small to medium sized, there are various advantages for hosting it at wxCode:

In conclusion, hosting your component at wxCode requires much less work and thus is a lot faster for you and easier for others to find (and use it).

6) The component list or something else in the site is not working as expected. What can I do?

Report the errors/warnings you get in the component list page as a wxCode bug... see the support page...

About component administration


7) How can I access the SVN repository for my component? How can I make a release for my component? How can I make the website for my component? How can I add a Bakefile-based build system to my component?

See the wxCode maintainer guide and eventually ask for help on the wxCode-users mailing list...

8) How should I ship resources embedded in my components: as XRC files or as hardcoded build functions ?

XRC resources allow you to keep separed the GUI and the code which handle it and, most important, they also make it possible for the end user to edit the resources of your component without modifying the code and possibly using a graphical XRC editor (wxGlade, wxDesigner... etc). However they force your component's user to link its program also with wxXML and wxXRC libraries. Hardcoded build functions instead has some speed advantage over XRC and do not require any additional linkage but they are much more difficult to modify and customize for users' needs. You are free to choice the resource build system you prefer but take in count that XRC system is widely used and in the long run is much more flexible...