Params for simple windows using tm-open-window message

This is a feature request.

It could be very useful to have these parameters available for the tm-open-window message. (and maybe the tm-open-external-window as well.)

'menubar=yes/no, titlebar=yes/no, toolbar=yes/no'

It seems that scrollbar options could be left up to CSS, whereas these cannot.

There are very many exciting use cases for the aesthetics of simple view pane windows for individual Tiddlers.

I have dabbled with core…windows.js, but I know somebody else would do a better job incorporating the couple lines necessary for this.

The problem is, that it never is “a couple of lines.”

I assume whith menubar=yes you mean the menubar-plugin that is shown at the top of tiddlywiki.com - right?

With titlebar=yes I assume you mean the tiddler title in view-mode as shown below. -
All of it? Only the title or including modified info and tags?

I do not know, what you mean with toolbar=yes – You will need to be more specific with this one.

Edit mode will cause a lot of synchronisation “edge cases”. So open a tiddler in edit-mode can cause problems and potentially loosing data.


tm-open-external-window opens a completely new browser window, with a fixed URL address. We can not control that view. It will show the page. That’s basically it.

I believe the OP is referring to several legacy “windowFeatures” of the window.open() javascript API. These values were previously used by the window.open(...) function to control whether the rendered window would have a BROWSER titlebar, menubar, and/or toolbar. However… these windowFeatures values are generally no longer supported by most (all?) modern browsers.

Currently the TWCore’s handling for tm-open-window does this:

window.open("","external-" + windowID,"scrollbars,width=" + width + ",height=" + height + (top ? ",top=" + top : "" ) + (left ? ",left=" + left : "" ))

The result is that the new window is always created as a “minimal popup window”, with only an application titlebar and browser address bar and the specified width,height, and top/left position.

-e

2 Likes

Yes, I should have been more spedific:

. . . This is what I was referring to in the windows.js.

W3C Window open() Method

window.open(*URL, name, specs, replace*)

The parameter exists as “specs” separated by commas with no whitespace technically.

I would have assumed that this would have worked:

window.open("","external-" + windowID,"menubar=no,titlebar=no,toolbar=no,scrollbars,width=" + width + ",height=" + height + (top ? ",top=" + top : "" ) + (left ? ",left=" + left : "" ))

The browser support appears to be pretty good. Emphasis on “appears”.

The following snippet works in Firefox as a popup. However, it still doesn’t get rid of the titlebar/toolbar/ menubar.

General Non-Tiddly Example:

<p>Click the button to trigger the popup!</p>
<button onclick="openPopup()">Open Popup</button>

<script>

// Function to open a new popup with a message
function openPopup() {
    let newWindow = window.open("", "Example", "toolbar=no,titlebar=no,menubar=no,width=400,height=400");
    newWindow.document.write("<h1>Welcome to our new popup!</h1>");
}
</script>

You can see very well why I thought this would be possible for someone with a little more experience.

You have my blessing to delete this topic.

I suppose these options really are being slowly deprecated by the browsers. It’s not that sad generally, but it would have been cool for TiddlyWIki menus and controls to be able to exist in multiple windows. If you are at all familiar with tiling window managers on Linux, then you can see how that could be very cool.

FOr instance, the sidebar could be sent to a different window - and used on the left or right without very much theming work at all.

These types of browser-window popups are being replaced by in-page modals and purpose-built alert boxes.

Even though your initial suggestion for tm-open-window is moot, there’s no need to delete the topic, as it still might help someone better understand the inner workings of the TWCore.

With regard to “the sidebar could be sent to a different window”, try this:

Put the following in a new tiddler:

\define hide() $:/config/SideBarSegments/Visibility/$(item)$
<$list filter="[all[shadows+tiddlers]tag[$:/tags/SideBarSegment]!has[draft.of]]" variable=item>
<$list filter="[<hide>!text[hide]]"><$transclude tiddler=<<item>> mode=block/>

Then, from that tiddler’s “more” menu, choose “open in a new window”. You now have a sidebar as a separate window, and can hide the sidebar in the main window by using the “double chevron” button (upper right corner).

enjoy,
-e

1 Like

It is nifty enough, but with windows that don’t have titlebars etc., it could reach that level of appeal that would push it to being a desirable feature for multiple purposes. It’s just missing that little bit of umph.(And while also being a browser-generic solution.)

Thank you for your help.

Just a word of advice…

You should not confuse W3C with w3Schools – they are not the same thing and are not related in any way. It’s true that w3Schools is better today than they were in the past, but you should avoid treating their material as though it were straight from the horse’s mouth.

You can read what the horse has to say here.

1 Like

Wow, great catch. Thank you, genuinely.

Also it’s weird that I’ve never been sent to the standards site from a search engine.

1 Like

Just in case anyone is wondering, I think that this official documentation says it is quite possible to have a clean popup window. However, I’m not sure it’s that clear.

Example:

globalThis.open("https://URL", undefined, "noopener,popup");

and then:

“To check if a window feature is set, given tokenizedFeatures, featureName, and defaultValue:”
“To check if a popup window is requested, given tokenizedFeatures”

It seems sort of complex now.

https://html.spec.whatwg.org/multipage/nav-history-apis.html#dom-open-dev

To check if a popup window is requested, given tokenizedFeatures:
    1. If tokenizedFeatures is empty, then return false.
    2. If tokenizedFeatures["popup"] exists, then return the result of parsing tokenizedFeatures["popup"] as a boolean feature.
    3. Let location be the result of checking if a window feature is set, given tokenizedFeatures, "location", and false.
    4. Let toolbar be the result of checking if a window feature is set, given tokenizedFeatures, "toolbar", and false.
    5. If location and toolbar are both false, then return true.
    6. Let menubar be the result of checking if a window feature is set, given tokenizedFeatures, "menubar", and false.
    7. If menubar is false, then return true.
    8. Let resizable be the result of checking if a window feature is set, given tokenizedFeatures, "resizable", and true.
    9. If resizable is false, then return true.
    10. Let scrollbars be the result of checking if a window feature is set, given tokenizedFeatures, "scrollbars", and false.
    11. If scrollbars is false, then return true.
    12. Let status be the result of checking if a window feature is set, given tokenizedFeatures, "status", and false.
    13. If status is false, then return true.
    14. Return false.

Lost about how this applies to a real example. . . Anyway, it is not my time for this yet, as I was already stretching my abilities to meddle with JS.