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

Ability to Enable Floating Windows #202

Open
jefrecantuledesma opened this issue Apr 23, 2024 · 3 comments
Open

Ability to Enable Floating Windows #202

jefrecantuledesma opened this issue Apr 23, 2024 · 3 comments

Comments

@jefrecantuledesma
Copy link

Would it be possible to add a setting to enable floating windows by default? This is a very minor thing, but the default behavior (at least this has been my experience on SwayWM) is for the windows to not be floating. Below is a screenshot of what I'm talking about. I have no idea if this is an easy thing to change or worth any of your developers' time.

1713832783_grim

If the windows were floating by default, here's what that would look like:

1713833106_grim

Also, thanks to everybody who works on this project!

@Ichthyostega
Copy link
Contributor

We might want to find out a bit more about context for this issue.
Your second image shows how Yoshimi typically behaves and how it is intended to behave.

You mentioned SwayWM; as far as I know, this is a so called "tiling window manager". Some people favour this kind of window layout very much, but I wouldn't say that it is mainstream...

The key point with a tiling WM is that it disregards the initial size hint given by the application and rather immediately places the window into full-screen or into a fixed grid of non-overlapping frames. Contrast this with the classical approach taken by most default window managers: this is to stack windows rather than to tile; such a window manager starts with the initial size hint given by the application and then applies what is known as "smart window placement" — which generates a somewhat random cluster or pile of windows partially covering each other. Typical examples would be XFCE or Mate or Gnome on Linux, or the classical style on windows.

This leads to the following questions:

  • why are you on SwayWM? was this a deliberate choice, or are you on some system (which?) where this is preinstalled?
  • does SwayWM offer some ability to set a preference for a specific application to not apply the tiling behaviour?
  • and last but not least: is it even possible for the application to set a specific layout hint? and is it a good idea for an application to do so, instead of just creating a default style window (which can then treated by the actual window manager according to its preferences)?

@jefrecantuledesma
Copy link
Author

jefrecantuledesma commented Apr 24, 2024

@Ichthyostega Thank you for the follow-up questions! No, tiling window managers definitely are not "mainstream," but they're common enough (or so nerds like I would argue). It's definitely not a very pressing issue. This is also my first time posting to a project, so I apologize if this was the wrong way to propose a recommendation.

Anyway, I have some answers for you:

  1. This question made me laugh. Yes, this was a deliberate choice as I prefer the simplicity of tiling window managers. I don't have to worry at all really about dragging around windows--and when I do need to, it supports that functionality.

  2. It does! I found a semi-workaround for this issue. Issuing swaymsg -t get_tree results in the following:

#1: root "root"
  #2147483647: output "__i3"
    #2147483646: workspace "__i3_scratch"
  #3: output "eDP-1"
    #39: workspace "2"
  #74: output "DP-7"
    #75: workspace "4"
  #78: output "DP-6"
    #79: workspace "3"
  #80: output "HDMI-A-1"
    #81: workspace "5"
      #43: con "(null)"
        #8: con "Ability to Enable Floating Windows · Issue #202 · Yoshimi/yoshimi — Mozilla Firefox" (xdg_shell, pid: 6765, app_id: "firefox")
        #95: con "fribbit@gronkum:~" (xdg_shell, pid: 94022, app_id: "foot")
        #90: con "*I have it back - Ardour" (xwayland, pid: 91678, instance: "ardour_ardour", class: "Ardour", X11 window: 0x600279)
      #97: floating_con "Yoshimi : " (xwayland, pid: 94120, instance: "FLTK", class: "FLTK", X11 window: 0x80000C)
  1. (cont) By specifying the class or instance type, I can put this line of code in my sway config file, which does result in Yoshimi opening windowed: for_window [class="FLTK"] floating enable, border normal. However, this isn't an ideal solution, as I imagine that other applications with the "FLTK" class would also open floating--which I don't normally want. If you look at the other results in the above code chunk, you'll see that Ardour, Foot (terminal emulator), and Firefox have either custom app_id's or classes, whereas (I believe) Yoshimi's is generic.
  2. This is a very good point. Given that tiling window managers often, well, tile, it would make sense to not force this on the user. However, having the option to have Yoshimi open always tiled, either through an option in the settings or giving it a proper app_id/class, would be pretty helpful. Of course, not pretty helpful to the vast majority of people, but helpful to us window manager enjoyers :)

@Ichthyostega
Copy link
Contributor

@jefrecantuledesma you are welcome!
The whole point with Open-Source and Free Software is that we can talk to each other and that we're free to try things out which are not "mainstream".

Obviously, the flip side of the coin is that all that variability makes it hard to build a UI that works well under the various different setups. And to add to that, when programming an UI, we have to deal with various layers of libraries, frameworks and standards. For the programmer, this can be quite intimidating, since often you're unable to say why something works the way it works.

The window-tree you posted above is interesting, insofar it shows that the programs using / relying on the xdg_shell protocol have an "app_id", while Ardour and Yoshimi have the metadata properties "instance" and "class". Ardour somehow managed to set these properties to custom values. I know Ardour uses GTK, and probably there is some mapping of metadata done somewhere in GTK.

Yoshimi on the other hand uses the FLTK toolkit, which is oriented towards rapid application development. In FLTK you have some kind of a GUI builder, which offloads most of the work required to get started with building a GUI. On the long run, this approach can be a blessing and a curse at the same time. To be honest, I don't have the slightest idea where and how the above mentioned "class" and "app_id" metadata is mapped by FLTK.

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

No branches or pull requests

2 participants