Proposal: Changing PageTemplate list filter to be a macro

[Riz]

Something like

<$list filter=<<tv-config-pagetemplate-filter>> variable="listItem">

in the $:/core/ui/PageTemplate?


It will allow complex and fine grained manipulations of display like

exports.run = function() {
    var filter;
    if (window.matchMedia("(min-width: 960px)").matches) {
         filter = "[all[shadows+tiddlers]tag[$:/tags/PageTemplate]!has[draft.of]]";
    } else {
     filter = "[all[shadows+tiddlers]tag[$:/tags/PageTemplate]!has[draft.of]] -$:/core/ui/PageTemplate/sidebar";
    }

return filter;

and so on.

[Mat]

As a non-js kinda guy I'm wondering if the 'manipulability' would translate into wikitext too, i.e via the actual TW UI? 

<:-)

[Jeremy Ruston]

Hi Riz

That’s an interesting proposal. A few observations:

* In support of the proposal, there are precedents for the core using variables that are expected to be provided via a JS macro. For example, tv-get-export-image-link, tv-get-export-path, tv-filter-export-link etc. 

* Meanwhile, I’ve proposed in the past that we bring the same ability to enable/disable individual components tagged $:/tags/PageTemplate via checkboxes just as we do for $:/tags/PageControls, $:/tags/ViewToolbar etc. Those two proposals could coexist, but at the cost of some complexity

*  The example you’ve given of making the UI responsive to the viewport size would appear to be insufficient, in that we might plausibly want to set other configuration in response to the screen size (eg font, font size, margins, or moving tiddler toolbar buttons into the dropdown on smaller screen sizes). In the past I’ve envisaged solving these problems through a new mechanism that can provide initial values for arbitrary configuration tiddlers that depend upon environmental factors like the viewport size. The nice thing about that approach is that it’s pretty universal; we can use it to configure anything that is controlled by config tiddlers. In combination with my proposal above, your example would be a matter of setting $:/config/PageComponents/Visibility/$:/core/ui/PageTemplate/sidebar to “hide”

What do you think?

Best wishes

Jeremy.

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/96302185-29b6-43a1-88da-b4f8c857bbfa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Riz]

That would be nice to see in action. Although I am eager to see how we are going to bring the environmental variables into play. Is it going to be like: If platform is android => Visibiliy tiddlers are created at startup?

[Jeremy Ruston]

Hi Riz

That would be nice to see in action. Although I am eager to see how we are going to bring the environmental variables into play. Is it going to be like: If platform is android => Visibiliy tiddlers are created at startup?

The idea would be to be able to express rules with logic like that, yes.

Each rule would consist of a filter that is run to determine if the rule is active, the title of a tiddler, and a value to store in that tiddler if the rule matches.

The browser is already exposed through the "browser-sniff” plugin, so your example might be written as:

filter: [{$:/info/browser/is/android}str.equals[yes]]

tiddler: $:/config/PageComponents/Visibility/$:/core/ui/PageTemplate/sidebar

value: no

We’d represent the rules as fields on a tiddler with a special tag.

Best wishes

Jeremy

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/c40c0da1-1a95-406e-8cdc-ab2cac24dbcc%40googlegroups.com.

[PMario]

Hi,

I think this should be done with CSS ..

-m

[Riz]

I agree with the CSS line of thought wrt fonts and others, as there is nothing much to gain in introducing a redundant mechanism to tie them to view-port size.

However, things like page-template and editor toolbar buttons are different. Problem with CSS here is, `display:none` is inefficient. Yes it won't be displayed, but it will be loaded nevertheless. This is acceptable when you have a couple of page-templates to remove, but imagine third party themes with radically different page-templates having to load all the default page-templates in addition to the new ones. It is an unnecessary burden.



@Mat

Yes!. You can define the filter in a macro tiddler ($:/tags/Macro) using the correct variable name.

[PMario]

On Wednesday, March 21, 2018 at 11:04:45 AM UTC+1, Riz wrote:

... Problem with CSS here is, `display:none` is inefficient. Yes it won't be displayed, but it will be loaded nevertheless.

That's a good argument.

-m

[TonyM]

I will just add, currently using Display:none on toolbar buttons is fine if you do not set button boarders

If you do you end up with empty boarders on the tool bar (little Circles)

Regards

Tony