Some thoughts and hopes for TiddlyWiki 5: WYSIWYG, comparisons, etc
Rich
I just read Jeremy's post announcing the pre Alpha of TiddlyWiki 5 (a
little late to the party).
As you consider WYSIWYG solutions, I hope you will consider getting
rid of edit vs view mode, changing the model a little to "what you see
is what it is." The Aloha editor is seeming to do this with jquery
and html5 (I think), and seems like an elegant solution.Getting away
from modes would make it a step quicker as a note-keeping device.
For myself, I would gladly be rid of wikitext and would make the non-
reversible upgrade in a second! I just want to write -- not code --
in TW, even if it is only wiki markup.
I may be setting myself up for flammage here, but I think it
worthwhile to take a look at what MS's OneNote is doing on several
fronts that TW5 intends to head for: incorporating images and sound
files as drag and drop, hypertext, (OCR of image text!) and most of
all WYSIWYG with no modes. What they are getting wrong is that the
format is not cross-platform, and is not legible to most search
engines. KDE's basket is making a stab at being a OneNote knockoff,
getting most of both the right and wrong parts down, but KDE acts like
a virus on my system, fouling up everything so it is unusable. I was
using Tomboy, which is great for ease of use, but it is a pain to get
at notes cross-platform. I sync to dropbox, but I cannot read the
files on a phone browser like I can TW. THey have a sync service as
part of ubuntu one, but it makes you store your local copy in a preset
location that is not part of my indexed search area. I keep returning
to TW, but keep disliking it because of the lack of WYSIWYG and the
edit mode.
I would like to see the ease of use of Tomboy, the feature set of
OneNote, the cross-platform compatibility, portability, and user
configurability of TW2, and the html/css direction you are going with
the pre-alpha. I think the roadmap in your announcement bodes well
for all of this.
I think embracing html5 and css is an important step in the right
direction. One of the limitations of TW I run into at present is that
my desktop search (Google Desktop) does not find any of my TiddlyWiki
text because it skips the JS content. I have been trying, with
limited success and lots of setbacks, to keep all my content (email,
word proc, text files, html. pdf, databases, image headers, audio
tags...) indexed in one search engine. Solutions happen, then go out
of commission (altavista desktop) or "upgrade' themselves out of
usefulness (x1), or don't index everything (google desktop). Getting
my TW content visible as html would be great.
Finally, I still find the opening of linked tiddlers confusing in the
default behavior. Always opening on top would be less disorienting,
and tabs would give the best of both worlds, which is how I have my
TW2 set up presently. The tabs keep the story idea by opening in
order, but keep more info (current tiddler + all titles to other
tiddlers) on the main screen for quick access.
I use notetaking apps every day, and have just arrived back at TW2 (my
FiddlyWiki version of it anyway) after a sojourn through the above
mentioned ones. I am really looking forward to the development of TW5
and wish I could code so I could contribute more, but that probably is
not happening any time too soon..
Anyway, thanks for giving me a listen.
Jeremy Ruston
> little late to the party).
Thanks for the comments. TiddlyWiki5 has taken a back seat while we've
been focussing on TiddlySpace, with some of the innovations from
TiddlyWiki5 (like SVG handling) being brought over TiddlySpace.
> As you consider WYSIWYG solutions, I hope you will consider getting
> rid of edit vs view mode, changing the model a little to "what you see
> is what it is." The Aloha editor is seeming to do this with jquery
> and html5 (I think), and seems like an elegant solution.Getting away
> from modes would make it a step quicker as a note-keeping device.
Yes, I like the idea of modelessness, and TiddlyWiki5 is intended to
support that way of working.
> For myself, I would gladly be rid of wikitext and would make the non-
> reversible upgrade in a second! I just want to write -- not code --
> in TW, even if it is only wiki markup.
This is the nub of the matter. In TiddlyWiki5 I was trying to simplify
the editing environment by switching from wikitext to HTML. The
advantage of HTML being that it is native to the web, and therefore
better for interoperability, and that browsers offer (primitive)
facilities for building rich text editors.
However, the feedback from the group was loudly that losing wikitext
was too high a price to pay for that ease of use.
I believe now that the goal should be to offer direct editing of HTML
that has been generated from wikitext, with the edits automatically
updating the wikitext.
When TiddlySpace has settled down a little more, I hope to return to the topic.
> I may be setting myself up for flammage here, but I think it
> worthwhile to take a look at what MS's OneNote is doing on several
> fronts that TW5 intends to head for: incorporating images and sound
> files as drag and drop, hypertext, (OCR of image text!) and most of
> all WYSIWYG with no modes. What they are getting wrong is that the
> format is not cross-platform, and is not legible to most search
> engines. KDE's basket is making a stab at being a OneNote knockoff,
> getting most of both the right and wrong parts down, but KDE acts like
> a virus on my system, fouling up everything so it is unusable. I was
> using Tomboy, which is great for ease of use, but it is a pain to get
> at notes cross-platform. I sync to dropbox, but I cannot read the
> files on a phone browser like I can TW. THey have a sync service as
> part of ubuntu one, but it makes you store your local copy in a preset
> location that is not part of my indexed search area. I keep returning
> to TW, but keep disliking it because of the lack of WYSIWYG and the
> edit mode.
>
> I would like to see the ease of use of Tomboy, the feature set of
> OneNote, the cross-platform compatibility, portability, and user
> configurability of TW2, and the html/css direction you are going with
> the pre-alpha. I think the roadmap in your announcement bodes well
> for all of this.
This is a useful articulation, thank you.
> I think embracing html5 and css is an important step in the right
> direction. One of the limitations of TW I run into at present is that
> my desktop search (Google Desktop) does not find any of my TiddlyWiki
> text because it skips the JS content. I have been trying, with
> limited success and lots of setbacks, to keep all my content (email,
> word proc, text files, html. pdf, databases, image headers, audio
> tags...) indexed in one search engine. Solutions happen, then go out
> of commission (altavista desktop) or "upgrade' themselves out of
> usefulness (x1), or don't index everything (google desktop). Getting
> my TW content visible as html would be great.
I believe that Google Desktop allows for pluggable modules to extend
it's search capabilities to other storage media. It would perhaps be
possible to write such a module that enabled Google Desktop to search
TiddlyWiki files properly.
The other side of the HTML visibility problem is the need to present
HTML to search engines. TiddlyWeb has facilities for generating HTML
on the server, but currently it isn't as capable as the HTML
generation that takes place inside the TiddlyWiki client code.
> Finally, I still find the opening of linked tiddlers confusing in the
> default behavior. Always opening on top would be less disorienting,
> and tabs would give the best of both worlds, which is how I have my
> TW2 set up presently. The tabs keep the story idea by opening in
> order, but keep more info (current tiddler + all titles to other
> tiddlers) on the main screen for quick access.
The key for me is that TiddlyWiki allows people to choose between
these different presentations.
> I use notetaking apps every day, and have just arrived back at TW2 (my
> FiddlyWiki version of it anyway) after a sojourn through the above
> mentioned ones. I am really looking forward to the development of TW5
> and wish I could code so I could contribute more, but that probably is
> not happening any time too soon..
Thoughtful contributions like this from prospective users are
incredibly valuable, and fundamentally shapes our work.
> Anyway, thanks for giving me a listen.
Many thanks
Best wishes
Jeremy
> --
> You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
> To post to this group, send email to tiddly...@googlegroups.com.
> To unsubscribe from this group, send email to tiddlywikide...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.
>
>
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
Yakov
I'd like to add my 50 cents about the wonderful vista of TW5.
My intention is mostly to highlight some "restrictions" (things that
are hard) of TW2 (aside that of speed and ease of use) and figure out
which ones will be in focus of TW5 development and which probably will
not. So, here we go:
* multilangual use. As for now, I've heard of tweaking with themes
some other concepts ([1]), but this is of concern afterall, the idea
of inter-personal web notebook implies some internatianality) By
multilangual use I mean some fields architecture in the first place -
like, say one title which is an id of a tiddler and titles and
textareas with some language suffixes in names.. anyway, Tobias
figured some things in [1]
* export mechanism. TW is too standalone and if I need to pick some
items and send them to other people I need either use something like
Eric's plugin which allows to "print" tiddlers into html or make one
more TW and import the tiddlers into it (and install some plugins if
needed); and some devices like e-ink Books restrict this even worse
since they can't do JavaScript. Also, more interaction with file
system can allow syncronize with already written things some more
([2]); however, I understand that the latter thing is not about
"restrictions" but rather about "extention".
* input of formulae. This is also not exactly a restriction, and there
are some plugins [3] for that; but renewing TW means loss of the
plugins on the one hand and a question about possibility to visualize
a formula when editing on the other. The latter thing I'm talking
about is not WYSIWYG itself, but rather a hybrid which is used in
codecogs-based plugins ([4]) and Open Office: it is always faster to
write a formula in some markup (not clicking buttons with mouse) but
see what it will look like in some other "window".
* "massive operation manager". The gem of TW is that we can organize
things very precisely but once someone gets to reorganize things, say
change one tag to another, or delete many tiddlers, he/she needs some
sort of plugin (and sometimes this requires also manual piloting, when
shaping the list of tiddlers to delete for instance). Something like
that is required when importing tiddlers (checking tiddlers by tags,
authors etc). The latter is implemented in plugin(s)
(ImportTiddlersPlugin by Eric and others, perhaps).
And one more feature that's not about "restrictions" at all:
* link rebinding. TW is "enclosed" space of hypertext, so this seems
proper not to get links within it broken after renaming a tiddler. I
mean, if tiddler B has a link/{tiddler/..} macro referencing tiddler
A, it would be nice to get a "would you like to rebind all the links
to this tiddler" dialog when renaming A (which has references).
I know, I sound so demanding, but afterall it's interesting to hear
what do you think of this matters and what to expect in future.
Many thanks, Yakov.
[1] http://groups.google.com/group/tiddlywiki/browse_thread/thread/d38df1e51d3e4d54/a54f42d375850eab
[2] https://groups.google.com/group/tiddlywiki/browse_thread/thread/4c9744205f64a415
[3] https://groups.google.com/group/tiddlywiki/browse_thread/thread/72a1d4bdc6f0742e/7a33f8783b51572b
[4] http://twmath.tiddlyspot.com/
Jeremy Ruston
> some other concepts ([1]), but this is of concern afterall, the idea
> of inter-personal web notebook implies some internatianality) By
> multilangual use I mean some fields architecture in the first place -
> like, say one title which is an id of a tiddler and titles and
> textareas with some language suffixes in names.. anyway, Tobias
> figured some things in [1]
I agree entirely. My goal is to devise a better mechanism for
translators to create new translations of TiddlyWiki, and for that
same mechanism to be usable by creators of TiddlyWiki to manage the
translation of their content.
> * export mechanism. TW is too standalone and if I need to pick some
> items and send them to other people I need either use something like
> Eric's plugin which allows to "print" tiddlers into html or make one
> more TW and import the tiddlers into it (and install some plugins if
> needed); and some devices like e-ink Books restrict this even worse
> since they can't do JavaScript. Also, more interaction with file
> system can allow syncronize with already written things some more
> ([2]); however, I understand that the latter thing is not about
> "restrictions" but rather about "extention".
I think this is indeed another question about "what functionality goes
in the core". There's been a lot of discussion in the group over this,
and people often argue that particularly useful plugins should "go in
the core" because they are so useful.
I have come to the conclusion that it is unhelpful trying to define
the core in terms of how extensive its functionality should be, and
instead we should look to engineering considerations of minimality to
drive the shape of what belongs in the core. The questions about
usefulness should guide the scope of particular vertical editions of
TiddlyWiki.
> * input of formulae. This is also not exactly a restriction, and there
> are some plugins [3] for that; but renewing TW means loss of the
> plugins on the one hand and a question about possibility to visualize
> a formula when editing on the other. The latter thing I'm talking
> about is not WYSIWYG itself, but rather a hybrid which is used in
> codecogs-based plugins ([4]) and Open Office: it is always faster to
> write a formula in some markup (not clicking buttons with mouse) but
> see what it will look like in some other "window".
I agree. I'd like the wikification to be seamlessly extensible, so
that users can reach up for mathematical formulae, choreographic
symbols, musical symbols etc.
> * "massive operation manager". The gem of TW is that we can organize
> things very precisely but once someone gets to reorganize things, say
> change one tag to another, or delete many tiddlers, he/she needs some
> sort of plugin (and sometimes this requires also manual piloting, when
> shaping the list of tiddlers to delete for instance). Something like
> that is required when importing tiddlers (checking tiddlers by tags,
> authors etc). The latter is implemented in plugin(s)
> (ImportTiddlersPlugin by Eric and others, perhaps).
Yes, my goal in the core is to make it easy for peoplt to create
plugins to support specific refactoring scenarios.
> And one more feature that's not about "restrictions" at all:
>
> * link rebinding. TW is "enclosed" space of hypertext, so this seems
> proper not to get links within it broken after renaming a tiddler. I
> mean, if tiddler B has a link/{tiddler/..} macro referencing tiddler
> A, it would be nice to get a "would you like to rebind all the links
> to this tiddler" dialog when renaming A (which has references).
Yes, this one keeps eating away at me. There are powerful attractions
for keeping tiddlers in working storage in a more structured tree
format that makes it easier to do this kind of thing. (Another example
of something that's hard to do with the current architecture is a
checkbox that is typed [ ] and gets changed dynamically to [X] when it
is clicked).
> I know, I sound so demanding, but afterall it's interesting to hear
> what do you think of this matters and what to expect in future.
Many thanks for the interesting observations,
Best wishes
Jeremy
> Many thanks, Yakov.
>
> [1] http://groups.google.com/group/tiddlywiki/browse_thread/thread/d38df1e51d3e4d54/a54f42d375850eab
> [2] https://groups.google.com/group/tiddlywiki/browse_thread/thread/4c9744205f64a415
> [3] https://groups.google.com/group/tiddlywiki/browse_thread/thread/72a1d4bdc6f0742e/7a33f8783b51572b
> [4] http://twmath.tiddlyspot.com/
>
Rich
TiddlySpace...I did not know about the project til now.
One last thought on (preferably modeless) WYSIWYG and wiki
compatability. I imagine this has already been discussed, but it
seems most of the payoff for keeping wiki markup is that people like
to write in it, especially for certain tasks such as tiddlers with
macros and tiddlers that do other things than store someone's
hyperprose. It might simplify design if there were an option to
create a wiki markup tiddler or a WYSIWYG tiddler at the outset and
just keep them separate. I may be wrong, but I don't think there are
many if any cases where someone would need to go from wysiwyg to wiki
markup and would not know which type of tiddler to create at the time
of creation. Then the (optional) translation can just be a
unidirectional wiki==> wysiwyg for people like me who would like to
get everything into html and stay there rather than having to create a
bidirectional translation. Two markup engines, with a possible one-
way, irreversible translation of wiki to WYSIWIG would seem to be an
easier problem than fully bidirectional, transparent formatting. Even
if bidirectional formatting remained the goal, a unidirectional
translation to WYSIWYG with the option to remain in wiki markup of
course reserved would be a solid fist step toward doing that, and you
could see if it was "good enough." A little inelegant, but might give
everyone what they want with less work.
Jeremy Ruston
That's pretty much how TiddlyWiki5 works: tiddlers are either wikitext
or html. The HTML can include special annotations for macros and
links. Internally, the wikitext is rendered into pretty much the same
HTML. Ultimately, though, I found that I really don't like the idea of
having two classes of content, with inevitable differences in
behaviour and capability.
Best wishes
Jeremy
Yakov
> for keeping tiddlers in working storage in a more structured tree
> format that makes it easier to do this kind of thing. (Another example
> of something that's hard to do with the current architecture is a
> checkbox that is typed [ ] and gets changed dynamically to [X] when it
> is clicked).
(which should be based on the "references" list) and .. what the
"working storage" really is? Neither I understant the issue with a
checkbox.. I mean it's connection with the problem.
I'd note that the references list should be formed a bit more
carefully: as for now, links placed in comments (which can be sections
that are shown with sliders) are not counted as references; as I
remember, in some tests transclusion macros also didn't cause a
creation of reference; but I'm not sure.
> I may be wrong, but I don't think there are
> many if any cases where someone would need to go from wysiwyg to wiki
> markup and would not know which type of tiddler to create at the time
> of creation.
type. The thing is when you write things first (for example, when
studying something), you need to write quickly. The WYSIWYM mode is
not good because you actually don't know what you mean. You replicate,
you try, but .. :) I can't say "don't mean anything" yet usually you
don't mean anything exact. And WYSIWYG helps here a lot. But then, it
is desirable sometimes to organize you thoughts, add css classes, some
macros etc. So the WYSIWYG->wikitext conversion is vital. For some
users, ofcourse.
Yours, Yakov.
Jeremy Ruston
>> Yes, this one keeps eating away at me. There are powerful attractions
>> for keeping tiddlers in working storage in a more structured tree
>> format that makes it easier to do this kind of thing. (Another example
>> of something that's hard to do with the current architecture is a
>> checkbox that is typed [ ] and gets changed dynamically to [X] when it
>> is clicked).
>
> I didn't really get this. What's the connection between rebinding
> (which should be based on the "references" list) and .. what the
> "working storage" really is? Neither I understant the issue with a
> checkbox.. I mean it's connection with the problem.
Basically, because tiddlers are just stored as blobs of text, there is
no easy way to retrieve all the references to a tiddler. So,
internally, TiddlyWiki scans each tiddler to look for links within it,
and then caches the outgoing links against each tiddler. This allows
the core to (relatively) quickly produce things like Missing, Orphans
and References.
However, there a lot of problems. The link scanning needs to be
quicker than a full scale wikification of the text, and there are
subtle mismatches between what the link scanning algorithm sees as
outgoing links, and what the wikification process sees.
One approach would be to apply more consistent pre-processing to each
tiddler, and maintain them in a more richly structured store that
could support these link-based scenarios more quickly. Going the whole
hog, we could store tiddlers internally in a tree structure (kind of
like a parse tree). If we went that far, it would make it much more
feasible to offer a feature that people have asked for since the early
days - the ability to type [ ] and have it rendered as a check box
that gets flipped to [*] when it is clicked. At the moment that's
pretty hard to do because there is no relationship you can navigate
between the checkbox in the DOM and the fragment of the raw tiddler
text that it corresponds to.
> I'd note that the references list should be formed a bit more
> carefully: as for now, links placed in comments (which can be sections
> that are shown with sliders) are not counted as references; as I
> remember, in some tests transclusion macros also didn't cause a
> creation of reference; but I'm not sure.
That's the problem I'm referring to: false negatives and positives
with the link detection.
Cheers
Yakov
> subtle mismatches between what the link scanning algorithm sees as
> outgoing links, and what the wikification process sees
escaping ("""...""", {{{...}}}) and macros? As for macros, it seems
that only those which contain names of tiddlers among parameters are
of interst..
> we could store tiddlers internally in a tree structure
working?
> parse tree
Meaning somewhat structure for "backward compability" between wikitext
and DOM?
Are there any dev notes about this somewhere?
Jeremy Ruston
>> subtle mismatches between what the link scanning algorithm sees as
>> outgoing links, and what the wikification process sees
>
> This seems strange.. Are there anything aside links ([..[..]]),
> escaping ("""...""", {{{...}}}) and macros? As for macros, it seems
> that only those which contain names of tiddlers among parameters are
> of interst..
That's right; but the point of the design was to be able to scan for
links quicker than doing a full-blown wikify. The link scanner is
based on very simple regexp detection which works most of the time -
it will pick up tiddler titles within macro parameters, for instance.
>> we could store tiddlers internally in a tree structure
>
> Do you mean storing in the file or in the object model, while TW is
> working?
I meant in an object model while TW is working.
>> parse tree
>
> Meaning somewhat structure for "backward compability" between wikitext
> and DOM?
Yes, that's right.
> Are there any dev notes about this somewhere?
Not really. There's the TiddlyWiki5 code itself, and some discussion
in the group since its release. I make notes at
http://jermolene.tiddlyspace.com/, but not as fully as I should.
Best wishes
Jeremy
>
> --
> You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
> To post to this group, send email to tiddly...@googlegroups.com.
> To unsubscribe from this group, send email to tiddlywikide...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.
>
>
--
Yakov
description of the links graph? It would make the file bigger for
sure; yet names of tiddlers can be replaced with their numbers in the
storeArea in a saved file and calculated on startup.
I have one more question. I'm writing quite big and consistent manual
for TW (along with many thoughts on interface, styling, navigation
etc) but I'm afraid it would be of little use if TW5 would be very
different from TW2. Can you comment this somehow? (I'm writing the
thing in russian initially, so I can send it right now; also, I need
to think of the multilangual approach for it)
Also, the same thing with development: I was planning to study the dev
part of TW in the next term, but if core changes considerably, would
it good enough to start with TW2?
And one more note about TW5: as for now, the approach looks very good
for handheld - I mean the buttons etc, this is even close to WYSIWYG
possibilities of Word Mobile (and "office", not plain text processors
are of big value for mobile, esp. for older devices and OSs) - keep
this in mind. But I haven't tested it yet (and even don't know if TW5
is available for download), so I can't say anything about navigation
(while usual tree of folders serves quite ok). Also, speaking about
mobile, I'll notice some subtleties with saving. For example after
some seacrch about [1] I've got a comment from a friend of mine who
said that it can be the Opera which doesn't support Java because it is
oriented on on-line work through their servers. Each page you open is
downloaded by them, processed somehow and compressed and sent to you -
and this practice seems to be popular (as I understand, SkyFire also
works so). I'll probably report on this when I find the solution.
Ofcourse, let me know if this is already known and solved.
[1] https://groups.google.com/group/tiddlywiki/browse_thread/thread/d405d4cd6c559cf3
Jeremy Ruston
> description of the links graph? It would make the file bigger for
> sure; yet names of tiddlers can be replaced with their numbers in the
> storeArea in a saved file and calculated on startup.
Persisting the extra data in the file could certainly be done, but
I've found arrangements like that to be too brittle: it's too easy for
the metadata and the data to fall out of sync with one another.
> I have one more question. I'm writing quite big and consistent manual
> for TW (along with many thoughts on interface, styling, navigation
> etc) but I'm afraid it would be of little use if TW5 would be very
> different from TW2. Can you comment this somehow? (I'm writing the
> thing in russian initially, so I can send it right now; also, I need
> to think of the multilangual approach for it)
I'd always favour maintaining tight standards of backwards
compatbility as we move to successive versions of TiddlyWiki, and I'd
hope that we could add and extend features in a way that encourages
people to upgrade to newer versions.
> Also, the same thing with development: I was planning to study the dev
> part of TW in the next term, but if core changes considerably, would
> it good enough to start with TW2?
Definitely start with TW2. Any subsequent developments to TiddlyWiki
will always be strongly related to the current code base.
> And one more note about TW5: as for now, the approach looks very good
> for handheld - I mean the buttons etc, this is even close to WYSIWYG
> possibilities of Word Mobile (and "office", not plain text processors
> are of big value for mobile, esp. for older devices and OSs) - keep
> this in mind. But I haven't tested it yet (and even don't know if TW5
> is available for download), so I can't say anything about navigation
> (while usual tree of folders serves quite ok). Also, speaking about
> mobile, I'll notice some subtleties with saving. For example after
> some seacrch about [1] I've got a comment from a friend of mine who
> said that it can be the Opera which doesn't support Java because it is
> oriented on on-line work through their servers. Each page you open is
> downloaded by them, processed somehow and compressed and sent to you -
> and this practice seems to be popular (as I understand, SkyFire also
> works so). I'll probably report on this when I find the solution.
> Ofcourse, let me know if this is already known and solved.
That sounds like Opera Mobile. Confusingly, Opera have two different
mobile browsers:
Anyhow, in the mobile space, there is no good cross-platform solution
for TiddlyWiki to save changes. I think that the best bet for many
platforms is to use apps - little wrapper apps that encapsulate the
stock TiddlyWiki HTML file and extend it with native saving
capabilities. On the iPad and now the iPhone there is TWMobile and
TWEdit:
http://itunes.apple.com/gb/app/twmobile/id381945222?mt=8
http://itunes.apple.com/gb/app/twedit/id409607956?mt=8
And for Android phones there is AndTidWiki:
http://mgsimon.de/android/andtidwiki/
Best wishes
Jeremy
> [1] https://groups.google.com/group/tiddlywiki/browse_thread/thread/d405d4cd6c559cf3
Yakov
already works with errors, why not implement this along with somewhat
"refactor links" button? Since tiddlers are not renamed frequently,
this could be an ok solution for link binding.
I must notice, the current behavior (with "errors") has one advantage:
namely, if wikiwords are used as names of classes (in
{{ClassName{..}}} wrappers), the tiddler ClassName (which probably
doesn't exist) has the corresponding list of references which
sometimes is useful for aggregation some semanical elements. Although
the toolbar macro can't make the list of references to some other (not
current) tiddler, which makes such aggregation somewhat awkward.
----
> I was hoping that we'd get to the point where the advantages of completely rebuilding TiddlyWiki from the ground up would outweigh the disadvantages of losing backwards compatibility.
(this is from http://tiddlywiki.com/tiddlywiki5/ , TiddlyWiki
tiddler). Perhaps I've got something wrong.
> Definitely start with TW2. Any subsequent developments to TiddlyWiki
> will always be strongly related to the current code base.
publicly after the exams, so I hope first pieces of documentation will
appear in the end of Jan - start of Feb.
----
speaking about Opera Mobile.
Is it true that TiddlySaver is written in JSE and JSE needs a Java
virtual mashine (such as CrEme, http://www.nsicom.com/Default.aspx?tabid=138),
not Java emulator? Can TiddlySaver be rewritten in JME (probably not,
since it interacts with filesystem..)?
> I think that the best bet for many platforms is to use apps -
> little wrapper apps that encapsulate the stock TiddlyWiki
> HTML file and extend it with native saving capabilities.
mean?" Actually I don't understand what should call what. If
TiddlyWiki is launched by browser only browser can interact with file
system; and if it is so, the browser must get access to file system
(for editing!) via some technology - Java or ActiveX or smth else.. So
what technology do you mean; or where I'm wrong and what other
solutions can be achieved? Do you mean that it's probably possible to
create an application which would work much like server - listen to
browser requests and do the edit work with file system?
The problem is my handheld works on Win Mobile 5 and it is unlikely
that a solution appears "by itself".