GTK+ Forums

Hi all,

First off sorry if this has been asked before, but I couldn't turn up anything relevant searching here (or Google for that matter).

I'm trying to create a ToggleButton subclass in Python, that is basically a typical toggle button, but with a DrawingArea inside (rather than a label) that updates when certain properties change. What I'm doing at the moment is simply subclassing ToggleButton, adding a DrawingArea as a child of the ToggleButton instance, and queueing a draw on the DrawingArea whenever the ToggleButton receives a draw signal, or the properties I'm watching change.

When I load up the app, the blank button is drawn, but nothing else. I've got print statements in the DrawingArea's draw callback, and it seems it never gets called, despite explicitly calling queue_draw on it when the ToggleButton is drawn, and when I want to update it with new data. I'm hoping someone can provide a quick example of how I should be doing this, because I can't seem to work out what the parent classes are taking care of, and what I need to be taking care of.

Thanks in advance.

Making custom widgets can be quite a complicated matter. There's many things that can go wrong and its doubtful that I can guess without code, though likely the code is long for a normal post.
My expertise is not with python so I will likely be way off on a few things.
How are you subclassing it? Are you doing that directly in python or via gobject? I would have thought if you are just adding the drawing area to the togglebutton as a child I don't see why there is need for subclassing at all. In this case I would see it as container add; connect a signal to a callback for togglebutton changes; in the callback adjust the properties of the drawing area and then call invalidate region or otherwise on it.
If you are doing subclassing with gobject you can create your own class which will handle all the signal emission/connections internally. There's a few tutorials around: http://www.pygtk.org/articles/cairo-pygtk-widgets/cairo-pygtk-widgets.htm, http://zetcode.com/gui/pygtk/customwidget/ as well as some example code that isn't drawing area parent based: http://git.gnome.org/browse/pygtk/tree/examples/gtk/widget.py

Thanks for the reply, and sorry, I should really have posted the source first thing. Here's a cut down version of the class (I just stripped out all the cairo drawing code and the code I use to respond to update signals):

I'm subclassing from Gtk imported from gi.repository, which if you're not familiar with it, is Python's GObject introspection bindings. I'm pretty sure this means it's subclassing from the same GObject that I'd be subclassing from if I wrote the widget more or less from scratch, which I guess means I can override/add signals etc. if I need to (that was the plan anyway). This widget is going to be a reusable one (I've loaded it into a Glade catalog for the project), which is why I wanted it all wrapped up nicely in a class. My hope was that in subclassing directly from ToggleButton, I'd be able to keep all the functionality I still wanted, and just tack on the DrawingArea and any extra bits I needed.

I notice you are connecting to a draw signal which is new in gtk3. I didn't realise that there was a python binding out for gtk3 yet. Perhaps there isn't and this draw signal is just getting ignored? The c reference also shows a difference in the arguments for the callback function
You say the drawing updates when certain properties change. Where are these properties? The normal OO approach is to declare them in the custom widget and set up public accessor functions to change them (those functions can then make the appropriate calls to redraw them). In the end with gtk2 you only need to connect the expose event in the class and do the queue_draw functions in the methods.
Possibly you also could do with setting size requests. One of my Drawing Areas defaults to zero allocated size as I haven't got around to setting it (at the moment its a useful catch-all for divide by zero errors etc.).

Paul, thanks very much for all your help. The signal is there, and does in fact work. Your post pointed me down an investigation path which eventually led me to the answer. I checked whether the drawing area had been realized, which it hadn't. This puzzled me since it's supposed to happen in the DrawingArea class init. It then dawned on me that maybe the widget wasn't visible...it wasn't (big d'oh!). Once I set it to visible in my class init, the widget performs perfectly. As for the updates on property change, all that was doing as watching another GObject's properties and calling a redraw if they changed. I cut it out because I didn't think it was relevant. Anyway it's all good now, so thanks again.

hmm?,
I never thought that you'd ever have to explicitly st visible to true; figured this'd be the default. Might be worth discussing that on one of the pygtk developers group.
You seem to have tracked down that problem quite quickly and efficiently. By the way, the forum is quite under-represented of good pygtk users, who often don't get a response, so even if you are able to figure out a problem on your own without the need to ask questions, posting it in case some-one else may stumble into the same problems can be a good way of helping people out.
Thanks for sharing your answer,
Paul.

Same here, otherwise I would have checked that right away. I've posted it to the main PyGTK mailing list (I didn't see any separate developer list - maybe I didn't look hard enough). If and when I know something more I'll post it here, along with any other problems I come across. Thanks again.