Nothing Special   »   [go: up one dir, main page]

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

xdg: update initial maximize logic for wlroots 0.18 #2007

Merged
merged 2 commits into from
Jul 20, 2024

Conversation

jlindgren90
Copy link
Contributor

The initial configure event is now sent explicitly by labwc rather than by wlroots. We need to move the maximize/fullscreen logic to the initial commit handling accordingly.

Updates #1956, fixes #1994, replaces #1995.

The initial configure event is now sent explicitly by labwc rather
than by wlroots. We need to move the maximize/fullscreen logic to
the initial commit handling accordingly.

Updates labwc#1956, fixes labwc#1994, replaces labwc#1995.
@jlindgren90
Copy link
Contributor Author

Maybe the view_wants_decorations() check should be moved too.

@Consolatis
Copy link
Member
Consolatis commented Jul 19, 2024

This prevents setting the output before map, intended?
From memory that is required for scale notifications to work before map but I am not sure right now. @ahesford might be able to confirm.

Edit:
It was actually introduced via ed19bc4

The desired SSD mode is not known at this point. When it is known,
kde-deco/xdg-deco will call view_set_ssd_mode() themselves.
@jlindgren90
Copy link
Contributor Author

This prevents setting the output before map, intended?

There is still this code in xdg_toplevel_new():

/*
 * Pick an output for the surface as soon as its created, so that the
 * client can be notified about any fractional scale before it is given
 * the chance to configure itself (and possibly pick its dimensions).
 */
view_set_output(view, output_nearest_to_cursor(server));
if (view->output) {
	wlr_fractional_scale_v1_notify_scale(xdg_surface->surface,
		view->output->wlr_output->scale);
}

Does that address the concern?

@ahesford
Copy link
Member

I think the assignment of an output in xdg_toplevel_new, which was added to make sure foot sets its initial size based on a correct output scale, is probably sufficient even in cases when a view is initially maximized.

@Consolatis
Copy link
Member

In that case I think we can remove the view_set_output() calls in the fullscreen and maximized handlers as output will always be set via xdg_toplevel_new().

@jlindgren90
Copy link
Contributor Author

I agree this later assignments of view->output are probably a bit paranoid. I think it's a bit out of scope for this PR to remove them so I think I'll leave them as-is for now.

@Consolatis
Copy link
Member

Alright, PR LGTM, not tested. Feel free to merge if you are satisfied with it.

@jlindgren90 jlindgren90 merged commit a75301d into labwc:master Jul 20, 2024
4 of 5 checks passed
@jlindgren90 jlindgren90 deleted the xdg-initial-maximize-redo branch July 20, 2024 14:57
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.

chromium won't open fully maximized on launch
3 participants