[Bf-python] event ID questions (long post - sorry)

[Thomas Bleicher]

On Mon, Aug 15, 2005 at 11:30:44 -0300, Willian Padovani Germano wrote:
> >BTW: Download and Screenshots of a first release are available here
> >for those who are interested in exporters:
> >
> >   http://home.arcor.de/tbleicher/exif/index.html
> > 
> >
> Interesting work, but indeed from what you describe your initial design 
> needs to be simplified.

It definitivly had to be simplyfied. I rewrote it from scratch in
the last weeks and my big problems are gone. Or I have found good
workarounds ...

I hope I'll have a new snapshot ready these days.

> >Now the questions:
> >
> >1) I have up to 80 buttons to create at one time.
> >
> From the other email you sent you already found the range, 0 to 15382.  
> It was a last minute fix for issues with misinterpreted events, thanks 
> to Ton's help explaining what ranges we could use.  Thanks for pointing 
> the wrong value in the doc.

Yes. A current release of Blender does work fine with this range
(I didn't test all of the ids, though ;).

Sidenote: To keep track of my ids I implemented my own id counter
          class in 'user space'. It was easy enough so there is
          probably no need for such a function in BPy.

[Draw.Redraw]
> Yes, we should only call redraws when needed, not as a line that always 
> gets executed when the callbacks run.

I've no problems there anymore. The examples in the documentation
do not make this concept obvious, though. 

> I never saw a working example with py threads in Blender, but anyway, 
> you should attack the drawing part and see what could be changed.  Maybe 
> you need a widget added to Blender / BPython itself in C.
> 
> BTW, a while ago Martin DeMello reported he got a new scriptlink event 
> working, listeners:
> http://projects.blender.org/pipermail/bf-committers/2005-May/010727.html
> http://projects.blender.org/pipermail/bf-python/2005-May/002754.html
> Maybe that can be useful for scripts like yours, if you decide to use an 
> external gui lib, and Stani's Spe: http://www.stani.be/python/spe/blog/

I'd like to avoid any external dependencies. If it's not possible to
solve this in BPy I won't do it (not for the core functions components).

At least there is no fundamental reason why threads don't work, so
mayby I'll give it another try. For most of my 'long running processes'
an external daemon process will probably be the best solution. The
interface just has to check if the result is already available and can
go on drawing immediatly. 

> >3) Window.FileSelector() accepts a class method since 2.37. I could only
> >  make this work with methods of the same class that defines "myDrawFunc"
> >  etc. as its methods; ie. the toplevel class of the interface.
> >  
> >  I need to access a FileSelector window in other classes as well.
> >
> Sorry, can't play with this now and have no experience with this kind of 
> access to be able to comment.

This was related to unhealthy use of 'Draw.Redraw()' as well.
There is no problem in the BPy code.


> Maybe you mean deprecation warnings.  For some reason Python's C 
> function to report deprecated functions throws garbage at the console, I 
> haven't investigated.  We can avoid it in bpython by using a printf 
> instead, but for Python's own warnings fixing the script code to get rid 
> of the warning is the way to go.

I have never seen pure Python deprecation warnings do this to my
terminal. But if that was the reason it's fine by me. I don't cause
much warnings now and the output is clean.

garbage in -> garbage out!


> Sure, doc improvements and good examples are always welcome.  To help 
> you just need a recent epydoc to make sure your changes don't break the 
> doc generation.  You might email an example of what you get to document 
> and provide a patch.

Ok. I'll try to come up with a few good examples when I have
time again for it.


Thomas