[TWc] TreeDiagramFormatterPlugin

[G.J.Robert]

Hi,

I hacked (ugly-ly) and extended the list formatter handler of TWc because I needed a tree-like diagram or something like cladograms found on Wikipedia species, to organize my notebook. For those who may be interested, it's published on a TiddlySpace plugin-space: http://treedg.tiddlyspace.com/ . (Pardon me for not being so sure how to build a plugin-space so to be safely included without messing up other spaces. From the default 4 system spaces of TiddlySpace, I have dropped @system-theme and left the other 3 intact. Also I have hidden the essential tiddlers of the plugin as "excludeLists" so not to interfere your timeline.)

Any suggestions/feedbacks welcome (every aspect, even to the name of the plugin...)

Love and peace,
GJRobert

[Sonda]

Wonderful!

[Tobias Beer]

I hacked (ugly-ly) and extended the list formatter handler of TWc because I needed a tree-like diagram or something like cladograms found on Wikipedia species, to organize my notebook. For those who may be interested, it's published on a TiddlySpace plugin-space: http://treedg.tiddlyspace.com/

Really Nice!

 

Pardon me for not being so sure how to build a plugin-space so to be safely included without messing up other spaces.

As for plugins on TiddlySpace, I prefer to always create two spaces...

* one for the plugin to be included, e.g. @TreeDiagramFormatterPlugin

* one for the documentation, e.g. @treedg

The thing is, I don't think documentation or any of that should be inside a plugin *at all*. At least for my taste, many plugins are way too bloated like that. All it takes is a Documentation slice.

Code is code and prose, examples, parameters, configuration, version history, etc... are a different thing. They perhaps require proper example tiddlers and something that looks better than plain nothingness.

For an example perhaps see...

http://slidr.tiddlyspace.com

http://slidrplugin.tiddlyspace.com

As for the includable plugin space...

You pretty much should...

* remove *all* included bags, unless your plugin depends on any

* *especially* delete the ColorPalette, as well as GettingStarted

* tag the plugin excludeLists and excludeSearch because they have nothing to do with the content in space that includes them

* put SiteInfo into DefaulTtiddlers

* I usually name the SiteTitle with the plugin name to directly link it

* when ready for inclusion, I add the tag plugin to SiteInfo, recently I also started to tag it with @tobibeer and official to indicate that I am the actual author and not just the creator of a plugin space for something I haven't created, otherwise I tag it unofficial and with the actual authors name

If you want or need to, I can help you with the initial setup.

Best wishes, Tobias.

[G.J.Robert]

Tobias Beer於 2013年9月11日星期三UTC+8下午6時24分23秒寫道：

I hacked (ugly-ly) and extended the list formatter handler of TWc because I needed a tree-like diagram or something like cladograms found on Wikipedia species, to organize my notebook. For those who may be interested, it's published on a TiddlySpace plugin-space: http://treedg.tiddlyspace.com/

Really Nice!

Glad to have compliments from the community, thanks! Please keep telling me if you find any questions or problems contained with it. :-)
 

 

Pardon me for not being so sure how to build a plugin-space so to be safely included without messing up other spaces.

As for plugins on TiddlySpace, I prefer to always create two spaces...

* one for the plugin to be included, e.g. @TreeDiagramFormatterPlugin

* one for the documentation, e.g. @treedg

The thing is, I don't think documentation or any of that should be inside a plugin *at all*. At least for my taste, many plugins are way too bloated like that. All it takes is a Documentation slice.

Code is code and prose, examples, parameters, configuration, version history, etc... are a different thing. They perhaps require proper example tiddlers and something that looks better than plain nothingness.

For an example perhaps see...

http://slidr.tiddlyspace.com

http://slidrplugin.tiddlyspace.com

Yeah, I agree with this point. I liked to have simple manual be included in the main plugin tiddler so that I can consult the documentation anytime without having to import/include one more big documentation tiddler. But I guess you guys are right about the bloating problem and now I understand why Eric has splitted most of his documentations as separated tiddlers.

Since I agree with the practice now, I kind of regret that I have given the plugin such a long name, 'cause I'm afraid that "TreeDiagramFormatterPlugin" is a bit too long to type for TiddlySpace inclusion :-) So I guess I'll try to rename the plugin as something like "TreeDGPlugin", to avoid cumbersome citation and inclusion.

And many thanks to Tobias for detailed and informative steps below. I'll do the fix shortly ;-)
 

[Eskha]

A really nice plugin!

I think, the two following features could be interresting:
* Before any vertical bar, having an horizontal bar centered on the parent node,
* Having a syntax to do vertical diagrams instead of horizontal ones.

Best regards.

Eskha

[Tobias Beer]

Hi,

I think, the two following features could be interresting:
* Before any vertical bar, having an horizontal bar centered on the parent node,

I second that, guess I'd like it to see it like this with rather small lines, just the slightes visual clue...

 

* Having a syntax to do vertical diagrams instead of horizontal ones.

That's may be neat, too, but...

* it will result in a lot of horizontal scrolling

* it will require more of a quote style left border with those branchy things

* I guess, any second third level, etc... would have to be horizontal again for readability's sake

Best wishes, Tobias.

[Tobias Beer]

Some more things...

(a) I see your space ships with these simplistic grahpics.

I don't think you need those and so I think you should get rid of them. All you need is a bordera simplistic Base64 encoded 1x1 pixel held by a section or slice or variable in your plugin... which you then stretch either horizontally or vertically to the desired size. No resources external to the plugin are needed. You simply render this as...

<img src="data:image/gif;base64,R0lGODlhAQABALMAAICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAABAALAAAAAABAAEAAAgEAAEEBAA7" style:"height:1px;width:100px:"/>

...or the appropriate background image.

background-image: url([[TreeDiagramFormatterPlugin::pixel]]);

As before, this could be defined by the user to whatever he likes using css. Your ts:before would then need some defined width or height.

(b) what on earth are <tp>, <tl>, <ts> elements

?!?

(c) a tree should by default be wrapped into some span with a class .treedg

(d) right now I am playing with getting rid of images entirely and putting nothing but borders

(e) Seeing how you have included @White now, you should definetely create a plugin space outside of the treedg space or create a treedg-info space and then use the theme there.

Best wishes, Tobias.

[Tobias Beer]

Hi again,

(d) right now I am playing with getting rid of images entirely and putting nothing but borders

I guess that won't work with borders because you can't quite center that horizontally, can you now ;-)

 

(e) Seeing how you have included @White now, you should definetely create a plugin space outside of the treedg space or create a treedg-info space and then use the theme there.

Just don't use the GettingStarted tiddler at all. For a plugin, you have no need to reference the original GettingStarted tiddler... it's got virtually nothing to do with your plugin.

~

By the way, you should implement your StyleSheet like this...

config.shadowTiddlers['StyleSheetTreeDG'] = foo;

store.addNotification("StyleSheetTreeDG", refreshStyles);

This creates the StyleSheet as a shadow tiddler first that can be overwritten;

Also, naming it StyleSheetFoo groups all styleheet shadows together in the Shadows tab.

Best wishes, Tobias.

[Tobias Beer]

Hi,

I must say Robert, I quite like this plugin! Has a lot of potential.

(1) I have played a bit with it and made use of Base64...

http://tbdev.tiddlyspace.com/#NodeTreePlugin

Like that it's all just one plugin, no additional images. ;-)

(2) By the way, I have added that parent indicator, too.

(3) I am all for expressive names. So, if it's not too much to ask, I'd recommend renaming your plugin to NodeTreePlugin and then create the following two spaces...

http://nodetreeplugin.tiddlyspace.com

for nothing but the plugin

http://nodetree.tiddlyspace.com

for demo, documentation, release notes and all that stuff

(4) Finally I got the meaning of those question marks.

So, I have modified the example a bit to make it more clear and also added some @@color:grey;inline style@@

Best wishes, Tobias.

[Tobias Beer]

Hi again,

I have commited the above MOD to my repo on Github and did some commenting...

https://github.com/tobibeer/TiddlyWikiPlugins/commit/ecf90924f81fa6bc13561af19491986f0d7ddcc2

For the readable source code by itself, see...

