Open jkurei opened 4 years ago
Hi,
my concern is about the long term maintenance. When I change the code in the future, I won't really be able to test these mac specific changes which mean they will break eventually :-/
Yeah, thats an important concern.
Do you think having all os-specific stuff easily configurable from user settings could alleciate this enough? Im thinking window styling, for instance, would have two options: Mac vs Windows style, and left vs right. They would be defaulted for each os, but you could change them anytime.
Keeping thede things as minimal as possible would also be important.
Ive been thinking also about doing this completely on the user side, with themes and scripts, and I think most of it could be done... May be a Mac notes tree in the demo notebook? It brings other questions, as sharing scripts between users and all that is complicated.
Do you think having all os-specific stuff easily configurable from user settings could alleciate this enough? Im thinking window styling, for instance, would have two options: Mac vs Windows style, and left vs right. They would be defaulted for each os, but you could change them anytime.
Generally providing configuration makes things harder - now you have 4 distinct cases (mac style left/right, win left/right). I would just follow platform default (mac style left, normal style right), I don't think many people would like to have it otherwise.
Keeping thede things as minimal as possible would also be important.
Yes, that's definitely important principle. What can also help is to separate the special Mac platform code into separate components so e.g. MacTitleBarButtonsWidget
component. Not sure if that makes sense now since there isn't much except for template switch but if there would be more changes in logic I would consider a separate component.
I've been thinking also about doing this completely on the user side, with themes and scripts, and I think most of it could be done... May be a Mac notes tree in the demo notebook?
Yes, that's sort of an long term goal. I was thinking about how to expose the component layouts to the user, so they can rearrange the UI. But for this the theming would have to touch a lot of pieces and advanced concepts which I'm afraid would tie our hands in the future. So it's still in the plan, just not sure when and how ...
Yes, that's sort of an long term goal. I was thinking about how to expose the component layouts to the user, so they can rearrange the UI.
Order could be changed from CSS if the bar uses flexbox. The themes would be a bit fragile, tied to classes that arent in the contract though.
We could also expose this through CSS variables I think...
I use Linux, this is how it looks for me:
Go to option > appearance > native title bar > enable then restart trilium.
Maybe it will work in your Mac
I use a Mac for work and would love to have Trilium behave a bit more like a mac app. Also, many linux desktops don't really look like windows at all, and having mac-style buttons and such could be better. I've also thought if this would may be be better fixed from user themes... I don't know.
Because I think it won't be very hard, I'll be working on a PR to fix this, if you think this is a good idea. I wanted to open an issue first to discuss it.
I already have some ok-looking buttons:
I have the following ideas:
Keyboard shortcuts are also tripping me up a lot, I will see if I can make them more natural, using Cmd and all that, with minimal code changes.