Hej Jan,
I think I know where you are coming from (I read your thoughts here: http://slidesnstories.tiddlyspot.com/#TextStretch%20by%20Thomas%20Elminger) and I think it would be interesting to develop a concept for scientific documents authored using TW5.
Tobias points towards something that is critical for my CSS numbering solution: It is based on presentation and agnostic of content and structure. For scientific work I am afraid this is not enough. Important features of TiddlyWiki are transclusion, lists and filters … I think a scientific authoring tool should be able to deal with that. So a broader concept is needed. Let me explain some thoughts: In a perfect world, …
1. Authors would write chapters or sub-chapters as tiddlers and collect them in chapters and publications (books). A book usually is built up in a traditional structure like
- Title
- Contents Overview
- Foreword
- Chapter 1
- Sub-chapter 1.1
- and so on 1.1.1
- <<ref "see chapter 2.1">>
- term definition 1.1.1.1
- Chapter 2
- and so on 2.1
- reference to term definition 1.1.1.1: <<ref "{{term definition}}">>
- Conclusion
- Indexes
2. Publishers would ask for one document with all the content to reformat it for other publication channels like printed books, e-books and the like. What would this master document be? A story river?
3. Schools would possibly put the book on a server (in a DB like Danielo’s here? or in a TWederation Wiki?) where teachers/students can download/connect to it.
4. Teachers would collect chapters from several books as readings for their students. Can they use TW for this? How would this affect numbering of chapters and references?
5. Students would make their own annotations or cite excerpts in their own works.
A fool-proof authoring system would offer solutions and/or guidelines to use cases like these. To make a relevant contribution for scientific authors we should at least have a concept for 1. and 2. How should an author structure his/her work? What do we use single tiddlers for? How many levels of (nested) transclusion are acceptable? And so on …
Do you have a concept, Jan, or a real-world example wiki, we could use for this? It could be very helpful to develop and test even small contributions against such a reference project.
Kind regards, Thomas
--
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/66ad8007-2dfb-4c8b-8092-0b8d8401fc5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
>>it works DOM-oriented and thus – as for now – on a per tiddler base.
As far as I found out, your numbering counts through the storyriver, wich is fine for endnotes...
Hi Jan
>>it works DOM-oriented and thus – as for now – on a per tiddler base.
As far as I found out, your numbering counts through the storyriver, wich is fine for endnotes...
That was an error – and I just changed it in my new version 0.8.3 (see http://tid.li/tw5/hacks.html#TextStretch%20Versions for comments). When you opened another tiddler on the top of the story river, all numbers in allready open tiddlers changed – not very consistent. So each tiddler starts at number 1 now. I have been thinking about numbering them 1.1 … 2.1 with an additional tiddler-number prefix. Of course I can give you the old behaviour back if you prefer … maybe we could have separate classes for tiddlernumbers and rivernumbers so authors can choose.
Good night!
--
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/a9dc6a38-7838-4c49-b777-e687ad5910cd%40googlegroups.com.
Hi Thomas,
nice that both numbering-behaviours are possible.
Numbering throughout the storyriver would be fine for print/pdf export. I think "eternal-"consitency is not the problem, even in Word the footnotenumbers change if you add one in front.
For comments and reading of course the new tiddlerwise numbers of course are better, because they are smaller.
I would think a button to switch between two stylesheets would be a good solution. It could be an element of the endnotetiddler (which we know is science-fiction so far...;-).
Cheers
Jan
Am 29.08.2016 um 00:33 schrieb Thomas Elmiger:
Hi Jan--
>>it works DOM-oriented and thus – as for now – on a per tiddler base.
As far as I found out, your numbering counts through the storyriver, wich is fine for endnotes...
That was an error – and I just changed it in my new version 0.8.3 (see http://tid.li/tw5/hacks.html#TextStretch%20Versions for comments). When you opened another tiddler on the top of the story river, all numbers in allready open tiddlers changed – not very consistent. So each tiddler starts at number 1 now. I have been thinking about numbering them 1.1 … 2.1 with an additional tiddler-number prefix. Of course I can give you the old behaviour back if you prefer … maybe we could have separate classes for tiddlernumbers and rivernumbers so authors can choose.
Good night!
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/a9dc6a38-7838-4c49-b777-e687ad5910cd%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/d2bpFwTXggI/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/57C4074A.4030307%40googlemail.com.
Mat has achieved what something like that in quite brute force way in the cherrypicker.tiddlyspot.com. The problem ist that it has trouble dealing with Wiki-Code-Expressions, that is to say I have trouble doing this.
Perhaps it would be smarter to do something like that in js...
--
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/c391eed9-eff4-4aa9-8c8e-354672d41c49%40googlegroups.com.
To parseTreeNodes sounds a little chinese for me...but I think I understand.
If it is what Ithink it would put us all a big deal forward and could be the basis for many things I try to build.
- a filter collecting Footnotes
- a way of transcluding/navigating to parts of Tiddlers
... and thus new possibilities to present information stored in TWs for example in Slideshows et cetera
Hi JanTo parseTreeNodes sounds a little chinese for me...but I think I understand.
Yes, it takes some getting used to terminology. Think of it like that: You have wikitext and that is parsed by the TiddlyWiki core into a parseTree and then a widget tree subsequently constructed from that, which in turn eventually generates DOM elements for the browser to display, but not necessarily.
Since TiddlyWiki does away with the focus on manipulating DOM elements directly, operating on a widgets architecture, there is a bit of a gap. With TiddlyWiki classic it was easy to do DOM traversal and manipulation with jQuery and so we could do all kinds of fancy stuff after the fact, meaning, after TiddlyWiki did its default thing with the wikitext.
However, with the new architecture, we're a bit lacking on a general interface for developers to traverse the widget-tree-representation of your wiki text, e.g. so as to say "find that list and give me its list elements". Such a traversal may not even be desirable owed to the transient, stateless nature of widgets... which doesn't mean that they do not actually have a state, but that they can be trashed and recreated at any given moment... so if you have some other output that would depend on the current widget representation, there's a chance it would not notice that the thing it references and relies on to do further stuff actually changed from the first time it was created, e.g. that footnote index.
So, with TiddlyWiki classic there were HTML / DOM elements like ULs and LIs (which we still have, of course) for which we could use simple jQuery selectors to address them. However, now we would need some simplistic equivalent to address the underlying list widget, so as to be able to then do magick with a possibly much safer and much more powerful encapsulation in the form of a widget, that provides well defined interfaces for actually handling it, e.g. when to refresh or recompute the state of that widget, etc...If it is what Ithink it would put us all a big deal forward and could be the basis for many things I try to build.
- a filter collecting Footnotes
- a way of transcluding/navigating to parts of Tiddlers
... and thus new possibilities to present information stored in TWs for example in Slideshows et cetera
So, that's the thing: you would need to be able to tell the TiddlyWiki core:
- that right there is my "tiddler" in the widget tree
- and in that thing being the "tiddler" rendered from that wikitext, go find elements matching this or that pattern, e.g. all list widget where some attribute is such and such
- eventually return the corresponding widgets so that I can do fancy stuff based on what I'm given, e.g. with the list items ...presuming I know all about list widgets and how to get from the list itself to the items
However, one core paradigm is that widgets are transient things by nature, especially their representation in the DOM. So, in general the philosophy would be to always work try and with the underlying wikitext first. And if that proves difficult, chances are you simply haven't sliced and diced your wikitext just enough for you to be able to address every single chunk of concern separately.
To conclude with a much more practical example, let me put it this way:
if you turned your footnotes into actual tiddlers, e.g. as
$:/fn/the related tiddler/foo
$:/fn/the related tiddler/bar
and then retrieved it as:
<<fn foo>>
in the context of the related tiddler, then you could do all kinds of magick with those footnotes ...and all that would be missing is some simplistic plugin that, instead of using some markup in the tiddler, would go create those "under-the-hood"-related system tiddlers being the footnotes... which it would be most trivial to later on list with whatever eye-candy you fancy most.
Based on a given list of chapter tiddlers being rendered each with their individual, related footnotes tiddlers you could as well easily generate one big list of footnotes. All you need is for your footnotes to be actual tiddlers. Hence system tiddlers since you may not actually want them to be searchable on their own.
However, you could easily run into problems with the above approach if you ever chose to rename those titles. So, one crucial missing piece to safely model stuff like this, is that eventually TiddlyWiki will bring core support for every single (non-system) tiddler to have an auto-generated unique id, so it would be:
$:/some-unique-id-12345/foo$:/another-uniqueid-54321/bar
With the eventual tiddler being:
title: some related tiddlerid: some-unique-id-12345
Refer to <<fn foo>>.
Am I making sense?
Best wishes,
Tobias.
--
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/e7f95d27-4dcc-4fab-bdce-eb968c8c07cf%40googlegroups.com.
Hi JanTo parseTreeNodes sounds a little chinese for me...but I think I understand.
Yes, it takes some getting used to terminology. Think of it like that: You have wikitext and that is parsed by the TiddlyWiki core into a parseTree and then a widget tree subsequently constructed from that, which in turn eventually generates DOM elements for the browser to display, but not necessarily.
Since TiddlyWiki does away with the focus on manipulating DOM elements directly, operating on a widgets architecture, there is a bit of a gap. With TiddlyWiki classic it was easy to do DOM traversal and manipulation with jQuery and so we could do all kinds of fancy stuff after the fact, meaning, after TiddlyWiki did its default thing with the wikitext.
However, with the new architecture, we're a bit lacking on a general interface for developers to traverse the widget-tree-representation of your wiki text, e.g. so as to say "find that list and give me its list elements". Such a traversal may not even be desirable owed to the transient, stateless nature of widgets... which doesn't mean that they do not actually have a state, but that they can be trashed and recreated at any given moment... so if you have some other output that would depend on the current widget representation, there's a chance it would not notice that the thing it references and relies on to do further stuff actually changed from the first time it was created, e.g. that footnote index.
So, with TiddlyWiki classic there were HTML / DOM elements like ULs and LIs (which we still have, of course) for which we could use simple jQuery selectors to address them. However, now we would need some simplistic equivalent to address the underlying list widget, so as to be able to then do magick with a possibly much safer and much more powerful encapsulation in the form of a widget, that provides well defined interfaces for actually handling it, e.g. when to refresh or recompute the state of that widget, etc...If it is what Ithink it would put us all a big deal forward and could be the basis for many things I try to build.
- a filter collecting Footnotes
- a way of transcluding/navigating to parts of Tiddlers
... and thus new possibilities to present information stored in TWs for example in Slideshows et cetera
So, that's the thing: you would need to be able to tell the TiddlyWiki core:
- that right there is my "tiddler" in the widget tree
- and in that thing being the "tiddler" rendered from that wikitext, go find elements matching this or that pattern, e.g. all list widget where some attribute is such and such
- eventually return the corresponding widgets so that I can do fancy stuff based on what I'm given, e.g. with the list items ...presuming I know all about list widgets and how to get from the list itself to the items
However, one core paradigm is that widgets are transient things by nature, especially their representation in the DOM. So, in general the philosophy would be to always work try and with the underlying wikitext first. And if that proves difficult, chances are you simply haven't sliced and diced your wikitext just enough for you to be able to address every single chunk of concern separately.
To conclude with a much more practical example, let me put it this way:
if you turned your footnotes into actual tiddlers, e.g. as
$:/fn/the related tiddler/foo
$:/fn/the related tiddler/bar
and then retrieved it as:
<<fn foo>>
in the context of the related tiddler, then you could do all kinds of magick with those footnotes ...and all that would be missing is some simplistic plugin that, instead of using some markup in the tiddler, would go create those "under-the-hood"-related system tiddlers being the footnotes... which it would be most trivial to later on list with whatever eye-candy you fancy most.
Based on a given list of chapter tiddlers being rendered each with their individual, related footnotes tiddlers you could as well easily generate one big list of footnotes. All you need is for your footnotes to be actual tiddlers. Hence system tiddlers since you may not actually want them to be searchable on their own.
However, you could easily run into problems with the above approach if you ever chose to rename those titles. So, one crucial missing piece to safely model stuff like this, is that eventually TiddlyWiki will bring core support for every single (non-system) tiddler to have an auto-generated unique id, so it would be:
$:/some-unique-id-12345/foo$:/another-uniqueid-54321/bar
With the eventual tiddler being:
title: some related tiddlerid: some-unique-id-12345
Refer to <<fn foo>>.
Am I making sense?
Best wishes,
Tobias.
--
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/e7f95d27-4dcc-4fab-bdce-eb968c8c07cf%40googlegroups.com.
Hi JanTo parseTreeNodes sounds a little chinese for me...but I think I understand.
Yes, it takes some getting used to terminology. Think of it like that: You have wikitext and that is parsed by the TiddlyWiki core into a parseTree and then a widget tree subsequently constructed from that, which in turn eventually generates DOM elements for the browser to display, but not necessarily.
Since TiddlyWiki does away with the focus on manipulating DOM elements directly, operating on a widgets architecture, there is a bit of a gap. With TiddlyWiki classic it was easy to do DOM traversal and manipulation with jQuery and so we could do all kinds of fancy stuff after the fact, meaning, after TiddlyWiki did its default thing with the wikitext.
However, with the new architecture, we're a bit lacking on a general interface for developers to traverse the widget-tree-representation of your wiki text, e.g. so as to say "find that list and give me its list elements". Such a traversal may not even be desirable owed to the transient, stateless nature of widgets... which doesn't mean that they do not actually have a state, but that they can be trashed and recreated at any given moment... so if you have some other output that would depend on the current widget representation, there's a chance it would not notice that the thing it references and relies on to do further stuff actually changed from the first time it was created, e.g. that footnote index.
So, with TiddlyWiki classic there were HTML / DOM elements like ULs and LIs (which we still have, of course) for which we could use simple jQuery selectors to address them. However, now we would need some simplistic equivalent to address the underlying list widget, so as to be able to then do magick with a possibly much safer and much more powerful encapsulation in the form of a widget, that provides well defined interfaces for actually handling it, e.g. when to refresh or recompute the state of that widget, etc...If it is what Ithink it would put us all a big deal forward and could be the basis for many things I try to build.
- a filter collecting Footnotes
- a way of transcluding/navigating to parts of Tiddlers
... and thus new possibilities to present information stored in TWs for example in Slideshows et cetera
So, that's the thing: you would need to be able to tell the TiddlyWiki core:
- that right there is my "tiddler" in the widget tree
- and in that thing being the "tiddler" rendered from that wikitext, go find elements matching this or that pattern, e.g. all list widget where some attribute is such and such
- eventually return the corresponding widgets so that I can do fancy stuff based on what I'm given, e.g. with the list items ...presuming I know all about list widgets and how to get from the list itself to the items
However, one core paradigm is that widgets are transient things by nature, especially their representation in the DOM. So, in general the philosophy would be to always work try and with the underlying wikitext first. And if that proves difficult, chances are you simply haven't sliced and diced your wikitext just enough for you to be able to address every single chunk of concern separately.
To conclude with a much more practical example, let me put it this way:
if you turned your footnotes into actual tiddlers, e.g. as
$:/fn/the related tiddler/foo
$:/fn/the related tiddler/bar
and then retrieved it as:
<<fn foo>>
in the context of the related tiddler, then you could do all kinds of magick with those footnotes ...and all that would be missing is some simplistic plugin that, instead of using some markup in the tiddler, would go create those "under-the-hood"-related system tiddlers being the footnotes... which it would be most trivial to later on list with whatever eye-candy you fancy most.
Based on a given list of chapter tiddlers being rendered each with their individual, related footnotes tiddlers you could as well easily generate one big list of footnotes. All you need is for your footnotes to be actual tiddlers. Hence system tiddlers since you may not actually want them to be searchable on their own.
However, you could easily run into problems with the above approach if you ever chose to rename those titles. So, one crucial missing piece to safely model stuff like this, is that eventually TiddlyWiki will bring core support for every single (non-system) tiddler to have an auto-generated unique id, so it would be:
$:/some-unique-id-12345/foo$:/another-uniqueid-54321/bar
With the eventual tiddler being:
title: some related tiddlerid: some-unique-id-12345
Refer to <<fn foo>>.
Am I making sense?
Best wishes,
Tobias.
--
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/e7f95d27-4dcc-4fab-bdce-eb968c8c07cf%40googlegroups.com.