Closed Bug 954184 Opened 8 years ago Closed 8 years ago

Expand Tray Icon context menu with commonly used actions

Categories

(Instantbird :: Other, enhancement)

All
Windows XP
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bugzilla, Assigned: clokep)

References

Details

Attachments

(1 file)

*** Original post on bio 750 by Paul [sabret00the] <sabret00the AT yahoo.co.uk> at 2011-04-10 10:17:00 UTC ***

We should be providing the same usability in the context menu of the system tray icon that we do in the jump list.
Blocks: 954054, 953598
*** Original post on bio 750 at 2011-04-10 13:03:46 UTC ***

This isn't blocking jumplist support but only parity to it on pre-Win 7 systems. It's rather blocking bug 954055 (bio 619), which is OS specific integration and menus.

In my opinion the idea sounds good though.
Blocks: 954055
No longer blocks: 954054
Summary: Tray Icon context menu should provide functions on parity of basic jump list support (bug 618) → Tray Icon context menu should provide functions on parity of basic jump list support
*** Original post on bio 750 at 2011-04-10 13:09:47 UTC ***

This really has nothing to do with jump lists, I think it's good to refer to bug 954054 (bio 618) while fixing this bug, but having exact parity I think is a poor assumption when going into the bug.  We need to look at the actual issue and see how to best fix it instead of directly proposing a solution.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: All → Windows XP
Summary: Tray Icon context menu should provide functions on parity of basic jump list support → Expand Tray Icon context menu with commonly used actions
*** Original post on bio 750 by Paul [sabret00the] <sabret00the AT yahoo.co.uk> at 2011-04-10 14:39:43 UTC ***

(In reply to comment #2)
> This really has nothing to do with jump lists, I think it's good to refer to
> bug 954054 (bio 618) while fixing this bug, but having exact parity I think is a poor
> assumption when going into the bug.  We need to look at the actual issue and
> see how to best fix it instead of directly proposing a solution.

At current jump lists are available on two OSs. Most computers are running pre-jump list version of Windows. Are we really going to penalise them for not upgrading? Also the sheer assumption that users access jump lists in the same way they do the system tray, something they've been taught for years is a huge assumption. We can always slowly drop support for the system tray but for now it should be fully featured. If we generate the options elsewhere, we can feed them to the jump-list and the system tray equilaterally for now. And start filtering some out post-1.0. Bare in mind that bug 954054 (bio 618) only deals with basic support (i.e. tasks) and not usability bonuses/extended support (i.e. frequent conversations).
*** Original post on bio 750 at 2011-04-10 14:46:39 UTC ***

(In reply to comment #3)
> At current jump lists are available on two OSs.
They're only available on Windows 7 currently (as far as I know at least). But that shouldn't stop someone from implementing them if someone wants to.

> Most computers are running
> pre-jump list version of Windows. Are we really going to penalise them for not
> upgrading?
How are we penalizing them at all? All I said is that this is not related to jump lists and should be handled separately.

> Also the sheer assumption that users access jump lists in the same
> way they do the system tray, something they've been taught for years is a huge
> assumption.
That's exactly what I said, that's why I'm saying this should be handled separately.

> We can always slowly drop support for the system tray but for now
> it should be fully featured. If we generate the options elsewhere, we can feed
> them to the jump-list and the system tray equilaterally for now. And start
> filtering some out post-1.0. Bare in mind that bug 954054 (bio 618) only deals with basic
> support (i.e. tasks) and not usability bonuses/extended support (i.e. frequent
> conversations).
Sure, and that's part of the solution, but I don't think we should file bugs with a preconceived idea of the solution. They should be filed to identify short comings and bugs in the software, then the best, more efficient way to fix them can be identified. I think it's good to keep it in mind, just doesn't make sense to block on it or anything like that.
*** Original post on bio 750 at 2011-04-10 16:50:49 UTC ***

Just my 2 cents: the current tray icon context menu looks stupid with only the "Restore" and "Exit" items. I initially wanted to include there items to quickly change the current status, but the current way to change the status doesn't work without being able to focus the blist window (which is clearly not desirable when doing things quickly from the systray icon). This is very similar to bug 954180 (bio 746) which is on Mac about the status selector of the menu bar which doesn't work when there's no buddy list window.
*** Original post on bio 750 at 2011-06-27 18:24:19 UTC ***

This is not just a Windows issue. On Linux it is just as annoying that it is not possible to change status (available/away/offline) from the taskbar icon.

Another minor flaw is that the taskbar icon disappears from the taskbar when the contact list is displayed. This makes it impossible to click the taskbar icon again to *hide* the contact list.
*** Original post on bio 750 as attmnt 921 at 2011-10-22 15:28:00 UTC ***

This adds "Available", "Unavailable" and "Offline" to the tray icon's context menu. I wanted these in a submenu (Set Status), but that doesn't seem possible using the MinTrayR code AFAIK.
Attachment #8352663 - Flags: review?(florian)
Assignee: nobody → clokep
Status: NEW → ASSIGNED
*** Original post on bio 750 at 2011-10-25 17:27:28 UTC ***

(In reply to comment #7)
> Created an attachment (id=921) [details]
> Feature parity with Jumplist
> 
> This adds "Available", "Unavailable" and "Offline" to the tray icon's context
> menu.

The code in the patch looks fine. (I'm assuming you have tested it of course.)

> I wanted these in a submenu (Set Status), but that doesn't seem possible
> using the MinTrayR code AFAIK.

What's the problem? MinTrayR doesn't seem to make any magic with that menu, so why couldn't it have a submenu done exactly in the same what that the File menu currently has a submenu?

(By the way, from a UX point of view, I'm not sure a submenu would be better.)
*** Original post on bio 750 at 2011-10-26 12:04:32 UTC ***

(In reply to comment #8)
> (In reply to comment #7)
> > I wanted these in a submenu (Set Status), but that doesn't seem possible
> > using the MinTrayR code AFAIK.
> 
> What's the problem? MinTrayR doesn't seem to make any magic with that menu, so
> why couldn't it have a submenu done exactly in the same what that the File menu
> currently has a submenu?
> 
> (By the way, from a UX point of view, I'm not sure a submenu would be better.)

I probably did it wrong (I tried putting another menupopup around the three status items, but I probably needed a menu tag outside of that).  If you think it's better anyway, it doesn't matter though!

And yes, I tested it. It seemed to work fine.
Comment on attachment 8352663 [details] [diff] [review]
Feature parity with Jumplist

*** Original change on bio 750 attmnt 921 at 2011-10-26 23:28:52 UTC was without comment, so any subsequent comment numbers will be shifted ***
Attachment #8352663 - Flags: review?(florian) → review+
*** Original post on bio 750 at 2011-10-26 23:58:17 UTC ***

Checked in as http://hg.instantbird.org/instantbird/rev/893f46ec629d
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.2
You need to log in before you can comment on or make changes to this bug.