Bug 502416 - close to tray should be default
Summary: close to tray should be default
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: tucan
Version: 11
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Simon
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-05-25 02:34 UTC by Rahul Sundaram
Modified: 2013-03-13 05:44 UTC (History)
4 users (show)

Fixed In Version: 0.3.8-0.1.alpha.fc10
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-23 19:04:14 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Rahul Sundaram 2009-05-25 02:34:43 UTC
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 21:32:35 UTC
this is not a bug, it's a feature request

Comment 2 tucaneando 2009-05-30 00:40:12 UTC
There are many window managers which doesnt have a notification area, its not default for compatibility issues.

Comment 3 Rahul Sundaram 2009-05-31 06:29:07 UTC
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 10:17:14 UTC
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 10:21:28 UTC
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 10:32:08 UTC
(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 10:41:59 UTC
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 11:39:55 UTC
(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 16:30:15 UTC
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 20:57:23 UTC
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 21:07:38 UTC
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 12:31:42 UTC
@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 21:55:38 UTC
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 22:00:48 UTC
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 19:04:04 UTC
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-19 00:07:23 UTC
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.