8000 [EPIC] Better Visual Components Proposal · Issue #447 · pyscript/pyscript · GitHub
[go: up one dir, main page]

Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

[EPIC] Better Visual Components Proposal #447

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
1 of 4 tasks
fpliger opened this issue May 22, 2022 · 3 comments
Closed
1 of 4 tasks

[EPIC] Better Visual Components Proposal #447

fpliger opened this issue May 22, 2022 · 3 comments
Labels
epic a highlevel collection of smaller related issues tag: component Related to PyScript components tag: styling Related to the styling of pyscript components type: feature New feature or request

Comments

@fpliger
Copy link
Contributor
fpliger commented May 22, 2022

This is an umbrella issue to collect the tasks needed to re-design a more solid and flexible presentation design for all the visual components:

  • Replace Tailwind with a pure CSS solution
  • Propose a design that allows dynamic theming of the visual elements. Ideally, this could/should be a non PyScript specific design that can play well in supporting translation between PyScript and other frameworks that generate UI (i.e., Toga?). This discussion can eventually be part of the discussions in [DISCUSSION] Dynamic loading style (CSS) and theming support #340 or we can open a new issue for the actual implementation task
  • Implement dynamic CSS and theming support : One important aspect of this (that probably should be explicit in the design work proposed in the item above, is that dynamic CSS/theming should still allow users to define local small style changes to components (i.e., changing background color, font color, etc...). Basically allowing a baseline theme for PyScript (that can be reused by many apps) and additional style to be used by the app itself.

Related Issues:

@fpliger fpliger added type: feature New feature or request tag: styling Related to the styling of pyscript components tag: component Related to PyScript components labels May 22, 2022
@freakboy3742
Copy link
Contributor

There isn't really an opportunity to "share themes" with Toga - but the reason why may be illustrative for PyScript's theming approach.

Toga deliberately does not support themes - the core look and feel of an app is entirely determined by the platform. On iOS, buttons don't have borders, and match the background color; on macOS, they're gray, and have a slightly rounded borders; and so on. This is very deliberately not opened to the end user to control; if you don't like the look a 8000 nd feel of the widgets on your platform, take that up with your operating system vendor, or pick a different platform :-)

Toga does have the ability to modify the appearance of some widgets for "functional" purposes - e.g., you can say "I want this button to be red, because it's an Emergency stop" button. The mechanism it uses to do that is effectively CSS (technically, it's a CSS-like language subset called Pack, but the long game is to use an actual CSS implementation). This means you end up writing code like:

 toga.Button("Emergency Stop", style=Pack(background_color='red'))

You can't change the fundamental appearance of a button/selection/table though. The only stylistic elements that are exposed are relatively simple color/background/font styles, and are very explicitly exposed on a per-widget basis; just because you define a color style on a widget, doesn't mean the color will change - either because the widget or the platform defines that the color isn't user-modifiable.

IMHO, there is a analog to what PyScript could/should aim for. The web doesn't have a consistent look and feel for apps - but PyScript is in a position to provide a single stylesheet that defines the "PyScript look and feel". That appearance won't be to everyone's taste, but you can stake out what a PyScript looks like by default.

There are then 2 distinct modes of extension:

  1. Specific style elements can be exposed on specific widgets, such as the background color of a button. This could be in the down with specific widget attributes (e.g., <py-button background-color='red'>), or by using CSS styles (i.e., <py-button style="background-color: red">) and defining how the CSS styles will be mapped to the DOM elements that actually render the button. Not all CSS styles would be automatically recognised on widgets.
  2. The overall requirements of a PyScript "theme" can be documented, so others could replace (or augment) the default PyScript theme with a custom theme. This would effectively mean documenting the internals of how each widget is rendered (and maybe providing a testbed) so that theme writers can easily apply whatever stylistic approach they want.

(1) is what Toga provides on a per-widget basis. To my mind, this part isn't "theming" - its defining functional requirements of a specific widget in the context of an app.

Implementing (2) in Toga isn't possible, because it would mean overriding the default platform look and feel; but PyScript doesn't have that constraint because of the lack of a "default" look and feel for the web.

Another, partially related area where there is potential overlap with Toga is in establishing consistent terminology. If we agree that a "thing you click on to make an action happen" is called a "Button", it has an "on_press" handler that is triggered when it is pressed, and exposes the background color as something that can be customised, then the APIs exposed by Toga and PyScript will be very similar, and the cognitive overhead of turning a GUI written in PyScript into a native app with Toga will be lower.

@MarcSkovMadsen
Copy link
MarcSkovMadsen commented Jun 8, 2022

One thing to consider is also how the css will if integrated in other environments. I'm a contributor to Panel and for Panel using something like Bootstrap is not a great idea because it has a tendency to interfer with the css in jupyter. For my use cases I'm also thinking how things work inside VS Code in an interactive environment.

For that reason I've always be looking to web components like fast.design, shoelace or wiredjs as they don't have problems being integrated with other design systems/ css frameworks.

When I saw you used tailwindcss for PyScript I thought "oh no" as I believe you are developing something general and users would like to be able to select their own design system. I don't think you should be building something opinionated. Let others rebuild Streamlit, Panel or what ever on top of PyScript using their preferred design system.

Thumbs up for PyScript. Great work.

@fpliger
Copy link
Contributor Author
fpliger commented Jun 16, 2022

@MarcSkovMadsen thanks. Great point.

Tailwind was an experiment to have something "quick and dirty"... but yeah, PyScript should be less invasive.

@fpliger fpliger added the epic a highlevel collection of smaller related issues label Jun 27, 2022
@marimeireles marimeireles 7D12 added epic a highlevel collection of smaller related issues and removed epic a highlevel collection of smaller related issues labels Jun 27, 2022
@pyscript pyscript locked and limited conversation to collaborators Feb 12, 2023
@marimeireles marimeireles converted this issue into discussion #1178 Feb 12, 2023
@tedpatrick tedpatrick moved this to Closed in PyScript OSS Apr 3, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
epic a highlevel collection of smaller related issues tag: component Related to PyScript components tag: styling Related to the styling of pyscript components type: feature New feature or request
Projects
Archived in project
Development

No branches or pull requests

4 participants
0