Wilk-tweaks -- Issues: CodeMirror CSS and Tools Sidebar Tab is missing

#1

@vilc — These issues are related to: Wilk-tweaks, my collection of TW tweaks, settings, styles, and palettes

Code mirror styles: use the !important setting, wich I personally think is toxic.

It can easily be changed to the following CSS, which does the same thing without !important

.cm-s-tiddlywiki div.CodeMirror-selected {
	background-color: <<colour tag-background>>;
}

image

The Tools Sidebar is gone

It seems you removed the tag: $:/tags/SideBar from $:/core/ui/SideBar/Tools. I’m not really sure why?

It seems you did edit the tiddler in a way that is not according to “best practice”. eg:

<$let tv-config-toolbar-icons=yes tv-config-toolbar-text=yes tv-config-toolbar-class="">

Removing the quotes for yes is error-prone, if inexperienced users copy / paste the code. So I do suggest that you the following syntax instead:

<$let tv-config-toolbar-icons="yes" tv-config-toolbar-text="yes" tv-config-toolbar-class="">

There are some other things with the Tools-sidebar, but I need to investigate it further.

I think there is room for improvement.

-mario

1 Like
Wilk-tweaks, my collection of TW tweaks, settings, styles, and palettes
#2

@pmario thanks for the comment!

CodeMirror CSS

I was aware that !important is problematic, I simply didn’t find time yet to figure out how to do this properly. Thanks for posting the solution!

Tools Sidebar

I removed the $:/tags/SideBar tag from $:/core/ui/SideBar/Tools intentionally. I rarely use the tools that are not in the Page Toolbar, and when I do, I like the compact UI of the dropdown from the chevron more than the tools tab. This also leaves more space for my custom tabs, like Starred. I can put it back in place if the current layout is confusing for users – is this what you had in mind? I think all the tools that a viewer of this wiki could need often are in the Page Toolbar already.

Regarding the contents of $:/core/ui/SideBar/Tools, I don’t recall ever editing it, other than removing the $:/tags/SideBar tag. I have created the wiki on TiddlyHost some time ago on v.5.2.7, and updated it to 5.3.0 yesterday.

But I have checked right now and the last changes to $:/core/ui/SideBar/Tools are from 6 years ago, so its not that. I need to take a look at it.

Coincidentally, today I have discovered an issue with $:/core/ui/EditorToolbar/transcludify – in some of my wikis it used the same non-quoted parameter syntax, which in case of prefix={{ caused the button to fail (but interestingly only on external core wikis). I also do not recall ever modifying this tiddler, and if so, then certainly not removing quotes from parameters. Right now I don’t have any idea why such a thing would happen, it doesn’t seem logical that TH or some plugin would randomly remove quotes and reformat some system tiddlers. Thanks for pointing it out.

#4

May be you did experiment with the SideBar/Tools and then decided, to remove it. And the “old” experimental code is still there.

It seems you did not want to change to “Tolls” tab content,

  • the easiest way to fix it, is deleting it.
  • Then the core shadow tiddler will take over agsin
  • Then remove the “$:/tags/SideBar” from the shadow. So it will be gone.

I personally would prefer the Tools sidebar to be there. … May be there can be an option to “disable / enable” it in the ControlPanel → Settings tab.

BUT … The Tools toolbar should be removed without creating a “real tiddler” that withstands future updates. → Thinking.

-mario

#5

@vilc … You did mention the Palette Manager edition. I’m just curious. Did you only create your 2 new palettes or did you also improve the other existing core palettes at your edition?

#6

@pmario I have created the two Graphite Light palettes using your Palette Manager Plugin (big thanks for that of course), but I didn’t change anything in the core palettes. However, I did isolate some CSS from Palette Manager Plugin that makes the input fields look nicer, see here: https://wilk-tweaks.tiddlyhost.com/#Text%20input%20style.

Since you’re asking, maybe you’ll be interested in some of my ideas regarding the palettes:

I’m planning to improve those two light palettes (there are some missing colors, e.g. diff highlighting) and create two analogue dark palettes using the same IBM Carbon Design guidelines (as far as it is viable in Vanilla Theme and current palette mechanism).

I also had an idea of using the Graphite palettes as a “rig” to quickly create new palettes by defining only a few colors, intention similar to this demo by cdruan: [IDEA] Tools for manipulating colours and palettes · Issue #5236 · Jermolene/TiddlyWiki5 · GitHub
but without having to create a completely new theme and palette system. My Graphite palettes use only 12 grays (this including white and black), 2 or 3 shades of blue for primary and other accents, and occasional yellow or red. My idea was to expose those 20 or so colors in the beginning of the palette, and refer to them in the rest of the palette with color macro. The shades of the background and main accent colors could be interpolated given the edge values and one in the middle. Creating a new palette in the simplest form would be a matter of assigning one “background” color (from which the “gray” spectrum would be interpolated) and one “accent” color (from which the other accent colors would be interpolated). And then optionally other colors could be defined, e.g. hand-adjusted background spectrum, or changing the yellow/red accents.

Advantages:

  • Works with current Vanilla theme and palette system.
  • Allows granular control like current palettes if needed, but does not require to go through all the colors for a good coherent look.
  • Far easier to introduce than cdruan’s solution, and so within my ability to make it.

Disadvantages:

  • No idea how well the interpolation of background colors would work, especially for a more saturated or darker spectrum like in the core Desert Sand palette. But then still, even manually adjusting the 12 background colors would be easier than with the current system.
#7

Yea the current system has some room for improvement. IMO it’s basically the lack of understanding, where the colours are used.

That was the reason why I did create the Palette Manager edition, which connects UI elements with the colour definition.

I think there will be many users, which would like to have dark themes.