On 05/18/2015 06:18 AM, Marek Brysa wrote:
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! :-)
I wish I had time to help but
don't, sorry. :(
The width of the list box on the left has the been calculated
precisely according to the design valid at that time:
https://wiki.gnome.org/Design/Apps/Oops
https://github.com/abrt/gnome-abrt/commit/046c730c293c5981a09af70ae769183...
Resizable width was explicitly rejected by designers. Granted, in
Allan's most recent design, the list seems wider and we'll take a look
at it.
https://github.com/abrt/gnome-abrt/issues/103 I don't have a good
solution to this; any number you pick will be
theme-dependent. Suffice to say it's no longer wide enough in F22. :(
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.
I'm not
sure what value there is in allowing multiple reports, but
anyway: this used to take you through the entire reporting process as
though you've never done it before, which was very confusing. At a
minimum, there should be a separate workflow for bugs that have
previously been reported somehow. But in F22, pressing the button indeed
does nothing, as far as I can tell.
> * 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?
Yeah sure.
> * environ, cmdline, backtrace, hostname, comment and reason
should not
> have horizontal scrolling. This makes them all extremely difficult to
> read.
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.
I figured that out
after using ABRT for some months. This is really not
obvious at all.
* Search -> Find. Search should be activated automatically by
typing,
This works in the problem list. Or do you mean while reporting?
I think I was
unclear. This is a really easy one to fix: I mean to
simply rename "Search" to "Find" because Search is a completely
different pattern. (As far as I can tell, the names are arbitrary.)
This is a useful tool and ABRT can do the same thing and more, it can
even automatically download debuginfos:
https://github.com/abrt/abrt/issues/934
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.
I can live with that: a small price to pay for
coredumpctl. Cool.
Thanks,
Michael