https://github.com/tobibeer/TiddlyWikiPlugins/blob/master/mods/NodeTreePlugin.js

Best wishes, Tobias.

[G.J.Robert]

Hi, I'm back. I was playing with PolyGlotPlugin on my new space and went out for a class so have to catch up with the progress during the last hours ;-) Very happy to see your feedbacks and even quite a few improvements which I must learn to do. Great!

Tobias Beer於 2013年9月12日星期四UTC+8下午5時04分42秒寫道：

Hi,

I think, the two following features could be interresting:
* Before any vertical bar, having an horizontal bar centered on the parent node,

I second that, guess I'd like it to see it like this with rather small lines, just the slightes visual clue...

Hi Eskha, actually I have tried to use a "tp:after" declaration with "display: table-cell" to hold the short bar after the parent node as you said, but I failed because the little bar was appear inline "right after" any text but not linked to the vertical bar itself. With my poor CSS knowledge I couldn't figure out why it did not behave as expected, so I gave up, and that's why in the initial releases there were no such good little starting bars.

But thanks to Tobias, in 0.5.0 we are having them, just applying the image to the right of the parent node! That simple. I just couldn't think of this. Ha!
 

 

* Having a syntax to do vertical diagrams instead of horizontal ones.

That's may be neat, too, but...

* it will result in a lot of horizontal scrolling

* it will require more of a quote style left border with those branchy things

* I guess, any second third level, etc... would have to be horizontal again for readability's sake

Best wishes, Tobias.

Besides of the concerns Tobias pointed out, this design may be going beyond my ability now, so I'm sorry that I can only leave this to the community here. Maybe we can find if there are CSS snippets dealing with this...

By the way, I recall to have learn the "table-row" and "table-cell" way from discussions on Stackoverflow. Thanks to the genius' there!

[G.J.Robert]

Hi Tobias,

I'm really delighted to read all the posts above and see all the improvements you implemented. Thanks a lot for the help beyond my limitation and the new practices which I can learn from.

Mind if I leave the new plan for tomorrow of UTC+8 here? ;-) Here's my plan:

1. Short-term (tomorrow or these days)
1. Create the two spaces with the proposed NodeTree name :) (So this is an acception to the GitHub comment :) )
   
• actually I have already created "@treedgplugin" hours ago and was going to make it a pure plugin-space as you have instructed, but then I got diverted to PolyGlotPlugin...ha... Things you see were done half way and hung there. So the white theme I used on @treedg was to give the doc space a beautiful look.
  
• host NodeTreePlugin 0.5.0 mod at @nodetreeplugin. Do you mind if I put your name on the author or contributor field, and normalize the mod as a new release based on your changes?
• I have also been thinking about hosting all the plugin docs together at one space like @gjrobert-tw, so this way I do not create doc spaces each dedicated for every one plugin. How do you think of such practice? Feasible?
1. Reply to the posts above and explain and discuss in detail.
2. Reply to the GitHub comments.
2. Long-term (in a few weeks hopefully)
1. Improve the demos and share how I use the trees with multiline contents
2. See if the documentation needs more amendments

See you later :-)

Love and peace,

GJRobert

Tobias Beer於 2013年9月12日星期四UTC+8下午8時14分40秒寫道：

[Kosmaton]

Hello,

I'm finding that when I load my tiddlyspace page, it now displays the
SiteInfo tiddler by default, which wasn't the case last time I checked.
This interferes with the design of that particular page.

What caused/motives the change? Can I disable it?

cheers,

~K

--
♾ http://veminra.net ♾

[Tobias Beer]

Hi GJRobert,

Firstly, I have made another few commits...

https://github.com/tobibeer/TiddlyWikiPlugins/commit/4463356dbf170ef8b783cbcac669c09130aaedd6

The images are actually now created in the StyleSheet shadow which makes it easier to modify for an end user... see commit comments.

I'm really delighted to read all the posts above and see all the improvements you implemented. Thanks a lot for the help beyond my limitation and the new practices which I can learn from.

I think you've written a beautiful plugin there. Not a lot of limitations, I find. ;-)

Mind if I leave the new plan for tomorrow of UTC+8 here? ;-) Here's my plan:

Great to see you taking up on this. It's not that I want to force people to do things my way. So, feel free to disregard whatever you like to do differently. Also,t ake your time, no need to hurry... you want to rename your plugin? Just do it, it's not like people have been depending on it for years now. ;-)

Create the two spaces with the proposed NodeTree name :) (So this is an acception to the GitHub comment :) )

Good, me likes. ;-)

Actually, I just took the half an hour and created both spaces...

http://nodetree.tiddlyspace.com

http://nodetreeplugin.tiddlyspace.com

actually I have already created "@treedgplugin" hours ago and was going to make it a pure plugin-space as you have instructed, but then I got diverted to PolyGlotPlugin...ha... Things you see were done half way and hung there. So the white theme I used on @treedg was to give the doc space a beautiful look.

 

Yes, a nice presentation is always desireable over a plain plugin look.

host NodeTreePlugin 0.5.0 mod at @nodetreeplugin. Do you mind if I put your name on the author or contributor field, and normalize the mod as a new release based on your changes?

 

Of course not, modify / incorporate to your liking.

I have also been thinking about hosting all the plugin docs together at one space like @gjrobert-tw, so this way I do not create doc spaces each dedicated for every one plugin. How do you think of such practice? Feasible?

You can / should do that. That's another approach of doing things. I just fear that my space might get way to crowded and stuff hard to find, so I make a documentaiton space for every plugin. Makes it easier to find actual plugin related stuff, like examples, etc... and keep things separate.

Sure, a nice presentation in a personal space is something I will be doing shortly too.

> Reply to the posts above and explain and discuss in detail.

> Reply to the GitHub comments.

> Long-term (in a few weeks hopefully)

1. See if the documentation needs more amendments

1. Improve the demos and share how I use the trees with multiline contents

Sure, take your time. What is really interesting is how this can be leveraged / combined in a kind of "related tiddlers" manner, e.g. what RelatedTiddlersPlugin and http://tobibeer.tiddlyspace.com/#x-plore do, only differently... in an interactive manner.

Imagine this...

Starting from a root tiddler, a *new* plugin determines the tagging tree, perhaps two levels deep deep and renders it using NodeTreePlugin. However, when a user clicks a node at the far right that itself has tagging tiddlers, the nodetree is rerendered and the tree you clicked is presented as the new root node, or rather one in the middle, so you can go back to any parent(s).

Depending on the position where we are and whether or not there are still children or parents, NodeTreePlugin is leveraged to render the current position and focus on the node that was clicked, while automatically scrolling right<>left in order to get to the next level of tagging tiddlers.

This could be differnet types of relations, not necessarily tagging, could be linking as well. In fact, the perfect NodeTreeBrowser could easily show both, tagging and linking relations, using differnet colors.

Best wishes, Tobias.

[Tobias Beer]

Hi Kosmaton,

I'm finding that when I load my tiddlyspace page, it now displays the
SiteInfo tiddler by default, which wasn't the case last time I checked.
This interferes with the design of that particular page.

Mhhh, that's not so good. Sorry for the inconvenience. I guess that is due to me having modified a bunch of plugin spaces to automatically show the SiteInfo tiddler on startup. One way to "fix" this is to create your own version of DefaultTiddlers rather than use the default.

The thing is, as a plugin publisher, I have to die one death or another, either my plugin space ends up overwriting someone elses GettingStarted their DefaultTiddlers... I have decided to do the latter.

Actually, I think the DefaultTiddlers tiddler should be another one of those public tiddlers automatically created on space creation to its default content.

Best wishes, Tobias.

[G.J.Robert]

Tobias Beer於 2013年9月12日星期四UTC+8下午8時02分54秒寫道：

Hi,

I must say Robert, I quite like this plugin! Has a lot of potential.

(1) I have played a bit with it and made use of Base64...

http://tbdev.tiddlyspace.com/#NodeTreePlugin

Like that it's all just one plugin, no additional images. ;-)

Great for single-file TW users then! Love this practice and thanks for the lesson :)

Btw, Tobias, I have a feeling that your Base64 images are not as black as my old images (you can find v0.4 on @treedgplugin now). How do you see them? If they are indeed not equal in the grey scale, is this due to the resolution and scaling of the image? I have to admit that I like black and sharper lines better :-p Is there a way to keep using Base64 images while making the bars blacker and sharper?

