Drop-down calendar does not close unless you click on it

[Nick Buchanan]

The drop down calendar in the panel that opens when you click on the date and time will only close if you click again on the date and time. It would be much nicer if the calendar would close with any click outside the calendar. For example: When I'm using the calendar, I tend to click it open, glance at it, and return very quickly to what I was working on. The intuitive thing would be for the calendar to simply close when I click back on the application I was working on, in order to keep work flow interruption to a minimum. But an extra click is required on the date and time bar itself to close the calendar.

Brainstorm idea: http://brainstorm.ubuntu.com/idea/18304/

[Michael Rooney (mrooney)]

I surprisingly couldn't find a duplicate so I've opened a task for gnome-panel.

[Umang Varma (umang)]

Do other applets like Volume Control, Drawers, etc require a new bug, or can this bug be modified to include all drop-down applets?

[Nick Buchanan (nscb)]

I just checked if this behavior is common to other applets, specifically volume control, screen resolution, network manager, and battery, and these will close with a click anywhere outside the applet. In fact, they behave as I would like calendar to behave.

[Umang Varma (umang)]

In that case, I better not report any bugs in this project till I upgrade to Jaunty. :P

[Textureglitch (textureglitch)]

I actually enjoy the current calendar drop-down behavior and I don't want it to change.

Right now I can browse and scroll freely in other windows while the calendar is still visible; something I do often when trying to match an email/schedule in a browser with my own current schedule.

If the calendar were to disappear when I click somewhere else then I cannot go back and forth from scrolling in a window and changing the month view in the calendar because it would get reset all the time.

[mati (mati-wroc)]

Textureglitch, maybe that behaviour could be kept with a double-click?

It's only an utility and definitely should disappear like other applets or menus.

[Michael Rooney (mrooney)]

That sounds like a usability hack, Textureglitch. You can already
scroll in unfocused windows as long as the cursor is over them, so
that would still work. And if you'd like to be able to type in
unfocused windows, then use focus-follows-mouse which allows this
globally. But like I said, scrolling in an unfocused window doesn't
give it focus so you could still do what you are talking about
regardless. The current behavior is inconsistent with other applets
and applications and I think is a confusing and annoying experience to
most users most of the time.

[Sjors Gielen (sgielen)]

I agree with Textureglitch. Maybe behavior like Yakuake's is in order: It has a button; when pressed, Yakuake stays open even if it loses focus, when unpressed it closes automatically. Though Yakuake's icon is quite unclear, adding such a simple button would fix this bug for both kinds of people: those who want it to close automatically, and those who don't. The button could simply have a thumbtack icon, with a little tooltip that explains what it does. No usability hacks, makes everybody happy.

However, such a solution does not qualify as a papercut, I think, so maybe this one should be marked as invalid and a different real papercut should be selected. Let's not leave users in the dark by just changing this behavior to what *other* people want. :)

[Bryce Harrington (bryce)]

Agreed with last comment. This does not qualify as a papercut since changing it as proposed could be seen as a regression by people who may prefer the current implementation; thus this change should either be done upstream, or requires the analysis of the design team to provide guidance first.

[David Siegel (djsiegel-deactivatedaccount)]

mpt, can you please offer a design suggestion for how the drop-down calendar should behave when you click off of it?

[Omer Mano (mermerico-gmail)]

Actually, what would really be cool (though not in papercut domain) would be the ability to undock the calendar, making it permanent. The behavior would then look like this:

1. The user clicks on the time and the calendar appears. The user clicks on a different window, and the calendar disappears.
2. The user clicks on the time and the calendar appears. The user clicks and drags the top of the calendar and it undocks from the panel and stays on top of other windows. The user clicks on the time, and a small animation shows the calendar returning to the panel and disappearing. If the user clicks on the time again, a similar animation shows the calendar returning to the same location it disappeared from.

This should solve all the issues people were having, and even gives us a nice widget-like thing (calendars are among the most commonly used widgets).

[Sjors Gielen (sgielen)]

What Omer Mano wrote is something like KDE (at least 4.3) has, only it has it in reverse:

