>I'm trying to understand... was it an alternative interface for
>Blender, or an interface toolkit just happening to sit on top of
>Blender? (or both?)

No its an alternative interface for blender , bgl is nothing more than opengl stuff, but bare minimum opengl 1 stuff. Note that blender uses opengl for its own GUI API but I did not use that api at all. So it is a separate interface. Its basically Morphic , bare bones Morphic, but still Morphic. I was successful in providing a GUI API that is far more flexible compared to the existing Blender python GUI API and excels at custom made guis that the standard gui does not allow. However bgl is slow and quite buggy.

> What really would interest me is your personal opinion on Smalltalk as
> somebody coming from a Python background. That is, once you have more
> experience with it (Smalltalk). I don't know much Python, but
> considered it more than once because of something I didn't find in
> other mainstream languages that I would miss from Smalltalk: named
> parameters. Of course in Smalltalk you don't have that, since the
> method signatures give you that for free ;-)

I dont care about languages any more. I do not care about smalltalk the language. I dont believe language choice matters. There I said it. If smalltalk did not have this amazingly cool environment I would never have left python. I am actually quite happy with python, then one thing I did miss seriously was a good IDE. I used to be a Delphi coder back a decade ago , before being a python coder and Delphi had this amazing IDE in some areas even superior to smalltalk ide and pharo. So I was searching for a very good IDE for python and I found smalltalk, smalltalk has simple syntax like python and the IDE of high quality I came to love in Delphi. So I think it fits like a glove for my needs. Ironically both python and Delphi IDE have been deeply influence by the smalltalk language and enviroment. So it feels kinda of funny after 25 years of messing with coding to go back to the roots of all this.

I am sure I am going to miss python's stability and library support but I think I am trading them off for something superior.



> Conceptually I find Lisp also very interesting. But anytime I evaluate
> going the Lisp route I find myself planning to reach first some
> Lisp-based-Smalltalk syntax & semantics and then I say: why waste my
> time if there *is* already Smalltalk, waiting to be used? :-)

I dont think its hard to see that Lisp is THE language , well more like a family of languages. Lispers can be snobbish about other languages but they are correct lisp is superior even to smalltalk. There is little doubt in that. But again I do not believe language choice is that important , if it was people would not be making awesome software with other languages which they do. Its ironic because AI an area that lisp dominated is now dominated by python that goes fundamentally against the lisp philosophy and something that lispers quite correctly consider far inferior to lisp. Once again its the environment that attracted me , in this case emacs. Even though I decided to go with Pharo, Emacs is far from being out of the equation. I am still planning bringing emacs like text editing features to pharo for Ephestos. Long term plan but it is there.


> I don't get it... which part will you port from Python to Smalltalk,
> and which part you don't need/want to port?
None. This is no longer a python project its pure smalltalk. I may create a python socket bridge for smalltalk to use python libraries and to access programms like Blender and mypaint etc. but is not big priority right now. Ephestos is basically an effort to improve pharo and make it more inviting to newcomers. If I can offer tools also useful to veteran smalltalkers that will be double win for me.


> And Blender would... render 3d? (whilst the interface would be on the
> Pharo side?)

Yes , Ephestos and hence pharo would be able to control blender completely.

 > The idea of (socket) "brides" to other languages / runtimes always
> made sense to me. At least short-term to break the library/devs cycle.
> I don't know if this idea was evaluated by the community. Recently
> there was an announcement of a bridge to a XUL (Mozilla) -based
> frontend, with Smalltalk back-end, using Seaside's continuations. So
> it should be easier as ever.

my bridge already works and have been tested between 2 blenders , blender and cpython 3 , blender and cpython 2 and blender and pypy. Its in the proteas folder in the link I provided. So it just waits for me to port it to pharo XMLRPC library. Its just a matter of me getting familiar with pharo.

 > I very much liked what Stef wrote yesterday, it got me thinking: start
> small and work steadily...
Yes I agree with Stef of course. I dont plan to do anything very complicated most of the tools that I am planning are small additions to pharo . The only thing that takes time is for me to become familiar with pharo libraries, as soon as I do that I will be able to provide one tool after another in relative quick speed.

 > Good to see that you have such long-term plans! :-)

I am not doing this just for pharo, I plan to use these tools for making art. My goal is to become a professional artist and I would love to build my owns tools and find alternative ways of artistic expression. Thus the long term process of the project.

To give you a clear idea , I am trying to achieve something similar to this

http://openendedgroup.com/field/OverviewBanners2.html

At first Ephestos was supposed to be an extension of Field. But their support was non existant (the original developer obviously are busy with art projects ) and I needed help to understand the code, so I chose to go down the pharo route because if I had any problems I had much better chances to get it fixed in pharo than getting it fixed in Field. But Ephestos and Field are two projects with very similar goals.

Thank you for your interest I will keep you posted with any significant progress.