Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ta/monitor ordering #919

Merged
merged 7 commits into from
Dec 1, 2023
Merged

ta/monitor ordering #919

merged 7 commits into from
Dec 1, 2023

Conversation

ThomasAdam
Copy link
Member

  • WIP
  • WIP: Monitor ordering

@ThomasAdam ThomasAdam added this to the 1.0.9 milestone Oct 23, 2023
@ThomasAdam ThomasAdam self-assigned this Oct 23, 2023
@ThomasAdam ThomasAdam added the type:enhancement Augmenting an existing feature label Oct 24, 2023
@ThomasAdam ThomasAdam marked this pull request as ready for review October 24, 2023 22:00
@somiaj
Copy link
Collaborator

somiaj commented Oct 24, 2023

The order only seems to be set at the initialization stage, if I run xrandr --output DP-2 --left-of DP-4 to change my monitor order, the variables are not updated, and now 1 is my left monitor and 0 is my right monitor. But if I then restart fvwm3, the order is updated.

Now that I see what you are doing with this, I think my lexographic order approach would be worthwhile. If the monitors are all in the same line, you'll get the same result here, but there will also be a predictable order for other setups as well. (well I'm assuming in a line means the top coordinate is all the same, with different sized monitors lined up along the bottom, which I think is a very odd setup, it would be different).

@ThomasAdam
Copy link
Member Author

Hey @somiaj

Yeah -- there's definitely some rough edges which I've yet to deal with, such as recreating the ordering should the layout change while FVWM is running.

I completely agree about your lexicographical approach -- I'm just not too sure how best to implement it.

@somiaj
Copy link
Collaborator

somiaj commented Oct 25, 2023

@ThomasAdam point me to which part of the code assigns the order, I might be able to come up with something, should be just a simple sort, and since the number of monitors will always be small, a standard sort algorithm should do the trick.

@somiaj
Copy link
Collaborator

somiaj commented Oct 25, 2023

@ThomasAdam It seems like qsort in <stdlib.h> will do the job. Here is some pseudo code that I hope is enough for you to understand and maybe implement.

First you need a compare function, such as:

int mon_compare(const void *m1, const void *m2)
{
	const struct monitor *mon1 = m1;
	const struct monitor *mon2 = m2;

	if (mon1->si->y == mon2->si->y) {
		return mon2->si->x - mon1->si->x;
	} else {
		return mon2->si->y - mon1->si->y;
	}
}

Then just put all of the monitors into an array, mon_array, and call qsort:

qsort(mon_array, number_of_monitors, sizeof(monitor), mon_compare);

The array will be sorted, then just number the monitors based on their position in the array:

for (int i = 0; i < number_of_monitors; i++) {
	mon_array[i]->si->number = i;
}

My c knowledge is still very basic, and just following examples, so I'm sure this will need to be adjusted.

@ThomasAdam ThomasAdam force-pushed the ta/monitor-ordering branch 2 times, most recently from 429d4f5 to c26fdb0 Compare November 28, 2023 17:42
libs/FScreen.c Outdated Show resolved Hide resolved
@somiaj
Copy link
Collaborator

somiaj commented Nov 28, 2023

My quick tests (with only two monitors) seem to show it works. I even tested my optimization suggestion and I get the exact same result. It still doesn't update the ordering on monitor changes, I have to restart fvwm to get the ordering to update.

@ThomasAdam
Copy link
Member Author

It still doesn't update the ordering on monitor changes, I have to restart fvwm to get the ordering to update.

Really? I'm moving the ordering of screens around using xrandr, and they update just fine, without restarting fvwm.

What am I missing?

Copy link
Collaborator

@somiaj somiaj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems to work now!!

Sort the list of monitors which fvwm tracks in an ascending linear
progression, from left-to-right.  Currently, any monitors which are
above or below will not to be tracked in this way.

In doing so, it then becomes possible to use:

    $[monitor.0.name]

Which would yield the name of the first monitor on the left.

    $[montor.1.name]

Would be the monitor on the right of monitor 0, and so on.

This therefore makes position geometries easier, as in:

    Style moo StartsOnScreen $[monitor.2.name]

Regardless of whether the monitor ordering changes, or the same config
is used across different monitors.
Store the list of monitors in a Red-black tree, rather than a TAILQ
list.  This should allow for better insertion sorting of the monitors in
different configurations.
Tag each monitor with a number when inserting -- the idea being that
monitor 0 -> n represents the ordering for each monitor.
When a RandR event occurs, ensure the monitor(s) affected are removed
and reinserted into the tree so that their position changes also.
When looking up numbers from a string, use strtonum() (from BSD) rather
than atoi() so that we can distinguish between errors.
Update the fvwm documentation to mention how RandR screens are arranged
and detected.

While here, remove mention that RandR is optional, it is now a core
dependency.
When outputting JSON information, include the randr order number
assigned to the specific monitor.

This also bumps the version to 3.
@ThomasAdam ThomasAdam merged commit b725f2e into main Dec 1, 2023
5 checks passed
@ThomasAdam ThomasAdam deleted the ta/monitor-ordering branch December 1, 2023 14:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:enhancement Augmenting an existing feature
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

2 participants