webview.start() function

I propose an alternative way to start a webview application

webview.start(title, html, css='', script='', js_api=None, options={})

would start a webview window with the given title and html. Optionally separate CSS and JS can be supplied as parameters (or embedded into the html). options would be a new dictionary with window specific options of create_window. start would be a single window blocking function, subsequent windows shall be opened using create_window.

All the building blocks are already in place, so the implementation should pose no challenges.

Comments are welcomed.

[shivaprsd]

Agreed. What I suggest is to merge the base_uri and transform_url functions into one; The later already does the protocol check, the former properly adds the path. The new function can be used by both create_window and load_html.

But about start it has occurred to me that this is in fact the best time for such a drastic change! What, other than a major release like 2.0, can be the best place to put it? 3.0 would be too late. I know, I said it, it’d be work. But I don’t think it would complicate the API; instead simplify it, if we do it properly. Here’s my idea:

• GUI libraries want to run on the main thread. Fine. We’ll makecreate_window open windows only if we’re running; if we’re not running, we will postpone the call till start. I am imagining a global stack to which create_window pushes the ‘calls’ (store the window-specs) and start would execute one by one.
• Obviously, start would not take any arguments. It would return nothing also. It has to be called from the main thread and it will block. All create_window calls, before or after start, will not block, but return the uid of the window.
• API calls work the same way as before. They wait for _webview_ready.
• Only start will _initialize_imports.

Now what all this means for the single-window app maker is just an extra call to start after their usual create_window:

import webview

if __name__ == '__main__':
    webview.create_window('Simple browser', 'http://www.flowrl.com')
    webview.start()

It would in no way complicate the API! It complicates our lives, of course. 🙃 I say do it now before the core code gets messier. I dare give it at least a try before 2.0. Another (not so attractive) option is to release a 1.9 with what we have now, and 2.0 later, with the task list mentioned in #197 including start.

[shivaprsd]

Now that’s much better, the two initial suggestions seemed far-fetched. But now how does start differ anyway from create_window? If we don’t want any options, both syntaxes are the same, which kind of defeats the purpose of introducing start, right?

Before this issue was opened, I had envisioned a start function but with a different objective: to actually start the application. Like the run function of most web-server frameworks. You can create all the windows you need with create_window and start your app when you’re done. So create_window would never block execution, and return the uids of all windows. To quote:

Do one thing, and do it well.

I had got this idea when I wrote the doc for multiple windows, realising how odd it was with only the initial call to create_window blocking and giving a special uid “master” to it and all that stuff. But I restrained from proposing it as implementing such a model would render us backward-incompatible. It would be also much work. But honestly now, that would have been a better purpose for the start function.