tiddlywiki 5 and html
xen
is going to abandon the use of wikitext and will focus on providing a
WYSIWYG editor backed by HTML formatted text. Wikitext will still be
available but javascript code and plugins will not be compatible with
the new version.
http://www.tiddlywiki.com/tiddlywiki5/
How do you feel about this? And I mean the change from wikitext to
html in particular.
Jeremy Ruston
> is going to abandon the use of wikitext and will focus on providing a
> WYSIWYG editor backed by HTML formatted text. Wikitext will still be
> available but javascript code and plugins will not be compatible with
> the new version.
To be fair, it's not abandoning wikitext, TW5 uses wikitext in exactly
the same way as current TiddlyWiki, as I've detailed in [twdev]. But
it offers the additional option of keeping tiddlers in HTML so that
the WYSIWYG editor can be used. So it's an additional choice, not a
reduction in choices as I think you're presenting it. The same macros
can be used in wikitext and HTML.
The incompatibility of plugins isn't directly related to the addition
of HTML features; it's more driven by the need to sort out
TiddlyWiki's APIs (which are confusing and poorly documented in
places), and the desire to support features that can't easily be
retrofitted into classic TiddlyWiki.
Best wishes
Jeremy.
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
Peter Lazarev
how about integration of tiddler-tabbar in the kernel. i think is a very
important capbility and should be delivered with every tiddlywiki
peter
Mark S.
apparently settled on one particular wiki dialect. If everyone used
the same dialect, then you could seamlessly pour data back and forth
between the various wiki-emulants.
I find the overall move to TW 5 a bit disheartening. Not all of us are
whipper-snappers that can pick up new technologies at the drop of a
hat. I was hoping for a knowledge platform that would stay stable for
a half decade or so at a time. I just about have everything working as
a productivity tool, rather than a nerd-toy. Once TW 5 is the rule of
the land, plugin developers will lose interest in the old TW, and many
will break (plugins that is, not developers) as FF and IE mutate. Its
likely that many of the plugins I'm using won't have equivalents on TW
5, or at least not for a year or two.
I've started looking at other information wrangling technologies. One
commercial product for instance has changed little in a decade, which
at this point I consider a good thing.
Mark
Jeremy Ruston
> whipper-snappers that can pick up new technologies at the drop of a
> hat. I was hoping for a knowledge platform that would stay stable for
> a half decade or so at a time. I just about have everything working as
> a productivity tool, rather than a nerd-toy. Once TW 5 is the rule of
> the land, plugin developers will lose interest in the old TW, and many
> will break (plugins that is, not developers) as FF and IE mutate. Its
> likely that many of the plugins I'm using won't have equivalents on TW
> 5, or at least not for a year or two.
I understand your concerns, and I think there's a few mitigations:
- It's going to take many months for TiddlyWiki5 to get to the point
where it's a viable replacement for bare-bones classic TiddlyWiki
- There's a huge investment (from me, from Osmosoft, from everyone in
the community) in "classic" TiddlyWiki, and content in that format,
and it's not going to go away
- I hope you'll have seen that my approach to backwards compatibility
has always been pretty aggressive. I've consistently championed
consistency and backwards compatibility over whizz-bang new features
because I believe that having a stable platform is the best basis for
a vibrant ecosystem to build on top of it
In other words, I think that the basic economics of the situation are
going to ensure that both classic TiddlyWiki and TiddlyWiki5 are going
to coexist for many years.
Best wishes
Jeremy
Xen
wikitext and also the option of having dual wysiwyg/html.
So the choice will have to be made on a per-tiddler basis.
What I am concerned with is that plugins that traverse or use wikitext
(the source of a tiddler) will have to be tailor-made for either html
or wikitext. Is there a provision to make them format-unaware?
The data plugin I mentioned in the twdev thread was a prime example.
I'd like to be able to extract records or sections, create tiddlers
out of them, and then invoke tiddler functions on those temporary
tiddlers. It is possible to make the infrastructure for this (records,
tiddlers and slices) oblivious do the data format, that is to say that
that these generic methods would support multiple formats. A html
record could be embedded in a special tag, whereas a wikitext record
could be embedded in a {{record{ ...}}} wrapper. The code would handle
all of it and the macro that is responsible for the data collection
would be unaware of the native format.
All macros would then need to call existing generic functions for text-
manipulation, all of which are tailor made to work on several native
formats. If some macro gets back a piece of text, and calls a wikifier
on that, the wikifier would know whether it is wikitext or html and
proceed accordingly. But this is difficult since text is just text and
it cannot identify itself.
What I really don't understand is that you've gone the multiple-format
+ html/wysiwyg approach and not the wikitext/wysiwyg approach.
Xen
text format is because MediaWiki has chosen such stupid markup for
bold and italics. (Well there are probably a lot of other reasons but
this is self-apparent). Everyone else has come to adopt the following
convention:
- *bold* means bold
- /italics/ means italics
- _underline_ means underline
This is the de facto convention for regular text that has no special
markup. Mozilla Thunderbird for instance will style any text according
to these rules.
And for a wiki it should be the same: **bold**, //italics//,
__underline__. Unfortunately not everyone has agreed on this.
But we're stuck with MediaWiki and we're stuck with TiddlyWiki which
also has some weird conventions that just don't look right. (!!!header
instead of === header ===)
I believe Wikispaces has it just about right except for the lack of
easy transclusion and macro-calling.
But even though there are many differing wikitext formats, this does
not mean moving away from wikitext is the better choice.
I vote for a wysiwyg editor that works with wikitext!
Jeremy Ruston
> wikitext and also the option of having dual wysiwyg/html.
> So the choice will have to be made on a per-tiddler basis.
>
> What I am concerned with is that plugins that traverse or use wikitext
> (the source of a tiddler) will have to be tailor-made for either html
> or wikitext. Is there a provision to make them format-unaware?
In TiddlyWiki5 two subtle parts of the macro processing have been more
explicitly separated. The first is the text processing to render the
source text of the tiddler to a DOM representation. For wikitext
tiddlers, this is the wikification process. For HTML tiddlers, this is
the conversion from a string of HTML to a DOM structure representing
the same HTML.
The second is the processing of dynamic content within that DOM
representation. The archetypal case is when something that has already
been displayed needs to be changed due to a change in the store. For
example, when a tiddler is first created, any links to it need to
change from italicised to non-italicised to indicate that the tiddler
now exists. This processing to refresh the display is inevitably a
DOM-based operation.
Bother of these layers of processing exist in classic TiddlyWiki, as
well, it's just they're not so well separated.
This architecture means is that precisely the same macros can be used
within HTML tiddlers and wikitext tiddlers. For macros, in classic
TiddlyWiki, the rendering process was fixed; all macros are rendered
as a <DIV> with additional attributes giving the macro parameters. So,
macro writers just had to write the DOM-based refresh mechanism for
their macros.
> The data plugin I mentioned in the twdev thread was a prime example.
Parenthetically, and I should have replied to the original thread,
I've come to believe that aggregated tiddlers can be restrictive. I've
found the best rule of thumb to be to split things up into the
smallest chunks that make semantic sense, and then to use
tags/fields/slices etc. to tie them together into multiple dynamic
aggregations for presentation and processing. I appreciate your
concern about the restriction of needing to name every tiddler. In
many cases the best way around seems to be to use synthetic names
(much as a database assigns numerical ids for records in some
situations).
> I'd like to be able to extract records or sections, create tiddlers
> out of them, and then invoke tiddler functions on those temporary
> tiddlers. It is possible to make the infrastructure for this (records,
> tiddlers and slices) oblivious do the data format, that is to say that
> that these generic methods would support multiple formats. A html
> record could be embedded in a special tag, whereas a wikitext record
> could be embedded in a {{record{ ...}}} wrapper. The code would handle
> all of it and the macro that is responsible for the data collection
> would be unaware of the native format.
It sounds like some of the complexity you've got comes from the
nesting of tiddlers inside other tiddlers, and the need to re-invent
how to encode the metadata. I've found that pulling back to a simpler,
non-hierarchical model avoids this problem.
> All macros would then need to call existing generic functions for text-
> manipulation, all of which are tailor made to work on several native
> formats. If some macro gets back a piece of text, and calls a wikifier
> on that, the wikifier would know whether it is wikitext or html and
> proceed accordingly. But this is difficult since text is just text and
> it cannot identify itself.
In the case of tiddlers, in TW5 there's a MIME type to identify the
content type.
> What I really don't understand is that you've gone the multiple-format
> + html/wysiwyg approach and not the wikitext/wysiwyg approach.
I presume by "wikitext/wysiwyg" you mean the approach of
round-tripping from wikitext to wysiwyg and back again?
I do think about that approach, particularly being aware of the
WIKIWYG project that originated at Socialtext. The roundtripping is a
hard problem (but then again so is parsing what browsers leave behind
when you type and paste into an contenteditable="true" elements).
Xen
specific answers in the original thread in twdev [1].
> This processing to refresh the display is inevitably a
> DOM-based operation.
I take it these processing scripts are tailor-made to the specific
event that was registered? I mean, if you only need to change links
from italic to bold, it makes no sense to rewrite the entire div
containing the tiddler.
> In the case of tiddlers, in TW5 there's a MIME type to identify the
> content type.
Okay so macros calling getTiddlerText would also call
getTiddlerMimeType
> > What I really don't understand is that you've gone the multiple-format
> > + html/wysiwyg approach and not the wikitext/wysiwyg approach.
>
> I presume by "wikitext/wysiwyg" you mean the approach of
> round-tripping from wikitext to wysiwyg and back again?
YES! That's what I mean! Finally :P That's what Wikispaces does and I
think it's the best solution. By FAR. Even if it is more difficult.
That was my whole point of starting this thread.
I mean, the whole multi-record thing is a complicated issue, but this
is just obvious. Obvious I say!
Well it depends on whether wikitext is going to stay FULLY supported
by all of the plugins.
If it is, then it is a non-issue, because
- users that like wikitext better than wysiwyg will stay with wikitext
- users that prefer wysiwyg over wikitext won't mind the html.
But if it isn't...
Well, I'm glad you're are at least giving it some thought.
[1] http://groups.google.com/group/tiddlywikidev/t/719cd36887de0235
Xen
----
> So I'm not against wysiwyg, and I'm not against being able to write
> the HTML, I'm against writing HTML //as a language for markup.//
FWIW, I guess there's a misunderstanding here.
I don't think anyone will be expected to compose tiddlers in raw HTML
(unless they want to). Instead, you'll be able to use wiki markup
just
like you do in TiddlyWiki 2.x.
IIRC, Jeremy said that such tiddlers would be saved with their
original
markup rather than persisting* as HTML, due to the issue of
round-tripping (wiki markup -saving-> HTML -editing-> wiki markup).
I'd prefer using HTML as common denominator, but I'm not sure how
realistic that is. (Sorry if this issue has been resolved already, it
might be buried somewhere in this rather lengthy thread.)
-- F.
* the markup would still be rendered as HTML when displaying a tiddler
Eric Weir
On Mar 30, 2010, at 12:41 PM, Jeremy Ruston wrote:
>> What I really don't understand is that you've gone the multiple-format
>> + html/wysiwyg approach and not the wikitext/wysiwyg approach.
>
> I presume by "wikitext/wysiwyg" you mean the approach of
> round-tripping from wikitext to wysiwyg and back again?
>
> I do think about that approach, particularly being aware of the
> WIKIWYG project that originated at Socialtext.
Almost all of this discussion is way, way over my head. I understand -- or misunderstand! -- enough to make me anxious, though.
My use of TiddlyWiki is not to make things look pretty. TiddlyWiki is not a presentation medium or tool for me. It is a way -- an extremely versatile way -- to create, store, organize, reorganize, and retrieve data -- in my case text. I also rely heavily on the ability to export export raw text, free of coding of any kind, to other applications for other kinds of processing, e.g., for further tweaking of structure, moving from what makes sense to me to what will be needed to help others understand, and for formatting.
Anything that detracts from the ability to do those things would make TiddlyWiki less useful and less attractive to me, tending toward uselessness to the degree that it does so.
Consider it a rant -- or perhaps better, an expression of anxiety, likely rooted in misunderstanding of flat-out ignorance.
Regards,
------------------------------------------------------------------------------------------
Eric Weir
Decatur, GA USA
eew...@bellsouth.net
Jeremy Ruston
I hope you have no need to be anxious. TiddlyWiki5 is a functional
superset of classic TiddlyWiki, no-one is going to lose features if
they choose to make the transition. TiddlyWiki5 is about adding
functionality. The discussion with Xen is about how we can add WYSIWYG
editting. There are two approaches we've seen with other wikis:
WYSIWYG editting of wikitext and WYSIWYG editting of HTML. We're
discussing which of those would be more useful in TiddlyWiki5. In
practice we'll almost certainly support both ways of operating.
> My use of TiddlyWiki is not to make things look pretty. TiddlyWiki is not a presentation medium or tool for me. It is a way -- an extremely versatile way -- to create, store, organize, reorganize, and retrieve data -- in my case text. I also rely heavily on the ability to export export raw text, free of coding of any kind, to other applications for other kinds of processing, e.g., for further tweaking of structure, moving from what makes sense to me to what will be needed to help others understand, and for formatting.
>
> Anything that detracts from the ability to do those things would make TiddlyWiki less useful and less attractive to me, tending toward uselessness to the degree that it does so.
As I say, there's no question but that TiddlyWiki5 will continue to
support wikitext in the same way as classic TiddlyWiki.
> Consider it a rant -- or perhaps better, an expression of anxiety, likely rooted in misunderstanding of flat-out ignorance.
It's cool to know how people are thinking, and what they're worrying
about. But do bear in mind that I am paying attention here, and have
been watching this group for nearly five years. I hope I've been able
to keep track of the what's important about TiddlyWiki, where it's
soul lies, and am above all concerned with backwards compatibility,
keeping what we've got, and not throwing the baby out with the
bathwater. I'm evidently not always the best at explaining things, and
it seems the best way to explore TW5 design issues is probably with
this sort of discussion. But as I say, I think it's OK to take off our
"panic hats", nothing terrible is going to happen!
Best wishes
Jeremy
> Regards,
> ------------------------------------------------------------------------------------------
> Eric Weir
> Decatur, GA USA
> eew...@bellsouth.net
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
> To post to this group, send email to tiddl...@googlegroups.com.
> To unsubscribe from this group, send email to tiddlywiki+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
Mark S.
On Apr 1, 1:08 am, Jeremy Ruston <jeremy.rus...@gmail.com> wrote:
> I hope you have no need to be anxious. TiddlyWiki5 is
> a functional superset of classic TiddlyWiki, no-one
> is going to lose features if
TW is a great product, and I certainly appreciate the effort that has
gone into making it so.
While it may be true in the technical sense that no one will lose
features, the fact that there will be no backward compatibility with
existing macros/plugins will have an immediate impact on anyone not
using the barebones TW. Following the announcement of TW5, I decided
to start over and create my own TW, using as few plugins as necessary
to get the functionality I expect. If you were to see my TW today, at
a glance you might think it to be hardly different from the basic TW.
But, in fact there are two dozen plugins required. Eliminating plugins
that will not be relevant to TW5, or that merely configure the
environment, I still have:
CalendarPlugin
CheckboxPlugin
ConfirmExitPlugin
DatePlugin
ExportTiddlersPlugin
GotoPlugin
GridViewerMacro
ImageSizePlugin
IncludePlugin
InlineJavascriptPlugin
MAS_submitFormPlugin
NestedSlidersPlugin
NewHerePlugin
ReminderMacros
SearchOptionsPlugin
SiteMapMacro
TaggedTemplateTweak
TiddlerEncryptionPlugin
TiddlersBarPlugin
TwHelpSearchPlugin
WikifyPlugin_With_MAS_Patch
TiddlerTweakerPlugin
Actually, these aren't all the macros I plan to use -- I have a series
of information management plugins that I am perfecting in a separate
TW.
You may notice that few of these plugins have anything to do with
cosmetics, WikiText or WYSIWYG. But, since TW can't handle more than
about 2M data, a macro like IncludePlugin is necessary to bring data
on and offline. The TiddlerEncryptionPlugin plugin is necessary to
continue viewing encrypted information. Calendar & reminder plugins
are essential if TW is going to compete with existing PIM software.
The basic search functionality of TW will swamp your story if you
chose a poor keyword, and interferes with basic usage, so the various
search engine tweaks are pretty important. NewHere and SiteMapMacro
are important in creating a tag-tree for navigating the data set.
Images in TW view at their native size, making their use untenable for
cataloging without a plugin like ImageSizePlugin.
I hope this gives you an feel of the experience of a semi-advanced
user on the ground. The other iterations of TW I have used very likely
used *more* plugins than this. It would be interesting to know what
percentage of daily TW users are content with core TW without any
additional plugins. I would hazard less than 25% ... and those mostly
newbies.
Thanks for listening,
Mark
Jeremy Ruston
> features, the fact that there will be no backward compatibility with
> existing macros/plugins will have an immediate impact on anyone not
> using the barebones TW.
Let's be clear: if we wanted TiddlyWiki5 to be compatible with classic
TiddlyWiki plugins, we wouldn't be able to make any of the
improvements that are driving TiddlyWiki5.
As I've said, it may be possible to devise a mapping layer that lets
some classic plugins work with TiddlyWiki5, but in general we cannot
have our cake and eat it.
But, nobody needs to suffer, because classic TiddlyWiki isn't going to
go away, and people will continue to use it until TiddlyWiki5 reaches
the point where it meets their needs.
> Actually, these aren't all the macros I plan to use -- I have a series
> of information management plugins that I am perfecting in a separate
> TW.
It's a good list. I'd expect some of those functions to migrate into
the core in TiddlyWiki5.
> You may notice that few of these plugins have anything to do with
> cosmetics, WikiText or WYSIWYG.
If I've given the impression that TiddlyWiki5 is about just cosmetics
then I'm rather dismally failing to communicate some basic things
about it!
> But, since TW can't handle more than
> about 2M data, a macro like IncludePlugin is necessary to bring data
> on and offline.
Surprisingly, I get many reports of people using TiddlyWikis that are
bigger than that.
One of the planned features for TiddlyWiki5 is an "exploded mode"
where some or all of the tiddlers live in separate files referenced
from the main TiddlyWiki file. (You will also be able to implode a
TiddlyWiki, to bring all those annexed files into the main store).
Exploded mode will make it easier for developers to work on plugins
using a standard text editor, and will permit larger datasets to be
managed by standalone TiddlyWiki
> The TiddlerEncryptionPlugin plugin is necessary to
> continue viewing encrypted information.
I'd expect encryption to remain as something best delivered in a
plugin, to make it easier to swap it out, and use different encryption
approaches
> Calendar & reminder plugins
> are essential if TW is going to compete with existing PIM software.
I think a basic calendar plugin would be useful for the core, but in
general I've learned that what I might call the GTD space is best
served by plugins that explore different methodologies, and that the
core TW5 code should remain a neutral platform for building different
types of GTD-type systems.
> The basic search functionality of TW will swamp your story if you
> chose a poor keyword, and interferes with basic usage, so the various
> search engine tweaks are pretty important.
TW5 definitely needs to fix search in the core.
> NewHere and SiteMapMacro
> are important in creating a tag-tree for navigating the data set.
Yes, I think that the core should provide better support for different
tagging scenarios.
> Images in TW view at their native size, making their use untenable for
> cataloging without a plugin like ImageSizePlugin.
I think this should be fixed in the TW5 core.
> I hope this gives you an feel of the experience of a semi-advanced
> user on the ground. The other iterations of TW I have used very likely
> used *more* plugins than this. It would be interesting to know what
> percentage of daily TW users are content with core TW without any
> additional plugins. I would hazard less than 25% ... and those mostly
> newbies.
Best wishes
Jeremy.
> Thanks for listening,
> Mark
Saverio
That is, being able to associate a relationship type with the tag
instead of just assuming generic "isA"? Extended fields does this to
some extent, but they are hidden and not as easy to use as tags. It
would be cool to combine the functionalities of both tags and extended
fields.
> Yes, I think that the core should provide better support for different
> tagging scenarios.
> --
> Jeremy Ruston
> mailto:jer...@osmosoft.comhttp://www.tiddlywiki.com
Jeremy Ruston
> That is, being able to associate a relationship type with the tag
> instead of just assuming generic "isA"? Extended fields does this to
> some extent, but they are hidden and not as easy to use as tags. It
> would be cool to combine the functionalities of both tags and extended
> fields.
I'm currently modelling tags the same as before: as a list of strings,
with no internal structure.
You could certainly imagine extending the core tagging to include a
relationship type that defaults to "is a", as you suggest. I'd thought
idly in the past about doing this in a lightweight way by supporting
the convention of dealing with tags of the format
<relationship>:<target>, like Flickr. It'd be interesting to explore
what you think would be the smallest extension to classic TiddlyWiki
that would unlock your desired functionality,
Best wishes
Jeremy
Saverio
1) extending the tag definition to optionally allow definition of the
relationship type as:
tags = "conventionalUntypedTag1 isA(tagA) conventionalUntypedTag2
belongsTo(tagB) dependsOn(tagC)"
2) then storing these under the cover as extended fields
isA = conventionalUntypedTag1 conventionalUntypedTag2
belongsTo = tagB
dependsOn = tagC
3) but enhancing or adding tag access methods that allow retrieval/
editing of the relationship type as well as the tag values would go a
LONG way...
Thank you for considering!
Saverio
> isA = conventionalUntypedTag1 conventionalUntypedTag2
Mike
InlineJavascript (plugin or native) w/ TW5
Mike
Mark S.
On Apr 1, 6:11 am, Jeremy Ruston <jeremy.rus...@gmail.com> wrote:
> > Calendar & reminder plugins are essential if TW is
> > going to compete with existing PIM software.
>
> I think a basic calendar plugin would be useful for
> the core, but in general I've learned that what I
> might call the GTD space is best served by plugins
> that explore different methodologies, and that the
> core TW5 code should remain a neutral platform for
> building different types of GTD-type systems.
There are a great number of applications and/or software enhancements
that invoke the GTD brand. I get the impression that a great many of
their proponents haven't actually read the book, but have done a scan
of the wikipedia entry. In GTD, the calendaring (new word?)
requirements are actually very simple. David Allen is very clear that
calendars should not be a place to hang daily todo lists. Calendars,
he says, should be used for:
* time specific actions
* day specific actions
* day specific information
He says,
"Those three things go on the calendar, and nothing
else! I know this is heresy to traditional time-
management training, which has almost universally
taught that the 'daily-to-do-list' is key. But such
lists don't work, for two reasons"
(Page 40, GTD Penguin Paperback, 2003 edition)
If there is more than one or two good calendaring plugins, I'm not
aware of them. I suspect most everyone is using Eric's calendar and
Jeremy Sheeley's Reminder plugin. That only thing lacking from this
arrangement is the recording of "time-specific" actions.
Any calendaring system that could record the three pieces of
information stated above, should be amenable to GTD.
Thanks,
Mark
Jeremy Ruston
> InlineJavascript (plugin or native) w/ TW5
TW5 will definitely support InlineJavaScript via a plugin, but I'm
very cautious about putting it into the core. In shared environments
it could be a vector for malicious code. It'd be OK if we could
adequately sandbox the execution of the javascript fragments, but I
haven't found that to be possible with current browsers.
I think the best balance is for the core to continue with the current
approach of systemConfig-style plugins implementing macros that are
then referenced by macro invocations in the text. By keeping the code
and content strictly separate we can allow servers to implement
protection measures, like only executing plugins from trusted sources.
Cheers
Jeremy
>
> Mike
>
> On Apr 1, 10:19 am, Saverio <saverio.mavig...@gmail.com> wrote:
>> Oops, tagA would be stored under the isA extended field, as well:
>>
>> > isA = conventionalUntypedTag1 conventionalUntypedTag2
>
> --
> You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
> To post to this group, send email to tiddl...@googlegroups.com.
> To unsubscribe from this group, send email to tiddlywiki+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
>
>
--
Mike
customization options to the end user. I know you mentioned backwards
compatibility - are you thinking of something like
DepreciatedFunctions? Allowing some old plugins to get in, but not
creating a core code increase. . . Kind of a best of both worlds
scenario
I think the TW5 prototype is awesome, and justly so is creating a lot
of discussion !
Just a question of timing, are you thinking of a alpha version in
2010, or is everyone jumping the gun a little?
Keep up the good work !
Mike
> > For more options, visit this group athttp://groups.google.com/group/tiddlywiki?hl=en.
AlanBCohen
consider moving into the core for TW5, I am left wondering about fET?
This is the single, most important extension for any of my TW files;
calendar, status reporting, addressbook, knowledge databases of
various subjects, and blood sugar tracking (I'm a diabetic).
Next would be the DataTiddler and FornTiddler plugins that allow me to
build useful templates for entering structured information ( a lot of
my content falls in this category).
I realize there are many people with a wide variety of needs; but I
will be staying with the current TW series until these capabilities
are available in a replacement.
Alan
Jeremy Ruston
> customization options to the end user. I know you mentioned backwards
> compatibility - are you thinking of something like
> DepreciatedFunctions? Allowing some old plugins to get in, but not
> creating a core code increase. . . Kind of a best of both worlds
> scenario
That's the idea. I think it's possible, but I don't want to raise
expectations too much as many plugins of necessity play some quite
dirty tricks to achieve their goals. (Not that they're badly written,
just that TiddlyWiki's architecture sometimes requires these slightly
dirty tricks).
> Just a question of timing, are you thinking of a alpha version in
> 2010, or is everyone jumping the gun a little?
Yes, that is the goal. As usual I'm not getting to spend as much time
on it as I would like. The focus for Osmosoft as a whole is still
firmly on classic TiddlyWiki, it's just me working on TW5 at the
moment.
Cheers
Jeremy
> For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
Jeremy Ruston
needs to be built into the core.
The prototype includes the bare bones of support for a jQuery-like
filter chaining syntax that will permit tiddler selection and sorting
in an efficient and readable form of JavaScript. I'm envisaging
building a visual representation on top of that, which would permit
end users to type or drag and drop filter queries, somewhat like the
email rules dialogs you find in email clients. Then I'd like to wrap
that around a templating mechanism that permits the filtered tiddlers
to be displayed through templates that are selected by template.
(TiddlyWiki already includes a templating mechanism, of course).
So, you'd be able to compose a filter that, say, pulls out all of your
recent posts, orders them, and selects a template for each one based
on whether it's a photograph, video, or text post.
Best wishes
Jeremy
twgrp
> Any thought paid to supporting semantically rich tagging in TW 5?
> That is, being able to associate a relationship type with the tag
A note here, assuming I understand you right; Because tags are
interchangeable with tiddler names, it *is* possiblt to type a tag...
by tagging it!
We already have many (but not all[1]) of the tools to benefit from
this, i.e regarding filtering etc.
[1] At least one such missing filter is to be able to get "all
tiddlers tagged with any of the tiddlernames [B1,B2...] that are of
type C (i.e tagged C)". I just raised a related question here;
http://groups.google.com/group/tiddlywiki/browse_thread/thread/45f39cd12f4c47be#
Knightnet
please everyone but I think everyone WILL say that TW has already been
an amazing success and a brilliant concept well developed. I for one
am looking forward very much to see a new version using the latest
concepts & I've no doubt that it will be well implemented.
If you were to look back at a few of my past posts in this group,
you'd see that I've always wanted HTML storage and WYSIWYG in TW, I'm
not a fan of WIKI markup - life is too short to keep trying to
remember it all and worst of all, I can't just copy & paste from a web
page or a Word document and expect it to "just work" which is what I
need if the tool is to be useful on a daily basis.
I like the ideas presented behind TW5 and TiddlyWeb - great work
everyone and thanks!
Regards, Julian Knight
http://it.knightnet.org.uk, http://www.totallyinformation.com
Jeremy Ruston
from an experiment to a welcoming and useful ecosystem has been thanks
to the contributions of many other people such as Eric, Saq, Simon and
Daniel, Chris Dent, Udo Borkowski and lots more.
The html/wikitext dichotomy is interesting on many levels, and I hope
TiddlyWiki5 will serve as a good tool for both situations, and allow
experiments towards blends of both approaches.
Cheers
Jerm