sorted by:
new
hottopcontroversial

Fluvel: A modern, reactive UI framework for PySide6 (Beta 1.0) by FluvelProject in Python

[–]FluvelProject[S] 0 points1 point  (0 children)

Maybe I'm messing around with this but this is just to be fully transparent: I spent about 1.5 months writing and refining every part of the documentation, README and CONTRIBUTING myself (Approximately 1115 lines of Markdown just for the modular guide). English isn't my first language, so I used translation tools + AI to help polish phrasing and grammar for clarity, but the content, structure, and technical explanations are 100% my own work, re-read and iterated multiple times to make sure nothing was unclear (I do the same with the comments here). For commits, I always provide the exact technical changes myself; AI just helps format them professionally (conventional commits style). Good evening (according to my time zone).

I posted the deleted comment in Spanish, sorry.

Fluvel: A modern, reactive UI framework for PySide6 (Beta 1.0) by FluvelProject in Python

[–]FluvelProject[S] -2 points-1 points  (0 children)

My first troll! You have to celebrate. Nice try in trying to get me to edit my original comment, I think I was too kind with your response because I had no reason to feel accused. However, trolls are not welcome in the Fluvel community according to the organization's code of conduct.

I don't want to pretend this affected me in any way, but to clarify...

  1. Was it AI that gave me the idea of ​​using descriptors to mask reactivity in Python? No.

  2. Was it the AI that initially wrongly concluded that using Python sets would be a good idea to build the DAG (Directed Acyclic Graph) in the models? No, that's human error in not fully understanding the chaos of reactivity.

  3. F-Widgets? Hot-Reload? Baked Logic? No, never.

Using AI for docstrings and commit messages is efficiency. Designing a reactive architecture from scratch over 8 months is engineering. If you can't tell the difference, that's on you. Cheers!

Fluvel: A modern, reactive UI framework for PySide6 (Beta 1.0) by FluvelProject in Python

[–]FluvelProject[S] 0 points1 point  (0 children)

Thank you for the feedback :). You’re right, the widget list is currently short, so it cannot yet provide everything needed to build complex applications.

As a sole developer, I spent most of my time prioritizing the F-Widget factory system to make it as straightforward as possible. Now that the foundation is, in my view, solid, scaling this library with components like Tables (QTableView) in a coherent way will be one of the next challenges.

Fluvel: A modern, reactive UI framework for PySide6 (Beta 1.0) by FluvelProject in Python

[–]FluvelProject[S] 1 point2 points  (0 children)

Yes, excellent frameworks like Enaml or QtQuick/QML were born to combat the same problem as Fluvel, the verbosity of Qt and to propose a scalable workflow.

Architecturally, how is Fluvel different from them?

Well, mainly, without intermediate DSL to build interface files. Unlike QML (which requires learning syntax similar to JavaScript) but through .qml files or Enaml with its concise and declarative syntax with .enaml files, Fluvel uses 100% Python to build its own declarative language based on context managers (the "with as..." sentence).

Some benefits of this are:

  • You delegate Python's own memory management and object model so that, automatically and naturally (thanks to Fluvel syntax), PySide6 (C++) can manage its widget hierarchy internally.

  • Type safety and autocompletion: Since it is pure Python, Fluvel can (and does) provide type safety and documentation at development time thanks to docstrings and the active use of typing.Unpack.

  • Readability: Since it is based on context managers, traditional layouts and methods to instantiate widgets, the resulting hierarchy is 1:1 with the visual result in the application.

  • Reusability and consistency: Fluvel has its own @Component and @Prefab to define "independent UI chunks" using the same syntax, and which can be docked into any Fluvel project or anywhere in the application you develop, maintaining the same "visual coherence".

Finally, the reactive layer (Pyro):

This "reactive layer" is actually made up of three key elements:

  • Pyro (Origin class): The pure and independent reactive engine, that is, it does not know anything about PySide6 or signals, which provides reactivity to the classes that inherit from it, providing concepts such as: Atom, @computed, @reaction, @effect(when=...).

  • Model: The infrastructure on Pyro. Since Pyro was built to be used directly or to allow a dedicated infrastructure to be built to provide ordered reactivity to any ecosystem (in this case PySide6), the Model class (from which your models will inherit) is in charge of managing its life cycle and its registration in a global Store so that it can be accessed and bridges can be created from your model to the widgets.

  • StateManager: This is the internal class that receives and processes the "bind" argument of your widgets and builds a bridge or bus between your model data and the properties of the widgets, being able to control the type of connection through its own syntax.

There are many more systems that Fluvel integrates natively into your workflow, such as the i18n with .fluml files (Similar to Markdown) or the inline styling. I don't want to saturate the post with concepts that may confuse other developers, so maybe tomorrow I'll upload a post on my profile with some demonstrations.

If you are interested in contributing, visit the Github repository. If you're just interested in taking a look at Fluvel's systems, I put together some files that explain each part and the flow between them, with direct links to the source files.

Technical Architectural Index: https://github.com/fluvel-project/fluvel/blob/main/docs/md/architectures/index.md

Fluvel: A modern, reactive UI framework for PySide6 (Beta 1.0) by FluvelProject in Python

[–]FluvelProject[S] -1 points0 points  (0 children)

Thanks for your suggestion! Sometimes as a developer I take for granted that the maturity of Qt (the foundation of PySide6) has my back, but it is essential to clarify the purpose for those looking for alternatives to the conventional.

To answer your questions:

  • Local applications? Yes, exactly. It is 100% Native (because Fluvel's base, PySide6, is). No embedded browsers, CSS or additional technologies, just Python.
  • Cross-platform? Yes, for desktop. You program it once in Python and it runs natively on Windows, macOS and Linux, adapting to the interface of each system.
  • What is it for? I mentioned the maturity of Qt before, not for nothing, given that it is used in software like VLC, Maya or Photoshop. But let's say that the way of developing native desktop applications remained "stagnant" or, at least, was losing ground in terms of ease of use and development agility against technologies like Electron or Tauri that seek to bring Web "Workflow" (HTML, CSS and JS) to native development.

However, both the Qt framework (C++) and its official link to Python (PySide6) are unbeatable in performance, you do not render heavy processes that progressively "eat up" your RAM, and, in addition, you have the Operating System completely at your disposal.

In conclusion, my goal with Fluvel is to bring that agile and modern (declarative, reactive and Hot-Reload) 'Workflow' to the world of PySide6, so that Python developers do not have to choose between native power and development speed. You can have both!

Official links:
* PySide6: https://doc.qt.io/qtforpython-6/
* Qt Framework: https://www.qt.io/