Right. The more we simply connect to real TW the better IMO.
Shirley, that is the point?
TT
Right. The more we simply connect to real TW the better IMO.
Shirley, that is the point?
TT
Erm. Not so sure.
What can I say? I’d guess whichever method could be done it is always best to easily invoke a live TW. Otherwise why do it? Something like that.
Best, TT
I wanted to follow up on this. The whole “card” thing.
FYI @joshuafontany wrote an experimental plugin that hasn’t had the attention it deserves for TW “Oembeds” https://github.com/joshuafontany/TW5-Oembed. Unfortunately the demo doesn’t seem to be working ATM.
Best, TT
This is just thinking out loud. The recipes are apparently written in a Onebox “Gem” in Ruby (on Rails). Presuming that a headless browser driver exists for Ruby, then it might be able to fetch and parse the actual contents of an address to a single tiddler and set up a more responsive “card”. This would make setting up cards much easier because rather than using a special description field, there could be a default fall back that takes the first 100 characters or so of a tiddler as description.
Just throwing this out there in case there are any bored Ruby programmers hanging around.
This is for embedding other things in TW, not the other way around.
Although the Other thing we embed in TW could be from a tiddlywiki !
I remember @telumire invented an smart solution to use Tiddlywiki lively in a Talk post!
I could not find the thread!
Thanks for keeping this thread alive!
My point in the OP was that there is a “distance” (visually) between Discourse and TW.
I simply think TW would do better if we could integrate a “TW Look” into Discourse.
I did suggest that rather than having links to TW-wikis we embed them. BUT there was concern on it being too much—that it would cause problems on bandwidth & performance here. So I, basically agreeing, abandoned that idea.
However, I still think we could maybe do more to "narrow the gap between talking about TW & using it??" And visual appearance is a big part of that.
I hope this is clear!
TT
Thanks for the mention ! I believe that you are talking about this post : Intended feature or potential security issue ? How to embed an iframe in talk.tiddlywiki
I agree that it would be amazing to have talk.tiddlywiki support tiddlywiki files natively ! Maybe it could allow embedding of html files, in a similar way that codepen does ?
A tiddlywiki theme for discourse could also be good but I’m not sure if the features of this forum are similar enough to tiddlywiki to allow that (sidebar, tags, …?)
It would do that easily. I shown that already. The issue is that there was concern on bandwidth & performance. That it would create problems for some users.
That iframes here on Discourse could cause problems.
That is why I did not push it further. But basic iframing looked well viable to me and easy.
TT
Right. It would be a Second Best. A “Cut Down” version! But maybe still useful?
But I am glad, @telumire, you really get the point of the OP!
Best, TT
A lot of water went under the bridge on this topic, I just reread the whole thing. There are plenty of great ideas and examples and many are 90% towards some useful outcomes.
The issue is that there was concern on bandwidth & performance. That it would create problems for some users.
With tiddlywiki.com not undergoing too many changes every day surely more often than not peoples browsers load it from the browser cache?
Also as I suggested earlier Static tiddlers could
As I understand is depending on how it is implemented the embed process queries the content at the end of the link when you attempt to view that link, so it only does so when you need to see that content. Some forums do it once and save the result of retrieving the card in their database.
The aforementioned data share method, demands a plugin to be installed on the host wiki, at present it is left to us to provision this, wiki.
Performance, whilst for some would be an issue if you decide to load discourse and browse content then you are tacitly deciding to use bandwidth to read content. Even tiddlywiki.com is smaller than many images or audio out there.
A lot of water went under the bridge on this topic, I just reread the whole thing. There are plenty of great ideas and examples and many are 90% towards some useful outcomes.
I thought you comments interesting.
I still believe that having a Discourse that can incorporate the look and feel of TW would help a lot.
As a second-best I did look at how to get control of the CSS for our Discourse. It is a bit beyond my skill level to actually do it.
What I can see is that it would definitely be possible to …
1 - write posts in a TW; (as normal)
2 - that can be directly posted to Discourse; (via a TW poster macro)
3 - that, in theory, on landing on Discourse, could be laid-out exactly the same as their origin in TW; (needs Discourse end CSS changes).
Just a comment, TT
800mb wow, envy on my part…
I upped my data from 2GB/mo to 4 a month ago. But then I am using a Mexican plan, roaming in the US, and using Google Maps constantly on the road…
800mb wow, envy on my part…
That’s 800mb total for the year! And, mb, not gb .
This is really handy for things like pointing out outdated tiddlers in documentation, explaining what text bodies mean, and helping newer users locate information.
Could this also be used with the static.tiddlywiki versions? I’d imagine so- ooo it would be cool to see what could be done with tiddlyhost as well.
This is really handy for things like pointing out outdated tiddlers in documentation, explaining what text bodies mean, and helping newer users locate information.
Could this also be used with the static.tiddlywiki versions?
Yes. Certainly embedding static pages would work and I think, not be so much of a problem for lower bandwidth users or those where full TW embed is not performative or costly?
An example of static embed …
<- Click to see ''Introduction To Filter Notation'' ...
This is the static version ... Introduction to filter notation
[UPDATE: One of the good things with the static TW is you can still click around; i.e. you click a link and it loads that item as a static page within the same iframe. That behaviour is very close to what I envisioned in the OP.]
[UPDATE Update: Though there are some items that aren’t rendered statically. Links to those give a 404. Nonetheless it is pretty useable on most linkage.]
I do think some of the ideas in this thread are worth pursuing into some kind of consensus & action.
Thoughts, TT
This is where I think an alternate template for generating static tiddlers would make all the links therein open the parent wiki.
I did create it here How to export static tiddlers who’s internal links will open the master wiki
an alternate template for generating static tiddlers would make all the links therein open the parent wiki.
I did create it here How to export static tiddlers who’s internal links will open the master wiki
Right. And that approach would match the OP I think on iframes?; i.e we’d iframe a static page for low overhead in a discussion group; but if a reader wanted to go further they would load TW Mother, knowing so.
Best, TT