How can I hide the color-picker when adding a "color" field?

[Si]

If you add the field "color" TiddlyWiki will replace the text-box for editing the field value with a color-picker.

In most cases this is very helpful, but I prefer to use color names (e.g. papayawhip), so I don't want to see the color-picker.

I can't figure out how to remove this feature, can anyone help me out?

[TW Tones]

Si,

I can have a look tomorrow, I have delved into this before, however just using your own view widget or edit-text widget will let you access the true value.

Of course also {{!!color}} to view.

You could write an edit template tiddler tagged $:/tags/EditTemplate that provides this text rather than stylised edit in edit mode.

if has:field[color] then use edit-text widget.

Regards

Tones

[Si]

Thanks Tones, if you have solution hidden away somewhere that would be great!

I know that I can add extra ways to view/edit the field, but I want to actually replace the existing mechanism for editing the "color" field.

[TW Tones]

Si,

I have always felt the color picker falls short, though it seems to be a HTML default. My research suggests it already users color names in the pallet.

• I would like to be able to search for color names in the picker
• or past a color number into the picker I extract from anywhere with an in browser color picker
• I have a collection of hundreds of color name/numbers which I would add to this selection

The custom formatting or editing of standard fields is handled inside javascript as far as I can see. I have found that the following allows you to edit the color field as text.

<$edit-text tiddler=<<currentTiddler>> field=color  type="text" tag="input"/>

Placing the above in a tiddler tagged  $:/tags/EditTemplate will allow you to edit it as text and use you color names in the editTemplate

Or better use;

<$list filter="[all[current]has:field[color]]" variable=nul>

Color: <$edit-text tiddler=<<currentTiddler>> field=color  type="text" tag="input"/>

</$list>

Of course you could replace or add a this with a select to select from the valid color names as well. See in $:/core/macros/colour-picker for a list of color names.

There is room for more research but is this enough for now?

Tones

[Eric Shulman]

Give this a try:

Copy the following tiddlers into your own TW document:

https://tiddlytools.com/edit-list.html#TiddlyTools%2FMacros%2Fedit-list

https://tiddlytools.com/edit-list.html#TiddlyTools%2FSettings%2FColors%2FX11Names

https://tiddlytools.com/edit-list.html#TiddlyTools%2FMacros%2Fedit-list%2FColorEditTemplate

The ColorEditTemplate uses this macro:

<<edit-list field:color colors:yes find:yes focusPopup:yes placeholder:"select a color" filter:[{TiddlyTools/Settings/Colors/X11Names}]>>

Notes:

* field:color targets the "color" field of the tiddler

* colors:yes shows the list items using their color values as the background of each item

* find:yes progressively filters the list for partial matches as you type in a color name

* focusPopup:yes automatically shows the list of colors when the color field gets focus

* filter:[{TiddlyTools/Settings/Colors/X11Names}] uses a list of standard X11 color names

Also note that the ColorEditTemplate doesn't automatically hide the TWCore default color field RGB color picker interface.

To hide the default RBG color picker, create a tiddler named $:/config/EditTemplateFields/Visibility/color with contents of hide

Let me know how it goes...

enjoy,

-e

[TW Tones]

Eric,

That looks like a substantial piece of work your edit-list macro. I am working on a fields handling package and this may be a good fit. Is it production ready for its broader use?

Love your work

Tones

[Si]

Wow thanks a lot Eric, yet again you have gone above and beyond.

Is there some part of the TiddlyWiki core that is telling TiddlyWiki to use the color-picker for the color field, or is this just something that the browser does automatically?

[Hans Wobbe]

Eric:

Thank you for this "excellent" additional capability.

Cheers,

Hans

[TW Tones]

Si,

 A quick attempt to edit-text to the field <$edit-text field=color/> shows it is still using the picker, so it seems it is this widget that is choosing to use the picker.

• Found edit-text widget defined in $:/core/modules/widgets/edit-text.js

I have not yet uncovered the full story. It is similar to when when you use {{!!modified}} in a tiddler, the system intervenes and responds with a formatted date.

Regards

Tones

[Eric Shulman]

