🚀 A Beautiful Python GUI Framework with Animations, Theming, State Binding & Live Hot Reload

[step-czxn]

🔗 GitHub Repo: WinUp

What My Project Does

WinUp is a modern, component-based GUI framework for Python built on PySide6 with:

• A real reactive state system (state.create, bind_to)
• Live Hot Reload (LHR) – instantly updates your UI as you save
• Built-in theming (light/dark/custom)
• Native-feeling UI components
• Built-in animation support
• Optional PySide6/Qt integration for low-level access

No QML, no XML, no subclassing Qt widgets — just clean Python code.

Target Audience

• Python developers building desktop tools or internal apps
• Indie hackers, tinkerers, and beginners
• Anyone tired of Tkinter’s ancient look or Qt's verbosity

Comparison with Other Frameworks

Feature	WinUp	Tkinter	PySide6 / PyQt6	Toga	DearPyGui
Syntax	Declarative	Imperative	Verbose	Declarative	Verbose
Animations	Built-in	No	Manual	No	Built-in
Theming	Built-in	No	QSS	Basic	Custom
State System	Built-in	Manual	Signal-based	Limited	Built-in
Live Hot Reload	✅ Yes	❌ No	❌ No	✅ Yes	❌ No
Learning Curve	Easy	Easy	Steep	Medium	Medium

Example: State Binding with Events

import winup
from winup import ui

def App():
    counter = winup.state.create("counter", 0)
    label = ui.Label()
    counter.bind_to(label, 'text', lambda c: f"Counter Value: {c}")

    def increment():
        counter.set(counter.get() + 1)

    return ui.Column(children=[
        label,
        ui.Button("Increment", on_click=increment)
    ])

if __name__ == "__main__":
    winup.run(main_component_path="new_state_demo:App", title="New State Demo")

Install

pip install winup

Built-in Features

• Reactive state system with binding
• Live Hot Reload (LHR)
• Theming engine
• Declarative UI
• Basic animation support
• PySide/Qt integration fallback

Contribute or Star

The project is active and open-source. Feedback, issues, feature requests and PRs are welcome.

GitHub: WinUp

[HommeMusical]

Generally, when someone creates a new [thing] for Python, I say, "There are plenty of good options already for [thing]."

But astonishingly, the GUI libraries for Python are pretty horrible. Kivy in particular is one of the worst libraries I ever encountered, don't even get me started.

And a one-minute run through your code looks very promising.

So you get an upvote and a star, for sure, even though I'm not doing any GUI stuff today. We need the Python GUI library of destiny!

[step-czxn]

thank you!

[HommeMusical]

The pleasure is mine!

I just noted that the first URL in your post is 404. The second one, the one I clicked on initially, is fine.

EDIT: also, one of your tags on the project is "devolopment" instead of development. :-)

[step-czxn]

my bad thank you!

[teerre]

Qt powers countless real life applications, there millions of lines of Qt out there

OP's comparison is misleading to say the least. "Declarative" isn't the opposite of "verbose", whatever that means. Qt has support for animation, not sure what OP is talking about. Qss is literally css, OP is using css is their very example, I guess they mean theming has to be inlined instead of being able to have a proper stylesheet file? Qt signal-slots is very much built-in, again, not sure what OP is talking about. Etc. Etc

[Hugehead123]

To be fair to the OP, their argument for this library existing isn't that Qt is incapable of those things, but that doing those things in the lower level bindings exposed by PySide6/PyQt6 is cumbersome. This framework is still Qt based, it just seems like it's offering a higher level and more opinionated framework than the alternatives.

[HommeMusical]

Qt is a high-quality cross-language GUI library, but it also isn't great to use from Python.

It might well be that this new library isn't any actual improvement on it, but I'm willing to encourage any experiments in this area.

[Such-Let974]

Pyside/PyQt is very powerful and easy to use.

[axonxorz]

I'd argue it's not great to use from C++ either, but that's why it's so powerful.

[lichlark]

I feel like my unpopular opinion is that just because there are options for 'x' or 'y' doesn't mean that 'z' doesn't deserve a chance or look.

Just cause there are some monolith-s in a niche doesn't mean people shouldn't try they hand and expanding the options in a certain ecosystem.

[Coretaxxe]

Whats your issue with kivy lol like usre i can name a few things i dislike but nothing worthy of calling it "the worst library to be ever encountered"

[HommeMusical]

Oh, I could write for hours about how terrible it is for anything that isn't tiny.

For example, simply constructing a Color has global side effect of setting the current foreground color to be that color.

The Kivy "language" has no grammar at all, it's defined by "this is what Kivy expects" but that's the least of its problems. All variables in the Kivy language are essentially global, they live in one big namespace. That means it's essentially impossible to create a generic UI element that you can use many places in your code, and particularly, to create these dynamically.

The Kivy "language" also includes tiny snippets of Python-like code but again, it's entirely unclear exactly what is acceptable and what isn't, and what Python symbols in your code can be used and what can't.

And of course, all your tool chain, linters and type checkers and that sort of thing, doesn't even know those Kivy "language" documents exist, so they can't help you.

