Surely gnome-abrt does not look as bad as before, but I do not agree that it has improved "a lot." Automatic crash reports are very valuable, but they will work just fine without gnome-abrt. Bugzilla reports are even better, but the UI for this is just not good enough. Continuing to ship it makes us seem less professional. To be clear: I'm not opposed to continuing to ship the system service that reports crashes automatically. Nor do I propose any changes for F22; it's way too late for that. But I do think we should remove gnome -abrt from the default install in F23. On Fri, 2015-05-15 at 16:41 +0200, Richard Marko wrote: > Sure. It's rocket science to make a GUI according to Gnome HIG, cause > it > shouldn't have any buttons or features. 2-3 years? I can and I will > write an Qt app for ABRT in 2-3 days when our DBus API stabilizes. > > I'm wondering what according to you is "in shape" as in my experience > most Gnome apps went downhill in terms of usability, features and > overall look. I'm sorry that my last mail was too harsh. I find gnome-abrt to be very frustrating to use. Here are some problems I see: * Random italic and bold text in the "This problem has been reported, but a _Bugzilla_ ticket has not been opened" label. * Problems should not disappear from the list with no indication as to why. (Removing core dumps to free disk space is good. Hiding the history of crashes completely when they're removed is not.) * Problems should not disappear *while they are currently being reported* as that leads to a confusing error message. * The list box on the left is not wide enough, resulting in a small bit of horizontal scrolling. * Above the list box, there is a distinction between My (what? crashes?) and System (what?) crashes that's not relevant or meaningful to users. * System crashes mysteriously disappear from the System list and appear in the My list while being viewed. * I can click the Report button on problems that have already been reported to both the ABRT server and to Bugzilla. Nothing happens when I do. * The word "ABRT" appears in the UI. What's an ABRT? (The string ABRT appears in several other places throughout the UI, and can be replaced by "Problem Reporting.") * The menu allows launching both Preferences and ABRT Configuration, which are separate(!) dialogs. * The window title of the Preferences dialog is Configuration. The window title of the ABRT Configuration dialog is Problem Reporting Configuration. * Both dialogs use the action area (buttons across the bottom of the dialog), which is deprecated. The dialogs should use a header bar and put the buttons there. * The ABRT Configuration dialog uses color question icons. They should be symbolic icons. * The Preferences dialog just needs to be removed. The huge lists of Workflows and Events are way too detailed. This looks good for a power user tool, but apps we ship by default should be simple to use. Hopefully we don't need to go over why each one of these options should not be configurable, except for Bugzilla account details. * If I click Configure on an item in the preferences dialog (e.g. Report to Fedora), the notebook items are too wide for the window, with horizontal scrolling. They start out scrolled to the right, so the leftmost portion of the first letter of each preference is cut off. * Clicking the Report button opens a new window. The application should use only one window. * There is too much blank space before the text Add a screencast. * Add a screencast launches a confusing tool with Stop, Record, Select window, and Close buttons in the bottom-right corner of the screen. It should use GNOME's professional built-in screen recording functionality instead (Ctrl+Alt+Shift+R). * Possible sensitive data is a false positive 99% of the time. Jakub added lots of filters to try to reduce these, but it's still always wrong. * The UI shouldn't mention "Fedora Contrib group members" because that's meaningless to users. * environ, cmdline, backtrace, hostname, comment and reason should not have horizontal scrolling. This makes them all extremely difficult to read. Attempting to scan a backtrace of any length for personal data is a chore, since I have to scroll down a bit, then scroll all the way across to the right, then scroll back to the left, then scroll down a bit more, then scroll all the way across to the right.... * The Forward button is a text button in the bottom right. It should be an icon button in the top right of the header bar. * Search -> Find. Search should be activated automatically by typing, filter (hide) content, and have an icon button in the header bar. We use Find for jumping around between content. * Pressing Ctrl+F should start a Find. * Most importantly, reporting very frequently fails with the message that the backtrace is unusable. That should almost never happen. If sufficient debug info isn't available, it shouldn't be possible to start a report. I don't intend to file problem reports for these (although I already have for a few). There are just too many issues. The landing screen looks mostly good. The rest of the tool does not. > Retrace server is something different and there's no reporting to > retrace server - retrace server (surprise) does retracing of core > dumps > to generate micro reports sent to faf. > > https://abrt.readthedocs.org/en/latest/howitworks.html Thanks for the correction. What does faf stand for? > If you ever talked to ABRT developers about these sort of things you > would know that there's integration ongoing to use tooling that > systemd > provides (both coredump hook & journald) so it would be possible to > use > coredumpctl and abrt alongside. I actually have many, many issue reports, about half or so of which were promptly fixed by Jakub. In particular, one related to coredumpctl: https://github.com/abrt/abrt/issues/835 I believe we've also discussed it on this list in the past. It's a killer feature that we should enable ASAP. The first time I typed 'coredumpctl gdb' I knew that I would never be able to seriously use a distro without systemd again. > By tremendous cost you mean you can't use fancy coredumpctl gdb > command > but with little effort you can write a simple wrapper around abrt-cli > that does the very same thing. Hm, "tremendous cost" was too hyperbolic, sorry. I want coredumpctl working out of the box, but it's probably more important to have ABRT by default. > I agree abrt-cli is not the most usable > or intuitive tool but I haven't seen an RFE from you about its > missing > features. So why you are bashing our project instead of trying to be > constructive? I don't care about abrt-cli because it's a CLI tool that most users will never notice or deal with. I don't think I've used it before ever. I do care about Problem Reporting (gnome-abrt). Michael -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
