Re: [twdev] Rethinking Popups
I've created an issue corresponding to this topic here: https://github.com/Jermolene/TiddlyWiki5/issues/3591 On Wednesday, November 28, 2018 at 8:14:03 AM UTC-6, Rob Hoelz wrote: > > Good idea, Jeremy! I was originally writing this up as a ticket on > GitHub, but I figured it'd get more exposure here. I'll open a ticket > straight away. > > -Rob > > On Wednesday, November 28, 2018 at 5:53:23 AM UTC-6, Jeremy Ruston wrote: >> >> Hi Rob >> >> Great, a proper overhaul of the popup mechanism is long overdue — the >> popup mechanism was one of the first, and most demanding, interactive >> mechanisms to be added to TW5 and I think we can now do a lot better. >> >> Perhaps the details may be best discussed on a new GitHub ticket, >> >> Best wishes >> >> Jeremy. >> >> >> >> >> >> On 28 Nov 2018, at 03:39, Rob Hoelz wrote: >> >> Hi everyone, >> >> I have been thinking for a while about the popup system after trying to >> fix a bug I reported, and I think the popup system could benefit from a >> little overhaul. I hope I'm not overreaching here - I would just really >> appreciate some feedback on these ideas! >> >> What circumstances are the popup system used in? >> >> To start, I looked through all references to "popup" in the TiddlyWiki >> codebase (not including non-official plugins). I found the plugin system >> is used for these four UI patterns: >> >> >>- Dropdowns (ex. search results, edit toolbar popups) - this is >>probably the most common >>- Menus (a special case of dropdown - ex. the export menu) >>- Accordion UI pattern (ex. *$:/Manager*, plugin info, tiddler info >>when you click "more > info" in the view toolbar) >>- Dialogs (ex. the confirmation prompt when you try to delete >>tiddlers matching a filter in *$:/AdvancedSearch*) >> >> So, bearing those four use cases in mind... >> >> What are the requirements of the popup system? >> >> We need popups to open when we activate the corresponding UI element >> >> This mostly corresponds to* <$edit-text> *and *<$button>* - but I don't >> see why we should limit ourselves to these. I like keeping the current >> shorthand - it makes the common case easy to do, plus it's backwards >> compatible. >> >> We need popups to close under certain conditions >> >> In my opinion, a popup should close under two conditions: >> >> >>- If I click on a UI element that completes the workflow that the >>popup was summoned to complete (applies to dropdowns, menus, and >> dialogs). >>For example: >> - Clicking on a tag in the tag dropdown >> - Clicking on a button in a "confirm" dialog popup >> - Clicking on a tiddler in the "create wikitext link" dropdown >>- If I click on or *otherwise grant focus* to an element outside of >>the popup >> - Dialogs are kind of the exception here - clicking outside of a >> dialog should probably not close it, but I don't think it's the end of >> the >> world if it does >> - Another exception is the "popup handle" - an input element >> that's bound to the popup. A prime example of this is the search >> query >> edit field - clicking in it shouldn't close the search results >> >> Clicking within a popup shouldn't close it, I think - which is contrary >> to the current default behavior. I think most people would expect a popup >> to stick around until they interact with it meaningfully, dimiss it with >> the button they summoned it with, or click outside of it. >> >> What would a new popup system look like? >> >> I rather like the idea of a new action widget - *<$action-popup>* - to >> be the common interface between wikitext and the popup mechanism. It can >> be the plumbing upon which the higher-level interfaces offered by >> *<$edit-text>* and *<$button>* are built. >> >> A widget can be bound to a popup (similar to how *focusPopup* works now) >> - clicking on a widget will not close its own popup (but *will* close >> others). >> >> The current popup system currently maintains state in JS; I would really >> like for the state to be maintained entirely in the tiddler store for >> consistency purposes. >> >> The current system supports nesting of popups - as far as I can tell, >> this is only really used for popups that
Re: [twdev] Rethinking Popups
Good idea, Jeremy! I was originally writing this up as a ticket on GitHub, but I figured it'd get more exposure here. I'll open a ticket straight away. -Rob On Wednesday, November 28, 2018 at 5:53:23 AM UTC-6, Jeremy Ruston wrote: > > Hi Rob > > Great, a proper overhaul of the popup mechanism is long overdue — the > popup mechanism was one of the first, and most demanding, interactive > mechanisms to be added to TW5 and I think we can now do a lot better. > > Perhaps the details may be best discussed on a new GitHub ticket, > > Best wishes > > Jeremy. > > > > > > On 28 Nov 2018, at 03:39, Rob Hoelz > > wrote: > > Hi everyone, > > I have been thinking for a while about the popup system after trying to > fix a bug I reported, and I think the popup system could benefit from a > little overhaul. I hope I'm not overreaching here - I would just really > appreciate some feedback on these ideas! > > What circumstances are the popup system used in? > > To start, I looked through all references to "popup" in the TiddlyWiki > codebase (not including non-official plugins). I found the plugin system > is used for these four UI patterns: > > >- Dropdowns (ex. search results, edit toolbar popups) - this is >probably the most common >- Menus (a special case of dropdown - ex. the export menu) >- Accordion UI pattern (ex. *$:/Manager*, plugin info, tiddler info >when you click "more > info" in the view toolbar) >- Dialogs (ex. the confirmation prompt when you try to delete tiddlers >matching a filter in *$:/AdvancedSearch*) > > So, bearing those four use cases in mind... > > What are the requirements of the popup system? > > We need popups to open when we activate the corresponding UI element > > This mostly corresponds to* <$edit-text> *and *<$button>* - but I don't > see why we should limit ourselves to these. I like keeping the current > shorthand - it makes the common case easy to do, plus it's backwards > compatible. > > We need popups to close under certain conditions > > In my opinion, a popup should close under two conditions: > > >- If I click on a UI element that completes the workflow that the >popup was summoned to complete (applies to dropdowns, menus, and dialogs). > >For example: > - Clicking on a tag in the tag dropdown > - Clicking on a button in a "confirm" dialog popup > - Clicking on a tiddler in the "create wikitext link" dropdown >- If I click on or *otherwise grant focus* to an element outside of >the popup > - Dialogs are kind of the exception here - clicking outside of a > dialog should probably not close it, but I don't think it's the end of > the > world if it does > - Another exception is the "popup handle" - an input element that's > bound to the popup. A prime example of this is the search query edit > field > - clicking in it shouldn't close the search results > > Clicking within a popup shouldn't close it, I think - which is contrary to > the current default behavior. I think most people would expect a popup to > stick around until they interact with it meaningfully, dimiss it with the > button they summoned it with, or click outside of it. > > What would a new popup system look like? > > I rather like the idea of a new action widget - *<$action-popup>* - to be > the common interface between wikitext and the popup mechanism. It can be > the plumbing upon which the higher-level interfaces offered by > *<$edit-text>* and *<$button>* are built. > > A widget can be bound to a popup (similar to how *focusPopup* works now) > - clicking on a widget will not close its own popup (but *will* close > others). > > The current popup system currently maintains state in JS; I would really > like for the state to be maintained entirely in the tiddler store for > consistency purposes. > > The current system supports nesting of popups - as far as I can tell, this > is only really used for popups that behave like menus, so maybe the right > thing to do is to break out a distinct "menu" widget. Doing so might > simplify state management quite a bit! It might also make sense to break > out a distinct "dialog" widget. > > I'm tempted to tie certain bits of extra state to a popup - eg. the search > text for "create wikitext link", so that it gets cleared as well when a > popup is closed, but maybe that's trying to do too much. > > Thinking Ahead > > (I have no idea why it just decided to go double-space) There are some
[twdev] Rethinking Popups
Hi everyone, I have been thinking for a while about the popup system after trying to fix a bug I reported, and I think the popup system could benefit from a little overhaul. I hope I'm not overreaching here - I would just really appreciate some feedback on these ideas! What circumstances are the popup system used in? To start, I looked through all references to "popup" in the TiddlyWiki codebase (not including non-official plugins). I found the plugin system is used for these four UI patterns: - Dropdowns (ex. search results, edit toolbar popups) - this is probably the most common - Menus (a special case of dropdown - ex. the export menu) - Accordion UI pattern (ex. *$:/Manager*, plugin info, tiddler info when you click "more > info" in the view toolbar) - Dialogs (ex. the confirmation prompt when you try to delete tiddlers matching a filter in *$:/AdvancedSearch*) So, bearing those four use cases in mind... What are the requirements of the popup system? We need popups to open when we activate the corresponding UI element This mostly corresponds to* <$edit-text> *and *<$button>* - but I don't see why we should limit ourselves to these. I like keeping the current shorthand - it makes the common case easy to do, plus it's backwards compatible. We need popups to close under certain conditions In my opinion, a popup should close under two conditions: - If I click on a UI element that completes the workflow that the popup was summoned to complete (applies to dropdowns, menus, and dialogs). For example: - Clicking on a tag in the tag dropdown - Clicking on a button in a "confirm" dialog popup - Clicking on a tiddler in the "create wikitext link" dropdown - If I click on or *otherwise grant focus* to an element outside of the popup - Dialogs are kind of the exception here - clicking outside of a dialog should probably not close it, but I don't think it's the end of the world if it does - Another exception is the "popup handle" - an input element that's bound to the popup. A prime example of this is the search query edit field - clicking in it shouldn't close the search results Clicking within a popup shouldn't close it, I think - which is contrary to the current default behavior. I think most people would expect a popup to stick around until they interact with it meaningfully, dimiss it with the button they summoned it with, or click outside of it. What would a new popup system look like? I rather like the idea of a new action widget - *<$action-popup>* - to be the common interface between wikitext and the popup mechanism. It can be the plumbing upon which the higher-level interfaces offered by *<$edit-text>* and *<$button>* are built. A widget can be bound to a popup (similar to how *focusPopup* works now) - clicking on a widget will not close its own popup (but *will* close others). The current popup system currently maintains state in JS; I would really like for the state to be maintained entirely in the tiddler store for consistency purposes. The current system supports nesting of popups - as far as I can tell, this is only really used for popups that behave like menus, so maybe the right thing to do is to break out a distinct "menu" widget. Doing so might simplify state management quite a bit! It might also make sense to break out a distinct "dialog" widget. I'm tempted to tie certain bits of extra state to a popup - eg. the search text for "create wikitext link", so that it gets cleared as well when a popup is closed, but maybe that's trying to do too much. Thinking Ahead (I have no idea why it just decided to go double-space) There are some other things that users might want popups to do someday; for example, Tobias' appear plugin augments the popup system with some additional behavior, and users might want features like tearoff menus in the future. We can't predict *everything* everyone might want, but it might be a good time to incorporate augmentations like Tobias' and identify other possible uses for the popup system. Thanks for reading! Please let me know if you have any suggestions, or if you find flaws in my ideas! I'd be happy to undertake this work, as long as it's a solution everyone's happy with. -Rob -- 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 tiddlywikidev+unsubscr...@googlegroups.com. To post to this group, send email to tiddlywikidev@googlegroups.com. Visit this group at https://groups.google.com/group/tiddlywikidev. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/6c257911-599d-4d04-b51d-172a14075737%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [twdev] Re: Request for help with new filter operator and new tutorial
Hi everyone!
Diego was kind enough to bring this discussion to my attention - I plan on
fixing up that issue he ran into.
Jeremy - if you decide to go with lunr.js but not use my plugin, please
feel free to reach out if you have questions about lunr.js! One pitfall I
ran into while upgrading from lunr 1.x to 2.x is that lunr's index is
immutable by default in 2.x - I ended up writing a plugin to add mutable
indexes. Of course, any collaboration on my plugin (along with advice on
how to improve it) would be most welcome!
-Rob
On Thursday, June 28, 2018 at 9:14:27 AM UTC-5, Diego Mesa wrote:
>
> Hey Jeremy,
>
> Just wanted to let you know of this plugin:
>
> https://github.com/hoelzro/tw-full-text-search
>
> which incorporates lunr.js into TW for full text searching. I just tried
> today and am somewhat able to do fuzzy searching with it (does not deal
> with immediatel searching properly yet). I have let him know about this
> discussion and the corresponding feature request on github, and have opened
> an issue on his repo for the fuzzy matching:
>
> https://github.com/hoelzro/tw-full-text-search/issues/4
>
> Perhaps you can reuse some of hoelzro's work?
>
> Best,
> Diego
>
> On Wednesday, June 27, 2018 at 8:47:06 AM UTC-5, Diego Mesa wrote:
>>
>> Hey Jeremy,
>>
>> Thanks for your feedback - I agree search needs to performant. Im glad
>> you're also looking at these issues!
>>
>> A priority for me is the inclusion of *fuzzy* searching - a quick look
>> seems lunr does support it:
>>
>> https://lunrjs.com/guides/searching.html#fuzzy-matches
>>
>> but elastic does not.
>>
>> Best,
>> Diego
>>
>> On Wednesday, June 27, 2018 at 2:28:18 AM UTC-5, Jeremy Ruston wrote:
>>>
>>> Hi Diego
>>>
>>> Filter operators are often re-executed and so it's important that they
>>> perform well. For an expensive operation like a search we need to try to
>>> cache as much of the work as we can.
>>>
>>> An approach that should work is to introduce a new startup module that
>>> tracks changes to the store in order to keep the index up to date, and then
>>> have the filter operator call a version of the search function that caches
>>> the results (and clears the cache when it is invalidated by changes to the
>>> tiddler store).
>>>
>>> Having said that, one of the client projects I'm working on for
>>> Federatial looks like it's going to need an enhanced search capability. If
>>> the project proceeds to the next phase then I'll be looking at adding a
>>> third party search index library -- I've been looking at
>>> https://lunrjs.com/ and http://elasticlunr.com/. The API that they
>>> feature allows the index to be dynamically modified by adding and removing
>>> data incrementally; fuse.js looks like it only accepts a monolithic block
>>> of data, and would require a re-index each time the tiddler store changes.
>>>
>>> Best wishes
>>>
>>> Jeremy
>>>
>>> --
>>> Jeremy Ruston
>>> jer...@jermolene.com
>>> https://jermolene.com
>>>
>>> On 26 Jun 2018, at 20:45, Diego Mesa wrote:
>>>
>>> Hey all,
>>>
>>> Thanks Jeremy for sending that. The following is *more pseduo-code than
>>> anything*, but reflects my quick hacking:
>>>
>>> (function(){
>>>
>>>
>>> /*jslint node: true, browser: true */
>>> /*global $tw: false */
>>> "use strict";
>>>
>>>
>>> var fuze = require("$:/plugins/fuzzy/fuze.js");
>>>
>>>
>>> var options = {
>>> shouldSort: true,
>>> matchAllTokens: true,
>>> threshold: 0.6,
>>> location: 0,
>>> distance: 100,
>>> maxPatternLength: 32,
>>> minMatchCharLength: 1,
>>> keys: undefined
>>> };
>>>
>>>
>>> /*
>>> Export our filter function
>>> */
>>> exports.fuzzysearch = function(source,operator,options) {
>>> var results = [];
>>>
>>>
>>> source = options.source || $tw.wiki.each;
>>>
>>>
>>> var searchTiddler = function(title){
>>> jsonData = $tw.wiki.getTiddlerAsJson(title)
>>> var fuse = new Fuse(jsonData, options); // "list" is the item
>>> array
>>> var result = fuse.search(operator.operand);
>>> return result;
>>>};
>>> source(function(tiddler,title) {
>>> if(searchTiddler(title) !== options.invert) {
>>> results.push(title);
>>> }
>>> });
>>>
>>>
>>> console.log("e");
>>> return results;
>>> };
>>>
>>>
>>> })();
>>>
>>> I quickly generated this just by looking at:
>>>
>>> $:/core/modules/filters/search.js
>>>
>>> which is just a wrapper around:
>>>
>>> $:/core/modules/wiki.js
>>>
>>> where exports.search = is defined.
>>>
>>> The issue is that as you can see from
>>>
>>> http://fusejs.io/
>>>
>>> Fuze works better if it would have access to the entire json string of
>>> the wiki, and it can handle the searching and scoring itself.
>>>
>>> What do you guys think? Any tips to help me move forward?
>>>
>>> Best,
>>> Diego
>>>
>>> On Tuesday, June 26, 2018 at 8:38:36 AM UTC-5, Jed Carty wrote:
I hadn't realised it could be done that way. That makes including
