Presenting: TagConfig ~ customize tags directly in tiddler edit mode

[twMat]

TagConfig

In tiddler edit mode, click directly on the tag to get this dropdown:

A configuration affects all instances of that tag.

notes

• I’m particularly proud of the hide feature (finally!)
• direct-icon lets you easily add any unicode character as icon. This actually works for //non-tags// too; the direct-icon displays like a regular icon in front the tiddlers title!
• The superior idea to make the very tag be the button, rather than some separate “config button”, is from Big J himself.
• This all been looong in the cookin… 2014

[Scott_Sauyet]

@twMat

TagConfig

Did you mean for that to be a link? At the moment, it just shows up as a header.

But this looks like a wonderful idea. I’ve never been very happy with the TagManager, and would much rather make these changes this way.

[twMat]

Doh! Corrected Thanks Scott!

[Scott_Sauyet]

It looks wonderful!

This is extremely useful.

Things to consider:

• I would love access to this from View mode as well. What do you think of having view mode displaying two tabs, the current behavior and your TagConfig?
• I know you’ve been involved in recent discussions regarding colors; I haven’t followed closely. But would it be possible to replace the palette icon with a color swatch for the current color?
• The icon selector does not act quite like a normal drop-down/SELECT. Would it be straightforward to hide the popup when a selection is made? Because that popup is long, the actual text field is hidden from view, and its not clear on clicking that a change has actually happened.

But don’t get me wrong, I love this, and will be happy to use it just as is!

[twMat]

Thanks!

@Scott_Sauyet

I would love access to this from View mode as well. What do you think of having view mode displaying two tabs, the current behavior and your TagConfig?

Aha, two tabs in the dropdown in view mode - that UI idea had not occured to me. I need to let the idea sink in.

A main ambition is to make TagConfig as non-intrusive as possible which is why using the otherwise unused edit-view tag as the button is so brilliant. A (personal) concern is also how such viewmode tabs would work visually with my add-sibling plugin. But overall I’m not quite sure that the configuration of a tag is performed “that much” to warrant it accesssible from view mode - ? I, as you, am not happy with the native Tag Manager - it is just too distant and non-contextual! But having to (merely) enter edit mode to access TagConfig feels balanced considering how rarely the configuration of a tag is done. Do you disagree? What’s your workflow?

I know you’ve been involved in recent discussions regarding colors; I haven’t followed closely. But would it be possible to replace the palette icon with a color swatch for the current color?

After googling “color swatch” I’m stisl not quite sure how it differs from a color palette - or is it perhaps selecting a color and thereafter its nuances are presented for refined selection? I’d welcome that but don’t quite know how to implement it. Also, I’ve tried to reuse as many parts of the core as possible by means of \import $:/TagManager (to keep my plugin small) so the seen color picker is the same as in the Tag Manager. (Maybe the push should be for a better color picker in the core?)

The icon selector does not act quite like a normal drop-down/SELECT. Would it be straightforward to hide the popup when a selection is made? Because that popup is long, the actual text field is hidden from view, and its not clear on clicking that a change has actually happened.

Good point! I wonder why it persists. In the implementation I’m using a tc-popup-keep for the TagConfig dropdown itself. I’m guessing this ripples down to underlying popups - ? Also, the \import $:/TagManager lets med call <$macrocall $name="iconEditor" title={{!!title}}/> so I’m not sure how to control the behaviour of it…? Suggestions are welcome.

[Scott_Sauyet]

@twMat

But having to (merely) enter edit mode to access TagConfig feels balanced considering how rarely the configuration of a tag is done. Do you disagree? What’s your workflow?

That would not bother me. My suggestion is because I write wikis often for people other than myself. Generally the bulk of my users see only a read-only view. But some of them are editors, often with no previous TW experience. So discoverability is always important. The easier it is to see that they can change colors and icons, the better. But this is a minor thing, very minor.

@twMat

After googling “color swatch” I’m stisl not quite sure how it differs from a color palette - or is it perhaps selecting a color and thereafter its nuances are presented for refined selection?

I was simply suggesting replacing the palette icon in the U buttonI with a small square of the selected color. This mockup makes it a little large, but it should be clear enough what I mean:

@twMat

Good point! I wonder why it persists. In the implementation I’m using a tc-popup-keep for the TagConfig dropdown itself. I’m guessing this ripples down to underlying popups - ?

I haven’t dug into the implementation at all, and have little experience with TW popups. But I’ll try to look soon to see if I have any ideas.

[twMat]

Updated!

Some cool modifications have been implemented, most notably @Scott_Sauyet 's color swatch idea (a significant improvement!) and a introduction of a user made library for direct-icons and…pretty big news:

You can now use direct-icons as a substitute for icons for any tiddler - tag or not. The direct-icon shows up in front of the tiddler title like a regular icon. (OP is updated to reflect this.) This feature could be a plugin in itself, so you’re getting 2-in-1 with this deal! The plugin is worth double of what you paid!!!

The UI still has some inconsistencies (priamarily the different types of buttons and the different dropdown UI’s) but I’d say the plugin fulfills its mission pretty well.

…

Help is still needed for the problem with refresh when typing a colour…

