Investigate bundling chromium or firefox with the portable version of ScriptedForms

[olivercrask]

I typically use chrome, but have noticed Jupyter works in IE11 but scriptedforms does not.

Wasn't sure of the best way to include the javascript log:
https://hastebin.com/jararenawu.js

[SimonBiggs]

I think Microsoft has moved from IE to edge. I'm not going to worry about any IE support.

[SimonBiggs]

Ooo and that's not the right bit of the console, just send the print outs themselves. I'm not sure how to access the console in IE though...

[SimonBiggs]

You okay for me to close this one?

[olivercrask]

Sure. Isn't really an issue for me, just thought I'd let you know as some PCs at my work default to that old IE

[SimonBiggs]

Yeah :). Thanks for thinking of it.

[SimonBiggs]

Actually, I have a neat little bat script at work that boots a jupyter server and then starts the result in a chrome app.

You could use something like that to run on a computer that has chrome but defaults to IE.

I'll send you that bat script later today.

[SimonBiggs]

@OxygenLithium

I use the following batch script to force JupyterLab to open in an 'app' within chrome.

start jupyter lab --port 8989 --no-browser --port-retries 0 --LabApp.token=a_custom_token_here

timeout 1

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --app=http://localhost:8989/lab?token=a_custom_token_here

I imagine scripted forms portable could even have chromium bundled with it (https://sourceforge.net/projects/crportable/) and then have the bat file point to the bundled chromium.

Then as long as scriptedforms is installed as a server extension you could use the above code with a parameter like --LabApp.default_url=/scriptedforms/use/landing-page.md or something of the like.

If you want to give that a try and you are able to get it working we could update the portable version to also include chromium. That would make it even more independent of user machine.

[olivercrask]

Brilliant thanks!
Will give that a try

[SimonBiggs]

Have you ever used https://electronjs.org/? I haven't actually used it for anything yet. But if the portable version really is that helpful then maybe wrapping ScriptedForms up as an electron app would be the ideal solution.

If you happen to be comfortable with electronjs (or don't mind learning it) that may be a perfect answer to making it ultimately portable.

[SimonBiggs]

@robmarkcole @OxygenLithium a big picture question that I would value both of your opinions on. I really want one primary version. That would be the "supported version" other versions might be available, but they won't get my major focus. Right now this is visible in this portable version, I don't use it, so it gets minimal support as a result.

As I see it there are multiple possible future "versions" of ScriptedForms. One is embedded within JupyterLab as a JupyterLab extension. The other is the pip installed web browser based standalone ScriptedForms (which is currently the primary version). Another is the portable python version, still within a browser. And lastly there is the possibility of an electron app, which feels and acts like a desktop application.

If I was to pick just one, and run with it, what would be your preferred? Why?

If a ran with the "electron app" things like JupyterHub are no longer possible. But was JupyterHub wanted for ease of portability anyway? If I go with the electron app then opening the forms up on a mobile pointing to a centre's server is no longer possible. ... But I'm not using it like that at the moment. If it is an electron app I believe my target audience will be far more comfortable downloading it and using it. It should just work independently of what is currently on their computer. They don't really need to know what is under the hood, they can just use it to open form files on their machine.

If ScriptedForms pivoted to be primarily just an electron app, with "dev mode" covered via a shortcut key combination or something. Would that be everything we want it to be? Is losing the option to make a server too much of a big deal?

If it is everything we would want it to be, then sooner rather than later it should become that. And really become just that. I wouldn't focus on any other option.

...let me know your thoughts.

[robmarkcole]

Hi Simon
some thoughts:

1. If this is a Jupyterlab extension, I expect it will get more users as the popularity of that platform grows (which seems certain), and I would make it visible in https://github.com/search?utf8=%E2%9C%93&q=topic%3Ajupyterlab-extension&type=Repositories.

2. For deployment, I would like to have a Jupyterhub running and accessible from office computers. I would like to send my boss a URL which would open a scriptedform, so they could interact with my analysis code, do something useful etc. It would be nice to have a browsable index of forms that can be searched on our internal intranet, and launched from anywhere via the browser. I imagine this would cover 75% of my use cases.

3. In the lab, we don't have any network access, which is why I require something that can run independently of a Jupyterhub and be as simple as possible. My colleague requested the portable version, and it is nice to have a small file on a USB drive that I can drop onto a computer and then have a shortcut on the desktop for running a scriptedform and doing something useful. I don't know anythig about electron apps, but I believe the browser is the most popular GUI :) Portable probably accounts for the remaining 25% of use cases.

Cheers

[SimonBiggs]

Example of Electron Apps are Visual Studio Code, and Slack.

But your points are valid, helpful, and have convinced me. The "primary version" should be the JupyterLab extension version. The standalone browser version (apart from JupyterLab) should be accessible from the same JupyterLab server and should primarily be focused on providing an "end user" experience, all debugging features removed.

No need for me to invest time into making into an Electron App.

Alright, how about ASAP I make it into a JupyterLab extension. I might give that a try tonight.

[robmarkcole]

Brilliant :)

[olivercrask]

I agree that the JupyterLab and portable versions will be most useful. JupyterLab for servers and general usage. Whilst the portable version can be used when access to the network is unavailable or in situations where you cannot get software installed. :)

[mlshapiro]

@SimonBiggs thank you for all the work - i am really enjoying using this tool.

I would be interested in helping to create a portable application that can load and render files. I have experience with electron and could prototype this implementation. I agree with @robmarkcole that you may get more adoption by focusing on the jupyter community (creating extensions, integrating with the notebook, working with jupyterhub). I personally have a use case within my organization where I would like to send un-technical users a form to render. It would be great to have them use a standalone application (without having to install/manage python).

[SimonBiggs]

Hi @mlshapiro,

Thank you. I am really glad you are enjoying using this tool.

Making an electron app would be quite valuable. I can also see significant advantages within my own organisation should ScriptedForms be able to be deployed in that simple method. Fundamentally, from the users point of view, ScriptedForms is a simple tool. It should just be able to read and display interactive files. Every other application of that type is a simple to install application, so ScriptedForms makes sense being one too.

There definitely is a "fear factor" around having a python installation. And there is a degree of comfort that users get from having a standalone, known to work executible installed on their own computer. It has the benefit that it will only change when they update the program. And something that worked before won't suddenly stop working when they update "such n such" package with pip.

I haven't created something with electron before so I would highly value your experience. What would you need from me so that you can begin prototyping?

[mlshapiro]

No I should be all set - I may need to ask you a few questions about architecture as we go, but I will open a separate issue/feature request for the development

[SimonBiggs]

Sounds good.

…

On Thu., 16 Aug. 2018, 3:14 am Marc Shapiro, ***@***.***> wrote: No I should be all set - I may need to ask you a few questions about architecture as we go, but I will open a separate issue/feature request for the development — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#222 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGQVexPb5etKYmt_F7AijiSGElO89ABYks5uRFcNgaJpZM4TIDIE> .