Greyed checkboxes

CalebJohn · 2019-05-28T07:00:30.439Z

sciurius:

As I understand this can later be added easily (should the user want it) with some custom css.

Can you see how hypocritical this is?

sciurius:

So I need to clobber all my notes --manually!-- with visible, ugly and disgusting <style> tags? This is not acceptible.

sciurius · 2019-05-28T07:35:30.556Z

You’re missing the point.
I have no problem adding a central custom css that will suit my needs. That’s the whole idea of custom css.
But I do have a problem having to manually add a piece of css to all my notes. It is a lot of work, and css in a note is visible and clobbers the view.

sciurius · 2019-05-28T07:37:21.474Z

As discussed earlier there are workflows that use checkboxes just the other way around (checked items are important, unchecked items are not).

laurent · 2019-05-28T11:52:59.967Z

@sciurius, graying out the checkbox is consistent with the rest of the UI. In the note list, the completed tasks are also ticked and grayed out (and crossed out). The majority of people consider that “ticked” is done so that’s why it’s like this by default now.

tessus · 2019-05-28T12:49:11.518Z

CalebJohn:

I actually think this is the best option. Joplin already handles duplicate names pretty gracefully so we don’t need to worry about that case. I think it makes sense to put it into a config notebook, that way we can support mobile only css and desktop only css.

Yea, if you have notes with the same name, but if you want to just reference the name, it will be a problem. Also, this also means that you only have one userstyle.css note for all clients, otherwise you would have to reference the id and not the name. IMO this is too fragile.

CalebJohn:

Additionally I’ve been thinking about how we can support new note templates in Joplin and this would be a nice way to handle that as well.

I'm strongly against creating folders for users. Remember the welcome notes and notebook mess, which btw still screws up people's installations? At least the tags are gone for the welcome notes now.

tessus · 2019-05-28T12:55:28.581Z

sciurius:

there are workflows that use checkboxes just the other way around

From all the discussions I believe you are the only one who uses this inverted checkbox logic. But I understand your frustation, so let's hope there will be custom css for mobile soon.

sciurius · 2019-05-28T13:11:47.146Z

In the end that would be the perfect solution for this and several other issues.

laurent · 2019-05-28T16:41:46.653Z

CalebJohn:

I actually think this is the best option. Joplin already handles duplicate names pretty gracefully so we don’t need to worry about that case. I think it makes sense to put it into a config notebook, that way we can support mobile only css and desktop only css.

Additionally I’ve been thinking about how we can support new note templates in Joplin and this would be a nice way to handle that as well.

I like this solution at a technical level because it allows customising things easily, it's cross-platform, and we get free sync for it by re-using the existing architecture (and without having to make that architecture more complicated).

Then we can indeed add more config in there, including the templates you mentioned.

On the other hand, it's not very user-friendly. People will have to read the doc, manually create that config notebook with the right name (I agree with tessus that we shouldn't do it automatically), and the notes inside with the right name too.

I'm not concerned about duplicate names though - let's say for now the result of having two notes named userstyle.css will be undefined - the algorithm will pick the first one. Later maybe that algorithm could emit a warning, but it's not a big issue for now.

tessus · 2019-05-28T17:39:45.862Z

Don't forget that with this solution you have one file that will determine the css for all your devices and all installations. This might not be wanted. I might want to have one css for my ipad, another one for my Android, and another one for desktop.

laurent:

it’s cross-platform, and we get free sync for it by re-using the existing architecture (and without having to make that architecture more complicated).

This was also the argument for the welcome notes...

I'm just saying, if you add it to settings, it will be bound to the instance of joplin, which is something I would prefer over syncing. And as I said, people can still put the css in a note for copy and paste purposes or for reference. Maybe other see it differently. I will tell you that using a notebook and note will be a mess. You will get all sorts of problems. IMO this is opening the proverbial can of worms.

laurent:

config notebook with the right name (I agree with tessus that we shouldn’t do it automatically), and the notes inside with the right name too.

This also means that people can't already have a folder that is called whatever you will pick for that name.

Another thing - I don't want a notebook called whatever that is visible to me. The notebooks are for my notes, not to configure the application. So, if I wanted to use a different css, I'd have to have a new folder which I don't want and which is in my way all the time?

Using notebooks and notes for configuration sounds nice and it could be an awesome feature, but it would require a lot more than what was discussed here. e.g. hiding notebooks and notes, a unique id per device that is appended to the config note name, merging of notes, .... this is highly complex when you want to do it right.

CalebJohn · 2019-05-28T18:42:59.312Z

My thought had been that we would take a different approach to creating the config notebook because it is so special, and as you noted, you would need to be able to hide it. What would have been possible is to manually specify the ID and only refer to it by such (the users would then be free to rename it however they want). For example the config notebook could use the ID 00000000000000000000000000000000 because the probability that any specific ID is in use is extremely low. If this did cause problems (only possible during rollout) we would have to help the 1 or 2 users and then it’s done.

