[TW2036] Planning for v5.4.0

#37

For what it’s worth, I use this syntax regularly, especially for testing purposes, and use the {{{ filter || template }}} syntax even more often — essentially, whenever I don’t need to define any of the other $list attributes. I would be sad to lose the current functionality, and it would also break a number of my templates.

ETA: One common scenario in which I’d use {{{ [<myvar>addprefix<anothervar>] }}} alone (i.e., without a transclusion template) is to display an inline link to the single-tiddler output of the filter if and only if it exists — thus, as a shorter alternative to <$link to={{{ [<myvar>addprefix<anothervar>] }}} /> or <$list filter="[<myvar>addprefix<anothervar>]"/>. In such cases, I wouldn’t want it to default to <ul><li><$link/></li></ul>.

In instances in which I do want filter results in an unordered list, I normally use <<list-links "[<myvar>addprefix<anothervar>]">> instead.

2 Likes
#38

I can confirm that I for one use the stand-alone version only for temporary debugging… for exactly the reasons you describe.

1 Like
#39

Yes, I do that a lot too. Even though I know its practically equivalent to the following, I still favour this shortcut syntax. This further raises the question, how consistent is TiddlyWiki’s shortcut syntax, and will this incompatible update break the previous shortcut syntax? Because I’ve always preferred to use the shortcut syntax when I’ve grasped what it means.

<$list filter="[<myvar>addprefix<anothervar>]">
	<$transclude tiddler="template" />
</$list>
#40

Incompatible updates can include updates that are more friendly to newbies. For example, as mentioned here, add a hidden setting to turn off drag and drop importing in Story River. I often run into this problem when I visit many TiddlyWiki sites.

1 Like
#41

I noticed this when i re-read the OP after I had posted about the plugin mechanism - so fair call on keeping it out of scope for now. Good to know that it is on the radar as a vital feature.

Given that this is a growing build up of planning over future releases - have you considered using the Projects feature of GitHub so its clear whats in this release and whats a priority for future releases ? I imagine it could also help track anyone who volunteers to work on code or documentation changes prior to the PR being raised ?

CB

1 Like
#42

A post was split to a new topic: [MWS] Questions about Bags and Recipes

#43

from user point of view, <<list-links [<myvar>addprefix<anothervar>] >> works well, it’s clear what the purpose of the filter is.
I also use the shortcut inside codeblocks for debugging eg

\function lf()[charcode[10]]
<$codeblock code={{{ [<myvar>addprefix<anothervar>] +[join<lf>] }}} />

I have always thought of it more as a tool, I never really thought this shortcut syntax was intended for use in wikitext body.

#44

Fascinating discussion. I appreciate the rigor with which Jeremy is approaching the new version. I am learning a lot as I catch up in this thread.

FWIW I do use this filtered transclusion shortcut syntax in my right sidebar tabs. I find it useful beyond simply for testing filters.

Table of Contents tiddler example:

2 Likes
#45

On a non technical note, would this be a good time to move the default icon set over to one @jeremyruston you were discussing …some time ago?

1 Like
#46

Or did that already happen?!

#47

I suggest we try to tackle refactoring the import process as part of v5.4.0, to allow for manually switching which deserializer is used and thus allowing for greater end user control over how data to be imported is interpreted.

2 Likes
#48

Right. Given that for many end-users (though not all) import and export are both central to getting the best usage of TW—I’d really like to see both better grained control of import and export; and more documentation on how to write importers and exporters.

#49

This is an interesting and informative thread and has shown me many things I was unaware TW could be applied to. Certainly, at my stage of TW expertise, these are way beyond what I would tackle but knowing about them is great.

I am a bit concerned though that in reading the suggestions for ‘improvement/enhancement’ of TW, we might be putting ourselves in a position that TW becomes ‘just another browser app’ rather than the different approach it currently holds.

Right now, TW has few competitors that I am aware of. If we just become another browser app, then all other browsers become competitors and we may end up continually chasing the tail of others developments. In marketing terms, why give up the high ground we currently occupy?

