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

[Willian Padovani Germano]

Hi Thomas,

Excuses for the long delay!

Thomas Bleicher wrote:

>Hello everyone.
>
>I'm new to the list and from reading the archive I hope I've finally
>found the right place to ask my questions.
>  
>
It usually is, it seems most of us are very busy with work, etc. right 
now, but that should change in a few weeks.

>I'm working on some kind of general export interface and try to make
>it as good and instructive for others as I can. It's getting more and
>more complex and I fear I'll have to review its design from the start
>soon. To Make It Right(tm) this time I hope to find some information
>about how things are supposed to work in BPY.
>
>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.

>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.

>2) If my feeble grasp on the Draw process is right, I "register"
>   three functions for drawing and event processing:
>
>        Draw.Register(myDrawFunc, myEvtFunc, myButtonEvtFunc)
>   
>   If "myEvtFunc" and "myButtonEvtFunc" contain a call to Draw.Redraw()
>   this will result in a redraw of the interface elements with every
>   event like ie. a mouse move.
>  
>
Yes, we should only call redraws when needed, not as a line that always 
gets executed when the callbacks run.

>   Currently I do all my stuff to create the interface within
>   "myDrawFunc" which causes noticeable response problems when time
>   consuming calculations have to be done (display lists do help but
>   they have to be generated first which takes it's time as well).
>   
>   Is there an easy way to solve this situation? GUIs use seperate
>   threads for drawing and updating their interfaces, so the drawing
>   has always something to show. I tried to import the threading module
>   but couldn't make it work and I'd prefer to stay with the Blender
>   tools if possible.
>  
>
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/

>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.

>   Why does Blender produce this output and can I get rid of it in
>   a clean way? I use the 2.37 binary tar balls from the download
>   page; no CVS or distribution packages.
>  
>
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.

>5) Even shorter one: If I'll ever get things right I'd like to document
>   these concepts in short exaples which I miss in the API documentation.
>   Could these be included in the docs and how could I help with it?
>  
>
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.

>PS: I learned from the list archive that a new design overhaul is
>    imminent. I'd like to share my experince with the BPy API from
>    the point of view of a somewhat experienced Python user if there
>    is still need to discuss this.
>  
>
Yes, we're still open for discussions.  The initial idea is to fix the 
API's inconsistencies and make the code use newer / better Python/C 
constructs, but feel free to share your opinions.

-- 
Willian