Closed djsavvy closed 2 years ago
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
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/
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.
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:
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.
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:
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!
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.