wio: windowed i/o
16 points by hawski
16 points by hawski
Not having much context for what this is supposed to accomplish, but having written similar code in D, I look at these to see if they repeated any of the mistakes I made.... a few things I saw here:
well just a quick glance, i actually wrote a couple more then saw they were addressed elsewhere in the code and deleted them, so possible i just missed things here too.
overall though.... most things I looked for were ok. It would still be a LOT of work to do something like make a gui toolkit on this, but for something like a game with a few gui integrations, not bad at all. Even supporting some drag and drop is a nice touch.
Thanks for the comments!
the X clipboard copy operation only touches CLIPBOARD. I've come to appreciate setting PRIMARY along with any explicit copy operation.
I'm not sure, it makes sense for text boxes but I don't know if other copies are expected to set PRIMARY.
the paste api is synchronous. [...] I prefer to retain the async nature of the underlying protocol.
This would be a good change, and also allow implementing getClipboardText for wasm.
the Win32 impl never enters an alterable wait state
I'm not familiar with this part of Win32, but my initial understanding is that the user should call MsgWaitForMultipleObjectsEx manually. wio.wait deliberately ignores wakeups that do not produce a wio event.
we can call and define obj-c compatible classes right in the D language :)
There's people working on it!
I'm not sure, it makes sense for text boxes but I don't know if other copies are expected to set PRIMARY.
The formal spec doesn't say you have to, but I like it a lot, I came onto it from a blog.... which I can't find rn, ugh. I'll reply again if I can find the link.
But the argument is surely relatable: it is kinda frustrating when you can copy and then ctrl+v something in one program, but middle click refuses to update, and the program you using (e.g. a terminal emulator) makes middle click WAY easier than clipboard paste. This doesn't happen often, because normally you select first then ctrl+c copy, so it naturally matches, but when programs shortcut it doesn't all the time. But why not? It is a useful expectation.
For non-text things... I could go either way, I don't think it is as important there for practical usability, but there is some elegance to being consistent. Besides, note you can have fallback types on the clipboard, e.g. copying an image might copy both the pixmap as image/png and a URL or the alt text or something as text/plain. When a program pastes, it picks the format that works best for it. Arguably, they should all follow the same protocol.
I've been toying with the idea of making my library just set a selection object, then copy() takes no arguments and only links the selection to the clipboard. But I didn't go that far lol.
Still, PRIMARY mirroring CLIPBOARD for text is definitely useful.
wasm
yes, indeed, what a bizarre platform that is lol.
MsgWaitForMultipleObjectsEx
Yeah, that's the function I build my main event loop out of, so it can try to support everything centrally, but it is fair to say your users, if they chose to opt into APCs, should handle it themselves, but it is difficult to do it well together, and before I got mine set up like this, there were operations that would not fire until something like a mouse motion event because that'd wake up the lib event loop and other things would be blocked even though they were ready.
There's people working on it!
Nice, not surprised! I know a few compiler/tool devs who jumped ship to Zig from D, which is a pity cuz they were doing some really cool things, but alas, open source projects have politics too, and I'll leave it there, but I still keep an eye on Zig. I recently added support to my D thing to shell out to zig cc for glibc compat and cross compilation and I was really impressed with how well it worked. We'll see if Zig laps us on Objective-C some day too, won't be surprised if they do.
I will say though, just personally for me, seeing the same function call syntax and vocabulary helped me get a grasp on the apis a bit easier. Obj-C itself isn't bad syntax, once you understand it and get used to it, it is fine, but it is different enough than the C++/Java lineage it still trips me up a lil.
it is kinda frustrating when you can copy and then ctrl+v something in one program, but middle click refuses to update, and the program you using (e.g. a terminal emulator) makes middle click WAY easier than clipboard paste.
That makes sense, thanks for the suggestion.
I've been toying with the idea of making my library just set a selection object, then copy() takes no arguments and only links the selection to the clipboard.
This is probably ideal for X11, but I wouldn't want to make that part of the API (although I don't use the primary selection often).
before I got mine set up like this, there were operations that would not fire until something like a mouse motion event
The API is like this because internal events have to be ignored on Wayland, otherwise something like
while (true) {
wio.wait();
tick();
draw();
}
will keep waking up for the OpenGL/Vulkan frame ready, which is a problem for e.g. immediate mode UI.
For the APC use case I would hope something like
MsgWaitForMultipleObjectsEx(...);
// (handle result?)
wio.update();
would suffice, and assuming APCs imply the user has Win32 code anyway it feels reasonable.
Yea, it'd prolly work. btw one little thing to praise, yay for using XInternAtoms instead of XInternAtom in a loop. little thing but i think the latter is responsible for more hate on xlib than it deserves cuz people blame it for slow startups lol