Add app/window/screen events

[thesoftwarephilosopher]

App events:

• [ ] AppLaunched
• [ ] AppTerminated
• [ ] AppHidden
• [ ] AppShown

Window events:

• [ ] WindowCreated
• [ ] WindowClosed
• [ ] WindowMoved
• [ ] WindowResized
• [ ] WindowMinimized
• [ ] WindowUnminimized
• [ ] WindowFocused

Screen events:

• [ ] ScreenLayoutChanged (i.e. screen may have been added/removed)

[thesoftwarephilosopher]

Regarding app lifetimes, it may be easier to use kEventAppLaunched and kEventAppTerminated than the way Zephyros does this.

[thesoftwarephilosopher]

Changing the milestone for this issue, there's no good reason to have it in 1.0 just yet.

[creese]

With just WindowCreated and WindowClosed, we should be able to create a nice one-workspace clone of http://xmonad.org.

[flaub]

+1

[thesoftwarephilosopher]

The difficulty here is in order to observe window-related events we must first register a permanent observer (AXObserverCreate) for the app (pid_t) whose windows these may be; there's no way to register for a such an event independent of the application it may originate from. This involves a lot of ugly bookkeeping that I'd like to avoid putting into the core of the app if at all possible. But the only alternative solution seems to be asking the user to keep track of all current and future apps and maintain observers for them throughout their lifetimes, which also isn't reasonable.

[thesoftwarephilosopher]

If anyone has an alternative API to point me to, or any other ideas, your input will be greatly appreciated.

[thesoftwarephilosopher]

Solved.

[mengelbrecht]

Is there already an API to use to get notified of launched Applications?

[thesoftwarephilosopher]

@mgee It's coming soon.

[mengelbrecht]

Nice! Looking forward to it :-).

[thesoftwarephilosopher]

This feature depends on #254.

[thesoftwarephilosopher]

I've got a better idea of how to implement this now.

[thesoftwarephilosopher]

Working on this now.

[thesoftwarephilosopher]

Thinking of making this a generic module like listener to reduce code duplication. Then all the events would be listed in tables in their relevant module, like listener.new(application.event.launched, function()...end):start()

[thesoftwarephilosopher]

I need to do this on a night when I have a fresh mind and no distractions. Tonight I had neither. :/

[iakshay]

Would be great, if we can get these events – https://github.com/jigish/slate/wiki/Events

How about some thing like Event.on(application.event.launched, function() end)

Maybe battery.watcher could also be integrated into this module.

[muescha]

add key pressed/key released events

benefit:

• to debug - see #290
• to make keystroke visialisation like in MousePose

[thesoftwarephilosopher]

@muescha That was done in eventtap which is coming in 1.1

[muescha]

i would prefer the @iakshay syntax Event.on over an eventtap naming.

[thesoftwarephilosopher]

@muescha For input events, the eventtap module is pretty much set in stone at this point. This issue is for other events, which need more thought.

[muescha]

but then it looks more consistent if it have always the same syntax and fits your idea for making a generic module for listener (or Event)

[thesoftwarephilosopher]

Moving to mjolnir-io/ext#14.

[nathankot]

this would be the final piece of the puzzle for https://github.com/nathankot/mjolnir.tiling :smile: although can't seem to find mjolnir-io/ext ??

[tmandry]

+1, @sdegutis can you link to the issue?

[iakshay]

+1 for events

[szymonkaliski]

Yeah, I'd love that too, shouldn't we reopen this?

[maxrothman]

@sdegutis :+1: as well, also can't find mjolnir-io/ext.

[thesoftwarephilosopher]

I'm currently working on events.

[nathankot]

@sdegutis thanks for the update :smile:

[svalaskevicius]

awesome! looking forward for event driven tiling WM on osx :) (in fact, the only thing keeping me from using osx is not having xmonad there)

[nathankot]

@svalaskevicius I hope we convert you eventually :stuck_out_tongue:

[svalaskevicius]

@nathankot thanks :) just to check - is the current implementation of tiling plugin working already or is it blocked by this issue.. and is there maybe a screencast of it in action? I've tried looking for it but couldn't find any. (should I have asked this elsewhere?)

[nathankot]

@svalaskevicius yep it works, but doesn't respond to new windows being added (so you'll have to re-tile manually), the tiling project is young so don't think there are videos out in the wild but could do one of my workflow if you want?

[svalaskevicius]

it would be definitely interesting to see! - it's usually one of the first things I look for when I hear of a new tiling WM :)

[creese]

@nathankot The last time I checked, the tiling project did not work for multiple monitors. Has that issue been addressed?

[nathankot]

@creese don't use multiple screens myself but this may have fixed it: https://github.com/nathankot/mjolnir.tiling/issues/9 , if not , please make a new issue at mjolnir.tiling ;)

[simichaels]

Any progress on event handling so far?

[thesoftwarephilosopher]

They're basically finished in the Swift window manager I was writing. Main problem is there's no UI in that one yet.

[szymonkaliski]

Hmmm, but is everything else working? I for one don't need a UI to use it... Is it mjolnir compatible? I'd love to use some modules we already have...

[thesoftwarephilosopher]

@szymonkaliski It's all working, but I haven't finished porting all the functions (it's so tedious). It's probably already Mjolnir-compatible, but if not, it could easily be made to be so. I have two versions: one that uses Lua very similarly to Hammerspoon (a Mjolnir fork), and one that's meant to be one you write in pure Swift (in Xcode), and compile into an app that you can run. Since the work was split in two repos, each repo might have an API function or two that the other doesn't, so I'm not entirely which has what. Anyway, I plan to spend an hour or so today cleaning that up and making both repos presentable, and writing down the current status of each in their own READMEs. There'll likely still be some work needed to port some API functions over from Mjolnir, and if that's the case, I'd love some help.

[thesoftwarephilosopher]

Oh right, I remember what I planned for the Swift-only version: it would be a framework that you could just import, and you'd just make a new Swift app that embeds and links to this framework, and uses it in applicationDidFinishLaunching. That way, everyone could re-contribute to the framework itself, while keeping their "config" (i.e. the program putting the framework to good use) separate.

[thesoftwarephilosopher]

@szymonkaliski turned it into a framework at https://github.com/sdegutis/WindowManager fwiw

[cmsj]

FWIW, I expect that the Hammerspoon modules for app/window/screen events would port over pretty easily. The code is at:

app events: https://github.com/Hammerspoon/hammerspoon/blob/master/extensions/application/watcher.m window events: https://github.com/Hammerspoon/hammerspoon/tree/master/extensions/uielement screen events: https://github.com/Hammerspoon/hammerspoon/blob/master/extensions/screen/watcher.m

(some of this stuff was inherited from Mjolnir's various modules anyway, so it may not all need to be ported over :)

[szymonkaliski]

@sdegutis https://github.com/sdegutis/WindowManager looks very cool, I hope I'll have some time to play with it soon!