[nemo]

@twMat

direct-icons

What is the logic by which the order of icons and direct-icons are displayed?

I ask because within the TagConfig menu, I’m seeing direct-icon first, but in the title of the tid when opened, I see direct-icon second

(these screenshots taken from a single view of your TagConfig v0.0.7 page (two screenshots only to avoid all the irrelevant space between).

Is it easy to make these consistent? (tbh, I’m not even sure which way I think is more “correct” - the “direct icons” is a new concept to me and I’ve not used it yet)

[EricShulman]

@twMat

Help is still needed for the problem with refresh when typing a colour…

Try using a separate $:/temp/... tiddler for that $edit-text widget. That way, the tag color doesn’t change while you are typing. Then, wrap that $edit-text widget in an $eventcatcher that responds to a $change event, which is only triggered when the input loses the focus due to user activity (i.e., clicking away or tabbing to another control)

Something like this:

<$let temp=<<qualify "$:/temp/tagconfig/color">>>
<$eventcatcher $change="
   <$action-setfield $tiddler=<<thistag>> color={{{ [<temp>get[color]] }}}/>
   <$action-deletetiddler $tiddler=<<temp>>/>
">
<$edit-text tiddler=<<temp>> type=text field="color" default={{{ [<thistag>get[color]] }}}/>
</$eventcatcher>
</$let>

Let me know how it goes…

-e

[Mohammad]

I suggest that the tiddler? in UI might be redundant since, in the official tag dropdown, an italic title already indicates a missing tag tiddler. So, you use the same philosophy.

[pmario]

Congratulation! – The “god father” of useful and good looking tools, that do not need a restart. I love it!

• As @Mohammad wrote, I think the tiddler? yes / no is redundant.
• May be a tooltip for the tiddler link, may be enough. eg. “foo bar - is a tiddler” or “foo bar - has no tiddler” or something similar

Is it possible to give $:/plugins/TWaddle/TagConfig/main a code-body: yes field, so it’s easier to see the implementation details.

• There is no license atm
  • If you want BSD you could do something like this: tocP — Parent based - Table of Content
  • 2 lines of code. No need to include the full license text. Only the link to the license.
  • And the copyright auto-updates the date year.

---

I think the color: hidden trick is a bit brittle, but I do like the implementation idea behind it.

It’s brittle for 3 reasons:

a) If the color field is set: the tag becomes visible
b) The core UI color-field “hides” the info - “pun intended”
c) If there is a color and the tag is “hidden” the color setting is lost

IMO they are troublesome.

• So I would suggest to use hide-as-tag: yes – or something similar.

We already have a hide-body field in tw-com as shown in: TiddlerFields

---

@twMat - Would you consider it to be a core-plugin in the future?
@jeremyruston - Would you consider it to be a core-plugin in the future?

---

Would you consider to give your “settings” it’s own “higher level” tab in the settings, similar to the one I did at: https://wikilabs.github.io/ – So the settings tab becomes less crowded.

Only a suggestion, that you can ignore.

[twMat]

Thank you everyone for feedback! - I’m working on implementing a lot of it accordingly.

@pmario - that’s certainly flattering compliments! and thanks for valuable feedback!

As @Mohammad wrote, I think the tiddler? yes / no is redundant.

ok, ok, ok… I’m buckling under the group pressure.

code-body: yes

sure

license

I don’t think I’ve ever used a license because I figure people are free to do with it as they wish… but I admit it would suck if someone somehow copied it and then he/she put a license on it that somehow blocks my let-go intention. Is that a risk, even when I created it previously?

brittle … core-plugin …

I would love for the functionality of several of my plugins to be in core plugins but, apropos the brittleness, I think seveal of my plugins can merely be seen as proofs of concepts because there’s no chance they live up to the official TW coding standards. In my plugins I try to avoid touching core shadows so I use methods to circumvent this that often rely on a lot of css hacky trickery. For example…

…in this plugin, I try to keep the plugin small and the code simple, so I reuse the color-picker macro via \import $:/TagManager… but to “exchange” the color-picker buttons “palette image” for the “color swatch”, I’m hiding the image and adding a css :before element colored with {{!!color}}.

That’s just one of several examples in this plugin. So, while usable, it’s a PoC.

The adding of hidden in the color field is another hack, but maybe I can improve this with your ideas.

Would you consider to give your “settings” it’s own “higher level” tab in the settings,

Yeah…positioning plugin settings is always a bit of a problem; If I understand you right, you propose a tab Controlpanel > Settings > TWaddle - yeah, I guess I have enough of public plugins for it to be justified. But a consequence is that users need to either know which plugins are TWaddle-plugins or they need to search around. (Side note: There should be a separate and native tag under Settings that lists all settings that the user has modified + the ones he wants immediate access to. That’s one reason for this gh proposal)

Again, thank you, everyone.

[twMat]

Updated - but very little of the feedback has yet been implemented.

One significant update is that it is now works for titles/tags with double quote characters (") - but not for single quote ('). CSS lets you use either one, but not both - [data-tag-title="This "is" why!"] (and triple """ enclosure is not a css thing). I urge you to update because a previous bug made it so that if you had any tiddler titled with the forbidden character, then the whole thing didn’t work.