On Sunday, July 25, 2021 at 3:57:13 AM UTC-7 TW Tones wrote:

That looks like a substantial piece of work your edit-list macro. I am working on a fields handling package and this may be a good fit. Is it production ready for its broader use?

I still working on improving it to the point where I can feel like it's "done" (if there is such a thing!)  For example, in the past 2 days, I've simplified a lot of code to handle issues like automatically changing between default tiddlywiki type and application/json, so it can transparently handle a combination of fields and indexes in the same tiddler.  I also reduced the complexity for handling focus and "activation" of input controls, so that fewer internal tracking tiddlers are required.  And just this afternoon, I refactored the code to vastly reduce the need for manually specified unique IDs to differentiate popups.

I've also built a "Tester" harness to try a variety of different parameter combinations and monitor the internal state tracking tiddlers for modal editing and popup list handling.

I'm sure I'll find yet more deeply technical areas to improve, but all in all, I'd say it's ready for people to TRY IT OUT and so I can get some important feedback.  Be sure to read the "Info" tiddler for specific details.

Give it a whirl and let me know...

https://tiddlytools.com/edit-list.html

Love your work

Aw shucks, thanks! :)

enjoy,

-e

[TW Tones]

Eric,

I thought I had missed this all a long, not that it was in the process of creation. I have built a package for field definitions and they can be assigned a field-type. The field type determines how a field will appear in a number of modes such as view or edit and allows editing in the current tiddler.

• Whilst many fields may just need transclude (to view) or edit-text widget to edit, we often have fields that can be selected from a filter or special values, such as the color field (that triggered this thread), or existing values in a string or all matching fields in the wiki, or even all tiddlers tagged with a special tag.
• It thus seems to me timely that you created edit-list for such cases, rather than me coding each and every possibility (field-type edit macro) as you seem to have done it.
  • With the added bonus of all the special features such as type to search.

Please consider my application here and consider if there would be a way to simplify its use

• In this case when trying to edit a field I have the following key variables already set  currentTiddler field.value fieldname field-values-filter
• So this appears to be the way I will use it 
  • <$macrocall $name=edit-list field=<<fieldname>>  filter=<<field-values-filter>> placeholder=<<field.placeholder>>  tooltip=<<field-tooltip>> id=???/>
  • Now there variables will be supplemented with other parameters as the need arises

So these two questions arise;

• Can we abolish the ID or make it equal to a tiddler-title-fieldname (slugifyeld)?
  • Yes I expect I will have multiple edit-list macros in one tiddler, and possibly more than one tiddler displayed at once.
• Is there any way I could avoid passing the same parameter=value pairs every time? such that I need only set the other parameters?
  • field=<<fieldname>>  filter=<<field-values-filter>> placeholder=<<field.placeholder>>  tooltip=<<field-tooltip>>
    
  • I could make a custom version of edit-list perhaps by modifying the $vars widget?

Elsewhere I have used a design pattern where if the parameter is provided, use it eg $parameter$, if the parameter is not provided eg emptyValue use another source.

eg; field parameter has no value use <<fieldname>> 

Is it correct then if following the $vars widget in edit list I could specify something like this?

<$set name=field value=<<field>> emptyValue=<<fieldname>> >

<$set name= filter value=<<filter>> emptyValue=<<field-values-filter>> >

<$set name= placeholder value=<<placeholder>> emptyValue= <<field.placeholder>>   >

<$set name=tooltip value=<<tooltip>> emptyValue=<<field-tooltip>> >

Then before the closure of $vars place </$set></$set></$set></$set> can you tell me where this is?

Why ask now?

My idea is if you replace the $vars at the beginning from the start with something like this for every parameter;

<$set name=paramname value="""$paramname$""" emptyValue="">

Or something like

<$vars 

    field={{{ [[$field$]is[blank]then<fieldname>] }}} 

    paramname={{{ [[$paramname$]is[blank]then<varname>] }}}

>

Or any other variable!

Or perhaps just

field={{{ [[$field$]] }}} so it can be edited if desired to {{{ [[$field$]is[blank]then<fieldname>] }}}

