23dcc99781441ed5f592c0ddcc8dc6864c185a41
over HTTP as a POST form. This is intended to decrease the amount of effort required to submit bug reports, reduce the potential for human error, and increase the consistency of the form of bug reports (always a crashinfo.txt, no wrapping or RARring, not pasted into BTS text fields, and no forgetting it entirely). This offers less chance to fix the bug than a real BTS entry. We can't interact with the user (since the submission is anonymous and not tied to an email), so we can't get more information about the problem or offer solutions; we can only fix it based on the crashinfo. This will result in noise, due to crashes caused by drivers. We don't want people to send bug reports accidentally, but we also don't want to encourage cancelling the report. This dialog defaults to "view", so pressing enter neither sends the report nor cancels. We don't want people to modify crashinfo.txt before they send it, since we want consistency. (Data sent is not re-read from crashinfo.txt; it's simply kept in memory.) We also don't want to give people the impression that changes in "view" will change what's sent. At the same time, it's convenient to have the crashinfo "view" function load notepad. So, crashinfo.txt is marked read-only, so attempts to save over it in notepad will fail. In this mode, we don't offer the option to load log.txt, or point to a BTS. This is intended to make bug submission as simple as possible for casual users. Keep the dialog simple and to the point. The id number that's displayed after a submission is intended to be used as a reference; we can say "reproduce the crash, submit the report and tell us what number is shown in the corner", and easily locate the report. It's intended to be ignorable by the most users, so no attempt is made at explaining what it means. (It should probably be grayed out, but I havn't dug into it yet to figure out how to gray it while still allowing the text to get focus, so it can be copied.) We send over HTTP, on port 80. This is probably the most likely way to be able to send data out without any configuration. (The localization support is incomplete.)
Languages
C++
85.7%
Lua
4.3%
C
4.3%
Rich Text Format
2.3%
CMake
1.1%
Other
2%