add viewport macro to core?

[Simon Huber]

Hello,

I'd like to propose adding a macro to the TW core functionality that returns the viewport dimensions

The use-cases can be many - there's no such thing in the core right now, I'd be happy if you can proof me wrong

I already use this small set of code:

(function(){

/*jslint node: true, browser: true */

/*global $tw: false */

"use strict";

exports.name = "viewport";

exports.params = [

  { name: "property" }

];

/*

Run the macro

*/

exports.run = function(property) {

  var viewPortWidth = Math.max(document.documentElement.clientWidth, window.innerWidth || 0);

  var viewPortHeight = Math.max(document.documentElement.clientHeight, window.innerHeight || 0);

  if (property === "height") {

    return viewPortHeight.toString();

  } else if (property === "width") {

    return viewPortWidth.toString();

  } else {

    return false;

  }

};

})();

How are my chances? I'd like to create a PR with documentation

Simon

[PMario]

Hi,

On Friday, February 16, 2018 at 10:21:26 AM UTC+1, Simon Huber wrote:

I'd like to propose adding a macro to the TW core functionality that returns the viewport dimensions

The use-cases can be many

Could you name some?

I'm a little bit concerned, that a macro won't be always updated. ... Since they are only calculated, if rendered. ... But I may be wrong here, without tests.

-m

[Simon Huber]

Am Freitag, 16. Februar 2018 11:29:38 UTC+1 schrieb PMario:

Hi,

On Friday, February 16, 2018 at 10:21:26 AM UTC+1, Simon Huber wrote:

I'd like to propose adding a macro to the TW core functionality that returns the viewport dimensions

The use-cases can be many

Could you name some?

executing, revealing, listing different things if the viewport width/height is lower than x, something else if higher

one can do things in css with vw of media queries, but inside macros or widgets I couldn't find a way to get the viewport dimensions

I'm a little bit concerned, that a macro won't be always updated. ... Since they are only calculated, if rendered. ... But I may be wrong here, without tests.

no you're right! it doesn't update. Should I go the widget way?

-m

thanks Mario!

Simon 

[Jeremy Ruston]

Hi Simon

I think the way to do this is as a startup module that listens for viewport size changes and then updates a couple of state tiddlers with the values. The changes to those tiddlers would then trigger any necessary rerendering via the refresh process.

The new DynaView plugin already listens for scroll and resize events, and so it might be reasonable to extend it with these features:

https://github.com/Jermolene/TiddlyWiki5/blob/master/plugins/tiddlywiki/dynaview/dynaview.js

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/e751f885-5861-476c-9ae6-358a6ab1ecaf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Simon Huber]

Thank you Jeremy,

I think the way to do this is as a startup module that listens for viewport size changes and then updates a couple of state tiddlers with the values. The changes to those tiddlers would then trigger any necessary rerendering via the refresh process.

The new DynaView plugin already listens for scroll and resize events, and so it might be reasonable to extend it with these features:

https://github.com/Jermolene/TiddlyWiki5/blob/master/plugins/tiddlywiki/dynaview/dynaview.js

yes this looks perfect,

should it do this by default or by enabling it through a config tiddler?

Best wishes

Jeremy

Simon 

[Jeremy Ruston]

Hi Simon

should it do this by default or by enabling it through a config tiddler?

Yes, great idea, and a checkbox in the plugin control panel would be nice.

Best wishes

Jeremy.

Best wishes

Jeremy

Simon 

--
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/de94fa0f-bd17-4029-ac84-11bf9019964b%40googlegroups.com.

[Simon Huber]

Thanks Jeremy,

I've made a pull request here: https://github.com/Jermolene/TiddlyWiki5/pull/3126

best wishes,

Simon

[Riz]

Could you name some?

Loading separate page-templates for mobile platform would be a start.

[Simon Huber]

Could you name some?

Loading separate page-templates for mobile platform would be a start.

 yes, great Idea!

The dynaview plugin now adds an option to save viewport dimensions dynamically :) !

Simon

[Riz]

IMHO, shouldn't we add them as a part of existing $:/Info tiddlers? That is where it is expected, right? If we do that, third party themes which radically changes outlook by differing Pagetemplates can make use of it. Please consider if not too late already.

sincerely,
Riz

[Simon Huber]

Hi Riz,

IMHO, shouldn't we add them as a part of existing $:/Info tiddlers? That is where it is expected, right? If we do that, third party themes which radically changes outlook by differing Pagetemplates can make use of it. Please consider if not too late already.

I used $:/state tiddlers because they don't trigger a save-wiki process
If you save a wik html file -i in my case on chromium - a bottom download bar appears, that causes a page resize and another dimension change which causes it to save again
with auto saving enabled this could be bad

I think it's not too late to change anything but the $:/state tiddlers seemed best to me

Simon

[Riz]

I do not mind that either - as long as I do not have to install a plugin just to get access to this piece of info. As in, I recommend this to core - instead of a plugin.

[Simon Huber]

I do not mind that either - as long as I do not have to install a plugin just to get access to this piece of info. As in, I recommend this to core - instead of a plugin.

That was my initial idea, too

Now I'm just happy to have it somewhere, but I also think it would be better to have it in the core. It adds almost no weight.

Maybe at one point we can have it as a core feature, would be great

Simon