Re: assertion error "PRI(owl) >= priority" otp.c line 248
> I mean, I'm actually assuming an _array_ would work better than > either. But if I can't dream up insane anti-solutions that would > _technically_ work, what's the point of weekends anyway? Good point. This said, the current way windows and turned into TwmWindow structs has been "efficient enough" for several decades (for me anyway, and I routinely have 200-300 windows), and AFAIK hardware resources are not depleting yet (even though single thread performance has stopped improving), so I think there's no hurry to improve this ;-) Stefan
Re: assertion error "PRI(owl) >= priority" otp.c line 248
>> Hmm... so is it because we changed PRI(owl) without changing the >> OtpWinList accordingly, [...] > > Yes[0]. The PRI() of the transient changed when the main window > gained focus, but it's still down among the normal windows where it > was prior. Looking at OwlEffectivePriority which in my code was just a access to the owl->priority field, I see that the priority is now a lot more dynamic, so there's indeed a lot more ways to change the priority and forget to adjust the stacking accordingly. >> I missed this change. I'm not very familiar with FULLSCREEN. Why >> do we need to change the OTP depending on focus? > https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html#STACKINGORDER > >* [on the top of everything] focused windows having state > _NET_WM_STATE_FULLSCREEN I don't understand how that spec says that focus changes should change stacking order. It doesn't seem to say anything about what we should with FULLSCREEN windows that don't have focus, so it seems perfectly acceptable to keep them on top. To my naive reading, I'd argue that we should raise windows to the foreground when they get the FULLSCREEN prop and disregard focus. Of course, that shouldn't make any significant change to the code anyway: when we get a property change to/from FULLSCREEN we need to restack the window (and potentially its transients), and if we decide to pay attention to focus, then it just means we also need to restack similarly when the focus of a FULLSCREEN window changes. And indeed, that's what I see. So, yes, the code has changed a fair bit since when I wrote it, and the fact that priority can be "inherited" by transients means that several windows can change priority at the same time, so restacking needs to look for the transients and restack them as well (and be careful not to run the consistency check before they've all been restacked). Stefan
Re: assertion error "PRI(owl) >= priority" otp.c line 248
On Mon, Jul 08, 2019 at 11:08:25AM -0400 I heard the voice of Stefan Monnier, and lo! it spake thus: > > Actually, what we obviously need to do is get rid of TwmWindow > > structs wholesale, just embed SQLite, and store our runtime data > > there; then the indexes will find them for us! > > I don't follow. Wouldn't a hash-table work just as well? SQLite > seems like a rather expensive way to implement a hash-table. I mean, I'm actually assuming an _array_ would work better than either. But if I can't dream up insane anti-solutions that would _technically_ work, what's the point of weekends anyway? -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: assertion error "PRI(owl) >= priority" otp.c line 248
On Mon, Jul 08, 2019 at 11:04:10AM -0400 I heard the voice of
Stefan Monnier, and lo! it spake thus:
>
> Hmm... so is it because we changed PRI(owl) without changing the
> OtpWinList accordingly, [...]
Yes[0]. The PRI() of the transient changed when the main window
gained focus, but it's still down among the normal windows where it
was prior.
We don't _move_ the transient to a new priority; it's just THERE as
soon as its master has focus. 's why the solution I wound up with was
that we just needed OTP entry points that explictly say "do {un,}focus
stuff", rather than the previous "restack this window", so it knows it
needs to explicitly handle already-unsorted stuff as part of the
action.
> IIRC we already had code doing something along those lines, more
> specifically code that raises its transients when we raise a normal
> window (see RaiseSmallTransientsOfAbove).
Yes, but that has two issues. One, it only does _Small_ transients,
so misses larger one. And the other (and the reason I couldn't just
use TryToMoveTransientsOfTo()) is that it embeds assumptions about how
to find the transients, which aren't effective since it's not where
its priority would indicate in the list (heck, if it were, we wouldn't
be eating the assertion fail, either...).
> I missed this change. I'm not very familiar with FULLSCREEN. Why
> do we need to change the OTP depending on focus?
https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html#STACKINGORDER
* [on the top of everything] focused windows having state
_NET_WM_STATE_FULLSCREEN
> Can you point me to the code which changes the "OTP" in response to
> focus change?
That happens in OwlEffectivePriority() (which PRI() is just a call
to).
https://bazaar.launchpad.net/~ctwm/ctwm/trunk/view/head:/otp.c#L1654
[0] In my case. I'm still going with the assumption that Olaf's is
closely related, except his seems to happen on _un_focus rather
than focus, but we haven't managed to verify it yet.
--
Matthew Fuller (MF4839) | fulle...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
Re: assertion error "PRI(owl) >= priority" otp.c line 248
> Actually, what we obviously need to do is get rid of TwmWindow structs > wholesale, just embed SQLite, and store our runtime data there; then > the indexes will find them for us! I don't follow. Wouldn't a hash-table work just as well? SQLite seems like a rather expensive way to implement a hash-table. Stefan
Re: assertion error "PRI(owl) >= priority" otp.c line 248
>> From what I remember of the time I wrote and debugged OTP, these >> problems were invariably due to things like calling RaiseWindow >> instead of OtpRaiseWindow. > > That would lead to assertion failures where it compares against the X > window stack. These troubles are triggering a bit earlier, on the > > assert(PRI(owl) >= priority); > > e.g., the priority isn't monotonically increasing from the bottom->top > of the OWL. Hmm... so is it because we changed PRI(owl) without changing the OtpWinList accordingly, or is it because we changed OtpWinList without changing PRI(owl)? > This got trickier with the _FULLSCREEN stuff, where the > effective OTP of a window now depends on whether it has focus or not, I missed this change. I'm not very familiar with FULLSCREEN. Why do we need to change the OTP depending on focus? Can you point me to the code which changes the "OTP" in response to focus change? > And, in this case, DOUBLE tricky, because its transients have to move > with it; IIRC we already had code doing something along those lines, more specifically code that raises its transients when we raise a normal window (see RaiseSmallTransientsOfAbove). Stefan
Re: Binding a function to key+mousebutton
Matthew D. Fuller wrote: I'd suggest commenting out the Ungrab call and running with it. See what happens :) I did that and immediately figured out why it was needed :-) I was going to make Alt+Mouse1 execute "xvkbd -text '\\m3v'", so that in Firefox Alt+Mouse1 would open the context menu and send a "v". Doing that while over a picture would then save this picture, thus simulating the old "Ctrl+Mouse1 = Save Picture" from Opera 11. Now with that Ungrab commented out, ctwm does never send the right mouse click to Firefox, instead it shows the little icon with the 3 mouse buttons with the right being filled. This is correct, of course, because the left mouse button is still hold and then xvkbd "executes" the right mouse button, and so ctwm shows the icon that it always shows when two mouse buttons are hold at the same time while being over the background. Thus, the XUngrabPointer in the f.exec allows the command that is executed by f.exec to simulate mouse clicks even if f.exec was started by a mouse click. This makes sense with my xvkbd example. So the bug is somewhere else: Looking at xev, the first click of the mouse button bound to the f.exec shows the ButtonRelease event, as it should. But it seems the mouse is still not fully released from ctwms POV. Because the next click shows the icon with the three mouse buttons where one is highlighed. That means ctwm still considers this mouse button pressed. BUT: only if the same button is pressed again. I.e., binding 'f.exec "true"' to the left mouse button and pressing it once (works) will cause no problem with all consecutive middle or right clicks. But with the next left click, no matter how long it takes until is is performed. But if ctwm really thought that the left mouse button was still hold, it would show the mouse icon also for the next middle or right click So it's just like ctwm spawns a separate state for the left mouse button that is only used when the left mouse button is pressed again but not for any other action. Really strange! -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. BioinformatikMail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
