Add --query

[momoson]

Fixes issue #4.

[emersion]

Thanks for the patch! Is there a reason why this has been moved after the loop?

[emersion]

Style: we use tabs

[momoson]

Thank you for the review and sorry for the style messup.

Reason for putting print_state after the polling loop:

1. Query should show state after changing the state.
2. print_state sets state.running=False hence short circuiting the loop, make the app exit before the state is even changed.

Further, the loop is now encapsulated into the apply_state branch. Otherwise the code loops infinitely, due to state.running always true.

[emersion]

Query should show state after changing the state

Does xrandr have this behaviour?

print_state sets state.running=False hence short circuiting the loop, make the app exit before the state is even changed.

It's possible to just reset state.running = true to re-start the loop.

Further, the loop is now encapsulated into the apply_state branch

I believe this breaks invoking wlr-randr without making any changes. The loop needs to run for wlr-randr to retrieve the current output data.

[momoson]

Thank you again for your review.

Query should show state after changing the state

Does xrandr have this behaviour?

According to its manual it shows the current state of the system. A quick skim over its code base seems to show that the state after change is printed. It also shows that the code, if changes are successfully applied, exits before showing the current state. In my eyes this contradicts with the statement from the manual

When this option is present, or when no configuration changes are requested, xrandr will display the current state of the system.

as it is not mentioned that the option will be ignored whenever a configuration change is done.

Eventually this means that we can either (1) stick to the way xrandr is doing it, thus ignoring the --query option when we apply any changes or always consider and print either the state before (2) or after the change (3).

Personally I do not like option (1) as calling wlr-randr with or without --query would not make a difference. Option (2) needs more changes inside the code, as the changes either need to be buffered or the arguments need to be read twice. You can see the necessary code changes here. Hence I think it is best to go with option (3), showing the user the result of his changes.

print_state sets state.running=False hence short circuiting the loop, make the app exit before the state is even changed.

It's possible to just reset state.running = true to re-start the loop.

Further, the loop is now encapsulated into the apply_state branch

I believe this breaks invoking wlr-randr without making any changes. The loop needs to run for wlr-randr to retrieve the current output data.

Running the code with gdb has shown me that the current state is retrieved upon the call to wl_display_roundtrip. Otherwise the current master version would also not work, as print_state prints immediately and does not schedule printing after the state is retrieved.

[emersion]

Hence I think it is best to go with option (3), showing the user the result of his changes.

Yeah, agreed.

[emersion]

So the current patch does option (2) right? We'd probably need to move the print_state call after applying changes and after a new roudntrip?