About components |
1) Can I access the components from CVS or Subversion ?
Sure! You just need a configured CVS client, see this Sourceforge CVS doc, or a configured Subversion client, see this Sourceforge CVS doc. When reading both documents, refer to the "About" and "Anonymous access" sections. Our suggested CVS and Subversion clients are TortoiseCVS and TortoiseSVN.
Please note that you can also browse the CVS/Subversion repository of a component online just following the links in the component list page and that each component is either in the CVS repository or in the Subversion one, not in both.
2) What is the best way to get or use the wxCode components ?
It is recommended that you use CVS 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):
- If you haven't already done so, get the CVS repository of the component (or the Subversion one if the component is using Subversion instead of CVS, i.e. has a 'Browse Subversion' link instead of a 'Browse CVS' link in its description). Look at FAQ #1 for more details.
- Under Windows you can tipically use your CVS/Subversion's "Patch" function (e.g. for TortoiseCVS and 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:cvs diff -bu2 >mypatch.patch
(if you checked out the CVS repository) orsvn diff --diff-cmd="diff" --extensions="-buw" >mypatch.patch
(if you checked out the SVN repository) - 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).
- 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 | ^ TOP |
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:
- wxCode is a well-known place for developers using wxWidgets to look for code. It's more likely that you find someone who will appreciate (and find) your work here.
- Since wxCode contains a number of components, people can pick and choose among them. If they use CVS, they won't have to download each package individually and deal with the hassle of managing them separately.
- You can use the wxCode bakefiles to easily write the build systems for your components. The wxCode bakefiles provide all the basic stuff for a typical component.
- You already have a website skeleton for your component and documentation specific for setting up a wxWidgets-based cross-platform component.
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 | ^ TOP |
7) How can I access the CVS 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 in the wxCode-users mailing list...
How can I create a wiki-based website for my component ?
Just go in the wxCode wiki and create a new link to your component page in the sidebar menu. Then edit your component page as you would do in any other wiki. To make it easier (for you) to update your component info you should not writ ein the wiki (which is not connected to the wxCode database) some things like the most updated version of your component; instead you should give to the user a link to your component database info:
http://wxcode.sourceforge.net/showcomp.php?name=MYCOMP
Common things to put in the wiki: TODO lists, feature request lists (alternative to the SF feature request tracker), a space for user's comments...
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...
