A question about fakefullscreen and on the scripting/customization system in general

[nativerv]

Following my comment on #871:

I would actually prefer all my windows to be fake fullscreen'd by default (as in xmonad), instead of toggling them manually, but the fakefullscreen also tells the window itself that it should to go fullscreen or something, doing the same as if i pressed F11 in firefox or chromium for example, which is not exactly usable. I want it to go to fullscreen (fake fullscreen) only when the app wants it, like when i fullscreen a video on youtube or whatnot, but not to tell it to go fullscreen immediately for some reason. That's my issue/question number 1.

But the F11 thing apart, i tried doing the following script to do the job (fakefullscreen'ing all (or some) windows automatically):

#!/bin/sh

set -ue

: "${HYPRLAND_INSTANCE_SIGNATURE:=none}"

handle () {
  event="${1%%>>*}"
  class="${1##*>>}"
  class="${class%%,*}"

  echo "event: '${event}' class: '${class}'"

  [ "${event}" = "fullscreen" ] && [ "${class}" = "firefox" ] && hyprctl dispatch fakefullscreen || true
  [ "${event}" = "fullscreen" ] && [ "${class}" = "mpv" ] && hyprctl dispatch fakefullscreen || true
}

socat - 'UNIX-CONNECT':"/tmp/hypr/${HYPRLAND_INSTANCE_SIGNATURE}/.socket2.sock" | while read -r line; do
  handle "${line}";
done

But either i'm missing something, or that level of customization is impossible rn. That's my issue/question number 2.

It does not work, and even if it did, fakefullscreen would only work on currently focused window as far as i get it, which
may not be the one that requested fullscreen.

And even if there was a way to specify window for fakefullscreen (and get that window id too to specify it), there is no way to specify ordering of the event actually happening and it's handler being fired (before, after), so how is it supposed with this naive approach to enable fakefullscreen to stop it from going fullscreen if the window is already fullscreen'd?

Also, the same fullscreening problem is affecting my mpv setup as i use --force-window=immediate (as pointed in #1375), but in this case even toggling fakefullscreen manually with a keybind doesn't help, mpv fullscreens anyway. Maybe that is a bug actually. That's my issue/question number 3.

Maybe i'm missing something, but the current scripting/customization system seems not very robust. Will it always be that way or you plan on extending it to allow more customizations? And, can i deal with my concrete stuff somehow right now?

If you please me to throw my opinion out, i think that the api for customizing a hackable tiling wm/compositor like Hyprland should be exposed through proper programming lang instead of the DSL from the start. At least the configuration should be written in shell scripts and should be optimized for that (to the point of hyprctl performance/manual batching situation), through calls to hyprctl or sourced functions into the init script. That already will provide much greater customizability and integration into the system, but it would be best if it were a native approach in C++ like the classic dwm/xmonad/qtile/etc wms have, which allow almost infinite customizability almost for free, like small stuff that i've described, or bigger like implementing custom layouts for example, etc. Or, at least, to have a bindings to scripting language like lisp or lua, but to be worth it they should be as full as possible, which undermines it before the native solution as it is a lot of extra work. There may be a user-friendliness argument, but i think that it is the other way around, the DSL is not only as hostile as minimal program in C or any other proper lang to the average end user that doesn't know any C/C++ (given that end users of hyprland are power users anyway as with any other tiling wms), but it is also hostile to the users that know some C/C++ and don't mind such approach, which it otherwise wouldn't be.

The only thing that i know of that is preventing such system from being usable out of the box is that on wayland to restart the wm you need to restart the whole compositor, killing the whole session. But i'm sure there are ways to solve this problem. I'm not at expert on the topic, but maybe something like compiling user's code to .so binaries and dynamically loading them into hyprland, or just separating hyprland's wm from the compositor like x11 does and exposing wm as a library to the user as xmonad does. Haven't seen anything like that in any other compositor, though. But if that is solved, then the rest shouldn't be much of a problem. Even live reloading can be done with scripts that do recompiling and restarting.

Don't know if this was already discussed, but there's my two cents anyway. Want to hear your opinion on that, besides just that this is a lot of work and out of scope and probably won't happen.

[vaxerski]

Hyprland's scripting API is pretty simple in its methodology, yes. Why? Because this project is like 10 months old.

Am I going to add a plugin system? probably, off in the future.

The problem with plugin systems is that few people can write them and even fewer really need to, that's why I am focusing on other stuff.

For your script, I think it is doable, but it won't be that simple. Call fullscreen to unfullscreen it and then call fakefullscreen. The problem then is that when you leave fullscreen it will stay in the fakefullscreen mode. Further issue you pointed out yeah they dont take windows as arguments.