[tw5] Re: How can I hide the color-picker when adding a "color" field?

2021-07-27 Thread 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!is[blank]else[]]
> perhaps [case[$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},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

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/c5c5408f-47b0-4005-b685-37ee6962088en%40googlegroups.com.

[tw5] Re: How can I hide the color-picker when adding a "color" field?

2021-07-27 Thread 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 <> 
rather than <>  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!is[blank]else[]]
perhaps [case[$id$,] where the first non blank value is used or nothing 
at all.
or [case[$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}]

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="[case[small],[medium],[large]]" variable=case>
   <$list filter="[match[small]]">

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

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

  



Tones


On Tuesday, 27 July 2021 at 08:58:19 UTC+10 Eric Shulman wrote:

> 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: <>
>
> 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
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/076adf04-7c91-44e9-8878-da94284ddba2n%40googlegroups.com.

[tw5] Re: How can I hide the color-picker when adding a "color" field?

2021-07-26 Thread 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: <>

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

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/3e6b64f2-7a95-455c-abd3-52b116f18093n%40googlegroups.com.

[tw5] Re: How can I hide the color-picker when adding a "color" field?

2021-07-26 Thread 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!is[blank]else[]]
}}} 
  tiddler={{{ [[$tiddler$]!is[blank]else!is[blank]else[]]  
}}}
field={{{ [[$field$]!is[blank]else!is[blank]else[text]]  
}}}
index={{{ [[$index$]!is[blank]else!is[blank]else[]]  
}}}
timestamp={{{ 
[[$timestamp$]!is[blank]else!is[blank]else[yes]]   }}}
  default={{{ [[$default$]!is[blank]else!is[blank]else[]]  
}}}
  placeholder={{{ 
[[$placeholder$]!is[blank]else!is[blank]else[]]  }}}
  tooltip={{{ [[$tooltip$]!is[blank]else!is[blank]else[]]  
}}}
 type={{{ [[$type$]!is[blank]else!is[blank]else[]]
}}}
width={{{ [[$width$]!is[blank]else!is[blank]else[15em]]  
}}}
   filter={{{ [[$filter$]!is[blank]else!is[blank]else[]]
}}}
 find={{{ [[$find$]!is[blank]else!is[blank]else[no]]  
}}}
 goto={{{ [[$goto$]!is[blank]else!is[blank]else[no]]  
}}}
  confirm={{{ [[$confirm$]!is[blank]else!is[blank]else[no]]
}}}
focus={{{ [[$focus$]!is[blank]else!is[blank]else[no]]
}}}
   focusPopup={{{ 
[[$focusPopup$]!is[blank]else!is[blank]else[no]]  }}}
 cancelPopups={{{ 
[[$cancelPopups$]!is[blank]else!is[blank]else[yes]] }}}
listwidth={{{ 
[[$listwidth$]!is[blank]else!is[blank]else[100%]]  }}}
   listheight={{{ 
[[$listheight$]!is[blank]else!is[blank]else[1]]   }}}
   scroll={{{ [[$scroll$]!is[blank]else!is[blank]else[10]]  
}}}
 fontsize={{{ 
[[$fontsize$]!is[blank]else!is[blank]else[1em]] }}}
  stretch={{{ [[$stretch$]!is[blank]else!is[blank]else[yes]]  
 }}}
   colors={{{ [[$colors$]!is[blank]else!is[blank]else[no]]  
}}}
 multiple={{{ [[$multiple$]!is[blank]else!is[blank]else[no]]  
}}}
 view={{{ [[$view$]!is[blank]else!is[blank]else[<>]]
}}}
>
<$macrocall $name="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=<> />
\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]]">
<>

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


enjoy,
-e
On Monday, July 26, 2021 at 6:36:07 AM UTC-7 Eric Shulman wrote:

> 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] }}} 
>> paramname={{{ [[$paramname$]is[blank]then] }}}
>> >
>>
>
> 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!is[blank]else[text]] }}}>
>  
> -e
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/27a83b1c-f06d-4dc3-ad71-ede84f92224dn%40googlegroups.com.