That said, typing this out makes sort of proves your point that it would be adding a lot of needless complexity and we’re sure to get complaints about the additional notes…

How about a compromise? We allow the user to select a userstyle.css in settings by having them point to a note with css in it. This way they can have separate css for each device and get the benefit of syncing infrastructure. We would also probably want to allow users to copy and paste css into settings for the users that don’t want configuration notes.

tessus · 2019-05-28T20:05:53.115Z

CalebJohn:

How about a compromise? We allow the user to select a userstyle.css in settings by having them point to a note with css in it.

Yes, this would certainly makes sense. However, I would rather use the link from Copy Markdown link to specify the file than entering the filename manually.

CalebJohn · 2019-05-28T20:12:56.226Z

tessus:

However, I would rather use the link from Copy Markdown link to specify the file than entering the filename manually.

I was thinking we would use some kind of dropdown. But copy markdown link is certainly easier. Maybe we could have a right click menu item "Set Style"

tessus · 2019-05-28T20:24:53.641Z

CalebJohn:

Maybe we could have a right click menu item “Set Style”

Also not a bad idea. As long as I don't have to enter anything manually and the hash is used internally I am good. But I am not the one who has the authority to decide.

sciurius · 2019-05-29T07:24:44.991Z

laurent:

graying out the checkbox is consistent with the rest of the UI.

This may be so, but Joplin seems to be the only tool that uses greyed out checkboxes like this in its UI. And not even then:
scrot20190529092400
All other tools I know use greying out when an item cannot be selected or changed.

zblesk · 2019-05-30T19:20:19.080Z

tessus:

Another thing - I don’t want a notebook called whatever that is visible to me. The notebooks are for my notes, not to configure the application. So, if I wanted to use a different css, I’d have to have a new folder which I don’t want and which is in my way all the time?

exactly this. Those two things are logically different: I should not see configuration in places that are meant for my notes.

I do think think there is a way around this, while still getting to keep all of the advantages: make the notebook a special case, hardcode its name and hide it.

More precisely: imagine you set the name (and I do mean the name, I don't care about the ID) of the notebook to ce8e849c-b6a2-4f19-b2b1-9a4f9b4f57ee, or some other random guid. (Please don't use all zeroes, that's just asking for trouble.)
No need to implement notebook or note hiding - just hardcode that notebook to be hidden.
Also no need for special notes with specific names - Add a menu item saying "Customize CSS" (or maybe "Customize CSS for this particular instance" that will open (or create) a note, with a hardcoded name, in that notebook, and display its contents in a 'edit settings' window/dialog.

That way, it could internally be a notebook for syncing purposes, there would be no issue of it being displayed among your other notes (because the notebook would be hidden) and no issue with specific names (because that'd be hidden as well, and handled when a user clicks on the 'Customize CSS' menu item.)

CalebJohn:

Maybe we could have a right click menu item “Set Style”

I think this is a bad idea from the UX point of view. Having to see an option on every single note, while that option will be used by a fraction of users, for a single note among potentially thousands you create in Joplin, would just be confusing and superfluous.

CalebJohn · 2019-05-31T04:55:16.567Z

zblesk:

That way, it could internally be a notebook for syncing purposes, there would be no issue of it being displayed among your other notes (because the notebook would be hidden) and no issue with specific names (because that’d be hidden as well, and handled when a user clicks on the ‘Customize CSS’ menu item.)

In this case how would we access the css notes from other devices? And what if we want 2 devices to use the same css?

zblesk:

I think this is a bad idea from the UX point of view. Having to see an option on every single note, while that option will be used by a fraction of users, for a single note among potentially thousands you create in Joplin, would just be confusing and superfluous.

I disagree here, this is already the standard on mobile and desktop OS's for setting the wallpaper. I would argue that users are already familiar with these kinds of options and won't negatively effect anyones workflows.

tessus · 2019-06-09T06:06:40.658Z

I think we should create a new topic, e.g. userstyle.css on desktop and mobile or rename this one.

Either way, the sooner we agree on a solution, the sooner we can start implementing it…

nettlebay · 2019-06-10T18:12:02.708Z

Hello! I do not know where userstyle.css file is located. Sorry. I am on Linux Manjaro.

foxmask · 2019-06-10T18:33:34.040Z

should be there https://joplinapp.org/#custom-css

nettlebay · 2019-06-11T14:35:23.571Z

Les notes et paramètres se trouve(nt)* dans (notes & settings are in) : /home/username/.config/joplin-desktop. But no css file in sight! Do I have to create it myself? What is its full content? Thanks you for your help

*il y a une faute de conjugaison. Il manque “nt” à la fin de “trouve”: “Les notes et paramètres se trouvent dans…” (there is a fault of conjugation. Missing “nt” at the end of “trouve”: “Notes and settings are in…”)