1. When the user clicks on the time then focuses another window, the calendar stays.
2. When the user drags the calendar away, it becomes a separate window. Currently, the window then disappears right away (that's probably a bug, since I'm using 4.3 beta2...) but it should disappear when focusing another window.

I can't decide on whether Omer's or KDE's behavior (except for the bug, naturally) is more intuitive or logical, though. It's a matter of opinion. At least the idea is great, it's all in the details :)

[FiNeX (finex)]

I want to add a small note: the reason for keeping the calendar open on KDE 4 is based on the following use case:

1) Tom, our example user, wants to write a document or he wants to book something
2) Tom opens the calendar and go back to his application.
3) Tom can interact with the wanted application keeping the calendar opened so he can keep a watch on it.

[Radoslav Georgiev (valsodarg)]

I would like to propose further enchantments:

1. Open the calendar on prolonged hover over (User X hovers on the calendar for 5 sec or so and the calendar opens, it closes when the user click away or hover out)
2. Integrate (or rather figure how to) integrate with Thunderbird.

Now in all fairness #2 might not belong here, but I have it for a suggestion.
Additionally Ubuntu Developers might want to do the same schema for the volume manager (it currently stays open)

[Vish (vish)]

-1 to this idea!This would truly be a regression.

 the present behavior is good. Pls dont change it!

[Radoslav Georgiev (valsodarg)]

Perhaps the best solution is to make it configurable:
Have an option to in the preferences to autoclose, but leave it uncheck.

[Sebastien Bacher (seb128)]

adding options for such details only lead to non consitant desktop behaviour between installations and confusing dialogs for users, that's such a detail that users should be able to work with the behaviour either way

[karit (nzkarit)]

-1

Please leave as is. I like it to be open while I am writing in other windows.

[Hernando Torque (htorque)]

@17
What about another gconf-key? There already are keys like 'gmt_time' and 'format' that don't confuse users by not being present in the preferences dialog.

[Matthew Paul Thomas (mpt)]

Nick Buchanan is correct, I think, that expected behavior would be for the calendar applet to close in the same way other drop-down applets do. However, the calendar is unlike other applets in that (as Textureglitch says) it is often useful to have it open while referring to information in other windows, which may require switching between and scrolling through those other windows.

So, I suggest that the calendar have a dedicated button or menu item for opening it in a window by itself, and that once that is implemented, the drop-down calendar applet should close automatically when you click outside it. But that would be, as Bryce Harrington suggested, a feature quite a bit larger than a paper cut. And until that is implemented, I think changing the current behavior would aggravate as many people as it pleases.

