I have been using matlab for decades. I am looking to transition to python. I am especailly unsure how to create python GUIs. I have created many GUIs, with various UI elements, and code that runs from UI-triggered events. I want to know if there is a reliable way to create python GUIs. I don't want somehting that might disappear in a year when a single developer stops updating a single project. Please do a thorough research report. In a separte section, do a comarison between matlab and python. The cost and number of toolboxes in matlab are not relevant to my consideration.

ChatGPT said:

To make sure I deliver the most helpful results, could you clarify a few things:

1. What types of UI elements do you commonly use (e.g., buttons, sliders, tables, plots, file pickers)?

2. Do you have a preference between desktop applications vs. web-based UIs (like running in a browser)?

3. Are you interested in a low-code or visual design interface (similar to MATLAB GUIDE or App Designer), or are you comfortable coding the GUI by hand?

This will help me focus the research on GUI frameworks that suit your needs best.

You said:

1 mostly simple- buttons, listboxes (lots of those), tables, text and number edit boxes. The other secondary items are file pickers, plots. 2 desktop is fine. If it can be web-based let me know in a separate section, but the main report is for desktop, in windows. 3 I prefer a visual design interface, it's much faster - I use App designer a lot. I used GUIDE a lot before that. I want a critical evaluation

ChatGPT said:

Thanks for the detailed information. I’ll investigate reliable, actively maintained Python GUI frameworks suitable for building desktop applications on Windows, especially those offering visual design tools and supporting common UI elements like buttons, listboxes, tables, text/number inputs, file pickers, and plots.

I’ll also include a separate section on web-based options for comparison, and a dedicated comparison section between MATLAB and Python GUI development (excluding cost/toolbox considerations).

I’ll let you know as soon as the report is ready.

Research completed in 5m · 23 sources

Evaluation of Reliable Python GUI Frameworks for MATLAB User Transition

Evaluating Python GUI Frameworks for Transitioning from MATLAB App Designer

Introduction

MATLAB’s App Designer provides an integrated drag-and-drop GUI builder with a rich set of components for building desktop apps. When moving to Python, users seek similar capabilities – buttons, multi-select listboxes, tables, text/numeric inputs, file pickers, plots, etc. – and an event-driven architecture. This report surveys actively maintained Python GUI frameworks suitable for desktop applications (Windows focus) that could serve as alternatives to MATLAB App Designer. Each option is evaluated in terms of maturity, maintenance status, documentation, ease of use, availability of visual design tools, and community adoption. We then highlight which tools appear most reliable for long-term use (avoiding single-maintainer or unstable projects). A separate section briefly discusses web-based UI options in Python for awareness. Finally, we provide a comparison between MATLAB GUI development and Python GUI development for experienced App Designer users (focusing on workflow and technical differences, not cost or licensing).

Key Python GUI Frameworks for Desktop Applications

PyQt / PySide (Qt for Python)

Maturity & Maintenance: PyQt (by Riverbank Computing) and PySide (official Qt for Python) are bindings for the Qt framework, one of the most mature GUI toolkits. PyQt has been available since 1998 and PySide since 2009pythonguis.com

. Both are actively maintained to support the latest Qt 6. Qt itself is backed by the Qt Company and an open-source community, ensuring ongoing development. Being backed by a commercial project, Qt for Python benefits from professional maintenance and a large user basepythonguis.com

.

Documentation & Community: Qt’s documentation is comprehensive, and Python-specific docs (for PyQt5/6 and PySide2/6) are well-maintained. There are numerous books, tutorials, and examples. In fact, PyQt/PySide is widely regarded as the best-documented Python GUI optionmedium.com

pythonguis.com

. The community is large – many developers in scientific, engineering, and commercial domains use PyQt/PySide, so finding help or examples is easy.

Features & Ease of Use: Qt is a full application development framework, offering not just basic widgets but also advanced components: e.g. MVC-based tables and list views, model frameworks, built-in dialogs (file pickers, color pickers), multimedia playback, OpenGL integration, web embedding, and morepythonguis.com

. Virtually any UI control needed – buttons, multi-select list boxes, trees/tables, text areas, numeric spin boxes, file dialogs – is included. Plots can be embedded via libraries like Matplotlib (using Qt’s canvas) or specialized tools like PyQtGraph. Qt uses a signal-and-slot event model, which experienced MATLAB users can equate to callback functions (with added flexibility). While Qt’s breadth means a learning curve, it “is not really any more complex [than others] for smaller projects”pythonguis.com

. Many users report that once you grasp the basics, building applications with Qt becomes straightforward. For building “commercial-quality” applications, PyQt/PySide is often recommended as the best all-rounder despite the initial learning investmentpythonguis.com

.

Visual Design Tool: A major advantage for MATLAB switchers is Qt’s drag-and-drop GUI designer. The Qt framework provides Qt Designer / Qt Creator (a WYSIWYG editor) for designing interfaces visuallypythonguis.com

. Developers can place widgets on forms, set properties, and then either load the .ui design file in Python or convert it to Python code. This is very similar in spirit to MATLAB’s App Designer. As one user notes, “Qt is easy with QtDesigner – you can easily skip the actual GUI coding and focus on core programming. Linking with code is easy as well.”reddit.com

. This lowers the barrier for those who prefer visual layout over writing geometry managers in code.

Community Adoption: PyQt/PySide has broad adoption in industries (for engineering tools, data analysis apps, etc.) and open source projects. The support and large community make it a reliable choice for the long term. In summary, PyQt/PySide (Qt) is a feature-rich, actively maintained toolkit that can create modern, native-looking applications on Windows (and Mac/Linux)pythonguis.com

. It stands out as a “batteries-included” solution and the best all-rounder for desktop Python GUIspythonguis.com

pythonguis.com

. Recommended for robust, long-term projects.

Tkinter (Standard Library)

Maturity & Maintenance: Tkinter is Python’s de facto standard GUI library (in the standard library). It’s a wrapper around Tcl/Tk GUI toolkit which has existed since the 1990s. Tkinter is bundled with Python, so it’s universally available and does not require additional installationdocs.python.org

. While Tkinter itself doesn’t see revolutionary new features (Tcl/Tk is mature), it is maintained as part of Python – e.g., Python ships with Tcl/Tk 8.6 which includes the modern theming support (ttk)docs.python.org

. This stability means Tkinter will remain available and working in future Python releases, but it also implies a slower evolution of new widgets.

Documentation & Community: Being so old and widespread, Tkinter has many tutorials and a sizable beginner community. Official Python docs cover the basics, though for deeper aspects one might refer to Tcl/Tk documentation. Compared to Qt, some find Tkinter’s documentation scattered or outdated (much online content references older APIs). Still, for fundamental widgets and usage, plenty of examples exist. The community often recommends Tkinter for newcomers due to its simplicity and zero external dependenciesreddit.com

.

Features & Ease of Use: Tkinter provides all basic widgets needed (buttons, labels, checkboxes, text entry, etc.) and the themed widget set (ttk) adds more modern-looking variants and some extras like progress bars and treeviews. One limitation is that Tkinter’s default listbox supports multi-selection, but there is no native table/grid widget – instead one uses the ttk.Treeview widget to create tabular displays. File dialogs and other common dialogs are available via modules like tkinter.filedialog. Plotting can be done by embedding a Matplotlib canvas (Matplotlib has a TkAgg backend). All of this is doable, but Tkinter is generally better suited for simpler GUIs. It has a procedural flavor (though it can be used in OOP style) and a single-threaded event loop that is straightforward.

Ease of learning: For simple tasks, Tkinter is often praised as easy to start with – you can get a basic window with a button in just a few lines. One Reddit user writes that they “choose tkinter because it’s faster to implement [for a quick GUI], but it will always look dated”reddit.com

. Indeed, Tkinter GUIs by default have an older look-and-feel (unless styled with ttk themes). Layout management in Tkinter (using pack/grid/place) can be less intuitive than a drag-drop designer for newcomers, but for basic layouts it’s manageable. As applications grow, organizing code and troubleshooting layout can become challenging, which is where more robust frameworks might shine.

Visual Design Tool: Unlike Qt, Tkinter has no official GUI builder bundled. However, third-party tools exist. Notably, PAGE (Python Automatic GUI Generator) is a drag-and-drop builder that generates Tkinter code, with a Visual Basic-like interfacewiki.python.org

. Another is Pygubu, which lets you graphically design UIs and save as an XML (ui) definition that the pygubu library can load at runtimewiki.python.org

. These tools can be helpful but are less polished and less maintained than Qt Designer (PAGE was last updated in 2022wiki.python.org

). In practice, many Python developers simply hand-code Tkinter GUIs due to their moderate complexity.

Community Adoption: Tkinter is widely used for small utilities, education, and by hobbyists given its easy availability. It’s considered reliable (nearly bug-free) for what it offers, but not as powerful or modern as alternativesreddit.com

reddit.com

. Some advanced features common in other frameworks (e.g. rich tables, complex dialogs) might need extra work or external libraries in Tkinter. Long-term, Tkinter’s guarantee is that it will always be there as long as Python is – a form of stability – but it likely won’t gain major new features. For simple to moderately complex desktop apps, Tkinter is a safe, if somewhat dated, choice. For more complex, polished applications, developers often outgrow it and move to Qt or others.

wxPython (wxWidgets for Python)

Maturity & Maintenance: wxPython is a wrapper for the C++ wxWidgets toolkit, which has been around since 1992. wxPython itself first debuted in 1998pythonguis.com

. A major reboot (wxPython “Phoenix”) was undertaken to improve and support Python 3 – this project is now the mainline and is actively maintainedpythonguis.com

