Presenting: TagConfig ~ customize tags directly in tiddler edit mode

Plugins
#17

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!

#18

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,

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.

I think that would be an excellent idea!

#19

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

image

  • 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)
    image
    but in the edit mode, only the real name is clickable, and the direct-icon prefix is not clickable. This is not intuitive
    image

  • 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:
image

results in this tid title:

image
image1047×210 17.7 KB

#20

Hi @twMat,
very nice tool :+1:

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

Any idea?

Thanks, Stefan

#22

Interesting problem. Testing stuff, I note that the width difference between existing link and missing can actually either be wider or narrower, depending on letter!

image
image

So for the only solution I can think of, one would in the <td> with the link, need this

<$link/>
@@.widest <$view field=title/>@@
@@.narrowest <$view field=title/>@@

styled to set italic/normal and font-weight and also float:left; visibility:hidden

While that’s not a huge cost, I’m not sure it’s worth it (?) (Perhaps comparable: In native TW, it is evidently accepted that when the second scrollbar pops out it pushes the whole river. (I go Gah! every time!))

Well, that’s the user choosing to add that arbitrary text though…

in the edit mode, only the real name is clickable, and the direct-icon prefix is not clickable. This is not intuitive

Yeah, I agree this is not optimal. Of your bullets, I actually think this is the most importantn one. I’ll see if I can come up with a solution (…ouff… I fear this will mess with the line-up for the direct-icon + icon + tiddlertitle that took quite some work to get right).

I suspect you have some overwritten stylesheet leftover - ? Check the plugins shadow list and see if you’ve overwritten something, and delete it. (And please confirm here so I know if it actually is something I should look in to.)

As for collapsing white space in the tiddler title but not in the tag… yeah, it’s such a fringe case that I don’t think it’s worth bothering with. I do think it is important to easily insert one space (which does work) but for wider space I think the user has to resort to &nbsp;. Good enough, IMO.

Lot’s a great feedback @nemo - thanks!

#23

The plugin just calls, the core iconEditor though (defined in the $:/TagManager):
<$transclude $variable="iconEditor" title={{!!title}}/>
…which only takes a title as a param.

But I agree, which again speaks for my previous reflection that the standard distro ought to feature a public and general list-picker macro. From what I can tell, the core locally defines several sleightly different instances; one color-picker, another icon-picker, etc.

#24

PNGs are huge in size. I would limit them to SVGs only.

#25

IMO not really worth the trouble, since tag configuration is probably done rarely.
Also table cell properties are inherently hard to control. Table layout is largely controlled by the browser.

#26

IMO you should keep accessibility and keyboard tab-handling in mind. So screen-readers still need to be able to handle tags well. As soon as you start to mess up semantic HTML, that’s getting difficult.

#27

Oh, I wasn’t expecting that!

I agree it’s probably not worth it, esp since as noted, TW as a whole is dynamic with things sometimes moving unexpectedly.

All my testing and example screenshots have been via edits on https://tagconfig.tiddlyhost.com/ - I’ve only now had a chance to install it locally and I don’t see it on my own setup - so that’s good. (But a bit concerning that it’s showing up on the very page promoting the plugin)

#28

Updated!

The main difference is that the clickable area of the button now includes the icons/direct-icons a’la @nemo 's input . Much better. @pmario I don’t know how to test “accessibility and keyboard tab-handling” that expressed concern about. Do you think you could see if there is a problem? (And, if problem, was there no problem in the old version?)
…

Also @pmario - or anyone who can help - I’m hitting the problem that you kindly replied to on gh yesterday where I need to access the tiddler title when current is the draft. This affects the “Used in n other tiddlers” like so:

If you in edit mode create a new tag, it will state "Used in 0 other tiddlers" (good) but if you save the tiddler and reopen edit, it now says "Used in 1 other tiddlers"(bad). I want “other tiddlers” to neither refer to "Draft of 'xxx'" nor "xxx".
This is the current counter:

<$count filter="""[all[current]tagging[]!is[draft]]"""/>

Thank you!

#29

Actually your screen reader accessibility is a bit better than the one of v5.3.7 – Which needs to be improved quite a bit. – So it can stay as it is atm. But it should be improved in the future, once we know what to do with the core UI.

#30

You could use this

<$text text={{{ [all[current]tagging[]!is[draft]] -[<saveTiddler>get[draft.of]] +[count[]] }}}/>
  • saveTiddler … is defined in $:/core/ui/EditTemplate/tags and contains the name of the draft tiddler that is edited
  • -[<saveTiddler>get[draft.of]] … removes the draft.of tiddler from the list, if there is one
  • +[count[]] … should give us the right number now

This works for me. But more testing should be done.

have fun!
mario

1 Like
#31

Hahaaa - I was just formulating a message where I had concluded it wasn’t even possible to get the draft name of the edit view tiddler (unless the genesis macrocall for the whole plugin has the title name as a param). But you found saveTiddler - excellent! Some quick tests do seem to work! Mucho thanko!

Is there any advantage with the textwidget you propose over the countwidget currently used?

#32

No. I did change it, to be able to see the tiddler list values, for easier testing. But if the filter works you can use the count-widget instead.

#33

…and with that possibly last piece in the puzzle, I’m thinking this might just be it for some time now:

Updated!

 - this one all thanks to @pmario

2 Likes
#34

@twMat I only just looked here

Your idea to use an “on click” that is not already in use ie: “The tag pill in the editor” is great. Finding such “unenhanced user interface opportunities” is great stuff. If anyone finds another please share it with the community.

  • We could ask for a change to the core to allow items to be added there via a tag as is possible with the view tag pills. You solution would them be added simply using a tag. eg $:/tags/EditorTagDropdown

You may be aware of my reimagin tags which provides a whole set of tools on all view tag pills including actions - I just added a “remove tag from all tiddlers” item here When a tiddler is deleted, should other tiddlers with that tiddler's name as a tag have the tag removed? - #9 by TW_Tones.

My question

Would it be possible for you to allow your dropdown to be made accesible from the view tagpill?, If not as part of your plugin, such that if installed your plugin I could access the dialogue (or a version of it) and/or could be tagged $:/tags/TagDropdown to add it if desired?

  • There will be an issue with a “dropdown in a dropdown” that may need to be resolved, or simple only use the tagpills dropdown to display your dialogue.

I ask now because I am looking and moving my reimagin tags into a plugin soon, and it would be a nice feature to add.

A simple config item to enable/disable your solution on a wiki may be smart, for read only wikis. ( I see you did)

Love your work

#35

I think that is a great idea. TagConfig currently needs “activation” which injects a macrocall into a core tiddler, which would be better if it could be avoided.

Would it be possible for you to allow your dropdown to be made accesible from the view tagpill?, If not as part of your plugin, such that if installed your plugin I could access the dialogue (or a version of it) and/or could be tagged $:/tags/TagDropdown to add it if desired?

“access the dialogue” - yeah, I could probably externalize the dropdown content into a procedure. I did some quick testing just now but it was not as direct as I expected though. I was not aware of the $:/tags/TagDropdown tag so I’ll take that into consideration. But, my job (as a teacher) starts again in two days after a long summer vacation and I really have to start preparing for it so I won’t get back to this in the foreseeable future. So I can’t tell when I’ll get to this.

I just added a “remove tag from all tiddlers” item

That feature is actually a very good one and it would make sense to include in TagConfig. This is an incentive for me to look closer into the coding again. Again, I can’t tell when though.

#36

if you just allow your dialogue to be called or transcluded I will have a go and share back.

#37

As I said, I did some quick testing just now but it was not as direct as I expected. But do feel free to play around and if you have a good solution I’d be happy to merge it. Please take that through private messaging though.

1 Like