GNOME Bugzilla – Bug 531850
Clock applet's calendar does not place correctly when applet is on a bottom panel
Last modified: 2020-11-06 20:22:59 UTC
Please describe the problem: I moved my main panel to the bottom of the desktop. When I click on the clock applet to bring up the calendar (without the evolution appointments section expanded), about one third of the time the window pops up with its lower edge about five pixels *below* the bottom of the screen, obscuring both the last week of the month and the applet button that I need to click to close the applet. When the appointments tab *is* expanded initially, the bottom of the calendar window is even farther below the edge of the screen, but surprisingly, the top of the window (where it says |>Appointments) is at the same place as the first case above. In both cases, the workaround is to click the panel (to bring it above the applet), click the clock to close the applet, and click it again to reopen the applet. About two thirds of the times I click it (based on tests of repeatedly opening and closing the applet's calendar window) it works fine; one third of the time it shows this buggy behavior. The applet shows this behavior when it is on a side or bottom panel, but not on a top panel. On a side panel it's not so crippling though, as the difference is just between a calendar rendered several pixels up or down. There is, however, no constraint in any of these cases that keeps the calendar from rendering off-screen, as in the case where a side-panel-located clock is placed near the bottom of the panel, in which case the whole thing is cut off. Steps to reproduce: 1. Create a bottom-aligned panel. 2. Place a clock applet on that panel. 3. Open the clock applet's calendar between 1 and 5 times. Actual results: One of those times, the calendar is placed unusually low; sometimes so low that it goes offscreen. Expected results: The calendar will always be placed so that A: All parts of the calendar are on-screen, and hence clickable. B: The original clock applet is clickable without any explicit window-focusing onto the panel. Does this happen every time? About one third of the time, apparently at random, even when I attempt to reproduce the bug one time after another without changing anything about my setup. Other information: I will attach several screenshots.
Created attachment 110492 [details] Screenshot of incorrect rendering
Created attachment 110493 [details] Screenshot of correct rendering
Created attachment 110494 [details] Bad placement happens even without the appointments section expanded
Created attachment 110495 [details] One possible placement for a side-panel clock's calendar...
Created attachment 110496 [details] ...and another.
*** Bug 518840 has been marked as a duplicate of this bug. ***
This happens to me when something causes the applet to change while it's open. For example, just now I was adding a bunch of calendars to Evolution; when Evolution finished downloading events from the server, the popup updated and obscured the area of the panel I need to click to close it. (It seems that I can't get my mouse to the clock applet without the popup moving back above it, unlike the original reporter — perhaps because I use focus-follows-mouse — so now I get to restart my panel. Yay!)
This still happens with clock-applet 2.30.2. The calendar is out of position when the panel the applet is attached to is in any place other than the top of the screen. Being able to move the calendar popup (and then have the applet remember the position) would fix this problem in the short term. The obvious long term solution is to make the applet behave more intelligently with regards to calendar placement.
Its probably time for someone to mark this as confirmed after two years on the list, yeah?
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.