(2) By the way, I have added that parent indicator, too.

This is also a major breakthrough into v0.5! I have tried to use "tp:after" displayed as table-cell but failed (bug of the browser?) Thanks for adding this!

(3) I am all for expressive names. So, if it's not too much to ask, I'd recommend renaming your plugin to NodeTreePlugin and then create the following two spaces...

http://nodetreeplugin.tiddlyspace.com

for nothing but the plugin

http://nodetree.tiddlyspace.com

for demo, documentation, release notes and all that stuff

Thanks for building these two spaces ;-) I'll add on @nodetree.

(4) Finally I got the meaning of those question marks.

Yeah... Sorry for not having written the doc more clearly.

My idea was that we use % marks just as we use * or # for lists levels. But before I use images as bars, I can only use right borders of the parent node to make the vertical bar and they definitely link together with their cousins, so spacers were needed. So I used question marks as spacer items. And since it belongs to the TiddlyWiki list algorithm, the number of the marks denotes the level depth.

Later I found that questions marks at the beginning of lines conflict with my adapted MediaWikiTableFormatterPlugin (another story: I changed the exclamation mark to question marks for <th> cells because exclamation marks break tiddler sections!). So I added slashes as an alternative of questions marks. So actually they play the same role as spacers!

So, I have modified the example a bit to make it more clear and also added some @@color:grey;inline style@@

Looks clear this way. Or how about giving the <ts> elements a default grey color?

Best wishes, Tobias.

[G.J.Robert]

Tobias Beer於 2013年9月12日星期四UTC+8下午6時06分02秒寫道：

Ha, I forgot from which plugin I learned to attach the stylesheet at the end of the plugin that way, but I have also noticed that there were no shadow tiddlers created after all. I did not know how to improve the situation though. Thanks for fixing this. :-)
 

Best wishes, Tobias.

[G.J.Robert]

Tobias Beer於 2013年9月12日星期四UTC+8下午5時47分02秒寫道：

Some more things...

(a) I see your space ships with these simplistic grahpics.

I don't think you need those and so I think you should get rid of them. All you need is a bordera simplistic Base64 encoded 1x1 pixel held by a section or slice or variable in your plugin... which you then stretch either horizontally or vertically to the desired size. No resources external to the plugin are needed. You simply render this as...

<img src="data:image/gif;base64,R0lGODlhAQABALMAAICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAABAALAAAAAABAAEAAAgEAAEEBAA7" style:"height:1px;width:100px:"/>

...or the appropriate background image.

background-image: url([[TreeDiagramFormatterPlugin::pixel]]);

As before, this could be defined by the user to whatever he likes using css. Your ts:before would then need some defined width or height.

(b) what on earth are <tp>, <tl>, <ts> elements

?!?

Ha, there are actually:

• <tl> = tree lists, just like "ol" "ul" "dl"
• <ti> = tree items, just like "li"
• <tp> = tree parent nodes
• <ts> = tree separators/spacers

I thought of using table cells and borders to make such a tree diagram in the first place, but I knew this would take too many markups. After searching on Stackoverflow, I found someone sharing about "display: table-row/table-cell", so I decided to combine this CSS trick with the TiddlyWiki list markup mechanism, creating new elements without using CSS classes, because I don't want to use {{css{wrappers}}} per item. Fortunately it worked with acceptable layouts (only that the bars were very ugly before v0.4).

 

(c) a tree should by default be wrapped into some span with a class .treedg

In the first place I did design to use a class to wrap the whole tree, that was when I was still thinking of table markups and using CSS rules like ".treedg td/tr/th". But later when I changed to list model and new elements, I abandoned the overall class wrapper. It seems that we can do without it, how do you think?
 

(d) right now I am playing with getting rid of images entirely and putting nothing but borders

It's a pity that CSS does not offer "border: upper-half/lower half" :-p

MediaWiki cladograms use borders, but based on nested tables. The output is very clean, but I found it too hard and too complicated to implement with TiddlyWiki markups... (perhaps have to write another plugin like MediaWikiTableFormatterPlugin)
 

[Tobias Beer]

Ha, there are actually:

• <tl> = tree lists, just like "ol" "ul" "dl"
• <ti> = tree items, just like "li"
• <tp> = tree parent nodes
• <ts> = tree separators/spacers

I thought of using table cells and borders to make such a tree diagram in the first place, but I knew this would take too many markups. After searching on Stackoverflow, I found someone sharing about "display: table-row/table-cell", so I decided to combine this CSS trick with the TiddlyWiki list markup mechanism, creating new elements without using CSS classes, because I don't want to use {{css{wrappers}}} per item. Fortunately it worked with acceptable layouts (only that the bars were very ugly before v0.4).

The bit I am missing is where I don't find TL, TI, TP, TS in an HTML spec. So, I presume this is markup you have invented yourself and for some reason the browser doesn't care (interprets it as a span) and applies some custom css to it? I never knew this was possible / allowed.

 

(c) a tree should by default be wrapped into some span with a class .treedg

In the first place I did design to use a class to wrap the whole tree, that was when I was still thinking of table markups and using CSS rules like ".treedg td/tr/th". But later when I changed to list model and new elements, I abandoned the overall class wrapper. It seems that we can do without it, how do you think?

I think it is more intuitive to know there's a <span class="nodetree"/> wrapped around it and then be able to style that with paddings margins backgrounds and what not rather than to have to do this all the time...

{{nodetree{

&&parent&&

%chilc

%child

}}}

 

(d) right now I am playing with getting rid of images entirely and putting nothing but borders

It's a pity that CSS does not offer "border: upper-half/lower half" :-p

MediaWiki cladograms use borders, but based on nested tables. The output is very clean, but I found it too hard and too complicated to implement with TiddlyWiki markups... (perhaps have to write another plugin like MediaWikiTableFormatterPlugin)

I wouldn't bother. I tried for 10 minutes, thought... well, of course, it's not that simple... and didn't want to bother inenting it. End of borders for me.

Best wishes, Tobias.

[Kosmaton]

Thanks Tobias!

That was a quick fix -- a small inconvenience for the benefit of using your plugins :) Could have been twyp or TagSearchPlugin...

Yes, I suppose it would be good if a fresh space would include a blank DefaultTiddlers to evade this issue. Or if for some reason this has downsides, something that warns the user.

Kosmaton

-- 
♾ http://veminra.net ♾

[Chris Dent]

On Friday, September 13, 2013 7:51:08 AM UTC+1, Kosmaton wrote:

Yes, I suppose it would be good if a fresh space would include a blank DefaultTiddlers to evade this issue. Or if for some reason this has downsides, something that warns the user.

It would need to be something other than blank, presumably whatever the default is at the moment.

Adding this wouldn't be too difficult but it seems a bit of a slippery slope. How many more will we need?

[Tobias Beer]

Hi Chris,

Well, as I said, either they get my SiteInfo or they get my DefaultTiddlers ...I decided for it being SiteInfo (and tagging to DefaultTiddlers) to be ok.

After all, a SiteInfo tiddler shouldn't be something more vital to a space than whatever is in some GettingStarted tiddler. As for the latter, I believe a GettingStarted space is muuuuuch more appropriate and maintainable... seing how much false and irrelevant stuff is in the current GettingStarted. o.O

Best wishes, Tobias.

[G.J.Robert]

Tobias Beer於 2013年9月13日星期五UTC+8下午3時15分02秒寫道：

Ha, there are actually:

• <tl> = tree lists, just like "ol" "ul" "dl"
• <ti> = tree items, just like "li"
• <tp> = tree parent nodes
• <ts> = tree separators/spacers

I thought of using table cells and borders to make such a tree diagram in the first place, but I knew this would take too many markups. After searching on Stackoverflow, I found someone sharing about "display: table-row/table-cell", so I decided to combine this CSS trick with the TiddlyWiki list markup mechanism, creating new elements without using CSS classes, because I don't want to use {{css{wrappers}}} per item. Fortunately it worked with acceptable layouts (only that the bars were very ugly before v0.4).

