Palette Manager -- Feature Complete

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

There is a delete key button already, but it does not create a $:/config-clone. If absolutely nothing is found, it returns an empty value, because #000000 is a valid value.

But I’m not convinced, that it makes sense. I would rather search for a possibility to “merge” or “register” different palettes that come with a plugin.

As I wrote, I think there was a discussion somewhere already. May be on GH


Edit: See [IDEA] - provide a way to extend palettes · Issue #7736 · Jermolene/TiddlyWiki5 · GitHub

Thank you for the update, Mario! May I suggest some design improvements? I think there are too many borders at the moment inside the scrollable area that has borders itself.

I made the styles very specific in order to not interfere with the table preview.

This would also allow to get rid of the empty rows in the table.

palette-manager-design-hack.json (1.5 KB)

That’s interesting. Looks good! Thank you very much.

I’ll take the hints and implement them right now. I hope I can release a new version with the improvements this weekend.

The last change did take much more time as I thought, because if I’m “tinkering” I need to improve this and that … and this … and that … you got it. :wink:

-m

2 Likes

I did just publish Palette-Manager v0.9.2 – It should improve readability according to @telmiger’s suggestion. But I did add several new element-classes for easier CSS definitions.

Have fun!

4 Likes

I did just publish Palette-Manager v0.10.1

  • The main improvement is, that there is no browser reload needed anymore, to use the plugin.
    So it can be used with every online wiki without saving it first.

  • Previews can be hidden now

Have fun!
Mario

4 Likes

Hi Mario,

I just noticed the license, CC BY-NC-ND.

In your understanding of this license, does this mean that I cannot use this plug-in in an in-house documentation project at work, because, even though we’re not selling that documentation, it is a commercial entity creating/using it?

Or could I import the plug-in, make my changes, and delete the plug-in without ever saving it in the wiki? Would that be contrary to the license?

Also, in your interpretation of the No-Derivations clause, I assume that you don’t mean that building a wiki using this plug-in is a derived work – else why release a plug-in? – but what would you consider a derived work? Only a new plug-in based substantially on this code?

Do you think an informed user would share your interpretations? How about a lawyer?

I’m not a lawyer, so I can’t address the legal aspect of your question. However, from a purely technical standpoint, now that @pmario’s PaletteManager uses my wikitext-based color picker instead of the previous javascript-based color picker, you CAN use his plugin “without ever saving it in the wiki”.

Also note that the wikitext-based color picker now recognizes all varieties of RGB color values, including hex #rgb, #rrggbb, #rrggbbaa as well as decimal RGB(r,g,b), and RGBA(r,g,b,a)… and if you import TiddlyTools/Settings/Colors/X11 then it will also recognize all standard X11 color names (e.g., “red”, “blue”, “green”, “Dodger Blue”, “Fuchsia”, “Lemon Chiffon”, “Light Sea Green”, “Mint Cream”, “Papaya Whip”, “Tomato”, etc.)

enjoy,
-e

5 Likes

Yes, I did test it before I asked. It’s possible to do. I’m wondering if Mario thinks that’s compatible with the license he’s chosen. Clearly, as the effect is simply to change some palette entries, which could easily be accomplished other ways, it’s not as though a proscription could be enforced. But I was wondering how Mario thought of that in relation to his license.

I didn’t realize that this wasn’t already possible. I haven’t done much (yet) with color schemes in TW, only a few minor tweaks, and I’m sure I just copied the format already there.

Oh, very nice!