It would become possible for pesky designer like me to edit the edit-list macro to make use of my own variables, rather than parameters by providing a variable in the matching set parameter, however if the $paramname$ is set it will still behave as advertised/documented?

Then I could simply use <<edit-list>> OR <$macrocall $name=edit-list [additional parameter values] /> and my default variables will be used.

I really appreciate your self documenting and well laid out macro, it makes it possible for me to modify, or more importantly ask you for this feature, while presenting an actual mechaisium, hopefully to make such a modification possible. If you can do this I may revisit my field definitions and allow them to set the variables needed by the edit-list macro if desired, making it much simpler to use, because I can guide the user to providing the parameters needed to the edit-list macro.

Regards

Tones

[TW Tones]

Eric,

If you area interested for a future enhancement, this is very appropriate to the edit-list widget, I would think it somewhat trivial each time the value of a field is selected/set to record it in a data tiddler so we can get the most recently used values, perhaps lifting it to the top of the list, so we get the possible values in order of use frequency (as the history list does).

Regards

Tones

[Eric Shulman]

On Monday, July 26, 2021 at 12:02:43 AM UTC-7 TW Tones wrote:

I thought I had missed this all a long, not that it was in the process of creation.

I created the edit-list macro quite a while ago for use in http://TiddlyTools.com/filtergenerators.html, but I've only recently completely re-written it to be much more robust and have many new optional parameters.

I've also finally put in the work to document it properly and publish it as a stand-alone TiddlyTools URL (http://TiddlyTools.com/edit-list.html)

So these two questions arise;

• Can we abolish the ID or make it equal to a tiddler-title-fieldname (slugifyeld)?

I'm actually doing something like this already.   The code currently generates an ID by combining the target tiddler title, the target fieldname or indexname, an optional ID param, and a system <<qualify>>.  To do this, I use the following:

<$vars   tid={{{ [[$tiddler$]!match[]else<currentTiddler>] }}} re="[^a-zA-Z0-9\-\_]">

<$vars    id={{{ [[$index$]!match[]else[$field$]] +[addprefix[/]addprefix<tid>addsuffix[_$id$]] }}}>

<$vars    id={{{ [<id>search-replace[$:/],[]search-replace:g:regexp<re>,[_]addsuffix<qualify>search-replace[--],[-]] }}}>

Note that this is somewhat different than using the slugify[] filter operator, as my method converts all non-alphanumerics (plus "-" and "_" into "_"), and preserves capitalization.  In contrast, slugify[] retains period "." and converts letters to lower case.

Retaining "." is not an option for my code, since the id is actually used to construct CSS selectors, which use "." as part of their syntax, so it can't be part of the ID itself.  In any case, without using the *optional* "id:..." param, each edit-list instance is very likely to be unique, and the "id:..." param is now only needed under very specific circumstances.

• • Yes I expect I will have multiple edit-list macros in one tiddler, and possibly more than one tiddler displayed at once.

See the "id parameter" discussion in the Notes section here: https://tiddlytools.com/edit-list.html#TiddlyTools%2FMacros%2Fedit-list%2FInfo for more details

• Is there any way I could avoid passing the same parameter=value pairs every time? such that I need only set the other parameters?
  • field=<<fieldname>>  filter=<<field-values-filter>> placeholder=<<field.placeholder>>  tooltip=<<field-tooltip>>
    
  • I could make a custom version of edit-list perhaps by modifying the $vars widget?

Elsewhere I have used a design pattern where if the parameter is provided, use it eg $parameter$, if the parameter is not provided eg emptyValue use another source.

eg; field parameter has no value use <<fieldname>> 

Is it correct then if following the $vars widget in edit list I could specify something like this?

<$set name=field value=<<field>> emptyValue=<<fieldname>> >

<$set name= filter value=<<filter>> emptyValue=<<field-values-filter>> >

<$set name= placeholder value=<<placeholder>> emptyValue= <<field.placeholder>>   >

<$set name=tooltip value=<<tooltip>> emptyValue=<<field-tooltip>> >

Then before the closure of $vars place </$set></$set></$set></$set> can you tell me where this is?

