[UI] add selectable tags- and search-dropdown #3565

BurningTreeC · 2018-11-21T10:13:52Z

this adds a saveTiddler attribute to factory.js

if it's present it's used as a tiddler title where all the inputs/changes made by the user get stored
this can be used for selecting dropdown-entries that are filterable by an input field
the entries should be sorted by the saveTiddler and the original tiddler (<$edit-text tiddler="originaltiddler" .../>) can be updated with the selected dropdown-entry which will be shown within the input, without changing the filtering of the dropdown-items

Update: to the above mentioned changes, this adds:

a refreshTiddler attribute to factory.js (refreshes the input-text when that tiddler changes, sets it to whatever is within the editTiddler)
a full-featured keyboard-selectable tags-dropdown
up/down selects a dropdown tag
enter adds the selected tag
escape clears the input field, or - if empty - cancels editing the tiddler

this adds a `saveTiddler` attribute to factory.js if it's present it's used as a tiddler title where all the inputs/changes made by the user get stored this can be used for selecting dropdown-entries that are filterable by an input field the entries should be sorted by the `saveTiddler` and the original tiddler (`<$edit-text tiddler="originaltiddler" .../>`) can be updated with the selected dropdown-entry which will be shown within the input, without changing the filtering of the dropdown-items

Jermolene · 2018-11-21T11:23:46Z

Hi @BurningTreeC this is intriguing, but I'm not sure I fully understand. Can you post a more complete example?

BurningTreeC · 2018-11-21T15:48:37Z

@Jermolene - I've updated the first comment with the additions made

BurningTreeC · 2018-11-21T20:17:11Z

we could refactor the logic for dropdown-selection into a macro, so that we can reuse it for the search-dropdown, fieldname-dropdown etc

pmario · 2018-11-22T14:14:49Z

do you have a minimal-test-case?

BurningTreeC · 2018-11-22T17:04:08Z

@pmario - this is a current prerelease with my additions from this PR:

http://selectabledropdowninput.tiddlyspot.com

keep the top 3 state tiddlers open
try the tags Input of HelloThere
the first state is the real text value of the tags input
the second state is the user input by which the dropdown is filtered
the third state is the state used to refresh the input field (its text is updated and focus is set)
in the tags input try:
-- up arrow / down arrow to select a tag from the dropdown
-- write something to filter the dropdown
-- up / down again, to see that the input updates with the selected tag but the dropdown filtering remains the same
-- press Enter to add a tag (dropdown filtering remains the same), one can add more tags by same filter
-- press Escape to reset the input field (all tags will be shown again, input gets cleared)
-- on Escape: if all tags are shown and input field is clear, it cancels editing
-- that's all

pmario · 2018-11-22T17:12:42Z

Great stuff! .... As you wrote, it would be cool to have it for the search input. Users would love this!

BurningTreeC · 2018-11-22T17:19:23Z

thanks @pmario , for the tags and search dropdowns, we have to take into account that we can add tabs within the dropdowns with different filterings

the select-logic by up/down needs the filters that are used within the current open dropdown tab

I think therefor we should put the filters (the tags and search dropdowns have two different filters for non-system and system) for the dropdown lists into a field somewhere. Then I can make the macro look up for the filters in those fields

refactored the dropdown-selector logic into a `selectable-dropdown-input` macro

lets us define the state for a tabs-list explicitely, useful for selectable-dropdown-inputs, knowing the state tiddler from outside

BurningTreeC · 2019-01-03T13:26:55Z

core/wiki/macros/tabs.tid

-\define tabs(tabsList,default,state:"$:/state/tab",class,template,buttonTemplate,retain)
+\define tabs(tabsList,default,state:"$:/state/tab",class,template,buttonTemplate,retain,explicitState)
+<$set name="qualifiedState" value=<<qualify "$state$">>>
+<$set name="tabsState" filter="[<__explicitState__>minlength[1]] ~[<qualifiedState>]">


this is a workaround so that I know the state tiddler
the tabs macro simply uses a title without qualifying when explicitState is present

but a way to access a qualified state from outside the scope would be more elegant

BurningTreeC · 2019-01-03T13:28:44Z

core/wiki/macros/input.tid