I think that would be a shame.

bobj

1 Like
#50

What one person sees as “modern” or “aesthetically pleasing” could look terrible to another. CSS is going to always be the way in which you manipulate how the your UI components look. Just curious, what are you referring to when you say “require end-users to manipulate JS”? I don’t think anyone needs to alter any JavaScript to get HTML UI components with CSS to look “modern” or “aesthetically pleasing”.

#51

The reason for this is simple, the current widgets provided by TiddlyWiki are functional, but the css is missing. I think there should be a more aesthetically pleasing css provided to the end user. For example, I’m struggling with select styling right now, because straight <$select> styling doesn’t really look good. But I don’t know how to use css to set a better looking style. Of course the user can take the style he wants, but TiddlyWiki should provide a basic, better looking style. Maybe it could be implemented as an officially maintained plugin. Well, I may be thinking a bit too much.

I said that the end user doesn’t need to manipulate js because I saw some component libraries like shadcn/ui class, but these component libraries require js or ts to use. Maybe sometime we should redesign the interface of TiddlyWiki to be similar to the vscode kind of style, it might be more appealing to users.

#52

The default appearance of the $select widget depends upon the browser and platform you are using.

To use CSS to change this appearance, you can add class="mySelectClass" parameter to the $select widget, and then define a .mySelectClass CSS class in a tiddler tagged with $:/tags/Stylesheet. Note that to apply styles to the droplist items (the option child elements), you need to use .mySelectClass option as the CSS selector

For example:

.mySelectClass { border-radius:0.5em; }
.mySelectClass option { font-size:2em; }

-e

#53

I simply tweaked your method and it looks better now. I’m using tidgi, and the browser used behind it is chrome. my point is that TiddlyWiki should provide a nice neat style, rather than letting that be handled by the browser. Because different browsers display different styles.

#54

Yeah, but you see, that is part of the problem. Each browser already has its own style, so you want Tiddlywiki to also have its own style, so that it looks the same across all browsers, but what about those people that use Firefox for example, and don’t like that TIddlywiki is not using the Firefox style that they expect. It is all a matter of personal preference, so Tiddlywiki simply leaves it to the browser you are using to determine the style. Most professional websites online do not use the default styling provided by the browser. They customize it with CSS the way they like. You want Tiddlywiki to customize it to a design that you personally think is “modern” or “aesthetically pleasing”, but who is to say what that is? If they started including styles provided in the core, then where does that end? How many styles, who’s idea of “modern” or “aesthetically pleasing” is going to appease the most people? In the end, they end up with exactly what they have. People designing their own style with CSS and attaching as a class to the object. Ultimately, Tiddlywik is not doing anything other than what ever other web developer on the planet is doing. Designing their site the way they want with CSS. Tiddlywiki in its most basic form, a clean empty.html is as bare bones as you get appearance wise, but it gives you a foundation to build on rather than you developing it from scratch on your own. You have to take the time to style things the way you like. Tiddlywiki is infinitely customizable, unlike other note taking systems that require you to use THEIR style.

Don’t take anything I am saying as an insult, it is just that TIddlywiki can only do so much, without practically writing your notes for you. There is a templating system, access to css classes in all of their widgets, everything they can do to allow you to completely alter the entire visual appearance and functionality to whatever you like. It is better to leave it to the individual than to start bloating the system down with unnecessary personal preferences.

5 Likes
#55

This is indeed a controversial issue, but let me explain. I’m not saying that I want my favourite style to be the TiddlyWiki style. I’m saying that it would be better for TiddlyWiki to give a more general aesthetically pleasing style than for the underlying browser to control the style. And the user can remove that style or add new ones. This means that if someone likes the firefox style, he can remove the TiddlyWiki style. If there is a person who is good at using CSS, then he can also add custom styles.

Another solution is that special styles can be written in the documentation and some introduction is given, for example, under this entry, a particular style is used to show the functionality of the select. But again, this involves editing and improving the documentation, and that might be another issue.

#56

TiddlyWiki is more like a library, focusing solely on core functionalities.

1 Like