Skip to content
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

Qt #20

Open
jamesdbrock opened this issue Sep 16, 2023 · 3 comments
Open

Qt #20

jamesdbrock opened this issue Sep 16, 2023 · 3 comments

Comments

@jamesdbrock
Copy link

jamesdbrock commented Sep 16, 2023

Like many other people, I want to write good-looking apps with React-style (Model-View-Update, The Elm Architecture) in 100% Python.

Congratulations on implementing Hooks in Python; I believe you’re the first person to do that.

https://maartenbreddels.medium.com/advance-your-ipywidget-app-development-with-reacton-6734a5607d69

Once a common library for rendering/reconciliation exists, the same procedure can be repeated for Qt

It sure would be nice if we could write PySide6 apps with Reacton. Here’s an issue for talking about that.

@maartenbreddels
Copy link
Contributor

Hi @jamesdbrock,

Good to hear you like Reacton, and declerative UI's. I have explored Qt support a while ago, and I actually managed to get that working.
Would you be interested in that?
I could open a draft PR, so you can see what I looks like.
I see https://github.com/pyedifice/pyedifice uses the classes based approach, while Reacton uses the function style, any strong reasons for 1 vs the other?

Regards,

Maarten

@jamesdbrock
Copy link
Author

I have explored Qt support a while ago, and I actually managed to get that working. Would you be interested in that?

Yes please! But is it realistic for Reacton to support both iPyWidgets and PySide6? Are you going to end up limiting Reacton to the common feature set of each? I've surveyed all these half-finished Python declarative GUI projects and it seems like a common theme is trying to abstract over multiple backends.

I see https://github.com/pyedifice/pyedifice uses the classes based approach, while Reacton uses the function style, any strong reasons for 1 vs the other?

Historical reasons. @fding wrote Edifice in 2021, when functional-style React Hooks was still new. I think he used the class-based approach because it was established and well-understood. Edifice also has a make_component function decorator, but without Hooks it’s not very useful.

I, personally, strongly prefer pure functional programming for everything.

@maartenbreddels
Copy link
Contributor

Dear James,

Checkout out #21 for the POC.
As you can see there is nothing that needs to be changed in core.py (well, that first commit is unrelated to this PR, it might be the fix for #14). So we didn't really need to abstract over multiple backends, it kinda came out naturally.

I currently don't have much interest in supporting Qt myself, nor do we (Widgetti) have the bandwidth right now.
We could be interested in a Reacton-qt build on top of Reacton since that would give extra eyes on it. I would say Reacton is pretty solid right now, and the test coverage is quite extensive.
There is a little bit of technical dept, and possible could use a performance review, which would benetit both the widget and the qt backend.
If these are things you would be interested in, I could see a fruitful collabaration.

I would be less interested in adding many more features in Reacton, or doing unneeded refactors that could potentially change behaviour. Since Reacton is the foundation of Solara, we are conservative about making changes.

Let me know what you think.

Regards,

Maarten

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants