Fix detection of screen layout changes #44
Conversation
|
Is it good to use OperationQueue.main? Wouldn't it be better to keep the queue nil so we don't force processing on the main thread? |
As of now, all Swindler events are dispatched on the main thread, and since this ultimately leads to an event I put it on the main queue. Otherwise, this assertion would have ended up failing. Perhaps it would be better to allow the user to customize where event handlers are run. My thinking has generally been that the biggest slowdowns are likely going to be from the AX API calls, which halt the current thread until the requested application responds. Those are all handled on the background queue. Other processing I expect to be fast and not a real blocker, but I'd love to know what you think about this. As for the processing going on within Swindler itself, I don't think it would be a bottleneck. It should probably happen on the same thread as the event is going out on to reduce unnecessary overhead. The only possible slowdown I can see is accessing |
|
Actually, I just remembered that there is a lot more going on than |
|
I should probably read the whole code before commenting, but in my opinion we shouldn't tie the event system to the main thread if possible; actually giving the ability to set the preferred queue would be cool. There were some missing notifications when we didn't use the main thread in chunkwm, but I figured those were issues with the interoperability between the C api using event loops and c++ threads not playing well together.... |
|
That's true, there will likely be a lot of internal processing to do for Spaces. Dispatching external event handlers on one thread seemed much easier to deal with for user code, but if folks want to customize this then that's fine with me. I opened #46. Do you need concurrency or you just want to get it off the main thread specifically? Out of curiosity, with a "headless" app like chunkwm, do you know of any specific problems encountered when processing on the main thread? |
Mainly I just want to keeps as much stuff as possible of the main thread.
It's been quite a while since I read that codebase, but if I remember correctly, only the notification listening code is on the main thread. Event handlers just push the events on a queue where there are some worker threads processing these for the different registered plugins. The main pain points arise when dealing with any user interaction. For example the border plugin, which must execute on the main thread, uses higher level Cocoa API, which don't play well when mixing threads, and the mutexes in the main thread event handling code. So you just end up dispatching everything async to the main thread to avoid any deadlocks. There are also some concurrency issues, which are hard to pinpoint leading to some glitchy behaviour probably because of some race conditions. Ideally, I'd like to recreate the functionality of chunkwm (which imo doesn't have decent alternatives), tiling, rule system, follow focus mouse and border, but with a more user friendly UI. |
|
@choco Are you working on such a project now? I'm working on x3 which currently is a clone of i3 but I have a lot of the same goals as you. |
|
@tmandry Nope, haven't started working on it yet. I'm not really familiar with i3, and in general with other tiling window manager. kwm and chunkwm were actually my first so I'm not sure what's the state of the art on linux, how much those differ and how many features are actually achievable on macOS with the constrained accessibility APIs. All I have are some things I would like to be able to do, how I'd want some interactions to behave, but I don't know if they are the best solution for the problem. It would be nice to brainstorm some ideas and have a better understanding of what's good |
Fixes #42.