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

Applications that start in fullscreen aren't in the right location #193

Closed
ARDiDo opened this issue Jan 3, 2022 · 28 comments
Closed

Applications that start in fullscreen aren't in the right location #193

ARDiDo opened this issue Jan 3, 2022 · 28 comments
Labels
bug

Comments

@ARDiDo
Copy link
Contributor

@ARDiDo ARDiDo commented Jan 3, 2022

The application appears to be scaled correctly, but there's, maybe, a distance of 100 pixels between the top of the window and the top of the screen.
I've only been able to reproduce this after a837fef, but I can't confirm that that commit contained the breaking change.

Something of note is that screenEdgeStrength activated when encountering that clearance area.

@johanmalm
Copy link
Collaborator

@johanmalm johanmalm commented Jan 4, 2022

@johanmalm johanmalm added the bug label Jan 4, 2022
@ARDiDo
Copy link
Contributor Author

@ARDiDo ARDiDo commented Jan 5, 2022

There might be a connection. But sadly, just commenting out those lines didn't help : )
I'll try to look into this a bit more.

@johanmalm
Copy link
Collaborator

@johanmalm johanmalm commented Jan 5, 2022

Sorry, I meant to do the same for full-screen. I.e. don’t let the application start in full screen.

The alternative is to set the view padding/margin (for csd/ssd respectively) on first unmax/unfullscreen state… which seems messy.

@ARDiDo
Copy link
Contributor Author

@ARDiDo ARDiDo commented Jan 5, 2022

Yeah, I get that.
I might try to tackle that problem in the future, if I ever think of something that is a little bit less messy, but I'll just force the view to be unfullscreened for now.
EDIT: dc203a2 fixes this. Closing for now.

@ARDiDo ARDiDo closed this as completed Jan 5, 2022
@Consolatis
Copy link
Contributor

@Consolatis Consolatis commented Jan 5, 2022

Maybe this bug should be kept open and extended to starting in maximized state.
Currently (with dc203a2 applied) starting in either maximized or fullscreen state (foot --maximized || foot --fullscreen) places the window somewhere around -20 -20.

@johanmalm johanmalm reopened this Jan 6, 2022
@johanmalm
Copy link
Collaborator

@johanmalm johanmalm commented Jan 6, 2022

I've tried with mpv -fs ... and also get an odd placement.
Agree, let's keep this open as a reminder to fix this.

@ARDiDo
Copy link
Contributor Author

@ARDiDo ARDiDo commented Jan 21, 2022

8e9643a fixes this with mpv, and SDL with the Wayland backend.

I have a working fix for xwayland as well, but I want to do a little bit more testing on it first.

@johanmalm
Copy link
Collaborator

@johanmalm johanmalm commented Jan 21, 2022

Does it work for both server and client side decoration?

@johanmalm
Copy link
Collaborator

@johanmalm johanmalm commented Jan 21, 2022

And if an xdg application is started in maximized mode, is the right padding/margin set when unmaximized?

@ARDiDo
Copy link
Contributor Author

@ARDiDo ARDiDo commented Jan 21, 2022

For your first question, I can't think of any xdg clients that use client side decorations off the top of my head, so I am unable to answer that.

As for your second question, when an application starts maximized, it's title text and the client's surface moved to the right of the screen, while all other server side decorations stay where they are. After moving my cursor, the client's surface moved back into maximized position. The client appears to be fixed after moving it, but I haven't done any thorough testing to see if that is entirely the case.

Unfortunately, I also experience this same strange behavior when unmaximizing views that don't start maximized. I tried reverting 8e9643a, and that didn't help. I've experienced this in nested sessions, and running from the tty, with both foot and Firefox. There is no problem coming out of fullscreen.

Thank you checking these things. Checking these cases hadn't crossed my mind.

@johanmalm
Copy link
Collaborator

@johanmalm johanmalm commented Jan 21, 2022

I find mousepad good for testing. mousepad is gtk3 and refuses to give up its CSD, so is always good for ensuring that CSD mode works with new features.

Alternatively, set decoration to client in rc.xml

<decoration>server</decoration>

@Consolatis
Copy link
Contributor

@Consolatis Consolatis commented Jan 21, 2022

Had a quick test with SSD (and two panels on top and bottom) with foot --maximized + foot --fullscreen and both seems to work without issues. Including unmaximizing / unfullscreening after window had been rendered.

@johanmalm
Copy link
Collaborator

@johanmalm johanmalm commented Jan 21, 2022

In “normal” mode, xdg toplevel surfaces with CSD enabled have an invisible area around the visible view (window). I call this padding.

The first time such a view is mapped, we force it to be unmaximized and then use update_padding() to get the padding size.

labwc/src/xdg.c

Line 240 in 8e9643a

update_padding(struct view *view)

When maximized, the padding is zero.

I think I’m right in saying that we can’t obtain the padding until such a view has been in an unmaximized state.

i guess the better way to do this would be to keep track of when the padding has been set and deal with it on unmaximize.
From memory, I think it tried setting the padding on every commit. I felt like an overhead we didn’t want, but maybe it’s a small price to pay.

@Consolatis
Copy link
Contributor

@Consolatis Consolatis commented Jan 21, 2022

What is the purpose of this invisible area?