. Notably, wxWidgets is maintained by a development team and wxPython is closely aligned with that teampythonguis.com

, so it’s not a one-person project. Updates are not rapid but steady; as of recent years, wxPython releases keep pace with new Python versions and OS changes (latest stable versions were updated through 2023). This indicates a fairly stable maintenance trajectory.

Documentation & Community: wxPython has a dedicated but somewhat smaller community. Documentation is decent: the wxPython project provides docs and a demo program showing many widgets. However, much of the documentation refers to wxWidgets (C++ API), so Python users sometimes have to translate from C++ docs. There is an official wiki and an active mailing list/Discord for wxPythonpythonguis.com

. In the past, one downside noted was that wxPython had fewer easily found learning resources compared to, say, Tkinter or PyQtreddit.com

. This has improved with community tutorials, but the learning curve can still be medium.

Features & Ease of Use: wxPython’s appeal is that it uses native GUI controls on each platform (via wxWidgets). This means on Windows, a wxPython app uses the real Win32 controls for buttons, listboxes, etc., yielding a truly native look and feelpythonguis.com

. It supports all the typical widgets and many advanced ones (tree controls, grids for tables, tabbed notebooks, etc.). Multi-selection listboxes and file dialogs are available. wxPython historically had a rich grid widget suitable for displaying tables of data, and it can embed Matplotlib graphs similarly to Qt. The event handling uses an event binder or decorator that is conceptually similar to MATLAB’s callback mechanism (bind events like button clicks to handler functions).

Cross-platform considerations: Because wxWidgets wraps native controls, certain platform-specific quirks can occurpythonguis.com

. For example, a UI might need slight adjustments on macOS vs Windows due to differences in how native controls behave. This is a known trade-off: you get native fidelity, but sometimes less consistency across platforms compared to Qt (which abstracts its own widgets more). For primarily Windows use, this is not a big issue.

Ease of use: Many find wxPython fairly Pythonic and straightforward once set up. It may be a bit more verbose than Tkinter for simple tasks, but far more scalable for bigger apps. One caveat from the past was that wxPython was largely maintained by a single “incredible programmer” and new versions were slow, sometimes requiring code changes on updatesreddit.com

. With Phoenix and a core team, this situation has improved (Phoenix aimed for backward compatibility and modernization). So, wxPython is reasonably stable for long-term use, though not as corporately backed as Qt.

Visual Design Tool: wxPython does not ship an official builder, but there are community GUI designers. wxFormBuilder is a popular open-source WYSIWYG designer that can generate wxPython code or wxWidgets XRC fileswiki.python.org

. Another is wxGlade, a Python-based GUI designer for wxPython (last updated 2020)wiki.python.org

. Using these, one can visually lay out dialogs and windows, then either load the design or subclass the generated code. While these tools exist, they are a bit less polished and less known than Qt Designer. One StackOverflow discussion noted “PyQt comes with a GUI designer... something that does not seem to exist for recent wxPython”reddit.com

, though this was a few years ago. The reality is that such tools for wx do exist (as noted above), but they are not as prominently integrated or maintained as Qt’s.

Community Adoption: wxPython was very popular in the early 2000s (it was even preferred by some Python core developers over Tkinter at one point). Its popularity dipped when wxPython lagged in Python 3 support, but Phoenix revived interest. Today, it remains a solid choice for those who value native look or have legacy code. It might not have the same mindshare as Qt or the simplicity of Tkinter, but it’s considered powerful and fairly reliable. It’s used in projects like the GUI of the ROS robotics platform and some open-source editors. With an active core team and the backing of wxWidgets, wxPython is likely to stay viable long-termpythonguis.com

.

Kivy

Maturity & Maintenance: Kivy is a cross-platform GUI framework released in 2011 (successor to the PyMT project)pythonguis.com

. It is actively maintained by the Kivy organization (a team of developers, not a single maintainer)pythonguis.com

. Kivy is professionally backed and maintained under the MIT licensepythonguis.com

. It’s unique in that it targets not just desktop (Windows, Linux, macOS) but also mobile platforms (Android, iOS) with the same codebase. Over more than a decade, Kivy has grown stable and reached a 2.0+ release, indicating maturity. Regular updates continue, focusing on performance and new widgets (e.g., Kivy 2.2 in 2023).

Documentation & Community: Kivy has good online documentation and an active user community, including a Discord and forums. Being specialized, its community is smaller than Tkinter/Qt, but quite enthusiastic especially for mobile app development in Python. Numerous examples and some books/tutorials exist. The learning curve for Kivy can be moderate because it involves learning some idiomatic approaches (like the Kv design language for layouts). However, the project provides ample guides for these.

Features & Design Approach: Kivy is built with a modern UI paradigm in mind – it uses an OpenGL ES rendering pipeline, meaning all widgets are custom-drawn (not native widgets). This gives Kivy apps a consistent look across platforms (skinned in a modern flat style) and allows advanced graphics (animations, multitouch) easily. It supports the required widgets: buttons, text inputs, sliders, etc., and more complex ones like scrollable lists. Multi-select is supported via specialized list views or selection widgets. For tables, Kivy doesn’t have a traditional grid widget; one would compose a table from layouts or use a RecycleView for scrollable lists of items. Kivy is strongly geared towards touch-friendly UIs, so it’s well-suited if you want a modern touch interface or to also deploy on tablets/phones.

Ease of Use: Python developers find Kivy’s API reasonably clean. You can define interfaces in pure Python or use the Kv language to separate the design. The framework is event-driven (widgets have properties and events you can bind to callback functions). Performance is a focus: Kivy apps use GPU acceleration, making them quite smooth even with animations or large numbers of widgets. One downside: if you need to incorporate existing desktop-oriented libraries (like Matplotlib), it’s possible but a bit involved. For instance, to show a Matplotlib plot, you might use Kivy Garden matplotlib plugin which renders the plot on a texturegroups.google.com

. This works, but it’s not as seamless as embedding in Qt/wx. Kivy’s strength is more in custom visualizations and interactive dashboards built with its own Canvas API.

Visual Design Tool: Kivy lacks an official maintained drag-drop designer. There was a project called Kivy Designer on GitHub, but it has been deprecated and unmaintainedreddit.com

. Some community efforts (like Kivy Studio Designer or third-party tools like LabDeck’s Kivy UI Designerlabdeck.com

) exist, but these are not widely adopted. Most Kivy development is done by writing the KV layout language or Python code manually. This might be a drawback for users who want a visual interface builder similar to App Designer.

Community Adoption: Kivy is popular in domains like mobile apps, multi-touch applications, or GPU-heavy interfaces. For a MATLAB user, if your primary goal is a desktop data analysis app, Kivy might be less of an obvious choice, unless you specifically want a highly custom UI or plan to deploy on mobile. In terms of reliability, Kivy’s multi-platform nature means you can pivot to mobile development (something MATLAB cannot do) and it will likely remain maintained by its team (it’s not reliant on one person, which is a positive for longevity). Overall, Kivy is reliable and well-maintained, but consider it a specialized tool – best if you need its unique features (touch support, custom drawing, mobile) or prefer its design style. For a traditional desktop form-based app with native look, other frameworks might fit better.

Dear PyGui

Maturity & Maintenance: Dear PyGui is a newer entrant (first released around 2020) that takes a very different approach to GUI development. It’s built on the Dear ImGui immediate-mode GUI paradigm. Despite being new, development has been very active and fast in the past few yearsreddit.com

. The library is written in C++ for speed, with Python bindings provided. The maintainers (Hoffstadt et al.) release updates frequently, and the project has gained a following on GitHub. While not as time-tested as Qt/Kivy, its rapid development and growing community indicate it’s being actively maintained for nowreddit.com

.

Documentation & Community: Dear PyGui has detailed documentation (the devs maintain a wiki and examples) and a community on Discord/Reddit. Many users share example GUI scripts since it’s relatively easy to put together interfaces quickly. By design, it’s somewhat niche – commonly used for tools in game development, quick engineering GUI panels, or embedding in other applications. The community, while smaller than the big frameworks, is quite engaged given the project’s novelty.

Features & Approach: Dear PyGui uses an immediate-mode GUI approach: you essentially create UIs by making function calls that draw widgets each frame (internally managed so state persists). This is unlike the retained-mode of others where you instantiate widget objects. The benefit is simplicity in certain scenarios – you can build interfaces dynamically and update them in a loop. It’s very fast (GPU accelerated) and asynchronousreddit.com

, meaning it can handle lots of widgets or frequent updates smoothly. Dear PyGui includes a wide range of controls: buttons, inputs, sliders, tables, tree nodes, etc., and even a plotting widget (wrapping ImPlot) for basic charts. This covers the typical needs (multi-select list can be made with listboxes or tables, text inputs, file dialogs via OS dialogs, etc.). Custom drawings (lines, shapes) are possible too.

Ease of Use: If you’re not familiar with immediate-mode GUI, there is a conceptual shift, but many find Dear PyGui easy to get started withreddit.com

. You do not subclass or layout widgets in containers; instead, you call e.g. dg.add_button("OK") inside a context and handle events in callbacks or by polling widget states. The API is designed to be simple and Pythonic. For someone coming from App Designer, the lack of a visual layout tool and the different paradigm means a learning curve. But building an interface with a handful of controls is arguably easier than with Qt (less boilerplate).

One drawback is that Dear PyGui has no GUI designer – UIs are defined in code. Layout is handled by grouping commands and using things like columns, same-line positioning, etc., or splitting into window sections. This is less structured than using a form designer, but the library’s simplicity somewhat offsets that.