The bit I am missing is where I don't find TL, TI, TP, TS in an HTML spec. So, I presume this is markup you have invented yourself and for some reason the browser doesn't care (interprets it as a span) and applies some custom css to it? I never knew this was possible / allowed.

Ah, actually I think I have mixed HTML up with XHTML... I have read that in XHTML 1.1 we can write any new element as we like, and then using CSS to style it. I am actually not aware when the tide changes to HTML5, so I thought using TiddlyWiki formatter extensions to generate new elements is a good way to avoid having to generate CSS classes on standard elements (because I don't know how to do it...) Fortunately the Firefox allows this... :-p

Would there be any bad potentials with this practice?
 

 

(c) a tree should by default be wrapped into some span with a class .treedg

In the first place I did design to use a class to wrap the whole tree, that was when I was still thinking of table markups and using CSS rules like ".treedg td/tr/th". But later when I changed to list model and new elements, I abandoned the overall class wrapper. It seems that we can do without it, how do you think?

I think it is more intuitive to know there's a <span class="nodetree"/> wrapped around it and then be able to style that with paddings margins backgrounds and what not rather than to have to do this all the time...

{{nodetree{

&&parent&&

%chilc

%child

}}}

Yeah, I get your point. Dedicated CSS wrapper is indeed good for styling. Besides of manually input the wrapper, Is there a way to let the plugin to generate the wrapper div automatically (without explicit codes or with them?)
 

[Tobias Beer]

Hi GJRobert,

 

Ah, actually I think I have mixed HTML up with XHTML... I have read that in XHTML 1.1 we can write any new element as we like, and then using CSS to style it. I am actually not aware when the tide changes to HTML5, so I thought using TiddlyWiki formatter extensions to generate new elements is a good way to avoid having to generate CSS classes on standard elements (because I don't know how to do it...) Fortunately the Firefox allows this... :-p

Would there be any bad potentials with this practice?

For all I care (right now), all major browsers render it correctly, except IE which even at version 10 is too illiterate to translate :before and :after selectors. Chances are that TW in general or one with NodeTreePlugin in it won't pass a validator test, so perhaps it is more advisable to use all spans and give them corresponding classes, e.g. nt-parent, nt-list, nt-item, nt-separator, etc... and cuck all that in some outer nodetree wrapper.

I think it is more intuitive to know there's a <span class="nodetree"/> wrapped around it and then be able to style that with paddings margins backgrounds and what not rather than to have to do this all the time...

{{nodetree{

&&parent&&

%chilc

%child

}}}

Yeah, I get your point. Dedicated CSS wrapper is indeed good for styling. Besides of manually input the wrapper, Is there a way to let the plugin to generate the wrapper div automatically (without explicit codes or with them?)

To be honest, I do not fully comprehend how exactly the actual formatter code works. If you can walk me through that some time, I'd appreciate. In general, I would think that a <tl> would semantically be contained inside a <tp> rather than follow it... this would definetely remove the need for an additional class as we'd have our <tp> wrapping it all. But then the actual tree parent content would have to be wrapped again in some ".nt-parent" class so as to separate it from the adjacent <tl> in terms of being able to style it, i.e give it that background image and perhaps some other visual characteristics later on.

- tobias

[chris...@gmail.com]

On Fri, 13 Sep 2013, Tobias Beer wrote:

> Well, as I said, either they get my SiteInfo or they get my DefaultTiddlers
> ...I decided for it being SiteInfo (and tagging to DefaultTiddlers) to be
> ok.

For spaces created in the last year they won't "get" your SiteInfo as
every new space gets one created for it (as well as a GettingStarted).
So yours will be clobbered by the recipe cascade.

If your space has a DefaultTiddlers and theirs does not then they will
get that.

What I would suggest you do for a space designed for inclusion is:

* Not change DefaultTiddlers, use the existing shadow.
* Edit GettingStarted to include getting started info and transclude
SiteInfo

Then, visitors will see what your space is about but when they include
it they will not get SiteInfo, nor DefaultTiddlers nor GettingStarted.

> After all, a SiteInfo tiddler shouldn't be something more vital to a space
> than whatever is in some GettingStarted tiddler.

I don't undertand this statement. The SiteInfo is designed to be
exactly that: the description of the space, including tags which
indicate it's meaning[1].

> As for the latter, I
> believe a GettingStarted space is muuuuuch more appropriate and
> maintainable... seing how much false and irrelevant stuff is in the current
> GettingStarted. o.O

Could you elaborate and if possible provide improvements?

[1]: See http://tsiscover.tiddlyspace.com/tsiscover for some
experimentation on how SiteInfo and its tags could be used.

--
Chris Dent http://burningchrome.com/
[...]

[Tobias Beer]

Hi Chris,

I tend to disagree.

For spaces created in the last year they won't "get" your SiteInfo as
every new space gets one created for it (as well as a GettingStarted).
So yours will be clobbered by the recipe cascade.

I don't want them to get my SiteInfo, that's the whole point. Mine stays where it is and it should never overrule theirs. In fact, a SiteInfo should not be deletable (as a tiddler or otherwise).

If your space has a DefaultTiddlers and theirs does not then they will
get that.

And they should, because that's how inclusion works and I don't think it should quite work like that. Not only should SiteInfo be prohibited from being included but also DefaultTiddlers unless I, as the owner of the including space, explicitly chose it... e.g. "Overwrite this tiddler with the one from space xyz"... however, still as a locally saved tiddler!

What I would suggest you do for a space designed for inclusion is:

* Not change DefaultTiddlers, use the existing shadow.
* Edit GettingStarted to include getting started info and transclude
   SiteInfo

I understand the pragmatic approach behind you promoting the status quo in these matters. However, I think it cements how this both poor and *faulty* current version of a GettingStarted tiddler is being cemented in new spaces... which is something I find hard to support. Hardly anyone is helped by it. GettingStarted should *not* be some tidbit leveraging a macro to create a new ColorPalette. Stuff like that could and should rather easily be loaded on-demand via remoting. Instead, it should be a platform to guide new users with more or less complex desires to meet certain ends... *not* by virtue of being part of a space, but by providing meaningful entry-points to a well-structured knowledge base... or load wizard like functionality on-demand, on space creation or later.

Then, visitors will see what your space is about but when they include
it they will not get SiteInfo, nor DefaultTiddlers nor GettingStarted.

I see how my changes added DefaultTiddlers to the mix and I emphasize *again* that this tiddler should *not* be one that is ever included. Instead it should be *created* on space creation with the bare minimum of default contents. Getting started should read... "Click [[here|http://getstarted.tiddlyspace.com]] on how to get started on TiddlySpace"... SiteInfo is already initialised meaningfully. If an app or theme or whatever depends on a given default-tiddler it needs dedicated instructions for making such an adjustment.

I do understand that changing such things may result in people asking questions, hello Kosmaton ;-) But I see no sense whatsoever in having a GettingStarted tiddler that reads...

<<tiddler SiteInfo>>

Sure, it's a bit of a purist approach to even remove that, being me. But, as I said, SiteInfo *is* (currently) very much an integral part to qualify a space and should be the one being loaded via DefaultTiddlers ..unless the latter is explicitly modified. A generic space knows and should not know a GettingStarted tiddler or manifest some current version of a poor-man's instruction manual saying "while you may modify this, please point to the original GettingStarted if you plan on distributing your space". I think this approach makes no sense. GettingStarted is *not* a version of some tiddler being shipped and cemented on space creation.

> After all, a SiteInfo tiddler shouldn't be something more vital to a space
> than whatever is in some GettingStarted tiddler.

I don't undertand this statement. The SiteInfo is designed to be
exactly that: the description of the space, including tags which
indicate it's meaning[1].

Other than taking a closer look by visiting a space, a SiteInfo tiddler is what tells the outside world what this space is about. I find both the TiddlySpace or TiddlyWiki GettingStarted tiddlers to essentially be for the bin. Personally, I never used it and it's one of the first things I get rid of ...a start tiddler in CamelCase, bah.

> As for the latter, I
> believe a GettingStarted space is muuuuuch more appropriate and
> maintainable... seing how much false and irrelevant stuff is in the current
> GettingStarted. o.O

Could you elaborate and if possible provide improvements?

GettingStarted is *not* a control panel nor a feature loaded wizard, to me. It might one day be a tiddler able to load wizard-type features via ajax, on-demand. If we want a ControlPanel, create that... and remove those "admin" tabs from SideBarTabs.

To me, a space has a ominant presentational side to it, being all includable, etc. While a default TW does it, I don't think a default TiddlySpace should show some spaces-, public-, private-, drafts-, missing-, or orhpans-tabs. These are things relevant for the owner / editor of a space... not a visitor. They should also not be in some imposing "backstage cloak" but be part of a tiddler living side-by-side with any other tiddler... in order to easily switch back and forth rather than to open and close that panel that covers it all.

I think it is more important to think of spaces as a presentational platform and whichever non-tiddlyspace-member visits it might just know little to nothing about TiddlySpace, or about tabs or "missing" or "public" tiddlers or (included) "spaces" or backstage panels. In this case, usability is predominantly the usability provided to those interested in the contents created by a space owner.

In other words... "What is TiddlySpace being used for?" answers the questions as to what use cases and goals it is being optimized for. I am quite certain that the home-tiddler of a space *must not* depend on what is being included by means of a plugin, theme or whatever. My personal conviction is that — to make things right — you should PUT a meaningful DefaultTiddler (if non-existing) into ny of those 12000 spaces not defining a DefaultTiddlers tiddler. The front door of some space does *not* depend on the space owner shopping for a bouquet of flowers or the type of front door of that flower shop.

Consider this me being the devils advocate. If it literally is easy for you to *fix* the DefaultTiddlers tiddler of spaces that do not define one, I strongly advice to do that rather than ask me to change my publishing pattern. A landing page to a space must *never* depend on any feature it hopes to leverage, unless explicitly opted-in.

- tobias

[Tobias Beer]

Hi Chris,

[1]: See http://tsiscover.tiddlyspace.com/tsiscover for some
experimentation on how SiteInfo and its tags could be used.

As a sidenote, I have added tsiscover to @customize for reference...

http://customize.tiddlyspace.com/#Tsiscover 

best wishes,

- tb

[chris...@gmail.com]

On Sun, 15 Sep 2013, Tobias Beer wrote:

> I tend to disagree.

I have to admit that I've had trouble parsing your message and teasing
out the real issues, goals and concerns. If I've misunderstood
something please correct me.

In any case I've responded within.

> For spaces created in the last year they won't "get" your SiteInfo as
>> every new space gets one created for it (as well as a GettingStarted).
>> So yours will be clobbered by the recipe cascade.
>
> I don't want them to get my SiteInfo, that's the whole point. Mine stays
> where it is and it should never overrule theirs.

Right, and for spaces which are following the currents standards, they
won't.

> In fact, a SiteInfo should not be deletable (as a tiddler or otherwise).

Why?

It's a tiddler it is supposed to be operable in the same way as any
other tiddler. Special casing tiddlers seems inflexible and the
architecture is predisposed towards flexibility.

> If your space has a DefaultTiddlers and theirs does not then they will
>> get that.
>
> And they should, because that's how inclusion works and I don't think it
> should quite work like that. Not only should SiteInfo be prohibited from
> being included but also DefaultTiddlers unless I, as the owner of the
> including space, explicitly chose it... e.g. "Overwrite this tiddler with
> the one from space xyz"... however, still as a locally saved tiddler!

The way you make it so a space can't include a tiddler from your space
is by _not having that tiddler_ in your space, which is what I've
suggested. If you don't want people to include a DefaultTiddlers,
don't have one.

If you need a DefaultTiddlers in order for people to understand your
concept then have a docs space which includes your plugin space and
_tell_ people through the magic of communication to include the plugin
space, not the docs space.

I recognize that some poeple might see this an imposition but the
current ethic surrounding TiddlySpace is not only the assumption that
people are literate but that they _should_ be literate.

As currently constructed TiddlySpace is not tiddlers-for-dummies.
While having such a thing exist would be glorious nobody is currently
putting in the work to make it happen. We've got two choices at the
moment: accept and adapt to how things are now or provide pull
requests with improvements.

> What I would suggest you do for a space designed for inclusion is:
>>
>> * Not change DefaultTiddlers, use the existing shadow.
>> * Edit GettingStarted to include getting started info and transclude
>> SiteInfo
>
> I understand the pragmatic approach behind you promoting the status quo in
> these matters.

This is not entirely the status quo. It's a relatively new mode. It
used to be that most space didn't have a SiteInfo automatically so the
above would not work.

Things do evolve and change, quite often. In fact I've asked you to
provide me with a concrete alternative but I haven't been able to
understand it yet. If you do and/or I'm able to understand it and it
makes sense then perhaps we can change things. But first I (and
others) need to understand.

> However, I think it cements how this both poor and *faulty*
> current version of a GettingStarted tiddler is being cemented in new
> spaces...

I'm still unclear on how GettingStarted is broken?

And it certainly isn't cemented: Everyone gets to change it however
they like. Or they can change DefaultTiddlers so it goes away. There
are options. It sounds like you want to make it so there are fewer?

> which is something I find hard to support. Hardly anyone is
> helped by it. GettingStarted should *not* be some tidbit leveraging a macro
> to create a new ColorPalette. Stuff like that could and should rather
> easily be loaded on-demand via remoting. Instead, it should be a platform
> to guide new users with more or less complex desires to meet certain
> ends... *not* by virtue of being part of a space, but by providing
> meaningful entry-points to a well-structured knowledge base... or load
> wizard like functionality on-demand, on space creation or later.

So your issue with GettingStarted is that it provides a stand in for
applications that ought to exist but do not yet?

This is very true. It would be good for those applications to exist,
but they don't right now so we need something. GettingStarted is what
we've got.

>> Then, visitors will see what your space is about but when they include
>> it they will not get SiteInfo, nor DefaultTiddlers nor GettingStarted.

So, right now (for a modern space) they won't get a SiteInfo and they
won't get a GettingStarted. They'll only get a DefaultTiddlers. If
_you_ don't want one, don't use one in your space, or go ahead and
agree to my earlier question: Should we make DefaultTiddlers one of
the tiddlers that get automatically created during space creation?

> I see how my changes added DefaultTiddlers to the mix and I emphasize
> *again* that this tiddler should *not* be one that is ever included.
> Instead it should be *created* on space creation with the bare minimum of
> default contents. Getting started should read... "Click
> [[here|http://getstarted.tiddlyspace.com]] on how to get started on
> TiddlySpace"... SiteInfo is already initialised meaningfully. If an app or
> theme or whatever depends on a given default-tiddler it needs dedicated
> instructions for making such an adjustment.

So let me see if I can parse out what you are saying, please correct
me where I am wrong:

* DefaultTiddlers _should_ be created at space creation time.
* GettingStarted should be tiny and point elsewhere to info.

If this is the case, that seems fine, but there's no point doing the
second point until that content exists.

> I think it is more important to think of spaces as a presentational
> platform and whichever non-tiddlyspace-member visits it might just know
> little to nothing about TiddlySpace, or about tabs or "missing" or "public"
> tiddlers or (included) "spaces" or backstage panels. In this case,
> usability is predominantly the usability provided to those interested in
> the contents created by a space owner.

It is true that at the moment TiddlySpace's interface is predisposed
to the members of a space. This was by design. The plan was to then
move on to the non-member experience but, well, everyone left.

It is encouraging that you have such interest and so many ideas, but
what we need in addition is people making changes to the code, doing
the open source thing.

[Tobias Beer]

Hi Chris,

First of all, I hope my somewhat challenging tone was ok...

Things do evolve and change, quite often. In fact I've asked you to
provide me with a concrete alternative but I haven't been able to
understand it yet. If you do and/or I'm able to understand it and it
makes sense then perhaps we can change things. But first I (and
others) need to understand.

The alternative is really straight forward. for me, the home tiddler of a space is by default defined by the space, not by some shadow default that is easily overwritten via inclusion.

Ergo, I think these two things would make sense ...

1) change the default recipe such that a public DefaultTiddlers tiddler is created containing the TiddlyWiki default, yet not just as a shadow.

2) PUT the same into all existing spaces that do not declare one and thus are presumably quite agnostic about it or rather have the default, as I don't know of any existing "apps" that define or depend on their own.

 

I'm still unclear on how GettingStarted is broken?

For one, it speaks of some ServerSettings tiddler that neither seems to exists, nor I ever heard of or were documented in a sensible way. That's what I meant with "such contents should *never* be cemented in a space" upon creation.

 

And it certainly isn't cemented: Everyone gets to change it however
they like. Or they can change DefaultTiddlers so it goes away. There
are options. It sounds like you want to make it so there are fewer?

What I mean with cemented is that the information it contains is going to be outdated, yet will stay, likely being false after a few months, even years. I believe most people don't even change it or care for it, especially when it contains information that does not reflect anything that can actually be found, e.g. some ServerSettings control-panel'ish type of thing.

So your issue with GettingStarted is that it provides a stand in for
applications that ought to exist but do not yet?

My issue with GettingStartes is that all it should contain are pointers to immutable references that actually help in GettingStarted in a comprehensive, yet concise, mostly guided manner. This tiddler should not be one big fat GettingStarted-compendium stored in a space ...there simply is too much to consider and having a different ColorPalette is not even one of the more critical things.

This is very true. It would be good for those applications to exist,
but they don't right now so we need something. GettingStarted is what
we've got.

I don't think we necessarily do need wizard-like apps loaded on-demand. Those might some day be the icing on the cake. Although the RandomColorPalette thingy would be a rather neat candidate for some prototypish wizard loaded on-demand.

What I think were a step in the right direction is a GettingStarted space that thoughtfully guides new or existing users when trying to figure out certain concerns, and which provides details on meeting certain ends, overcoming known issues, topics like how to get / set up / work with themes, localisations, plugins and what not ...starting by guiding different personas to possibly different sets of Q&A based on: What is it that the user want to achieve on TiddlySpace?

So, right now (for a modern space) they won't get a SiteInfo and they
won't get a GettingStarted.

I *o* get it, because I always delete the latter. Should I (not) care? Not sure.

 

They'll only get a DefaultTiddlers. If
_you_ don't want one, don't use one in your space, or go ahead and
agree to my earlier question: Should we make DefaultTiddlers one of
the tiddlers that get automatically created during space creation?

Yes, I think we should. The starting point of a space is not something that should be easily overwritten via inclusion ...if at all, for 99% of spaces it's content, not functionality coming from included spaces.

Now, to make themes work it is kinda required to not initialise or set a default ColorPalette or StyleSheet... at least, I have yet to come accross a theme other than the system-theme that desires to be agnostic to defining a balanced ColorPalette for that theme. Also, to not break themes or spaces, it is kinda necessary that plugin spaces do not ship with any UI components, like a ColorPalette or StyleSheet... other than in the form of a dedicated StyleSheetPluginX created by the plugin.

So let me see if I can parse out what you are saying, please correct 
me where I am wrong:

* DefaultTiddlers _should_ be created at space creation time.
* GettingStarted should be tiny and point elsewhere to info.

That's precisely what I think. The former I want to be set (/ initialised) ...and the latter I'd prefer to see evolve in the form of a space. The actual GettingStarted tiddler would merely provide reliable access points (if not just *one*) to a more comprehensive guide... sure yet to be created, curated by TiddlySpace-pro's. Hence, I just created @GettingStarted and I'd like for it to be filled with concise information that help in getting started... whether it will end up being the sole reference contained in the actual GettingStarted tiddler or not. In fact, it would actually be nice if whatever is presented as GettingStarted in a space is pulled in via XHR from said space so as to be flexibly extensible.

 

If this is the case, that seems fine, but there's no point doing the
second point until that content exists.

That may be right. But perhaps there is no need to start with content that is mountains more comprehensive (if not bloated) than what is in the current GettingStarted tiddler... although chances are that it will be naturally better structured (not linear) and evolve ...well, being a space and all.

 

It is true that at the moment TiddlySpace's interface is predisposed 
to the members of a space. This was by design. The plan was to then
move on to the non-member experience but, well, everyone left.

;-)

 

