[IDEA] Plugin sourcing, find out UI element is caused by which plugin/tiddler

[linonetwo]

Is your feature request related to a problem? Please describe.

I have installed tons of plugins from the library, and I sometimes don't know a button is from which plugin. And sometimes I do know, but to find the readme of that plugin, I have to open plugin list and ctrl+f for plugin then click on it.

Describe the solution you'd like

Automatically add data-plugin-name to a UI element if it is generated by a plugin.

Then we can have another plugin to read that data field in the dom element, and add a context-menu button / tooltip to open plugin tiddler or plugin readme, even the plugin website.

Describe alternatives you've considered

Set up a standard (and toolbox) of this kind of metadata, and recommend plugin authors to add this to the dom element generated by their plugin.

Additional context

Many games have this feature for the mod content. If an item is added by a mod, it will have some clue in the UI to let the user know this is caused/added by the plugin. So the player will know he should go find the mod author to raise an issue, instead of going to the game's repo to rise the issue (if there is a bug that occurred).

[CodaCodr]

Just FYI: I do this a lot, even with regular HTML/wikitext if the structure is complex enough to warrant it. Here's a typical use of $eventcatcher

<$eventcatcher selector=".sv-targeted-link" $click=<<sv-targeted-link-actions>> $contextmenu=<<not-used-yet>> tag="div" 
  class="E:CLICK t:popout-section-selector macro:display-current-chapter-sections actions:sectionview-links:sv-targeted-link-actions">

When viewed in DevTools, I can see t: the tiddler it resides in, macro: the macro it resides in, actions: the tiddler and macro holding the actions.

If plugins did that too, it could save a lot on debugging/tracing time.

[linonetwo]

@CodaCodr what does t: mean? Does it equal to t="popout-section-selector" ?

I think this could also be achieved by adding data-t="popout-section-selector" in dom element, and use another inspector plugin to read this data field.

[kookma]

Just FYI: I do this a lot, even with regular HTML/wikitext if the structure is complex enough to warrant it. Here's a typical use of $eventcatcher

I am interested in using this specially for debugging! Is it possible to provide a working example?

[pmario]

Automatically add data-plugin-name to a UI element if it is generated by a plugin.

If I create UI elements with widgets and I have to assign a class for styling I do use eg: wltc-some-class where the wl prefix indicates that the class is created by one of my wikilabs widgets. ...

I also use wltm- wltv- prefixes for core equivalents of tm- and tv- ... This helps me debugging my own stuff.

---

One problem I see is, that there are plugins that only change the TW default settings eg: My multicol-dropdown plugin only contains CSS changes that overwrite default settings.

---

An other problem will be wikitext macros, that will be part of plugins. The data-attribute will be part of the wikitext and not hardcoded by JS.

So users will copy paste the code if they need it and they won't change the data-attribute .. So there will be a lot of "false positives" over time, which will make the info bloat and pretty much useless.

just my thoughts

[pmario]

I think it's not only a problem for plugin authors, it also is a problem in the core itself. ... If you need to track down, where an UI element comes from you are basically "reverse engineering" the core UI.

So if the core rendering mechanism would automatically add better info to the created elements it will automagically also help every plugin author

[pmario]

I think the transclusion variable may be a good candidate here.

If we implement a "tv-debug" variable that can be set globally eg: tv-debug = "UI" we could add a function to the core widget class that will add the transclusion-variable to a data-UI attribute to every visible UI element.

By default the variable will be tv-debug = "no" because it may have performance implications ... It would be possible to make tv-debug = "UI X Y Z" ... So it would be expandable if needed.

just an idea

[CodaCodr]

100% agree with @pmario and that's the reason why I do it. Although TW is a lot better these days at not creating so many elements, there are still many opportunities to make the "reverse engineering" of the output easier.

@CodaCodr what does t: mean? Does it equal to t="popout-section-selector" ?

Yes, in that example. The whole point is to know where the $eventcatcher came from. (Much like my reply on TW Talk about call site)

[CodaCodr]

@linonetwo Perhaps these images will help...

[CodaCodr]

@pmario

just an idea

Damned good idea. I wouldn't need this:

[CodaCodr]

@linonetwo I think you should combine your proposal with @pmario's proposal and reword the title of this issue accordingly. IOW, I think we can all agree, this is not just about plugins/widgets...

🤔

[linonetwo]

@CodaCodr I think using transclusion variable means we can locate UI element in specific tiddler, right?

[linonetwo]

In electron/nwjs environment (TiddlyGit / TiddlywikiDesktop ), we can add custom context menu, so if there are sufficient data, we can let user use context menu to jump to the source tiddler of UI element.

[Jermolene]

Thanks @linonetwo

Automatically add data-plugin-name to a UI element if it is generated by a plugin.

How would that be done automatically?

I think the transclusion variable may be a good candidate here.

If we implement a "tv-debug" variable that can be set globally eg: tv-debug = "UI" we could add a function to the core widget class that will add the transclusion-variable to a data-UI attribute to every visible UI element.

By default the variable will be tv-debug = "no" because it may have performance implications ... It would be possible to make tv-debug = "UI X Y Z" ... So it would be expandable if needed.

just an idea

That's an interesting idea. Minor detail is that I would prefer tv-debug-ui=yes rather than having to test for a token in a list. It would also be an interesting challenge to unpack the data in a usable form. I think it would be worth going ahead with a PR.

[AnthonyMuscio]

I applaud consideration of such debug tools, but as someone who does a lot of "reverse engineering" in tiddlywiki, I do have tools that help, and we could have an installable debug plugin.

• Toggle on or off such things in this thread, especially if they increase file or memory use
• Provide a complementary tool set, including smart search tools eg;
  • Search for macro definitions, variable references etc...
  • results that address precedence eg; last CSS selector, redefined variables/macros etc...

[linonetwo]

• Toggle on or off such things in this thread, especially if they increase file or memory use

Maybe similar to https://bit.dev/

So @AnthonyMuscio do you already have code or demo, any inspiration will help.

[pmario]

Have a closer look at thisTiddler variable for debugging

<<New in: 5.3.0>> The thisTiddler variable is set by the $transclude widget to contain the title of the tiddler that was transcluded. This means that within transclusions thisTiddler will contain the title of the transcluded tiddler. It is not affected by macros, which means that within a macro thisTiddler will contain the title of the tiddler from which the macro was invoked. Intermediate, nested macro calls are ignored.

[quote redacted]

[AnthonyMuscio]

So @AnthonyMuscio do you already have code or demo, any inspiration will help.

My comment was intended to apply to the features discussed in this thread, not so much to present new ideas for debug. I do have a range of tools, as do others, to support debug and other information but not directly related to this topic.

• I am suggesting there is value to bringing a set of tools together but perhaps it is best delt with in its own thread.