Bugzilla – Full Text Bug Listing
| Summary: | Display.getClientArea() includes toolbar on Linux | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Tod Creasey <Tod_Creasey> | ||||
| Component: | SWT | Assignee: | Eric Williams <ericwill> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | billy.biggs, eclipse, ericwill, kmarmaliykov, m.sched, Matthew_Hatem, mseele, olivier.cailloux, remy.suen, svandijk | ||||
| Version: | 2.1 | Keywords: | triaged | ||||
| Target Milestone: | 4.10 M1 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux-GTK | ||||||
| See Also: |
https://git.eclipse.org/r/128142 https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=f18822ba0a908eca14702cd1bb430358b57f9f12 |
||||||
| Whiteboard: | RHT | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 33054, 105879 | ||||||
| Attachments: |
|
||||||
|
Description
Tod Creasey
Chrix, is there API to get the usable screen area? Maybe you saw some in your journey through multi-monitor land ... If not, close as WONTFIX (ie. CANTFIX). Thanks. POST 2.1 Switching OS to Unix All There appears to be a way to get it through some window manager property such as _NET_WORKAREA. Created attachment 8461 [details] _NET_WORKAREA patch This patch implements a fix for getClientArea/getBounds using _NET_WORKAREA from the EWMH spec. It was tested on metacity 2.4.34/GNOME2.2/RH9. I noticed some weirdness with how this was implemented on Kwin from KDE 3.2, and I tried to take that into account when decoding the result of the query, but I have not tested that yet. The patch caches the result of the query for 8 seconds since it currently takes two round trips to the X server to query the work area, and there is a lot of code which seems to want this information. The property is queried using the GDK function, which the docs here say should not be avoided: http://developer.gnome.org/doc/API/2.0/gdk/gdk-Properties-and-Atoms.html#gdk-property-get I would like to update my patch to use the X call, but it would require adding some more native methods and stuff, and since this works and the function was already there, I thought it should probably be saved for later. OK, the patch was now successfully tested on KDE 3.2 as well. :) Thanks for the patch Billy. The gnome window manager (metacity?) on RH EL3 appears to have the same bug it had a year ago. In particular _NET_WORKAREA does not return a correct area when the task bar is set vertical on the right of a 2 multimonitor system or in between the 2 monitors. Marking as WONTFIX. Actually, I was wrong all along. This is fixable in the multi-monitor case as well. What I missed was _NET_WM_STRUT_PARTIAL's relationship in all of this. _NET_WM_STRUT_PARTIAL is the atom which gives you the list of all panels and their absolute positions. This is what metacity and other WMs use to calculate the work area. Internally, metacity has a work area per xinerama head which is calculated from this data in the obvious way. Furthermore, the SWT API for this already exists. Monitor has a getClientArea() which is apparently filled in with the appropriate information under Windows. Using _NET_WM_STRUT_PARTIAL this could be implemented for Gtk+. With the dual head case solved, I would suggest that Display.getClientArea() should return the result of _NET_WORKAREA under Gtk+, since this is the 'global workarea' and does work in the single-head case. Monitor.getClientArea() is already used in the jface code to position windows, so this should be fixed too. I can file a new bug report on that if you like. Reopening. Need to investigate _NET_WM_STRUT_PARTIAL for Monitor.getClientArea (Billy: if you have code that uses _NET_WM_STRUT_PARTIAL for Monitor.getClientArea, please past it here. Thanks) *** Bug 82571 has been marked as a duplicate of this bug. *** Moving to Billy. *** Bug 86260 has been marked as a duplicate of this bug. *** Fixed > 20050922 on GTK+ in the single monitor case using _NET_WORKAREA. There is no standard yet for the multi-head case, and the partial strut stuff doesn't work. Still need to fix Motif. Not fixed on my single-monitor GTK install (gnome 2.12). Both Monitor::getClientArea and Display::getClientArea return the screen resolution, including the task bar. With what window manager? (In reply to comment #13) > With what window manager? Metacity. Could it be a recent regression in metacity? Run 'xprop -root |grep WORKAREA', it should look like this: _NET_WORKAREA(CARDINAL) = 0, 25, 1920, 1175 If it's not blocking off enough room for your panel, then this should cause other bugs, like your nautilus icons on the root window would be appearing underneath the panel. If the workarea is wrong, you should file a bug at bugzilla.gnome.org, probably against metacity. (In reply to comment #15) > Could it be a recent regression in metacity? No, xprop output seems ok for my 1400x1050 screen and one panel at the bottom: _NET_WORKAREA(CARDINAL) = 0, 0, 1400, 1014 I do have four virtual desktops, though, but I figured this would not matter. The full output is: _NET_WORKAREA(CARDINAL) = 0, 0, 1400, 1014, 0, 0, 1400, 1014, 0, 0, 1400, 1014, 0, 0, 1400, 1014 OK, this is clearly our bug :( is there any chance to get this fixed in the near future? I believe the problem I saw is with Control::getMonitor, which creates its own monitor instead of picking one from Display::getMonitors. I filed bug 147418 for this. Monitor::getClientArea works almost as expected if one of the monitors from Display::getMonitors is used. I noticed the following minor thing: when I have multiple vertical panels at either the left or right side of my screen, only the outermost ones (the ones along the edges of the screen) are subtracted from the screen bounds to compute the client area. Panels that are stacked are considered as client area. Is there a chance to see this fixed in the future? This bug occurs on, I guess, most linux-based platforms, which are supposed to be supported by SWT, and that in a very central and useful API call... I don't understand why the patch for at least the single-monitor case has not been included in the mainstream SWT, or did it not work? I can't believe there would be no way under linux to ask for the client area... How would the other software work? Did someone found a workaround, in the meantime? Thanks a lot. Update: Monitor.getClientArea seems to be working with 4.2 + Ubuntu 12.04. Display.getClientArea still seems wrong. Changing platform to Linux GTK Ubuntu 13.04, KDE 4.10, problem still exists with SWT 4.2.2. Both Monitor and Display ignore the toolbar dimensions. xprop output correctly subtracts them. Also this problem exists with Unity(standart Ubuntu desctop environment). Still reproducible on 4.8 M7 and GTK3.22. I will investigate. New Gerrit change created: https://git.eclipse.org/r/128142 (In reply to Eclipse Genie from comment #27) > New Gerrit change created: https://git.eclipse.org/r/128142 This patch fixes the issue by using Display.getWorkArea(), which queries the _NET_WORKAREA from the WM. Since this is a "big" change, I'll merge this patch in 4.10. Gerrit change https://git.eclipse.org/r/128142 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=f18822ba0a908eca14702cd1bb430358b57f9f12 (In reply to Eclipse Genie from comment #29) > Gerrit change https://git.eclipse.org/r/128142 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=f18822ba0a908eca14702cd1bb430358b57f9f12 Patch is in master now. Verified in I20180923-1800. |