Add tc-entitled class to tiddlers

[danielo515]

This may require the resolution of #958, but it is indeed a very needed thing.

I don't understand why we are adding class names based on tags and not based on titles.

This would be a very powerful features for building awesome custom view templates. The most important point is that it allows plugins and other mechanisms to style a tiddler without modifying the tiddler itself (AKA adding a tag). Some cool implementations would allow to:

• Hide any part of the current tiddler and show a special one based on an external condition: existence of another tiddler, any flag, presence of a field or even a date
• Style all the tiddlers contained on a list in any special way, again, without any modification to those tiddlers.

This has started on https://groups.google.com/forum/#!topic/tiddlywiki/NiS6c9yO-Lg

[tobibeer]

From what I guess you want to do, I think it should be possible and relatively easy to extend the core so that for each ViewTemplate element one could define a filter whereby the element would only be displayed if the filter had any result.

[danielo515]

Hello Tobias, That could be a solution. @pmario has proposed another one on the boards. Currently TW has great support for including and positionning new parts, but it totally lacks the ability to hide them.

[danielo515]

Maybe instead of a filter, which could be a solution bit complex to set we could use a simple variable. But that variable could be a filter.. which provides more flexibility. But if there is no filter set, how would we fallback to the default filter?

[tobibeer]

But if there is no filter set, how would we fallback to the default filter?

That is what I asked myself too and which is why I thought for a second the logic may need to be in reverse: If the filter returned any results, the element should not be displayed. In other words, if there is no filter, then there is no results, so: show it.

Possibly sounds confusing, possibly makes sense.

In other words, the filter could specifically define when NOT to display an element which literally is what you want from a functional perspective, e.g. hide this when foo.

[pmario]

------ just some rants, that make me feel better. Ignore if you want :)

The problem, that I have with the current TW UI change requests is best described with: "someone's feature is an other ones bloatware"

IMO we are adding bloat for quite some time already. ... I can't help myself, but for me the new edit-toolbar (as useful as it is for newbies) is bloat.

I would like to have a core, where this type of functionality could be a plugin. If the core would support changes like the toolbar and your proposal here as plugins, we would all win. The core would be better defined and imo even simpler, in the end.

At the moment every feature we add makes everything more complicated.

[danielo515]

Hello @pmario

I'm not sure what do you mean exactly with "core" and I both agree and disagree with you, let me explain myself. I agree with you in keeping the core simple, as much as possible. But for that being possible it should be as extensible and configurable as possible, so you can plug-in (that's the point of plugins) any functionality you need. In my opinion this particular proposal does not add any bloatware but provides that required extensibility.

If with core you mean default edition then I disagree with you about removing newbie-friendly features. As long as you include all the user-friendly plugins in the default edition I'm ok about removing every possible byte from the core. The reason is because it's trivial for an advanced user like you or me to get a "barebones" edition, but any help we give to any incoming user is very valuable.

You are always concerned about keeping things away from core and I someway agree with you, but one of the advantages of TW5 over TWC is that some basic stuff that were in plugins is now into the core. What would be a good balance then?

[tobibeer]

I think there are ways to render a more bare-bones version of the core. What that requires is someone willing to work on it and to refactor all the removed bits into meaningful "core-extensions", if you will, like a "control center" or an "editor toolbar", even a "view-template toobar" or an "edit-mode toobar".

[danielo515]

Hello @tobibeer,

I agree on that because I'm one of the users that use tiddlywiky for things very far away from the default usage,and getting rid of unwanted stuff is usually a hard work. But wasn't that what TWC was? A super tinny core with lots of plugins?

[Jermolene]

getting rid of unwanted stuff is usually a hard work

Can you expand on that? The cases we've discussed recently seem to me to be not just about getting rid of unwanted stuff, but also changing the logic of existing features. That's where the difficulties often come.

[danielo515]

The cases we've discussed recently seem to me to be not just about getting rid of unwanted stuff, but also changing the logic of existing features. That's where the difficulties often come.

Hello @Jermolene

Getting rid of unwanted stuff is one topic that from my point of view is closely related to changing the logic of existing features. If instead of hiding something and then put your stuff there you can just choose (more granularly) how things are built, then the need to getting rid of things decreases.