Here's a neat little trick:  if the <$vars> are declared at the top level of the macro definition (i.e., not nested within some other widgets or HTML), then they are all automatically closed when the end of the macro is reached.  Thus, I only need to declare the <$vars> (or <$set>) and don't have to worry about having any matching </$vars> (or </$set>)

 

It would become possible for pesky designer like me to edit the edit-list macro to make use of my own variables, rather than parameters by providing a variable in the matching set parameter, however if the $paramname$ is set it will still behave as advertised/documented?

Then I could simply use <<edit-list>> OR <$macrocall $name=edit-list [additional parameter values] /> and my default variables will be used.

This is an interesting approach.

I really appreciate your self documenting and well laid out macro, it makes it possible for me to modify, or more importantly ask you for this feature, while presenting an actual mechanism, hopefully to make such a modification possible. If you can do this I may revisit my field definitions and allow them to set the variables needed by the edit-list macro if desired, making it much simpler to use, because I can guide the user to providing the parameters needed to the edit-list macro.

Let me give it a try and see how well I can make it work. 

-e

[Eric Shulman]

On Monday, July 26, 2021 at 12:10:01 AM UTC-7 TW Tones wrote:

If you area interested for a future enhancement, this is very appropriate to the edit-list widget, I would think it somewhat trivial each time the value of a field is selected/set to record it in a data tiddler so we can get the most recently used values, perhaps lifting it to the top of the list, so we get the possible values in order of use frequency (as the history list does).

Hmm...  it may be possible to use such a field/value "history" tiddler to create a self-modifying use of edit-list, where values that are entered by hand are then automatically added to the list filter, so that the next time you use that specific edit-list instance, the list contains all the previously entered values.  One problem I anticipate is that it may create a "refresh loop", so it might only be practical to do this when using the confirm:yes option, as it defers the actual updating of the stored value until after the "save" button is pressed.

Let me think about this for while.  I'd like to ensure that the current implementation is stable and reasonably bug free before I dive into adding such a significant new feature.

-e

[TW Tones]

Eric,

Thanks for your feedback. this is a seriously advance tool thanks.

I see what you are saying about the uncertainty without the confirm:yes option. In my fancy-fields solution I have one mode called update, basically each field type has some wikitext defining how to view and how to edit a given field (definition) and where I would use the edit-list macro, in cases where I want the selection features, Another mode I have is called update, basically it uses the view mode to display field content and provides a button to update, on clicking it replaces the view with the edit mode, this is where I was thinking I may save the field value so if desired it can be restored/reset after edit. If seems to me this may be the best point to capture the values for MRU most recently used history etc... rather than in a subset of cases where the edit-list macro is used. Especially if the user then clicks to close the "update/field edit" because I can discover the final value and if it changed.

I point this out because perhaps edit-list is not the place for this history to be captured, although it can "consume the history", rather a more generic set of actions to invoke to set a data tiddler to a fieldname/value, for example in my update button. This could be used to log other actions to the data tiddler as well, then the MRU would just form part of the filter used by edit-list to find values.

I suppose the question for edit-list and other macros, may be, does the designer pump up the filter parameter with the history filter? or shall we permit an additional history-filter parameter, that if used is combined with the filter parameter?. The history may only be a sortby (order in history) filter or more advanced.

But, hey edit-list is already doing so much, don't be distracted by me :)

Regards

Tones 

[TW Tones]

Oh,

This method mentioned later for setting variables to use in edit-list may be better (although untested)

<$vars 

    field={{{ [[$field$]is[blank]then<fieldname>] }}} 

    paramname={{{ [[$paramname$]is[blank]then<varname>] }}}

>

Regards

Tones

[Eric Shulman]

On Monday, July 26, 2021 at 5:07:07 AM UTC-7 TW Tones wrote:

This method mentioned later for setting variables to use in edit-list may be better (although untested)

<$vars 

    field={{{ [[$field$]is[blank]then<fieldname>] }}} 

    paramname={{{ [[$paramname$]is[blank]then<varname>] }}}

>

The following handles two levels of fallback:

1. if the param is passed to the macro
2. else if the param is set as a variable
3. else use a default value

