tm-open-window - how use paramObject?

[Mat]

I'm working to improve the SideEditor. The new idea is a "separate window" feature, i.e to split out the editor into a separate window which you can then place in front of any other applications you're working on with your computer.

Question: 

The doc for tm-open-window reads:

paramObject

Hashmap of variables that will be provided to the window

but there is no example for how to use this.

Digging in the core, I find $:/core/modules/startup/windows.js which has

 paramObject = event.paramObject || {},
 windowTitle = paramObject.windowTitle || title,
 template = paramObject.template || "$:/core/templates/single.tiddler.window",
 width = paramObject.width || "700",
 height = paramObject.height || "600",
 variables = $tw.utils.extend({},paramObject,{currentTiddler: title});

(I'm assuming this is a definition of it, as opposed to merely some invocation)

But how do I formulate the paramObject argument to achieve:

1. I wish to send along a variable value to be used inside the opened window.
2. width and height are, according to the docs, separate parameters in the tw-open-window call BUT I'm not happy with how they can only be set in pixels because the context I'm using it in does things in vh, vw. 
3. I wish to control the position of the window.

Thank you!

<:-)

[PMario]

On Sunday, July 19, 2020 at 3:22:40 PM UTC+2, Mat wrote:

But how do I formulate the paramObject argument to achieve:

1. I wish to send along a variable value to be used inside the opened window.

IMO just create them. eg:

<$action-sendmessage $message="tm-open-window" width=xxx height=yyy myVar1="some text" myVar2="test" .../>

It should do the trick and give those elements are "variables to the new window" ... Similar to <$var or <$set ...

 

1. width and height are, according to the docs, separate parameters in the tw-open-window call BUT I'm not happy with how they can only be set in pixels because the context I'm using it in does things in vh, vw. 

That's a restriction coming from the browser API. https://developer.mozilla.org/en-US/docs/Web/API/Window/open#Window_features ... Scroll down a bit to "SIZE" and have a closer look at the description. min = 100px and unit is px. ... So imo can't be changed, even if we want to.

 

1. I wish to control the position of the window.

IMO would need to update the function -> GitHub feature request!

Should be possible from the API point of view. See former link.

-mario

[Mat]

PMario wrote:

IMO just create them. eg:

Hahaaa! That does work! This was the most critical of my questions.

1. width and height... pixels VS vh, vw. 

That's a restriction coming from the browser API. https://developer.mozilla.org/en-US/docs/Web/API/Window/open#Window_features ... [...] imo can't be changed, even if we want to.

Yeah... looks like you're right. 

1. I wish to control the position of the window.

IMO would need to update the function -> GitHub feature request!

Gotcha. Thanks.

Additionally, the API docs, under the section with headling "Toolbar and UI parts features" seem to indicate is should be possible to get rid of UP parts. Specifically I want to remove these two "rows", at least the "about:blank" row:

...and/but if I do succeed in removing that upper row, then I'll also need a "close window" button from within the window. 

For these things to be doable, i.e remove the two "rows" and create a close window button, would these also be new features implemented in TW - or is it anything that can already now be accessed via tm-open-window?

Thank you PMario!

<:-)

[Eric Shulman]

On Sunday, July 19, 2020 at 6:22:40 AM UTC-7, Mat wrote:

1. width and height are, according to the docs, separate parameters in the tw-open-window call BUT I'm not happy with how they can only be set in pixels because the context I'm using it in does things in vh, vw. 

You can get *some* control over the width/height of the opened window by calculating it based on $:/info/browser/screen/width and $:/info/browser/screen/height.

For example, if you want the window to be 2/3 of the screen width, you could write:

<$action-sendmessage $message="tm-open-window"
   windowTitle=<<currentTiddler>>
   width={{{ [{$:/info/browser/screen/width}divide[3]multiply[2]] }}} />

-e

[Mat]

Eric Shulman wrote:

You can get *some* control over the width/height of the opened window by calculating it based on $:/info/browser/screen/width and $:/info/browser/screen/height.

Yes, that's a good idea and I think it would even give me *full* control because I can do something like:

[{$:/info/browser/screen/width}multiply[my-value-in-vh-or-vw]]

<:-)

[TW Tones]

Mat,

Somewhere recently a chat about open in new window, and discussions about the side editor, which impresses me, but some how I find it hard to use, something personal thing about edit in sidebar, I went on to make open in new window more robust for my needs that allows us to edit tiddlers to view with the view template

The key for me was being able to open in new window, in view or edit modes on tiddlers, that incorporate the view and edit templates that impact tiddlers in the story but also in the new window. The Open in window is only really a "display body in new window".

• Try this on Tiddlywiki.com new-windows (attached)
• I also included prior work which moves the tiddler to the new window, ie closes the one in the story first, but this only displays the body.

I am keen to see where you go, perhaps with refining the chrome around new windows.

So I share this in the spirit of collaboration. I will eventually publish it if people are keen.

Regards

Tony

[Mat]

TW Tones

Thanks for sharing. I'm don't know if I fully see all of it's functionality but I do see the two "special toolbar buttons" and the result of clicking them. Maybe there is more? It seems to have some RTL setting; when typing in the editor the letters stack up on the left side. Regardless; Nice!

Your creation has a somewhat different objective than the SideEditor does: The SideEditor is intended to provide very "quick and accessible" way to edit things. It intentionally does not give a full edit view because I find that most fields are rarely changed. The "quickness" is also reflected in the hover-to-focus feature which makes it possible to simultaneously show things that in total are bigger than the screen I'm working on. My current experiments with a break out window is mostly to allow feeding data into the editor while working with e.g another program all together or another wiki.

<:-)

[danraymond]

Tones, how to stop editor the letters stack up on the left side as Mat points out. Its the same here also. Would like to use it for my purposes but the stacking stops its general use for me.

[TW Tones]

Dan,

Can you show me a snapshot of this. I can't imagine what is wrong.

I downloaded the first json and dropped it on tiddlywiki.com

Note the view icon opens in a new window will all the view templates that apply to the tiddler, not just a rendered view of the tiddler.

It may not honour some unusual uses of class or css, and does not navigate to links selected (in the story).

I am happy to look into it.

Tones

[danraymond]

Hi Tones,

seems we both in Australia!

I have attached my current base wiki. Just open any tiddler using your icons then try to type text. you will see the cursor jumps to the start of the first line wiht each key stroke. I have the whitespace them installed and use the Stories plugin. No other altered CSS that I know of.

Thanks for taking a look

[TW Tones]

Dan,

Great, another Australian user, where are you?, I am in Randwick./Sydney, I am thinking of starting a local user group. Perhaps virtual since Bob is in Canberra.

Thanks I see it now, the problem is only when using the edit view window. 

It is because I am using the default editor, and as it is not a draft tiddler the refresh occurs.

I will look into it shortly, I think there is a way to forestall refresh, but not sure in this application.

Thanks

Tones

[danraymond]

Hi Tones,

I am in West End, Brisbane. Been a tiddlywiki use since the first days of classic - and they still all work!! A local user group would be a great idea.The maturing of Tiddlywiki and its users is wonderful to watch.