On Monday, July 14, 2014 2:40:06 PM UTC-4, Jeremy Ruston wrote:
>
> Hi Stephan
>
> I do remember seeing that in the roadmap but, given that I can't wait,
>> that doesn't help here. (Back when I planned to do this a couple of weeks
>> ago, today was the "ready for use by" date I set as a goal and I have a
>> writing buddy who's still waiting for the first time I'll be the one doing
>> the writing and he the editing rather than the other way around.)
>>
>> Unfortunately, I've just tested TagList on bjhacks.tiddlyspot.com and
>> the drag-and-drop behaviour is too finicky and has no visual
>> drag-in-progress indication. (I still don't know why drag-and-drop
>> sometimes works and sometimes opens the tiddler instead... seemingly at
>> random.)
>>
>
>> I'll have to either patch it or write my own.
>>
>
> Best of all, you could work on the feature for the TW5 core....
>
I'd be willing... but almost all of what I've learned about TW5's core so
far is either confined to the tiddler store or related to writing plugins
so I'm not even sure where to begin.
(Possibly by trying to find an API documentation generator which like's the
current form TW5's method comments take so I can have that method index I
want.)
>
>
>> Does TW5's plugin format have a TWc-like license field I can check
>> without looking at the source and risking my freedom to write clean-room
>> clones if the license isn't both CC-BY-SA compatible and GPL-compatible?
>>
>
> Just to check, you'd like to be able to check the license of a plugin
> without inspecting the source? That makes sense. There's no license field
> on plugins at the moment, but I would be happy to add support for one.
>
That's correct.
>
> All the plugins that are part of the tiddlywiki repo are covered by
> TiddlyWiki's BSD license. Does the BSD license meet your needs?
>
That's perfectly fine.
>
>
>> (That's why you've never seen me contribute anything to TiddlyTools
>> plugins or write any of the TWc ideas that'd be trivial to write by
>> combining and adjusting existing bits. With TWc being more or less
>> invisible to Google and the main source of functionality being CC-BY-SA
>> only, I had no impetus.)
>>
>
> Just to be clear, the issue here is the licensing of TiddlyTools, not
> TWClassic itself?
>
Yeah.
The only problem I've ever had with TWClassic was that, without TiddlyTools
plugins, it felt crippled and, since everyone's docs and plugins were in
Google-resistant TWClassic instances, finding docs and examples needed to
reinvent TiddlyTools stuff under a more GPL-compatible license was
prohibitively difficult.
(Sort of similar to the "Open Core" licensing schemes various vendors try
because they want to have their cake and eat it too.)
>
>>
>> 1. I'm still interested in implementing this as a custom StoryView
>> but I'm not sure how to reconcile the "two story rivers" part with the
>> API
>> exposed at that level of the stack so it's conditional on the timeline
>> view
>> being active. (I've been specifically tuning my vision for the data model
>> with the intent that it still make sense when viewed as a normal
>> TiddlyWiki
>> and I'm envisioning the two-river timeline view as analogous to things
>> like
>> cecily.)
>> 2. I still have to dig into the navigation mechanism enough to figure
>> out how to redefine clicking a link as "If it's present in the timeline
>> river, hide the normal river and scroll to it. Otherwise, show the normal
>> river, insert the tiddler if necessary, and scroll to it."
>>
>>
> Basically, you'll need a new widget that's something like the navigator
> widget, processing tw-navigate messages more selectively.
>
That makes sense. However, I'm still a little unsure about the proper way
to switch the "two story rivers" part on and off based on which StoryView
is selected.
("I only know how to do X in Javascript, but the proper/only way to do Y is
in WikiMarkup. What's the proper way to make X control Y?" seems to be the
pattern many of my questions boil down to.)
> Having said that, there are features like the suppression of $:/temp/
>>>> tiddlers when saving, which relies on specialised treatment of a certain
>>>> prefix.
>>>>
>>>
>>>
>>
>> That's the main thing I was wondering. Which prefixes have which special
>> behaviours. (That's actually part of what kept me from making the mockup's
>> internal representation even more TW5-like while I was iterating.)
>>
>
> I think the only cases are the prefix check for $:/state/popup tiddlers
> used in the save filters such as:
>
>
> https://github.com/Jermolene/TiddlyWiki5/blob/master/core%2Ftemplates%2Fsave-all.tid
>
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FJermolene%2FTiddlyWiki5%2Fblob%2Fmaster%2Fcore%252Ftemplates%252Fsave-all.tid&sa=D&sntz=1&usg=AFQjCNGCRkfeH8yQvpc5n5drPqrCurVAXQ>
>
>
Since it already says that $:/temp tiddlers shouldn't be saved, that
doesn't sound right. Now that I know what I'm looking for, here's what ack
(ack-grep in Debian packages) turned up once I added .tid to the extension
whitelist.
> % ack --ignore-dir=test --ignore-dir=tw2 '\[prefix\[\$:/' ../../..
> ../../../editions/tw5.com/tiddlers/filters/FilterOperator prefix.tid
> 13:|`[prefix[$:/]]` |Equivalent to `[is[system]]` |
../../../core/wiki/config/SyncFilter.tid
> 3:[is[tiddler]] -[[$:/HistoryList]] -[[$:/StoryList]] -[[$:/isEncrypted]] -
> [prefix[$:/status]] -[prefix[$:/state]] -[prefix[$:/temp]]
../../../core/templates/save-lazy-images.tid
> 4:[is[tiddler]] -[prefix[$:/state/popup/]] -[[$:/HistoryList]]
> -[[$:/boot/boot.css]] -[type[application/javascript]library[yes]]
> -[[$:/boot/boot.js]] -[[$:/boot/bootprefix.js]] -[!is[system]is[image]]
> +[sort[title]]
../../../core/templates/save-empty.tid
> 4:[is[system]] -[prefix[$:/state/popup/]] -[[$:/boot/boot.css]]
> -[type[application/javascript]library[yes]] -[[$:/boot/boot.js]]
> -[[$:/boot/bootprefix.js]] +[sort[title]]
../../../core/templates/save-all.tid
> 4:[is[tiddler]] -[prefix[$:/state/popup/]] -[[$:/HistoryList]]
> -[[$:/boot/boot.css]] -[type[application/javascript]library[yes]]
> -[[$:/boot/boot.js]] -[[$:/boot/bootprefix.js]] +[sort[title]]
Judging by that, I'm guessing the rule is "Don't save $:/status, $:/state,
or $:/temp" and is defined by core/wiki/config/SyncFilter.tid
On a related note, since I don't mind improving the documentation whenever
>> I run into a question like this, when I'm working on a draft and don't
>> fully understand the subject matter, how much of the Q&A would you prefer
>> be done where while I'm bringing a draft up to spec?
>>
>
> Any amount of Q&A is great, and very useful for me too. Obviously best for
> it to be public so that other people can benefit.
>
I always prefer transparency. What I'm wondering is where you draw the line
between "discuss it on the mailing list" and "discuss it on the issue
tracker".
(For example, at the extreme "issue tracker" end, would you have any
problem if your first hint that I was proposing a change was a pull request
for an early draft that may have inaccuracies and then we refined the draft
in the pull request via discussion and added commits until you felt it was
ready to merge or would you prefer discussion take place here until I reach
a certain level of understanding and the draft reaches a certain level of
polish?)
>
>
>> 5. What would be the least face-meltingly horrible way to monkey-patch
>>>> the search field so that Ctrl+Enter treats the contents as a literal
>>>> tiddler name and opens it directly?
>>>>
>>>
>>> I don't think that that can be done right now without some core changes.
>>> We'd want something like this:
>>>
>>> <$keyboard key="ctrl-enter" message="tw-navigate"
>>> param={{!!$:/temp/search}}>
>>> <$edit-text tiddler="$:/temp/search" tag="input"/>
>>> </$keyboard>
>>>
>>> But the trouble is that the tw-navigate event currently uses a
>>> non-standard parameter name for the tiddler title, and this cannot be set
>>> by the keyboard widget.
>>>
>>
>> Hmm. Should I open a feature request for that on the issue tracker?
>>
>
> Fixing it well is likely to be a big job; I think we need to bring in far
> more flexibility to the representation of sequential actions to be
> performed on a button click, message etc. But there's a quick fix by
> modifying this line:
>
>
> https://github.com/Jermolene/TiddlyWiki5/blob/master/core%2Fmodules%2Fwidgets%2Fnavigator.js#L143
>
> To:
>
> this.addToStory(event.navigateTo || event.param,event.navigateFromTitle);
>
>
The main thrust of my question was "what (if anything) do I need to do in
order to make sure the goal of solving this properly doesn't slip through
the cracks" but thanks for the workaround.
> Best wishes
>
> Jeremy
>
>
>
>
>
> --
> Jeremy Ruston
> mailto:[email protected] <javascript:>
>
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/tiddlywikidev.
For more options, visit https://groups.google.com/d/optout.