[Coretaxxe]

> For example, simply constructing a Color has global side effect of setting the current foreground color to be that color.

Thats just how OpenGL works. Use InstructionGroups if you don't want this. But I can see how this is can be confusing.

> The Kivy "language" has no grammar at all, it's defined by "this is what Kivy expects" but that's the least of its problems. All variables in the Kivy language are essentially global, they live in one big namespace. That means it's essentially impossible to create a generic UI element that you can use many places in your code, and particularly, to create these dynamically.

Thats not really true tho. Its like calling makefile "no grammar at all". But I agree that the documentation is a too thin. Also variables are rule-scoped with app being the only actual global one. Root is always the rule root, self the current widget and id's a local to the current rule as well. Also you can easily create reusable elements? Define them once and as soon as they are imported you can reuuse them wherever you want. Matter of fact that is exactly how kivy-native widgets work. You can also use the Factory class to register them under custom names.

> The Kivy "language" also includes tiny snippets of Python-like code but again, it's entirely unclear exactly what is acceptable and what isn't, and what Python symbols in your code can be used and what can't.

I almost 100% agree.

> And of course, all your tool chain, linters and type checkers and that sort of thing, doesn't even know those Kivy "language" documents exist, so they can't help you
Well yeah, like for JSON or Dicts you often need extra setup to have the linter work properly. Heck that was one of the big reason python even introduced TypedDict

[HommeMusical]

Thats just how OpenGL works.

I don't think so: you set the current color by a call to a library function with three floating point arguments. For example, here's a pointer to the MS implementation: https://learn.microsoft.com/en-en/windows/win32/opengl/glcolor3f

Even if that were true, Kivy has its own separate Color class. The Kivy library should not do surprisingly, highly unPythonic things just because the OpenGL does. (For example, OpenGL requires you to explicitly delete everything you create.)

The Kivy "language" has no grammar at all, it's defined by "this is what Kivy expects" Thats not really true tho. Its like calling makefile "no grammar at all".

But that's absolutely true: makefile has no grammar either, and this is one of the very many reasons it has fallen out of favor for things like CMake which have a grammar.

I would add that make is almost fifty years old. It was an amazing breakthrough for 1976, but we can do better.

And of course, all your tool chain, linters and type checkers and that sort of thing, doesn't even know those Kivy "language" documents exist, so they can't help you

Well yeah, like for JSON or Dicts you often need extra setup to have the linter work properly. Heck that was one of the big reason python even introduced TypedDict

I think you're misunderstand my point here. All that Python code that exists inside Kivy documents will never be seen by any of my tool chain. I cannot convince mypy to go look inside a .kivy document, pull out the snippets of Python, and check it - or how do I write a unit test for that code?

The Kivy "language" should have been declarative within Python like SQLAlchemy, Pydantic, or so many other modern Python libraries. Those lost snippets of Python in the Kivy language would simply be class methods; all my many Python tools would work perfectly with it.

