RFC Ghost/Meta tiddlers

Developers
#1

First I would like to reserve the name Ghost tiddler for this specific application, or if not adopted my own use later.

Background

Folks an often used mechanisium by plugin and solution designers and even in the core, is to use an external tiddler to store information such as the visibility toggle for editor toolbar buttons.

  • That is we have a tiddler, usualy a system tiddler which as part of its title is a target tiddlername. When listing or displaying the tiddler we can construct the title and test if it exists and/or has a value.
  • This is essential if we do not want to edit a shadow tiddler

Limitations with above

  • Solutions that establish such a mechanisum can not easily see if others are doing something similar.
  • This creates a proliferation of tiddlers to store very simple information, often a binary yes/no, true or false. Athough usualy hidden behind a system tiddler.
    • This often results in long tiddlernames which themselves consume more bytes.
      • eg; $:/config/ViewToolbarButtons/Visibility/$:/core/ui/Buttons/close-others
    • Because we have no idea of the tiddler naming conventions, different plugins and solutions use, we dont know about each other and it makes it hard to cache such lookups.

A possible solution RFC

The idea would be to provision a “namespace” such as “$:/ghost” (I may have used shadow had it not already being used) and when needed a user or solution could test for or create a ghost tiddler even by just providing a fieldname in the ghost tiddler (ie there is no template or prerequisit, or action tiddler needed to create a ghost tiddler, Just use it by setting a field to its value (which you can test for before you do so).

“My Tiddler”
“$:/ghost/My Tiddler”

In common solutions like I discuss here RFC: Conditional UI elements Tabs/buttons and more we may use a generic fieldname eg; condition, in bespoke solutions the designer “may name the field according to their brand or plugin name” such as a fieldname $:/plugin/PSaT/myplugin/conditions so it is both unique and indicates what plugin or solution introduce the field.

  • The matching tiddler for the fieldname $:/plugin/PSaT/myplugin/conditions can explain its use.

Reasoning for a ghost tiddler

  • provide a standard location for external info relating to a named tiddler
  • The ability to review one tiddler to see the different settings that apply to it
  • We can have a tiddler info tab itterate the fields and create a UI to adjust these fields. So all solutions can create a settings tiddler that appears in a shared info tab.
  • This would be an opportunity to document the the changed date of a core tiddler, annotate core tiddlers, back up the tags field title before changes and much more.
  • As not all will be shadow tiddlers themself, they could all be listed, transfered, deleted.
  • The text of the Ghost tiddler could be used for freeform notes on the named tiddler or to act as a data tiddler with a standard record type to log activity on the target tiddler or collect other useful information relating only to that tiddler. Eg edit date history and total bytes at edit.
  • Another use is for the ghost tiddler to contain a child-filter that identifies the children such as for $:/ControlPanel there would be a $:/ghost/$:/ControlPanel tiddler containing
    • child-filter="[tag[$:/tags/ControlPanel]]"
    • This would allow the settings to be listed as a heirachy with each tab that contains other tabs also setting their child-filter (or tab/menu filter)

Advanced ideas

Perhaps the adioption of another namespace such as &:/which is also a system tiddler as discussed here Expanding the is system namespace then we can save more bytes with ghost tiddlers found at “&:/tiddlername” or even “👻:/tiddlername”

Stratigic analysis and comments wanted :nerd_face:

Section Editor Plugin: First Stable Release
RFC: Conditional UI elements Tabs/buttons and more
#2

I have long wanted a clean way to have a synopsis tiddler of some of my most important tiddlers but this would be free form text and image - ie standard tiddler content.

I don’t know whether this ghost system would help me or not. If I was able to deploy your proposed system then the ghost tiddler would contain a hand curated (edited) synopsis, often this would focus on the highlighted text in an existing (much longer tiddler). Along the lines of revision cards but not quite!

I am familiar with existing plugins aimed at revision cards but they would not suit my workflow or style of working. My way of working would be to be able to throw a global switch to say “show me the short version if it exists” otherwise show me the regular tiddler - everything else would work as it does at present - any existing way of filling the story river with tiddlers would know when to substitute the synopsis tiddler if it exists otherwise show the regular.

Would your proposed system help me along that journey, I do write fairly simple plugins these days?

I guess what I am interested in here is functionality and convention to detect and recognise a tiddler perhaps only by title that is associated with another tiddler with which it has a paired relationship. I would then wish to make the substitution in any list of tiddlers destined for the storyriver.

I could of course add a field in each tiddler that had a paired synopsis tiddler but that is less elegant than an automatic detection of a ‘ghost’ that may or may not exist based purely on tiddler title which may or may not be what you are thinking about here?

Example

“My Tiddler” - main tiddler
“My Tiddler::” - synopsis tiddler detected based on a simple concat on the tiddler title.

Obviously any change in title would need to be reflected in the ghost version if the tiddler title was the mechanism for recognising this relationship between two tiddlers otherwise any change to tiddler title would destroy the paired relationship.

I would generally not wish to see both the full and synopsis versions of a particular tiddler except when I was editing the synopsis and wishing to refer back to the main tiddler.

I suspect I am on a different path here but thought it worth a mention.

#3

Some comments from my perspective of not a developer, but a user who likes to tweak and experiment with the inner workings of TW just a little bit, hope it’s worth something in the discussion.

1. I like the idea of storing all additional information about a tiddler in a structured manner and easy to find (e.g. currently the “visibility” and “fold” are split in different places).

2. Petty detail. The name “ghost” is good, but maybe we can find something more clear to new users, and not so similar to “shadow” to avoid confusion. Maybe something like “about” or “meta”.

3. As far as I understand, one reason against storing all information in a single tiddler would be to allow for easy modification of it with plugins (including core updates). But we could still create a structured system with separate tiddlers, e.g.:

  • $:/ghost/MyTiddler/visible
  • $:/ghost/MyTiddler/folded
  • $:/ghost/MyTiddler/keywords

4. I think it would be helpful to extend the functionality of any field-related operators, so that they are also able to access the “ghost” fields, e.g. has:ghost[folded] (easy to introduce syntax-wise for has, but I guess not so for other operators like search).

#4

I think what you’re looking for is not necessarily the same as the ghost mechanism from OP (which is rather meant for settings/config mostly hidden from normal user interaction).

What you want can be achieved with simple namespacing like MyTiddler and MyTiddler/Synopsis and using Relink plugin with Relink Titles subplugin. Changing the title of the main tiddler to MyNote will change it across all its “children” to MyNote/Synopsis and so on.

#5

Thanks - that is useful to know. Yes I knew I was probably stretching the scope of the OP but the ability to pair and substitute is an interesting topic so I thought it worth throwing in even though I suspect it is borderline “on topic”. Thanks for the heads up.

#6
  • Thanks for your feedback, it is great to see related ideas.

I think if you look around you will find some tiddler note, or abstract solutions. In this example you give, I suspect there may be more value in either;

  • An additional text area field in subject tiddler.
    • I can show you how to do this.
  • An additional tiddler for your synopsis tiddler, in part because you may want to do more with your synopsis tiddler like tag it, or use a special template for it. #1

I think we need to decide precisely one use/function for each field in the ghost tiddler, and the text field would not be available for the synopsis. I favor a data tiddler for a more functionality.

  • We could add a text area field and editor for it, in the ghost
  • Although it seems to me a good case for a separate tiddler #1 as above
  • Of course let us say we had a “standard tiddler note text area” in the ghost tiddler by default perhaps you, and other solutions could just use that, for synopsis/review/comments etc…

#1

Even in the case of separate tiddlers perhaps the ghost tiddler mechanism can be used to generate the name eg; “👻:/ tiddlername/synopsis” eg using <<ghost tiddler:"synopsis">> like a qualify macro, where otherwise we use <<ghost fieldname>> for a tiddler/fieldname in the standard ghost tiddler.

  • This would save you making the mechanisium yourself.
  • The mechanism could provide ways to show it on the subject tiddler in the viewTemplate etc…
#7

Good Idea, but I like that it was close to a shadow without being it. But meta tiddler would be acceptable to me.

  • Sure but see my reply to @jonnie45 in some ways I want to stop the proliferation of tiddlers, but yes with a structured names we could make export tools that know how to include a tiddlers meta tiddlers.

I am already thinking about this but Custom functions and operators are most likely sufficient., Just as we use [all[current] and [<currentTiddler>get[fieldname]] we can also use [<ghost/meta>get[fieldname]]

Yes I meant to mention this above.

  • Relink is almost always used by myself and solves a number of issue if installed including maintaining the ghost tiddlers title when the subject tiddler changes (need to check)
  • Relink can even be set rename fields that exist with a tiddler title if they are renamed.

Thanks @vilc for your feedback

#8

And one more thought. Moving things like fold state or visibility to their new place would probably break a lot of custom UIs and plugins and require them to be updated.

I don’t know if such a thing is considered backwards incompatibility. Things will break if not updated, but we’re not really removing any functionality, just moving some data to other place.

#9

For backward compatibility we would not move anything to it, just for future solutions. For example, I am thinking to use ghost!!condition for this RFC: Conditional UI elements Tabs/buttons and more

Also note here Section Editor Plugin: First Stable Release the clear possibility to use state fields in a ghost/meta tiddler rather than separate tiddlers.
!!state/name including with a custom qualify if desired.

#10

This will be considered a backwards compatibility problem.

So new stuff could be based on it, but it will be very unlikely, that the existing mechanisms for visibility and foldability will be changed in the core UI

#11

Reading the OP my tendency also was closer to a “meta” name.

I think the OP will be conceptually very similar to the the existing $:/config namespace, which may cause an acceptance problem.

IMO there needs to be a clear advantage over the existing mechanisms, which are mainly driven by “solving a single usecase”.

The main problem with the existing mechanisms is inconsistency. The UI code is 100% uscase specific. eg:

  • Visibility using the $:/config NS, where
    • buttons are visible by default if the $:/config/…/Visibility… tiddler does not exist
    • If config-tiddler exists use “show” or “hide” as values to be compared with
  • condition-field for toolbar buttons also defines the visibility
    • contains a filter, that needs to return any value to show the button
    • only exists in EdtiTemplate ui code
  • condition-disabled-field which contains a filter, that defines the button enabled/disabled state
    • needs to return “yes” or “no”, so it can be used as an input for the button-widget disabled input

… and probably many more.

So if a “meta-system” can create a generic way to solve all of the problems mentioned above in a generic way, I think there is a chance.

#12

Just to be clear, I think you’re suggesting a system where we use a particular system-like name-space ($:/casper/mark/mysetting) that acts like a single tiddler, but all members of the namespace get stored in one tiddler.

That would be interesting. Then, if with the press of the button we could convert them to shadow tiddlers, we would have a new way to make plugins. Currently you have to depend on 3rd party tools or use node to build plugins.

#13

Thanks Mark. I hadn’t read it that way. Interesting, indeed.

@TW_Tones I’ve fallen into the habit of appending -data to my tiddlers:

$:/something/really/cool
$:/something/really/cool-data

which isn’t exactly satisfying, but it works.

Oh, and yes, “meta” is definitely the way to go. “ghost” will need explaining. “meta” is blindingly obvious (to most of us, at least).

2 Likes
#14

I meant to add, @pmario’s concerns (now that I’ve read them) are mine, too. There’s more to consider “back stage” than I realized at first glance.

#15

I sort of like charismatic names, like ghost.

Meta is the parent name of a certain social media giant.

#16

@pmario We could do as we do with pop-ups and just test for the existance of a field as well.

The config name space is perfect for wiki globals and yes its being used for tiddler specific settings. I suppose my idea is going forward use a meta name space for tiddler specific only. Reducing the number of future tiddlers.

  • it would be possible to use a cascade from meta to config tiddlers for legacy I can detail later.

I dont follow this but I am interested.

To be clear in my approach anytiddler may have a matching $:/meta/anytiddler containing information about “anytiddler” and it only., the same with $:/systemtiddler $:/meta/$:/systemtiddler.

  • a shared tiddler where settings and states are stored as fields not seperate tiddlers.
  • provide some simple tools to generate the meta tiddler title and fields.
  • an interesting idea that has arisen this to let any designer to create additional tiddlers under the tiddlers meta eg
    • $:/meta/anytiddler/synopsis
    • thus a tiddler info tab can show all related meta tiddlers however they were added.
#17

Yep, I get it Tones, I like it.

I actually did something similar with an About tab in something recently.

image

I guess all the tab details will be in the meta space.

So yeah, I like that idea too. :+1:

#18

I have started exploring the supporting functions and procedures to get access to the meta tiddler, and a named field. I see value in looking at a cascade, eg: cascade.meta where one can ask for say “condition” and it takes the following steps;

  • Get the field condition on the current tiddler ELSE
  • Get the field condition on the meta tiddler ELSE
  • Get the value of condition set in $:/config/meta/condition tiddler if available ELSE
  • Default if parameter used ELSE << added
  • Return nothing

Am I insane adding this to the meta approach?

  • Insane because or the additional complexity, sane because it is a code pattern I often want to use.
  • You could still ask to get only the fieldname from the meta tiddler <<get.meta condition>>
  • Find the meta tiddler title only using <<get.meta>>

I have also started preparing a set of equivalent methods for accessing a meta subtiddler, by default “$:/meta/tiddlername/subtiddler” or your chosen “meta subtiddler” title, perhaps to use for external notes and other information requiring a whole tiddler. Basically this is the way for designers to leverage the same mechanism but for their own subtiddler eg; “note”, synopsis, history…