Touch Support

[Antikyth]

An interesting thing I saw mentioned was touch support in window managers - I think this is a good idea actually, and, whether an official touch module is written or not, writing AquariWM in a way such that input methods could be open to more diverse methods such as touch, in addition to mouse and keyboard support, could certainly have its benefits. This is something to keep in mind not just when designing input modules, but also layout modules - touch gestures that make sense must be able to communicate enough information to AquariWM so that all layout modes could be adjusted by touch gestures. I imagine this would primarily come in the form of implementing code that can 'interactively' swap windows with a pointer (touch or cursor), as well as being able to resize and move windows with a pointer to (both in floating and in tiling layouts).

This is an early idea in the project of course, and there isn't really anyone else here yet, but to anyone reading in the future - do you have any thoughts on this, if it is not already implemented?

[Antikyth]

This is definitely not a plan for what touch gestures would be, but an idea of what kind of things touch gestures might need to be able to do. The major part here for tiling layouts to be able to support is setting the split between some particular windows to an exact screen coordinate... this is a challenging problem, let's see if it is something that a good solution can be found for. It would need to be something that could work in all the popular tiling layouts, well, really in any tiling layout, for it to be added.

[Antikyth]

'select next workspace', 'move this window to next workspace', 'swap these two windows' are very simple actions - no change to the layout needs to be made, other than that a window is added or removed to the workspace. Resizing, however, would have to follow the pointer (touch or cursor), so there would have to be an API function along the lines of split.setScreenX(100) and split.setScreenY(100) (just for the purposes of giving an example). The biggest difficulty here is with nested layouts, but it definitely does seem possible... I'm having a hard time visualizing it in the context of more complex types of layouts though, e.g. a spiral/dwindle layout. How might that be implemented for those..?

[cplir-c]

If resizing a window in a container, do you add to or take from other windows in the container or to/from outside windows?

[Antikyth]

I'm imagining that you modify the windows in that container only, unless you're affecting the edge of the container, in which case you affect only the outer window(s) on both sides of that split. If you're resizing any split, you're resizing the windows directly against that split on either side?

I'm not sure: the design behind AquariWM has changed (still the same goal) over the past weeks, so I haven't necessarily thought about the layouts in that yet. Right now AquariWM is waiting for me (or any contributors) to get X.RS (an X Rust library) to a usable state so that it can be reimplemented in that. After that happens, work can begin on developing AquariWM, including with defining its modularity (well, the modularity of any compliant window managers and clients) with the WMMC spec.