> With either xfce4-panel[1] or matchbox-keyboard[2] displayed, the > xy-maximization is fine.
> When both are displayed the xy-maximized windows are too high. See [3]: > the dialog's buttons are hidden behind the matchbox-keyboard.
> I guess this is an openbox bug since windows' sizes are ok with other > window managers - e.g. matchbox.
I am reassigning this and #550221 to matchbox keyboard now. I don't know this tool nor do I have the time to invest its x properties but it seems all unexpected behaviour recently involves this tool. I see no wrong behaviour in how openbox is handling ICCCM and EWMH compliance.
Cheers Nico
-- Nico Golde - http://www.ngolde.de - n...@jabber.ccc.de - GPG: 0xA0A0AAAA For security reasons, all text in this mail is double-rot13 encrypted.
> * Pini <gilles.filipp...@free.fr> [2009-10-21 12:59]: >> I use xfce4 + openbox + matchbox-keyboard on an Openmoko FreeRunner[0]. >> xfce4 is configured with 1 bottom xfce4-panel.
>> All applications are xy-maximized using this configuration snippet in >> ..config/openbox/rc.xml:
>> With either xfce4-panel[1] or matchbox-keyboard[2] displayed, the >> xy-maximization is fine.
>> When both are displayed the xy-maximized windows are too high. See [3]: >> the dialog's buttons are hidden behind the matchbox-keyboard.
>> I guess this is an openbox bug since windows' sizes are ok with other >> window managers - e.g. matchbox.
> I am reassigning this and #550221 to matchbox keyboard now. I don't know this > tool nor do I have the time to invest its x properties but it seems all > unexpected behaviour recently involves this tool. I see no wrong behaviour in > how openbox is handling ICCCM and EWMH compliance.
I've done some testing around this bug and set up a simple testcase to reproduce it (attached).
AFAIUI, all lies in how STRUTs are handled by the window manager. IMO they should be cumulative: when win1, win2, ..., winN set STRUTs, the resulting workarea should be cropped by STRUT1 + STRUT2 + ... + STRUTN.
The testcase demonstrates that openbox currently crops the workarea with max(STRUT1, STRUT2, ..., STRUTN) instead of their sum. This way is wrong - IMHO - since only one STRUT can be set at once per display side then. Moreover, setting - say - a right STRUT + a bottom STRUT results in an overlapping in the workarea's bottom right corner.
The window manager shown in the pictures documenting the bug is not Openbox. Openbox does not use rounded titlebars at this time, I would guess it is Metacity from the look of it.
-- To UNSUBSCRIBE, email to debian-bugs-dist-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hi, * Dana Jansens <dan...@orodu.net> [2009-11-05 19:45]:
> The window manager shown in the pictures documenting the bug is not > Openbox. Openbox does not use rounded titlebars at this time, I would > guess it is Metacity from the look of it.
I guess that comes from xfce...
Cheers Nico -- Nico Golde - http://www.ngolde.de - n...@jabber.ccc.de - GPG: 0xA0A0AAAA For security reasons, all text in this mail is double-rot13 encrypted.
Discussion subject changed to "Bug#551807: Re: Bug#551807: openbox: xy-maximized windows uncorrectly y-sized with xfce4-panel + matchbox-keyboard" by Gilles Filippini
> Hi, > * Dana Jansens <dan...@orodu.net> [2009-11-05 19:45]: >> The window manager shown in the pictures documenting the bug is not >> Openbox. Openbox does not use rounded titlebars at this time, I would >> guess it is Metacity from the look of it.
> I guess that comes from xfce...
As I've just explained on the upstream's BTS follow up, the confusion comes from the fact I've taken VNC snapshots of my FreeRunner - running openbox - from my laptop - running metacity.
I can assure that I've experienced this bug with openbox.
Running the provided testcase should be enough to convince you.
|
