Thanks. I'll look into it once I've got the more "essential for prototyping" bits like the timeline itself converted over to TiddlyWiki. Are you using the same license as TiddlyWiki core?
As for the desired behaviour, I'll want to aim for something similar to what RearrangeTiddlersPlugin does in TWClassic. My current draft concept is to have it implemented for story rivers via a little grab handle to the left of the title based off appearance of the Vertical Ellipsis <http://www.fileformat.info/info/unicode/char/22EE/index.htm> (⋮) character and using "cursor: move" but I'll need to do more research on what people already expect drag handles to look like in native UIs. On Monday, July 14, 2014 4:07:42 PM UTC-4, BJ wrote: > > Hi Stephan, > the taglist widget has drop handlers on the list elements, dragging an > element and dropping it on to another list element cause the dragged item > to be inserted before the item it was dropped on. If an element is dropped > anywhere outside of the list it will not be 'caught' by the taglist widget, > and is caught by the default drophandler which causes the tiddler to be > opened. > The functionality is the bare minimum for the application that I wrote it > for - you could definitely improve upon it :-) .The visual dragging > behaviour is the default from the link widget. It would be nice if an item > could be dropped at the end of the list (append after the last item). > > best of luck with your project > > BJ > > On Monday, July 14, 2014 8:02:27 PM UTC+2, [email protected] wrote >> >> >> >> On Monday, July 14, 2014 12:22:54 PM UTC-4, Jeremy Ruston wrote: >>> >>> Hi Stephan >>> >>> Hi, I've been working on this mockup >>>> <https://dl.dropboxusercontent.com/u/14610481/mockup/index.html> (also >>>> attached for posterity) and, now that I've properly realized how >>>> high-level >>>> TW5's APIs actually are, I'd like to convert it to a set of >>>> mutually-cooperative TiddlyWiki plugins before I go any further. (so I've >>>> also attached my TODO.md in case anyone wants more context for what I >>>> intend to to) >>>> >>> >>> It looks like you are trying to write a jQuery+Handlebars application >>> that behaves like a TiddlyWiki but isn't actually based on TiddlyWiki code, >>> is that right? I can see the comment in tw5_mock.js about needing to work >>> around the lack of documentation, but am a bit confused about the approach >>> you are taking. >>> >>> In terms of the technical documentation, have you read this: >>> >>> http://tiddlywiki.com/#TiddlyWiki%20for%20Developers >>> >>> It may not explain everything, but hopefully sets your expectations for >>> how radically the TiddlyWiki architecture departs from expectations set by >>> jQuery. It's much more like Angular. The big change is that TiddlyWiki (and >>> Angular) eschew storing state data in the DOM. >>> >> >> The mockup began >> <https://dl.dropboxusercontent.com/u/14610481/story_planner_mockup.html> >> as a jQuery-based thing with no TiddlyWiki plans, no data model whatsoever, >> and no templating. (Again, attached for posterity) >> >> I only realized it was a good fit for TiddlyWiki after I started to >> experiment and had done several iterations of the design. At that point, I >> started incorporating elements of the default TW5 theme and moving the >> innards into increasingly TiddlyWiki-like configurations as I wrapped my >> mind around TW5's design. >> >> >>> >>>> 2. As you might have guessed from the mockup, tiddler ordering is >>>> almost as important to preserve as tiddler contents in this UI. What's the >>>> most proper way to store an ordered list of tiddlers where a ListWidget >>>> can >>>> access them and a drag-and-drop reordering plugin can easily hook in to >>>> persist state? (I've been trying to mock up tiddler store APIs as closely >>>> as possible but, at the moment, it's just relying on the ordering >>>> guarantee >>>> of the Array() underlying the mock implementation.) >>>> >>> >>> TW5 has a mechanism for ordering the tiddlers with a particular tag (see >>> "tag ordering" on http://tiddlywiki.com/#TiddlerTags). >>> >>> >> Thanks. That's exactly what I needed to know. >> >> >>> The plan is to extend the list widget to allow entries to be dragged and >>> dropped, but it's not implemented in the core yet. BJ has a plugin >>> implementation, though: >>> >>> http://bjhacks.tiddlyspot.com/#TagList >>> <http://www.google.com/url?q=http%3A%2F%2Fbjhacks.tiddlyspot.com%2F%23TagList&sa=D&sntz=1&usg=AFQjCNGLBm9SeR0pNasQic_iU1pYgXb1MQ> >>> >>> >> 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. 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? >> >> (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.) >> >>> >>> The story river is just the list widget: >>> >>> >>> https://github.com/Jermolene/TiddlyWiki5/blob/master/core%2Fui%2FPageTemplate%2Fstory.tid#L16 >>> >>> You can easily have as many story rivers as you like - the easiest way >>> is another tiddler tagged $:/tags/PageTemplate. >>> >> >> That should probably be all I need for the display part. (I did figure >> the "just a list widget" part out, a reveal widget will probably be good >> enough for v1.0 hide/show, and I should be able to specify the template via >> a macro so that both "Chapter X: Title..." breaks and scene cards can be >> tiddlers in the same list. (And, worst case, I could prototype the timeline >> within another tiddler in the main story river.) >> >> My main remaining concerns are: >> >> 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." >> >> >>>> 4. Could someone explain the under-the-hood differences between the >>>> different namespaces in "Naming of System Tiddlers"? >>>> >>> >>> That tiddler is describing the conventions that were used to devise the >>> various system tiddler names. Those conventions are not enforced in any way. >>> >>> 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.) >> >> 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? >> >> >>> 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? >> > -- 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.
