Re: [pygtk] cleaner module reload?

[Johan Dahlin]

> Yes, but this is cleaner:
> 
> if not hasattr(foo, "__gtype__"):
> gobject.type_register(foo)

That won't work, since gobject.GObject has a __gtype__ property, so
hasattr will always return True. You need to check in your subclass and
make sure that python does not traverse its class and bases to fetch the
value.

I still think the gobject.type_name is the most clean solution.

-- 
Johan Dahlin <[EMAIL PROTECTED]>

___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

Re: [pygtk] cleaner module reload?

[Skip Montanaro]

>> gobject.type_register(foo)
>> 
>> at the module level to register gobject.GObject subclasses.  To
>> support module reloading I wrap it:

Gustavo> No needed for any of these hacks.  Since pygtk 2.3.92, pygtk
Gustavo> allows registering the same python class with the type system
Gustavo> as many times as you like, so module reloading should Just
Gustavo> Work.

Thanks, but we're far away from that (2.2.0 according to gtk.pygtk_version).

Skip
___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

Re: [pygtk] cleaner module reload?

[Skip Montanaro]

>> try:
>> gobject.type_register(foo)
>> except RuntimeError:
>> pass
>> 
>> This works but seems "unclean".  (I've been using Python for ten
>> years or

Johan> I'm not I can see why raising a RuntimeError from a library like
Johan> PyGTK is considered unclean.

Like I said, I've been using Python for about ten years and never needed to
catch RuntimeError.  I've just never seen it used in a situation where you
might want to recover.  We're dealing with types and values.  I would expect
a TypeError (type that's already registered) or ValueError (a "value" of
gobject.GObject that's already registered) to be raised here.

Johan> When are RuntimeError exceptions supposed to be raised?

Rarely, if ever, in my experience.  The libref doc states:

 Raised when an error is detected that doesn't fall in any of the other
 categories.

There are so many builtin exceptions that RuntimeError just doesn't get
used.  It's rare that something else doesn't work.  If nothing builtin
works, the usual route is to define a custom exception of some sort, often
as a subclass of Exception, but sometimes as a subclass of another builtin
exception.

class TypeRegistrationError(TypeError):
pass

>> if not gobject.is_registered(foo):
>> gobject.type_register(foo)

Johan> gobject.type_register sets the __gtype__ variable in the class
Johan> when it's registered, so this should do it:

Johan>   if not foo.__dict__['__gtype__']:
Johan>   ...

Johan> but that's even uglier, so what about using g_type_name and it's
Johan> python wrapper?

Yes, but this is cleaner:

if not hasattr(foo, "__gtype__"):
gobject.type_register(foo)

Johan>   if gobject.type_name(foo) != 'GObject':
Johan>   ...

Johan> Seems to work, but it's still not the nicest way to check this, so you
Johan> can check if the name is registered:

Johan>   if not gobject.type_from_name('__main__+foo'):
Johan>   ...

I think hasattr() is the way to go.  Thanks for the hint that attributes
were added to the class as a side-effect of type registration.

While we're discussing adding attributes during type registration, I did
notice that __gsignals__ is also removed as a side-effect of type
registration.  This is a shame, because it's lost as a nice indicator of the
signals that are defined by this class.  I'm sure there's some way to
introspect this, but it's not something that (for example) pydoc could use.
It took me awhile to realize pydoc wasn't broken when I tried running it on
one of my GObject subclasses.  I couldn't figure one why it didn't tell me
about __gsignals__.  (I should have noticed the addition of __gtype__ there
as well.)

Skip
___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

Re: [pygtk] cleaner module reload?

[Gustavo J. A. M. Carneiro]

A Qui, 2004-08-12 Ãs 19:17, Skip Montanaro escreveu:
> I use
> 
> gobject.type_register(foo)
> 
> at the module level to register gobject.GObject subclasses.  To support
> module reloading I wrap it:

  No needed for any of these hacks.  Since pygtk 2.3.92, pygtk allows
registering the same python class with the type system as many times as
you like, so module reloading should Just Workâ.

  Regards.

-- 
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic

___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

[pygtk] Announcing devhelp support for PyGTK2 Reference manual

[John Finlay]

Johan Dahlin added devhelp 
(http://www.imendio.com/projects/devhelp/devhelp) index creation support 
to the PyGTK Reference:

http://www.pygtk.org/pygtk2reference/index.html.
The manual and tarballs have been updated to include devhelp indexes. 
There were no other significant changes from the 2.4.9 version. The 
devhelp index alone for use with the 2.4.9 version is available from:

http://www.moeraki.com/pygtkreference/pygtk2reference.devhelp.gz.
John
___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

Re: [pygtk] cleaner module reload?

[Johan Dahlin]

> try:
> gobject.type_register(foo)
> except RuntimeError:
> pass
> 
> This works but seems "unclean".  (I've been using Python for ten years or

I'm not I can see why raising a RuntimeError from a library like PyGTK
is considered unclean.

When are RuntimeError exceptions supposed to be raised?

> if not gobject.is_registered(foo):
> gobject.type_register(foo)

gobject.type_register sets the __gtype__ variable in the class when it's
registered, so this should do it:

  if not foo.__dict__['__gtype__']:
  ...

but that's even uglier, so what about using g_type_name and it's python
wrapper?

  if gobject.type_name(foo) != 'GObject':
  ...

Seems to work, but it's still not the nicest way to check this, so you
can check if the name is registered:

  if not gobject.type_from_name('__main__+foo'):
  ...

Much cleaner IMHO.

I know the naming scheme is a bit ugly, perhaps it'd be better if we
could specify the name in the class somehow, or just doing as in C and
let us pass it in as an argument in type_register.

Should probably open up a bug for that.

-- 
Johan Dahlin <[EMAIL PROTECTED]>

___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

[pygtk] cleaner module reload?

[Skip Montanaro]

I use

gobject.type_register(foo)

at the module level to register gobject.GObject subclasses.  To support
module reloading I wrap it:

try:
gobject.type_register(foo)
except RuntimeError:
pass

This works but seems "unclean".  (I've been using Python for ten years or
so, and I think this is the first occasion I've had to catch a RuntimeError
exception.)  I didn't see any obvious way to ask "has the foo class been
registered?"  All the various gobject functions that take a type/class seem
to raise exceptions of one sort or another if foo isn't a PyGTK type.  I
suppose I should let it go at that, but I was hoping for something like:

if not gobject.is_registered(foo):
gobject.type_register(foo)

Thx,

-- 
Skip Montanaro
Got spam? http://www.spambayes.org/
[EMAIL PROTECTED]
___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

[pygtk] Re: Invalid TreeIter from custom treemodel

[Vitaly Ostanin]

John Finlay wrote:

Your custom model has a couple of broken methods:
on_iter_n_children() and on_iter_nth_child()
These do not properly handle the case where iter or parent is None. 
These special cases indicate the toplevel rows should be used. See:

file:///usr/local/doc/pygtk2reference/class-gtktreemodel.html#method-gtktreemodel--iter-n-children 

file:///usr/local/doc/pygtk2reference/class-gtktreemodel.html#method-gtktreemodel--iter-nth-child 


for more info. As a guess you should start each with something like:
if not node:
   node = self.doc
Thank you very much! Fixed treemodel.py is attached and works 
clean :)

--
Regards, Vyt
mailto:  [EMAIL PROTECTED]
JID: [EMAIL PROTECTED]


treemodel.py.bz2
Description: application/bzip
___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

Re: [pygtk] pygtk-2.2/pygtk-2.4 and pyOpenGL

[Johan Dahlin]

tor 2004-08-12 klockan 14.09 skrev [EMAIL PROTECTED]:
> Hi,
> 
> When using pygtk-2.2 (pygtk-2.2.0-1.win32-py2.3) together with
> pyOpenGL (PyOpenGL-2.0.1.08.py2.3-numpy23) everything
> works fine. But when using pygtk-2.4 (pygtk-2.3.96.win32-py2.3)
> I get the following traceback when calling show_all () on the 
> widget tree containing the gtk.DrawingArea:
> 
> TypeError: multiple bases have instance lay-out conflict

Can you provide us with a small testcase? Hopefully without any pyOpenGL
code at all.

-- 
Johan Dahlin <[EMAIL PROTECTED]>

___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

[pygtk] pygtk-2.2/pygtk-2.4 and pyOpenGL

[Bernhard . Rumpler]

Hi,

When using pygtk-2.2 (pygtk-2.2.0-1.win32-py2.3) together with
pyOpenGL (PyOpenGL-2.0.1.08.py2.3-numpy23) everything
works fine. But when using pygtk-2.4 (pygtk-2.3.96.win32-py2.3)
I get the following traceback when calling show_all () on the 
widget tree containing the gtk.DrawingArea:

TypeError: multiple bases have instance lay-out conflict

What could be the reason for this? (using gtk+-2.4.4)

thanks for any hints!
Bernhard


___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

Re: [pygtk] Mnemonic broken after adding widget?

[Stephen Kennedy]

> >However, mnemonic-activate is not fired if I connect to it after adding
> >the tab. It's work-aroundable in code but obviously breaks with glade.
> >See the attached test case. 
> >  
> >
> The notebook's internal "mnemonic-activate" handler stops handlers 
> connected after it from being activated.

I've come across this before (pygtk Digest, Vol 1, Issue 939) and this
kind of builtin behaviour still baffles me. It just seems needlessly
complex.

Here are three common use cases for signals:
1) I want the default behaviour.
2) I want to override the default behaviour.
3) I want default plus additional behaviour.

Currently 2 and 3 are quite complex. Or perhaps there's an easier way?
1) no action needed.
2) find and disconnect default handler, install handler.
3) find remember and disconnect default handler
  a) (before) connect custom, reconnect default
  b) (after) connect a proxy which calls default and returns false
 connect custom handler after

IMHO the builtin signal handlers should use "connect_after" and never
stop the signal chain. Then:
1) no action needed.
2) use connect and return true from handler.
3) use either connect or connect_after depending on need.

Any gtk hackers care to comment?
Stephen.
-- 
Stephen Kennedy <[EMAIL PROTECTED]>
http://meld.sf.net visual diff and merge

___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

[pygtk] allocating colors

[Johannes Zellner]

Hello,

if I allocate more than 256 colors for drawing on a gtk.Image(), the
label colors of other widgets in the application get some wrong color.
I don't really understand this, as I'm running a TrueColor visual
with 24 bits depth here.

How should I allocate colors to avoid a colormap corruption?

-- 
Johannes
___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/