= How to Submit a Ticket = === historical note === In the old SourceForge tracker we had ''Bugs'', ''Patches'' and ''Feature Requests''. Now we have ''tickets''. If you have ever used wx SF tracker, please read [wiki:WikiStart] to learn how to use the same username. === introduction === Before creating a new ticket, '''you must login'''. __Make sure that the e-mail address in your preferences is correct.__ Obviously, you should first search if the bug or proposed enhancement is already submitted (use [/search?ticket=on search] for global search or queries to list tickets with the classname in [query:status!=closed&summary~=grid title] or [query:status!=closed&keywords~=wxGrid keyword]). If you are not sure that you encountered the same bug, open a new ticket and add mutual links to both tickets (`#1234` is automatically linked). If you want to express interest in a bug that is already submitted, CC yourself or add more details. Or even better, try to fix it. === summary === Like in [https://wiki.ubuntu.com/X/Reporting#head-63f6d4e3e78a5db3d861bc10bdceab01d8c9ad8d other] issue trackers you should select a meaningful title. You may assume that the `summary` will be viewed together with `type` and `component`, so you don't need to write `[wxMac]` if the component is set to `wxMac`. === component === `Component` is the most important drop-down field. If the ticket is related to `wxHtml*`, `wxAui*`, `wxRichText*` or `wxStyledText*` or `OpenGL`, use these names as a component, but remember to write what wxPort and OS are you using. If you see a bug in the control that has generic implementation on your platform, select `GUI-generic`. `wxGrid` has generic implementation on all platforms. `wxFileCtrl` has native implementation only on GTK. When in doubt, look it up in a header file. If the bug is in the `base` sub-library (see [/browser/wxWidgets/trunk/build/bakefiles/files.bkl files.bkl] to find out which files belong there), select `base`. If the ticket is relevant to more than one port (and it's neither `base` nor `generic`), select GUI-all. `wxPython` is for Python-specific issues and for C++ classes that are in wxPython but not in wxWidgets. `build` is for ticket related to bakefiles, `configure.in`, `wx-config`, etc. You can probably guess when to use other options. === keywords === Use full C++ names of relevant classes as keywords (e.g. `wxFileDialog`, not ~~`file dialog`~~ nor ~~`FileDialog`~~). If your platform is not very popular, add it also as a keyword (e.g. Solaris, IRIX, Win9x). Other suggested keywords are: * `printing`, * `dnd` (for drag'n'drop problems), * `transparency` (for alpha-channel problems), * `thread` (for concurrency problems, if wxThread is not given), * `regression`. === version === Setting `version` is recommended, but `milestone` can be left to developers === description === Explain how to reproduce the problem. Check if you can see it in the samples. If not, try to make a '''minimal''' modification to one of the samples to demonstrate it and attach this modification as a patch (if the patch only demonstrates the bug, don't check the patch checkbox). If you use wxPython and can show the program in a few lines of Python code, that's also useful. Make sure the code is '''complete''' (with imports and instantiation of `wx.PySimpleApp()`) and '''minimal'''. ''Minimal'' means that every line of the code is necessary. Write what platform you are using. If you tested also other platforms or older versions, let us know. === patch === Attaching a patch that fixes the bug or implements the enhancement you propose will give a higher priority to your ticket. Please read [wiki:HowToSubmitPatches] for the details. === final note === At last, when you see that the bug you reported in the past was fixed, but the ticket is still open, we will appreciate if you close it. You can easily list [query:status!=closed&reporter=$USER&group=component all open bugs you reported]. And at any time, feel welcome to verify other bugs in the tracker.