Skip to content

Use the move bar to freely position windows #1670

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

Merged
merged 4 commits into from
Jan 24, 2025
Merged

Use the move bar to freely position windows #1670

merged 4 commits into from
Jan 24, 2025

Conversation

svillar
Copy link
Member

@svillar svillar commented Jan 7, 2025

Users should be able to move the windows around (although the 3 windows will still be grouped together) by clicking and dragging in the recently added move bar bellow the window.

Window distance to the user would require additional changes and it is not included in this PR

Fixes #99, fixes #927

@svillar
Copy link
Member Author

svillar commented Jan 7, 2025

Demo of the new behaviour

movingwindows28.mp4

Compare it to what was happening previously

ScreenRecording_2024.12.02-12.17.59.mp4

@felipeerias
Copy link
Collaborator

@svillar This is a great improvement!

It is a pity that the window moves downward when clicking the first time. Maybe we need to apply a transform taking into account the hit point where the click has happened in the window widget. I've had a look at the code and I think that we can gather all the information that we need, but it seems a bit complex to implement.

It would be awesome to implement the grab button as well, but we can leave that for another PR.

@svillar
Copy link
Member Author

svillar commented Jan 8, 2025

@svillar This is a great improvement!

It is a pity that the window moves downward when clicking the first time. Maybe we need to apply a transform taking into account the hit point where the click has happened in the window widget. I've had a look at the code and I think that we can gather all the information that we need, but it seems a bit complex to implement.

Yeah, I agree is the main drawback. Should we land this as is, or do you prefer to fix this issue first.

It would be awesome to implement the grab button as well, but we can leave that for another PR.

Yeah, I think we can treat it as an enhancement

@svillar svillar added the release_candidate PR that should be part of the next release label Jan 14, 2025
@javifernandez
Copy link
Member

Yeah, I agree is the main drawback. Should we land this as is, or do you prefer to fix this issue first.

It's quite annoying, tbh. I have mixed feelings, because the feature is nice and something users have been requested since long ago. How difficult would it be to fix ?

Copy link
Collaborator

@felipeerias felipeerias left a comment

Choose a reason for hiding this comment

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

LGTM. The feature works well enough, I think. We can leave the improvements (window "jump", etc.) for future PRs.

@svillar
Copy link
Member Author

svillar commented Jan 15, 2025

Yeah, I agree is the main drawback. Should we land this as is, or do you prefer to fix this issue first.

It's quite annoying, tbh. I have mixed feelings, because the feature is nice and something users have been requested since long ago. How difficult would it be to fix ?

Not trivial at least. I can give it a try though

@javifernandez
Copy link
Member

BTW, this change causes a regression in the headklock functionality. It's not possible to lock the window based on the headset orientation.

@svillar
Copy link
Member Author

svillar commented Jan 15, 2025

BTW, this change causes a regression in the headklock functionality. It's not possible to lock the window based on the headset orientation.

It works fine here. See the video:

headlock.mp4

Copy link
Member

@javifernandez javifernandez left a comment

Choose a reason for hiding this comment

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

The fix for the headlock regression worked, thanks.

I have some comments about the code, see below inline.

Copy link
Member

@javifernandez javifernandez left a comment

Choose a reason for hiding this comment

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

The code looks good now.

In terms of functionality, this new version works much better now. Awesome ! The z-axis movement is fluid and clear now, and it's more stable as it's not affected by unconscious movements on the other axes.

On the bad news, I've found out a bug, which I don't think it's a regression but something this PR has not considered. When enabling the headlock, it's still possible to touch the "free movement" bar and start moving the window. The headlock is stopped, but the radio-button in the settings dialog is still enabled.

@svillar
Copy link
Member Author

svillar commented Jan 16, 2025

The code looks good now.

In terms of functionality, this new version works much better now. Awesome ! The z-axis movement is fluid and clear now, and it's more stable as it's not affected by unconscious movements on the other axes.

On the bad news, I've found out a bug, which I don't think it's a regression but something this PR has not considered. When enabling the headlock, it's still possible to touch the "free movement" bar and start moving the window. The headlock is stopped, but the radio-button in the settings dialog is still enabled.

Good catch. Fixed now

Copy link
Member

@javifernandez javifernandez left a comment

Choose a reason for hiding this comment

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