(BTW, please don't use the Incomplete status unless a bug report is missing information on how to reproduce the problem or whether it has been fixed.)

[cenoura (maggico89)]

I think an intuitive and probably easy-to-implement solution would be as follows:
when the user clicks on the time, the calendar shows up, and when he clicks out it disappears. But when the calendar is open, it should have a little icon in the corner (like a pin or something) that when clicked "pins down" the calendar, so that it won't lose focus if the user clicks somewhere else.

(sorry for the poor english..)

[Umang Varma (umang)]

I agree with cenoura. This is the simplest, easiest and most intuitive solution that helps all. The "pin" should be a simple toggle button. I don't see a simpler solution.

I think the status should be made Confirmed and changed as described above (Comment #21): https://bugs.launchpad.net/hundredpapercuts/+bug/387573/comments/21

[Radoslav Georgiev (valsodarg)]

I have a simpler idea:

1. If the user Clicks on the calendar it should mimic the current behavior (as in stay open until clicked again).
2. If the user hovers-over the calendar it should mimic the debated behavior (as in stay open unless hover-out/click out)

Face it when you click on the calendar you do want it to show, which means that you would like to work/interact with it for longer than few seconds. However when you hover over it, you want to have a quick glance and are not interested in having to change stuff on it.

[Paul Natsuo Kishimoto (khaeru)]

The ideas of Omer Mano, Sjors Gielen and cenoura or Valsodarg both have merit.

Another addition would be a time-based hide. Before libnotify became common, I remember seeing popups with a little circular pie chart counting down a fixed period. Under some conditions (click, hover, long hover, whatever) the calendar could show with a similar chart near either a tear-off strip or a pin that would cancel the timer. The timer would communicate to the user the option to hold the calendar open longer.

[Radoslav Georgiev (valsodarg)]

Possibly but what if the user needs to switch application during the process or needs to use the mouse. (Your suggestion will require the mouse to hover over the calendar to keep it displayed ~ or at least thats what I understand)

[Stephen Irons (stephen-irons)]

My wife is a musician; she uses a computer because she has too, for email, writing program notes, etc. She does not just click around and experiment on the computer, because she is afraid she might break things, even though I have repeated explained that she cannot do any permanent damage.

She complained at me the other day because "I can't make the calendar thing go away".

It think that she had accidentally clicked on the date-time, rather than the power-off button next to it. To her, the calendar just appeared.

She did not know that clicking on the time again would make it go away -- everything else in the panel disappears automatically. Everything else that sticks around has a close button.

If the sticky behaviour remains, it should at least have a close button.

[Umang Varma (umang)]

Completely agree with Stephen. It has to have at least a "X" button that can be clicked to close it. I have had to close the calender for others at least a few times times already (in one year that is a lot).

[Sjors Gielen (sgielen)]

I can't believe the... lack of common sense... of some users.
Anyway, in general, they missed that clicking the time opened the calendar, and didn't understand how to close it. I'm actually against having a close button, since then there's two ways to close it and that could be confusing; also closing it by re-clicking the time is more intuitive if they know it actually does that.
So what about letting them know it actually does that, by, for example, highlighting the time when the calendar is open? Something like in OS X. If the calendar is open, the time in the panel is highlighted, and closing the calendar brings the time back to its original state. It shows users the relationship between the two, in an intuitive way; they will be able to find out how it works on themselves.
Do you think that's an idea?

So I propose this fix for this complete bug:
1) When the calendar is open, highlight the time in the panel
2) Show something like a paperclip or other icon on the calendar, and when clicked, the calendar stays around and doesn't close automatically (or the other way around: when clicked, it always disappears after a while).

[Umang Varma (umang)]

The second option I believe is the ideal solution. (https://bugs.launchpad.net/hundredpapercuts/+bug/387573/comments/21) But it doesn't look like everyone here found it a great idea, which is disappointing.

[Vish (vish)]

Since the papercuts invalid list is growing , some good ideas are getting lost , hence assigned it to Ayatana[after discussing with David Siegel] for further consideration.

The "pin" sounds like a reasonable good choice.

[Tralalalala (tralalalala)]

I absolutely like the calendar the way it behaves now and I don't want it to be changed. When doing my administration in OpenOffice.org Calc I've always got the Calendar opened and I really like the way I can enter data into Calc and at the same time look at the calendar to see which week numbers I have to enter into Calc. When one month is ready, I can just click on the arrow in the calendar to go on to the next month and I can just go on typing data into Calc. This is how the calendar should work.

[Vish (vish)]

Won't Fix in papercuts , but is tagged "ayatana" to be overseen in The Ayatana project.

[molecule-eye (niburu1)]

The current default behavior in Jaunty (not closing unless the applet is clicked) is inconsistent with the default behavior of most other applets and should be changed for consistency.

However, it would be nice to have the option of the calendar staying open when clicking off of it, e.g. by having a "sticky" button on the calendar. Plus there is good demand for this option, as evidenced by this thread.

[Sjors Gielen (sgielen)]

However, molecule-eye, the other applets you compare with, do they actually have the same use case? Are there any other applets that give information that a user may want to see while he's, for example, typing his e-mail? You can't, for example, compare the calendar with the volume control applet, obviously. :)

[Kip Warner (kip)]

This is an extremely annoying bug. My two cents.

[poikiloid (efelthauser)]

I liked the behavior of staying open until a second click to close it. But I like Omer's suggestion in comment #11 too.