GNOME Bugzilla – Bug 329491
Add API to allow constraining popup windows to be "onscreen"
Last modified: 2015-03-08 13:52:02 UTC
I'm filing this to follow up on Owen's remarks in bug 161972 comment 15: "If you want to submit a patch to GTK+ that adds a new API to constrain a window to the workarea, that might be OK. An API to retrieve the workarea probably is OK. Starting to constrain POPUP windows without explicit app API is not compatible, and will not be accepted." As pointed out in that bug, this is something that is affecting lots of applications, ranging from making windows less usable (e.g. bug 329386) to causing accessibility issues (e.g. bug 161972). Now that Metacity finally handles keeping managed windows "onscreen" (and does so automatically without app intervention), I think it's time to kill these other bugs. It'd be easier to do so with gtk+ API. I'm willing to work on this, but there are some questions: - Do we just constrain to WORKAREA? This would be easy & fast, but since WORKAREA is required to be a rectangle doing this might be odd when dealing with partial struts; this wouldn't allow those popups in open areas next to those struts (which would probably only be a problem when the app itself was in such areas or adjacent to them, but may be really odd in such cases). - Do we do the general constraint problem to avoid offscreen & struts? We could just use the Metacity code that I wrote to do this and it'd avoid the problems with just doing WORKAREA, but it would mean monitoring struts of all other windows (or an EWMH extension to have the WM set some root property that we could monitor) and would be slower in pathological cases. - Do we make a new EWMH hint to generalize WORKAREA, as it seems a little odd itself anyway (it seems to predate partial struts, which means icons also avoid such areas)? - Should the API be at the gtk, gdk, or gdk_x11 level? - Should there be API for "please constrain all subsequent popups to be 'onscreen'" or for "please constrain this specific popup window to be 'onscreen'" or both?
Yes, the workarea think came earlier than the struts, and I think we never fully resolved that area of the spec to make sense. It would probably make sense to look into some standardized property where the window manager export the "effective workarea" which results from combining workarea and struts. That would allow gtk to just monitor a single property. On the other hand, we probably don't have to monitor at all, and it would be fine to just get the current value of the property when a window is popped up. You normally don't do that in a tight loop... I think we should have gdk api to get the "effective workarea", probably in the form of a GdkRegion, and gtk api to position a window, likely in the form of a GtkMenuPositionFunc, or similar
Nothing ever happened here, other than adding an api to get workarea, so applications can do the right thing if they want to.