Bug 520293 - Bad user interaction when service isn't running
Summary: Bad user interaction when service isn't running
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: abrt
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jiri Moskovcak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-30 10:43 UTC by Mads Kiilerich
Modified: 2015-02-01 22:48 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-03 20:06:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Mads Kiilerich 2009-08-30 10:43:27 UTC
Description of problem:

When I have abrt installed and the server isn't running (because of some other error) then it (I assume) shows a grey warning sign in the notification area with just the tooltip "Daemon is not running". The user has no way to find out which daemon isn't running.
Click does nothing - which also is quite confusing. Right click makes it disappear - which is even more confusing.

It also seems like et pops up a notification message before it has got a place in the notification area, so the message is shown all the way to the left, pointing at the Fedora logo.

After restarting the ABRT service it appears again and notifies me "Warning, ABRT service has been started" - nice to know, definitely not worth a warning.

The tooltip then changes to "ABRT service is not running" - that's fine. But it confuses me why the message has been changed.


Version-Release number of selected component (if applicable):

abrt-0.0.7.1-1.fc12.i686

Comment 1 Jiri Moskovcak 2009-09-01 14:15:21 UTC
Hi,
> The user has no way to find out which daemon isn't running.
I changed the confusing tooltip, so now it says "ABRT service ..." every time.

> Click does nothing - which also is quite confusing.
- click should open the abrt-gui, which doesn't make sense if daemon is not running

> Right click makes it disappear - which is even more confusing.
- I agree and I added a pop-up menu with "Hide" and "Quit" items as an right click action.

> so the message is shown all the way to the left
- Yes, I noticed that, but according the code the icon is shown before the notify message, but I'll investigate it little deeper.

Jirka

Comment 2 Mads Kiilerich 2009-09-01 14:42:50 UTC
Cool - let me know when there is a koji build I can try

Comment 3 Jiri Moskovcak 2009-09-02 15:36:25 UTC
http://kojipkgs.fedoraproject.org/scratch/jmoskovc/task_1649615/ it's just a scratch build, so it won't last there for a long time ...

Comment 4 Mads Kiilerich 2009-09-02 23:30:05 UTC
Yes - it seems better. Except that it no longer crashes, so I can't get into the same error state ;-)

A couple of other comments:

It is confusing that running abrt as an ordinary user does nothing. I would probably expect the daemon to be called "abrtd" leaving the name "abrt" for the gui tool.

It seems strange that "abrt-gui" starts in the background. I see no reason for that.

The icons in abrt-gui lacks tool-tips explaining what they do. Especially the "save to disk" icon is confusing.

The "report" window looks fine, but it doesn't inform me what will happen when I click "send". Will it send to bugzilla.redhat.com, or what is going on? It is fine to make it easy to send reports, but we also don't want too much noise.

It seems strange that the abrt-applet icon appears just because the abrt service has been started.

The applets menu with "hide" and "quit" is fine, but the user still doesn't know what he is hiding or quitting. I suggest adding a "About ABRT" (which will be enough for some users) leading to an about box with something like "ABRT applet - pops up whenever an incident is detected and helps reporting it".

"ABRT has been started" might be ok as popup, but the tooltip should be more like "ABRT is running".

I once noticed that the tooltip for hovering over the applet icon showed up all the way to the left. 

"Crash has been detected" is also sometimes shown to the left. When it is shown at the right place it looks like it flickers once to the left first.

Breaking abrt-gui or yum with ctrl-c also shows up as an crash in abrt - I guess python KeyboardInterrupt always should be ignored.

It confused me that provoking a crash in my own binary didn't show up. I would rarther have it show up in the abrt system - but obviously it should say something like 
Sep  3 01:24:36 localhost abrt daemon: Executable doesn't belong to any package
the messages below but let me see the stack trace and perhaps mail a report to someone or save the report to a file.

The following message is however both duplicated and wrong:
Sep  3 01:24:36 localhost abrt daemon: Warning: Corrupted or bad crash, deleting...
Sep  3 01:24:36 localhost abrt daemon: W: 'Corrupted or bad crash, deleting...'
The crash was neither corrupted or bad - it was just unknown.

Comment 5 Jiri Moskovcak 2009-09-03 11:30:20 UTC
(In reply to comment #4)
> Yes - it seems better. Except that it no longer crashes, so I can't get into
> the same error state ;-)
> 
> A couple of other comments:
> 
> It is confusing that running abrt as an ordinary user does nothing. I would
> probably expect the daemon to be called "abrtd" leaving the name "abrt" for the
> gui tool.
> 

Agree, I'll change it.

> It seems strange that "abrt-gui" starts in the background. I see no reason for
> that.
> 

Don't understand this, if I run abrt-gui, it shows up like any other app.

> The icons in abrt-gui lacks tool-tips explaining what they do. Especially the
> "save to disk" icon is confusing.
> 

Will fix.

> The "report" window looks fine, but it doesn't inform me what will happen when
> I click "send". Will it send to bugzilla.redhat.com, or what is going on? It is
> fine to make it easy to send reports, but we also don't want too much noise.
> 

Hm, user should probably have a choice to specify which plugin(s) he wants to use for reporting the bug from the report dialog, now it just try to use all enabled plugins. And for the noise - abrt can find if the bug is already BZ, so it won't report it again.

> It seems strange that the abrt-applet icon appears just because the abrt
> service has been started.
> 

I'll change it.

> The applets menu with "hide" and "quit" is fine, but the user still doesn't
> know what he is hiding or quitting. I suggest adding a "About ABRT" (which will
> be enough for some users) leading to an about box with something like "ABRT
> applet - pops up whenever an incident is detected and helps reporting it".
> 

I'll add the about window.

> "ABRT has been started" might be ok as popup, but the tooltip should be more
> like "ABRT is running".
> 

If I change the behavior of the applet to not show when the daemon is started there is no need to set any tootlip.

> I once noticed that the tooltip for hovering over the applet icon showed up all
> the way to the left. 
> 
> "Crash has been detected" is also sometimes shown to the left. When it is shown
> at the right place it looks like it flickers once to the left first.
> 

I know, trying to fix it.

> Breaking abrt-gui or yum with ctrl-c also shows up as an crash in abrt - I
> guess python KeyboardInterrupt always should be ignored.
> 

Also known bug.

> It confused me that provoking a crash in my own binary didn't show up. I would
> rarther have it show up in the abrt system - but obviously it should say
> something like 
> Sep  3 01:24:36 localhost abrt daemon: Executable doesn't belong to any package
> the messages below but let me see the stack trace and perhaps mail a report to
> someone or save the report to a file.
> 
> The following message is however both duplicated and wrong:
> Sep  3 01:24:36 localhost abrt daemon: Warning: Corrupted or bad crash,
> deleting...
> Sep  3 01:24:36 localhost abrt daemon: W: 'Corrupted or bad crash, deleting...'
> The crash was neither corrupted or bad - it was just unknown.  

I agree that the message is misleading, but the handling of unpackaged programs is quite a lot work (the plugin logic is not ready for that) so it will take some time, but it is on our TODO list.

Comment 6 Mads Kiilerich 2009-09-03 20:06:24 UTC
abrt-gui starts in the foreground for me too now.

Thanks. I will close this report and continue on the upstream tracker instead. ;-)


Note You need to log in before you can comment on or make changes to this bug.