Mohamad et a
To add to this conversation what we are talking about is the visibility of
fields when in the edit template, there are the already hidden ones in the
edit fields list such as "created", change count and others. I have taken a
different approach in my key tiddlywiki. I leave the edit facility alone
but rarely enter edit mode at all. I have created the ability to edit
fields in view mode (using some gymnastics to edit the current tiddler and
a toggle to show / hide), and provide my own code to edit each field, so I
can honour the nature of different fields, like dates have time stamps and
date pickers, the icon field has the image selector, and some fields allow
you select from predetermined values and some from existing values in other
tiddlers matching fields. Using this method I can list in an
edit-fields-list (field) the fields to display and their order, provide
drop down lists to add fields and much more. This facility extends to tags,
alternative tag fields and the text field.
Whilst this is working in a robust way for me it is premature for me to put
forward proposed changes to the development team, but I expect I will
eventually. You may have seen some posts from me about fields as first
class citizens. I believe we need to provide the core the following
features.
- An easy way to edit fields in the current tiddler
- The ability to define fields, their usage and ways they can source
information
- An easy way to arrange what and how fields can be displayed in
tiddlers view mode or an additional mode called update.
I have also an example where I have manipulated the way the edit fields
list that appears in edit mode works such that it includes links to the
fields definition.
I have also taken this further to allow the field definitions to include
how a field may appear for view or edit in list columns. Basically if you
list some tiddlers you can provide a tiddlername that tags all the columns
you want in that list, the columns then define its title, and how to
display and/or edit that fields value in the list. I believe these should
all be rolled into the field definition.
The reason it is not ready for inclusion in the core or key plugins is the
solution would best set a standard such that in future others can share
field definitions, column definitions etc... and the core can just enable
this and set the standards with out providing all the details.
Regards
Tony
On Tuesday, October 9, 2018 at 8:45:56 AM UTC+11, Mark S. wrote:
>
> You could, if feeling adventurous, hack
>
> $:/core/macros/tag-picker
> Go down to the line:
>
> <$list filter="[tags[]!is[system]search:title{$:/temp/NewTagName}sort[]]"
> variable="tag">
>
> and change to:
>
> <$list
> filter="[tags[]!is[system]!prefix{$:/config/Tags/hide/myprefix}search:title{$:/temp/NewTagName}sort[]]"
>
> variable="tag">
>
> and then make a tiddler:
>
> $:/config/Tags/hide/myprefix
>
> and put whatever prefix you wish to prevent showing (in the editor)
>
> This way if you have a series of structural tiddlers (one's that you use
> to create a TOC tree, for instance) then you could put
>
> toc_
>
> So that you would see tags that had actual meaning (contacts, personal,
> locations, etc.).
>
> -- Mark
>
>
> On Monday, October 8, 2018 at 1:56:51 PM UTC-7, Mohammad wrote:
>>
>> Hello Mark,
>> Should we do this for every field and tag we don't want?
>>
>> -Mohammad
>>
>
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/4986fae3-83d9-492c-a244-04ec10be7e29%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
