I am creating a program using wxpython which entails the need to create many sub-windows for each of menubar items. I am currently creating those sub-windows by writing different class definition for each and instantiating those classes for each event. Is this better than to have wx.window? How does two compare and what are the situations where they should be used?
If each toolbar item is to open a new "window", then I would recommend a wx.Frame or wx.Dialog. You almost never need to use wx.Window directly. wx.Window is the parent of wx.Frame and wx.Dialog. As such, wx.Frame and wx.Dialog potentially add additional functionality.
Dialogs are modal and should be used when you want program execution to stop while the dialog is dealt with (like when you need to get special information to complete some task). Frames are used when you don't need to stop program execution.
Related
I wanted to ask if it is possible to draw a child window inside a parent window so that it will only be able to move inside the parent window and won't be able to move out of the parent window bounds.
If you mean having actual windows with title bar, menu, status bar etc. inside the parent window then the answer is:
No, Tcl/Tk and by extension Tkinter does not support this with its standard widgets.
There have been efforts in the past to implement widgets which emulate MDI as you can see on the TCL wiki, but most of them are over a decade old. You will probably have to implement it yourself or choose a different GUI toolkit if you really need to implement this kind of UI design.
If you do it yourself, you can use the Frame widget as the subwindow, and use place to put it in the containing window. Or, you can create it as an object on a canvas. You'll have to write all of the code to give the inner window borders and a title bar, and to manage moving it around, iconifying it, etc.
I was hoping some one could explain to me the difference and reason behind why I keep coming across two different methods for which people place buttons into the widget? I sometimes see
button = Button('Button', self)
or
self.spinner = QtGui.QSpinBox()
I just want to know whats the difference, is one more beneficial than the other? When to use which in what scenarios and why? Does the position of 'self' affect this in the widget some how?
Assuming you only care about PyQt and PySide…
There are two different places that self appears in your examples, which mean very different things.
First, as an argument to the constructor:
Every widget's constructor has a parent parameter, with a default value of None.
There are three reasons to leave out the parent:
You're going to assign the widget to a layout or other parent after creation.
You're creating a top-level window.
You're creating a special-purpose widget like QDesktopWidget.
If none of these are true, you need to pass a parent. If self is a widget, and the thing you're creating is a child of that widget, you will pass self as the parent.
Here's an example of the first alternative:
self.spinner = QtGui.QSpinBox()
hbox = Qt.QHBoxLayout()
hbox.addWidget(self.spinner)
self.addLayout(hbox)
We can't pass a parent to QSpinBox at construction time because its parent doesn't exist yet. So, we leave it off, and addWidget it to a layout object later.
This is all explained early in most tutorials for PySide or PyQt, like First programs in PySide and Layout management in PySide.
Meanwhile, one of your examples stores the widget in self.spinner, making it an instance attribute on self, which means we can refer to it later. For example, if some other method (like the signal handler for a button) wants to adjust the spinner's value, it can access it as self.spinner.
If you will never need to refer to the child widget in your code after the current function, you don't need to store it.
This part is explained in the Classes chapter in the Python tutorial.
I have written a little python utility that monitors my typing speed, using pyxhook to hook keyboard events, and a thread timer to update my words per minute number.
Right now it just prints to the terminal every 2 seconds.
How can I make this appear in a little always-on-top gui box?
I tried playing around with tkinter, but the mainloop() function doesn't like my key listener and timer. It seems I can only run the gui OR my event handlers, but not both.
Unfortunately I don't think I can use the keyhandler in tkinter, since I am wanting to capture events from other windows.
Any suggestions?
I don't know how to go about doing this in tk, but I've been using PySide lately and I know you could use that.
One way to do it in pyside would be with two classes running in separate threads that communicate using the Qt signal & slot mechanism available in pyside. One class would subclass QThread & get methods that run your existing code & pass the data via signals to the Ui class. The 2nd class would be the one for your gui elements. it would call for an instance of the first class, connect the signals & slots, then start it & begin drawing the display.
resources if you go the pyside route:
http://www.matteomattei.com/pyside-signals-and-slots-with-qthread-example/
search 'pyside dock widget' on this site
search for github's pyside examples
https://pyside.github.io/docs/pyside/PySide/QtCore/QThread.html?highlight=qthread
I am working on a project coded in python with GUI in Wxpython for last 3 sleepless night now I got struck.Actually inside main parent frame I am executing a new subframe in another thread all I want is to stop further code execution until its subframe has done its work and closed.
I have tried using threading.Thread.join() method but it does not seems to work efficiently and after the Closing of subframe the Main Parent Frame Hangs.
Is there any efficient method to do this thing?
Use a wx.Dialog instead of a sub-frame and its ShowModal() method to stop the execution of the main frame. Technically, you could also use the frame's MakeModal() method for a similar effect, but I think using a dialog makes more sense.
By the way, when using threads with wxPython (or any GUI toolkit), you MUST use the toolkit's threadsafe methods to update the GUI. You should not try to directly access a GUI element from a thread as that is undefined behavior. Instead, use wx.CallAfter, wx.CallLater or wx.PostEvent as they are wxPython's threadsafe methods.
See also:
http://wiki.wxpython.org/LongRunningTasks
http://www.blog.pythonlibrary.org/2010/05/22/wxpython-and-threads/
I am creating a plug-in to a GTK3 program. This plug-in can be enabled or disabled at runtime. When enabled, it should populate its GUI in a given area (a GtkBin) in the host program. When disabled, it should remove itself from that area.
This simple program depicts the usage:
#!/usr/bin/python2
from gi.repository import Gtk
window = Gtk.Window()
class Plugin(object):
def __init__(self, host):
assert(isinstance(host, Gtk.Bin))
self.host = host
self.guest = None
def enable(self):
box = Gtk.Box(orientation = Gtk.Orientation.VERTICAL)
for x in range(10):
box.add(Gtk.Button("Button {}".format(x)))
self.guest = box
self.host.add(self.guest)
def disable(self):
self.host.remove(self.guest)
# self.guest.destroy() # is this better?
self.guest = None
plugin = Plugin(window)
plugin.enable()
#plugin.disable()
window.connect("destroy", Gtk.main_quit)
window.show_all()
Gtk.main()
I wish that when the plug-in is disabled, all widgets it added to the host should be properly disposed.
I have found this question quite similar: Free object/widget in GTK? It proposed gtk_container_remove and gtk_widget_destroy. But I am worrying:
Consider gtk_container_remove. It removes the direct child of the host container. In my case, the child is also a composition of many other widgets and they may be referencing each other. Will removing the direct child enough for all the widgets to be disposed?
Consider gtk_widget_destroy. It is recursive and appears to be what I need, but also seems too brutal. Is this really necessary to manually destroy a widget? Would it be better to leave that job to the reference-counter?
I am willing to hear the "best practice" for this case.
Best practice is to never rely on a garbage collector to collect an object that controls a limited resource in a timely fashion. It could delay collecting any particular garbage indefinitely. You wouldn't want to leave a file open for the garbage collector to clean up, because there's a limit to the number of file handles you can have open at once.
It happens that Python's garbage collector has a reference counter and will free objects with no references immediately, but that is an implementation detail. If you use another implementation, such as PyPy or IronPython, this does not apply. I've had a program break when I moved it to another implementation, because I had inadvertently relied on Python's reference counting to clean up resources. Also, you can end up with bugs that happen because you accidentally create a cycle somewhere.
I don't know of any best practices for widgets specifically. I hadn't considered the possibility that I should be cleaning those up. If a widget has a window associated with it, that is an OS handle that you should theoretically clean up. Usually, only a GtkWindow will have a real window, but it's possible for your plugin to create a widget with a window. So, I would say that in that one specific unlikely case, you should theoretically destroy the widget. Otherwise, it's fine to destroy them manually if you don't need them, but I would say don't go out of your way to do so.
From my point you can use any of those, since what will happens is this:
When you use gtk_container_remove, if your child object (self.guest) have no other reference, then it will be destroyed automatically. I mean GtkContainer will decrease the reference count and the GObject system will call then gtk_widget_destroy.
If you call gtk_widget_destroy, the that will indeed destroy the widget, and in the process will release the widget from its parent.
So, you can use any of those, but I will use the first one.