@johanmalm
Copy link
Collaborator

@johanmalm johanmalm commented Jan 21, 2022

I think it’s for drop shadows. Maybe also to allow move/resize grab outside a thin window border.

@johanmalm
Copy link
Collaborator

@johanmalm johanmalm commented Jan 21, 2022

See the bottom of this page

https://wayland-book.com/xdg-shell-basics/xdg-surface.html

@ARDiDo
Copy link
Contributor Author

@ARDiDo ARDiDo commented Jan 21, 2022

Thanks for testing @Consolatis. Since no one else has reported any problems with unmaximizing, and I can't remember ever having a problem with unmaximizing before this, I wont bother messing around with it too much.

Well, I tried out mousepad, and it didn't want to start in fullscreen. Mousepad believed it was fullscreen, but it wasn't.

@Consolatis
Copy link
Contributor

@Consolatis Consolatis commented Jan 21, 2022

@johanmalm Thanks for the link, the book looks interesting. Bookmarked for a later time.
So that area is basically part of a client which tells the compositor its not part of the client. I hate CSD.

@ARDiDo I only had a quick test with foot though, so wayland native + SSD client. Can't say anything about X11 or CSD clients.
By the way: GTK 3 apps can be used for testing X11 and Wayland: GDK_BACKEND=x11 gtk-app .. vs GDK_BACKEND=wayland gtk-app .. and they should render their own CSD when labwc config sets decorations to client.

@Consolatis

This comment was marked as off-topic.

@Consolatis
Copy link
Contributor

@Consolatis Consolatis commented Jan 24, 2022

Recent revert of 6651d45 fixed both issue for me and at least native Wayland SSD clients can be started in fullscreen and maximized. So what's left is verifying X11 and Wayland CSD clients can properly be started in fullscreen / maximized states.

@ARDiDo
Copy link
Contributor Author

@ARDiDo ARDiDo commented Jan 24, 2022

7a3cd65 adds support for xwayland clients. I tested this with a game played over Wine, and before, the game was the right size, just placed mostly off screen. After, it was placed in the right spot.

CSD clients seem to be the sticking points of this. Mousepad can't start in fullscreen with the wayland or the x11 backend. Weird thing to note, is that with the x11 backend, mousepad presented itself as if it were fullscreen (no decorations), while it didn't present itself as fullscreen with the wayland backend. I can probably get down to the root cause of it this week, but if someone else wants to take a crack at it, then be my guest.

@Consolatis
Copy link
Contributor

@Consolatis Consolatis commented Jan 25, 2022

Tested with xterm -fullscreen and it works as intended.
Tested with xterm -maximized and it appears maximized, the top position and width is correct but it extends below the bottom of the screen. Double clicking the title bar then causesd a proper maximize with the bottom lining up with the bottom of the screen.

@ARDiDo
Copy link
Contributor Author

@ARDiDo ARDiDo commented Jan 29, 2022

I've done some testing, and xterm doesn't make a call to view_maximize(), or any other related functions. I'll do some more testing to see if xterm is alone in this weirdness.

@ARDiDo
Copy link
Contributor Author

@ARDiDo ARDiDo commented Jan 29, 2022

e2cca1f fixes the problems that I was having with mousepad. The padding acts the same as it is when it starts outside of fullscreen.

I did some more testing with sakura, and I've found that it doesn't like to go through conventional means to maximize either. It sets the maximize_vert and maximize_horz members of the xwayland surface to true, without making any requests to us whatsoever. I plan on fixing this sometime this week, but I don't think we can do anything about xterm. It doesn't set those members, or make any maximize related requests.

@Consolatis
Copy link
Contributor

@Consolatis Consolatis commented Jan 29, 2022

The fact that I am able to maximize the xterm window after it has been started with xterm -maximized likely means it just gets the output size from XWayland and sets its own size to be the same and positions at 0, 0. Which then obviously clashes with the SSD and thus extends ssd_height below the bottom of the output. Not much we could do about that other than checking if the pos is 0, 0 in output local coordinates and size matches output->usable_area, then forcing a maximize. If we want to do that however.. Not so sure.

@ARDiDo
Copy link
Contributor Author

@ARDiDo ARDiDo commented Feb 3, 2022

Alright, well, it looks like handling maximized xwayland windows is messier than I expected. If I try to maximize sakura when it is mapped, then it gets positioned somewhere in the middle of the screen. Right size, wrong location. It's not view_maximize() that places it there, so I think sakura may be doing it to itself. But I'm not sure.
With how strangely sakura and xterm act, I say that we may be better off ignoring any xwayland view that doesn't bother to send a formal maximize request.

@Consolatis
Copy link
Contributor

@Consolatis Consolatis commented Feb 8, 2022

we may be better off ignoring any xwayland view that doesn't bother to send a formal maximize request.

Agreed. If an application doesn't care to send a maximize request but instead tries to emulate it itself we should probably don't try to fix it on our end.
Are there more issues related to fullscreen / maximized on startup? If not, I suggest closing this issue.

@ARDiDo
Copy link
Contributor Author

@ARDiDo ARDiDo commented Feb 11, 2022

I can't find any more issues, so I'm closing it. Thanks for your help @Consolatis and @johanmalm.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug
Projects
None yet
Development

No branches or pull requests

3 participants