Support for manual config files (Options, CSS, JS)

[9z0]

Multiple Electron-based projects allow the user to have their own CSS/JS run at startup.

This allows the user to customize almost any part of the UI/UX to their liking without burdening the developer (you) with requests (other than helping with the syntax if a user is stuck).

---

A few examples (existing issues) which can be implemented in this way:

• Font type customization #133.
• Change font size (Scaling) #57.
• Color customization #99.
• "Add minWidth and minHeight constraints to the window" #118.

And a lot more: adding/moving buttons, always-visible todo count, resizing bars/panels etc.

Even more complex features/bug fixes can possibly be implemented in case development stops for whatever reason.

---

Example projects which can provide ready-made methods for this are:

• Joplin. It provides userchrome.css (for customizing the app UI) and userstyle.css (for customizing MD rendering). See here.
• Notable.

---

It comes down to just reading a user-filled CSS file/JS file and running them on startup.

---

Tasklist:

• [ ] Options

  • [ ] Unminify the user-preferences.json so that it can be easily edited. Alternatively, support a simple format, like ini along with/instead of the json file.
  • [ ] Simple comments in the file to indicate, in short, the function of each user-changeable option and its accepted values.

• [ ] CSS

• [ ] JavaScript

[9z0]

I edited the issue title to reflect the need for a solution for advanced editing while keeping the GUI simple.

Aside from customization, options in user-preferences.json should be expanded to allow the user to change the defaults in multiple areas.

I think this will benefit the advanced user while being easy enough for @ransome1 to add.

[ransome1]

@9z0 if you say allow the user to change the defaults in multiple areas, what exactly does this mean?

[9z0]

@9z0 ah ok, now I understand what you are referring to in the other ticket.

What did you see it as? :D

I assume the typical sleek user has tried out a couple of different todo(.txt) apps and was amazed on how unpleasant many felt like and how much complexity had been worked into some interfaces.

1. I can only speculate about others and my own experience will obviously affect my view, but for me, you'd be surprised (maybe not you!) how many of these apps miss basic usability features or have feature-breaking omissions. Among them one or more of:

• No filters!
• No search!
• No sort!
• One key delete AND no delete confirmation AND no undo.
• Only accepts files named "todo.txt"
• Filter options don't include none. You can't filter todos without context, for example.

2. And those that do have most of the above right have ALL its features in your face in specific ways and are not customizable. So either the app is unusably simple or caters only to the developer usage habits and workflow.

A good design philosophy is to have sane defaults AND simplicity out-of-the-box AND customizability (and, depending on the case, extensibility). These are not contradictory. You don't have to choose; although I'll admit that it takes a bit more effort and vision to implement.

I do agree with you that many users could simply want a simple list to add and check, but I'd claim that this is offered already offered by multiple other todo apps. The "art" here is subtle intuitive design (think Apple) that the user wouldn't even think to mention if you asked them about the features of the product or what they like about it.

Fortunately, much of these cues and options are out there already and not too difficult to implement. For example, sleek itself:

• puts setting icon and help in a corner out of the way but accessible.
• moving todo options from a three-dot menu to context menu (one click either way). -> cleaner look.
• click panel headings to filter by none.
• panel close arrow that appears only if the user hovers on the separator.
• etc

As long as the basic usage is as easy as possible, and features don't force themselves on the user, I think the simplicity of sleek (and todo.txt) is comfortably achieved. To be clear, at this point I'd take a todo.txt app that covers the basics over a feature-rich one; but my whole point is that we don't have to pick! It is all about how the features are implemented.

[9z0]

Exposing settings in the config file is not a problem, especially if existing settings get removed from the GUI but stay active in the code. Implementing new edge case features and making them available in the user-preferences.json is totally fine, as long as those features are developed neatly, maintained and don't interfere with the major functionality.

👍

I personally rather focus my efforts on existing features or ones that benefit most users,

That's both obviously the better thing to do and I agree. At the same time, with any feature, there is a product of "number of users x simplicity of implementation x value of the feature (and maintainability, etc like you mentioned above).

I think that exposing settings in text (reading them on startup) may help a minority of users but has a higher score of simplicity and applicability to many things. I think that, conservatively, 70% of my requests I can do myself with text settings/reading user CSS/JS.

@9z0 if you say allow the user to change the defaults in multiple areas, what exactly does this mean?

Options relevant to the functions of sleek and looks without limitation to a particular UI element.

Let the user know (in the file) that these are subject to change. I'd suggest unminifying the json file for ease of use, though!

[9z0]

A couple of examples of what I mean by exposing as much as possible of functions of sleek:

• how often the file is polled for changes.
• how many todos to show in each lazy loading cycle.

These little things can solve individual-user issues on the long run.

[9z0]

Since sleek is moving more and more beyond a bare-bones app, we are increasingly having to choose between customizability and simplicity of use.

A solution like this one is widely used to offer the user a choice while keeping the UI simple and user-friendly.

I added a task list to the first post with what I think is a good foundation to start with the options part (or maybe continue, since sleek already uses these kinds of options 😉).

@ransome1 If you want, I can split this issue into three separate ones.

[github-actions[bot]]

This is an automated response. We acknowledge your report, and we appreciate your engagement. However, as there has been no recent activity in this thread, it has been marked as stale. If you have any further feedback or if the matter is still relevant, please do not hesitate to respond. Otherwise, this thread will be automatically closed in 15 days from now.

[dnngll]

Xreference to https://github.com/ransome1/sleek/issues/99#issuecomment-1717753556 to avoid autoclose

[ransome1]

A custom css file can be used in the latest developer preview, more information here: https://github.com/ransome1/sleek/wiki/Custom-CSS

The config file is not minified in the rewrite if sleek. All currently implemented configurations appear in here.

Regarding JavaScript, I don't see the point. If a user is into heavily customizing an app using JavaScript, it might be a better idea to simply fork sleek.