Differences

This shows you the differences between two versions of the page.

--- misc:gui_frameworks_for_linux [2016/05/21 18:41] – [PyGObject] mithat
+++ misc:gui_frameworks_for_linux [2017/05/29 19:28] (current) – [wxPython (including Phoenix)] mithat
@@ Line 2: / Line 2: @@
 ===== Python-centric =====
+==== Tkinter ====
+**TL;DR**: Perhaps OK for small, one-file utility apps
+Pros
+  * Comes out of the box with Python.
+Cons
+  * Look and feel are a real buzzkill on Linux, possibly also on other platforms---even with themed widgets. The ugliness of menus is pretty much a deal killer
+  * No standard GUI builder, though a few 3rd party ones exist.
+<file python tkdemo.py>
+from tkinter import *
+from tkinter import ttk
+def do_nothing():
+    print('passssss ...')
+root = Tk()
+root.option_add('*tearOff', False)
+s=ttk.Style()
+s.theme_use('clam')
+# Menubar
+menubar = Menu(root)
+root.config(menu=menubar)
+filemenu = Menu(menubar)
+filemenu.add_command(label='New ...', accelerator='Ctrl + N', command=do_nothing)
+filemenu.add_command(label='Open ...', accelerator='Ctrl + O', command=do_nothing)
+filemenu.add_separator()
+filemenu.add_command(label='Quit', accelerator='Ctrl + Q', command=root.destroy)
+editmenu = Menu(menubar)
+editmenu.add_command(label='Copy', accelerator='Ctrl + C', command=do_nothing)
+editmenu.add_command(label='Cut', accelerator='Ctrl + X', command=do_nothing)
+editmenu.add_command(label='Paste', accelerator='Ctrl + V', command=do_nothing)
+menubar.add_cascade(label='File', menu=filemenu)
+menubar.add_cascade(label='Edit', menu=editmenu)
+# Toolbar
+toolbar = ttk.Frame(root)
+tb_foo = ttk.Button(toolbar, text='Foo', command=do_nothing)
+tb_foo.pack(side=LEFT, padx=2, pady=2)
+tb_bar = ttk.Button(toolbar, text='Bar', command=do_nothing)
+tb_bar.pack(side=LEFT, padx=2, pady=2)
+toolbar.pack(side=TOP, fill=X)
+# Status bar
+status = ttk.Label(root, text='System status: doing nothing', borderwidth=2, relief=SUNKEN, anchor=W)
+status.pack(side=BOTTOM, fill=X)
+# Go!
+root.mainloop()
+</file>
 ==== PyGObject ====
+**TL;DR**: Perhaps best option for Linux-centric apps---unless/until some GNOME goofiness happens.
 Replacing PyGTK.
 Pros
+  * Workflow (UI layout to code) is pleasant.
   * First-class Linux framework.
   * LGPL
@@ Line 22: / Line 85: @@
   * Poor support on other operating systems.
   * GTK3 is the future and it is built for GNOME. For other desktop environments, who knows how well it will work and what will be supported. Will a ton of GNOME dependencies eventually be required?
-Thoughts
-  * Workflow (UI layout to code) is pleasant.
-  * Perhaps best option for Linux-centric apps---unless/until some GNOME heaviness/goofiness happens.
-==== PyQt ====
+==== wxPython (including Phoenix)===
-Pros
+**TL;DR**: Perhaps best option for multi-platform proprietary apps that have zero budget.
-  * First class Linux framework.
-  * Excellent multiplatform support (except maybe non-GNOME GTK).
-  * Lots of components (including "we do it differently" DBUS, etc.)
-  * Used by Spyder and a lot of others.
-Cons:
-  * GPL-only or commercial license is at ~$500. (PySide is LGPL, but there has been little development.)
-  * Qt code can be heavy, somewhat verbose.
-  * Possibly PITA to install if not using distro repos (which you want because it moves so fast).((on Debian, ''qttools5-dev-tools'' will get standalone Qt Designer and other stuff.))
-Thoughts
-  * Perhaps best option for multi-platform FOSS apps and for proprietary apps that have a $500 tools budget.
-==== wxPython (Phoenix)===
 Pros
   * Liberal license.
@@ Line 50: / Line 95: @@
 Cons
+  * Support for Python 3 via Phoenix is still raw.
   * Second-class Linux framework.
-  * Awkward external UI builder (wxGlade is incomplete, wxFormBuilder requires building, wxSmith is integrated with Code::Blocks)
+  * Wonky UI builder support
-	* wxFormBuilder generates .fbp files which are XML---but not really human readable.
+    * Requires third-party tools:
-  * Tiny bit awkward external UI file export/import mechanism (no UI file format, export a class with GUI, in program subclass it to make your wired-up window.).
+      * wxFormBuilder needs to be built (generally not in repos), generates .fbp files, which are XML but not really human readable.
+      * wxGlade is incomplete.
+      * wxSmith is integrated with Code::Blocks.
+    * No UI file format results in slightly awkward UI file export/import mechanism: export a class with UI builder, subclass it in the app to make your wired-up window.
   * Code seems awkward at times (perhaps it's only oddly named components)
 Awkward points:
   * In wxville, a Frame is a window, a Window is the mega-parent class, a Control is a widget.
@@ Line 61: / Line 110: @@
   * Events: self.Bind(//event-type//, //handler//, //emitting-object//)
-Thoughts
+==== PyQt ====
-  * Perhaps best option for multi-platform proprietary apps that have zero budget.
+**TL;DR**: Perhaps best option for multi-platform FOSS apps and for proprietary apps that have a $500 tools budget.
+Pros
+  * First class Linux framework.
+  * Excellent multiplatform support (except maybe non-GNOME GTK).
+  * Lots of components (including "we do it differently" DBUS, etc.)
+  * Used by Spyder and a lot of others.
+Cons:
+  * GPL-only or commercial license is at ~$500. (PySide is LGPL, but there has been little development.)
+  * Qt code can be heavy, somewhat verbose.
+  * Possibly PITA to install if not using distro repos (which you want because it moves so fast).((on Debian, ''qttools5-dev-tools'' will get standalone Qt Designer and other stuff.))
+==== PySide ====
+**TL;DR**: Abandonware? If not now, later?
+Classic PySide was released in 2015 and works with Qt 4.8 framework. PySide2, which supports Qt5, is being developed, but it's not production ready, seems to be moving slowly, and doesn't seem to have much mindshare.
 ==== Kivy ====
-Interesting, but not really a desktop application framework. Good for touch interfaces.
+**TL;DR**: Not really a desktop application framework. Well-suited to touch interfaces.
 Pros