It's perfect now. Thanks !

@svillar svillar force-pushed the moving_windows branch 3 times, most recently from cc3b4cf to 67a8d45 Compare January 17, 2025 12:32
@javifernandez javifernandez self-requested a review January 17, 2025 12:56
Copy link
Member

@javifernandez javifernandez left a comment

Choose a reason for hiding this comment

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

I tested the change to avoid the big initial repositioning and it's now better. It places the window slightly upper the current position, which is better than downwards. Ideally, I'd try to reduce the distance, though.

Anyway, since this is a temporary solution, I think we can live until we solved it properly.

@svillar
Copy link
Member Author

svillar commented Jan 22, 2025

I tested the change to avoid the big initial repositioning and it's not better. It places the window slightly upper the current position, which is better than downwards. Ideally, I'd try to reduce the distance, though.

"it's not better" or "it's now better" ? I guess the latter :)

@javifernandez
Copy link
Member

I tested the change to avoid the big initial repositioning and it's not better. It places the window slightly upper the current position, which is better than downwards. Ideally, I'd try to reduce the distance, though.

"it's not better" or "it's now better" ? I guess the latter :)

The latter. indeed :)

@felipeerias
Copy link
Collaborator

The repositioning fix doesn't work great on Pico because the window is also moved to the side. Is this expected?

ScreenRecording_2025.01.23-12.33.25.mp4

Copy link
Collaborator

@felipeerias felipeerias left a comment

Choose a reason for hiding this comment

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

I have collected the proposed changes here, so they are easier to test:

8b9eb83

There's an additional bug: if you open the window distance popup and unplug the glasses, the popup remains visible while the rest of the UI changes.

@svillar
Copy link
Member Author

svillar commented Jan 23, 2025

The repositioning fix doesn't work great on Pico because the window is also moved to the side. Is this expected?
ScreenRecording_2025.01.23-12.33.25.mp4

Not really

Copy link
Collaborator

@felipeerias felipeerias left a comment

Choose a reason for hiding this comment

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

LGTM. Perhaps we can integrate this PR and deal with the repositioning of the window in a separate one?

@felipeerias
Copy link
Collaborator

The repositioning issue is unfortunate because it leads to strange behaviours, specially with more than one window.

ScreenRecording_2025.01.24-12.00.19.mp4

However, it is hard to fix because we basically need to add a new transform that will compensate for the position of the click within the whole window system.

@svillar What do you think about integrating this PR and moving that work to a future one?

@svillar
Copy link
Member Author

svillar commented Jan 24, 2025

The repositioning issue is unfortunate because it leads to strange behaviours, specially with more than one window.

Ah, that's because we're reorienting and that is done based on the central window. What I would do is to only show the move bar for the front window.

Users should be able to move the windows around (although the 3 windows will still be
grouped together) by clicking and dragging in the recently added move bar bellow
the browser front window.

This required a small refactoring in head lock mode. From now on, instead of having
a head lock on/off switch, we have a head lock mode, which can take three different
values: no lock (normal mode), head lock and controller lock (the one used to move
windows).

Currently when moving windows, they closely follow the orientation of
the controller. That means that they are prone to the natural small
shaking of human hands. To alleviate that, we can add some linear
interpolation between consecutive orientations. By using a value close
to 0 (in this case 0.1) we ensure that the interpolated value is very
close to the previous value, and thus, the movement is very smooth.

Fixes #99, fixes #927
Users can now modify the distante to the browser window when dragging
the moving bar widget by moving the controller/hand closer or further
away.

As this can be done with a gesture now there is no need to have a
dedicated widget in the settings for that.
When moving windows with the new bar widget the windows initally move down
as soon as the user grabs the bar. That's because the reorientation operates
over the front window and not over the new bar widget.

In order to make it slightly better we're compensating part of that initial
rotation. But this is an ugly hack for the 1.8 release that should be
removed as soon as possible.
The top bar of the phone UI has now a new button that when clicked
displays a seekbar that can be used to change the window distance.
@svillar svillar merged commit dc3da54 into main Jan 24, 2025
22 checks passed
@svillar svillar deleted the moving_windows branch January 24, 2025 12:27
@felipeerias felipeerias removed the release_candidate PR that should be part of the next release label Apr 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Drag and rotate windows using the controller Click and Drag windows
3 participants