It is encouraging that you have such interest and so many ideas, but
what we need in addition is people making changes to the code, doing
the open source thing.

I see. Would this be it...

https://github.com/TiddlySpace/tiddlyspace

?

I believe Mario was already poking in that direction. Perhaps it's time to think less of just being a user and more in terms of developer / "source (code)" contributor. We'll see how that works out. I understand that there might soon'ish be a point when you can only afford reviewing proposed commits to the codebase and then pushing them... rather than doing much active development.

Best wishes, Tobias.

[G.J.Robert]

Greetings Tobias,

Tobias Beer於 2013年9月15日星期日UTC+8上午8時28分34秒寫道：

Hi GJRobert,

 

Ah, actually I think I have mixed HTML up with XHTML... I have read that in XHTML 1.1 we can write any new element as we like, and then using CSS to style it. I am actually not aware when the tide changes to HTML5, so I thought using TiddlyWiki formatter extensions to generate new elements is a good way to avoid having to generate CSS classes on standard elements (because I don't know how to do it...) Fortunately the Firefox allows this... :-p

Would there be any bad potentials with this practice?

For all I care (right now), all major browsers render it correctly, except IE which even at version 10 is too illiterate to translate :before and :after selectors. Chances are that TW in general or one with NodeTreePlugin in it won't pass a validator test, so perhaps it is more advisable to use all spans and give them corresponding classes, e.g. nt-parent, nt-list, nt-item, nt-separator, etc... and cuck all that in some outer nodetree wrapper.

I see. IE10 cannot even parse :before and :after correctly? That sounds horrible. If IE has this limitation, will it improves the situation on it if we change the custom elements <tl> <ti> <tp> <ts> to spans?

From the point of Web standard, I agree that safe elements are more feasible. Since all I did in sketching this plugin was just looking at the TiddlyWiki core list formatters and see if there is an easy door to extend and implement something simple in the similar way, I may need more studies in how other plugins handles to create more flexible and ideal elements. Hope that I can catch up soon :-)

