Porting my scripts from 2.49 over to 2.5 . One problem I did not figure out so far is how this call from 2.49 is supposed to be done in 2.5 :
Blender.Window.DrawProgressBar( 0.0, “Doing this and that…” )
I really need this as some of my export scripts can very well take up to half a minute to export everything included.
I am wondering about this as well. Looking at the C source of bpy.ops.fluid.bake I found that Blender has some C functions to update the progress bar. The relevant struct seems to be wmJob (defined in wm_jobs.c). However there does not seem to be any Python interface to work with this class. If it really does not exist, it definitely seems like something that’s worth a feature request. With the console window being disabled by default, there is no other way to give feedback to the user, while a Python script blocks Blender completely.
That’s unfortunately not of help to me. I’m not looking for reporting text but a progress bar showing how much of the process has been complete so far. At the top of the screen in the info panel there is a symbol and next to it sometimes text appears. Maybe there is also a kind of progress bar included in that location like in 2.49 which one can access? The python console really is totally unsuitable for this task.
But that is what it is, a text based progress bar. Did you actually run the code?
I realize you want it to appear in the GUI perhaps you should investigate OpenGL and just draw in the viewport?
It’s clear what that code is doing, similar to wget. But that’s not what I need as you don’t have a python console open all time… especially not in 2.5 with the crappy UI with all the squandered space left and right. I really need it somewhere in the info panel where it also used to be in 2.49 .
I know the OpenGL part quite well but I have no idea where this info-panel is hidden in python nor if it requires an actual Panel subclass (complicated but doable). The documentation on 2.5 python API sucks in various places and one is the obnoxious neglection of possible enumeration parameters in the Panel class. Old coder wisdom: people can read manuals but they can’t fortune tell parameter values.
You could make your own progress bar that would render on the viewport, using the bgl module. Actually with the bgl you can do some super cool graphics on the viewport both 2d and 3d, ideas man has already uploaded a nice doc about it and there many pys out there that use it, and you could even use 2.49 pys as the bgl has remained largely the same. And progress bars are very easy to make actually .
but they can’t fortune tell parameter values
print(dir(myVar))
This yields the same as if you press CTRL+SPACEBAR in the python console (aka auto-completion). The problem is though that this does not show neither:
This is what the docs are for and they lack in that department in some places.
Where’s this doc? I found a couple of things so far but nothing uses BGL in any way or shows if you can access the info panel somehow. It would be good if you could place a Panel up there but the bl_context/bl_region_type/bl_space_type parameters are undocumented so no idea what is possible there.
Hm… I’ll have a look at it. Only problem I see is where it does paint to. Is it just the panel the mouse is above or the entire screen?
EDIT: Took a look at it. It’s not working. The handler grabs the pointer but nothing is painted at all.
EDIT: EDIT: Found another version which does render something. Looks like the context though is the window you call the menu up in with. This is useless for export scripts as they are not called this way. If only we could grab the ENTIRE blender screen and not just a single panel.
Its neither of the two so its not a problem, as as I know. The 2 scripts that I have found and many others that are out there , they are rendering on top of the viewport and image editor. That means that its non destructive it does not affect anything and when the opengl rendering is finished it just disappears leaving everything untouched underneath it. Also the the great new is that it work quite well with bfl which the module responsible for displaying text, so you can both display text and graphics on top of the viewport and because basically bgl is opengl, its blazing fast and super flexible, you could do a million things with it , or some super cool progress bar . You could theoretically even do a preview render on the viewport and it could work real time like a game using nothing more than bgl. However bgl is not a complete opengl implementation though they keep adding opengl stuff all the time.
I will use it for my script for making a library editor for materials that will display image thumbnails of materials on top of the viewport.
by the way blender text editor already comes with a template of a model operator for draw (text => Script templates => Operator Modal Draw) that uses the bgl to draw a trail for the mouse and display text, you should look into it, i think it will help you understand how to make your progress bar have both 2d and text , it wont take you too much time to figure it out as the script is very basic and the bgl is very easy to use.
Figured out that much already too. But all of that is linked to the current context. Problem is with an export script there is none as it uses a sort of file browser but once the script starts it’s gone. So unless I can either paint onto a panel of my choice (aka obtain a context from a Region of choice) or I can paint on the entire blender window this is all futile. I tried already adding the draw callback to Window (bpy.context.window) or Screen (bpy.context.window.screen) the same way as with Region but this insta-crashes Blender. It just seems to be impossible to do and this is a nuisance. 2.49 had a simple progress bar. Why the hell does 2.5 have to throw anything good about 2.49 out of the window and replace it with crap on a stick U_U .
Sorry I missed the part you were talking about an “import script” . Also I think you are not fair here, 2.5 is still far from mature and the progress bar is the least of our concerns, dont compare 2.49 with 2.5 , there has been alot of rewrite with 2.5 and thats a very good thing, actually you should kneel before the blender developer that had the balls to do a rewrite on code, rewrites are as common in programming as comet naked eye sightings. You think that 3d studio max or Maya users will have the luxury of a rewrite on their awful gui in this decade, not even in their wildest dreams.
Progress bar falling through the cracks is a result of those rewrites, even slight changes in code are enough to brake compatibility imagine having a completely new api for python. I have always complained about the wiki being crap, but I also acknowledged that if a well organized wiki was so easy to do then it would have been done by now. Till this day I find it hard to believe that blender is free and open source. We are so lucky.
Now I dont know how blender triggers the progress bar, but if c can do it so can python, you will have however study the code and use ctypes. And of course the question remains do import functions even written in c are able to access the progress bar ?
Another way around it , you could make a progress report using your script gui, a label reporting a % should be enough. I tried it , it works , but it only refresh when the panel is redrawn and the panel is redrawn only when the mouse hovers over it at least with the tool shelf in view3d. Its not ideal that the user should hover the mouse to see the progress but it can work and its not that much of a problem. Afterall if the import is fast , I dont see much of a point for a progress bar. Also this approach allow you to show abit more information, for example if the script gets slow somewhere you will be able or your user to tell what kind of data slows it down or even crash it .
Actually it’s an export script and yes it can run up to 30+ seconds if you export the animation file with all actions in one go. I know very well how it looks like to overhaul an API. The problem here is not the overhaul and some stuff missing in the wake of it it’s the new 2.5 UI which is a slow-down from the fast 2.49 UI. Workflow in 2.5 is <25% of what it had been in 2.49 due to bad design choice. The new data system, UI code and python integration is great but the UI “style change” is a blow in the face. That’s though a problem not belonging in this topic here.
I made myself a script to enumerator regions/areas on screen. I found that ‘INFO’ refers to the info window and ‘HEADER’ to the right place but nothing happens. It seems you can not add any panels there. If I could obtain a context for this region of choice I could BGL hijack the panel during exporting for like a huge progress bar. Problem is only I don’t know how I can get a context of a Region object of my choice.
EDIT: I think I found a solution… testing it now but it looks like this could rock the house as it allows you to go nilly-willy with the info-panel header 
EDIT: EDIT: Looks like I’m stuck. Blender seems to have some bug somewhere and it crashes if I try to run the operator modal. More precisely context.window_manager.modal_handler_add( self ) crashes. Sometimes I can get out a “Memoryblock free: pointer not in memlist” doing things slightly different. Something in the Python binding there seems to be wrong but I don’t know what.
EDIT: EDIT: EDIT: Figured out a way around the problem. Got a working progress bar going. But to use it a bit of continuation magic is required as a progress bar can only be done with a modal operator.
I wont complain if you share your magic with us… 
I’ll see if I can make a python console version out of it. Should not be that difficult. I want though first to implement the pseudo-continuation so it is directly usable as superclass for exporting.