search

wmutils / contrib

Useful bits and pieces
Other
93 stars 16 forks source link

Multiple monitors #42

Open pockata opened 8 years ago

pockata commented 8 years ago

Hello,

I know this topic has been discussed before and I know that the maintainers are not particularly interested in merging multi-monitor code, however multi-monitors are pretty common nowadays.

I myself use a laptop on a daily basis while traveling to work, at work the laptop is docked and uses two external monitors, and ad home attached to an eGPU setup for even more attached monitors. And all this is done while using wmutils.

I've created a set of utilities called mmutils (yes, zero imagination there) which provide a really similar way of interacting with monitor information to the way wmutils does with windows.

A lot of the code is borrowed from wmutils and lemonbar, but my C knowledge and experience are minimal and my additions might have impacted the overall quality.
Even though I've been using it for a month or two without any problems, I'd like other people to take a look and share some ideas on how I might improve it further.

I wouldn't imagine you ever merging this code in the repository, but if you like the code and how the utilities operate, you can add a link to the repository in the readme as a sort of recommended 3rd party helper utility so people who are interested in multi-monitor setups can benefit. That's my end goal.

Let me know what you think.

z3bra commented 8 years ago

From the readme, the usage seems good. I would perhaps use lsm -a to list (a)ll monitors and lsm only for currently used monitors. Just another idea as wmutils uses the -a switch to list all existing windows, no matter their state. So it would make lsw and lsm have the same semantics.

I like the way mattr works, by checking the window part visible on each monitor, it's a good thing you though about it.

One might need the ability to get the monitor id where the cursor is, something like pfm for "print focused monitor".

It would be great to have it integrated with wmutils, either in its own repo, or in core. To do so an update will be needed in util.c. The style of your mmutils will also need to match wmutils', but we can work togetther on this.

Thanks for putting hard work on this!

pockata commented 8 years ago

Awesome!

I would perhaps use lsm -a to list (a)ll monitors and lsm only for currently used monitors. Just another idea as wmutils uses the -a switch to list all existing windows, no matter their state. So it would make lsw and lsm have the same semantics.

I wrote lsm after mattr, so I picked the -c semantic from there, but it makes a lot more sense to use the same flag as lsw.

One might need the ability to get the monitor id where the cursor is, something like pfm for "print focused monitor".

Sounds nice. I'll implement it soon.

It would be great to have it integrated with wmutils, either in its own repo, or in core. To do so an update will be needed in util.c.

Let me know how you'd like to proceed from here. I can fork the core repo and merge in mmutils while also rewriting my code to reuse as much functionality as possible from core's util.c.

The style of your mmutils will also need to match wmutils', but we can work togetther on this.

I took a quick look at wmutils' code style and I see that you use tabs and open the function body with a curly brace on a new line. Anything else I should keep in mind?

Thanks for putting hard work on this!

Just returning the favor :smiley:

z3bra commented 8 years ago

It would be great to have it integrated with wmutils, either in its own repo, or in core. To do so an update will be needed in util.c.

Let me know how you'd like to proceed from here. I can fork the core repo and merge in mmutils while also rewriting my code to reuse as much functionality as possible from core's util.c.

Just keep the mmutils repo for now. When it's ready, we'll check what need to be done to have it integrated with core.

The style of your mmutils will also need to match wmutils', but we can work togetther on this.

I took a quick look at wmutils' code style and I see that you use tabs and open the function body with a curly brace on a new line. Anything else I should keep in mind?

openning brace on its own line for functions, tabs for indentation, spaces for aligmnement, line up 'switch' and 'case' statements, no braces for statements having a single line of code (unless it's an if/else). For main declaration, all programs use char **argv. I'm fine with char *argv[], but let's keep things consistent.

pockata commented 8 years ago

Just a small update.

I've created the pfm utility and changed lsm's -c flag to -a. I'll start working on the code style soon.

pockata commented 7 years ago

Hey @z3bra, I now have some time to get back to this. Are you still interested in this idea?

I've made some initial refactoring in this branch. My plan forward is to grab wmutils' util.c and reuse as much as possible.

Let me know what you think.

lwilletts commented 5 years ago

Massively interested in mmutils, already rewriting my old scripts for my setup and mattr is a godsend. What needs to be done to bring them up to spec and become part of the official wmutils family?

z3bra commented 4 years ago

Updating here as I recently worked on multi-monitors with XCB:

This Randr support was recently added to libwm. See these commits:

Note that this was quickly added in the hope that the code would remain short and uncluttered. It was also only tested by me, for my specific needs, so expect bugs.

It works though :)

Maybe someone can find the time to export these functions as separate tools for wmutils. Note sure whether they should be in core/ or opt/. Probably opt/, as multi-monitor setups are not the norm at all. They might be common enough to deserve introduction into core/ though…