User preferences

[crumblingstatue]

Let's discuss design and implementation of user preferences here.
In #16 I attempted to add a preferences struct for configurable default zoom, but it was a bit hasty.

We can write down both ideas about implementation, as well as what should be considered a preference.

Here is my list of what should be user preferences

• Default zoom level
• ... I'll try to think of more, lol

Unresolved questions:

• Should keybindings belong under user preferences, or should they be a separate entity altogether?
• What serialization format would we use to save preferences?

Implementation ideas:

• Use directories crate to get user config dir to store config in

[yds12]

First I'll just write what's on my mind regarding configuration, in a later post I'll try to summarize it in a more organized way.

There is a lot of things that right now are stored as consts somewhere, that should probably be configurable. The consts should still exist in case the user opened the program for the first time, but they should all be overridable with values found in configuration files. Let's call these "initial values".

Other than initial values, there are shortcuts. These should all be configurable. This part will be hard, considering the way things are done right now. The GUI code is very adhoc. The complicated part is that there are very different types of shortcut. Think about "pan" (moving camera). The current shortcut is the arrow keys. The other common alternative for this is to press "SPACE" or some other button while dragging the mouse. Or zoom, which currently is + and -, but could be mouse scrolling plus SHIFT, or something like that.

Other important consideration is what will be part of lapix configuration, and what will be part of tarsila. Like we have Event for lapix and UiEvent for tarsila, we might need to have a Preferences type in tarsila that contains a Preferences type from lapix. Shortcuts definitely should be part of tarsila. [Ok, I just checked and doesn't seem that lapix has much to be configured, there's initial palette colors, but I'm thinking that all preferences could be on tarsila.]

Here is my list of what should be user preferences

Some things:

• zoom level
• camera speed
• background color (UI colors in general)
• position of windows
• initial windows and UI state (which ones are visible, which ones are collapsed)
• starting color and selected tool
• starting palette
• shortcuts
• default directory to open when saving/exporting/loading palette, etc.
• etc...

There's a lot that can be configured.

Use directories crate to get user config dir to store config in

Yes, good idea. We should use this to find where to store the config file.

Should keybindings belong under user preferences, or should they be a separate entity altogether?

There should be a type for the shortcuts, but it would probably be part of a larger configuration object.

What serialization format would we use to save preferences?

Also interesting question. Toml is the default in rust and is a simple format, but on the other hand JSON and YAML are more common formats. I like the idea that the configuration should be easy to edit by hand, in case you want to customize stuff before without opening the program. Toml is very nice and simple when it's simple, but for nested things I think it's not so good.

Some other concerns I have: where will config live? In UiState? Will it be a global object (generally considered a bad pattern). One thing is certain: lots of parts of the program will need to access this.

---

I was postponing this topic because of those complications.

At the same time, I think it's good to provide configuration soon, because many people might be discouraged to use the program because the defaults are not what they like. It's nice to be able to use the defaults you are used to from other software.

---

There's just so much planning we can do beforehand, at some point we would need to write some code to see what works well. My suggestion would be to gradually improve this. For example, currently we have some keyboard shortcuts hardcoded in the keyboard.rs file. We could start from there:

• can we generalize this to shortcuts that are not only keyboard?
• can we serialize this to a file?
• can we change some of the UI code to be less adhoc and start using this new preferences object instead?

[yds12]

For the shortcuts, I think we need a whole overhaul of the input system. We need an InputManager that would keep track of mouse and keyboard events, and from those generate InputEvents. We would then check those events against the Shortcuts preferences to see how the event maps to a UiEvent or Event.

The modelling of the InputEvent is maybe the most important and difficult to do.

[yds12]

I'm considering to remodel the input like this:

The InputEvent has info about all the things that happened in that frame in the mouse/keyboard. It will include:

• keys pressed/down/released
• modifier keys down (CTRL, SHIFT, etc)
• mouse button pressed/down/released
• mouse position
• mouse scroll moves

One InputEvent can have all those things, or maybe we should have a collection of InputEvent, with one for each of those things.

The Shortcuts object will store the shortcuts that are configured for each action. We can start with a default Shortcuts object, but it should be easily deserializeable from a file, allowing the user to configure preferences by modifying this file manually, or later modify it via the preferences/shortcuts GUI.

The InputMapper (probably need a better name for this) will take those InputEvents and the Shortcuts configuration and figure out which Effects are triggered by that input combination. An Effect is either an Event (lapix) or a UiEvent (tarsila frontend).

[yds12]

I have a draft implementation of the configurable input system in this branch: https://github.com/yds12/tarsila/tree/input-overhaul