I can explain it with the current plan. I’m currently using tidgi, a launcher that allows me to repeatedly add the TiddlyWiki of nodejs. So the three pictures above have a common nodejs folder behind them, rather than three nodejs folders. The reason why this can be achieved is that tidgi will assign a dedicated port number and workspace ID to each wiki added, regardless of whether it duplicates the existing wiki or not. After starting TiddlyWiki, corresponding info tiddlers will also be generated, such as’ $:/info/tidgi/workspaceID '. Based on these info tiddlers, I can directly enter the corresponding layout when starting a certain wiki. Of course, only the default layout and flex layout are shown here. In the future, I will write some custom layouts.
This can achieve what I need. All the data is stored in one TiddlyWiki folder, and there are multiple different display schemes at the same time. Why not switch layouts within a TiddlyWiki? Because switching layouts is relatively troublesome, and more importantly, the status tiddlers cannot be changed. For instance, if I need to search for AAA, I also need to leave a record of searching for BBB. If they are only in one TiddlyWiki, they cannot coexist. After all, the bottom layer is a status tiddler, unless we save it.
This current solution is quite good. You can even see that in the same folder, there are three different palettes. In the future, there can also be different fonts, and each tiddler has a different button. After all, a workspace is only responsible for its specific related content and doesn’t need all the buttons.
However, the biggest drawback of this solution is that it must rely on tidgi. Without tidgi, it cannot run smoothly. There can only be one layout or constantly switching layouts. I hope to see more native solutions. But I still can’t find it for now.
innerwiki might be a breakthrough point. By leveraging nodejs local data, an innerwiki can be generated. Meanwhile, the data saved in the innerwiki can be placed back in the local folder instead of having to generate html to save it. If innerwiki can achieve synchronization with other servers, I think it will be very influential. I saw someone write a similar component using just a few dozen lines of code, but the data still needs to be saved as html to save it. I hope innerwiki can save the tid data locally like nodejs does.