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/046c730c293c5981a09af70ae769183c0a... 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