00:26 lsd|2: dd
07:02 JEEB: 40
07:02 JEEB: whoops
08:39 pq: zamundaaa[m], what does "borderless fullscreen" mean on Wayland?
08:40 pq: how could a window be fullscreen without setting the one and only fullscreen state, and if that state is set, then why would there be need to explicitly and separately trigger "no decorations"?
08:41 pq: or, does "fullscreen with decorations" exist?
08:45 emersion: that sounds like maximized
08:45 pq: that's what I thought too
08:58 kennylevinsen: on macOS fullscreen, the full top decorarions and global menu are always available to slide in on demand (which differs from when e.g. browsers just slide in their address bar or tabs on other OS's), but that's the only example I could think of across OS's...
09:00 pq: do you mean that "macos fullscreen" would be like "borderless fullscreen" and then in "true fullscreen" the global menu etc. won't appear?
09:02 pq: if that's something to be supported, sounds like should be an explicit new window state in the axis of floating, maximized, fullscreen with widgets, fullscreen.
09:02 emersion: i think it's just regular fullscreen, with a system-wide standard way to show the status bar and decorations?
09:03 emersion: (move pointer to the top edge)
09:03 emersion: android also has fullscreen swipe from top edge to show the status bar
09:04 pq: should the client have any say on whether gestures like "move pointer to top" should trigger DE things or not?
09:04 emersion: and in general a tap on a fullscreen app in android will reveal the status bar and navigation buttons
09:05 pq: probably not if it's an android game
09:05 pq: or any app where tapping is part of the normal usage rather than an escape
09:05 emersion: yeah, up to the app
09:06 emersion: gallery and video players behave that way, but other apps don't necessarily
09:06 pq: sounds like another explicit window state to me, rather than something to do with decorations protocol
09:07 emersion: the reason I bring it up is that apps have a way to show system UI
09:07 pq: that might be better
09:09 emersion: also in general on android the system UI integrates with the app
09:10 emersion: app draws behind the system UI, or sets the system UI color etc
09:10 emersion: (and is aware which parts of the app are covered with system UI)
10:06 kchibisov: macOS has 3 fullscreen modes: regular fullscreen which creates a separate workspace(useally called borderless), the one which doesn't create a workspace for it (simple), and the one which does modesetting.
10:07 kchibisov: I think simple fullscreen allows windows stack on top, while occupying all the area on the workspace (windows has the same concept).
10:07 kchibisov: Maximize window on macOS doesn't obscure the title bar, while simple fullscreen does.
10:08 kchibisov: The wayland fullscreen right now looks more like borderless, but maybe borderless they were talking about is some other _borderless_.
10:10 kennylevinsen: back in the day, it wasn't maximize but "zoom" which did not fill the screen but expanded the window to fit the content. I don't remember if/how that changed once they introduced the fullscreen type that becomes a new workspace
10:16 kennylevinsen: I feel like a catalogue of window management features per OS would be useful at times
10:41 pq: kennylevinsen, at first I read you saying "I feel like a catalogue of features" :-D
10:42 emersion: lol
10:42 kennylevinsen: Hah! I suppose that's not a too inaccurate description of my job role at times :P
11:10 wlb: weston/main: Loïc Molinari * libweston: Let multiple backends register the Windowed Output API https://gitlab.freedesktop.org/wayland/weston/commit/f4c69abc577f frontend/main.c include/libweston/windowed-output-api.h libweston/backend-headless/headless.c libweston/backend-wayland/wayland.c libweston/backend-x11/x11.c
11:10 wlb: weston Merge request !1404 merged \o/ (API: Let multiple backends register the Windowed Output API https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1404)
11:46 zamundaaa[m]: pq: it's not a thing on Wayland, just a concept from Windows. Some games support a variant of it where you can select a lower resolution though... Making it just a normal boring borderless window
11:48 pq: oh, so it can be not-fullscreen at all
11:49 pq: is it supposed to be floating, without letterboxing?
11:57 JEEB: it's basically fullscreen by means of window that takes the full size of the desktop
12:00 emersion: on windows, there is no semantic difference between exclusive fullscreen and borderless fullscreen
12:01 emersion: only a technical difference
12:01 emersion: exclusive fullscreen can modeset, borderless fullscreen integrates better with the rest of the desktop
12:01 emersion: (exclusive fullscreen is somewhat similar to DRM leasing)
12:07 wlb: weston Merge request !1477 opened by Derek Foreman (derekf) tests: Attempt to fix LSAN crashes https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1477 [Build system], [Testing]
12:11 pq: JEEB, I mean specifically in the case when it's not the full size
12:11 JEEB: pq: I think what was meant there is that render resolution is lower and yet the window size is full
12:12 JEEB: so on a 1920x1080 screen you have a 1280x720 render resolution selected in game and that then gets output as a 1920x1080 window
12:12 pq: no, I mean literally borderless-fullscreen window not covering full screen
12:12 JEEB: then it's not borderless fullscreen :)
12:12 JEEB: borderless fullscreen is when a borderless window matches the desktop display
12:13 pq: so borderless-fullscreen is techincally not fullscreen, it just happens to have the right size sometimes?
12:14 JEEB: borderless fullscreen is just a name to call fullscreen by means of not calling the exclusive fullscreen APIs.
12:14 pq: ok
12:14 JEEB: so if your window fills the whole desktop display then it is borderless fullscreen
12:14 zamundaaa[m]: What I meant is that some games have a "borderless" option, which can be different from the actual technical "borderless fullscreen"
12:15 JEEB: yes you can also have a borderless window of size 1280x720 which of course is not fullscreen in any way or form :)
12:15 pq: One cannot do that on wayland, because one cannot position the window correctly without making the window actually fullscreen by protocol.
12:16 pq: yes, very confusing, what's a semantic state and what's API/protocol state
12:16 JEEB: I think in wayland that would just be a window without decorations
12:17 pq: and in arbitrary position that cannot be controlled by the app
12:18 JEEB: on windows the window position has nothing to do with "window that has no decorations" :) I think the only case where the position matters is when you are trying to fill the desktop display with a window without decorations.
12:19 JEEB: although it's highly likely that a compositor sees the size request and puts it so that it covers the whole desktop display
12:22 pq: I wouldn't be so sure of that at all.
12:23 pq: Is it common to automatically move a window if it spontaneously grows partially off-screen?
16:39 ifreund: I certainly dont in my compositor
16:39 vaxry: I don't even allow the windows to do that >:)
16:43 JEEB: I was just trying to get specifics about window position out of that, since how you do it in wayland is a separate discussion :)
16:45 JEEB: window, window that takes the full desktop display size, application that wants exclusive fullscreen access being the three possible things in windows-land.
19:57 wlb: weston Issue #891 opened by Jordan Williams (jwillikers) What's the pkg-config variable pkglibexecdir for? https://gitlab.freedesktop.org/wayland/weston/-/issues/891