Community Adoption: Many are using Dear PyGui for “back office work, CLI tools, etc.”, essentially internal tools where developers want a quick GUIreddit.com

. Its performance and ease make it suitable for that. For long-term reliability, the project is still young and largely driven by its original authors (a smaller team relative to Qt/Kivy). There’s no large company behind it. However, it being open-source C++ and gaining traction is promising. In summary, Dear PyGui is a cutting-edge approach that is actively maintained and very fast. It can be a good choice if you prefer coding the UI and need high performance and modern looks, but be aware it’s not as battle-tested as the classic toolkits.

BeeWare Toga

Maturity & Maintenance: Toga is part of the BeeWare suite, aiming to allow Python GUI apps with native widgets on all platforms (Win, Mac, Linux, iOS, Android) using one API. This is ambitious, and Toga is still considered early-stage for some platforms. It’s under active development by the BeeWare community, led by Russell Keith-Mageepythonguis.com

. Toga’s first release was around 2017 and it has been steadily improving, but as of 2025 it may not yet have the full maturity of Qt or even Kivy. It is open-source (BSD license) and actively maintained, but primarily by a small group (in fact, much of it by the founder)pythonguis.com

. This raises some concern about bus-factor (a single lead developer), though the project has many contributors at varying levels.

Documentation & Community: BeeWare has extensive documentation and tutorials on their site, and an active community of contributors. However, the user community of Toga is still growing – far fewer production applications use Toga compared to the older frameworks. Questions and support are available via the BeeWare forums/Discord. For someone new, the docs are decent enough to build basic apps.

Features: Toga’s API covers standard widgets (buttons, labels, text boxes, tables, tree views, etc.) and it strives to implement these with native components on each OS. For example, on Windows it uses .NET WinForms or Win32 under the hood, on Mac it uses Cocoa, on Linux GTK, etc., abstracting differences. In principle, this yields truly native look-and-feel and behavior on each platform, which is appealing. In practice, some widgets or platform integrations are incomplete or have minor bugs because each platform’s backend has to be maintained. Basic things like multi-select in tables or list controls should work where the platform supports it, but one should verify if any limitations exist in the current version. Toga does allow displaying plots by integrating with libraries (no built-in plot widget, but one could embed a matplotlib output by drawing it onto a Canvas widget or using a webview). It also provides a Box layout system to arrange widgets.

Ease of Use: Toga’s design is meant to be Pythonic and easy to use. A simple app can be written in a few lines (defining main window and adding widgets). Packaging is made easier with BeeWare’s Briefcase tool, which can bundle the app for distribution (including as a standalone desktop app). This is a plus for deployment. However, Toga currently does not have a visual GUI designer – interfaces are coded. Given it’s still evolving, sometimes you may hit a not-yet-implemented feature or need to dive into the specifics of a platform. It is best for relatively simple UIs at the momentpythonguis.com

pythonguis.com

.

Community Adoption: Toga is promising, but its user base is modest compared to alternatives. It’s a project to watch – it could become very powerful as it matures, but one should be cautious about adopting it for mission-critical projects until it’s more battle-tested. For now, it’s a neat option if you want pure Python with native widgets and are okay working around some rough edges. In terms of reliability, because it’s largely one visionary developer’s project (albeit open source), it’s somewhat riskier long-term than frameworks backed by large communities or companies. Still, BeeWare has been around for years and likely will continue to improve Toga.

PySimpleGUI (Wrapper library)

Maturity & Maintenance: PySimpleGUI is a wrapper framework that was created in 2018 to simplify GUI development by providing a unified interface on top of Tkinter, Qt (PySide2), wxPython, or Remi (web)pythonguis.com

. It gained popularity among beginners for its straightforward syntax. However, PySimpleGUI is no longer actively developed as of 2025 – the original developer has stopped major development on the open-source versionpythonguis.com

. In fact, PySimpleGUI version 5 switched to a paid license model, and while an open-source fork (“FreeSimpleGUI”) exists, the momentum has dwindledpythonguis.com

. This means for new projects, PySimpleGUI is not recommendedpythonguis.com

(the ecosystem is stagnant and future support is uncertain).

Documentation & Community: During its active period, PySimpleGUI had excellent documentation (an official Cookbook and demo programs)pythonguis.com

. A community formed around it (e.g., a active user forum and the project wiki). But with the maintainer stepping back from open source, community support may wane. There is a fork trying to keep it alive, but it’s not clear how comprehensive that will be.

Features & Approach: PySimpleGUI’s appeal was that you could create a window with a few elements in just a couple of lines, without knowing the details of Tkinter or Qt. It would choose a backend (Tkinter by default, which was the most feature-complete backend)pythonguis.com

and create the GUI. It supports all basic controls like buttons, inputs, listboxes, tables (through a simple table element), and can integrate Matplotlib plots in a window. Essentially, it “doesn’t reinvent the wheel but provides a wrapper around other frameworks”pythonguis.com

, so you get the capabilities of the underlying GUI library but with a simplified API. The downside of this abstraction is that you lose access to some advanced features of the underlying toolkitpythonguis.com

.

Ease of Use: For someone transitioning from App Designer, PySimpleGUI might initially seem attractive because it’s very easy to use – no need for a separate designer or complex layout code. The code reads declaratively (you define a layout as a list of elements, then call Window(layout).read() in a loop to handle events). However, it does not provide a drag-and-drop editor; it simply reduces code complexity. Many have created impressive simple apps with it, but as designs grow, the limitations and the one-size-fits-all approach can become an issue.

Maintenance & Longevity: The key concern is that PySimpleGUI’s development status is now questionable. The lead developer’s pivot to a commercial model and the existence of multiple ports (PySimpleGUI for Tkinter vs Qt, etc.) introduced fragmentation. With the original project effectively on hold, relying on it for a long-term project is risky. For completeness: the last fully open version (PySimpleGUI4) is LGPL and can still be used, and the community fork is trying to maintain that, but it’s hard to predict its success. Thus, while PySimpleGUI was a brilliant idea to lower the entry barrier, for a robust future-proof application it fails the “actively maintained” criterion. The official advice in 2025 is to choose a different toolkit (like PySide6) for new projectspythonguis.com

.

PyGObject (GTK+ for Python)

Maturity & Maintenance: PyGObject is the Python binding for GTK, the GUI toolkit of the GNOME project. It is very mature on Linux (GTK has been around since late 90s, used by GIMP etc.). PyGObject is maintained by GNOME developers and tracks the GTK3 and GTK4 releases. On Linux, it’s kept up-to-date and is stable. It also works on Windows and macOS, but setting it up on those platforms requires more effort (installing GTK libraries separately). The maintenance is strong on the toolkit side (GTK is actively developed), and the PyGObject binding is stable, though not heavily publicized outside Linux circles.

Documentation & Community: There are fewer learning resources for PyGObject compared to Tkinter or Qtpythonguis.com

. One recommended resource is a comprehensive online tutorialpythonguis.com

, but overall community support often happens in GTK or GNOME contexts. The user base in Python tends to be those who specifically want to integrate well with GNOME desktop (for example, creating a Linux app that follows GNOME Human Interface Guidelines)pythonguis.com

. The community is much smaller on Windows – few people choose GTK on Windows if they can use Qt or wx (which are easier to deploy there).

Features: GTK provides a rich set of widgets (comparable to Qt in many respects), including buttons, multi-select lists, treeviews, editable text, file dialogs, etc. Embedding plots can be done (for instance, by embedding a Matplotlib canvas using the GTK3Agg backend). Glade, the GUI designer for GTK, allows drag-and-drop UI design and produces an XML (GtkBuilder .ui file) that PyGObject can load at runtimepythonguis.com

. This is very much like Qt’s approach with Qt Designer and is a big plus for visual design.

GTK apps on Windows will run, but the look-and-feel will be that of a GNOME app (Adwaita theme) which doesn’t exactly match native Windows style, and certain behaviors might feel alien to Windows userspythonguis.com

. Packaging GTK with your app on Windows is doable (via MSYS2 or included DLLs), but not as straightforward as shipping a Qt app.

Use Case: We include PyGObject here for completeness, but for a user coming from MATLAB on Windows, choosing GTK might not be the easiest path. It’s most suitable if you intend the app to run primarily on Linux (especially GNOME) and want to follow that ecosystem’s conventionspythonguis.com

. In terms of reliability, GTK and PyGObject are solid and maintained (not a one-man project at all), so the technology is sound long-term. It’s more about whether it fits your target deployment. If Windows support is needed, expect extra work.

Summary: PyGObject/GTK can certainly fulfill the functional requirements (it has the widgets and a GUI builder), and it is actively developed. But due to its niche community on Windows and trickier setup, it’s often not the first recommendation for cross-platform desktop Python apps unless you specifically align with GTK.

Other Notable Mentions

• Enthought TraitsUI / Qt: A higher-level framework that uses Qt (or WX) under the hood, with a declarative API for forms. It’s used in scientific apps to auto-generate UIs for data classes. This is a niche tool and maintained by Enthought, but community usage is limited.

• Enaml: A declarative GUI language for Python inspired by Qt QML, allowing you to write UI layouts in a special syntax. It typically uses Qt backend. It’s an interesting project but mainly driven by a small community. Use with caution if considering long-term support.

• Remi: This is a Python GUI library that actually runs in a web browser but is intended to feel like desktop. We discuss it more in the web section below. It even has a drag-drop editor for layoutspythonguis.com

  pythonguis.com

  . It’s not a mainstream choice for local desktop apps, but bridges the gap between desktop and web (no need to learn HTML).

   

