Announcing an early prototype for TiddlyWiki5
Jeremy Ruston
background planning for a proper overhaul of TiddlyWiki itself, doing
some little proof-of-concept experiments, and tracking browser
developments. 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. I
think that we've now reached that point, thanks mainly to the
accelerated development of the major browsers.
Over Christmas and New Year, when the office shut down, I finally had
the chance to spend some sustained time in coding-space, and stitch
some of these thoughts and experiments into a proper prototype. I've
kept it completely to myself up until now, partly for fear of
distracting efforts away from other things.
http://www.tiddlywiki.com/tiddlywiki5/
It's status is that it's just a prototype, and it's not in a fit state
to be used in anger; I've focussed on the things missing or broken in
the original TiddlyWiki, and not paid too much attention to areas that
don't need to change much. So, it's not currently structured as a
single file, nor is it capable of saving changes. However, it does
demonstrate some key new features and capabilities. There are three
areas I'd like to focus on:
- Embracing HTML
By default, tiddlers are stored and edited as HTML. This means that
you get a proper WYSIWYG editor, and that when Google looks at a
TiddlyWiki5 file it will also see the content properly. It's been
clear for a long time that wikitext is both a strength and a weakness
of classic TW, it gives users great power, but it's incredibly
off-putting for people who expect to type ctrl-B for bold. My goal in
bringing WYSIWYG to TiddlyWiki is to maintain the ability to type
macros and formatting directly, without going into weird sub-dialogs.
This is because I believe that the real power of wikis is the way that
they elevate linking to becoming part of the punctuation, and hence
the writing process, instead of an operation performed afterwards.
Anyhow, it's not all implemented yet, but in edit mode macros are
represented as special "proxy" visual objects that can have custom
interactions, but can be selected/copied/pasted just as if they were a
single character of text.
- Graphics as First Class Citizen
Both bitmap and vector graphics are now a first class citizen, with
image tiddlers embedded directly in the TiddlyWiki file, even in IE6.
There's support for SVG vector graphics (with a plan to cross-render
to VML for IE support). The idea is to be able to associate icons with
tiddlers (and hence tags), and use the icons to represent those
tiddlers in the UI. My mum is busy creating a library of a few hundred
little conceptual graphics to ship with the thing.
- Cleaning up
But the real benefit is that the design is now much smoother top to
bottom. TiddlyWiki originally evolved in fits and starts, and bears
the scar tissues of me learning JavaScript as I went. In TiddlyWiki5,
for instance, almost everything is a macro, including tiddler
containers (aka a TiddlyWiki "story"), and tiddler frames. It uses
jQuery and jQuery UI properly, leading to much more concise and clear
code. It properly matches the capabilities of TiddlyWeb, with revision
history retained for each tiddler and support for different
MIME-types.
I should say that although TiddlyWiki5 will break backwards
compatibility, there will be a migration path for existing TiddlyWiki
content. Firstly, it will support the existing TiddlyWiki wikifier, so
people can continue to use and edit tiddlers in wikitext if they want
to. Secondly, you will be able to perform a one-way upgrade of your
tiddlers from wikitext to html format. There'll be no going back at
that point, but in exchange you'll be able to use the WYSIWYG editor.
I stress that there's a lot to do before this thing is properly
usable, but I'm hoping it's at the point where the development
community can see how it's supposed to fit together, and we can start
to think about it as a group.
Very roughly, I was thinking of the following roadmap:
- Declare "alpha" when it works (ie, editting and save changes work properly)
- Declare "beta" when it's more or less feature complete
- Declare "release" when it's reliable
I'd hope that we could be at alpha in a couple of months, and release
sometime in the (northern hemisphere) summer, but it all rather
depends on what we decide as a group. I'll publish the code in GitHub
in the next couple very few hours.
I appreciate that this might be a bit out of the blue, but I hope it's
a pleasant surprise. Do please feel free to ask questions,
Best wishes
Jeremy
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
Mike
Thank you for sharing your vision of the future :D
How will this effect current plugins?
(I did see the tiddler upgrade, I am assuming this would be for data)
I like the two column display, the lean layout and the search bar
static on the bottom of the browser.
Mike
Paul Downey
> Very nice !
>
> Thank you for sharing your vision of the future :D
ditto
> How will this effect current plugins?
> (I did see the tiddler upgrade, I am assuming this would be for data)
I'm assuming there's no easy way to upgrade plugins, and this will
make a lot of them feel hacky and passe anyway.
I'm happy with this direction given the jQuery / HTML centricity will
vastly simplify authoring new plugins - the core code looks far more
grokable than the current core.
> I like the two column display, the lean layout
I gather this is demonstrating multiple stories, which will make
building verticals much more interesting.
> and the search bar
> static on the bottom of the browser.
I like my search bar at the top of the page, but can see that's all tunable.
--
Paul (psd)
http://blog.whatfettle.com
Jeremy Ruston
TiddlyWiki plugins into TiddlyWiki5. This is because the underlying
programming model has had to change quite a bit to enable the new
features.
I believe that it would be possible to write a little mapping layer
that would provide traditional TiddlyWiki APIs within TiddlyWiki5.
With such a thing, it may be possible to get some plugins to run. I'm
specifically interested in the little edge case of being able to
migrate some decent percentage of foreachtiddler incantations.
Cheers
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.
Mike
(InlineJavascriptPlugin)
Last year I converted all of my fET to ILJS, and have an extensive
amount scripts throughout my daily use TW
As all things go, I anticipate it may be a while before I could change
into TW5 completely, but I look forward to the new possibilities it
creates.
I took a look at the source after reading Paul's comments, and that
also looks very tidy - a lot of it is over my head, but the general
organization is much better.
Mike
On Jan 28, 2:38 am, Jeremy Ruston <jeremy.rus...@gmail.com> wrote:
> Paul's correct, out of the box, it won't be possible to drop existing
> TiddlyWiki plugins into TiddlyWiki5. This is because the underlying
> programming model has had to change quite a bit to enable the new
> features.
>
> I believe that it would be possible to write a little mapping layer
> that would provide traditional TiddlyWiki APIs within TiddlyWiki5.
> With such a thing, it may be possible to get some plugins to run. I'm
> specifically interested in the little edge case of being able to
> migrate some decent percentage of foreachtiddler incantations.
>
> Cheers
>
> Jeremy
>
>
>
> On Wed, Jan 27, 2010 at 9:00 PM, Paul Downey <paul.dow...@whatfettle.com> wrote:
> > On Wed, Jan 27, 2010 at 8:07 PM, Mike <eris...@gmail.com> wrote:
> >> Very nice !
>
> >> Thank you for sharing your vision of the future :D
>
> > ditto
>
> >> How will this effect current plugins?
> >> (I did see the tiddler upgrade, I am assuming this would be for data)
>
> > I'm assuming there's no easy way to upgrade plugins, and this will
> > make a lot of them feel hacky and passe anyway.
>
> > I'm happy with this direction given the jQuery / HTML centricity will
> > vastly simplify authoring new plugins - the core code looks far more
> > grokable than the current core.
>
> >> I like the two column display, the lean layout
>
> > I gather this is demonstrating multiple stories, which will make
> > building verticals much more interesting.
>
> >> and the search bar
> >> static on the bottom of the browser.
>
> > I like my search bar at the top of the page, but can see that's all tunable.
>
> > --
> > Paul (psd)
> >http://blog.whatfettle.com
>
> > --
> > 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 athttp://groups.google.com/group/tiddlywikidev?hl=en.
Morris Gray
> Speaking of fET, I was hoping to be able to migrate all of my scripts
> (InlineJavascriptPlugin)
> Last year I converted all of my fET to ILJS, and have an extensive
> amount scripts throughout my daily use TW
I have been doing the same thing. While fET is tremendous it does
cause one to avoid learning Javascript which is much more generally
useful. Supporting migration of legacy fET might be necessary in the
beginning, but I don't think it should ultimately take precedence as a
core support over the Javascript standard.
Morris
Anthony Muscio
I look forward to tiddlyWiki's evolutionary change. I want to flag here a strong interest in tagging functionality been improved in the core. The reason is that tagging offers such a substantial advantage buy effectively providing sets to which tiddler may or may not belong. When tags are also tiddlers you can quickly find the members of that set.
Most people using tiddlywiki quickly adopt tagging as an organising system and to drive status settings for task tools, and linking tiddlers in knowledge and hierarchical systems. A set of simple but highly adaptable tools for sophisticated tag manipulation should be part of tiddlywiki's evolution (especially, but not because of the need to port current plugins).
Such Tagging facilities should include
NewHearPlugin features allowing a quick hierarchy to be created
Toggling tags including lists with toggle check boxes.
Cycling Tags through a set -eg; Set next, unset last
Conditional toggling - eg; if tagged tag1 then - untage tag1 then add tag2 and tag 3
Set manipulation through tags - eg; Join all items tagged tag1 with all items tagged tag2 and tag them with Tag3
Such features would allow use of these core tools to do what many spend days developing. It may also allow novice users to quickly expand the capabilities of their tiddlywiki's without reference to individual addons and plugins.
If I can help by writing draft specifications I would be happy to do so. I expect coding these will be relatively trivial. Please let me know.
Regards Tony
TonyM
If you have not found an easy way to do it with TiddlyWiki, you have missed something.
www.tiddlywiki.com
Måns
"An important macro is displayTiddler, which creates a tiddler frame
(marked with the class "tw_tiddlerFrame") that displays a tiddler
complete with a UI for editting, and switching between revisions."
?1
The revisionstory:
Is it limited to a "session" (reset when document is saved) or is it a
story following a tiddler for life? (Is revisionstory available for
"standaloneTWs"? and what are the consequences speaking of filesize
etc..? )
> you get a proper WYSIWYG editor, and that when Google looks at a
> TiddlyWiki5 file it will also see the content properly.
I sort of like that Google search can't digg what's under the hood,
and I'm the one who is in charge, giving direct links to material...
> Firstly, it will support the existing TiddlyWiki wikifier, so
> people can continue to use and edit tiddlers in wikitext if they want to.
searchengines?
?3
Will transclusions and referring to sections in a tiddler as if they
were individual tiddlers still be available?
?4
My first instinct when viewing TiddlyWiki5 was to try to drag a
tiddler to the right (second storycolumn?) expecting the next tiddler
to pop up from underneath - something like "rearrange tiddlers" just
in two panes....
> for instance, almost everything is a macro, including tiddler
> containers (aka a TiddlyWiki "story"), and tiddler frames. It uses
> jQuery and jQuery UI properly, leading to much more concise and clear code.
instant rearranging of tiddlers?
I would love to see some kind of jquery implementation of Eric's
moveable panels - but that might be a plugindev question?? ..
!5
>I'm specifically interested in the little edge case of being able to
>migrate some decent percentage of foreachtiddler incantations.
I'm doing with TiddlyWiki, hadn't it been for fForEachTiddlerPlugin..
I believe it is needed in some way or another, not to (FND
citation):"... perpetuate reliance on a small group of established
experts. " if TiddlyWiki should be as tweakable for nonprogrammers
(like me) in the future...
I wouldn't use TW today if I couldn't solve most problems myself..
ForeEachTiddlerPlugin gives me the buildingblocks...
On the other hand fET needs an overhaul/update of documentation to
reflect what it is actually capable of in terms of using other params
than "just" text and tags - fields,slices sections and datafields are
currently available as well...
6
> I appreciate that this might be a bit out of the blue, but I hope it's a pleasant surprise.
I get a feeling that getting to know TiddlyWiki, as a newcommer, in a
year or so - will be a less frustrating experience that it has been.
WysiWyg "out of the box" - will most certainly make guests and
newcommers feel confident from the start..
Regards Måns Mårtensson
Måns
> little conceptual graphics to ship with the thing.
environmental condition? ;-)
Wolfgang has collected all kinds of graphics used by the TiddlyWiki
community in his TWdocument "img" http://img.tiddlyspot.com/". It's
used in his TWdocument: "Changes"
http://change.tiddlyspot.com - It would be very nice to have a
retrospective collection of graphics shipped with TW5..
Regards Måns Mårtensson
Michael Mahemoff
On Wed, Jan 27, 2010 at 6:36 PM, Jeremy Ruston <jeremy...@gmail.com> wrote:
http://www.tiddlywiki.com/tiddlywiki5/
Is there a procedure for downloading and running?
I've tried to download and run it in my browser. I downloaded the HTML and 4 JS files. It renders okay, though the tiddler buttons show times instead of icons. But I can't actually edit?
Paul Downey
> Such Tagging facilities should include
> NewHearPlugin features allowing a quick hierarchy to be created
> Toggling tags including lists with toggle check boxes.
> Cycling Tags through a set -eg; Set next, unset last
> Conditional toggling - eg; if tagged tag1 then - untage tag1 then add tag2
> and tag 3
> Set manipulation through tags - eg; Join all items tagged tag1 with all
> items tagged tag2 and tag them with Tag3
That's quite a list, and whilst I agree tagging is central, there's a
risk that adding many such features fight against what would be my
demand, that TiddlyWiki is as small as possible.
Putting too many features in the core makes developing TiddlyWiki5
harder to scale amongst other open source developers than a
micro-kernel core with as much as sensible pushed out into optional
extensions.
So I'd want to have all such features available, but as plugins,
and keep the core as small as possible to avoid the risk of big box
with flat batteries included which characterises many platforms,
such as the original jQueryUI library.
What will help developers are stronger constraints on what may be
safely extended, and places to converge, coordinate and agree on
names and methods crossing between plugins, so that for example,
my geotagging plugin works with someone else's maps plugin.
I can see this is starting to happen in TW5, with more functions
protecting features using closures, and exposing in a uniform way,
using jQuery like function chaining.
With the smallest core possible approach, there's nothing to prevent people
building *up* their own bundled distributions, so indeed a super-tagging
TiddlyWiki5 could be offered alongside other vertical editions, as indeed
with the current TiddlyWiki except many editions currently end up having
build *down* by masking superfluous core features.
Finally, what might help users build their own editions is if the process of
finding good quality plugins was more streamlined. I hesitate to say
"core" or "standard" plugins, or even "app store" but a simple and reliable
way of discovering and including high quality extensions will help keep
the mico-kernel core as small as possible and yet allow TiddlyWiki5 to
become as rich and feature complete as people would like.
Paul Downey
>> TiddlyWiki5 file it will also see the content properly.
I wonder how this plays with HTML 5 ContentEditable,
which is gathering support:
http://blog.whatwg.org/the-road-to-html-5-contenteditable
Michael Mahemoff
What will help developers are stronger constraints on what may be
safely extended, and places to converge, coordinate and agree on
names and methods crossing between plugins, so that for example,
my geotagging plugin works with someone else's maps plugin.
I can see this is starting to happen in TW5, with more functions
protecting features using closures, and exposing in a uniform way,
using jQuery like function chaining.
Agree. More open APIs with a clear event mechanism (probably based on jQuery custom events), and plugins will be able to go a lot further without monkey patching. The tiddler chaining concept will be a massive boon.
Finally, what might help users build their own editions is if the process of
finding good quality plugins was more streamlined. I hesitate to say
"core" or "standard" plugins, or even "app store" but a simple and reliable
way of discovering and including high quality extensions will help keep
the mico-kernel core as small as possible and yet allow TiddlyWiki5 to
become as rich and feature complete as people would like.
I agree entirely and have been very keen to see this kind of micro-kernel core, all this assumes it's easy for users to add and customise plugins. So that's one of the most important things to me. Speaking to regular users of TiddlyWiki, those who aren't even aware this group exists, I've met very savvy developers who use TW as a general scrapbook and aren't even aware of plugins, let alone knowing how to install them or how to make them.
Right now, backstage lets you import a tiddlywiki and then select plugins. But I would like to see a much friendlier approach - a place where you can browse, search, and install plugins at a single click. This would be a "blessed" - official - plugin repo, well-maintained, patrolled for spam etc; hopefully building on the work that Saq, Fred, and others have already done on this kind of thing. The protocol and source code would be open, so that anyone else could set up the same thing for someone to point to. This is a widespread phenomenon when it comes to open source plugin architectures. Prior art includes: WordPress, Firefox, Chrome, Vim, jQuery, Eclipse IDE, and many more. All of those are open-source projects which still have an official place for plugins, to go along with the thousands of other places they can be found elsewhere on the web.
Jeremy Ruston
very interesting. I've got some thoughts about tagging, some of which
show up in the prototype:
- We keep the tiddlers being tags thing, I agree it's been successful
- The core storage mechanism will index tiddlers by tag, making
searching by tag much, much faster
- The tiddler selector mechanism will allow you to use tag-based
filters in several places. For instance, in the current prototype the
left hand column is marked up with an "accept" parameter that causes
it to display all tiddlers tagged "documentation", with non-matching
tiddlers falling through to the next column
- By associating an image with a tag, we can show tags graphically,
and, for instance, make them behave like checkboxes where one can
apply and remove a tag just by clicking the icon
Further, I'm trying to decompose some of the classic TiddlyWiki macros
so that they can be more easily customised. For instance, making a
popup macro into which one places a
list-of-all-tiddlers-with-a-given-tag macro. So, for advanced users,
instead of just having pre-canned macros like <<tagging>> and
<<tagged>>, they'd be able to construct more complicated
customisations. And as you can see if you flip one of the tiddlers
into edit mode on the prototype, these macros are very visual, and
will support drag-and-drop and so on to make them easy to manipulate
Best wishes
Jeremy
--
Jeremy Ruston
> "An important macro is displayTiddler, which creates a tiddler frame
> (marked with the class "tw_tiddlerFrame") that displays a tiddler
> complete with a UI for editting, and switching between revisions."
> ?1
> The revisionstory:
> Is it limited to a "session" (reset when document is saved) or is it a
> story following a tiddler for life? (Is revisionstory available for
> "standaloneTWs"? and what are the consequences speaking of filesize
> etc..? )
The full revision history of all tiddlers can be retained in the local
file TiddlyWiki. We'll need some controls to manage filesize (eg only
keep the last 2 days revisions, or the last 10 revisions). We could
also explore some highly compressed representations which only store
the diffs between consecutive versions of tiddlers.
The motivation is to be able to work on a TiddlyWiki offline, and then
sync it to the cloud without losing your revision history; I think of
the revision history as being both an escape mechanism to get out of
trouble when you mess things up, and as a way of giving users access
to the provenance of information.
>> you get a proper WYSIWYG editor, and that when Google looks at a
>> TiddlyWiki5 file it will also see the content properly.
> ?2
> I sort of like that Google search can't digg what's under the hood,
> and I'm the one who is in charge, giving direct links to material...
Tiddlers can be stored in the TW5 file in several different formats,
some of which will not be crawled by Google, and some of which would
be. So, one could arrange things so that ones actual content was
visible, but plugins and other plumbing were stored, say, in an
x-tiddler script tag so that Google would ignore them.
>> Firstly, it will support the existing TiddlyWiki wikifier, so
>> people can continue to use and edit tiddlers in wikitext if they want to.
> Will the Wikifier edited text be read as easily as html by
> searchengines?
Tiddlers in wikitext would be stored in the file as wikitext, so
Google would see wikitext, just as it goes with current TiddlyWiki.
> ?3
> Will transclusions and referring to sections in a tiddler as if they
> were individual tiddlers still be available?
Yes, although it's not there now.
> ?4
> My first instinct when viewing TiddlyWiki5 was to try to drag a
> tiddler to the right (second storycolumn?) expecting the next tiddler
> to pop up from underneath - something like "rearrange tiddlers" just
> in two panes....
That's what I'm aiming for. Essentially, the functionality that one
expects from things like NetVibes
>> for instance, almost everything is a macro, including tiddler
>> containers (aka a TiddlyWiki "story"), and tiddler frames. It uses
>> jQuery and jQuery UI properly, leading to much more concise and clear code.
> Do you have any specific intentions implying some kind of zui/gui
> instant rearranging of tiddlers?
Cecily was my testbed for exploring some of this stuff:
http://www.osmosoft.com/cecily/
and
http://www.osmosoft.com/~jermolene/zoombox/
(Best experienced in Chrome or Safari)
I'm interested in being able to right-click on any icon in TW5 and
click "edit", and then have the image zoom up to fill the page, with
editting controls sliding in.
I like the Tiddly960 thing, I've also been getting interested in
columnar grid layouts. I like the idea of grids that you can zoom
into, and that reveal additional information when you do.
I like zooming because it allows you to progressively reveal
affordances for direct manipulation.
> I would love to see some kind of jquery implementation of Eric's
> moveable panels - but that might be a plugindev question?? ..
As I say, this should be built in. Furthermore, the tiddler container
mechanism makes it easy to, say, arrange that any tiddler link clicked
within a story should appear in a moveable popup.
> !5
>>I'm specifically interested in the little edge case of being able to
>>migrate some decent percentage of foreachtiddler incantations.
> I'm glad to hear that - as I wouldn't be able to do most of the things
> I'm doing with TiddlyWiki, hadn't it been for fForEachTiddlerPlugin..
> I believe it is needed in some way or another, not to (FND
> citation):"... perpetuate reliance on a small group of established
> experts. " if TiddlyWiki should be as tweakable for nonprogrammers
> (like me) in the future...
Yup, I agree: the appetite for FET is one of the big learnings for me
about TiddlyWiki.
> I wouldn't use TW today if I couldn't solve most problems myself..
> ForeEachTiddlerPlugin gives me the buildingblocks...
> On the other hand fET needs an overhaul/update of documentation to
> reflect what it is actually capable of in terms of using other params
> than "just" text and tags - fields,slices sections and datafields are
> currently available as well...
> 6
>> I appreciate that this might be a bit out of the blue, but I hope it's a pleasant surprise.
> Very much indeed - Thanks for sharing the prototype.
> I get a feeling that getting to know TiddlyWiki, as a newcommer, in a
> year or so - will be a less frustrating experience that it has been.
> WysiWyg "out of the box" - will most certainly make guests and
> newcommers feel confident from the start..
Many thanks for the kind comments, much appreciated,
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
> community in his TWdocument "img" http://img.tiddlyspot.com/". It's
> used in his TWdocument: "Changes"
> http://change.tiddlyspot.com - It would be very nice to have a
> retrospective collection of graphics shipped with TW5..
Yes, definitely. It's a longer subject but one of the things that we
need to do better this time around is establishing shared libraries
for images, plugins etc.
Cheers
Jerm
>
> Regards Måns Mårtensson
>
> --
> 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
>
> I've tried to download and run it in my browser. I downloaded the HTML and 4
> JS files. It renders okay, though the tiddler buttons show times instead of
> icons. But I can't actually edit?
Ouch, looks like we need to get it on GitHub so it's easier to get all
the pieces. FND gave me an idiots guide to Git, but it's way too
advanced for me...
Anyhow, showing times instead of icons is super weird, can you zip up
and send me what you've got?
Cheers
Jerm
Jeremy Ruston
Firefox finally supporting contentEditable instead of just designMode.
It now means (as you've seen from the HTML5 docs) that we've got a
moderately reasonable, reasonable cross-browser API for rich text
editting.
The trick that I got very excited about was experimenting with what
happens when you've got a non-contentEditable DIV embedded inside a
contentEditable one. The non-edittable DIV behaves like a token, or a
single meta character, and can be copied and pasted quite happily. I
felt this was awesome as it allows us to get the best of wikitext in a
WYSIWYG context
Cheers
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.
>
>
--
FND
> Ouch, looks like we need to get it on GitHub so it's easier to get all
> the pieces. FND gave me an idiots guide to Git, but it's way too
> advanced for me...
$ cd tiddlywiki5
$ git init
$ git remote add origin g...@github.com:Jermolene/tiddlywiki5.git # see [1]
$ git add index.html *.js images/*.svg # see [2]
$ git commit -m "initial commit"
$ git push origin master
My blog post[3] is probably more of a starting point to know which man
pages to query. There are certainly better guides for newbies[4].
-- F.
[1] repository needs to be created on GitHub first
[2] personally, I don't like committing third-party resources like
jQuery to the repo, but have an initialization step instead:
http://github.com/FND/tiddlyrecon/blob/master/Makefile#L11
[3] http://fnd.lewcid.org/blog/archive/58
[4] cf. http://delicious.com/Ace_NoOne/git
Mat
> I like the Tiddly960 thing, I've also been getting interested in
> columnar grid layouts. I like the idea of grids that you can zoom
> into, and that reveal additional information when you do.
>
> I like zooming because it allows you to progressively reveal
> affordances for direct manipulation.
Regarding wysiwyg and ease of use (I believe this is a TW adaptation):
Luminotes
http://luminotes.com/notebooks/2ftcb2dxtixrorm6vejmnb30g
Regarding zooming and revealing additional information when doing so;
Prezi
http://prezi.com/
particularly check out the latter that centers around a very seamless
zoom in/out concept.
Jeremy Ruston
> Luminotes
> http://luminotes.com/notebooks/2ftcb2dxtixrorm6vejmnb30g
Ouch, I hadn't realised Luminotes were closing their service, that's a shame.
> Regarding zooming and revealing additional information when doing so;
> Prezi
> http://prezi.com/
Indeed, Prezi is nice. I'm less keen on the fact that it's based on
Flash. A couple of years ago I did this experiment to investigate
similar effects in HTML:
http://www.osmosoft.com/cecily/
(Only works on Firefox 3.5+, Safari 3+ and Chrome 1+)
Cheers
Jerm
> particularly check out the latter that centers around a very seamless
> zoom in/out concept.
>
> --
> 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.
>
>
--