Created attachment 4508 add a calendar popup to the clock plugin I have seen multiple requests [*] asking for a calendar popup that opens up when clicking on the xfce4-panel clock, it has probably become expected behavior since this is how the KDE/GNOME/LXDE/xfce4-datetime-plugin panel clocks behave. Attached is a patch that adds this functionality to the xfce4-panel clock plugin, it allows to toggle the visibility of a window containing a GtkCalendar widget which is shown next to the plugin with a single click on the clock itself. This is disabled when a command is defined in order to not interfere with double clicks. [*] most recently https://bugzilla.novell.com/show_bug.cgi?id=767145
A calendar popup that does nothing feels kinda useless to me (or I'd at least expect something to happen when I'd click a date).
(In reply to comment #1) > A calendar popup that does nothing feels kinda useless to me (or I'd at > least expect something to happen when I'd click a date). I think its main purpose is to quickly look up a weekday corresponding to a certain date, ie. the equivalent of using cal(1) on a terminal. A toggle widget with an unmanaged popup window is more convenient than having to start up and to subsequently close a specialized application positioned by the window manager. Based on some requests and the fact that this is rather universally available across desktops, I've been convinced that actually a clock/calendar panel widget not providing such functionality is somewhat counterintuitive. All implementations I've checked (GNOME 2, GNOME Shell, KDE 4, LXDE) have the current day marked but allow the user to click on and select a different day without any actions resulting from it. Provided you agree that the above is at least somewhat useful functionality, what would be an acceptable implementation? AFAICS it is not possible to disallow selection with a GtkCalendar, I suppose it'd be possible to implement a calendar-like table of the current month inside the tooltip though it'd be less useful since it would be impossible to view a different month. For reference I'll attache a screenshot of different implementations.
Created attachment 4559 calendar popup implementations
Ok, well then we apply this. I'll also add GTK_CALENDAR_SHOW_WEEK_NUMBERS.
(In reply to comment #4) > Ok, well then we apply this. I'll also add GTK_CALENDAR_SHOW_WEEK_NUMBERS. OK, thanks, that is might be useful as well.
Pushed in 0456c3. Changed the code to lazy initialize to calendar widget/window on the first popup and some small code-style adjustments.
8e4e5be Hide calendar window on <Esc> or mouse press outside the popup. Added code for making the calendar popup behave like a transient window (like menus do). It can be closed by clicking anywhere on the screen outside the popup, or by pressing "Esc".
(In reply to comment #7) > 8e4e5be Hide calendar window on <Esc> or mouse press outside the popup. > > Added code for making the calendar popup behave like a transient window > (like menus do). It can be closed by clicking anywhere on the screen outside > the popup, or by pressing "Esc". Why? I find it inherently useful that I can e.g. switch windows or desktops while looking at the current calendar. It's also how other calendar popups behave. Can you please revert this?
Grabbing focus is also illogical behavior, the window is purely informational and doesn't wait for an user action like a menu or volume slider etc.
Guido, I obviously like the new behavior so my opinion might be skewed. I don't like popups to float around and pollute my window list only because I forgot to click the launcher again. Also, when I wanted to see the calendar again, clicking on the clock didn't work, I had to click twice (first click was hiding the buried popup, the second was showing it again). I found this behavior rather annoying, to the point I wrote a patch. I really though I am fixing a clear-cut deficiency (not to say a "bug") in the previous design and I expected people (and certainly you) to generally like the new behavior. Since it is no longer that obvious, I will wait for Nick's opinion on that matter. If he also is in favor of removing this feature I will promptly revert the patch.
There is something weird going on with window management. I have just tried the previous design on my laptop and generally it works well. The popup doesn't close but it stays on top of other windows so it cannot be accidentally lost. This, however, wasn't the case on my workstation. If the popup was guaranteed to work like this I have no preference for either keeping or reverting my patch. However, I'd propose a few minor tweaks: 1. make the clock a button, so it is clear what to do to close the popup, 2. make the calendar not to take keyboard focus at all. This is what old Gnome's clock applet used to do and it worked rather well.
(In reply to comment #11) > There is something weird going on with window management. I have just tried > the previous design on my laptop and generally it works well. The popup > doesn't close but it stays on top of other windows so it cannot be > accidentally lost. This, however, wasn't the case on my workstation. > > If the popup was guaranteed to work like this I have no preference for > either keeping or reverting my patch. However, I'd propose a few minor There must be something wrong with you WM, the popup code makes sure the correct windows state is set up, namely _NET_WM_STATE_STICKY, _NET_WM_STATE_SKIP_PAGER, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_ABOVE. The latter should keep it at the same layer as the panel itself and it should follow around and not show up in the task bar, this works fine with xfwm4 and the panel's own taskbar plugin. > tweaks: > 1. make the clock a button, so it is clear what to do to close the popup, That would be nice, might be difficult though for modes other than "digital". > 2. make the calendar not to take keyboard focus at all. > This is what old Gnome's clock applet used to do and it worked rather well. Sounds ok.
I have reverted the previous patch and implemented above mentioned features in andrzejr/clock branch. Not sure what was causing the WM issues on my workstation (will debug it later). I have quite a few of other problems with Xfce built on top of RHEL5 so that could have been something unrelated. The button seems to work just fine with all kinds of clocks. I've kept the "Esc" key function from my previous patch. The calendar popup is allowed to take keyboard focus (no change here). The frame looks ugly inside the button and takes additional space (padding) so in separate commits I've removed it completely.
Hi Guido, this is just a small detail, but would you mind removing the frame around the calendar widget? I talked to Andrzej a short while ago on IRC and we both agreed that it looks better without it. (If you need a screenshot-comparison let me know ;)) The other small detail I was wondering about is whether the calendar should hide when it loses focus. We also discussed that and I suggested we could make middle-click show the calendar persistently and left-click hide it on focus-loss. Thoughts on that? (I personally think both use-cases are viable and make sense and I think this variant would be better than a configuration option – mostly because you might want _both_ behaviors at different times.) Cheers, Simon
(In reply to comment #14) > this is just a small detail, but would you mind removing the frame around > the calendar widget? I talked to Andrzej a short while ago on IRC and we > both agreed that it looks better without it. (If you need a > screenshot-comparison let me know ;)) No, I wouldn't mind. > > The other small detail I was wondering about is whether the calendar should > hide when it loses focus. We also discussed that and I suggested we could > make middle-click show the calendar persistently and left-click hide it on > focus-loss. Thoughts on that? > (I personally think both use-cases are viable and make sense and I think > this variant would be better than a configuration option – mostly because > you might want _both_ behaviors at different times.) Middle-click is a possibility and much better than a config option which would be overkill, but it might be difficult to discover for users. In any case, I won't object as long as opening a non-modal window remains possible.