The above list covers the most suitable and actively maintained Python GUI options for desktop applications. Next, we’ll highlight which of these stand out as the most reliable choices for long-term use, especially in the context of transitioning from MATLAB.

Which Frameworks are Most Reliable Long-Term?

When considering long-term reliability, we prioritize mature projects with strong maintenance and multiple contributors or backing organizations (to avoid depending on a single individual). We also consider stability of the ecosystem (e.g., does it rely on other maintained libraries, does it have frequent releases, etc.). Here’s a summary of the evaluation:

• Qt (PyQt6/PySide6): Highly reliable. Backed by the Qt Company (for PySide) and a long-established third party (for PyQt) with a large community. Development has continued for decades and will likely continue. Plenty of learning resources and an active ecosystem make it future-proof. Qt’s comprehensive features and tooling (Designer) also mean you’re less likely to hit a dead-end – whatever UI functionality you need, Qt probably supports it. This framework is an excellent choice for professional, long-lived applicationspythonguis.com

  pythonguis.com

  .

   

• Tkinter: Very reliable (in terms of availability) – as the default GUI library, it will always be there with Python. It’s stable and well-tested. However, its ecosystem is relatively stagnant. It gets bug fixes but not many new features. If your needs remain modest and you value stability over modern looks, Tkinter is a safe bet. Just be aware it’s a bit dated, and you might have to supplement it with custom code for advanced widgets. Since it’s not a one-man project (it’s part of core Python/Tcl communities), there’s no risk of it suddenly becoming unmaintained. It simply won’t evolve rapidly.

• wxPython: Reliable, with caveats. It has a long history and is currently under active, although somewhat slower, developmentpythonguis.com

  . It doesn’t have corporate backing but does have the wxWidgets team behind itpythonguis.com

  . The risk of single-maintainer issues is low now that it’s a team effort. In terms of stability, once an app is working, it tends to keep working (wxPython values backward compatibility). The main caveat is the smaller community – you might not find as much help or many new high-level libraries built on wx. Still, wxPython has proven its longevity.

   

• Kivy: Reliable in the sense that it’s actively maintained by an organization and has been around for 10+ yearspythonguis.com

  . It’s open source and has multiple core developers, so not single-person dependent. Kivy’s user base ensures it will likely stick around, especially with the rise of interest in mobile Python apps. If your use case fits Kivy’s paradigm, you can be confident in its future support. The only caution: if you need a traditional desktop look-and-feel or a drag-drop designer, Kivy might not satisfy that – but that’s a matter of fit, not reliability.

   

• Dear PyGui: Moderately reliable, but not yet proven long-term. It’s under very active development nowreddit.com

  , which is great, but being a newer project, one must keep an eye on its trajectory. It does have multiple contributors (the founders plus community), but a lot hinges on the original team’s continued involvement. There’s no large company behind it. In a few years, it could either become a staple or could plateau – hard to say. So far, its momentum is strong and many early adopters are satisfied. As of 2025, it seems a viable choice, but if “decades-long” support is a concern, Qt or wx (with their track record) feel safer.

   

• Toga (BeeWare): Potentially risky for production use at this time. While the concept is excellent and it is actively maintained, it’s essentially a one-man-driven project with a small communitypythonguis.com

  . BeeWare has had slow progress in achieving all its goals (understandably, given the scope). If you require guaranteed stability and all widgets working consistently on each OS, Toga might disappoint in the short term. For long-term (several years out), if BeeWare’s community grows, it could become reliable. But for an immediate transition from MATLAB, Toga would be an adventurous choice. Stick to it only if you’re willing to tolerate some hiccups and perhaps contribute fixes upstream.

   

• PySimpleGUI: Not reliable going forward. As noted, its development has effectively stagnated and even the maintainer suggests choosing PySide6 insteadpythonguis.com

  . Relying on PySimpleGUI now would mean banking on an unofficial fork or an old version. For long-term projects, this is not advisable – there’s a real risk of no updates or support. The project became a victim of the single-maintainer issue (and a shift in licensing direction), exactly the scenario to be cautious of. Instead, if simplicity is desired, one could replicate a bit of PySimpleGUI’s approach by using higher-level abstractions or even building a thin wrapper internally around a stable toolkit.

   

• PyGObject (GTK): Reliable technically, but for Windows-centric development it’s less practical. GTK itself will be around (backed by GNOME), and PyGObject will be maintained as long as GNOME uses Python for anything. So the toolkit won’t disappear. But consider the ecosystem: on Windows, very few people use GTK, so you may be on your own solving Windows-specific quirks. If your audience is Linux, it’s a fine long-term choice; if Windows, reliability of deployment is a concern (not reliability of the code, but of the integration).

In summary, the most reliable, actively maintained choices for long-term desktop GUI development in Python are Qt (PySide6/PyQt)pythonguis.com

(number one recommendation) and the built-in Tkinter (for simpler needs). wxPython is also a solid contender if you prefer its native widget approach. Kivy is reliable if its cross-platform/mobile focus aligns with your goals. We would avoid frameworks that are essentially single-developer or whose future is uncertain, such as PySimpleGUI (stalled)pythonguis.com

or any very new project without an established community (Toga is borderline in this regard – promising, but not fully proven).

Web-Based Python UI Options (for Awareness)

While the focus is on desktop GUI frameworks, it’s worth noting that Python can also be used to create web-based UIs that serve a similar purpose (interactive applications for data visualization, control panels, etc.). These solutions run either in a browser or create a web interface for your app. They can be viable if you don’t mind a browser-based deployment or need cross-platform distribution without installing desktop binaries on each client. Below are some notable web-based UI frameworks in Python:

• Plotly Dash: Dash is a popular framework for building analytical web applications purely in Python. It leverages Flask (for the web server) and React (for the frontend) under the hood, but as a developer you write Python code to define layouts and callbacks. Dash is quite mature (initial release around 2017) and has a large community in data science. It excels at creating rich dashboards with interactive graphs (built on Plotly.js). Maturity: Dash is considered the most mature of the modern Python web app frameworkslinkedin.com

  , with a strong ecosystem of custom components. Ease of Use: Moderate – you need to understand the reactive callback model, but you don’t write JavaScript. Visual Designer: No drag-drop editor; you write layout in Python (using HTML and component classes). Dash is backed by Plotly, a company, so it’s actively maintained.

   

• Streamlit: Streamlit (launched in 2019, now owned by Snowflake) introduced an extremely simple way to make web apps for data science. You write a Python script as if writing linear code, using st.sidebar and st.button calls to add UI elements, and Streamlit handles rendering and interactions (by rerunning the script on changes). Maturity: It’s newer than Dash but has quickly grown popular; however, it’s slightly less mature in handling very complex app logiclinkedin.com

  . Ease of Use: Streamlit has the lowest learning curvelinkedin.com

  – you can often turn a prototype into an app in minutes. Visual Designer: None needed; it’s so high-level that a designer is not really provided. It’s great for quickly turning analysis scripts into shareable apps. For large apps (many pages, complex state), it can become challenging to maintain.

   

• Shiny for Python: Originating from R’s Shiny framework, Shiny for Python (by RStudio/Posit) is a newer offering (in early 2020s) that brings Shiny’s reactive model to Python. It allows you to create UI layouts using a high-level Python API (or even mix with HTML) and define reactive callbacks. Maturity: Shiny for R is very mature; Shiny for Python is newer, but leveraging the same concepts. It is considered a bit more structured for complex apps compared to Streamlitreddit.com

  . Ease of Use: Slightly higher learning curve than Streamlit (you need to think in terms of reactive expressions), but still easier than writing raw web code. Visual Designer: Shiny has a tool in R (Shiny Designer), but for Python it’s not fully developed yet (as of 2025). If you’re familiar with Shiny in R, this could be attractive.

   

• Gradio and Panel: These are other libraries often used for quick web apps:

  • Gradio allows you to create simple web interfaces (often for machine learning models) with minimal code. It’s very handy for demoing models – you define inputs and outputs (like sliders, image upload, etc.) and launch a local interface.

  • Panel (from HoloViz) is another framework that lets you create dashboards using various Python plotting libraries (Matplotlib, Bokeh, etc.) and even use Jupyter widgets, serving them as a web app.

• Remi: As mentioned, Remi is a pure Python web GUI library that lets you write desktop-like GUI code in Python and renders it in a browserpythonguis.com

  . It even has a built-in drag-and-drop editor for designing the UI visuallypythonguis.com

  , which is akin to having an App Designer for web. Remi runs a lightweight web server and by default launches a browser to display the UI. It’s completely self-contained (users just need a browser). Maturity: It’s been around several years and is fairly stable for simple UIs. Use cases: Good for IoT or headless systems where you open the UI remotely (e.g., control a Raspberry Pi via web interface)pythonguis.com

  . It’s not meant for multi-user web sites (if two users connect, they share the same state)pythonguis.com

  . But for a single-user app, it’s an interesting alternative. It requires no HTML knowledge; you only use Python, and Remi translates it to HTML/JS on the flypythonguis.com

  . This could be appealing if one wants a browser UI without leaving Python.

   

• Electron-like approaches (PyWebView, Eel): Another category is using web technology for UI but bundling it as a desktop app. PyWebView lets you create a window with an embedded browser, where you can load an HTML/JS interface and communicate with Python. Eel is a library that makes it easy to create a desktop app with a front-end in HTML/JavaScript and a Python back-end (it runs a local server and loads it in a browser window, similar to Electron but using Chrome/Edge). These approaches require web development skills (HTML/CSS/JS), so they’re not pure Python solutions, but they allow leveraging web UI frameworks with a Python backend.