+<$keyboard key="((input-down))" actions="""<$macrocall $name="select-dropdown-actions" beforeafter="after" reverse="" editTiddler=<<__editTiddler__>> saveTiddler=<<__saveTiddler__>> refreshTiddler=<<__refreshTiddler__>> filter1={{{ [<__filterTiddler__>get[dropdown-filter-1]] }}} filter2={{{ [<__filterTiddler__>get[dropdown-filter-2]] }}} filterMinLength="$filterMinLength$"/>""">
+<$keyboard key="((input-up))" actions="""<$macrocall $name="select-dropdown-actions" beforeafter="before" reverse="reverse[]" editTiddler=<<__editTiddler__>> saveTiddler=<<__saveTiddler__>> refreshTiddler=<<__refreshTiddler__>> filter1={{{ [<__filterTiddler__>get[dropdown-filter-1]] }}} filter2={{{ [<__filterTiddler__>get[dropdown-filter-2]] }}} filterMinLength="$filterMinLength$"/>""">
+<$keyboard key="((input-accept))" actions="""<$macrocall $name="accept-input-actions" editTiddler=<<__editTiddler__>> acceptActions={{{ [<__filterTiddler__>get[accept-actions]] }}}/>""">
+<$keyboard key="((input-clear))" actions="""<$macrocall $name="clear-input-actions" editTiddler=<<__editTiddler__>> saveTiddler=<<__saveTiddler__>> refreshTiddler=<<__refreshTiddler__>> clearEmptyActions={{{ [<__filterTiddler__>get[clear-input-empty-actions]] }}} refreshQualifier=<<__refreshQualifier__>>/>""">


it would make sense to add some keyboard widgets here that can be configured with more actions without having to edit this tiddler

BurningTreeC · 2019-01-03T13:33:27Z

core/wiki/macros/input.tid

+<$action-setfield $tiddler=<<__refreshTiddler__>> text=<<__refreshQualifier__>>/>
+<$action-deletetiddler $tiddler=<<__editTiddler__>>/>
+<$action-deletetiddler $tiddler=<<__saveTiddler__>>/>
+<$action-setfield $tiddler=<<__refreshTiddler__>> text=""/>


this sequence seems strange but is needed somehow like that if we don't come up with a different refresh mechanism

BurningTreeC · 2019-01-03T13:34:35Z

core/wiki/macros/input.tid

+<$action-setfield $tiddler=<<__editTiddler__>> text=<<nextTag>>/>
+<$action-deletetiddler $tiddler=<<__refreshTiddler__>>/>
+<$action-setfield $tiddler=<<__refreshTiddler__>> refresh-qualifier={{{ [[$(tv-refresh-input-qualifier)$]] }}}/>
+<$action-setfield $tiddler=<<__refreshTiddler__>> text=<<nextTag>>/>


theses two lines make the input field refresh after its text has changed through up/down-arrow selections

BurningTreeC · 2019-01-30T09:45:39Z

Hi @Jermolene , are you interested in this?

You proposed a refresh-mechanism for inputs that restores focus. Have you got an idea how to do that?

Jermolene · 2019-01-30T10:02:49Z

are you interested in this?

Very interested in gaining the functionality, but keen to do it right...

You proposed a refresh-mechanism for inputs that restores focus. Have you got an idea how to do that?

Tentatively, one possible approach is to have a tiddler called $:/state/current-focus that contains a string identifying the widget that owns the focus. Then each widget instance that wants to opt-in to the mechanism would need to have an attribute that gave the qualified ID for that widget. Then at refresh, the widget would detect whether it owned the focus, and set the focus to itself if so.

Jermolene · 2019-01-30T10:03:29Z

btw the other thing that we should be able to fix in this way is maintaining the focus/selection while editing fields within the current tiddler...

BurningTreeC · 2019-01-30T10:54:25Z

btw the other thing that we should be able to fix in this way is maintaining the focus/selection while editing fields within the current tiddler...

Ah yes, that should be done while we're on it.

So, if I understand it right, the widgets should define a unique ID and populate $:/state/current-focus with it when they get focus. When they leave focus, they check if the ID in that tiddler matches their ID and maybe set this.widget.shouldFocusAgain to true (?) and after a refresh of the widget, if this.shouldFocusAgain is true, it sets focus ...?

Jermolene · 2019-01-30T11:34:25Z

Hi @BurningTreeC

That's the idea, yes. There are quite a few points to think about:

Triggering a refresh cycle every time the focus changes might be burdensome, so we may need to e.g. suppress change events for changes to the selection tiddler that have been immediately actioned
We'll also need to track the start and end positions of the text selection
I don't think that there is a reasonable basis for the widgets to generate the IDs themselves, but perhaps we should explore whether there are any viable strategies.

BurningTreeC · 2019-01-30T11:59:48Z

Triggering a refresh cycle every time the focus changes might be burdensome, so we may need to e.g. suppress change events for changes to the selection tiddler that have been immediately actioned

That's the reason why I originally made the refreshTiddler attribute, so it does this kind of refresh only if that tiddler refreshes. That tiddler should refresh with the user-action, so it needs to be updated with an action-widget after a user-interaction. I understand that it's a bit complicated.

We'll also need to track the start and end positions of the text selection

Yes, that's important. I was thinking about an inputManager startup module that initializes an array where inputs store their selectionStart and selectionEnd identified by the unique ID we're going to use ...