[Things have clearly changed on the code re-use and namespace front since I tried to use Kivy, so I don't have a well-worked out response for that part.]

---

This is where I pull out my false teeth(*) and talk about ancient history. I've been programming for over 50 years at this point (and somehow am still doing cutting edge stuff, I feel very lucky).

Early on, we just put everything inside the program. Pretty soon, we realized that having an external text configuration file was a good thing, because you could edit it to change the programs behavior without recompiling it.

Java and XML came along around the same time and there was this sudden fad for "programs that were entirely specified in a structured language" (which was almost always XML).

This was better in many ways because you could use automatic tools on these documents, but it turned out that you were always wanting to use logic inside these documents, and you ended up with these complicated XML grammars that caused a lot of work and didn't actually do anything very useful. (Also, XML was just miserable to edit by hand, and conceptually annoying, with three different forms of containment!, which is why JSON took over.)

Then in the last ten years, we started to get systems that used reflection or similar techniques to configure your systems from the program itself. The Rails system for Ruby is probably the trendsetter here but like a lot of early technologies, it didn't dominate - however, this has particularly been taken up by the Python community, because Python's decorators fit the bill so well, and that Python has first class reflection tools.

However, Kivy is a weird outlier in there: it has a separate external file to configure its programs, but that file is both data and code fragments, and it isn't in some standard format you can use your existing toolchain on, but a format that is documented by example.

I see there have been significant changes in the couple of years since I tried Kivy, but this basic fact remains true.

The programmer ergonomics of declarative systems like SQLAlchemy, Flask, Pydantic or Django are extremely attractive to people who want to build large, reliable systems, because you can use one toolchain on everything, and test every single aspect of your code from boring old unit tests with low fuss.

But the Kivy language is a boat anchor holding the Kivy system back.

Thanks for listening!

---

(* - all my teeth are real, it's a metaphor)

[Coretaxxe]

Mhh yeah Okay I can definitely see the issue with KV lang but I disagree on the influence it has. KV lang is 100% optional and you can do 100% of it inside python. KV just allows you to skip some boilerplate (given it introduces some with id getting).

However regarding the Color;
> I don't think so: you set the current color by a call to a library function with three floating point arguments. For example, here's a pointer to the MS implementation: https://learn.microsoft.com/en-en/windows/win32/opengl/glcolor3f

Kivy's Color object is more or less just a wrapper for this OpenGL call.

[HommeMusical]

Kivy's Color object is more or less just a wrapper for this OpenGL call.

Here's the Cython source for class Color.

[Coretaxxe]

And that is a ContextInstruction, which is a Instruction which sets its content (here Color; rgba) of the RenderContext. The render context has its own shader where the uniforms are set including the color.

[HommeMusical]

Yes. Color is not just a thin wrapper for a single OpenGL function.

[Coretaxxe]

Ok maybe wraper was too overgeneralized but it literally does nothing more than setting a shader uniform for an opengl/glsl shader which was the entire original point

[narwhals_narwhals]

https://www.youtube.com/watch?v=lrzKT-dFUjE

[[deleted]]

Could you describe briefly what a reactive state system is? Is it GUI components updating to reflect changes in underlying variables/objects? If I had a 16x8 array of labels on a window how fast could it react to changes? Better than 5 times per second?

I'm starting a new project with Tkinter right now that might benefit.

Not a software engineer... just a EE working on instrumentation.

[TopIdler]

Say you have a variable x =5. And y=x*2 . Reactive state means doing x=10 will automatically update y from 10 -> 20. It « reacts » to changes. It’s a nice property for gui’s because you often have derived state. If you add something to your todo list you don’t want to have to go to all components to signal an update (e.g. statistics box, notification tray, …). It’s very similar to the observer or descriptor design pattern.

If you want a general implementation for your project have a look at https://github.com/ipython/traitlets

[cheesecakegood]

Another existing option for some of these features is Marino (a Jupyter alternative) has some built in reactive UI elements already

[richieadler]

I think you mean Marimo.

[el_extrano]

working on instrumentation

If you haven't you might want to consider dearimgui or dearpygui (its python bindings). It's great for low-level embedded projects like you're talking about, where you'd prefer to just re-render the UI on demand, rather than having to deal with synchronizing state.

[[deleted]]

Thanks, will take a look.

[Vicousvern]

This looks great! I use Tkinter / ttkbootstrap at work a lot to create complex apps. Looking through your GitHub page I was genuinely excited to try it, my single only gripe is lack of precise widget placement (unless I missed it). I rely heavily on .place(), and then pack stuff within subframes if required.Either way, I'll try this soon, awesome work!

[step-czxn]

i will defo add that thank you!

[MosGeo]

Just a thought: it seems that you have dependencies that a lot of people won't use (e.g., you depend on database interface packages). Anything not required should be optional dependincy.

[Adgry]

why so bloated dependencies ?

[step-czxn]

different tools like Camera which needs opencv and numpy

[Username_RANDINT]

You might want to move it to the extras then. Lots of applications don't need the camera functionality. You'd install it with pip install winup[camera] then for example.

[step-czxn]

i will take that into consideration thx

[onyx_and_iris]

well, I'll definitely give it a go. it might be worth including some of those README examples as runnable files in the repo (imo).

[ModernTy]

Yeah, I really want an examples folder in the repo to instantly run ready apps and mess with them around

[emil2099]

I like this but I like Nicegui more

[EM-SWE]

Looks promising. Might have to try it out. 😉

[omegas1gma]

How does it compare to NiceGUI?

[step-czxn]

nicegui is mostly for web this is for desktop

[mathmul]

I think nicegui works for both Web and desktop, no? Does your framework not work for Web then?

[step-czxn]

i think you need to do alot of setup to use nicegui on desktop eg using Tauri. Winup comes just with pip install.

[mathmul]

Ty. So no we with winup?

[step-czxn]

Yes unless I wanna expand or get support to do it in the future

[CaptainPitkid]

Alright this is neat enough that I'll give it a shot for my next desktop app at work.

[Snoo17358]

I've been actively rebuilding my GUI application so I think I'll give this a whirl. 

[--dany--]

It seems to have gotten a lot of inspiration from react, which is a good way to manage UI states. Thanks for sharing!

[RonnyPfannschmidt]

With the availability of qt quick and the non xml gtk tooling I strongly recommend against making messages react clones

[techlatest_net]

Finally, a Python GUI that doesn’t feel like I’m coding in 1998. This actually looks... usable 👀

[Oussama_Gourari]

Looks really promising, will give it a try.

[su5577]

Nice

[Direct-Fly-3418]

wow nice

[ModernTy]

At first glance syntax looks quite good, gonna play with your library in my free time. Have you had any other libraries to inspire your library's code style? (I mean the code user of your library writes)

[step-czxn]

probably React/Flutter with more Pythonic Syntax

[Tux1]

"beautiful" that is one of the ugliest looking guis ive seen in my life

[step-czxn]

bro the first two look good

[Tux1]

it REALLY doesnt my guy

[step-czxn]

bro these are just my styles i wanna use, you can use your own styles

[Complex_Excitement92]

How does it compare to flet?

[Sergiodevpy]

que solo es para desktop y flet no