From: <ma...@we...> - 2004-10-22 01:56:29
|
-- Jonatan Liljedahl <th...@ho...> wrote (on Thursday, 21 October 2004, 10:52 PM -0200): > On Thu, 21 Oct 2004 16:40:17 +0000 > Guido Schimmels <__g...@we...> wrote: > > > OroboROX 0.9.5 > > > > Link: > > http://roxos.sunsite.dk/dev-contrib/guido/ > > > > Changes: > > > > * fixes to get_wm_protocols(): fence post error and fallback to > > XGetWindowProperty() when XGetWMProtocols() fails (from xfwm4) > > * fix bug in handleButtonPress() which would lead to crashes on > > rapid clicks: win = get_mouse_window(dpy, c->frame) -> win = ev- > > > subwindow > > (again from xfwm4) > > * g_mainloop integration > > * more work on ping code (still disabled) > > * some work towards NET_WM_MOVERESIZE > > * fix two silly but harmless bugs in set_allowed_actions_hint() > > * insert "if (!client_exists(c))" safe-guards at various places > > * always focus new transient windows > > > > I didn't revert the modifier init code (xfwm4 -> Oroborus). > > If it still doesn't work everywhere I'd rather get it fixed, because > > > > the new code looks much better overall. > > I might do an interim release (0.9.5.1) with the old code though. > > Still same thing here, the eventhandling is broken. (modifier init > code). Does the new keyboard.c really look that much better? The old one > works (Especially with my ignore_mask stuff, didn't that fix your > numlock problem, Stephen?) > Is anyone else but me having this problem with the new keyboard.c? Could you explain again what the problem is that you're seeing, and how to reproduce it? I haven't noticed any keyboard issues with 0.9.5 so far (used it all day at work today, and installed at home this evening). > * FireFox (0.9) still gets only a close-button. xprop says > _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, > _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, > _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE. > I don't understand why MAXIMIZE is missing, but anyhow there is > apparently some other problem as SHADE and MINIMIZE is there but not on > the titlebar. It's nice that there is an option to disable this feature > now, though! =) Hmmm... I'm using Firefox 1.0PR, and get the following from xprop: _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE Notice, MAXIMIZE is not there by itself, but each of MAXIMIZE_HORZ and MAXIMIZE_VERT *are*. Perhaps this is a Firefox behaviour that has changed from 0.9 to 1.0PR? But, while on the topic of maximization... The oddity I'm noticing is this: if I maximize the window, then press the maximize button again, it reverts to its original shape fine. Repeat, rinse, lather, works great. If I vertical or horizontal maximize, then restore to original size... it WON'T do any sort of maximization at all from that point forward. Oh, and this is true on ALL windows, not just Firefox. > * struts aren't avoided when windows open. I have open at mouse-pointer > and if I start an app from the panel it opens there and covers the > margin. (No big deal) That's working fine for me. However, if I maximize a window, it doesn't obey struts on the right or left sides (i.e., it covers my right panel, but not my top panel). -- Matthew Weier O'Phinney ma...@we... http://weierophinney.net/ |