I think it is more intuitive to know there's a <span class="nodetree"/> wrapped around it and then be able to style that with paddings margins backgrounds and what not rather than to have to do this all the time...

{{nodetree{

&&parent&&

%chilc

%child

}}}

Yeah, I get your point. Dedicated CSS wrapper is indeed good for styling. Besides of manually input the wrapper, Is there a way to let the plugin to generate the wrapper div automatically (without explicit codes or with them?)

To be honest, I do not fully comprehend how exactly the actual formatter code works. If you can walk me through that some time, I'd appreciate. In general, I would think that a <tl> would semantically be contained inside a <tp> rather than follow it... this would definetely remove the need for an additional class as we'd have our <tp> wrapping it all. But then the actual tree parent content would have to be wrapped again in some ".nt-parent" class so as to separate it from the adjacent <tl> in terms of being able to style it, i.e give it that background image and perhaps some other visual characteristics later on.

Alright. I'll explain how my graffiti works soon and maybe we can see how this plugin may be re-written to meet a standard and better rationale.

- tobias

Cheers,
GJRobert

[Tobias Beer]

Hi GJRobert,

 

I see. IE10 cannot even parse :before and :after correctly? That sounds horrible. If IE has this limitation, will it improves the situation on it if we change the custom elements <tl> <ti> <tp> <ts> to spans?

This compatibility chart...

http://msdn.microsoft.com/en-us/library/hh781508(v=vs.85).aspx

Says that with ie9 all of the following are supported...

:before

:after

:first-of-type

:last-of-type

:only-of-type

:only-child

Anyhow, this is what it looks like in ie 10...

Seeing how the background image of the tp is properly displayed, I concluded that data:// URLs are working and that it must be a problem with something else.

I thought there might be something in ie that allows certain (pseudo-)selectors to only be allowed for white-listed elements. Considering how HTML knows no tp, tl, ti and ts... so, I tested it using DIVs with classes... to no avail, see here...

http://tbdev.tiddlyspace.com/#NodeTreePlugin

So, right now, I'm not sure what the problem is in ie... or what is failing. All I see in the devtools is that the corresponding css is displayed as strikethrough.

