Make awesomewm titlebar buttons appear on the natural side given the client's OS

[djsavvy]

We should have an option for whether the titlebar buttons (maximize and close) appear on the RHS or LHS of the titlebar.

For Windows/Linux users, this should be on the right side. For Mac users, this should be on the left side.

Note that Linux users can customize their WM/DE and switch the buttons around, so this should be a configurable option and not be hard-coded by operating system.

Possible implementation: a variable sent over by the task definition, that is then read into a file in the container and processed by awesomewm.

[rpadaki]

If we make cloud storage mount before starting the display, we can have this config reside in their cloud storage and be configurable from the client app! We can have nice defaults per OS

[philippemnoel]

We might also want to make these look like the user's OS. I know we're not sure on that yet. Savvy mentioned this could confuse users into thinking that they would be able to drag the windows outside of the SDL window, for instance, which is quite possible. I do want to keep this option open as I think it might make integration with user OS much stronger and improve retention, if that is not a concern. TBD.

Here's a link to a config that enables macOS-looking buttons and windows https://www.reddit.com/r/unixporn/comments/7hs3hf/awesomewm_my_awesome_macos_clone/

[philippemnoel]

adding to this: another one of our user demos requested that the UI looks as seamless as possible to their operating system -- I think the confusion that could arise from trying to drag pop-ups outside the window is much lower pain than the application not looking fully seamless.

[djsavvy]

I think moving the titlebar buttons to the correct side is a good call, but I'm afraid trying to make the UI look truly seamless will get hairy rather quickly. We would need to configure a lot of things on the fly: think titlebar height/default color, since that can change on Windows and Linux; border thickness/behavior (when do window borders disappear?); window drop shadows (so the user can tell if a window is focused or not), and a million other things that the OS window manager does and users see/interact with unconsciously, for the most part. Some behaviors, like being able to resize windows by dragging on their borders, are not going to be possible without forking awesomeWM. And others, like being able to drag "native-looking" windows around their screen freely, aren't going to be possible at all.

Also, users are quite used to very different-looking apps on their computer. At least on Windows, the electron Slack app looks quite different from anything else you'd use. Browsers obviously have their own theming. Postman, for example, is shit because it doesn't load sometimes and has crappy UX, but it looks relatively nice, and is pretty close to the Fractal app right now look-wise.

I think the issue of "making the UI look as seamless as possible" comes down to (at least) three possibilities:

1. Moving the awesomewm titlebar buttons to the OS-native side of the window. This is relatively low-hanging fruit, and it takes away the most jarring part of using Fractal on a mac.
2. Writing our own window manager with the capabilities of blending into all major operating systems. Like I said, there's a million different details to deal with here for it to feel natural, and this would probably take months to years of dedicated effort. One way to see why this is the case is to look at the codebases of even a "simple" window manager like awesome, and how long it's been in development, and compare its level of polish to those of the Windows or Mac environments (it's not even close). Even if we forked an existing project, we'd have to implement the "last 90%" (i.e. polish) on it ourselves.
3. Supporting the concept of multiple windows in the protocol itself, and allowing the multiple Fractal client windows to then be SDL --- they will automatically look and feel native. We won't have to worry about drop shadows, implementing resizing, dragging, etc., and everything will feel native to boot. This approach can (for example) be implemented by telling the X server it's connected to multiple screens, one per window, and capturing each screen separately.

I think we should proceed with #1 once we're done with more important features, and we should implement #3 in the longer-term for maximum polish. If we're hell-bent on #2 despite its downsides, then we should source a designer (perhaps even from communities like /r/unixporn) to make us some GTK/QT themes that look as close to windows/macos as possible on a Linux system. But I still think trying to half-way disguise Fractal subwindows as native will be a worse and more frustrating experience for users than if they can immediately know to have different expectations for Fractal subwindows.

[djsavvy]

[djsavvy]

[djsavvy]

[neilyio]

Just to sum up some discussion in Slack today, @djsavvy @rpadaki and I discussed the possibility of making custom title bars that match colours on each OS. @rpadaki mentioned it's possible, with some extra considerations for Windows.

We also discussed removing text from the title bars to further remove OS-specific differences (like fonts). @djsavvy pointed out that the text, along with title bar color, can be useful to the user to indicate which window is focused.

I created a mock-up of some ideas related to title bar color. The mockup includes an idea for a "tab" system in the bottom left, using color tab/title color to help the user identify windows.

Our current UI from Fractalized Blender:

Mock-up:

[philippemnoel]

I'm going to close this -- with #141 we're going to be moving to Weston for the backend and no longer use AwesomeWM, so this is no longer relevant!