~sircmpwn/wio

1

How close will wio stay to rio?

Leon Plickat
Details
Message ID
<20190614231200.o3go6giyzcxu75pg@tarazed>
Sender timestamp
1560553920
DKIM signature
missing
Download raw message
Hi,
I was wondering if wio is intended to completely imitate rio, or if
this project is allowed to move in a slightly different direction.

I have used wio now for a few days and noticed that it is nice if you
have a mouse, but not if you only have the touchpad of your laptop.
Here are a few things I would like to implement to make wio better
suited for laptop usage as well as a few generic improvements:

* All mouse buttons open the menu. Wio, unlike rio, only has a single
  menu. And I also doubt many people will use this with sam, acme or
  9term, so I do not think keeping continuity with these programs is
  important.

* The menu key opens the menu at the cursor position. Moving the
  cursor outside of larger windows is annoying with a touchpad or low
  mouse sensitivity.

* Keybinds. Sometimes pressing keys is nicer than pushing a touchpad
  down. I am thinking about keybinds for all events in the menu. Like
  `Super+n` to enable the "new" state or `Super+m` to enable the "move"
  state. Or maybe even go one step further so that pressing and
  holding down `Super+n` immediately starts the selection for the new
  terminal and releasing it stops the selection and spawns the terminal,
  so that no mouse button has to be pressed. `Super+m` would then
  immediately start moving the windows under the cursor. There are still
  some things I am not sure about, like what shall be done for "Resize",
  which requires multiple operations, or whether the keybinds for
  "Delete" should kill the window under the cursor or the one currently
  focused. A keybind to exit wio is also useful.

* `Esc` stops any active event / action.

* "Always above" and "Always below" options (in the menu). In the few
  time I have used wio, basically always when I spawned a small
  temporary terminal, I lost it behind a larger window. Currently the
  only option to bring it back is to move the larger window. Having
  the option to tell windows to always stay above or below would solve
  this problem rather elegantly, in my opinion. These windows could
  have a special border colour so they can be easily identified.

* Workspaces. Sometimes I (and I believe most other people as well) have
  to multitask. Having all windows on one singular workspace, even if
  "Hide" would work, is not really suited for that. I think this could
  be painlessly achieved by simply having an array of view lists instead
  of a single one. An integer in the server struct will be responsible
  for which is currently selected which can be changed via keybinds
  (like `Super+2` for the second workspace).

* A startup script. I would suggest a command flag to point to a file
  which will then be executed by wio. This would be nice for
  automatically starting a notification daemon, a bar or other things
  _after_ the compositor itself started.

If such patches would be accepted, I will implement them in a way, that
they can be disabled either at compile time or via a command flag, so
that people could have the pure rio experience, if desired.


friendly greetings,
Leon Plickat

-- 
leonhenrik.plickat@stud.uni-goettingen.de
PGP: 1A011200
Details
Message ID
<BUTU99BGZ8K5.TR8B5APA57F5@homura>
In-Reply-To
<20190614231200.o3go6giyzcxu75pg@tarazed> (view parent)
Sender timestamp
1560554093
DKIM signature
pass
Download raw message
On Sat Jun 15, 2019 at 1:12 AM Leon Plickat wrote:
> * All mouse buttons open the menu. Wio, unlike rio, only has a single
>   menu. And I also doubt many people will use this with sam, acme or
>   9term, so I do not think keeping continuity with these programs is
>   important.

Yes

> * The menu key opens the menu at the cursor position. Moving the
>   cursor outside of larger windows is annoying with a touchpad or low
>   mouse sensitivity.

No

> * Keybinds. Sometimes pressing keys is nicer than pushing a touchpad
>   down. I am thinking about keybinds for all events in the menu. Like
>   `Super+n` to enable the "new" state or `Super+m` to enable the "move"
>   state. Or maybe even go one step further so that pressing and
>   holding down `Super+n` immediately starts the selection for the new
>   terminal and releasing it stops the selection and spawns the terminal,
>   so that no mouse button has to be pressed. `Super+m` would then
>   immediately start moving the windows under the cursor. There are still
>   some things I am not sure about, like what shall be done for "Resize",
>   which requires multiple operations, or whether the keybinds for
>   "Delete" should kill the window under the cursor or the one currently
>   focused. A keybind to exit wio is also useful.

No

> * `Esc` stops any active event / action.

Yes

> * "Always above" and "Always below" options (in the menu). In the few
>   time I have used wio, basically always when I spawned a small
>   temporary terminal, I lost it behind a larger window. Currently the
>   only option to bring it back is to move the larger window. Having
>   the option to tell windows to always stay above or below would solve
>   this problem rather elegantly, in my opinion. These windows could
>   have a special border colour so they can be easily identified.

No

> * Workspaces. Sometimes I (and I believe most other people as well) have
>   to multitask. Having all windows on one singular workspace, even if
>   "Hide" would work, is not really suited for that. I think this could
>   be painlessly achieved by simply having an array of view lists instead
>   of a single one. An integer in the server struct will be responsible
>   for which is currently selected which can be changed via keybinds
>   (like `Super+2` for the second workspace).

No

> * A startup script. I would suggest a command flag to point to a file
>   which will then be executed by wio. This would be nice for
>   automatically starting a notification daemon, a bar or other things
>   _after_ the compositor itself started.

Yes