[vlc-devel] [PATCH] Windows: don't display a dialog when crash upload fails

[Wilawar]

I read this mail only now when I decided to reduce the pile of crud that
had accumulated in my VLC-Dev folder. If everything has already been
done, feel free to ignore this comment.

I can testify that the previous approach was very annoying especially if
VLC crashed multiple times in a row as I had to click through stuff
multiple times, sometimes waiting for the box to show up first, and
overall modal message boxes are very jarring in general. However, it’s a
good thing to let people know and give a choice about pushing bug
reports to somewhere on the Internet, which I expect of every well-
mannered program, so the one asking for confirmation will have to stay
(which it will, as I understood this).

> I think we are going about this the wrong way, and that it certainly
> make sense to invoke MessageBox with relevant contents if a bug-report
> fails to upload
As seems to be the way things are and as outlined above, I will have to
vouch for the opposite approach here. It’s at first totally
inconsequential for users if their bug reports aren’t being sent, except
for maybe not receiving bug fixes in the long run. It’s just not a
priority at all and thus doesn’t warrant annoying them with modal
message boxes, pulling attention to them (away from everything else) and
requiring explicit action to proceed with what they wanted to do.
The report sending can also slow down users if they experience multiple
crashes in a row, as every attempt takes time to finish.

> (maybe even ask if the user would like to save it somewhere for later
> access in that case).
This is a very good idea, they should be saved in some accessible
location like the user’s 'vlc' directory by default and this location
then documented on the ’Net as well as been given an entry in the 'Help'
menu of the main GUI. I would go even further in that the sending should
be totally asynchronous and maybe even be done by a small mini-service,
which could be started by a scheduled task on Windows. It might have
been easy to implement sending it at the next program start and it even
has the advantage of giving predictable behaviour, but other than that
I’d say that it has never been nice. That said, I’ll admit that I don’t
want to implement this myself. It’s certainly a chunk of work to do and
as such I don’t expect it to be done soon, but maybe, one day, someone
will. In the meantime, I guess that archiving stuff (don’t forget to
limit the storage consumed by this to maybe a few MiB at most) and
pointing to the archive from the GUI is within reach, however.

> I am personally not a big fan of diagnostics […]
Regarding the wording, I’d vouch for mentioning the relevant party,
which I cannot see without looking at the code in the file (it’s not in
the diff) and also plainly stating that VLC couldn’t connect to it. Just
use something like
"VLC couldn’t connect to the bug report server. (Plain FTP to
infestation.videolan.org,  TCP from port 49873 to port 23 [and from port
53581 to port 48278])".
I guessed that VLC doesn’t use secured FTP and I also suppose that
it’s much rarer that the first connection would succeed but the second
one won’t (that’s why I put the second port combo in braces). Also
note how I managed to pack all the technical info into it that users
would need to configure their firewalls properly and how I separated
it from the short non-technical info that anyone could read to know
what happened even if they had no clue about FTP and ports. I’m a bit
proud of this feat. :)

-- 
http://www.fastmail.com - Accessible with your email software
                          or over the web

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20161011/b0a82e54/attachment.html>