I have just started learning about creating GUI apps in Python. I decided to use Gtk version 3.
According to the (official?) tutorial on http://python-gtk-3-tutorial.readthedocs.org/ the proper way of building a hello world application is:
from gi.repository import Gtk
class MyWindow(Gtk.Window):
def __init__(self):
Gtk.Window.__init__(self)
self.set_default_size(200, 100)
self.connect('destroy', Gtk.main_quit)
self.show_all()
MyWindow()
Gtk.main()
In other tutorial (http://www.micahcarrick.com/gtk3-python-hello-world.html) I found completly different aproach which is:
from gi.repository import Gtk, Gio
class HelloWorldApp(Gtk.Application):
def __init__(self):
Gtk.Application.__init__(self, application_id="apps.test.helloworld",
flags=Gio.ApplicationFlags.FLAGS_NONE)
self.connect("activate", self.on_activate)
def on_activate(self, data=None):
window = Gtk.Window(type=Gtk.WindowType.TOPLEVEL)
window.set_title("Gtk3 Python Example")
window.set_border_width(24)
label = Gtk.Label("Hello World!")
window.add(label)
window.show_all()
self.add_window(window)
if __name__ == "__main__":
app = HelloWorldApp()
app.run(None)
Could someone experienced in this category tell me in what way should I write Gtk 3 apps in python these days? I'm already familiar with writing GUIs (spent few months in Java's Swing) so you can go on with terms like events, callbacks and so on..
Choosing to write your new program with a GtkApplication or just a GtkWindow depends on the functionality you require, and to some extent the intended audience.
For most cases, especially when you are still learning the toolkit, I would tend to agree with valmynd that GtkApplication is unnecessarily complicated. GtkApplication provides a lot of extra functionality that you probably don't want or need in smaller applications.
For larger, more complete applications I agree with Dragnucs, the second approach is superior and can provide better integration into the desktop environment. From GNOME Goal: Port to GtkApplication (see also the GtkApplication docs):
Porting your application to use GtkApplication has quite nice benefits:
GtkApplication handles GTK+ initialization, application uniqueness, session management, provides some basic scriptability and desktop shell integration by exporting actions and menus and manages a list of toplevel windows whose life-cycle is automatically tied to the life-cycle of your application.
However I disagree with Dragnucs about why the GtkWindow approach is introduced in the tutorial. I tend to think simple examples with very little boilerplate are more appropriate for a tutorials Getting Started section (but, I do think that the read-the-docs tutorial needs to be updated to include at least some mention of GtkApplication).
In applications I've written I tend to either subclass both GtkApplication and GtkWindow or for single window quick-and-nasty applications just subclass GtkWindow. Your decision will depend on your applications needs.
Technical difference: There is also an important technical difference between how the two examples are implemented. The example with just a GtkWindow creates a new Gtk main loop for each instance of the program. The example with GtkApplication creates a single main loop attached to the first instance and each subsequent call to run(None) will request that the original instance create a new window (the new instance will then exit). Try opening up two terminals and running your application in each window, notice that one terminal will wait until all the windows have closed before becoming sensitive again. You can change this behaviour by using G_APPLICATION_NON_UNIQUE instead of G_APPLICATION_FLAGS_NONE.
The second code example looks unnecessary complicated to me, the first looks perfectly fine. The author of that second tutorial has put a link to another, even more simple example (Source):
from gi.repository import Gtk
window = Gtk.Window(title="Hello World")
window.connect("destroy", lambda w: Gtk.main_quit())
window.add(Gtk.Label("Hello World!"))
window.show_all()
Gtk.main()
There is nothing wrong with either approaches. You can use all the default widgets, not subclassing anything, like in the example above. Or you can subclass certain widgets, mainly as a way to give your code a nice structure and having re-usable custom/modified widgets in the end. That is all up to you.
The same applies to Qt and many other GUI frameworks, btw.
The second approach is better. It makes the application more integrated into the desktop and informs more about what it does or is meant to do. It also provides you with more tools to use with your application.
I think the first approach is just not up to date or something. The second one is really the preferred way.
You can see that the application Gnome-music is actually using the second approach with Gtk.Application usage. All the official Gnome apps are using Gtk.Application, and all Gtk application should be using it too.
Related
Note how this application implements a mainloop by the activate signal and .run() method call:
import gi
gi.require_version("Gtk", "4.0")
from gi.repository import Gtk
def on_activate(app):
win = Gtk.ApplicationWindow(application=app)
btn = Gtk.Button(label="Hello, World!")
btn.connect('clicked', lambda x: win.close())
win.set_child(btn)
win.present()
app = Gtk.Application(application_id='org.gtk.Example')
app.connect('activate', on_activate)
app.run(None)
Correct me: I think this activate signal is emitted as an event to synchronise the creation of GTK windows, widgets, etc, so that the GUI part does not race to happen before the application is ready. What else is the point?
Then, when the Window, widgets, etc are all drawn, the application gets stuck in a mainloop by .run(). This way the application doesn't exit immediately, but rather waits for user input.
What bothers me here is that I don't see the value of the Application class. Because of it, we got an event on signal activate to tell "oh the app is ready", but what is this app anyway? Why can't I just do .run() on Gtk.ApplicationWindow or even Gtk.Window?
In order to answer those questions above, I invented/discovered this question that, if answered, I think it will address my frustration:
Question: What is the GT4 approach in running GUI apps without using Application or ApplicationWindow classes?
Background
I come from a TKinter background. There, I could make an app simply by saying something like:
import tkinter
class MyApp(tkinter.Tk):
def __init__(self):
super().__init__()
self.title('some title')
if __name__ == '__main__':
myapp = MyApp()
myapp.mainloop()
It feels much simpler, without a spaghetti of creating two objects (like in GTK4) with signals emitting through them just to barely get a .run() mainloop.
But I have to use GTK4 for this project, and Tkinter is not an option. So I have to learn the suitable GTK4 for me.
According to the docs: "GtkApplication is a high-level API for writing applications.
It supports many aspects of writing a GTK application in a convenient fashion, without enforcing a one-size-fits-all model.
Currently, GtkApplication handles GTK initialization, application uniqueness, session management, provides some basic scriptability and desktop shell integration by exporting actions and menus and manages a list of toplevel windows whose life-cycle is automatically tied to the life-cycle of your application.
While GtkApplication works fine with plain GtkWindows, it is recommended to use it together with GtkApplicationWindow."
Source: https://docs.gtk.org/gtk4/class.Application.html
The clasic hello world from Gtk3 will not work on Gtk4
This works:
import gi
gi.require_version("Gtk", "3.0")
from gi.repository import Gtk
win = Gtk.Window()
win.connect("destroy", Gtk.main_quit)
win.show_all()
Gtk.main()
But if you change "3.0" by "4.0" does not work and the reason is on the migration guide:
"GTK 4 removes the gtk_main_* family of APIs. The recommended replacement is GtkApplication"
https://docs.gtk.org/gtk4/migrating-3to4.html#stop-using-gtk_main-and-related-apis
Gtk have a different approach to Tk, you will need to be used to that.
And GTK4 is still new, you will found more examples about Gtk3 code, so, keep the migration guide at hand
I'm a bit confused with some gtk and gnome concepts. I'm trying to get list of non minimized windows on my gnome2 desktop, but after reading the pygtk documentation and inspecting the results, I can't understand the results.
Neither of the two snippets below appears to work.
First I tried this..
>>> gtk.gdk.window_get_toplevels()
[<gtk.gdk.Window object at 0xb74339b4 (GdkWindow at 0x8a4c170)>]
>>> gtk.gdk.window_get_toplevels()[0].get_children()
[]
then this
>>> d = gtk.gdk.DisplayManager()
>>> d.get_default_display().get_screen(0).get_root_window().get_children()
[<gtk.gdk.Window object at 0x89dcc84 (GdkWindow at 0x8a4c170)>, <gtk.gdk.Window object at 0x89dccac (GdkWindow at 0x8a4c0c0)>]
As seen in the console output, the second option returns two windows. But I haven't been able to figure out what they are. None of them has any children and I allways get those two windows regardless how many windows I have on my desktop.
Could anybody explain the hierarchy of objects of the typical gtk based desktop environment?
I can't understand why the above code doesn't work.
Please refrain from posting alternative solutions that resource to wnck, xlib, qt, etc. I'm more interested in understanding what I am doing wrong than in getting advice such us checking other libraries.
Your constraint is like saying "I want to build a CD player using only a banana. Please refrain from posting alternative solutions that resort to lasers." GTK can't do that, you're using the wrong tool for the job.
Here's an explanation of what a "window" actually means and why your code doesn't work:
First off, you need to understand the difference between a gtk.Window and a gtk.gdk.Window. A GTK window is a top level GTK widget that can contain other widgets. It is usually linked to a window on your desktop, but doesn't have to be - in GTK 3 there is an OffscreenWindow.
A GDK window, on the other hand, is platform-dependent. On an X desktop it is a thin wrapper around an X window, which is not necessarily a toplevel desktop window. On other systems it exists to abstract away the windowing system. A GDK window receives events, so some GTK non-window widgets have their own GDK windows. "Window" is really a terrible name for these objects, but it was inherited from X and it's probably not going to change.
Each GTK process only knows about its own windows. You can get a list of the toplevel GTK windows of your own application using gtk.window_list_toplevels(). Getting the children of these windows should return you the GTK widgets that they contain. However, you can't descend into the widget hierarchy of other processes' windows. For example, what if another process has a window with a child widget that is a custom widget that your process doesn't know about? What should it report as the type of that widget?
Getting a list of the toplevel GDK windows with gtk.gdk.window_get_toplevels() is basically the same as getting a list of the toplevel X windows, as far as I understand it. You have no way of knowing what kind of windows they are - they might be the Gnome Panel, or they might be Qt windows, or they might be something else altogether that doesn't correspond with a desktop window.
Libwnck (link to the overview of what it does) can get you a list of non-minimized windows, and their titles, but it won't allow you to see inside them. There's no way to do that. Libwnck uses GDK internally, so technically you could do it using GDK, but why would you bother if there's already a library that does that for you? If you really want to do it yourself, look at the libwnck source code.
The windows you get are the windows that were created within your process. To get the list of windows, you need to query the properties of the root window, like this:
import gtk.gdk
root = gtk.gdk.get_default_root_window()
for id in root.property_get('_NET_CLIENT_LIST')[2]:
w = gtk.gdk.window_foreign_new(id)
if w:
print(w.property_get('WM_NAME')[2])
Please note that GDK is a thin layer over underlying OS graphics engine (X11/Quartz/Aqua/GDI etc) and result may differ on different NIX devices.
well maybe crazy is a bit too strong of a word, but what I am asking is if there are any window toolkits out there that don't have me do this:
class MyApp(SomeWindowClass):
I really don't want to use a library made by someone who is so obsessed with objects that he/she thinks that there should be a class for the app (which there will only be one instance of, so I don't see why anyone would want to do that extra typing)
(btw, no offense intended towards anyone who agrees with the way these libraries are set up, I just really want to know if there is anything out there with a tad bit less objects)
In general GUI toolkits rely on having some form of event loop running, the Application class in these toolkits is generally in charge of that event loop and marshaling events from the underlying window manager. Sure they could call the class EventLoopManager or something, but you need it either way so its just a naming thing then. In some cases though some toolkits who often use events can occasionally be used without them, and then you certainly dont want it to be some automatic thing.
There is PyQT.
Tkinter has one object per window/dialog, not app, and requires no classes to get something painted on the screen. It does, however, have its own main loop (like all the other GUI libraries). Obligatory Hello World:
from Tkinter import *
root = Tk()
w = Label(root, text="Hello, world!")
w.pack()
root.mainloop()
PyGTK another toolkit; which is python binding of Gtk. It is well structured with having excellent window and event loop system.
A typical example to show a window
import gtk
class Application:
def __init__(self):
self.window = gtk.GtkWindow(gtk.WINDOW_TOPLEVEL)
self.window.show()
if __name__ == "__main__":
app = Application()
gtk.mainloop()
Another recommendation is PyQt; which is python binding of Qt.
Typical hello world example is
import sys
from qt import *
app = QApplication(sys.argv)
myLabel = QLabel("Hello world!", None)
app.setMainWidget(myLabel)
myLabel.show()
app.exec_loop()
PyQt and PyGtk are widely used for rapid GUI development. From my experience pyGtk is poor in the online documentation/support compared to pyQt. But both are favorite of mine.
As you see with the answers above, GUI programming is almost always heavily object oriented, and there are good reasons for this: the graphical elements share a lot in terms of how they can be positioned within one-another, caring about whether the mouse pointer is over them etc. Furthermore, the C++ kits that qt, wx, gtk et al. wrap are already structured on a class/inheritance hierarchy, so you should not be surprised that the python wrappers are also.
If you want only simple GUI elements, then you may consider easyGUI (simple message boxes, text edit, choices), triatsUI (interactive object wrappers, primarily for controlling graphical objects) , which each solve some part of the GUI interactions without explicitly having you write GUI code.
For editing the values of fields in a record-like structure, you could also investigate GUIdata.
PS: there are various graphical tools out there to let you design your GUIs and link together some of the events, e.g., QtDesigner, that can help you avoid much of the tedious class definition code.
I've got a Python/GTK project I've been working on for a while, and some of the functionality I want already exists in Gnome panel applets. Based on my reading, panel applets are already in a subclass of the standard GTK Bin, so I would think there'd be a way that I can use the C-based GTK objects in my Python-based application.
For instance, I've got the fish applet in /usr/lib/gnome-panel/fish-applet-2 as a binary
Can I do some GTK magic to get that object so it can be embedded into my Python/GTK gui?
I'm not expecting a step-by-step walkthrough, but if anyone can point me in the right direction, I'd appreciate it.
The code for applets in gnome panel is quite complex. It's based on the gnome Bonobo framework (which in turn is based on CORBA). But now the whole thing is in a bit of a flux because gnome is moving away from Bonobo to a new dbus-based design. So if it's loading existing gnome panel applets you want you should absolutely use the code from gnome panel to do it. There is (or at least was) an example program included that does nothing but load an applet into a window.
If you want to display a widget from one of your own programs (a custom applet) inside another of your programs it's much easier. There are a set of widgets called GtkSocket and GtkPlug for this purpose. Of course the to programs doesn't need to run on the same machine. But there is always the delicate problem of getting them together in the first place.
How would I get a handle to the active gtk.Window in python? (not a window I created, but the currently focused window).
The answer is actually not OS-specific -- you can do it within GTK. You can get a list of all the toplevel windows from the application using gtk.window_list_toplevels(), then iterate through it until you find one where window.is_active() returns True.
If you want to consider other windows than the ones from your application, then you could try gtk.gdk.screen_get_default().get_toplevel_windows() but this will only get you GDK windows and not GTK windows, because you have no way of knowing whether those GDK windows are actually associated with GTK windows.
[Note: This answers the question as the OP originally phrased it, which other readers will probably be searching for - not the very different question that they changed it to in comments on the other answer.]
If you have a GtkApplication and have added your GtkWindows to it - which you should probably do, because GtkApplication can do lots of really cool stuff! - then you can use GtkApplication's much simpler API dedicated to this purpose:
Gtk.Application.get_active_window():
Gets the “active” window for the application.
The active window is the one that was most recently focused (within the application). This window may not have the focus at the moment if another application has it — this is just the most recently-focused window within this application.