Hi Evan > > 1. The user's direct interaction initiates all changes to the state of > the tiddler store -- or at least the vast majority of changes. > 2. The user's interaction with editor widgets can change the state of *at > most* one tiddler at a time. (I understand this does not apply to > triggering widgets!) > > That's not quite right. Firstly, some user actions might trigger an asynchronous change to the store - for example, triggering the loading of a lazily loaded tiddler. Second, changes made by other users in multi-user scenarios are planned to automatically ripple to other connected browsers. Third, imagine a clock plugin that just sets $:/currentTime every 1s to the current time. That would make it easy to display an automatically updating clock or timer in any required format, and would lead to asynchronous changes to the tiddler store.
You make a strong case that editor widgets should not have state > independent of the store, to avoid conflicts in or loss of data. This > makes sense to me. I also agree that delay is a feature of the interface / > UX design, and it is my view that the degree of delay should be a function > of the *means* by which the information is changed, rather than *what* > information is changed -- hence the proposal that it be a feature of the > instigating widgets. > I understand the motivation, but as I mentioned above I think it's hard for such a system to offer any solid guarantees as to how the specified delay will be treated. > The question then becomes how the editor widgets can communicate to the > renderer that the changes they have instigated should be delayed. There > needs to be a means of associating the changes (which the renderer receives > as event notifications from the store) with the specific source and delay > value. If assumption 2 is correct, only a single delay value need be set > per change. > The problem here is how one coalesces adjacent updates. But I maintain that the fundamental mistake to couple the operation of the tiddler store to the user interface concerns of how we handle refreshing. Remember that the refresh cycle is not intrinsic to the tiddler store; it's built on top of the mechanisms that it provides. Best wishes Jeremy. What would it do if the same tiddler were written twice with different >> delays specified? > > > I don't have a strong understanding of the situations where this might > occur, other than a keypress followed by another keypress (which should > reset the delay). > > > On Wednesday, 23 September 2015 16:01:46 UTC-5, Jeremy Ruston wrote: >> >> Hi Evan >> >> On Wed, Sep 23, 2015 at 8:21 PM, Evan Balster <balste...@gmail.com> >> wrote: >> >>> The other day I picked through the code to ascertain what would be >>> necessary to implement a refresh delay setting in $edit-text and friends. >>> >> >> Great stuff, there's a lot to navigate there. >> >>> >>> - State Modifying Widgets >>> - Add a new "delay" property, and possibly means to fall back to >>> default values >>> - Store this property in the AddTiddler hashmap >>> - AddTiddler microkernel function >>> - Extract the delay property from the hashmap argument >>> - Pass the property to enqueueTiddlerEvent >>> - enqueueTiddlerEvent wiki.js function >>> - Accept the delay property as a third argument >>> >>> What would it do if the same tiddler were written twice with different >> delays specified? >> >>> >>> - Add this property to the data for the change event >>> - - "change" event handler >>> - Extract the delay property from the event argument and schedule >>> delay >>> >>> I think this proposal essentially duplicates an existing mechanism, but >> is not as well encapsulated. Here you have logic in the render.js change >> handler, and in the wiki store. The apparent benefit is that the caller >> gets to control the delay, but at a great cost: the change event handler >> must keep track of a whole bunch of delays, rather than just one. The >> caller doesn't in fact have control over the delay because of competition >> with other code writing to the same tiddler (including the core). >> >> It feels much neater to make the delay be a concern of the main render >> module. The need for these delays is a user interface concern, and >> shouldn't be a part of the store. >> >> (Just to be clear that none of this negates the need to extend the >> existing mechanism so that we can defer refresh for tiddlers other than the >> usual draft tiddlers). >> >> >>> One nice thing about this approach is that it would no longer be >>> necessary to check for draft tiddlers in the change event handler -- >>> instead, the editor widgets in the EditTemplate would simply assign a delay >>> value. >>> >> >> Surely lots of different delay values? >> >> >>> Probably the most obtrusive element of this solution is that the >>> parameter of the change event would need to be redefined as a hashmap... >>> It looks as if there is a lot of code that handles that event, and I don't >>> know enough about TiddlyWiki to identify other possible datapaths for the >>> delay variable. >>> >> >> Since the end of the beta the interfaces within TiddlyWiki have been >> constrained to backwards compatibility. It's actually not that much of a >> constraint, one can usually fix things by adding rather than changing or >> taking away. >> >> >>> If multiple change events are aggregated, it would be sensible to use >>> the *lowest* delay value associated with any of them for scheduling >>> purposes. >>> >> >> This again means that the caller has even less control than indicated by >> the interface. There are two places where the specified delays are >> aggregated. >> >> >>> >>> ...Anyway, at this point I'm feeling as if I could try my hand at this >>> modification -- but I might end up out of my depth as I'm not a JavaScript >>> expert. Jeremy, let me know if this scheme sounds remotely sensible. >>> >> >> I welcome contributions but would urge you to consider having a go at >> something less speculative and therefore controversial. I think there are a >> lot of popular issues on GitHub that are amenable to a fix by anyone with >> the time, and of course I'll always be happy to advise when I can. >> >> Best wishes >> >> Jeremy. >> >> >>> >>> >>> On Wednesday, 23 September 2015 12:23:56 UTC-5, Jeremy Ruston wrote: >>>> >>>> Hi Evan >>>> >>>> > So the source of objection to this feature is that the data might be >>>> erased if the containing widget tree is refreshed within that small >>>> interval of time? I would consider that acceptable... >>>> >>>> I don't think random, hard to find data loss is at all acceptable. The >>>> basic design of TiddlyWiki has to be robust, I think. >>>> >>>> Anyhow, #1494 rather endlessly repeats the reasons why the originally >>>> proposed solution doesn't work within the context of TiddlyWiki's design. >>>> >>>> The best solution to the problem is to extend the existing refresh >>>> dampening mechanism as you propose. Using a field like "refresh.slow" as >>>> you suggest is nice and quick, but may be a bit restrictive. One >>>> alternative would be to consult $:/config/refreshdelay/<tiddlertitle>, but >>>> of course that would be rather expensive, adding a store lookup for every >>>> changed tiddler. >>>> >>>> Best wishes >>>> >>>> Jeremy. >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Sep 23, 2015 at 10:52 AM, PMario <pmar...@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On Tuesday, September 22, 2015 at 9:09:31 PM UTC+2, Evan Balster wrote: >>>>>> >>>>>> However, based on a quick look at the code, I can speculate about two >>>>>> ways of implementing this change that do not involve storing editor state >>>>>> in the widget tree: >>>>>> >>>>>> 1. Have a field other than "draft.of" which marks a tiddler as a >>>>>> "draft" for the purposes of refresh time. >>>>>> 2. Modify the "change" event listener receive an optional >>>>>> parameter for the timeout associated with any given change, allowing >>>>>> any >>>>>> source of changes to define its own timeout value. >>>>>> >>>>>> #1 could be implemented quickly by changing this line >>>>>> <https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/render.js#L75> >>>>>> of the render code to something like: >>>>>> >>>>>> if(!tiddler || !tiddler.hasField("draft.of") >>>>>> || !tiddler.hasField("refresh.slow")) { >>>>>> >>>>>> >>>>> What if you just add a field "draft.of" to your temporary input >>>>> tiddler. There would be no need to change the core and it's easy for you >>>>> to >>>>> add the field to your code. >>>>> >>>>> -m >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "TiddlyWiki" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to tiddlywiki+...@googlegroups.com. >>>>> To post to this group, send email to tiddl...@googlegroups.com. >>>>> Visit this group at http://groups.google.com/group/tiddlywiki. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/tiddlywiki/d1e6e6e0-7b4e-4b15-aa3e-8a49afb83a06%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/tiddlywiki/d1e6e6e0-7b4e-4b15-aa3e-8a49afb83a06%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> Jeremy Ruston >>>> mailto:jeremy...@gmail.com >>>> >>> >> >> >> -- >> Jeremy Ruston >> mailto:jeremy...@gmail.com >> > -- Jeremy Ruston mailto:jeremy.rus...@gmail.com -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscr...@googlegroups.com. To post to this group, send email to tiddlywiki@googlegroups.com. Visit this group at http://groups.google.com/group/tiddlywiki. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAPKKYJZBQ87fWKE9U3ck-c4wymRZqXM--BYGeorD9HpW%3DC7Fjg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
