Here is a better explanation of why user signals won't add much
functionality.
First of all, you have to realise that while GTK+ is quite friendly to
language bindings (the number that have sprung up is proof of this), its
object model is not. To create a new GtkObject descendent (widgets are
objects), you specify a number of functions that initialise the class
structure and actual objects. These functions are not easy to wrap, as
they don't have a user_data argument or some other way to pass a python
object to the C wrapper. Signals are pretty similar.
When a signal is called, any handlers connected to the signal with
gtk_signal_connect are executed. Then the object class's handler (if any)
is called. Finally handlers connected with gtk_signal_connect_after are
called. Now the object class's handler doesn't get passed the user_data
argument, and you can't specify a marshaller for it (AFAIK).
Now I could add user signal support to pygtk, you would not be able to
include the class's signal handler. Also, it is impossible to add a C
signal marshaller (a function that converts an array of parameter
definitions to arguments to a C function) in a general way. This means
that connecting C functions to signals created from python is not going to
work. This leaves you with python functions being connected to these
signals. It is probably simpler (and probably less overhead) to just
implement this by storing some callbacks in a list like the code in my
previous message.
As for style stuff, if I add editing to the signals, the following will
work:
style = widget.get_style()
style = style.copy() # we don't want to change every widget that uses
# this style.
style.font = load_font('fontname')
widget.set_style(style)
The question I was asking about was for the style attributes that are
state dependent (eg colors). These are exported to python as tuples, so
you access them as style.bg[STATE_NORMAL] for instance. Now running
style.bg[STATE_NORMAL] = cmap.alloc(0xffff, 0, 0)
will give you an error because you can't assign to tuples.
My question is what would be the best way round this? One idea is number
of functions like:
style.set_bg(STATE_NORMAL, cmap.alloc(0xffff, 0, 0)
There may be better solutions I haven't thought of yet though.
James Henstridge.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
On Sun, 14 Feb 1999, David M. Cook wrote:
> On Mon, Feb 15, 1999 at 09:46:50AM +0800, James Henstridge wrote:
>
>
> > Now for adding new signals ... If I did this, you realise that you would
> > only be able to attach python handlers and call them with GtkObject.emit()
> > method?
>
> No, I don't understand the limitations involved. I am not as intimate with
> pygtk as its creator ;}
>
> >In this case, it may be easier to store a list of tuples like
> > (func, user_data) and run
> > for func,user_data in handlers:
> > func(object, some_arg, user_data)
>
> I think you're saying pass a callback to the object in question? That's
> what I'm doing now. I just like the idea of being able to create compound
> widgets in Python that behave just like Gtk widgets. I suppose passing
> callbacks struck me as a bit Tkinterish ;}
>
> > Now for editable styles. I am personally in favour of using RC files to
> > set this sort of information, but maybe it should be included for
> > completeness.
>
> I don't understand how to change styles dynamically this way. How can I let
> the user change the font on the fly, for instance?
>
> Dave
> To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
>
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
