Bug 502416 - close to tray should be default
close to tray should be default
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: tucan (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Simon
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-24 22:34 EDT by Rahul Sundaram
Modified: 2013-03-13 01:44 EDT (History)
4 users (show)

See Also:
Fixed In Version: 0.3.8-0.1.alpha.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-23 15:04:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rahul Sundaram 2009-05-24 22:34:43 EDT
Description of problem:

Close to tray should be enabled by default in the preferences. Usually download managers do this and users would expect this behaviour.
Comment 1 Simon 2009-05-28 17:32:35 EDT
this is not a bug, it's a feature request
Comment 2 tucaneando 2009-05-29 20:40:12 EDT
There are many window managers which doesnt have a notification area, its not default for compatibility issues.
Comment 3 Rahul Sundaram 2009-05-31 02:29:07 EDT
Software should optimizing for the common behaviour and not the corner cases. Majority of Linux users are undoubtedly using either GNOME or KDE. Both have a notification area. Even minimalistic window managers have extensions that support this behaviour these days. Those using these minimalistic WM's are usually power users well capable of changing the default and they can switch it off if needed.
Comment 4 Christoph Wickert 2009-05-31 06:17:14 EDT
As long as we do not have packaging standards to make sure a notification area is installed, we should not change the default behavior. If we had something like a virtual provides for "desktop-system-tray" that this package required, it would be ok - but we have not.
Comment 5 Rahul Sundaram 2009-05-31 06:21:28 EDT
Notification area is already a standard part of GNOME, KDE, Xfce etc and many applications already use it. What purpose a virtual provides serve? What WM's would make use of it?
Comment 6 Christoph Wickert 2009-05-31 06:32:08 EDT
(In reply to comment #5)
> Notification area is already a standard part of GNOME, KDE, Xfce etc and many
> applications already use it. 

Yes, and most of them - directly or indirectly - require a panel to make sure a notification area is installed. Or they don't have their tray icons enabled by default - just for that reason.

> What purpose a virtual provides serve? 

Make sure there is something to provide the systray so the app does not get hidden when you close it and you have none installed.

Take this package: How do we make sure there is a tray? And please don't talk of power users, this is something that needs to be sane on the packaging level and should not require any user action (like disabling the tray icon).

> What WM's would make use of it?

None. WM's or other packages would provide it and apps like this would make use of it.
Comment 7 Rahul Sundaram 2009-05-31 06:41:59 EDT
There are dozens and dozens of applications that depend on a notification area already. There is nothing special about this software. If you find virtual provides somehow useful, propose it in the packaging list.  T
Comment 8 Christoph Wickert 2009-05-31 07:39:55 EDT
(In reply to comment #7)
> There are dozens and dozens of applications that depend on a notification area
> already. 

Yes, and most of them somehow already require it. If they don't, they should not use it by default, simple as that.

> There is nothing special about this software. If you find virtual
> provides somehow useful, propose it in the packaging list.

I wanted to do this anyway, this RFE is a good reminder. Thanks.
Comment 9 Bug Zapper 2009-06-09 12:30:15 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Fedora Update System 2009-07-17 16:57:23 EDT
tucan-0.3.8-0.1.alpha.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/tucan-0.3.8-0.1.alpha.fc11
Comment 11 Fedora Update System 2009-07-17 17:07:38 EDT
tucan-0.3.8-0.1.alpha.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/tucan-0.3.8-0.1.alpha.fc10
Comment 12 Simon 2009-07-19 08:31:42 EDT
@rahul
it would be nice, if you give a karmapoint to the update. (after testing of course)
Comment 13 Fedora Update System 2009-07-22 17:55:38 EDT
tucan-0.3.8-0.1.alpha.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update tucan'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-7867
Comment 14 Fedora Update System 2009-07-22 18:00:48 EDT
tucan-0.3.8-0.1.alpha.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update tucan'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-7877
Comment 15 Fedora Update System 2009-07-23 15:04:04 EDT
tucan-0.3.8-0.1.alpha.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 16 Fedora Update System 2009-09-18 20:07:23 EDT
tucan-0.3.8-0.1.alpha.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

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