Resurrect the Toga-web backend using Pyscript#1475
Conversation
|
Hi, Is there a plan to move forward (resurrect) with toga-web? I saw the examples in pyscript but did not see roadmap or discussion. |
|
@aeroaks Yes - the web backend is on our todo list; however, in terms of priorities, it's a little lower than solidifying the desktop and mobile platforms. In terms of roadmaps, I wouldn't expect to see big changes from the Toga side unless someone contributes them. |
|
In a way it would work out for me, as I can spend a limited time in contribution. I was thinking of picking up small tasks to e.g., make the tutorials in the Toga documentation work (in a similar way as the tutorials added in the pyscript repo). But for that I would need some alignment how and where to begin. |
mhsmith
left a comment
There was a problem hiding this comment.
I tested using the temperature conversion app and everything worked correctly, except as noted below.
|
|
||
| return width, height | ||
|
|
||
| def __css__(self): |
There was a problem hiding this comment.
I'm curious about the rationale for putting this here rather than in the web backend. Is it because we eventually intend to define the Pack algorithm in terms of CSS (#1544), so it makes sense for both realizations of the algorithm to be in the same file so they can be kept consistent?
There was a problem hiding this comment.
Essentially yes, but I'd phrase it a slightly different way. It's not so much about defining Pack in terms of CSS; it's more a matter of saying that a style engine can define any set of rules you want, but you have to be able to define a mapping to CSS if you want your style engine to be compatible with web deployment.
This implementation of __css__() is specific to Pack, and describes how Pack's style rules map to "pure" CSS; the implementation for Colosseum will be a 1-1 mapping of the literal style declarations. Other style engines could define complete arbitrary rules, as long as they provide an analogous CSS mapping.
The connection with #1544 is more about using CSS as a reliable known reference implementation; the Pack CSS mapping rendered in a browser should provide the same output as a Pack implementation in native widget layout.
| toga.Command( | ||
| None, | ||
| "Preferences", | ||
| group=toga.Group.HELP, |
There was a problem hiding this comment.
Doesn't look as if this is being used anywhere.
There was a problem hiding this comment.
Correct - it's a placeholder that acts as a tease for future functionality (in the hope it will jolt someone into potentially contributing).
| except ModuleNotFoundError: | ||
| # To ensure the code can be imported, provide a js symbol | ||
| # as a fallback | ||
| js = None |
There was a problem hiding this comment.
Running the test suite in CI would be the obvious case. The interface compliance tests are part of the web backend, so we need to be able to import toga_web on non-web platforms.
| [tool.briefcase.app.tutorial.web] | ||
| requires = [ | ||
| '../../src/web', | ||
| ] | ||
| style_framework = "Bootstrap v4.6" |
There was a problem hiding this comment.
None of these will work, because they're all called "tutorial" rather than the actual name of the app.
There was a problem hiding this comment.
🤦 I'm really firing on all cylinders at the moment...
Codecov Report
|
PyScript was announced at PyCon 2022. This provides an easy-to-deploy Python in the browser.
This doesn't implement every widget, but it's enough to get Tutorial 0 and 1 (hello world and the F2C calculator) going, plus the first few stages of the BeeWare tutorial (up until the point
httpxis imported); and the general approach being used should be broadly compatible with other widgets.It pairs well with beeware/briefcase#898 as a means of deploying apps using this backend.
PR Checklist: