[Bf-python] Pure Python GUI

[Theo de Ridder]

Hi Jonathan,

You surely did a nice job, but you are also asking about
the perspective in the long run.
I have thought about this already for years, and my
final conclusion is that integration of a powerful
Python IDE within Blender itself will remain rather primitive
and clumsy. I really like the basic idea of Blenders non-overlapping
windows (are yours overlapping?) but what you need
for an IDE (editing, databrowsing, documenting, debugging, profiling,  
etc)
already fills a complete screen, so integration does not
give much added value, while you have to redo too many available
libraries.

As an oldtimer, unhappy with all of the elegance of Python
gone lost in so many tools (due to copying unneeded complexity from
other language frameworks), I decided about a year ago to finally
realise (hidden in the countryside as an hermit) my old ideas
about an extreme powerful and pythonic IDE. This IDE will
have remote realtime connectors to other applications, including  
Blender,
enabling to work with multiple screens and computers.
It will only be based on standard Python libraries and wxpython. It
exploits the wx.stc (scintilla editor) and wx.aui (a new panes  
framework)
up to their limits and far beyond what is done in any existing tool.
At this moment I am making substantially progress, but due my ambition
to make it complete, it will come out not before the end of this year.
The first release will be a free shareware binary for OS X. Source
will not be free as long as I do not have some reasonable compensation  
for
my enormous amount of unpaid artistic programming efforts.

Theo


On 2 mrt 2008, at 12:55, Jonathan Merritt wrote:

> Greetings Pythonites,
>
> I have heard some rumors about better Python GUI support coming out of
> the Apricot project.  Does anyone know what the plan is in that area,
> and the timeline?  Campbell? :-)
>
> I have been working on a proof-of-concept for a Python GUI that runs
> inside Blender (similar to the goo project, although aiming to be more
> of an all-rounder).  Initially, I have built a component hierarchy,
> drawing canvas and event system that all go together to simulate
> Python panels.  Here is a video of the system in action:
>     http://www.youtube.com/watch?v=tERvnJEKg7o
> The GUI is surprisingly responsive (any "stickyness" is a result of
> screen cast and YouTube).  Some things don't work properly yet, but
> about 98% of the functionality of Blender's button panels is there.
>
> The code is *not* yet ready for public consumption, so I will be
> tidying it up over the next few weeks, aiming at an initial release
> around Easter.  In the mean time, the project is hosted at Google  
> Code:
>     http://pycomponents.googlecode.com
> (Use Source->Browse->Trunk to get to SVN.)
>
> The GUI uses a full component / event model, based on the ideas from
> Java/Swing (although quite modified to become more Python-esque).  I
> don't think I have it all correct yet, but this proof-of-concept shows
> that a system like this can be fast enough to be indistinguishable
> from the C implementation of panels (which was my primary concern).
> Once my python panels have been re-written and documented properly,
> I'll integrate the current Blender.Draw() components into them.
>
> The question is: am I wasting my time with this in the long run, and
> will Python GUIs become *much* better in the near future (with things
> like automated layout, etc.)?  What are the general thoughts?
>
> Thanks,
>
> Jonathan Merritt.
>
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> http://lists.blender.org/mailman/listinfo/bf-python