After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 338729 - clock applet calendar popup positioning doesn't work on all WMs
clock applet calendar popup positioning doesn't work on all WMs
Status: RESOLVED OBSOLETE
Product: gnome-panel
Classification: Other
Component: clock
2.12.x
Other Linux
: Normal normal
: ---
Assigned To: Panel Maintainers
Panel Maintainers
Depends on:
Blocks: 338728
 
 
Reported: 2006-04-16 19:28 UTC by Dan Winship
Modified: 2020-11-06 20:20 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dan Winship 2006-04-16 19:28:26 UTC
metacity has a bug in its handling of resizing windows with non-NorthWest gravity, Obug 338728), and the calendar popup in the clock applet depends on this bug for correct functioning.

Specifically, if you place the applet in a bottom panel, click it to pop up the calendar, and then click back and forth between two days with different numbers of events listed, then under metacity, the bottom of the popup will stay pinned to the top of the panel, but under most other WMs (or with no WM), the top-left will stay pinned and the popup will either shrink and detach itself from the panel or grow and overlap the panel.

The fix is that the window needs to both move and resize itself when it gets
a size_allocate in that situation.
Comment 1 Elijah Newren 2006-04-17 01:36:57 UTC
Since I notabug'ed 338728, I'll add a short comment here: The metacity 'bug' Dan mentions is explicitly defined as correct behavior in the EWMH as a clarification (Dan would probably prefer I used quotes on that word) to how window gravity is supposed to work.  My opinion is that the other unnamed WMs and the no WM cases are buggy.  But, that's a discussion for wm-spec-list.  Dan and many others admittedly smarter than me might decide otherwise and get the EWMH changed.

Of course, that doesn't rule out working around those other buggy WMs...  :-)
Comment 2 William Jon McCann 2006-06-16 02:30:15 UTC
If I remember correctly, at one point it did use the standard gravity and do a move and resize.  It looked terrible.  I think the way it works now, at least under metacity, is much better.  So, I don't think we should change back.  Getting it to this point took quite a bit of work and I think it finally works well.

I have no idea if the metacity behavior is a bug or not but it is certainly helpful to have this kind of functionality in some form.
Comment 3 Dan Winship 2006-06-16 13:38:40 UTC
(In reply to comment #2)
> If I remember correctly, at one point it did use the standard gravity and do a
> move and resize.  It looked terrible.

If it did a separate move and resize, it would have looked bad, but if it
did them together it would look exactly like it does now.

> I have no idea if the metacity behavior is a bug or not.

Metacity complies with the EWMH as written. There was discussion on wm-spec-list
about this, and there was not a consensus that the EWMH was wrong, and there
was at least a weak consensus to not change the EWMH regardless, so metacity is
not buggy by that definition.

However, the calendar still does the wrong thing if you're running no window
manager at all.
Comment 4 André Klapper 2020-11-06 20:20:40 UTC
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.