Let's take an example: the tiddler folding animation. Currently there is no way to deactivate that animation separately. You have to deactivate the animations for the entire wiki, it's all or nothing. That is an example that involves both topics, getting rid of things (in this case a single animation) and changing the current logic (for example, using a variable <<animate-folding>>).

But there is a subjacent topic that only involves getting rid of things. Imagine that I want to create a very special edition of TW, one that would only require the micro-kernel and a couple of core features: the wiki store, the tiddler class and and maybe a couple of other things. Currently if I need something that it's on the core (a banana) what I get is a gorilla holding the banana and the entire core jungle. I can envision a couple of scenarios where this happens: implementing TW using a framework like NativeJs, or ReactNative, where I'm going to write the entire view layer. Or maybe a very mobile-focused edition, where I don't use the sidebar at all (but I can't get rid of id, so I hide it) and instead I provide a convenient sliding menu. Those are some approaches that are only focused on getting rid of stuff.

Regards

[Jermolene]

Hi @danielo515

Let's take an example: the tiddler folding animation

That's exactly what I mean: the stated goal is for a plugin to change the way that the core operates. To do that, we always need to specifically facilitate the extension. And that's OK, I'm very permissive on little tweaks to the core that permit plugins to do more things.

Anyhow, my point is that that does not come under the heading of "getting rid of stuff", it's about "changing stuff". The distinction is important because we do actually have several very consistent ways to get rid of stuff (ie CSS and overwriting core templates). But, as I say, "changing stuff" always requires the cooperation of the core.

Imagine that I want to create a very special edition of TW

This is a different topic, no?

Currently if I need something that it's on the core (a banana) what I get is a gorilla holding the banana and the entire core jungle

I don't think that that's correct. Think of the way that the core page template is nested for example. It's easy to have ones own page template that incorporates the core tiddler view template. The TiddlyWiki user interface is represented as a tree of templates. You can re-use any branch of the tree very easily.

implementing TW using a framework like NativeJs, or ReactNative, where I'm going to write the entire view laye

I'm not sure where this is going. Does the TiddlyWiki core need to do anything special to help people re-writing TiddlyWiki with a different framework?

Or maybe a very mobile-focused edition, where I don't use the sidebar at all (but I can't get rid of id, so I hide it) and instead I provide a convenient sliding menu. Those are some approaches that are only focused on getting rid of stuff.

We must be talking at cross purposes. It's trivial to hide the sidebar in several different ways:

• Use CSS to hide the class tc-sidebar-scrollable
• Hide it by setting $:/state/sidebar to no
• Overwrite the core template $:/core/ui/PageTemplate/sidebar

[danielo515]

And that's OK, I'm very permissive on little tweaks to the core that permit plugins to do more things.

Ok, I'll prepare one or two more PRs

Anyhow, my point is that that does not come under the heading of "getting rid of stuff", it's about "changing stuff". The distinction is important because we do actually have several very consistent ways to get rid of stuff (ie CSS and overwriting core templates).

I don't see that as getting rid of them. It's just shadowing (in case of template override), hidding, but the bits are still there. I'm not sure if they are also being executed (widget tree being generated for example). Not to mention that the space they take (in Kb) is still there plus your shadowing stuff.

Think of the way that the core page template is nested for example. It's easy to have ones own page template that incorporates the core tiddler view template. The TiddlyWiki user interface is represented as a tree of templates. You can re-use any branch of the tree very easily.

Not sure if I'm following you here. Do you mean that I can provide the core a place to live (for example, a div) and it will be limited to be inside that div? I know this is possible because I have created a TW edition that sandboxes another Tiddlywiki, and it's pretty straightforward to render the entire TW where you want.

I'm not sure where this is going. Does the TiddlyWiki core need to do anything special to help people re-writing TiddlyWiki with a different framework?

Yes, we are going a bit crazy here 😄 I mean that, if the core were more modular it would be easier to mix it according to your needs/likings not only with other frameworks, but with TW itself. Instead of hiding the sidebar I decide to not include that "plugin", instead of overriding the view-template to show a normal text area I just don't include the edit-toolbar. That's what I mean with getting rid of stuff. But I have to admit that this is far far away from the original motivation of this request.

We must be talking at cross purposes. It's trivial to hide the sidebar in several different ways:

Use CSS to hide the class tc-sidebar-scrollable Hide it by setting $:/state/sidebar to no Overwrite the core template $:/core/ui/PageTemplate/sidebar

