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/046c730c293c5981a09af70ae769183c0a07034a
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
--
desktop mailing list
desktop@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/desktop
