Does anyone see any use in keeping the “Send crash reports” in the Application settings or in general?
I don’t even know if or where any reports are actually being sent…Besides I don’t even know if they were being sent anywhere is there anyone actually going to read them or capable of doing anything with them?
IMO a better idea would be to incorporate any log file into a bug report sent to a Github issue that a user “chooses” to send.
Reason I ask is I’m going to reorganize the “Configuration” settings to make more room, and also would like to get rid of this preference setting… not to mention there’s an unlabeled label defaulting to “TextLabel”.
Probably a good idea to remove. I don’t know what’s in those reports, but this kind of feature can very easily send sensitive information by mistake. In some jurisdictions this could be problematic if the user hasn’t affirmatively opted in to each element transmitted (e.g. under the GDPR).
My thoughts exactly. I always refuse to “automatically” send Microsoft or who ever crash data. If I need to I can choose to send the necessary info.
As far as what’s in the reports… it contains the usual OS and machine and build info, date & time… and what ever in the log files. Without trying to parse all the reporting code - I’m thinking the logs contain warning & error messages. as there;s a QT message handler installed in the logging method.
This sounds like a good list. Loaded dynamic library versions might also be handy for reprex, especially for resolving dll hell on Windows.
I really like your idea of creating a draft Github issue the user can edit and post. That way the user can redact anything sensitive themselves, as well as add additional context. The key fact that solves a bug could be something like “I just bought a new graphics card” or “my disk is getting full”… these facts might be perfectly obvious to the user but not included in the default crash report.
Well there’s currently a “Report bug” in the help menu that links to a new Github issue. In a feature branch I’m waiting to push contains an update to the Help menu → About dialog which includes a listing of all the system & build info… there’s a Copy to clipboard button that a user can use to cut & paste that info into an Issue bug report. Probably need to figure out an easy way to access a log file file to send appropriate info.
Like I said I don’t even know where the “send reports” is going - the Seamly website? - which is of no use to me or any other devs who don’t have access . Makes more sense from a dev’s point of view if it’s either sent to a Github issue or cut and pasted to a thread here. Not to mention it’s just more bloated code… which I hate.
Hoo boy. The following is based on a quick read of the code, and needs to be confirmed. I really hope I’m wrong.
The crash reporting code appears to be basically unchanged for at least 6 years, although at least 5 users have worked on the file containing this code since then, vapplication.cpp
Commit comments suggest reports are only sent on Windows, but I can’t immediately see where that check is implemented
Logs are sent verbatim to someone’s Github account as a gist. I have no idea who that github personal token belongs to, but I hope the owner has set it up to prevent others accessing the reports. Also gh tokens are supposed to never be disclosed, and this is a terrible and insecure attempt at obfuscation.
Like I said I hope I’m wrong. At the very least, I think we can do better at transparency with our users’ information. I could possibly confirm what’s going on in the debugger if I ever manage to get the build going.
To be a bit more constructive in my remarks, I think a better approach would be to attempt to construct a limited set of version information and logs, and give that to the user to edit and post as discussed.
Edit: some creative github searching turned up another active project (it appears to be a fork??) called Valentina, which appears to send crash reports to the same github account. I don’t know the history of this project so maybe that’s to be expected, but I found it surprising considering the potentially sensitive nature of the logs.
Edit 2. This is a reply to @Douglas’ message below. The rude forum software won’t let me post anymore because it says it doesn’t like newcomers.
Jolly good!
That makes two of us tbh
This topic happened to be the top thread when joined, which is why I clicked and ended up down a rabbit hole looking at the code
As someone that just joined the forums minutes before posting in this topic - make no assumptions about the project. I have no idea of your skill level, but if you looked further you would have saw this:
Which means that the CollectReports(), and subsequently the call to SendReports() are only included in the build IF the build is for Windows AND if the GNU C++ compiler is used. I happen to know MSVC is used in the workflows. So the reports code is not included in any Seamly2D releases… and thus the reports are not being used. Kinda of what I suspected, and why I asked the original question to begin with.
Debugger is not needed - I already know what’s going on… nothing., but hey knock your self out trying to get to that breakpoint.
Mostly in the interest of letting the forum software know that y’all aren’t the only ones to have an opinion on the matter I will submit my opinion that it is better not to have buttons that don’t work as advertised. Barring as an alpha feature, or, as long as it mostly works, as a beta feature. But it sounds like the crash-report checkmark should have been part of someone’s personal branch, but got pulled into the main distro due to a lack of proper vetting.
My software (on Mac) crashes every time my laptop sleeps and wakes up. I have to close the application everytime I stop working on it. I’ve never sent a report.
My ha’pennies worth… As far as I can remember (since 2017, Feb) The crash report has never worked and I have never had a need for it, anyway. Normally, a crash report option request should pitch up after a crash, to be reported. And this has never happened to me.
Also, anyone who has had a crash that wishes to report it, always does it here on the forum. So I agree… Crash report can go.
Well probably not since the fork. There’s no way it could, as there is the conditional above where only a Windows build using the GNU C++ complier would have the code. Also DrMngw needs to be installed. Our Githib workflows are using the MSVC compiler.
And “automatically” you never would, as the send reports only applies to GNU C++ Windiws builds. Which begs the question… why would this option even appear in a Mac build? I would assume you could confirm this checkbox exists on the Configuration prefs page?
That being said… I wish I had access to a Mac so I could more easily debug some of the Mac related issues such as the one you mentioned.
Agreed… To me buttons that don’t work are confusing & frustrating, and are like the old “Under Construction” on a webpage that exists forever. I hate to keep it pointing out, but IMO the reports stuff is just more crap RT threw in just because that’s what apps are supposed to do.
I’ve had my suspicions about the reports checkbox, but have just left it alone until now. I’m adding some editing options (specifically related to the improved Move, as well as the Rotate tool… options to append to the point names suffix… such as adding _MOV to get a name like A1a1_MOV to identify it as a move without having to type it in everytime), and need the room on the configuration page.
So… I’m removing the Send reports checkbox from the form as it’s another do nothing button. I could remove (or comment out) the application.cpp code as well ?
