> 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
>> 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
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
> 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
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
>> 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
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