When to consider web-based UIs? If you foresee that your users might want to access the tool remotely or you want to deploy without worrying about OS-specific packaging, a web app can be advantageous. For example, tools like Dash or Streamlit can be deployed to a server or cloud and accessed via browser – users don’t install anything. Even for local use, some people use Streamlit or Dash like a desktop app (running locally, opening a browser window). The trade-offs are:

• Pros: No GUI toolkit installation issues, very easy cross-platform (browser is the platform), often quicker to build certain types of UI (especially forms or plots).

• Cons: Not suitable for very interactive complex GUI elements (like highly custom interactive tables, though Dash is quite capable). Also, performance can suffer for extremely heavy interactions since there’s a round-trip through a web server. Lastly, you might need to run a local server which adds complexity if distributing to non-technical users (though there are tools to package Streamlit/Dash apps as desktop executables too).

In the context of a MATLAB user: If your app in MATLAB was effectively a local dashboard or analysis tool, frameworks like Dash or Streamlit could let you recreate that in a web UI with relative ease, and possibly offer easier sharing with colleagues (no need for them to install Python – you could host it or package it). However, if you specifically want a native desktop application feel, then sticking to the desktop GUI frameworks discussed earlier is the way to go.

To summarize, Python’s ecosystem gives you the freedom to choose desktop or web for your UI. Web-based UIs in Python (Dash, Streamlit, Shiny, etc.) are very powerful for certain use cases, and have large communities in 2025. They are not direct analogues of App Designer (since App Designer doesn’t create web apps, except with MATLAB’s Web App Server for deployed web apps). But it’s good to be aware of these, as they might influence your choice depending on the end-users of your application.

MATLAB App Designer vs Python GUI Development – A Comparison

For an experienced MATLAB user transitioning to Python, it’s important to understand the differences in GUI development workflows and capabilities. MATLAB App Designer provides a unified environment: you design the UI with drag-and-drop, and you write callbacks in MATLAB code within the same app file. It’s tightly integrated, with MATLAB’s graphics and data processing at your fingertips. When moving to Python, here’s how things compare:

• Learning Curve: MATLAB App Designer is relatively easy to pick up for MATLAB users – it’s designed to be accessible, even if one isn’t a professional software developer. In contrast, Python GUI frameworks (especially Qt/wx) might feel less intuitive initially and require learning new concepts/APIsreddit.com

  . One user noted that in Python, “the GUI side of things aren’t as simple and easy to start off with” and that using PyQt/PySide involves “a steep learning curve”reddit.com

  . This is because Python GUI frameworks often demand understanding of event loops, layout systems, and object-oriented programming patterns. However, once that learning curve is overcome, Python offers far more flexibility (as we discuss below). Tools like Qt Designer help bridge this gap by providing a familiar drag-and-drop interface for layout, making the learning process smoother by separating design and logic.

   

• Visual Design Integration: In App Designer, the design canvas and code editor are in one application; you can click a button in the layout and directly edit its callback. In Python, the design and code are usually separate (except in frameworks where you code the layout by hand). With Qt Designer, for example, you design the UI then load it in code or convert it to code – an extra step, but not too cumbersome. Other frameworks like wx (with wxFormBuilder) or Tkinter (with PAGE) similarly separate the design tool from your coding environment. This means workflow-wise, you might juggle between a GUI designer program and your Python IDE. On the flip side, this separation can enforce cleaner code architecture (UI definition vs. logic). It’s a different approach from App Designer’s all-in-one file. For a GUIDE user (MATLAB’s older GUI tool), this separation will feel familiar (GUIDE also separated .fig and .m files). For an App Designer user, it’s a bit of adjustment.

• Language and Syntax: MATLAB code vs Python code are different, but assuming you’re comfortable with Python for non-GUI work, the big change is how callbacks are defined and connected. In MATLAB App Designer, you typically have functions like ButtonPushed(app, event) that are auto-wired to UI components. In Python, you will manually connect signals or bind events to handler functions (e.g., button.clicked.connect(my_function) in PyQt, or button.bind(wx.EVT_BUTTON, handler) in wxPython, or a command in Tkinter). This is a one-time setup per widget. It’s a minor difference, but requires understanding the event model of the chosen framework. Conceptually, it’s similar (callback functions triggered on events), but done in code rather than via the App Designer interface.

• Available Components: Both MATLAB App Designer and Python frameworks offer a wide range of UI components:

  • Basic controls (buttons, labels, sliders, text fields) – available everywhere.

  • Advanced controls: App Designer has things like UITable, UIAxes (for plots), tree controls, etc. Python frameworks like Qt or wx also have equivalents (QTableWidget/QTableView, Matplotlib integration or native plotting widgets, tree views). In fact, Python’s options might be more extensive. For example, Qt has widgets for web content, media playback, OpenGL, etc., which MATLAB doesn’t provide in App Designer. This means if you wanted to extend your app in new directions, Python might have libraries readily available. However, making a simple table or plot might require a bit more manual setup (e.g., embed a Matplotlib plot in a Qt widget, versus dropping a UIAxes and using MATLAB’s plotting commands directly on it).

  • Third-Party Components: MATLAB has a limited set of custom components (some user-submitted in File Exchange). Python, by virtue of being open-source, has a plethora of third-party widgets or modules (like date pickers, rich text editors, etc. for Qt). This expands what you can do but also means if you need something, you may have to look for an external package.

• Flexibility and Customization: A frequent complaint about App Designer is that it can be limiting for complex appsreddit.com

  . It’s great for quick GUIs, but if you try to deviate beyond its provided components or capabilities, you hit walls. For example, historically, things like custom UI layouts, interactive customization of components, or integrating non-supported Java components were painful – some advanced users resorted to Java hacks or undocumented features which could break in new MATLAB versionsreddit.com

  . One user said “you start hitting limitations [in App Designer] when trying anything slightly outside the basic stuff very very quickly”reddit.com

  . In Python, while the learning curve is higher, the frameworks are more flexible and extensible. If something isn’t provided out-of-the-box, you can often find a Python library for it or even interface with other languages (for instance, call C/C++ or use a web widget). Essentially, Python GUI development is closer to “general programming” – you have more power to customize, at the cost of more responsibility. An example: if MATLAB’s UITable doesn’t do what you want, you’re stuck; in Qt, if QTableWidget is insufficient, you can use a QTableView with a custom model, or even subclass it in Python to tweak behavior.

   

• Performance: MATLAB App Designer UIs run on the MATLAB runtime and are generally snappy for moderate components, but can become slow if the GUI has many elements or if you update the UI very frequently. Some users have observed issues like App Designer apps being “annoyingly slow” to update or having lag with certain operationsreddit.com

  . Python GUI frameworks like Qt or wx are implemented in optimized C/C++ under the hood, so the UI event handling and rendering are very fast. The performance bottleneck is usually your Python code if anything. In practice, a well-written Python Qt app will feel as responsive as a native app. Heavy real-time plotting might need optimization (just as in MATLAB you might struggle with rapid updates to UIAxes). Kivy and Dear PyGui, leveraging GPU, can actually offer very high performance in terms of rendering. Overall, you likely won’t lose out on performance by switching – you may even gain if MATLAB’s UI was a bottleneck. That said, if your Python app needs to do heavy computations, you might need to manage threading or asynchronous calls to keep the UI responsive (MATLAB does this behind the scenes since it’s single-threaded with an event queue). Python requires you to handle that (e.g., using QThread, multiprocessing, asyncio, etc., depending on toolkit).

   

• Deployment: With MATLAB App Designer, you can package apps as standalone .exe installers (which bundle MATLAB Runtime) or as web apps for MATLAB Web App Server. In Python, deployment can be a bit more manual but is very flexible:

  • You can use tools like PyInstaller or cx_Freeze to package your Python app into an executable that includes the Python interpreter and all dependencies. This is analogous to MATLAB’s compiler. The size of the bundle might be large (tens of MBs, similar to how MATLAB Runtime is a few hundred MBs), but it’s a one-time thing for users to install.

  • If using web frameworks, deployment might mean hosting on a server or instructing users to run a pip install and then streamlit run app.py, etc., depending on the audience.

  Packaging Python apps has gotten easier, and for something like a PyQt app, PyInstaller usually produces a working Windows executable without much fuss. The difference is you have to take this extra step; in MATLAB, it’s integrated into their tools (with the requirement of MATLAB licenses for compiling if not included in base product). Since we’re not focusing on cost, we won’t dwell on the fact that Python’s distribution is free – but it is worth noting in terms of process, distributing a Python app doesn’t require the end user to have Python if you bundle it properly, just like distributing a MATLAB app doesn’t require them to have MATLAB (just the runtime). So deployment effort is roughly similar, with Python perhaps needing a bit more DIY.

• Ecosystem and Integration: MATLAB apps excel in that they are in MATLAB – so you have all of MATLAB’s math and plotting capabilities readily available. In Python, you’ll rely on libraries (NumPy, SciPy, Pandas, Matplotlib, etc.) to provide similar capabilities. The good news is that Python’s scientific stack is extremely powerful and in many cases offers more functionality or performance than base MATLAB. For example, Python has multiple plotting libraries (Matplotlib, but also interactive ones like Bokeh or Plotly) that you could integrate in a GUI. You can also integrate web content or database access easily. Essentially, moving to Python opens up a broader ecosystem. If you were using specialized MATLAB toolboxes, you’d need to find Python equivalents (which often exist, e.g., for signal processing, machine learning). This isn’t a GUI difference per se, but an important consideration for a MATLAB user porting an app – the core computational code might need translation to Python libraries. Many users find Python’s libraries quite sufficient for replacing most MATLAB functionality.

