thank you for pointing out these issues. I tried to answer most them inline.
----- Original Message -----
From: "Michael Catanzaro" <mcatanzaro(a)gnome.org>
To: "Discussions about development for the Fedora desktop"
Sent: Friday, May 15, 2015 11:26:47 PM
Subject: Re: Significant drop in ABRT reports in F22
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.
By that time we should have DBus API even for Bugzilla reports and as Richard mentioned,
it should be fairly easy to write a completely new GUI to perfectly fit Gnome's UX.
The wheels are in motion, it's just that our team is moving a lot of them. We
certainly welcome and appreciate any contributions - send patches! :-)
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
> 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
* 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.)
This is a problem that needs to be addressed in the back-end. We'll take it into
account when doing the new DBus API.
* Problems should not disappear *while they are currently being
reported* as that leads to a confusing error message.
Same as above.
* The list box on the left is not wide enough, resulting in a small
of horizontal scrolling.
The width of the list box on the left has the been calculated precisely according to the
design valid at that time:
Resizable width was explicitly rejected by designers.
Granted, in Allan's most recent design, the list seems wider and we'll take a look
* Above the list box, there is a distinction between My (what?
crashes?) and System (what?) crashes that's not relevant or meaningful
This is again a problem in the back-end.
* System crashes mysteriously disappear from the System list and
in the My list while being viewed.
This will be fixed with reworked D-Bus API.
* I can click the Report button on problems that have already been
reported to both the ABRT server and to Bugzilla. Nothing happens when
You should be able to report a problem as many times as you wish because you can send a
report via e-mail or you can upload the problem data etc.
If "Nothing happens when I do.", then you've found a bug.
* 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.")
Could you please create and issue for that?
* The menu allows launching both Preferences and ABRT Configuration,
which are separate(!) dialogs.
We are going to merge those dialogs, but it's not high in our priorities.
* The window title of the Preferences dialog is Configuration. The
window title of the ABRT Configuration dialog is Problem Reporting
* 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.
I think we need to go over why each one of these options should not be configurable.
Hopefully we don't need to go over why each one of these options
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.
Is that something in Gnome's HIG? Anyway this is because we need to launch a separate
libreport process for reporting. It should be doable with a single window using the new
* 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
ABRT is not a GNOME-only project. The tool provides a bridge between Desktops and
libreport. GNOME is not he only Desktop we need to support.
* 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
Please report false positives so we can do assisted learning :-)
* The UI shouldn't mention "Fedora Contrib group
that's meaningless to users.
* environ, cmdline, backtrace, hostname, comment and reason should not
have horizontal scrolling. This makes them all extremely difficult to
I believe this is a matter of preference. For me, wrapped lines are less readable.
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....
You don't need to scroll, you can jump by search result.
* The Forward button is a text button in the bottom right. It should
an icon button in the top right of the header bar.
This can be addressed in reporting UI using the new DBus API.
* Search -> Find. Search should be activated automatically by
This works in the problem list. Or do you mean while reporting?
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.
The coredump goes through a sanity check when ABRT generates a core backtrace. There is
unfortunately no way of telling whether full retracing will succeed unless you actually
try it. Please note that programs crash because they reach an unexpected state so there is
a significant probability that so much memory is corrupted that the retracing simply
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.
As I said, the reporting "wizard" is part of libreport and it will be much
easier to work on it once the new DBus reporting API is in place.
> Retrace server is something different and there's no reporting to
> retrace server - retrace server (surprise) does retracing of core
> to generate micro reports sent to faf.
Thanks for the correction. What does faf stand for?
FAF stands for Fedora Analysis Framework.
It lives on the same machine as the retrace server because they can benefit from each
other's data. Right now, we're internally discussing an even tighter integration
of the two.
> If you ever talked to ABRT developers about these sort of things you
> would know that there's integration ongoing to use tooling that
> provides (both coredump hook & journald) so it would be possible to
> 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
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.
This is a useful tool and ABRT can do the same thing and more, it can even automatically
We're going to introduce the tool very soon.
In the meantime, you can enable abrt-journal-core that makes ABRT use coredumpctl:
# systemctl disable abrt-ccpp
# systemctl enable abrt-journal-core
# systemctl start abrt-journal-core
The only downside is that the coredump is saved twice - once in journal and once in
ABRT's dumpdir. This is the reason it's not enabled by default, but we're
going to solve it in the future.
> By tremendous cost you mean you can't use fancy coredumpctl gdb
> 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
> I agree abrt-cli is not the most usable
> or intuitive tool but I haven't seen an RFE from you about its
> features. So why you are bashing our project instead of trying to be
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).