[DaveGifford]

At the end of the year, when people are listing their favorite new plugins and tools, I guarantee you this will be #1 or #2 in my list and that of many others. Helpful tools placed right at the point where they are needed. The plugin I didn’t know I needed.

[Scott_Sauyet]

@twMat

now works for titles/tags with double quote characters (") - but not for single quote ('). CSS lets you use either one, but not both - [data-tag-title="This "is" why!"]

You can get around this restriction by using escapecss, replacing each <<currentTiddler>> in the stylesheet with {{{ [<currentTiddler>escapecss[]] }}}, or moving it into a procedure, as I do in this:

$__plugins_TWaddle_TagConfig_stylesheet.json (2.1 KB)

The output CSS looks like this:

[data-tag-title='cos\'\ I\ say\ so'] .tag-config-table button:has(.tc-image-palette):before {
	background:Fuchsia; x:cos' I say so;
}

[data-tag-title='This\ \"is\"\ why\!'] .tag-config-table button:has(.tc-image-palette):before {
	background:LimeGreen; x:This "is" why!;
}

(Is that x selector a debugging artifact? )

[twMat]

Updated

The vertical alignments of the icon and the direct-icon should look good now. Not that anybody complained (I am a bit nervous that such things could be browser dependant though…)

Thanks to @EricShulman we can now type a color without refresh! I could not have solved that myself!

And @pmario 's handling for “hidden” is definitely an improvement. I’ll get to the Controlpanel tab at some later stage. I figure that such a designated tab is an opportunity to add general (and relevant) stuff about ones plugins.

@Scott_Sauyet - I didn’t yet try out your “quote” solutions that you just posted but that sounds very hopeful! Much appreciated.

[twMat]

Ha! - @Scott_Sauyet 's thing with escapecss made me chuckle; I had really repined over not being able to solve the “quotes issue” and had given up… and here comes Scott to save the day.

Updated!

Frankly, it’s pretty darn good now! But here are some nitpicks that I’m not 100% satisfied with but I’m not sure I’ll do anything about them:

• it is not obvious that the user should click on the “swatch” color-picker button but hopefully the line-up with the other clickable things is a clue.
• I had to tweak the position of the dropdowns, not only for the only dropdown I created, i.e the direct-icon dropdown but also for the other. Hopefully they look the same across browsers.
• The “direct-icon” dropdown only sometimes retracts when clicking on the dropdown (intending to mark+copy an icon) - anyone else noticing this?
• To have the color and icon dropdowns retract when I open the direct-icon dropdown, I was surprised to have to explicitly define actions to delete their state tiddlers.

…these last three bullets make me wonder if it would make sense for the core to feature a public list-picker macro? It seems the core has a few separate implementations and users need to define their own. That’s why I cheated with the direct-icon dropdown! - ideally I’d call some “picker macro” specifying if it should be a vertical list (like tag dropdowns) or horizontal (like the color-picker) and what field the selection should end up in, and what tiddler to fetch the populating data from (I was surprised to find the color-picker containing a hard coded list of colors).
Thoughts on this - anyone/everyone?

Thanks!

[Scott_Sauyet]

@twMat

it is not obvious that the user should click on the “swatch” color-picker button but hopefully the line-up with the other clickable things is a clue.

I think the change in the cursor helps when hovering. It acts like the two drop-downs below it. If you added this behavior to the checkbox above, it would be even better:

.tag-config-drop-down input[type="checkbox"] {
  cursor: pointer;
}

But my experience has been that such color swatches often are clickable, so I personally would certainly just try doing so,

@twMat

Hopefully they look the same across browsers.

I don’t know if they look the same browser-to-browser, but inside Brave/Windows and Firefox Dev/Ubuntu, they look consistent on the page.

@twMat

these last three bullets make me wonder if it would make sense for the core to feature a public list-picker macro?

I think that would be an excellent idea!

[nemo]

This is looking better all the time!

Further notes from my testing just now, roughly in increasing importance (to my thinking)

• When a tid doesn’t exist and is rendered italic, and then ‘hide’ is clicked, that generates the tid and it changes to non-italic. This change in font makes the name a little wider and so pushes the whole menu to be wider. From a using-the-UI point of view, this feels a little glitchy, esp since further click/unclick doesn’t change anything.

• direct-icon … because this is arbitrary text, it could make things confusing if used poorly. Obviously can’t handhold users for everything, but this feels wierd somehow

• secondly, still on direct-icon. When it’s set (and using a contrived-length direct-icon text for demonstration purposes here), the tag pill is fully clickable (as you’d expect)
  
  but in the edit mode, only the real name is clickable, and the direct-icon prefix is not clickable. This is not intuitive
  

• finally, still on direct-icon - the influence of direct-icon+icon on the tid title is now weirder than before - with the direct-icon text showing up twice (and whitespaces collapses too, as distinct to the tagpill view of the same text)

Thus this direct icon:

results in this tid title:

[StS]

Hi @twMat,
very nice tool

I’d like to limit the icons to png files only

Any idea?

Thanks, Stefan