I don't think that there is a reasonable basis for the widgets to generate the IDs themselves, but perhaps we should explore whether there are any viable strategies.

I couldn't find another way ... a tiddler can have many inputs that edit the same tiddler and the same field/index and they could all be siblings, so a state qualifier using a combination of the editTitle, editField/Index and stateQualifier wouldn't be unique. I came up with adding the index of the widget within the array of its siblings to that identifier which is working well:

this.editQualifiedID = this.editTitle + (this.editField ? this.editField : "") + (this.editIndex ? this.editIndex : "") + this.getStateQualifier() + this.getOwnSiblingsWidgetIndex();

But possibly I'm just not seeing the best approach

BurningTreeC · 2019-01-30T12:23:15Z

I see now that my approach would need to register each widget within an array of its parent widget

pmario · 2019-01-31T11:06:04Z

btw the other thing that we should be able to fix in this way is maintaining the focus/selection while editing fields within the current tiddler...

I think this would be a "killer" ;)

BurningTreeC · 2019-03-12T12:22:30Z

Hi @Jermolene , this PR has merge conflicts that could be resolved. Do you have an idea/a roadmap how to go on with this? The unique widget id seems to be difficult to solve, this mechanism here uses a different approach, demanding that a given condition must be true in order for the input to refresh its text and focus again.

the condition is that a given refreshTiddler has changed and that the refreshCondition attribute is "true". it's a bit tricky as a mechanism, but it works

Jermolene · 2019-03-12T12:34:42Z

Do you have an idea/a roadmap how to go on with this? The unique widget id seems to be difficult to solve, this mechanism here uses a different approach, demanding that a given condition must be true in order for the input to refresh its text and focus again.

It's tricky. The problem is that if we merge this then we're committed to supporting this technique forever, and that might limit our ability to address related problems in the future. On balance, experimental stuff like is good to chew over as a plugin. Do you think that's feasible, if we added enough core hooks?

BurningTreeC · 2019-03-12T12:55:07Z

@Jermolene , I know I'm absolutely not convinced that this should be the mechanism to stick with forvever. but it's a mechanism that works, now.

the plugin proposal would be just right. about the hooks ... would you just add a hook in the factory.js refresh method, passing the widget?

Jermolene · 2019-03-12T12:56:50Z

would you just add a hook in the factory.js refresh method, passing the widget?

Yes I think that's reasonable.

BurningTreeC · 2019-03-12T13:00:15Z

would you just add a hook in the factory.js refresh method, passing the widget?

Yes I think that's reasonable.

ok, there are more points where factory.js would need to be extended, see https://github.com/Jermolene/TiddlyWiki5/pull/3565/files#diff-2788afb61c207f85b558b296f643ce5e

what's the best way to do it?

Jermolene · 2019-03-12T13:04:49Z

what's the best way to do it?

Too many hooks at random places will also box us in too far. It may be reasonable to look at subclassing the existing factory.js, I'm not sure how much hackery would be needed to make that possible though...

BurningTreeC · 2019-03-12T13:25:27Z

what's the best way to do it?

Too many hooks at random places will also box us in too far. It may be reasonable to look at subclassing the existing factory.js, I'm not sure how much hackery would be needed to make that possible though...

ok, I'll make a minimal working concept and see where subclasses make sense without overdoing it

BurningTreeC · 2019-03-14T08:38:50Z

Hi @Jermolene,

in order to make this functionality work using hooks and a startup module, I need 3 hooks, one in the refresh method, one in the execute method and one in the getEditInfo method of factory.js

it's really simple to extend it this way, I think it'd be a great hackability extension

BurningTreeC · 2019-03-14T11:21:02Z

in order to make this functionality work using hooks and a startup module, I need 3 hooks, one in the refresh method, one in the execute method and one in the getEditInfo method of factory.js

nah, this was exaggerated, I only need 1 hook in the refresh method

BurningTreeC · 2019-07-04T07:34:49Z

opening this again for discussion - I got a version working that uses the new widget-subclassing here: http://selectable-inputs.tiddlyspot.com/

BurningTreeC · 2019-07-04T07:53:47Z

closing in favor of a new attempt

BurningTreeC added 7 commits November 21, 2018 15:02

add refreshTiddler attribute && refresh on changes

f72d0a3

add tag-picker with dropdown-selection

f2e7d2e

add style for selected tag

dfe8362

fix refreshTiddler - refreshing

cb2abfe

Update tag-picker.tid

7a84d28

add tag-input cancel-actions (escape)

9e7a541

Update tag-picker.tid

03808ac

BurningTreeC changed the title ~~inputs: second tiddler where edits can be stored~~ [UI] add selectable tags-dropdown Nov 21, 2018

BurningTreeC added 2 commits November 21, 2018 16:12

Update tag-picker.tid

933071c

Update tag-picker.tid

09c6bd1

BurningTreeC added 6 commits November 21, 2018 17:05