[tw5] Re: How can I hide the color-picker when adding a "color" field?

2021-07-26 Thread 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] }}} 
> paramname={{{ [[$paramname$]is[blank]then] }}}
> >
>

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!is[blank]else[text]] }}}>
 
-e

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/e384ebb8-d4aa-4501-9045-4455b1bfec6en%40googlegroups.com.

[tw5] Re: How can I hide the color-picker when adding a "color" field?

2021-07-26 Thread 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] }}} 
paramname={{{ [[$paramname$]is[blank]then] }}}
>

Regards
Tones

On Monday, 26 July 2021 at 17:42:45 UTC+10 Eric Shulman wrote:

> 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 <>.  To do this, 
> I use the following:
> <$vars   tid={{{ [[$tiddler$]!match[]else] }}} 
> re="[^a-zA-Z0-9\-\_]">
> <$varsid={{{ [[$index$]!match[]else[$field$]] 
> +[addprefix[/]addprefixaddsuffix[_$id$]] }}}>
> <$varsid={{{ 
> [search-replace[$:/],[]search-replace:g:regexp,[_]addsuffixsearch-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=<>  
>>   filter=<> placeholder=<>  
>>   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 <> 
>>
> Is it correct then *if following the $vars widget in edit list* I could 
>> specify something like this?
>> <$set name=field value=<> emptyValue=<> >
>> <$set name= filter value=<> emptyValue=<> >
>> <$set name= placeholder value=<> emptyValue= 
>> <>   >
>> <$set name=tooltip value=<> emptyValue=<> >
>>
> Then before the closure of $vars place  *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  (or )
>  
>
>> 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 <> 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
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from

[tw5] Re: How can I hide the color-picker when adding a "color" field?

2021-07-26 Thread 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 

On Monday, 26 July 2021 at 17:50:47 UTC+10 Eric Shulman wrote:

> 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
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/627eab05-f068-4fa0-b405-1b2ada439d04n%40googlegroups.com.

[tw5] Re: How can I hide the color-picker when adding a "color" field?

2021-07-26 Thread 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

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/45a3b03f-862c-49ba-b51e-95d1ae5b8e1en%40googlegroups.com.

[tw5] Re: How can I hide the color-picker when adding a "color" field?

2021-07-26 Thread 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 <>.  To do this, 
I use the following:
<$vars   tid={{{ [[$tiddler$]!match[]else] }}} 
re="[^a-zA-Z0-9\-\_]">
<$varsid={{{ [[$index$]!match[]else[$field$]] 
+[addprefix[/]addprefixaddsuffix[_$id$]] }}}>
<$varsid={{{ 
[search-replace[$:/],[]search-replace:g:regexp,[_]addsuffixsearch-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=<>  
>   filter=<> placeholder=<>  
>   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 <> 
>
Is it correct then *if following the $vars widget in edit list* I could 
> specify something like this?
> <$set name=field value=<> emptyValue=<> >
> <$set name= filter value=<> emptyValue=<> >
> <$set name= placeholder value=<> emptyValue= 
> <>   >
> <$set name=tooltip value=<> emptyValue=<> >
>
Then before the closure of $vars place  *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  (or )
 

> 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 <> 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

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/7aba452e-1519-48f8-af6f-2545ea5a33f0n%40googlegroups.com.

[tw5] Re: How can I hide the color-picker when adding a "color" field?

2021-07-26 Thread 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

On Monday, 26 July 2021 at 17:02:43 UTC+10 TW Tones wrote:

> 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=<>  
>   filter=<> placeholder=<>  
>   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=<>  
>   filter=<> placeholder=<>  
>   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 <> 
>
> Is it correct then *if following the $vars widget in edit list* I could 
> specify something like this?
> <$set name=field value=<> emptyValue=<> >
> <$set name= filter value=<> emptyValue=<> >
> <$set name= placeholder value=<> emptyValue= 
> <>   >
> <$set name=tooltip value=<> emptyValue=<> >
>
> Then before the closure of $vars place  *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] }}} 
> paramname={{{ [[$paramname$]is[blank]then] }}}
> >
> Or any other variable!
>
> Or perhaps just
> field={{{ [[$field$]] }}} so it can be edited if desired to {{{ 
> [[$field$]is[blank]then] }}}
>
> 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 <> 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
>
>
>
>
> On Monday, 26 July 2021 at 12:31:17 UTC+10 Eric Shulman wrote:
>
>> 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

[tw5] Re: How can I hide the color-picker when adding a "color" field?

2021-07-26 Thread 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=<>  
  filter=<> placeholder=<>  
  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=<>  
  filter=<> placeholder=<>  
  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 <> 

Is it correct then *if following the $vars widget in edit list* I could 
specify something like this?
<$set name=field value=<> emptyValue=<> >
<$set name= filter value=<> emptyValue=<> >
<$set name= placeholder value=<> emptyValue= 
<>   >
<$set name=tooltip value=<> emptyValue=<> >

Then before the closure of $vars place  *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] }}} 
paramname={{{ [[$paramname$]is[blank]then] }}}
>
Or any other variable!

