Will module GUI be used again?

Hi
Can anyone tell me if the Blender Module GUI is to be used again?
I know it disappeared after 2.23 but can it not be included in a Blender build, I am sure it is an existing module. Correct me if I am wrong but is it just a case of putting #include <gui.h> in the C code?
GUI is such a neater and cleaner way of inputting a file into a Python script plus would aid backwards compatability.

Cheers

GUI is such a neater and cleaner way of inputting a file into a Python script

What is wrong with Blender.Draw ?

Nothing, but Blender.GUI is a file-open dialog box for python scripts. My IO_Suite.blend depends on it, so I hope someone adds it back. Isn’t it strange how the most useful features are removed for no apparent reason?

Hi,

I’m currently rewriting the Python API for blender. This means removing the code that is currently in Blender and starting from scratch. Removing is easy, and is done already. Get the latest cvs sources and build using the flag --enable-exppython :smiley:
This will enable the new implementation for the Python api. Currently no usefull functionality is in it, but I’m working on that. The plan is to get the Python api to a level where it’s compatible with 2.23. We are not planning to re-implement the 2.10 api, although I will create the new implementation in such a way that it should not be difficult to add the 2.10 api.
I will investigate the possibilities for adding the GUI module, but as far as I know, it’s a 2.10 feature.

Isn’t it strange how the most useful features are removed for no apparent reason?

Well, as far as I know, the only features that have been left out of blender 2.26 is the gameengine and the 2.10 api. The gameengine has been left out because of the problems with the physics engine and the 2.10 api has been left out because we found out we didn’t have the source code. :frowning:

With regards,
Michel

Hi michel,

I’m currently rewriting the Python API for blender. This means removing the code that is currently in Blender and starting from scratch.!

now,…there`s a big job!

Thank you for stepping up to the plate and helping to make blender a better program :smiley:

      dale

Hi

Stupid question maybe.
But why take out the Python?
Surely this will introduce more incompatability problems.
Is it so all the Python can be put in a Python.dll?

Cheers

Hey,

this is not a stupid question at all!

The reason that the current Python api implementation is being replaced by a new implementation, is because of:
[>] Hard to read source code
[>] Gives a lot of problems when building blender (old api is partly written in Python).
[>] The 2.23 api was in the progress of being rewritten, but was interwoven a lot with the older implementation.

After some discussion, we decided that it may be good to start from scratch, take the good parts out of the current implementation and write new parts which are difficult to maintain.

So, the Python api itself is not being taken out of Blender. Don’t worry :slight_smile:

The new implementation is integrated in Blender in such a way that the current implementation will work. Only when we are convinced that the new implementation is fully backward compatible with 2.23, we will remove the current implementation.

With regards,
Michel

I noticed you are using SWIG, doesn’t that include more code than necessary? Not that I would know really, but I have done quite a few python extensions, and I didn’t find it very hard to just handcode it. But then again, I didn’t create new python types (yet), it was all more like python wrappers for C/C++ functions sofar.

Wow…great works,
thx from all MakeHuman team! :smiley:
http://www.kino3d.com/~MakeHuman/

Hi,

Well, I started writing the api using SWIG, because I think that it can save me a lot of time writing the wrappers for functions and types. Unfortunately I found out last weekend that SWIG is unusable for the api defined by blender. There are some functions that have different return types depending on the value requested.
For example think of the Blender.Get function, it can return an integer (current frame), a float (current time), a string (filename). Writing C functions that can be wrapped by SWIG, is (almost) impossible. And thus I decided to remove all SWIG code and do it all by hand.

With regards,
Michel

You don’t have the source? Does this mean Jan Walter, who (I believe) added the GUI module and the 2.10 api, took it with him when he left NaN? Makes me wonder if he left on bad terms. Anyway, I’m glad someone is working on the Python API.

[quote=“scorpius”]

You don’t have the source? Does this mean Jan Walter, who (I believe) added the GUI module and the 2.10 api, took it with him when he left NaN? Makes me wonder if he left on bad terms. Anyway, I’m glad someone is working on the Python API.[/quote]
Hi,

When testing blender a couple of days before release of 2.26, we found out we were missing this part. Instead of waiting longer with the release, we decided to leave it out. Actually, Jan Walter is still somewhat involved with Blender, and I don’t believe he left on bad terms at all!!

With regards,
Michel