Maximization and Windowed Fullscreen #130
Conversation
src/platform/macos/mod.rs
Outdated
|
|
||
| #[inline] | ||
| pub fn set_fullscreen_windowed(&self, fullscreen: bool) { | ||
| } |
There was a problem hiding this comment.
Perhaps these unimplemented methods should invoke unimplemented!() for now?
There was a problem hiding this comment.
I thought of that but it seemed to me it would make no sense to panic instead of noop for these things.
|
I'd like to rework the fullscreen/dimensions system. |
|
@tomaka does that mean this needs to wait for that or do you have a sketch of what that rework would mean that you'd like a PR for? |
|
@pedrocr Basically I'd like to have an API that can't be in an invalid state. In other words it should be impossible for the user to pass parameters that conflict with each other. |
|
@tomaka ok, so I just made with_fullscreen() and with_fullscreen_windowed() mutually exclusive by disabling one when the other is set. It shouldn't really happen as users should choose one or the other, and at least in X11 setting both is harmless but it's better be safe than sorry. After creation fullscreen_windowed already interacts properly with the window sizes so I don't see any other bad interactions added by this. |
|
@tomaka any opinion on this? |
|
Ah forgot to come back here. I didn't mean just methods. The methods are only helpers. What I want is an enum of some sort in the EDIT: Be aware that the current API already doesn't respect that, which is why I wanted a small rework. |
|
@tomaka, moved the fullscreen stuff into its own enum. See if that's what you meant. |
|
That's a good start! Unfortunately now the problem is that the backends are broken. |
|
Can't do much about the backends, I was just able to make sure X11 was working and Wayland should be too. Not sure what you mean about moving stuff into Windowed. At least on X11 the Windowed Fullscreen is just a hint you pass to the window manager who will resize the window for you. It will also remember the original window size and take you back to those dimensions when you unset the hint. So these fullscreen states and the dimensions are independent of each other. |
|
This now has conflicts with the existing code. Is it still worth pursuing? |
src/lib.rs
Outdated
| pub enum FullScreenState { | ||
| None, | ||
| Windowed, | ||
| Total(platform::MonitorId), |
There was a problem hiding this comment.
A more conventional name for this case would be Exclusive
There was a problem hiding this comment.
Probably, I don't have much experience with this kind of API to know what's usually used.
|
@tomaka cleaned up the commits and made them apply to current master. I discussed this with Ralith on IRC and we didn't see why it would make sense to move the dimensions into the fullscreen enum. This is also a pretty basic functionality so it would be important to expose it. Checks currently fail because I've only implemented X11 support and because glutin also needs a minor update to use the new fullscreen enum. |
Implement a simple API to set a window to maximized. Implement it only for the X11 backend.
pedrocr
force-pushed
the
maximization
branch
3 times, most recently
from
3dfe855 to
1c7ddce
Compare
There are two kinds of fullscreen. One where you take over the whole output the other where you just set the window size to the screen size and get rid of decorations. The first one already existed, implement the second which is more common for normal desktop apps. Use an enum to consolidate all the fullscreen states.
|
One problem is that Wayland doesn't have a distinction between exclusive and windowed fullscreen. It's up to the server to decide. |
|
And I think this API is full of corner cases. For example what if I create a window in exclusive fullscreen and call IMO there should be a clear state when it comes to windowed/fullscreen. |
|
Wouldn't the solution just be to move maximized into the enum as well to make all the states mutually exclusive? And if on some platforms some states don't exist that's fine two, the given backend should just ignore the distinction, no? |
|
On second thought I think the current API is already ok:
|
|
Implementing this properly in Wayland will require some work on wayland-window to expose the missing methods, but I don't see any large difficulty in terms of exposing the functionality. Now, it'll likely require some internal state-tracking, as the way these things are handled in wayland is rather that a window can be either regular, minimized, maximized or fullscreen. There is no notion of "both fullscreen and maximized". |
|
I still don't understand how maximized and fullscreen are orthogonal. What would a fullscreen non-maximized window be? |
|
So here's how most apps I've seen at least on X11 tend to work around maximized/fullscreen. They keep three types of state:
Then the following behavior happens:
If you consider maximized as not orthogonal to fullscreen step 4 and 5 get merged into one. You don't keep the previous state around, on every action you reset everything. This API also allows you to do that (just make the two calls) but provides the normal interaction where you get to unset only fullscreen or only maximized and have that state be tracked. |
|
Ok that makes more sense. I had the same mindset as wayland, which is that a window is either maximized or fullscreen. I guess I could just r+ this, and the API can always change later. |
|
I think it makes sense to make the api |
Use the enum to make a single fullscreen API that's much more consistent. Both set_fullscreen() and with_fullscreen() take the same enum and support all the variations so you can build the window however you want and switch between the modes at runtime.
|
Ok, pushed a commit to unify |
pedrocr
force-pushed
the
maximization
branch
4 times, most recently
from
2ab0b9f to
2d4365b
Compare
|
|
|
😃 |
…t-no-floor Don't draw the floor if the background is transparent
As suggested in #129 implement the ability to set the window to maximized and fullscreen. So far only implemented for X11 as that's the only thing I have access to.