The nature of these is that they might be off, but that the spirit of them would be great any way closest they can be accomplished without breaking the dedication level to backwards/forwards compatibility.
These UI feature suggestions:
A default left sidebar option, to whatever degree can mirror the right one on a core level, but without filling it with content yet, until such further potential development. This would not require showing it by default, but presenting it as an option that users can fill in with their own sections in a similar way to the right sidebar.
Basic line numbers in the editor without a special editor
saving tiddlers in edit mode while it stays open, without re-navigating to the tiddler, and loosing place in the editor.
I noticed some deeper widgets/messages are tied between tiddler creation navigation, and the vanilla theme, making it weird to create different tiddler creation and navigation scenarios with different imagined layout configurations. (This might be related to something that was mentioned already.) . . . . From what I vaguely remember, this could be accomplished by splitting some messages into multiple steps of smaller messages. Compatibility would be accomplished by making the existing messages perform these multiple operations.
These features could create a mass of possibilities of proliferation in custom layout configurations without users needing to know js.
Thank you for the thoughtful and useful feedback. I’ve made some edits to the OP which I have marked with the date.
Yes, the idea is to expose low level primitives that allow deep customisation of the location hash behaviour.
There would be a global setting to control the deduplication behaviour. I am also hoping to offer the ability to switch between modes on a per-filter basis, and the ability to control deduplication via a variable.
The primary work involved with this is to go through the core and ensure that there are no dependencies on the current deduplication setting.
I agree that an official plugin library is vital to the future of TiddlyWiki. However, I think we would be wise to treat improvements to the plugin library as out of scope for v5.4.0. There is a lot of work involved, and a good deal of that work is tasks that fall outside of the core development that is the focus for v5.4.0.
This comes up regularly, and I very much like that there are experiments in this area.
However, while I am sympathetic to the desire to optimise the performance per byte ratio, there is a trade-off here: it would make supporting TiddlyWiki users more complex because we would be dealing with what would amount to a series of different TiddlyWikis, each with their own selection of core tiddlers and plugins.
I like to talk about universality as one of the key goals of the core. It’s a useful way of thinking about several different aspects of the development of TiddlyWIki:
Universality of usefulness is an important criterion for inclusion of a feature in the core. (If a specific feature is deemed to have too narrow a use case to make it into the core, then we would generally instead add the hooks to make it possible to implement the feature in a plugin)
Universality of audience means that we want TiddlyWiki to be accessible to everybody in the world, regardless of language, disability, culture, but united in the desire to make sense of a complex world
Universality of platform is the idea that TiddlyWiki should support the widest possible range of devices, browsers, operating system etc.
I am not referring to the filtered attribute syntax like this:
The problems are around using the triple brace syntax on its own:
{{{ [<myvar>addprefix<anothervar>] }}}
As things stand, that syntax produces a list of linked titles returned by the filter. Sadly, it just produces a stack of DIVs and not a semantic HTML list
My guess is that this syntax is rarely used because it is so limited. Part of the process of the development v5.4.0 is to validate those assumptions.
If we do decide to redefine this syntax, there is an opportunity to think up some useful alternative meanings. For example:
Present the filter results as a semantic HTML list so that it is easier to apply CSS styling
It would be fantastic if we could mobilise a team to focus on documentation improvements. We’ve had some incredibly useful contributions over the years and yet there is always more to do.
My thoughts on this are included in the associated GitHub thread. While it may be appropriate to use ES2024 in some subsidiary projects like MWS, I think we should continue to target a relatively conservative subset of JavaScript, albeit more modern than at present. I think this approach is enormously beneficial to end users, and doesn’t hit developers too hard.
We’ve had a few attempts at this over the years, but nothing that has been truly satisfactory. I am confident that implementing this feature would require at least a modest break in backwards compatibility, and so we should definitely give it consideration for v5.4.0.
There have been improvements to permalink handling that go a long towards making linking to section marks viable. However, my sense is that users actually want something more ambitious: to be able to address a section of a tiddler in such a way that it can be used anywhere a tiddler can be used. In other words, being able to transclude just the chunk of a tiddler delimited by two section marks.
I would like to explore whether we can find a viable approach. There is a possibility that we could somehow be able to optionally treat wikitext tiddlers as if they were plugins with each section being a separate shadow tiddler. More thinking is definitely needed; we need a solution that is elegant and easy to use.
We’ll change the filters in the core to work in either mode.
When we’ve experimented with disabling deduplication in the core we actually found that the broken cases were relatively easy to spot; typically, the giveaway would be duplicate items appearing in a list that shouldn’t have duplicates.
Excellent point, thank you.I will add it to the OP.
I think that might be the best approach. I will add it to the OP in the section about staying competitive.
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.
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.
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.
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 ?
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
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.
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.
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?
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”.
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.
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
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.
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.