All those options are just shadowing. You hide things, or you override things, but those things are still there. The file size is the same, the rendering process happens anyways... etc.

And regarding the original request, I would like to know how well the test of @pmario are going... Regards.

[Jermolene]

Hi @danielo515

but the bits are still there. I'm not sure if they are also being executed (widget tree being generated for example). Not to mention that the space they take (in Kb) is still there plus your shadowing stuff.

If you hide stuff with CSS then it will still be rendered into the widget tree. If you hide things by overriding the core template then nothing will be rendered. I really don't think that the space consumed by the unused templates should be a concern, as it is trivial compared to the users content.

Do you mean that I can provide the core a place to live (for example, a div) and it will be limited to be inside that div? I know this is possible because I have created a TW edition that sandboxes another Tiddlywiki, and it's pretty straightforward to render the entire TW where you want.

Well, at the moment, the core creates the page container div itself:

https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/render.js#L56

But that wasn't what I was getting at. I was saying that one can, say, override the core page template with a completely new page layout, but re-use some of the core page elements (eg the main tiddler view template).

if the core were more modular

To me, it's hard to imagine how the core could be any more modular than it already is. Every single thing is broken out into a single tiddler.

it would be easier to mix it according to your needs/likings

But it's perfectly straightforward to make a custom core plugin, we've discussed it before. I've made the point that I'm not interested in the burden of supporting multiple versions of the core, but there's absolutely nothing stopping anyone experimenting.

not only with other frameworks,

What do you mean here?

but with TW itself. Instead of hiding the sidebar I decide to not include that "plugin", instead of overriding the view-template to show a normal text area I just don't include the edit-toolbar. That's what I mean with getting rid of stuff. But I have to admit that this is far far away from the original motivation of this request

And the point that I have made repeatedly is that doing all of that is a lot of work, and literally the only saving it provides is that the core plugin doesn't contain a bunch of otherwise inert, unused templates. Until somebody proves otherwise, the performance gains will be miniscule. I've learned to be highly suspicious of performance-derived arguments that aren't backed up with decent quality data.

[danielo515]

I really don't think that the space consumed by the unused templates should be a concern, as it is trivial compared to the users content.

TW can not be considered exactly a small web application. The empty edition is about 1.8MB which is huge. My oldest and biggest TW is only 5mb including several plugins, so TW core is about 30% of it.

Well, at the moment, the core creates the page container div itself:

And then inserts it. https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/render.js#L58 If I want it on a different place I have to override the entire render.js or use some JS for moving it. Not a concern right now, but good to know.

To me, it's hard to imagine how the core could be any more modular than it already is. Every single thing is broken out into a single tiddler.

Sorry for being unclear. The core it's very modular, but it's everything bundled into the same plugin. So it's very very modular, no discuss on that, but it's impossible to get the different modules separatelly.

not only with other frameworks I mean that you can use TW as part of another framework, or build a tw including only the bits you want.

I've made the point that I'm not interested in the burden of supporting multiple versions of the core Why multiple versions? I'm talking about splitting the core across several smaller plugins, not to version the core for every possible use case.

I've learned to be highly suspicious of performance-derived arguments that aren't backed up with decent quality data. That sounds like an experience lesson that made you a wise man. I have to admit that I also lost big amounts of time performance-tuning things that never got used, or with minimal performance gains or ended with implementations too limited to be useful. I'll learn from your experience here.

[Jermolene]

Hi @danielo515

Why multiple versions? I'm talking about splitting the core across several smaller plugins, not to version the core for every possible use case.

I don't think that's an option. It would be very confusing for most users to keep track of which core plugins they've got, whether they've got the right versions. There's a huge conceptual simplicity to a single core plugin, and I don't think we should abandon it. As I say, though, there is nothing to stop people experimenting with packaging the core tiddlers differently.

[danielo515]

If I remember correctly @pmario made a pull request to add css meta selectors, which is much more powerful than this approach. If that path is going to be taken this issue can be closed

[pmario]

@danielo515 The data-tags PR has been merged.

It includes a "class-field" that is added to the tiddler body data-tags and data-tiddler-title attributes.

[pmario]

@danielo515 ... IMO can be closed

[Jermolene]

Thanks @pmario @danielo515