Update tag-picker.tid

8cd1c80

use tv-refresh-input-variable

6d90da4

use tv-refresh-input-variable

c34ec4a

Update factory.js

3859f4d

use tv-refresh-input-qualifier

331eee7

use tv-refresh-input-qualifier

0257b15

BurningTreeC added 6 commits November 22, 2018 21:13

refactor dropdown-selector macro

f3d19df

add $:/core/macros/input

c526b1d

refactored the dropdown-selector logic into a `selectable-dropdown-input` macro

move dropdown macros to $:/core/macros/input

1a5ecd9

Update input.tid

144651d

Update input.tid

a45a8f7

add explicitState to tabs macro

a52fb20

lets us define the state for a tabs-list explicitely, useful for selectable-dropdown-inputs, knowing the state tiddler from outside

BurningTreeC commented Jan 3, 2019

View reviewed changes

Merge branch 'master' into patch-48

bbe91ff

BurningTreeC closed this Mar 14, 2019

BurningTreeC deleted the patch-48 branch June 23, 2019 13:29

BurningTreeC restored the patch-48 branch July 4, 2019 07:33

BurningTreeC reopened this Jul 4, 2019

BurningTreeC closed this Jul 4, 2019

BurningTreeC deleted the patch-48 branch July 20, 2020 06:33

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[UI] add selectable tags- and search-dropdown #3565

[UI] add selectable tags- and search-dropdown #3565

BurningTreeC commented Nov 21, 2018 •

edited

Loading

Jermolene commented Nov 21, 2018

BurningTreeC commented Nov 21, 2018

BurningTreeC commented Nov 21, 2018

pmario commented Nov 22, 2018

BurningTreeC commented Nov 22, 2018

pmario commented Nov 22, 2018

BurningTreeC commented Nov 22, 2018 •

edited

Loading

BurningTreeC Jan 3, 2019

BurningTreeC Jan 3, 2019

BurningTreeC Jan 3, 2019

BurningTreeC Jan 3, 2019

BurningTreeC commented Jan 30, 2019

Jermolene commented Jan 30, 2019

Jermolene commented Jan 30, 2019

BurningTreeC commented Jan 30, 2019

Jermolene commented Jan 30, 2019

BurningTreeC commented Jan 30, 2019 •

edited

Loading

BurningTreeC commented Jan 30, 2019

pmario commented Jan 31, 2019

BurningTreeC commented Mar 12, 2019

Jermolene commented Mar 12, 2019

BurningTreeC commented Mar 12, 2019

Jermolene commented Mar 12, 2019

BurningTreeC commented Mar 12, 2019

Jermolene commented Mar 12, 2019

BurningTreeC commented Mar 12, 2019

BurningTreeC commented Mar 14, 2019

BurningTreeC commented Mar 14, 2019

BurningTreeC commented Jul 4, 2019

BurningTreeC commented Jul 4, 2019

[UI] add selectable tags- and search-dropdown #3565

[UI] add selectable tags- and search-dropdown #3565

Conversation

BurningTreeC commented Nov 21, 2018 • edited Loading

Jermolene commented Nov 21, 2018

BurningTreeC commented Nov 21, 2018

BurningTreeC commented Nov 21, 2018

pmario commented Nov 22, 2018

BurningTreeC commented Nov 22, 2018

pmario commented Nov 22, 2018

BurningTreeC commented Nov 22, 2018 • edited Loading

BurningTreeC Jan 3, 2019

Choose a reason for hiding this comment

BurningTreeC Jan 3, 2019

Choose a reason for hiding this comment

BurningTreeC Jan 3, 2019

Choose a reason for hiding this comment

BurningTreeC Jan 3, 2019

Choose a reason for hiding this comment

BurningTreeC commented Jan 30, 2019

Jermolene commented Jan 30, 2019

Jermolene commented Jan 30, 2019

BurningTreeC commented Jan 30, 2019

Jermolene commented Jan 30, 2019

BurningTreeC commented Jan 30, 2019 • edited Loading

BurningTreeC commented Jan 30, 2019

pmario commented Jan 31, 2019

BurningTreeC commented Mar 12, 2019

Jermolene commented Mar 12, 2019

BurningTreeC commented Mar 12, 2019

Jermolene commented Mar 12, 2019

BurningTreeC commented Mar 12, 2019

Jermolene commented Mar 12, 2019

BurningTreeC commented Mar 12, 2019

BurningTreeC commented Mar 14, 2019

BurningTreeC commented Mar 14, 2019

BurningTreeC commented Jul 4, 2019

BurningTreeC commented Jul 4, 2019

BurningTreeC commented Nov 21, 2018 •

edited

Loading

BurningTreeC commented Nov 22, 2018 •

edited

Loading

BurningTreeC commented Jan 30, 2019 •

edited

Loading