Palette Manager -- Feature Complete

Intro Video

Please Like and Subscribe!

Function Overview

  • Cloned palettes have an origin field now, that allows us to have an “undo-button” per color changed
  • New Undo button if a color is different to the shadow palette
  • There is a new “Search input” to filter based on colour names
  • There is a new “Focus button” that sets the filter input to the first element of the colour names
    • eg: alert to focus on the alert notification element
  • If TW <<colour xxx>> macro is used the color-widget will show the resolved colour
  • Every colour-group has a preview element now
  • It’s straight forward to create your own previews
    • if the colour is eg: alert-muted-foreground
    • the preview tiddler is named: :/palettes/preview/alert-muted-foreground which will be shown right below the colour
  • The palette manager can be heavily customized. See Customize the Palette Manager

Known issues:

none

Demo

Demo: Palette Manager — Preview

Have fun!

Feedback is very welcome.
This code should have a chance to be part of the core in the future.

17 Likes

Looking fantastic @pmario certainly worthy of core inclusion.
Some new users are really going to be influenced by the easy of customisation and even hardened users will appreciate the WYSIWYG nature of this. Thanks for your effort.

Feedback by way of a Question;
Snag_40cea51

  • I am curious why the preview shows the grey Default button background but the picker does not, and other elements. I am not asking for a solution necessarily but at least making it clear why this differs, in some ways showing its black is misleading. If perhaps it means “undefined” perhaps there is a better way to indicate as such without suggesting its black. This comes from the core I believe, not your Palette Manager.

Love your work

This is really nice tool, thank you, @pmario. I tried it in action inside the demo, here are some observations from “final user” and they are mostly about how the manager appears, so please feel free to ignore them.
It’s very good to have Reset button and the colour square next to it, as the customization can go wrong very quickly, I used it immediately, and also I created multiple clones to save intermediate versions. Previews help a lot. The possibility to search an element to change is also handy.
First I went on clicking around and then watched the video. After watching, everything became quite clear, but before I had some doubts.

  • The ‘colour name’ help text in the search box was a bit confusing, as I was typing “red” or a hex code to search elements (should I call them elements?) that use that colour.
  • It would be more comfortable for me to have more visible elements first in the list and less visible after and not in alphabetical order, like river background, tiddlers background etc. And also to have some kind of headings, like River, Alerts, Buttons and quick way to jump there.
  • The preview area, I think, could be emphasized with different background colour or in some other way. In some cases, I was confused about where the setting ends and the related preview starts.
  • In the external-link area, the colour for external link background is inherited and is shown as black, while actually it is not, there are other cases similar.
  • For me personally, foreground is not a very clear term. I guess it comes from CSS documentation, and it is good to see the name of the element, but the text on the left of the picker could be something like Text on buttons button-foreground.

Great tool, thank you very much!

1 Like

I’m not 100% sure, what you mean here but I do guess. The palette doesn’t contain any value. So it uses the default settings from vanilla CSS.

The manager only uses palette settings and has no idea about CSS settings. … That’s a problem, how the whole stuff is created at the moment.

There have always been inconsistencies.
The new preview elements only make it clear now, where all the problems are …

1 Like

Ah – I see. That’s right. It’s the palette “colour name” … So “red” wouldn’t find anything. … only he elements like: “alert”, “background”, “highlight” and so on can be filtered

I think I change the text to name - eg: alert, which may make it clearer out of the box

hmmm, That should be even harder with the default manager at tiddlywiki.com, where you don’t have any visual clue what is changed at all.

May be a bit more docs will help, which explains the different elements of the new UI … So 3 or 4 screenshots with some info and a link to a video may do the trick here

Everytime I do suggest custom ordered lists, that are sorted by “relevance” or “simple to complex” it is rejected. The only default sort order Jeremy approves for the core is alphabetical.

It should be possible to create a custom sort order by “hacking” the palette tiddler. It’s a text based data-tiddler, so it should be easy to make a clone and copy paste the different groups.

Groups are created by the first colour-name element like eg: alert or button and so on.

So if custom sort order is a thing, I think I will go with a dedicated edition. … Since it is already started now, it only needs to be extended with some more docs …

Since I control it, I can do what I want.

You are right. I did try very hard to create a view where the setting and the preview area clear to see. …

The problem with a different background colour for the preview area is; that it will be part of the palette settings … So it’s easy to mess it up …

I was thinking about a thicker left and right border “bar” that may cover the preview area … Some more testing will be needed.

Thx for the feedback

inherited is a native CSS value, which the palette colour macro can not resolve, since it doesn’t know about it at the moment. …

With the new colour-widget, which is part of the plugin, it should be possible to resolve such edge cases. …

BUT it’s a million times easier to remove such values from the palette settings, than create an algorithm, that is able to resolve it.

At the moment it’s possible to handle the <<colour xx>> macro only.

It’s completely out of the scope of this project, which started as a way to add the preview-elements. …

Adding the “filter” and the new colour-macro resolver did already “blow up” the “cost” to probably 100+ hours. …

But I think as the project is now, it adds real value and give us the possibility to create consistent and high quality palettes, which isn’t the case at the moment.

1 Like

That’s right and the Palette Manager as it is now makes that obvious. There is a lot of potential for improvement. IMO the new UI gives the users the possibility to see and articulate those problems.

So I think that’s one of the biggest wins of the whole effort, which makes me proud.

1 Like

Hmm, I think that makes sense if we consider TW as a programming environment or a language. It would be strange in fact to ask, say python, to change their language reference and put the most used modules first, however the alphabetical order looks too strict.

To be honest, I never used it. For those small changes I did for now, I searched for “applying custom style” in documentation and went with writing css for classes discovered with inspect element.

Hi ! Here’s a neat thing I’ve discovered today, maybe this will give you or someone else some ideas for improving the Palette Manager’s UI even further : a named color wheel

https://arantius.github.io/web-color-wheel/

Maybe a color wheel like this could be useful to display a color palette ?

2 Likes

Hi Mario,
I tried this tool today and found it very usefull, thanks a lot!

Some feedback after the first iteration over a palette:

  • great stuff: Cloning palettes, restoring original values, the improved colour macro (colour-picker-resolved) and the Manager in a new window are really useful and should be integrated into the core as soon as possible.
  • new window: there is a typo in the link text “Open the Palette Manager in a new Window” (window).
  • background colour: For some previews, background colour seems important to me. My adaptation of the previews (see my demo page) is not the most elegant — I am sure you will find a better way — but it shows what I mean.
  • link examples: tiddlywiki.com alone is not a good example, as for many users it will always be shown in the visited variant.
  • Plugin contents: You included $:/themes/tiddlywiki/vanilla/base in a modified version. It seems to be an older one. I replaced it with the v5.3.3 theme from tiddlywiki.com and the Save changes button displayed correctly again. – Could you perhaps explain in a few words, what kind of changes in the theme would be necessary?

In my testing and demo page, I apply a CSS hack to ensure better readability of editor buttons. Thus I had to add

to your $:/palettes/preview/tiddler-controls-foreground-selected in order to see the effect of my own hack. – I would not expect the previews to foresee that, of course. But in general I would say: more relevant context makes previews more valuable and reliable.

Alle the best, Thomas

Thanks for this input. I’ll have to remove the changes there and move the palette-manager stuff into it’s own stylesheet, so vanilla stays untouched. – I’ll publish a new version of the Palette-Manager Edition soon.

The vanilla changes have been there since the original PM version was intended to be merged into the core, which did not happen, due to the complexity of the code.

I did create a new issue: [BUG] PaletteManager - reset overwritten vanilla CSS · Issue #147 · wikilabs/plugins · GitHub

2 Likes

I do not have time to fully reply.

Just to say … @pmario as always your (always on-going) attention to details is the nearest thing to a miracle. Your pallette tool is brilliant.
(Almost as good as Cuban music.)

I have already said I want to have your babies.

TT, x

I did upload a new version v0.9.0 which is a big version jump and should have an improved vertical separation for better readability.

V 0.9.0 - 2024.01.12

  • Big jump in the version number, because the functionality was stable for a long time now
  • The plugin uses $:/plugins/wikilabs/palette-manager/styles now
    • This style tiddler also contains some TODOs to improve vanilla/base
    • base/vanilla theme tiddler has been removed from the plugin. So it’s not overwritten anymore
    • $:/_tw5.com-styles has been removed from the plugin. So it’s not overwritten anymore
      • Problems previewing the “Big Green Download” button has been fixed upstream
  • improve serch help text
  • Improve vertical separation in preview editor
  • Improve help text in 17 preview tiddlers

have fun!
Mario

2 Likes

Mario, Because of your new release I thought I would revisit your palette manager and it is great. I tend not to play with palettes as much as I could but there are few colours I usually want to change, possibly the most annoying to me is a red code-foreground, (single backticks) I change it to black.

I thought I would investigate using the color macro and color names using 5.3.x release features. Such as using it for attribute values, I am still working through that.

In the process of doing this I noticed in the color Macro documentation it says this;

If no such entry exists in the current palette, the vanilla palette is used instead. If no such entry exists in the vanilla palette, the system looks for a configuration tiddler with the title $:/config/DefaultColourMappings/<colour-name> and transcludes the colour from the text field. This enables to plugins to ship defaults for colours that are not present in the core palettes.

In particular creating the tiddlers $:/config/DefaultColourMappings/<colour-name> and I realised perhaps you could add a save and delete button to each color name in the pallet manager, to create/delete such default colour mappings?, perhaps tagging them with the current pallet name to group them.

  • This would allow people to generate single color pallet changes they can include in a plugin or distribute separately form the whole pallet.
  • Your pallet manager would then also be aware of this override mechanism and make it visible.

What do you think?

[Edited] I just found $:/config/DefaultColourMappings/<colour-name> will not override core colornames, only provide additional color-names.

  • Is there still a way we could save out individual color-name override values independent of the palette?

So you basically want a “clone”-like function, that removes the key from the palette.

The colour-macro is defined at: Palette Manager — Preview

\define colour(name)
<$transclude tiddler={{$:/palette}} index="$name$"><$transclude tiddler="$:/palettes/Vanilla" index="$name$"><$transclude tiddler="$:/config/DefaultColourMappings/$name$"/></$transclude></$transclude>
\end

So if there is no index in the current palette and no index in vanilla for “exsinting keys” it should be possible to overwrite “core” values.

I think there has been a discussion about “merging” 2 palette tiddlers, but I cannot find it atm.

Yes/No

See colour Macro

On a given pallet item in the pallet manager, a button to create (or delete) the tiddler $:/config/DefaultColourMappings/<colour-name> containing the color value and tagged with the current pallet name (or something else).

I understood these will override even the current palette settings.

  • I have discovered this will not override the Pallet but provide a “last resort” value, if not found in the pallet :frowning_face:

If it had;

One can then drag and drop this tag on any wiki to transfer the set of overrides.

By also providing a delete button in the pallet manager the user can see an override exists and remove it.

  • For example I would create $:/config/DefaultColourMappings/code-foreground with a value of #000000
1 Like