• Example – Plotting Workflow: In MATLAB App Designer, you might drop an axes component and then in code do plot(app.UIAxes, x, y). In PyQt, you have a couple of choices: you could embed a Matplotlib plot by using a FigureCanvasQTAgg in a QWidget and then call Matplotlib’s plot functions on that canvas. Or you could use a native plotting widget like QChartView (Qt Charts) or PyQtGraph for faster interactive plotting. It’s a bit more setup (a few lines to embed the canvas), but then plotting is similar. If you use something like PyQtGraph, you get extremely fast interactive plots (faster than MATLAB for large data). So the capability is there, but you must wire it up. In summary, common tasks (plotting, table display, etc.) are very achievable in Python, but may require more explicit code and choice of libraries, whereas MATLAB has them built-in but with limited flexibility if you want something different.

• GUI Layout and Resizing: In App Designer, one often struggles with layout management – MATLAB uses a somewhat manual approach with pixel positions or simple grid layout, and making UIs responsive to window resizing can be “troublesome”medium.com

  . In modern Python GUI frameworks, layout managers are more sophisticated (e.g., Qt’s layout system or wx’s sizers). They can automatically resize and adjust if used properly. It might take a bit of learning to use them, but you can generally make a UI that scales to different window sizes more gracefully than in App Designer. The trade-off is you must design that behavior (whereas App Designer might just fix positions unless you use their minimal auto-resize options).

   

• Community and Support: With App Designer, your support resources are MATLAB documentation, and MathWorks support/forums (and possibly some community videos or blogs). With Python, you have a huge community – places like Stack Overflow have countless Q&As on PyQt, Tkinter, etc., and the projects themselves have forums or Discords. You won’t have a single company’s official support like MathWorks, but the community often suffices. The flip side is the community will ask “which toolkit are you using?” since Python has many – whereas in MATLAB the answer is always App Designer. This goes back to decision paralysis: one reason the question of “which Python GUI to use?” is common (with nuanced pros/cons causing difficultytildes.net

  ). In MATLAB, the decision is made for you (there’s basically one GUI framework). In Python, you have to choose, which is why this report is useful. Once you choose a framework, you’ll frequent that framework’s community for help.

   

• Capability Limits: It’s worth reiterating an experienced MATLAB user’s perspective: “While MATLAB does make it fairly easy and painless to put together simple GUIs, you start hitting limitations … If MATLAB doesn’t provide the customizability you desire, you’re out of luck”reddit.com

  . They switched to Python and found they could do much more, despite the initial effortreddit.com

  reddit.com

  . Another user lamented that App Designer is “horrible” for not allowing the same freedom as GUIDE (which let you do more raw MATLAB figure manipulations)reddit.com

  . Python GUI frameworks, especially Qt, allow that “freedom” – you can directly manipulate low-level aspects if needed or combine with other libraries. In that sense, Python GUI development can be more powerful for an advanced user.

   

• Development Environment: MATLAB’s IDE is tailored for App Designer when editing apps. In Python, you’ll use a general IDE (VS Code, PyCharm, etc.) to write your GUI code. Modern Python IDEs have debugging, autocomplete for Qt/wx, etc., so in many ways it’s analogous. But you might miss certain conveniences like MATLAB’s integrated property inspector for UI components. In Qt Designer, you do have a property editor for widgets (very similar to App Designer’s Inspector panel). Then you switch to code to implement behavior. It’s a bit more manual but quite workable.

In conclusion (MATLAB vs Python): If you are an experienced App Designer user, expect that moving to Python will require learning a new toolkit’s API and possibly structuring your code more (separating UI and logic). It won’t be quite as drag-and-drop simple initially. However, the payoff is significant – you gain access to a vast ecosystem and can overcome many of the limitations you might have encountered in App Designerreddit.com

. Your apps can become more complex or specialized, and you can integrate Python’s machine learning, internet connectivity, or other capabilities easily. The choice of framework will determine how smooth the transition is. For example, if you choose PyQt/PySide with Qt Designer, you’ll find a lot of similarity to App Designer’s workflow (design UI visually, then write callback code), easing the transition. If you choose Tkinter, you’ll be writing layout code by hand, which is a different experience – still effective, but less familiar.

One strategy is to start with a simple prototype of your MATLAB app in a Python framework (maybe using Qt Designer to lay out a few components and printing messages on events) to get a feel for it. Many MATLAB users who transitioned report that after the initial learning phase, they “don’t look back”reddit.com

– Python’s flexibility and the ability to use multiple programming paradigms (procedural, OOP, functional) make it a joy, and the GUI is just one part of that ecosystem. Another user mentioned making the switch and finding Python + its libraries “much faster [execution] than equivalent MATLAB code despite the MATLAB JIT”, and combined with tools like Pandas “MATLAB starts to feel woefully inadequate”reddit.com

reddit.com

.

Thus, for an experienced MATLAB App Designer user, moving to Python GUI development means trading a bit of short-term comfort for long-term power and freedom. You should be prepared for more hands-on work in setting up the UI and managing the application structure, but you will be rewarded with virtually unlimited possibilities and a platform that is free and widely supported. And with frameworks like Qt, you won’t lose the convenience of a drag-and-drop UI builder – you’ll just be using Qt Designer instead of App Designer, and PySide6/PyQt6 instead of MATLAB, with your computational brains moving from MATLAB language to Python’s rich set of libraries.

Conclusion and Practical Guidance

Transitioning from MATLAB’s App Designer to Python for GUI development is a feasible and often rewarding move. Python offers multiple GUI frameworks to choose from, each with its strengths. To summarize the findings:

• PyQt/PySide (Qt for Python) – Best overall choice for robust desktop applications. It is mature, feature-rich, and well-supported. With Qt Designer providing a familiar drag-and-drop design experiencepythonguis.com

  , it eases the learning curve for MATLAB users. This toolkit is backed by a large community and commercial support, ensuring longevity. If your goal is to build a complex, polished application that will be maintained for years, Qt is a top recommendation. It may take some effort to learn, but “for getting things done” in professional-quality apps, it excelspythonguis.com

  . The investment is worth it, as you’ll rarely encounter a requirement that Qt cannot fulfill.

   

• Tkinter – Good choice for simple GUIs or quick utilities, especially if you value the convenience of something that’s built-in and requires no extra installation. It’s extremely reliable (almost no risk of deprecation) and easy to deploy. However, it lacks modern GUI amenities out-of-the-box and can look datedreddit.com

  . If your MATLAB app was fairly simple (a few controls, maybe a simple plot) and you want the fastest path with minimal external dependencies, Tkinter could do the job. Just be aware that you might miss some of the UI niceties of App Designer (there’s no default equivalent of MATLAB’s sophisticated components like UIAxes – though you can embed a plot manually). For anything more than basic use, you may quickly feel its limitations.

   

• wxPython – A solid alternative if you prefer native look-and-feel on Windows and a comprehensive set of widgets. It has a moderate learning curve and no official integrated designer (but wxFormBuilder is available for layout)wiki.python.org

  . wxPython is quite capable of everything App Designer can do and more. It’s slightly less popular nowadays than Qt, but it’s lightweight and gets the job done. Consider wxPython if you specifically want to avoid Qt’s licensing (though PySide6 is LGPL, so that’s free too) or if you have prior experience with wx. Otherwise, Qt’s larger community might make it a more convenient choice.

   

• Kivy – Great for modern touch-friendly apps or cross-platform needs that include mobile. If your MATLAB app idea could benefit from multitouch or needs to run on an Android tablet, Kivy is the way to go (MATLAB can’t target mobile). For a standard desktop tool, Kivy is less conventional – you won’t get a native look, and there’s no drag-drop editor currently. But it will give you a stylish, consistent UI and high performance. Maturity-wise, it’s reliable, but be ready to learn the Kivy way of doing things (which is quite different from App Designer’s paradigm). Kivy might be considered if you’re also interested in mobile development or if you want a very custom UI design that doesn’t need to mimic native components.

• Dear PyGui – An interesting choice for small to medium tools, especially if you want a modern UI quickly via code. It’s not the most orthodox approach, but many find it **very easy to use and versatile】reddit.com

  . Given its active development, it could be a good fit for internal engineering tools, data viz apps, etc. Without a visual designer, it’s more akin to writing a script that draws the UI (somewhat like writing MATLAB code to place controls programmatically). If you enjoy coding UIs and want fast results, you might try it. But for a large application or one that you want absolute guarantee of maintainability in a decade, Qt is safer.

   

• Toga (BeeWare) – Adopt with caution at this stage. While promising, it’s not yet as battle-tested. If you’re feeling experimental and are okay dealing with potential bugs or contributing fixes, Toga can be tried. Its promise of native widgets on all platforms is attractive but currently comes with trade-offs in completeness. For a mission-critical project, likely stick with one of the more established frameworks for now. Keep an eye on Toga’s progress, as it might become a major player in the future.

• PySimpleGUI – Not recommended for new projects, despite its past popularitypythonguis.com

  . Its simplicity was a major draw, but with its development stagnating, it doesn’t meet the criteria for a reliable, maintained tool. If ease-of-use was the only concern, one could replicate some patterns using high-level abstractions in Qt or even use PyQt’s simple widgets in a procedural style, or consider a web-based solution like Streamlit for simple apps. But PySimpleGUI itself, in 2025, should be avoided for forward-looking development due to the reasons discussed.

   

