A question about windowclasses

[daddyogreman]

If I were to write my own windowclass, I'm confused as to how I would get at the data I'm passing to it. For example, I'm trying to modify an extension that has a call to an (apparently) pre-defined window class that is instantiated with the call Interface.openWindow(url, "urlString")
I've read up some on window classes and it seems you can have one either bound to DB nodes or unbound. In the above case, it looks as though the windowclass is unbound as it's not being passed a node upon creation. I'm curious as to how, in the definition of the url windowclass, it can access the value urlString. I see there's a bunch of available calls within the famework of a windowinstance (bringToFront, close, createControl, onInit, etc), but I can't figure out how to get at the data that's been passed in with the instantiation of the window. Ultimately I just want to write a slightly different version of the url windowclass to open urls in a headless browser via lua executing command line bash but I don't see how to get at the value of urlString from within the windowinstance.

[Trenloe]

Interface.openWindow is defined here: https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/996644632/Interface#openWindow - i.e. openWindow(windowclass, datasource)

As mentioned in that API document, datasource is the name of the database node that the window will be built on. You can use <windowinstance>.getDatabaseNode to return the FG database node object referring to that DB node: https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/996644858/windowinstance#getDatabaseNode It'll be nil if the window instance doesn't have a data source.

[daddyogreman]

Ah so the ONLY way to pass data along to a windowinstance is via a DB node? Unbound windowinstances can never have data passed to them?

[Trenloe]

Unbound windowinstances can never have data passed to them?
You'll have to build the data in the unbound window during or after window initiation, using the windowinstance onInit function, or the onInit function of the controls in the window, or some external <windowinstance>.<LUA function> call.

[daddyogreman]

To clarify, I was under the impression the code I was looking at was instantiating a window instance (of windowclass url) with a simple string of a URL (SURL) with an auth token tacked onto the end. It sounds as though my impression was incorrect here and it's actually passing a database node that I haven't spotted yet where it's being loaded into that variable? That my impression of a window instance being passed a simple string is impossible?

[Trenloe]

Ah, sorry - I thought you were using "url" as a general terminology and not specifically the open external browser window functionality.

All that does is use the preferred operating system browser to open a URL. That URL has to be a valid website, or valid local file, or other valid URL registration on the computer. The call is a one shot call with nothing FG code can do after the call is sent - the browser is external to FG and FG code can't interact with it. That's why you asking about accessing the browser window confused me.

[daddyogreman]

If I wanted to override that one shot call to open a browser headlessly via the command line, would that be possible?
Right now it works just fine - it opens the URL in a browser. The problem is the browser is taking focus from Fantasy Grounds and opening a tab to play the sound. Which is annoying in both that I have to flip back to Fantasy grounds every time and when I'm done, I'll have a ton of open tabs to various urls I'll have to close. I was just hoping to override that functionality to call a headless browser which will deal with both the focus and crazy number of tabs issue.

[daddyogreman]

Or another approach - would it be possible to code up a new windowclass that can make a call to the operating system to accomplish what I want via lua? I'm extremely new to all of this - including lua.

[daddyogreman]

Also what does the code for the URL windowclass Look like?
How is it accessing the value of the string being passed to it if it isn't loading up a db node?

[superteddy57]

The coding is very limited when it comes to calling the operating system with ruleset code. This is for security reasons and protection for others and yourself.

[Trenloe]

Also what does the code for the URL windowclass Look like?
How is it accessing the value of the string being passed to it if it isn't loading up a db node?
It's not a windowclass exactly. The base FG application code knows to handle "url" differently - that it won't be a windowclass. All it does is launches the default O/S browser with the value of the second argument (URL string). Then it continues on its merry way, not knowing or caring if the browser opened and displayed the URL.

So, if you want to try to do something in the browser, you'll need to code something into the resulting resource pointed to by the URL - if it's an HTML page, put some code in to do what it needs to do then close the browser, for example.

[daddyogreman]

So what approach would be suggested here? If the url windowclass isn't necessarily a windowclass, would I have to create a db node to put the url into, create a new windowclass that loads up said db node so it can get at the url string? Looking at the docs for a windowinstance (https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/996644858/windowinstance) I'm not seeing anything that can actually interact with the OS. Looking at the docs for LUA itself, I do see there's obviously some calls to execute bash commands and the like (os.execute (https://www.lua.org/pil/22.2.html), for instance). I get the need for limiting direct access to the OS, but as stated earlier, obviously there's at least few things that can be done - the url "windowclass" being a good example where it just passes off the call to the OS to open the URL as the OS sees fit.

[Trenloe]

For security reasons you can't execute operating system commands directly from LUA within FG - they are specifically blocked.

A FG windowclass is only used for displaying a window within FG. "url" is the only exception to this.

Let's take a step back. Please give details of what you're trying to do.

[daddyogreman]

I just want a way to, instead of pass the URL off to the OS to handle as it chooses, specify that it should open the URL in a specific way - as in a command line call to a headless browser such as google-chrome --headless <URL> in bash on linux.
Or any other way to accomplish this. I have no control over the content of the web page being opened, so I can't modify things on that end.
On a side note, Trenloe you're awesome. Thanks so much for the help.

[Trenloe]

I just want a way to, instead of pass the URL off to the OS to handle as it chooses, specify that it should open the URL in a specific way - as in a command line call to a headless browser such as google-chrome --headless <URL> in bash on linux.
Or any other way to accomplish this. I have no control over the content of the web page being opened, so I can't modify things on that end.
All you can do is open a browser with a URL. That can be a web resource, local file or an application linked to a specifically registered URL class (depending on the operating system you're using).

If you want to do something more than just open a web page, the URL you use will need to open a specific application, or have some code embedded to do something more - like a local HTML file with code in the HTML, or something similar.

[Trenloe]

Note that your browser can more than likely process URIs rather than just HTTP based URLs. Some info on the difference here: https://www.guru99.com/url-vs-uri-difference.html

[Kelrugem]

I may be able to clarify what daddyogremann wants to do: Seemingly on Linux an url call also shifts the focus to whatever gets opened, unlikely to Windows seemingly (they were testing Celestian's sound extension and sound calls were seemingly resulting into that Syrinscape suddenly had focus and they needed to bring the focus back to FG).

I am not really an expert for those things, but I still believe that such a possible difference of Linux and Windows may only be changed by SmiteWorks themselves :) Which is why I suggested Daddyogreman to post here to see what the devs might say about that possible difference :)

[superteddy57]

The interaction with any OS related tasks is done within the engine of the program and not available with ruleset code. So in the case of url, it pipes into the ruleset to allow adding the string for the url, but the processing is done in the engine. The reasoning is for security and if you feel this is a problem with the Linux client, then I would recommend making a post within the Linux Unity thread in the support area of the forums. The dev responsible for that client to investigate.

[Trenloe]

I may be able to clarify what daddyogremann wants to do: Seemingly on Linux an url call also shifts the focus to whatever gets opened, unlikely to Windows seemingly (they were testing Celestian's sound extension and sound calls were seemingly resulting into that Syrinscape suddenly had focus and they needed to bring the focus back to FG).
Thanks for the background info. Context is always good when having detailed discussions such as these. I think we're gone beyond just this though...