From the point of Web standard, I agree that safe elements are more feasible. Since all I did in sketching this plugin was just looking at the TiddlyWiki core list formatters and see if there is an easy door to extend and implement something simple in the similar way, I may need more studies in how other plugins handles to create more flexible and ideal elements. Hope that I can catch up soon :-)

Not sure what you mean with more flexible or ideal elements. Sure, I'd prefer elements people know, e.g. span or div.

 

Alright. I'll explain how my graffiti works soon and maybe we can see how this plugin may be re-written to meet a standard and better rationale.

Not sure if it needs exhaustive rewriting or just a simple swap of lines. Take your time, for now it works in the environment I work with.

Best wishes, Tobias.

[chris...@gmail.com]

On Mon, 16 Sep 2013, Tobias Beer wrote:

> First of all, I hope my somewhat challenging tone was ok...

Quite fine, welcomed in fact. Just understand that I and anyone else
will respond in kind and that at this stage in the development of the
project(s) and your level of engagement with the project(s) that what
matters most is not suggestions but implementations. Your efforts have
been great, so I'm not trying to suggest that nobody is noticing all
the great things you have done, but rather that it's a job that's
never done, for all of us.

> The alternative is really straight forward. for me, the home tiddler of a
> space is by default defined by the space, not by some shadow default that
> is easily overwritten via inclusion.

Just made this:

https://github.com/TiddlySpace/tiddlyspace/issues/1101

> Ergo, I think these two things would make sense ...
>
> 1) change the default recipe such that a public DefaultTiddlers tiddler is
> created containing the TiddlyWiki default, yet not just as a shadow.

It's not a matter of changing the recipe (see the ticket).

> 2) PUT the same into all existing spaces that do not declare one and thus
> are presumably quite agnostic about it or rather have the default, as I
> don't know of any existing "apps" that define or depend on their own.

I'm not happy with backfilling tiddlers into existing spaces. There
are few enough active spaces that have some that are not in line with
the

Especialy since DefaultTiddlers is a TiddlyWiki requirement not a
TiddlySpace requirement: It would be hard to sure if a space was or
was not using TiddlyWiki.

> For one, it speaks of some *ServerSettings *tiddler that neither seems to

> exists, nor I ever heard of or were documented in a sensible way. That's
> what I meant with "such contents should *never* be cemented in a space"
> upon creation.

Right below where it mentions that tiddler it links to:

http://docs.tiddlyspace.com/ServerSettings%20shadow%20tiddler

Yes, that's somewhat new, so _older_ GettingStarted tiddlers don't
have it, supporting your case that the content should not be frozen.

> What I think were a step in the right direction is a GettingStarted space
> that thoughtfully guides new or existing users when trying to figure out
> certain concerns, and which provides details on meeting certain ends,
> overcoming known issues, topics like how to get / set up / work with
> themes, localisations, plugins and what not ...starting by guiding
> different personas to possibly different sets of Q&A based on: What is it
> that the user want to achieve on TiddlySpace?

That's a fine idea.

>> If this is the case, that seems fine, but there's no point doing the
>> second point until that content exists.
>
> That may be right. But perhaps there is no need to start with content that
> is mountains more comprehensive (if not bloated) than what is in the
> current GettingStarted tiddler... although chances are that it will be
> naturally better structured (not linear) and evolve ...well, being a space
> and all.

Yes, one would hope so, but efforts to engage the community in the
shared generation of documentation for any of tiddlyweb, tiddlyspace
or tiddlywiki have never quite flown as much as we would like. At the
moment the tidlywiki docs on tiddlyspace are only in any relatively
good state due in large part to your singular efforts.

>> It is true that at the moment TiddlySpace's interface is predisposed
>> to the members of a space. This was by design. The plan was to then
>> move on to the non-member experience but, well, everyone left.
>
> ;-)

I should probably not state it quite like that. People left because
they were not well supported and found better opportunities elsewhere.
They were then not replaced. This is somewhat in contract with my
situation.

> I see. Would this be it...
>
> https://github.com/TiddlySpace/tiddlyspace

That is where the code is developed, yes. Some of the TiddlyWiki side
content is pulled in from elsewhere.

> I believe Mario was already poking in that direction. Perhaps it's time to
> think less of just being a user and more in terms of developer / "source
> (code)" contributor. We'll see how that works out. I understand that there
> might soon'ish be a point when you can only afford reviewing proposed
> commits to the codebase and then pushing them... rather than doing much
> active development.

Yes, this is unfortunately true. I still don't know for certain how
things are going to turn out, but it is looking quite likely that my
involvement will be decreasing.

[G.J.Robert]

Hi Tobias,

I think your test for the proposed 0.5.7 is quite good, almost the same as the original custom elements. If it is for better compatibility, I support to change <tl>, <ti> etc. to proper divs.

The only weird thing I found in my Firefox 23 is that one of the "nt-ti" is not recognized by the browser as "last-of-type", so the tree get a bit of flaw. See below (not sure if the picture can be displayed below. Google editor does not let me move it!):

I have compared the codes of 0.5.6 vs. 0.5.7, but did not find clues why that item was rendered wrong. Do you see the same result in Firefox/Chrome or other browsers?

Tobias Beer於 2013年9月17日星期二UTC+8下午9時05分39秒寫道：

[Tobias Beer]

Hi GJRobert,

I think your test for the proposed 0.5.7 is quite good, almost the same as the original custom elements. If it is for better compatibility, I support to change <tl>, <ti> etc. to proper divs.

The only weird thing I found in my Firefox 23 is that one of the "nt-ti" is not recognized by the browser as "last-of-type", so the tree get a bit of flaw. See below (not sure if the picture can be displayed below. Google editor does not let me move it!):

I have compared the codes of 0.5.6 vs. 0.5.7, but did not find clues why that item was rendered wrong. Do you see the same result in Firefox/Chrome or other browsers?

I did some reading and it appears that for some odd reasons :last-of-type only considers html tag types, not class selectors, i.e. if we want to make this work with div's we'd have to use some js to figure out the last tree items within tree lists and give them a class rather than using pseudo selectors. Not sure why :first-of-type actually is working though.

See the code update on @tbdev (look for //fix). Not sure if that's the most efficient thing to do but I didn't kow how else to figure out that we're at the end of it. If we had a way to do that we could just add those classes once rather than always move it from the previous last to the new last.

Maybe your approach of using <ti> <tp> <tl> <ts>, as it appears to be working in all browsers I have tested is the better way to go.

Tobias.

[Tobias Beer]

Also, this only works when there is just one ts at the beginning or end...

.nt-ts:first-child:before,

.nt-ts:last-child:before,

.nt-ts:only-child:before{

    background-image: none;

}

When there are multiple it breaks. Perhaps it's better to use jQuery and dedicated classes after all?

Would be nice if there was a way to efficiently clean up the classes at the very end of the rendering rather than at every step.

- tobias

[Tobias Beer]

Hi GJRobert,

I have commited the new version 0.5.7 now. It's now at...

https://github.com/tobibeer/TiddlyWikiPlugins/blob/master/forked/NodeTreePlugin.js

What do you think?

Unfortunately, moving a file to a different folder unlinks the history for it, but it's all still there...

https://github.com/tobibeer/TiddlyWikiPlugins/tree/2225a0c54332b7a31fe1e35a3efeba5543fcbe84

Best wishes, Tobias.

[G.J.Robert]

So nice! You did it! It seems that you have find a clever easy way to fix the non-working :last-of-type. Wow I got it: you have converted the pseudo element selector to a class! Marvelous. jQuery is indeed such a saviour... I should try to undestand it sometime.

I have done a test before I see your updated test result at @tbDev. I appreciate as the output does not seem to be affected and looks the same with v0.5.6. Thanks for all you have done!

Love and peace,
GJRobert

Tobias Beer於 2013年9月22日星期日UTC+8下午7時50分53秒寫道：

[G.J.Robert]

I have just updated @nodetreeplugin by importing from @tbDev. Maybe you can double check if anything missing?

Btw, how about adding a link to readable source in the slices?

G.J.Robert於 2013年9月22日星期日UTC+8下午8時20分01秒寫道：

[Tobias Beer]

Of course. Done. ;-)

I've updated @NodeTreePlugin, too.

- tb

[Asimov Isaac]