• Web-based UIs – not the main focus, but always an option. If your target users could work with a web interface (or you want the app accessible remotely), frameworks like Dash or Streamlit provide rapid development and deployment. For instance, if your MATLAB App was largely about plotting results of computations with some input controls, a Streamlit app could accomplish that with minimal code and give you a web sharable interface. Dash is more comparable to building a structured app with multiple pages and complex callbacks (suitable if your app’s emphasis is on data visualization dashboards). These web options are all actively maintained and have corporate backing (Plotly for Dash, Snowflake for Streamlit, Posit for Shiny), so they check the reliability box. They diverge from the desktop GUI concept, but for completeness: a Python Shiny or Dash could be seen as an alternative “App Designer for the web” in some sense.

Finally, comparing MATLAB vs Python for GUI development: expect a shift from a tightly integrated environment to a more open and flexible development process. Python GUI development might require a bit more from you in terms of wiring things together and choosing tools, but it pays off in extensibility and community support. A MATLAB user who was frustrated by App Designer’s limits will find Python liberating – no more hidden or closed-off implementations, you can customize anything given enough know-how. One user who made the switch noted they could “now build very involved apps” in Python that would have been arduous in MATLABreddit.com

reddit.com

. Another mentioned that after transitioning, they “can’t bear to work in MATLAB any more”, finding Python’s ecosystem simply more enjoyable and powerfulreddit.com

.

For practical guidance:

• If you need to choose one framework to start with, try PySide6 (Qt) first – it’s a balanced choice for almost all requirements and has a friendly design toolpythonguis.com

  . There are plenty of tutorials aimed at PyQt/PySide beginners (some even specifically for people coming from MATLAB/other languages).

   

• If Qt feels too heavy or licensing was a concern (e.g., you insist on completely free for closed-source use, which PySide6 already covers), then try wxPython as a second option, or Tkinter if your app is very simple.

• Use the GUI designer tools available (Qt Designer for PySide/PyQt, wxFormBuilder for wx, PAGE/pygubu for Tkinter) to ease UI layout design. This will give you an App Designer-like experience of dragging components. Connect them in code similarly to how you did in MATLAB (one line connects a widget to a function, versus in App Designer you double-click to create the function – concept is comparable).

• Test a small prototype: perhaps recreate a small portion of your MATLAB app in Python to get familiar. You’ll quickly see the differences and also the new possibilities.

In conclusion, Python provides a robust path for developing desktop GUIs that can meet or exceed what you did in MATLAB App Designer. By choosing a well-maintained framework and investing some time to learn it, you can ensure your application is future-proof and not tied to proprietary limitations. Whether you go with the full-fledged Qt, the simple built-in Tkinter, or another route, you’ll be joining a large community of developers who build impressive interfaces in Python. With clear advantages in flexibility and a vibrant ecosystem, moving to Python GUI development can be seen as an upgrade in the long run, as long as you carefully select a toolkit that fits your needs and is poised to stay reliable for years to come.

Sources:

• Martin Fitzpatrick, “Which Python GUI library should you use?” (Python GUIs), updated May 2025 – comparisons of PyQt/PySide, Tkinter, Kivy, Toga, etc.pythonguis.com

  pythonguis.com

  pythonguis.com

   

• Official Python Wiki – GuiProgramming (updated Nov 2024) – lists of GUI frameworks and GUI builderswiki.python.org

  wiki.python.org

   

• Reddit discussion, “Which GUI framework do you use and why?” – user feedback on Qt (with Qt Designer) and Dear PyGuireddit.com

  reddit.com

   

• Reddit – “MATLAB GUI development easier than Python GUI?” – an experienced user’s take on switching from MATLAB GUI to Python (highlighting limitations of MATLAB and power of PyQt)reddit.com

  reddit.com

   

• LinkedIn post by Ajay Pawar – “Streamlit vs Dash vs Shiny” – quick comparison of popular Python web app frameworks (learning curve, maturity)linkedin.com

  linkedin.com

   

• Medium article by Ali E. Taşören – “Review of GUI tools on Python vs MATLAB” (2020) – noting pros/cons of App Designer and PyQt5medium.com

  medium.com

  .

   

Sources

You said:

looks like pyside6 is the best option for me. How do I install? And shoudl I use conda? I don't understand the advantages of conda.

2/2

ChatGPT said:

Thought for 22 seconds

Below is a practical, step-by-step guide to installing PySide 6 and a plain-English explainer of why (or why not) to use Conda. Follow the path that best matches your workflow.

1. Quick-start: the two common install routes

1-time: install Python 3.12 from http://python.org

python -m venv venv # make an isolated env

Windows: venv\Scripts\activate

macOS/Linux: source venv/bin/activate

python -m pip install --upgrade pip
pip install pyside6 pyside6-tools

CopyEdit