For example, the field value should default to "text" if not provided by either param or variable:

<$vars field={{{ [[$field$]!is[blank]else<field>!is[blank]else[text]] }}}>

 

-e

[Eric Shulman]

OK... so I thought of a really neat way to achieve your goal without modifying my macro!

Give this a try:

First, Create a tiddler (e.g., MyMacros/edit-list), tagged with $:/tags/Macro, containing:

\define my-edit-list(

         id,      tiddler,     field,     index,  timestamp,

    default,  placeholder,   tooltip,       type,     width, 

     filter,         find,      goto,    confirm,     focus,

 focusPopup, cancelPopups, listwidth, listheight,    scroll,

   fontsize,      stretch,    colors,   multiple,      view

)

<$vars

           id={{{ [[$id$]!is[blank]else<id>!is[blank]else[]]                        }}} 

      tiddler={{{ [[$tiddler$]!is[blank]else<tiddler>!is[blank]else[]]              }}}

        field={{{ [[$field$]!is[blank]else<field>!is[blank]else[text]]              }}}

        index={{{ [[$index$]!is[blank]else<index>!is[blank]else[]]                  }}}

    timestamp={{{ [[$timestamp$]!is[blank]else<timestamp>!is[blank]else[yes]]       }}}

      default={{{ [[$default$]!is[blank]else<default>!is[blank]else[]]              }}}

  placeholder={{{ [[$placeholder$]!is[blank]else<placeholder>!is[blank]else[]]      }}}

      tooltip={{{ [[$tooltip$]!is[blank]else<tooltip>!is[blank]else[]]              }}}

         type={{{ [[$type$]!is[blank]else<type>!is[blank]else[]]                    }}}

        width={{{ [[$width$]!is[blank]else<width>!is[blank]else[15em]]              }}}

       filter={{{ [[$filter$]!is[blank]else<filter>!is[blank]else[]]                }}}

         find={{{ [[$find$]!is[blank]else<find>!is[blank]else[no]]                  }}}

         goto={{{ [[$goto$]!is[blank]else<goto>!is[blank]else[no]]                  }}}

      confirm={{{ [[$confirm$]!is[blank]else<confirm>!is[blank]else[no]]            }}}

        focus={{{ [[$focus$]!is[blank]else<focus>!is[blank]else[no]]                }}}

   focusPopup={{{ [[$focusPopup$]!is[blank]else<focusPopup>!is[blank]else[no]]      }}}

 cancelPopups={{{ [[$cancelPopups$]!is[blank]else<cancelPopups>!is[blank]else[yes]] }}}

    listwidth={{{ [[$listwidth$]!is[blank]else<listwidth>!is[blank]else[100%]]      }}}

   listheight={{{ [[$listheight$]!is[blank]else<listheight>!is[blank]else[1]]       }}}

       scroll={{{ [[$scroll$]!is[blank]else<scroll>!is[blank]else[10]]              }}}

     fontsize={{{ [[$fontsize$]!is[blank]else<fontsize>!is[blank]else[1em]]         }}}

      stretch={{{ [[$stretch$]!is[blank]else<stretch>!is[blank]else[yes]]           }}}

       colors={{{ [[$colors$]!is[blank]else<colors>!is[blank]else[no]]              }}}

     multiple={{{ [[$multiple$]!is[blank]else<multiple>!is[blank]else[no]]          }}}

         view={{{ [[$view$]!is[blank]else<view>!is[blank]else[<<item>>]]            }}}

>

<$macrocall $name="edit-list"

         id=<<id>>,              tiddler=<<tiddler>>,          field=<<field>>,          index=<<index>>,   timestamp=<<timestamp>>,

    default=<<default>>,     placeholder=<<placeholder>>,    tooltip=<<tooltip>>,         type=<<type>>,        width=<<width>>,

     filter=<<filter>>,             find=<<find>>,              goto=<<goto>>,         confirm=<<confirm>>,     focus=<<focus>>,

 focusPopup=<<focusPopup>>, cancelPopups=<<cancelPopups>>, listwidth=<<listwidth>>, listheight=<<listheight>>, scroll=<<scroll>>,

   fontsize=<<fontsize>>,        stretch=<<stretch>>,         colors=<<colors>>,      multiple=<<multiple>>,     view=<<view>> />