Or perhaps just
field={{{ [[$field$]] }}} so it can be edited if desired to {{{ 
[[$field$]is[blank]then] }}}

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 <> 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




On Monday, 26 July 2021 at 12:31:17 UTC+10 Eric Shulman wrote:

> 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

[tw5] Re: How can I hide the color-picker when adding a "color" field?

2021-07-25 Thread 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

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/e7541509-1928-44ab-9624-cd7b6900a36en%40googlegroups.com.

[tw5] Re: How can I hide the color-picker when adding a "color" field?

2021-07-25 Thread 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
On Sunday, 25 July 2021 at 23:55:37 UTC+10 Si wrote:

> 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?
>
> On Sunday, 25 July 2021 at 10:07:14 UTC+1 Eric Shulman wrote:
>
>> 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:
>> <> 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
>> On Saturday, July 24, 2021 at 6:29:14 PM UTC-7 TW Tones wrote:
>>
>>> 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=<> 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=<> field=color  type="text" 
>>> tag="input"/>
>>> 
>>>
>>> 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
>>>
>>>
>>> On Sunday, 25 July 2021 at 04:48:25 UTC+10 Si wrote:
>>>
 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.


 On Saturday, 24 July 2021 at 14:31:37 UTC+1 TW Tones wrote:

> 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
>
>
>
>
> On Saturday, 24 July 2021 at 01:26:47 UTC+10 Si wrote:
>
>> 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?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop

[tw5] Re: How can I hide the color-picker when adding a "color" field?

2021-07-25 Thread Hans Wobbe 
Eric:

Thank you for this "excellent" additional capability.

Cheers,
Hans

On Sunday, July 25, 2021 at 5:07:14 AM UTC-4 Eric Shulman wrote:

> 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:
> < 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
> On Saturday, July 24, 2021 at 6:29:14 PM UTC-7 TW Tones wrote:
>
>> 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=<> 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=<> field=color  type="text" 
>> tag="input"/>
>> 
>>
>> 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
>>
>>
>> On Sunday, 25 July 2021 at 04:48:25 UTC+10 Si wrote:
>>
>>> 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.
>>>
>>>
>>> On Saturday, 24 July 2021 at 14:31:37 UTC+1 TW Tones wrote:
>>>
 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




 On Saturday, 24 July 2021 at 01:26:47 UTC+10 Si wrote:

> 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?
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/f738a754-ce55-47e1-8d5f-8f8e1e7d3f84n%40googlegroups.com.

[tw5] Re: How can I hide the color-picker when adding a "color" field?

2021-07-25 Thread 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?

On Sunday, 25 July 2021 at 10:07:14 UTC+1 Eric Shulman wrote:

> 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:
> < 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
> On Saturday, July 24, 2021 at 6:29:14 PM UTC-7 TW Tones wrote:
>
>> 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=<> 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=<> field=color  type="text" 
>> tag="input"/>
>> 
>>
>> 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
>>
>>
>> On Sunday, 25 July 2021 at 04:48:25 UTC+10 Si wrote:
>>
>>> 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.
>>>
>>>
>>> On Saturday, 24 July 2021 at 14:31:37 UTC+1 TW Tones wrote:
>>>
 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




 On Saturday, 24 July 2021 at 01:26:47 UTC+10 Si wrote:

> 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?
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/cc50261a-8c53-4ccc-a129-176525f721e1n%40googlegroups.com.

[tw5] Re: How can I hide the color-picker when adding a "color" field?

2021-07-25 Thread 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

On Sunday, 25 July 2021 at 19:07:14 UTC+10 Eric Shulman wrote:

> 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:
> < 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
> On Saturday, July 24, 2021 at 6:29:14 PM UTC-7 TW Tones wrote:
>
>> 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=<> 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=<> field=color  type="text" 
>> tag="input"/>
>> 
>>
>> 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
>>
>>
>> On Sunday, 25 July 2021 at 04:48:25 UTC+10 Si wrote:
>>
>>> 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.
>>>
>>>
>>> On Saturday, 24 July 2021 at 14:31:37 UTC+1 TW Tones wrote:
>>>
 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




 On Saturday, 24 July 2021 at 01:26:47 UTC+10 Si wrote:

> 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?
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/8b144040-5891-4394-a76a-3e7cd9fa40e3n%40googlegroups.com.

[tw5] Re: How can I hide the color-picker when adding a "color" field?

2021-07-25 Thread 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:
<>

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
On Saturday, July 24, 2021 at 6:29:14 PM UTC-7 TW Tones wrote:

> 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=<> 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=<> field=color  type="text" 
> tag="input"/>
> 
>
> 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
>
>
> On Sunday, 25 July 2021 at 04:48:25 UTC+10 Si wrote:
>
>> 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.
>>
>>
>> On Saturday, 24 July 2021 at 14:31:37 UTC+1 TW Tones wrote:
>>
>>> 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
>>>
>>>
>>>
>>>
>>> On Saturday, 24 July 2021 at 01:26:47 UTC+10 Si wrote:
>>>
 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?

>>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/1ffe4a73-2966-4407-99ba-2ae488e5dae6n%40googlegroups.com.

[tw5] Re: How can I hide the color-picker when adding a "color" field?

2021-07-24 Thread 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=<> 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=<> field=color  type="text" 
tag="input"/>


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


On Sunday, 25 July 2021 at 04:48:25 UTC+10 Si wrote:

> 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.
>
>
> On Saturday, 24 July 2021 at 14:31:37 UTC+1 TW Tones wrote:
>
>> 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
>>
>>
>>
>>
>> On Saturday, 24 July 2021 at 01:26:47 UTC+10 Si wrote:
>>
>>> 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?
>>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/a3abc023-a6e0-4b98-8d84-c4123334670dn%40googlegroups.com.

[tw5] Re: How can I hide the color-picker when adding a "color" field?

2021-07-24 Thread 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.


On Saturday, 24 July 2021 at 14:31:37 UTC+1 TW Tones wrote:

> 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
>
>
>
>
> On Saturday, 24 July 2021 at 01:26:47 UTC+10 Si wrote:
>
>> 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?
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/976af00e-ca9b-473a-a19f-31d34033fcd8n%40googlegroups.com.

[tw5] Re: How can I hide the color-picker when adding a "color" field?

2021-07-24 Thread 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 field.

On Saturday, 24 July 2021 at 14:31:37 UTC+1 TW Tones wrote:

> 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
>
>
>
>
> On Saturday, 24 July 2021 at 01:26:47 UTC+10 Si wrote:
>
>> 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?
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/d8147d5e-446d-4dee-80a4-bee642e16a71n%40googlegroups.com.

[tw5] Re: How can I hide the color-picker when adding a "color" field?

2021-07-24 Thread 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




On Saturday, 24 July 2021 at 01:26:47 UTC+10 Si wrote:

> 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?
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/2808d716-8018-4c6c-9e0b-61e334999131n%40googlegroups.com.