| **`conda` (Anaconda / Miniconda)** | • You already live in the Conda ecosystem <br>• Your project mixes Python + non-Python libs (e.g. C++, Java, R) <br>• You want one tool to install *both* runtime libraries *and* Python wheels | ```bash conda create -n qtapp python=3.12 pyside6 pyside6-tools -c conda-forge conda activate qtapp ``` | *Either way* you’ll now have: ```bash python -c "from PySide6.QtWidgets import QApplication, QLabel; app=QApplication([]); QLabel('Hello PySide').show(); app.exec()"

If a window with Hello PySide appears, the install worked.

2. Detailed pip route (no Conda)

1. Create / activate a virtual environment

   bash

   CopyEdit

   python -m venv venv venv\Scripts\activate # on Windows # or source venv/bin/activate # macOS / Linux

2. Upgrade pip and install

   bash

   CopyEdit

   python -m pip install --upgrade pip # good hygiene pip install pyside6 pyside6-tools # tools = Qt Designer, uic, rcc … pip install pyside6-addons # optional: QtCharts, QtDataVisualization…

   Wheel binaries are pre-built, so no C-compiler is needed on Windows or macOS ◆ PyPI

3. Launch Qt Designer

   After installation a script called designer (Windows) / designer.exe (Scripts folder) is on PATH.

   bash

   CopyEdit

   designer # or python -m PySide6.scripts.pyside_tool -d

   Save the .ui files you build; load them in Python with QUiLoader or convert to code using pyside6-uic.

3. Detailed Conda route

1. Install Miniconda (small) or Anaconda (full).

2. Create an environment and install via conda-forge

   bash

   CopyEdit

   conda create -n qtapp python=3.12 pyside6 pyside6-tools -c conda-forge conda activate qtapp

   conda-forge provides up-to-date PySide 6 (e.g., 6.9.0 as of April 2025) Anaconda

3. If a package is missing in Conda, mix in pip

   bash

   CopyEdit

   conda activate qtapp pip install some-pypi-only-lib

   Conda first, pip second keeps dependency resolution predictable.

Why isn’t there an “official” Conda build?
The Qt for Python team only publishes wheels on PyPI; volunteers on conda-forge repackage those wheels. They update quickly but occasionally lag a few days behind the pip release Qt Forum.

4. Conda vs pip in plain English

Rule of thumb:

• If you’re already comfortable with Conda (or need non-Python libs like CUDA, HDF5, GDAL) stick with it.

• If you mostly code in Python and ship small apps — pip + venv is lighter and simpler.

Community wisdom: “Conda is a system package manager; pip is a Python package manager” Reddit. Conda environments can even host different Python versions side-by-side, which is handy when you’re testing PySide 6 against multiple interpreter versions Saturn Cloud.

5. Next steps

1. Learn the basics of Qt Designer
   Lay out a form visually, save myapp.ui, then in Python:

   python

   CopyEdit

   from PySide6.QtWidgets import QApplication, QMainWindow from PySide6.QtUiTools import QUiLoader from pathlib import Path app = QApplication([]) ui = Path(__file__).with_name("myapp.ui") win = QUiLoader().load(ui.open("rb")) win.show() app.exec()

2. Explore PySide 6 extras

   • Charts: pip install pyside6-essentials pyside6-addons (QtCharts, 3D, DataViz) PyPI

   • Docs & examples: python -m PySide6.scripts.pyside_tool -h lists designer, assistant, linguist, etc.

3. Package your final app
   Use PyInstaller (pip) or conda-pack (Conda) to build a single-folder / single-file executable. Qt plugins are auto-detected.

TL;DR

• New to Conda? Try pip + python -m venv; it’s simple and works for PySide 6 out-of-the-box.

• Already using Conda for data science? Install PySide 6 from conda-forge and stay in that ecosystem.
  Either way, PySide 6 is just one command away, and designer.exe gives you the drag-and-drop comfort you’re used to from MATLAB App Designer.

Sources

You said:

So will I run conda and pyside in windows, or in WSL?

ChatGPT said:

Thought for 33 seconds

Should you install Conda + PySide on native Windows or inside WSL?

Bottom line

If your end-users will run your app on Windows, install Miniconda (or pip + venv) in native Windows and work there.
Use WSL only as an extra Linux test bed—nice to have, but not a requirement for PySide 6.

Installing in native Windows (recommended main environment)

CopyEdit

# 1. Install Miniconda for Windows (64-bit) # 2. Create and activate an env conda create -n qtapp python=3.12 pyside6 pyside6-tools -c conda-forge conda activate qtapp # 3. Test python - << "EOF" from PySide6.QtWidgets import QApplication, QLabel app = QApplication([]) QLabel("Hello from Windows Qt!").show() app.exec() EOF

pyside6-tools drops designer.exe in <env>\Scripts; use it just like MATLAB App Designer to lay out forms.

Packaging:

CopyEdit

pip install pyinstaller pyinstaller your_app.py --onefile

PyInstaller collects Qt DLLs automatically.

Installing inside WSL 2 (only if you want a Linux build)

1. Enable WSLg (built into Windows 11; on Windows 10 you need an X-server such as VcXsrv).
   Microsoft’s tutorial: “Run Linux GUI apps with WSL” Microsoft Learn

2. Inside Ubuntu:

CopyEdit

sudo apt update && sudo apt install -y build-essential libgl1 conda install -n base conda-forge::mamba -y # faster solver (optional) conda create -n qtapp python=3.12 pyside6 pyside6-tools -c conda-forge conda activate qtapp python -m PySide6.QtWidgets --test # tiny smoke-test

3. A PySide window should appear on your Windows desktop (rendered via WSLg). If it fails, check $DISPLAY is set (WSLg auto-sets :0) and ensure libgl1 or mesa-utils are installed — common missing deps noted in Stack Overflow threads Stack Overflow.

Remember: the binary built here is Linux-only. If you later run pyinstaller in WSL you’ll get an ELF executable that Windows users can’t run.

When does WSL actually make sense?

So start on Windows, get comfortable, then spin up WSL when you actually need Linux testing or tool-chain benefits.

Key take-aways

1. Conda works in both places, but environments are separate—install packages twice if using both.

2. PySide 6 is fully supported on Windows; no benefit to forcing it through WSL unless you need Linux.

3. WSLg is great for testing but not a deployment path for Windows users.

4. Stick with native Windows + Miniconda (or pip + venv) as your primary workflow, add WSL only if/when cross-platform work arrives.

Sources

You said:

I get this error: >>> conda create -n cspm python-3.12 pyside6 pyside6-tools -c conda-forge File "<stdin>", line 1 conda create -n cspm python-3.12 pyside6 pyside6-tools -c conda-forge ^^^^^^ SyntaxError: invalid syntax

ChatGPT said:

It looks like you ran the Conda command at the Python “>>>” prompt instead of at your system’s command-line prompt, and there’s a small typo in the command itself.

1 Exit the Python interpreter

If you see the interactive prompt (>>>), quit it first:

CopyEdit

>>> exit() # or Ctrl-Z Enter (Windows) / Ctrl-D (macOS/Linux)

2 Run the command in PowerShell, Command Prompt, Windows Terminal, or Anaconda Prompt—not inside Python

CopyEdit

conda create -n cspm python=3.12 pyside6 pyside6-tools -c conda-forge

Two fixes:

1. Run it in the shell, not inside Python.

2. Use an equals sign: python=3.12 (Conda syntax) instead of python-3.12.

After it finishes:

CopyEdit

conda activate cspm python -m PySide6.QtWidgets --test # quick smoke-test

A tiny window should appear; if so, the environment is ready.

You said:

PS C:\Users\pmacey> conda create -n cspm python=3.12 pyside6 pyside6-tools -c conda-forge conda : The term 'conda' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1 + conda create -n cspm python=3.12 pyside6 pyside6-tools -c conda-forge + ~~~~~ + CategoryInfo : ObjectNotFound: (conda:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException

ChatGPT said:

Thought for 22 seconds

Why “conda is not recognized” appears

Your PowerShell session can’t find conda.exe in PATH, which means either

• Miniconda / Anaconda isn’t installed, or

• It is installed but its folders were not added to PATH / not initialized for PowerShell. Stack OverflowAnaconda

Below are the two scenarios and how to fix each.

1 You haven’t installed Conda yet

Install Miniconda (or Anaconda) on Windows

1. Download the 64-bit “Miniconda 3 Windows installer” from the official site.
   Choose the Python 3.12 build. (Direct URL omitted; search “Miniconda Windows download” if needed.)

2. Run the installer

   • Recommended: keep the default “Do not add Miniconda to the system PATH”.

   • Accept “Register Miniconda 3 as my default Python”.

3. Open the “Miniconda Prompt” from the Start menu and verify:

   cmd

   CopyEdit

   conda --version

4. Enable Conda for PowerShell (one-time)
   In the Miniconda Prompt run:

   cmd

   CopyEdit

   conda init powershell

   Close and reopen Windows Terminal / PowerShell; conda should now work everywhere.
   (The init command adds a small auto-activate script to your PowerShell profile.) MonoVM.com

    

2 Conda is installed but not on PATH

Quick checks

CopyEdit

where conda # Classic cmd Get-Command conda # PowerShell

If both return nothing, the folders containing conda.exe aren’t in PATH.

Two ways to fix PATH

Manual edits work, but conda init is safer because it avoids PATH length issues and plays nicely with multiple Conda installs. Reddit

3 Create the PySide 6 environment once Conda works

CopyEdit

conda create -n cspm python=3.12 pyside6 pyside6-tools -c conda-forge conda activate cspm python -m PySide6.QtWidgets --test # a tiny window should pop up

If that test window appears, you’re ready to build PySide 6 apps.

Recap

1. Install Miniconda/Anaconda, or make sure its condabin/Scripts folders are on PATH.

2. Run conda init powershell (or use the Miniconda Prompt) so every new PowerShell session knows Conda.

3. Create your environment and proceed with PySide 6 development.

Following these steps eliminates the “conda not recognized” error and gets you straight to coding.

Sources

You said:

how do I add to path?

ChatGPT said:

Thought for 15 seconds

Below are three practical ways to put Conda on your PATH so the conda command works everywhere. Pick whichever fits your comfort level.

1 Use conda init (the easiest & safest)

1. Open the “Anaconda Prompt” or “Miniconda Prompt” from the Start menu
   (those prompts already know where conda.exe lives).

2. Run conda init powershell.
   What it does: writes a tiny startup snippet to your PowerShell profile that adds
   <Miniconda3>\condabin to PATH every time you open PowerShell and pre-loads the conda activate logic.Conda Documentation

3. Close all terminals ➜ reopen PowerShell ➜ type conda --version → it should print the version.

Why this is recommended:
conda init avoids manual typos and keeps PATH short (it adds only the needed condabin directory, not every Conda subfolder).

2 Add the folders in Windows Settings (graphical)

1. Start → Settings → System → About → Advanced system settings
   (or Right-click This PC → Properties → Advanced system settings)

2. Environment Variables… ➜ select “Path” under User variables ➜ Edit ➜ New

3. Add these two lines (adjust the username if different):

CopyEdit

C:\Users\<you>\Miniconda3\condabin C:\Users\<you>\Miniconda3\Scripts

4. OK out of all dialogs, reopen PowerShell, and run conda --version.

Step-by-step screenshots are in Microsoft’s docs on “Add a path to the PATH environment variable”Microsoft Learn.

3 Add with one command (setx) from any admin PowerShell

CopyEdit

setx PATH "$Env:PATH;C:\Users\<you>\Miniconda3\condabin;C:\Users\<you>\Miniconda3\Scripts"

Caution: setx truncates PATH to 1024 characters on some Windows versions; avoid it if your PATH is already long. Microsoft Learn

Verifying everything

CopyEdit

# Should print something like "conda 25.5.0" conda --version # Create the PySide environment again conda create -n cspm python=3.12 pyside6 pyside6-tools -c conda-forge conda activate cspm python -m PySide6.QtWidgets --test # tiny test window

If the commands run without “not recognized” errors and the test window appears, PATH is set correctly and you’re ready to build your PySide 6 app.

Sources

You said:

FOUnd this propblem: PS C:\Users\pmacey> conda create -n cspm python=3.12 pyside6 pyside6-tools -c conda-forge Channels: - conda-forge - defaults Platform: win-64 Collecting package metadata (repodata.json): done Solving environment: failed PackagesNotFoundError: The following packages are not available from current channels: - pyside6-tools Current channels: - https://conda.anaconda.org/conda-forge - defaults To search for alternate channels that may provide the conda package you're looking for, navigate to https://anaconda.org and use the search bar at the top of the page. PS C:\Users\pmacey>

ChatGPT said:

Thought for 59 seconds

Why you’re seeing “PackagesNotFoundError: pyside6-tools”

conda-forge builds every package for each Python version.
The pyside6-tools feedstock hasn’t finished its Python 3.12 build yet, so the solver can’t find a compatible wheel on win-64 while pyside6 itself is already available Anaconda. Community discussions confirm that the tools sub-package often lags a little behind the main bindings and that the fallback is to use pip inside the environment or stick to Python 3.11 until the new build lands CSDN Wenku.

Two painless work-arounds

Both give you:

CopyEdit

conda activate cspm designer # Qt Designer pyside6-uic my.ui > my_ui.py # convert .ui to Python python -m PySide6.QtWidgets --test

Why it’s safe to mix one pip wheel inside Conda

pyside6-tools contains only Python entry-points plus bundled Qt executables (designer.exe, lupdate, etc.).
It doesn’t ship extra DLLs that could clash with the Qt libraries already provided by pyside6; therefore installing it with pip in the same environment is benign. Conda itself recommends this pattern (“conda first, pip second”) for packages that aren’t on the channel yet Wikipedia.

Quick test

CopyEdit

conda activate cspm python - << "EOF" from PySide6.QtWidgets import QApplication, QLabel app = QApplication([]) QLabel("PySide6 OK").show() app.exec() EOF

If the window pops up, your environment is good to go.

Staying informed

• conda search -c conda-forge "pyside6-tools=6.*" will show when the 3.12 build appears.

• The feedstock’s GitHub page usually merges the new build a few days after each Qt/Python release; once you see a win-64/py312 artifact there, you can drop the pip wheel and do conda install pyside6-tools.

For now, choose Option A or B, and you can continue developing with Qt Designer immediately.

Sources

You said:

I get an error:

ChatGPT said:

Could you post the exact error text you’re seeing and let me know which of the two approaches you tried?

• Option A (Python 3.12 + conda install pyside6 then pip install pyside6-tools)