\end

Basically, you define an alternative "wrapper" around my macro, that handles the $vars-based parameter definitions, and then call my macro from it.

The advantage is that you don't have to change even one line of my code, and you can even re-define the fallback default values!

To use it you can put something like this in a tiddler:

<$vars tiddler="foo" filter="[all[tiddlers]!is[system]]">

<<my-edit-list>>

</$vars>

<$vars tiddler="bar" field="tags" filter="[all[tiddlers+shadows]tags[]]" width=20em placeholder="select a tag">

<<my-edit-list>>

</$vars>

enjoy,

-e

[Eric Shulman]

On Monday, July 26, 2021 at 7:40:48 AM UTC-7 Eric Shulman wrote:

OK... so I thought of a really neat way to achieve your goal without modifying my macro!

Tony,

I've just added this method of using variables vs. parameters as an alternative macro definition:

https://tiddlytools.com/edit-list.html#TiddlyTools%2FMacros%2Fedit-list-vars

which is invoked using: <<edit-list-vars>>

Of course, you will still need to have the underlying macro definition as well:

https://tiddlytools.com/edit-list.html#TiddlyTools%2FMacros%2Fedit-list

See Notes in https://tiddlytools.com/edit-list.html#TiddlyTools%2FMacros%2Fedit-list%2FInfo

for more details regarding usage.

enjoy,

-e

[TW Tones]

Thanks Eric,

This not only allows me to use my variable names but your internal variables stay the same so no modifications at all, as you say. This is a particularly useful solution when the widget or macro concerned is packed with functionality, which is forced upon us through the combining the edit-text and filtered selections. Personally I may use <<edit-fieldname>> rather than <<edit-list-vars>>  and I may even create other macros to use the edit-list macro features where many of the parameters are already set. In many ways this is layers of abstraction, and simplification, while maintaining maximum features.

Now some speculation

Looking at your example it makes me ask if perhaps a special case operator would be nice 

Rather than [[$id$]!is[blank]else<id>!is[blank]else[]]

perhaps [case[$id$,<id>] where the first non blank value is used or nothing at all.

or [case[$id$,<id>,{!!id},{id},2] where the first non blank value is used or 2 (because it will always provide a value ie 2 is the default).

Or alternatively the match could allow parameters match[$id$,<id>,{!!id},{id}]

Because the truth is there are many cases where the first non-blank value is what we are after.

I think the operator parameters demand this following format.

eg filters such as 

[{$:/config/name}case[yes]]

[{$:/config/name}case[yes],[no],[maybe]]  as a valid parameter test

Allowing a full "case" statement;

<$list filter="[<business-size>case[small],[medium],[large]]" variable=case>

   <$list filter="[<case>match[small]]">

  </$list>

   <$list filter="[<case>match[medium]]">

  </$list>

   <$list filter="[<case>match[large]]">

  </$list>

</$list>

Tones

[Eric Shulman]

On Tuesday, July 27, 2021 at 5:06:39 AM UTC-7 TW Tones wrote:

Looking at your example it makes me ask if perhaps a special case operator would be nice 

Rather than [[$id$]!is[blank]else<id>!is[blank]else[]]

perhaps [case[$id$,<id>] where the first non blank value is used or nothing at all.

The only thing that this eliminates is an implied "!is[blank]" syntax, but I can imagine that other conditional filters (e.g., match[], compare[], is[tiddler], etc.) might also be useful, so I'd be hesitant to make a special "case[...]" operator for this purpose.

In addition, to fit with the existing comma-separated operand syntax (e.g. "[search-replace[this],[that]]") your suggestion would written slightly differently, like this:

<$vars foo={{{ [case[$id$],<id>,{!!id},{id},2] }}}>

Also note that in the actual TiddlyTools/Macros/edit-list-vars code, I switched to using separate filter runs with the "~" (else) prefix.

This allows whitespace to be placed between the runs so that the "cases" are much more readable.

-e