Hi, Tobias.

I have been looking for a Horizontal Tree plugin for a long time.

The plugins like "family-tree" or "list-tree" can only render vertical list, such as:

• aaaa
• bbbb
• sss
• ooo
• cccc

Fortunately, I found your post here, and the style in the picture below is really the one I keep dreaming of.

However, unfortunately, all the links like " ***.tiddlyspace.com" are out of date so I cannot access them. 

Everything about the "NodeTreePlugin" or "treedg" is missing.

Would you like to tell me where to find them? 

Or could you give me some advice, so I could display a horizontal tree just with <ul> and <li>, instead of complex items like "root","branch", "entry" and so on.

Thank you!

BTW, I do love the plugins on your website, especially the "plantuml" plugin. They help me a lot.

Best regards,

Asimov

2017.05

在 2013年9月12日星期四 UTC+8下午5:04:42，Tobias Beer写道：

Hi,

I think, the two following features could be interresting:
* Before any vertical bar, having an horizontal bar centered on the parent node,

I second that, guess I'd like it to see it like this with rather small lines, just the slightes visual clue...

 

* Having a syntax to do vertical diagrams instead of horizontal ones.

That's may be neat, too, but...

* it will result in a lot of horizontal scrolling

* it will require more of a quote style left border with those branchy things

* I guess, any second third level, etc... would have to be horizontal again for readability's sake

Best wishes, Tobias.

[Stephen Wilson]

Have you tried TidGraph?
https://ihm4u.github.io/tw5plugs/#Tidgraph%20-%20Easy%20tiddler%20graphs%20for%20TW5

Might do what you're looking for.
Stephen

[Alex Hough]

The TidGraph would be good if the node filter could take TagTemplate...they you could see and rearange tiddlers

<$tidgraph start="Virtues" nodetemplate="$:/core/ui/TagTemplate"/>

Alex -

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscribe@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/bb7beb5a-bd52-45da-ad68-92fd11f6acb9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Asimov Isaac]

Thank you for your nice advice.

Yes, I have installed Tidgraph before. It is really amazing.

But the disadvantage of Tidgraph is that the nodes must be tiddlers or the filter operators of tiddlers.

What I want is that I do not need to create new tiddlers, and the nodes are just some texts. Just like what you do in some mindmap softwares, such as MindManager or XMind.

Or to be more accurate, the plugin "family-tree" linked below is nearly what I want.

http://familytree.tiddlyspot.com/

The only weakness is that it only creates vertical trees, which is not practical or handsome if you want to type in long texts or the hierarchies increase,

Maybe I could email the author of the "family-tree" and consult him about this? 

I believe that there must be some other people who need this kind of plugin.

Anyway, thanks again for your kind reply. I would update this post if I get any information from the author of the "family-tree".

Best regards,

Asimov

2017.05

在 2017年5月17日星期三 UTC+8下午8:09:35，Stephen Wilson写道：

[Pit.W.]

Just for the fun of it: I found this by accident.

the code below leads also to results. Could be quite powerful...
Was that intended? @Mat
Or is it an "Easter egg" ?

Kind regards

Pit

<div class="family-tree">

*Tree
*Tree2
**<<list-links "[!is[system]search[child]]">>

</div>

--

You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.

To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/7e9a1a3f-5693-4e2a-b7b2-834cf6fa449c%40googlegroups.com.

[Asimov Isaac]

Yeah, it's really COOL!

You can also try to search some other keywords, or remove the "!" before the "[system]". 

And you can find more interesting and funny tips with the "list-links Macro". This is embedded in TiddlyWiki.

Refer to the link below:

http://tiddlywiki.com/#list-links Macro

To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscribe@googlegroups.com.

To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/7e9a1a3f-5693-4e2a-b7b2-834cf6fa449c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/MrueYHk2j7U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywiki+unsubscribe@googlegroups.com.

To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/b77c642f-d8c8-ddab-7977-04d33c394a98%40eclipso.ch.

[Yakov]

Just for the record: most of tiddlyspaces are accessible via the Web Archive (example: [1]), although some are in outdated versions.

Best regards,
Yakov.

[1] https://web.archive.org/web/20131219043836/http://treedg.tiddlyspace.com/

среда, 17 мая 2017 г., 8:02:52 UTC+3 пользователь Asimov Isaac написал:

[Mat]

Asimov Isaac wrote:

Maybe I could email the author of the "family-tree" and consult him about this? 

Hi, I made "family-tree" but it's "more experimental than public". It was a side project as I made http://listtree.tiddlyspot.com/

The only weakness is that it only creates vertical trees, which is not practical or handsome if you want to type in long texts or the hierarchies increase,

I'd guess(!) it is possible to do it as a horizontal tree. I don't intend to pick this up any time soon though but I  am interested in the matter so, one day.

Please feel free to dabble around (which is pretty much how I do it). And, BTW, notice that it is all CSS based, no JS.

<:-)

[@TiddlyTweeter]

Ciao Mat

i maybe commented before that this and your great graphic family tree, unfortunately does not work. This is because you are only depicting UNI-linear descent. That's fine for some parts of the world, but Western societies, on the whole, think in terms of BI-lateral descent (i.e. descent is from TWO parents who need be depicted at the SAME level, not separated in a hierarchy).

Its actually a more difficult problem than you at first might think. TiddlyMap has exactly the same problem.: http://tiddlymap.org/#Using%20the%20Map%20Raster

Best wishes
Josiah

[Christopher Arcadia]

I agree it is no so useful as a family tree but it would be great if we could automatically visualize the tiddlers that share the same tag with something like this.

But as is, manually writing diagrams look out very nice using Mat's stylesheet.

[K500 L501]

"visualize the tiddlers that share the same tag" - wouldnt that be what TidGraph is doing?

-Kilo

On Thu, Jun 8, 2017 at 5:26 AM, Christopher Arcadia <christoph...@brown.edu> wrote:

I agree it is no so useful as a family tree but it would be great if we could automatically visualize the tiddlers that share the same tag.

--

You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscribe@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/e8b8bc52-b886-4c8c-a1fe-dfd10bee46ce%40googlegroups.com.

[@TiddlyTweeter]

Ciao Chris

Totally agree. Mat's branching bubbles are visually awesome & have huge utility.

The family tree problem is a big issue, but he should not get bogged in it.

J.

[G.J.Robert]

Just see the "new" posts since 2017.

If anyone ever need the old TWc (TiddlyWiki Classic) plugin of NodeTree as a reference, Tobias has still the source code hosted here:
https://github.com/tobibeer/TiddlyWikiPlugins/commits/master/mods/NodeTreePlugin.js

Also I have put the old TiddlySpace @nodetree space back online here:
https://gjrobert.github.io/TiddlyWikiClassic-NodeTreePlugin/

Still very amused to see the nice work done by Tobias. But the era of TiddlyWiki Classic and TiddlySpace is long gone.

isim...@gmail.com 在 2017年5月17日 星期三下午1:02:52 [UTC+8] 的信中寫道：

[Yakov]

Hi G.J.,

if you are interested in updates in the ecosystem of TWC, you may want to visit https://groups.google.com/forum/#!forum/tiddlywikiclassic Of'course, the most of the community uses TW5, but this doesn't mean TWC doesn't evolve.

Best regards,
Yakov.

[G.J.Robert]

Hi Yakov,

Thank you for the redirecting, and glad to see there is still a community of TWC.

I was so fond of TWC and TiddlySpace (a consumer of the plugins of course). Afterwards, I still keep my latest copy of the spaces as HTML files and append a couple of them every now and then for personal purposes.

But because I was also searching a great tool for both personal note-taking and also weblogging, sharing and collaborating, so I have started to use DokuWiki since 2016. I still love TWC and TW5 (of course TW5 is a huge and great work), just that I abandoned to use TW5 at all and only write in my DW.

That's off topic and trivial for here of course. I really appreciate all the good things TWC community gave to me. I even used TiddlySpace and quite a few plugin features and so many of my tweaks for containing hundreds of notes of legal classes, which helped me to pass the bar exam of our country. Good memory.

Wish all the best to all of you,
Robert

Yakov 在 2020年9月16日 星期三上午4:24:50 [UTC+8] 的信中寫道：