The initial plan was to divide the project , Ephestos, to 3 parts, 3
ages as I call them cause they are made one after the other as the one
depends on another.
The first is Morpheas Age which is the first and is the GUI.
"Morpheas" name is not accidental because more or less is a port of
Morphic GUI. Morphic for those are not aware of is the first effort of
visual coding around 40 years ago from the first programming language
to implement object orientation the programming language self. Morphic
is a GUI that is not just focused on some widgets that the user
operates , what separates it from the rest is that anything can be a
morph including language atoms (elements of the language syntax) . The
morph class is the big super class that all other morphs inherit from,
even code can be represented using morphs. For morphic its really easy
to do so because self and later smalltalk understand only objects. For
example in smalltalk an "if" , and even a "for" or "while" loop is an
object. Because a morph is of course an instance object , then a morph
can map to any other object. Smalltalk took the idea of morphic even
further and of course extend it with the peak being Squeak a modern
implementation of smalltalk and Pharo that run currently on all
platforms. Morpheas is an ancient greek god (aka Morpheus) that could
take any shape, which is also the prime goal of Morphic , to represent
everything and anything.
So the idea of Morpheas is to map morphic and bring it to python.
The second age is Proteas that maps morphs to code , creating visual
code. Every single language atom as I already explained can be a
morph , and morph can embed other morph , so a morph can a a simple
"if" and even a complete application with its gui. I have not touched
Proteas but because it deeply depend on Morpheas the foundations of
Proteas are already ready.
The third age is Orpheas , which is basically nothing more than a GUI
and visual code front end for Supercollider.
At the moment I have implemented the foundation of Morpheas, meaning
the Morph class (Morph is monolithic so it even handles its own
events) , the World morph which is the morph that contains all other
morphs (there was the idea and its currently possible to have multiple
worlds) , the node which handles all the parenting of morph (a morph
can be a child of another morph and one can ask a morph for its
children and parents and it will reply ... deeply influnced by
smalltalk messages , see also objective c that borrows this concept
from smalltalk ) then Hand morph that represent the mouse cursor and
it handles Blender events like mouse keyboard and others as long as
the cursor (hand morph) is on top of a morph thus making possible to
use Morpheas together with the existing beldner gui without the one
blocking the other (If the the hand is not on top of a morph it passes
all events back to blender and of course blender responds to them
appropriately ) and of course the hand trigger the proper events of a
Morph that are nothing more than Morph class methods. Currently its
possible to move morph by mouse. There is also text morph both single
line and multiline , input text morph ( called stringfield morph, does
not work as well I would like it to work but I am improving it right
now) , a basic menu morph functionality , wip button morph
functionality and others. At the moment it looks ugly as hell , but
cosmetic was not my prime concern for such early stage. Most of the
code is a port from pymorphic.py by another author so I dont claim
that I made all that myself , I just edit, test, modify and extend
appropriately. Another coder and friend has helped me trememdously
with the code.
So to conclude I have already an addon that make some extremely
basic , limited GUIs and it uses Blender bgl for rendering. Blender
bgl is tapping into the drawing of blender windows, its nothing more
than opengl wrapping so there are no big surprises there. So morpheas
drawing is all pure opengl 1 /2 calls.
Field already is doing what I wanted to do with Proteas extremely
well. The visual code and the live coding part and this is the one
thing that interests me deeply. My only problem is how to bring this
to blender or should I just port Ephestos to field and call it a day.
Porting Moprheas is fairly easy since I use only pure python code (if
you exclude the fact that is python 3 code so it may need some extra
care) and even the draw calls which are a small part of the code is
I am thinking of a Ephestos as a field plugin if you want or just
something that works inside field that will be able to generate
blender addons. As I said its still early and I am just brainstorming.
I am happy to inform you that I have download field, it works so far
ok on Macos Lion and I am in the process of reading documentation and
understanding its mechanics.
Sorry for the long post but Morphic takes some explaining because
though extremely old , is very different to existing GUIs and
If you want to take a look at modern version of Morphic give Pharo a
try , which is the most modern incarnation ---> http://www.pharo-project.org/home
Many of the tricks that field can do , pharo can do already (and both
self and smalltalk could do already back in the 70s as it was one of
the first software to implement GUIs and mouse support) , the only
problem is that is based on smalltalk and not python.
So I am really trying to figure out how to bring blender closer to
field , and not so much field to Ephestos , cause since Ephestos aims
at pure python, porting it is not a big issue. I dont expect you to
do the coding for me, if you can point me to the right direction and
advice me (from the field side of course) thats all the help I will
Are there any plans to support cpython 3 as well ?