The Dilemma: Building a Futuristic GUI for Ephestos
So far Ephestos has gone quite well and I am satisfied with my progress so far. I think its time to start thinking about a GUI for it. I was always very interested in creating futuristic GUIs like this http://vimeo.com/68113915 At first I thought about a project "Hyperion" to explore the idea of creating a vector editor in pharo, it was a fun experiment to see also the potential of Athens. However the more I think about the more unnecessary seems to me the use of SVG graphics. Back then I did not have integration with Blender so my idea now is to drop Hyperion and instead make the GUI inside Blender and export it as a set of animatable bitmaps. My dilemma is what graphic library to use : a) Morphic b) Athens or c)Roassal What I need is the following: 1) Ability to render small bitmaps fast and do animation , big bitmaps will be mostly static used for backgrounds 2) Basic interaction ability , mouse left and right click , mouse drag , mouse click press and release events. Of course keyboard events too 3) The ability to scale up and down images with minimum distortion 4) The ability to render text smoothly and scale it up and down 5) Transparency also plays a big role in layering those images I think so far that Roassal is the best candidate because it also integrates well with Morphic and Athens. Also I may still need some vector graphics for example charts or dynamic graphics that will depend on user input that would not be suitable to do strictly with SVG so the morphic option is getting weaker and weaker. I wanted a second opinion though since you are much more experienced than me. I may also create an API for creating such GUIs with Blender for Pharo. Another thing I am wondering is how to download all these images to Pharo , what you guys use to do download big data to Pharo , maybe Fuel ?
Hi, Le 13/09/2014 11:05, kilon alios a écrit :
have integration with Blender so my idea now is to drop Hyperion and instead make the GUI inside Blender and export it as a set of animatable bitmaps.
I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI?
My dilemma is what graphic library to use : a) Morphic b) Athens or c)Roassal
I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing.
What I need is the following:
1) Ability to render small bitmaps fast and do animation , big bitmaps will be mostly static used for backgrounds
You can do that from Athens over Morphc canvas.
2) Basic interaction ability , mouse left and right click , mouse drag , mouse click press and release events. Of course keyboard events too
no problem
3) The ability to scale up and down images with minimum distortion
For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result.
4) The ability to render text smoothly and scale it up and down
That's may be more tricky. I have issue to deal with when migrating DrGeo to Athens regarding text. I forgot about the details, but the hacks are in the Morph object for text rendering in DrGeo. Igor was very kind to help accurately on those problems.
5) Transparency also plays a big role in layering those images
Never dig on that, I may need that for DrGeo when importing bitmap.
I think so far that Roassal is the best candidate because it also integrates well with Morphic and Athens. Also I may still need some vector graphics for example charts or dynamic graphics that will depend on user input that would not be suitable to do strictly with SVG so the morphic option is getting weaker and weaker.
Sure. The downpoint, you will depend on one additional layer.
I wanted a second opinion though since you are much more experienced than me.
I may also create an API for creating such GUIs with Blender for Pharo.
Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious.
Another thing I am wondering is how to download all these images to Pharo , what you guys use to do download big data to Pharo , maybe Fuel ?
Images=pictures? Use plain PNG files! Use fuel to store the state of your application objects. Good work! Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu
" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? " yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file. So basically its a lot like the average games out there. "I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing." ok "For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result." I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things. "Sure. The downpoint, you will depend on one additional layer." dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large. "Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious." Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically. So basically you will be using Blender as a GUI designer. "Use fuel to store the state of your application objects." ah nice so fuel is a good candidate. I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
Hi another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work. http://youtu.be/c_D2YJSNj8I Almost a decade ago I did some ruby bindings by hand. It was working out of the box Bye Enno
Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios@gmail.com>:
" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? "
yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file.
So basically its a lot like the average games out there.
"I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing."
ok
"For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."
I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things.
"Sure. The downpoint, you will depend on one additional layer."
dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large.
"Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious."
Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically.
So basically you will be using Blender as a GUI designer.
"Use fuel to store the state of your application objects."
ah nice so fuel is a good candidate.
I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
Moving data between Pharo and Blender via Ephestos is not a problem, just something I need to sit down and code. I can already access all operators and all propertied of blender from pharo via Ephestos. What that mean is that you can manipulate Blender from pharo any way you want. Verse is a data protocol to move data around, it has some extra security but that is not relevant to Ephestos as currently my goal is local use. So both projects have very different goals. I dont also care supporting any other apps , right now , besides pharo and blender or having multiple users sharing data with each other. Saying that yes Ephestos can use Verse because it basically can use any python library so if you really want to integrate Verse into your workflow because you collaborate with multiple users using different applications you can use Verse's python api via Ephestos from Pharo. Verse is a C library with python wrappers. So there is not need for pharo wrappers if you use Ephestos. looks like the original author is still developing it --> http://verse.github.io/ On Sat, Sep 13, 2014 at 9:11 PM, Enrico Schwass <ennoausberlin@mac.com> wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
Almost a decade ago I did some ruby bindings by hand. It was working out of the box
Bye Enno
Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios@gmail.com>:
" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? "
yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file.
So basically its a lot like the average games out there.
"I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing."
ok
"For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."
I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things.
"Sure. The downpoint, you will depend on one additional layer."
dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large.
"Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious."
Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically.
So basically you will be using Blender as a GUI designer.
"Use fuel to store the state of your application objects."
ah nice so fuel is a good candidate.
I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado. Stef
Almost a decade ago I did some ruby bindings by hand. It was working out of the box
Bye Enno
Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>>:
" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? "
yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file.
So basically its a lot like the average games out there.
"I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing."
ok
"For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."
I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things.
"Sure. The downpoint, you will depend on one additional layer."
dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large.
"Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious."
Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically.
So basically you will be using Blender as a GUI designer.
"Use fuel to store the state of your application objects."
ah nice so fuel is a good candidate.
I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
Hello, On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
I have an adapted version of Swig for Pharo NativeBoost here: https://github.com/ronsaldo/swig Currently I am using it to generate my Bullet bindings (available here: https://github.com/ronsaldo/bullet-pharo) that can be used as an example of using Swig. I still have to improve more my Swig generator, by writing documentation and fixing some bugs. Greetings, Ronie 2014-09-13 16:11 GMT-03:00 stepharo <stepharo@free.fr>:
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
Stef
Almost a decade ago I did some ruby bindings by hand. It was working out of the box
Bye Enno
Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios@gmail.com>:
" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? "
yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file.
So basically its a lot like the average games out there.
"I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing."
ok
"For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."
I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things.
"Sure. The downpoint, you will depend on one additional layer."
dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large.
"Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious."
Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically.
So basically you will be using Blender as a GUI designer.
"Use fuel to store the state of your application objects."
ah nice so fuel is a good candidate.
I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
Ronie when you ready I can help writting a chapter for the nex book. Stef On 13/9/14 21:42, Ronie Salgado wrote:
Hello,
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
I have an adapted version of Swig for Pharo NativeBoost here: https://github.com/ronsaldo/swig
Currently I am using it to generate my Bullet bindings (available here: https://github.com/ronsaldo/bullet-pharo) that can be used as an example of using Swig. I still have to improve more my Swig generator, by writing documentation and fixing some bugs.
Greetings, Ronie
2014-09-13 16:11 GMT-03:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
Stef
Almost a decade ago I did some ruby bindings by hand. It was working out of the box
Bye Enno
Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>>:
" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? "
yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file.
So basically its a lot like the average games out there.
"I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing."
ok
"For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."
I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things.
"Sure. The downpoint, you will depend on one additional layer."
dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large.
"Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious."
Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically.
So basically you will be using Blender as a GUI designer.
"Use fuel to store the state of your application objects."
ah nice so fuel is a good candidate.
I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
so I tried to animate in Roassal having two different images display with a delay for few millisecond but it only displays the second image with this code form1 :=Form fromFileNamed:'/Users/kilon/Pictures/pharo.png'. form2 :=Form fromFileNamed:'/Users/kilon/Pictures/box.png'. v := RTView new. c := v canvas. s := TRBitmapShape new. s form: form1. c addShape: s. v open. (1 to: 100) do: [ :index| s form: form1. s signalUpdate . "(Delay forMilliseconds: 1000 ) wait." s form: form2. s signalUpdate . (Delay forMilliseconds: 1000) wait.]. I looked into RTAnimation but dont know how to use it for this example. Any help ? Does Roassal 2 support such animations ? if I do s form: and then s signalUpdate for each form separately it works fine but inside the loops does not seem to work , I tried bigger delays with no effect. On Sun, Sep 14, 2014 at 10:57 AM, stepharo <stepharo@free.fr> wrote:
Ronie when you ready I can help writting a chapter for the nex book.
Stef
On 13/9/14 21:42, Ronie Salgado wrote:
Hello,
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
I have an adapted version of Swig for Pharo NativeBoost here: https://github.com/ronsaldo/swig
Currently I am using it to generate my Bullet bindings (available here: https://github.com/ronsaldo/bullet-pharo) that can be used as an example of using Swig. I still have to improve more my Swig generator, by writing documentation and fixing some bugs.
Greetings, Ronie
2014-09-13 16:11 GMT-03:00 stepharo <stepharo@free.fr>:
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
Stef
Almost a decade ago I did some ruby bindings by hand. It was working out of the box
Bye Enno
Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios@gmail.com>:
" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? "
yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file.
So basically its a lot like the average games out there.
"I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing."
ok
"For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."
I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things.
"Sure. The downpoint, you will depend on one additional layer."
dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large.
"Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious."
Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically.
So basically you will be using Blender as a GUI designer.
"Use fuel to store the state of your application objects."
ah nice so fuel is a good candidate.
I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
I remember that there was an animated gif support. Now I do not remember exactly. for roassal2 have a look at the viva classes: this is the animation frameworks that igor designed. Stef On 14/9/14 10:22, kilon alios wrote:
so I tried to animate in Roassal having two different images display with a delay for few millisecond but it only displays the second image with this code
form1 :=Form fromFileNamed:'/Users/kilon/Pictures/pharo.png'. form2 :=Form fromFileNamed:'/Users/kilon/Pictures/box.png'. v := RTView new. c := v canvas. s := TRBitmapShape new. s form: form1. c addShape: s. v open.
(1 to: 100) do: [ :index| s form: form1. s signalUpdate . "(Delay forMilliseconds: 1000 ) wait." s form: form2. s signalUpdate . (Delay forMilliseconds: 1000) wait.].
I looked into RTAnimation but dont know how to use it for this example. Any help ? Does Roassal 2 support such animations ?
if I do s form: and then s signalUpdate for each form separately it works fine but inside the loops does not seem to work , I tried bigger delays with no effect.
On Sun, Sep 14, 2014 at 10:57 AM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Ronie when you ready I can help writting a chapter for the nex book.
Stef
On 13/9/14 21:42, Ronie Salgado wrote:
Hello,
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
I have an adapted version of Swig for Pharo NativeBoost here: https://github.com/ronsaldo/swig
Currently I am using it to generate my Bullet bindings (available here: https://github.com/ronsaldo/bullet-pharo) that can be used as an example of using Swig. I still have to improve more my Swig generator, by writing documentation and fixing some bugs.
Greetings, Ronie
2014-09-13 16:11 GMT-03:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
Stef
Almost a decade ago I did some ruby bindings by hand. It was working out of the box
Bye Enno
Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>>:
" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? "
yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file.
So basically its a lot like the average games out there.
"I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing."
ok
"For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."
I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things.
"Sure. The downpoint, you will depend on one additional layer."
dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large.
"Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious."
Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically.
So basically you will be using Blender as a GUI designer.
"Use fuel to store the state of your application objects."
ah nice so fuel is a good candidate.
I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
2014-09-14 11:32 GMT+02:00 stepharo <stepharo@free.fr>:
I remember that there was an animated gif support. Now I do not remember exactly.
At least in squeak there is an AnimatedImageMorph, that can load and display animated gifs. That works and is quite fast even for multiple instances. But of course no (alpha-)transparency
for roassal2 have a look at the viva classes: this is the animation frameworks that igor designed.
Stef
On 14/9/14 10:22, kilon alios wrote:
so I tried to animate in Roassal having two different images display with a delay for few millisecond but it only displays the second image with this code
form1 :=Form fromFileNamed:'/Users/kilon/Pictures/pharo.png'. form2 :=Form fromFileNamed:'/Users/kilon/Pictures/box.png'. v := RTView new. c := v canvas. s := TRBitmapShape new. s form: form1. c addShape: s. v open.
(1 to: 100) do: [ :index| s form: form1. s signalUpdate . "(Delay forMilliseconds: 1000 ) wait." s form: form2. s signalUpdate . (Delay forMilliseconds: 1000) wait.].
I looked into RTAnimation but dont know how to use it for this example. Any help ? Does Roassal 2 support such animations ?
if I do s form: and then s signalUpdate for each form separately it works fine but inside the loops does not seem to work , I tried bigger delays with no effect.
On Sun, Sep 14, 2014 at 10:57 AM, stepharo <stepharo@free.fr> wrote:
Ronie when you ready I can help writting a chapter for the nex book.
Stef
On 13/9/14 21:42, Ronie Salgado wrote:
Hello,
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
I have an adapted version of Swig for Pharo NativeBoost here: https://github.com/ronsaldo/swig
Currently I am using it to generate my Bullet bindings (available here: https://github.com/ronsaldo/bullet-pharo) that can be used as an example of using Swig. I still have to improve more my Swig generator, by writing documentation and fixing some bugs.
Greetings, Ronie
2014-09-13 16:11 GMT-03:00 stepharo <stepharo@free.fr>:
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
Stef
Almost a decade ago I did some ruby bindings by hand. It was working out of the box
Bye Enno
Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios@gmail.com>:
" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? "
yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file.
So basically its a lot like the average games out there.
"I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing."
ok
"For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."
I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things.
"Sure. The downpoint, you will depend on one additional layer."
dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large.
"Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious."
Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically.
So basically you will be using Blender as a GUI designer.
"Use fuel to store the state of your application objects."
ah nice so fuel is a good candidate.
I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
yeah I am afraid transparency is very important to me On Sun, Sep 14, 2014 at 1:34 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-14 11:32 GMT+02:00 stepharo <stepharo@free.fr>:
I remember that there was an animated gif support. Now I do not remember exactly.
At least in squeak there is an AnimatedImageMorph, that can load and display animated gifs. That works and is quite fast even for multiple instances. But of course no (alpha-)transparency
for roassal2 have a look at the viva classes: this is the animation frameworks that igor designed.
Stef
On 14/9/14 10:22, kilon alios wrote:
so I tried to animate in Roassal having two different images display with a delay for few millisecond but it only displays the second image with this code
form1 :=Form fromFileNamed:'/Users/kilon/Pictures/pharo.png'. form2 :=Form fromFileNamed:'/Users/kilon/Pictures/box.png'. v := RTView new. c := v canvas. s := TRBitmapShape new. s form: form1. c addShape: s. v open.
(1 to: 100) do: [ :index| s form: form1. s signalUpdate . "(Delay forMilliseconds: 1000 ) wait." s form: form2. s signalUpdate . (Delay forMilliseconds: 1000) wait.].
I looked into RTAnimation but dont know how to use it for this example. Any help ? Does Roassal 2 support such animations ?
if I do s form: and then s signalUpdate for each form separately it works fine but inside the loops does not seem to work , I tried bigger delays with no effect.
On Sun, Sep 14, 2014 at 10:57 AM, stepharo <stepharo@free.fr> wrote:
Ronie when you ready I can help writting a chapter for the nex book.
Stef
On 13/9/14 21:42, Ronie Salgado wrote:
Hello,
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
I have an adapted version of Swig for Pharo NativeBoost here: https://github.com/ronsaldo/swig
Currently I am using it to generate my Bullet bindings (available here: https://github.com/ronsaldo/bullet-pharo) that can be used as an example of using Swig. I still have to improve more my Swig generator, by writing documentation and fixing some bugs.
Greetings, Ronie
2014-09-13 16:11 GMT-03:00 stepharo <stepharo@free.fr>:
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
Stef
Almost a decade ago I did some ruby bindings by hand. It was working out of the box
Bye Enno
Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios@gmail.com>:
" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? "
yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file.
So basically its a lot like the average games out there.
"I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing."
ok
"For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."
I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things.
"Sure. The downpoint, you will depend on one additional layer."
dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large.
"Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious."
Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically.
So basically you will be using Blender as a GUI designer.
"Use fuel to store the state of your application objects."
ah nice so fuel is a good candidate.
I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
Why not use Woden? Phil Le 14 sept. 2014 12:51, "kilon alios" <kilon.alios@gmail.com> a écrit :
yeah I am afraid transparency is very important to me
On Sun, Sep 14, 2014 at 1:34 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-14 11:32 GMT+02:00 stepharo <stepharo@free.fr>:
I remember that there was an animated gif support. Now I do not remember exactly.
At least in squeak there is an AnimatedImageMorph, that can load and display animated gifs. That works and is quite fast even for multiple instances. But of course no (alpha-)transparency
for roassal2 have a look at the viva classes: this is the animation frameworks that igor designed.
Stef
On 14/9/14 10:22, kilon alios wrote:
so I tried to animate in Roassal having two different images display with a delay for few millisecond but it only displays the second image with this code
form1 :=Form fromFileNamed:'/Users/kilon/Pictures/pharo.png'. form2 :=Form fromFileNamed:'/Users/kilon/Pictures/box.png'. v := RTView new. c := v canvas. s := TRBitmapShape new. s form: form1. c addShape: s. v open.
(1 to: 100) do: [ :index| s form: form1. s signalUpdate . "(Delay forMilliseconds: 1000 ) wait." s form: form2. s signalUpdate . (Delay forMilliseconds: 1000) wait.].
I looked into RTAnimation but dont know how to use it for this example. Any help ? Does Roassal 2 support such animations ?
if I do s form: and then s signalUpdate for each form separately it works fine but inside the loops does not seem to work , I tried bigger delays with no effect.
On Sun, Sep 14, 2014 at 10:57 AM, stepharo <stepharo@free.fr> wrote:
Ronie when you ready I can help writting a chapter for the nex book.
Stef
On 13/9/14 21:42, Ronie Salgado wrote:
Hello,
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
I have an adapted version of Swig for Pharo NativeBoost here: https://github.com/ronsaldo/swig
Currently I am using it to generate my Bullet bindings (available here: https://github.com/ronsaldo/bullet-pharo) that can be used as an example of using Swig. I still have to improve more my Swig generator, by writing documentation and fixing some bugs.
Greetings, Ronie
2014-09-13 16:11 GMT-03:00 stepharo <stepharo@free.fr>:
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
Stef
Almost a decade ago I did some ruby bindings by hand. It was working out of the box
Bye Enno
Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios@gmail.com>:
" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? "
yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file.
So basically its a lot like the average games out there.
"I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing."
ok
"For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."
I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things.
"Sure. The downpoint, you will depend on one additional layer."
dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large.
"Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious."
Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically.
So basically you will be using Blender as a GUI designer.
"Use fuel to store the state of your application objects."
ah nice so fuel is a good candidate.
I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
what ? where ? how ? ;) I can use anything that is documented and keep its windows inside pharo window. Looks like I will be sticking with plain morphic for now I have not seen any substantial benefit in all other graphic libraries. I have to investigate NBOpenGL but it feels like an overkill for me and last time I tried it I had all sort of problems with it and my graphic card. Have no issue using Woden but if its not documented at all, I will need examples that actually show me how to do this. But I feel the problem I am facing performance wise is at the core of Pharo, its just that pharo is not able to handle big animations. But I will keep investigating my options. I could go for more static GUI its not such a big issue and keep animations to a minimum. On Sun, Sep 14, 2014 at 3:13 PM, phil@highoctane.be <phil@highoctane.be> wrote:
Why not use Woden?
Phil Le 14 sept. 2014 12:51, "kilon alios" <kilon.alios@gmail.com> a écrit :
yeah I am afraid transparency is very important to me
On Sun, Sep 14, 2014 at 1:34 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-14 11:32 GMT+02:00 stepharo <stepharo@free.fr>:
I remember that there was an animated gif support. Now I do not remember exactly.
At least in squeak there is an AnimatedImageMorph, that can load and display animated gifs. That works and is quite fast even for multiple instances. But of course no (alpha-)transparency
for roassal2 have a look at the viva classes: this is the animation frameworks that igor designed.
Stef
On 14/9/14 10:22, kilon alios wrote:
so I tried to animate in Roassal having two different images display with a delay for few millisecond but it only displays the second image with this code
form1 :=Form fromFileNamed:'/Users/kilon/Pictures/pharo.png'. form2 :=Form fromFileNamed:'/Users/kilon/Pictures/box.png'. v := RTView new. c := v canvas. s := TRBitmapShape new. s form: form1. c addShape: s. v open.
(1 to: 100) do: [ :index| s form: form1. s signalUpdate . "(Delay forMilliseconds: 1000 ) wait." s form: form2. s signalUpdate . (Delay forMilliseconds: 1000) wait.].
I looked into RTAnimation but dont know how to use it for this example. Any help ? Does Roassal 2 support such animations ?
if I do s form: and then s signalUpdate for each form separately it works fine but inside the loops does not seem to work , I tried bigger delays with no effect.
On Sun, Sep 14, 2014 at 10:57 AM, stepharo <stepharo@free.fr> wrote:
Ronie when you ready I can help writting a chapter for the nex book.
Stef
On 13/9/14 21:42, Ronie Salgado wrote:
Hello,
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
I have an adapted version of Swig for Pharo NativeBoost here: https://github.com/ronsaldo/swig
Currently I am using it to generate my Bullet bindings (available here: https://github.com/ronsaldo/bullet-pharo) that can be used as an example of using Swig. I still have to improve more my Swig generator, by writing documentation and fixing some bugs.
Greetings, Ronie
2014-09-13 16:11 GMT-03:00 stepharo <stepharo@free.fr>:
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
Stef
Almost a decade ago I did some ruby bindings by hand. It was working out of the box
Bye Enno
Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios@gmail.com>:
" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? "
yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file.
So basically its a lot like the average games out there.
"I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing."
ok
"For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."
I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things.
"Sure. The downpoint, you will depend on one additional layer."
dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large.
"Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious."
Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically.
So basically you will be using Blender as a GUI designer.
"Use fuel to store the state of your application objects."
ah nice so fuel is a good candidate.
I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
Why should he use it, now? I mean, is there a stable API? Or a roadmap ? Sometimes it is a bit dangerous to trust on "bleeding edge" pharo frameworks. I did some work based on Roassal3D just to found out there won't be any further development. The same happens with Roassal and GraphET. The same can happen with Woden too :) 2014-09-14 14:13 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
Why not use Woden?
Phil Le 14 sept. 2014 12:51, "kilon alios" <kilon.alios@gmail.com> a écrit :
yeah I am afraid transparency is very important to me
On Sun, Sep 14, 2014 at 1:34 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-14 11:32 GMT+02:00 stepharo <stepharo@free.fr>:
I remember that there was an animated gif support. Now I do not remember exactly.
At least in squeak there is an AnimatedImageMorph, that can load and display animated gifs. That works and is quite fast even for multiple instances. But of course no (alpha-)transparency
for roassal2 have a look at the viva classes: this is the animation frameworks that igor designed.
Stef
On 14/9/14 10:22, kilon alios wrote:
so I tried to animate in Roassal having two different images display with a delay for few millisecond but it only displays the second image with this code
form1 :=Form fromFileNamed:'/Users/kilon/Pictures/pharo.png'. form2 :=Form fromFileNamed:'/Users/kilon/Pictures/box.png'. v := RTView new. c := v canvas. s := TRBitmapShape new. s form: form1. c addShape: s. v open.
(1 to: 100) do: [ :index| s form: form1. s signalUpdate . "(Delay forMilliseconds: 1000 ) wait." s form: form2. s signalUpdate . (Delay forMilliseconds: 1000) wait.].
I looked into RTAnimation but dont know how to use it for this example. Any help ? Does Roassal 2 support such animations ?
if I do s form: and then s signalUpdate for each form separately it works fine but inside the loops does not seem to work , I tried bigger delays with no effect.
On Sun, Sep 14, 2014 at 10:57 AM, stepharo <stepharo@free.fr> wrote:
Ronie when you ready I can help writting a chapter for the nex book.
Stef
On 13/9/14 21:42, Ronie Salgado wrote:
Hello,
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
I have an adapted version of Swig for Pharo NativeBoost here: https://github.com/ronsaldo/swig
Currently I am using it to generate my Bullet bindings (available here: https://github.com/ronsaldo/bullet-pharo) that can be used as an example of using Swig. I still have to improve more my Swig generator, by writing documentation and fixing some bugs.
Greetings, Ronie
2014-09-13 16:11 GMT-03:00 stepharo <stepharo@free.fr>:
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
Stef
Almost a decade ago I did some ruby bindings by hand. It was working out of the box
Bye Enno
Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios@gmail.com>:
" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? "
yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file.
So basically its a lot like the average games out there.
"I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing."
ok
"For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."
I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things.
"Sure. The downpoint, you will depend on one additional layer."
dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large.
"Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious."
Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically.
So basically you will be using Blender as a GUI designer.
"Use fuel to store the state of your application objects."
ah nice so fuel is a good candidate.
I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
Do you know anything better for futuristic UIs at the moment? I guess that we aren't talking about commercial dev here. And if we would rely on everything being documented in Pharo, errr, we wouldn't go too far. That being said, there are plenty of examples in the Woden code. Phil Le 14 sept. 2014 16:28, "Nicolai Hess" <nicolaihess@web.de> a écrit :
Why should he use it, now? I mean, is there a stable API? Or a roadmap ?
Sometimes it is a bit dangerous to trust on "bleeding edge" pharo frameworks. I did some work based on Roassal3D just to found out there won't be any further development. The same happens with Roassal and GraphET. The same can happen with Woden too :)
2014-09-14 14:13 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
Why not use Woden?
Phil Le 14 sept. 2014 12:51, "kilon alios" <kilon.alios@gmail.com> a écrit :
yeah I am afraid transparency is very important to me
On Sun, Sep 14, 2014 at 1:34 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-14 11:32 GMT+02:00 stepharo <stepharo@free.fr>:
I remember that there was an animated gif support. Now I do not remember exactly.
At least in squeak there is an AnimatedImageMorph, that can load and display animated gifs. That works and is quite fast even for multiple instances. But of course no (alpha-)transparency
for roassal2 have a look at the viva classes: this is the animation frameworks that igor designed.
Stef
On 14/9/14 10:22, kilon alios wrote:
so I tried to animate in Roassal having two different images display with a delay for few millisecond but it only displays the second image with this code
form1 :=Form fromFileNamed:'/Users/kilon/Pictures/pharo.png'. form2 :=Form fromFileNamed:'/Users/kilon/Pictures/box.png'. v := RTView new. c := v canvas. s := TRBitmapShape new. s form: form1. c addShape: s. v open.
(1 to: 100) do: [ :index| s form: form1. s signalUpdate . "(Delay forMilliseconds: 1000 ) wait." s form: form2. s signalUpdate . (Delay forMilliseconds: 1000) wait.].
I looked into RTAnimation but dont know how to use it for this example. Any help ? Does Roassal 2 support such animations ?
if I do s form: and then s signalUpdate for each form separately it works fine but inside the loops does not seem to work , I tried bigger delays with no effect.
On Sun, Sep 14, 2014 at 10:57 AM, stepharo <stepharo@free.fr> wrote:
Ronie when you ready I can help writting a chapter for the nex book.
Stef
On 13/9/14 21:42, Ronie Salgado wrote:
Hello,
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
I have an adapted version of Swig for Pharo NativeBoost here: https://github.com/ronsaldo/swig
Currently I am using it to generate my Bullet bindings (available here: https://github.com/ronsaldo/bullet-pharo) that can be used as an example of using Swig. I still have to improve more my Swig generator, by writing documentation and fixing some bugs.
Greetings, Ronie
2014-09-13 16:11 GMT-03:00 stepharo <stepharo@free.fr>:
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
Stef
Almost a decade ago I did some ruby bindings by hand. It was working out of the box
Bye Enno
Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios@gmail.com>:
" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? "
yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file.
So basically its a lot like the average games out there.
"I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing."
ok
"For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."
I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things.
"Sure. The downpoint, you will depend on one additional layer."
dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large.
"Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious."
Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically.
So basically you will be using Blender as a GUI designer.
"Use fuel to store the state of your application objects."
ah nice so fuel is a good candidate.
I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
Plenty ? no A few ? yes Woden is certainly a project that I want it to be successful and keep going forward but at the moment I can't say its usable when each time I resize the window it corrupts the viewport. No offense intended but lately the more I dive inside Pharo the more I feel I waste my time, I love the IDE and the environment and live coding but using the libraries is a never ending struggle for me. I agree with Nicolai the landscape is not good, Pharo really lacks mature libraries . Sure we like to bash Java but Java libs are rock solid and very well documented. I bring Java as example. Again I am not complaining at all, I knew when I came to Pharo that I will have to face these limitations. I also don't feel comfortable asking questions all the time as if I want others to do my code but I did not have much of a choice. I just cant deal with the lack of documentation any more. I think Pharo as a general idea is great , you definitely have taken the Squeak fork one big step further but you have a very long road ahead of you to make Pharo a modern environment. Asking for animating a window with good performance is one of the very basics of a good GUI API. I know you have limited resources and once again I am not complaining at all I just present my opinion. Its clear that Pharo needs a lot more people to contribute and bring the system forward at least to solve the basic problems. Thank you all people who helped me. But I don't think it worths to make my project in Pharo, too many problems. I feel privileged to have helped you with my contributions , I wish the Pharo the best. I could return back to Python but I think its time for me to bite the bullet and learn C/C++, since graphics is an area that deeply interest me (more as an artist less as a coder), so I don't have much of choice. Maybe I can brings some of my code back to Pharo with NB wrappers , I definitely will keep a close eye on Pharo. In a few months I will also present to the Pharo community a secret last contribution ;) On Sun, Sep 14, 2014 at 6:26 PM, phil@highoctane.be <phil@highoctane.be> wrote:
Do you know anything better for futuristic UIs at the moment?
I guess that we aren't talking about commercial dev here. And if we would rely on everything being documented in Pharo, errr, we wouldn't go too far.
That being said, there are plenty of examples in the Woden code.
Phil Le 14 sept. 2014 16:28, "Nicolai Hess" <nicolaihess@web.de> a écrit :
Why should he use it, now?
I mean, is there a stable API? Or a roadmap ?
Sometimes it is a bit dangerous to trust on "bleeding edge" pharo frameworks. I did some work based on Roassal3D just to found out there won't be any further development. The same happens with Roassal and GraphET. The same can happen with Woden too :)
2014-09-14 14:13 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
Why not use Woden?
Phil Le 14 sept. 2014 12:51, "kilon alios" <kilon.alios@gmail.com> a écrit :
yeah I am afraid transparency is very important to me
On Sun, Sep 14, 2014 at 1:34 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-14 11:32 GMT+02:00 stepharo <stepharo@free.fr>:
I remember that there was an animated gif support. Now I do not remember exactly.
At least in squeak there is an AnimatedImageMorph, that can load and display animated gifs. That works and is quite fast even for multiple instances. But of course no (alpha-)transparency
for roassal2 have a look at the viva classes: this is the animation frameworks that igor designed.
Stef
On 14/9/14 10:22, kilon alios wrote:
so I tried to animate in Roassal having two different images display with a delay for few millisecond but it only displays the second image with this code
form1 :=Form fromFileNamed:'/Users/kilon/Pictures/pharo.png'. form2 :=Form fromFileNamed:'/Users/kilon/Pictures/box.png'. v := RTView new. c := v canvas. s := TRBitmapShape new. s form: form1. c addShape: s. v open.
(1 to: 100) do: [ :index| s form: form1. s signalUpdate . "(Delay forMilliseconds: 1000 ) wait." s form: form2. s signalUpdate . (Delay forMilliseconds: 1000) wait.].
I looked into RTAnimation but dont know how to use it for this example. Any help ? Does Roassal 2 support such animations ?
if I do s form: and then s signalUpdate for each form separately it works fine but inside the loops does not seem to work , I tried bigger delays with no effect.
On Sun, Sep 14, 2014 at 10:57 AM, stepharo <stepharo@free.fr> wrote:
Ronie when you ready I can help writting a chapter for the nex book.
Stef
On 13/9/14 21:42, Ronie Salgado wrote:
Hello,
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
I have an adapted version of Swig for Pharo NativeBoost here: https://github.com/ronsaldo/swig
Currently I am using it to generate my Bullet bindings (available here: https://github.com/ronsaldo/bullet-pharo) that can be used as an example of using Swig. I still have to improve more my Swig generator, by writing documentation and fixing some bugs.
Greetings, Ronie
2014-09-13 16:11 GMT-03:00 stepharo <stepharo@free.fr>:
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
Stef
Almost a decade ago I did some ruby bindings by hand. It was working out of the box
Bye Enno
Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios@gmail.com>:
" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? "
yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file.
So basically its a lot like the average games out there.
"I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing."
ok
"For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."
I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things.
"Sure. The downpoint, you will depend on one additional layer."
dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large.
"Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious."
Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically.
So basically you will be using Blender as a GUI designer.
"Use fuel to store the state of your application objects."
ah nice so fuel is a good candidate.
I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
2014-09-14 18:20 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Plenty ? no
A few ? yes
Woden is certainly a project that I want it to be successful and keep going forward but at the moment I can't say its usable when each time I resize the window it corrupts the viewport.
No offense intended but lately the more I dive inside Pharo the more I feel I waste my time, I love the IDE and the environment and live coding but using the libraries is a never ending struggle for me. I agree with Nicolai the landscape is not good, Pharo really lacks mature libraries . Sure we like to bash Java but Java libs are rock solid and very well documented. I bring Java as example. Again I am not complaining at all, I knew when I came to Pharo that I will have to face these limitations. I also don't feel comfortable asking questions all the time as if I want others to do my code but I did not have much of a choice. I just cant deal with the lack of documentation any more.
I think Pharo as a general idea is great , you definitely have taken the Squeak fork one big step further but you have a very long road ahead of you to make Pharo a modern environment. Asking for animating a window with good performance is one of the very basics of a good GUI API. I know you have limited resources and once again I am not complaining at all I just present my opinion. Its clear that Pharo needs a lot more people to contribute and bring the system forward at least to solve the basic problems.
This is definitly wrong :) Especially the older squeak versions were ahead of its time with (animated) interactive UI elements. Java (Swing) does not come with an animation framework for the UI (JavaFX, yes but that took its time). There was a timing/animation framework used by Roman Guy for its FilthyRich clients, that did really look great. He created UIs that never looked like ordinary Java UIs. But I think that was done by few people only. So, doing this for pharo should be doable. (I do remember something like that was done for Morphic (maybe this one: https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/... )) yoiu can do great thinks with Qt for C++ simple animation with the good old qwidget and the newer qml-framework. That's what I would call feature UIs (mostly what is done nowadays on mobile devices and other "platforms" have their own frameworks (java)android and Object-C (IPhone). And I think we will see more "feature"-UI on the web with HTML5/Canvas/Web-GL. Do we need a good new UI framework for pharo? Yes. Do we need many developers for working on this ? No, I think a handfull (2-4) people would be enough. What pharo really needs are: Many more developers *using* pharo as a platform. nicolai
Thank you all people who helped me. But I don't think it worths to make my project in Pharo, too many problems. I feel privileged to have helped you with my contributions , I wish the Pharo the best.
I could return back to Python but I think its time for me to bite the bullet and learn C/C++, since graphics is an area that deeply interest me (more as an artist less as a coder), so I don't have much of choice. Maybe I can brings some of my code back to Pharo with NB wrappers , I definitely will keep a close eye on Pharo.
In a few months I will also present to the Pharo community a secret last contribution ;)
On Sun, Sep 14, 2014 at 6:26 PM, phil@highoctane.be <phil@highoctane.be> wrote:
Do you know anything better for futuristic UIs at the moment?
I guess that we aren't talking about commercial dev here. And if we would rely on everything being documented in Pharo, errr, we wouldn't go too far.
That being said, there are plenty of examples in the Woden code.
Phil Le 14 sept. 2014 16:28, "Nicolai Hess" <nicolaihess@web.de> a écrit :
Why should he use it, now?
I mean, is there a stable API? Or a roadmap ?
Sometimes it is a bit dangerous to trust on "bleeding edge" pharo frameworks. I did some work based on Roassal3D just to found out there won't be any further development. The same happens with Roassal and GraphET. The same can happen with Woden too :)
2014-09-14 14:13 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
Why not use Woden?
Phil Le 14 sept. 2014 12:51, "kilon alios" <kilon.alios@gmail.com> a écrit :
yeah I am afraid transparency is very important to me
On Sun, Sep 14, 2014 at 1:34 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-14 11:32 GMT+02:00 stepharo <stepharo@free.fr>:
I remember that there was an animated gif support. Now I do not remember exactly.
At least in squeak there is an AnimatedImageMorph, that can load and display animated gifs. That works and is quite fast even for multiple instances. But of course no (alpha-)transparency
for roassal2 have a look at the viva classes: this is the animation frameworks that igor designed.
Stef
On 14/9/14 10:22, kilon alios wrote:
so I tried to animate in Roassal having two different images display with a delay for few millisecond but it only displays the second image with this code
form1 :=Form fromFileNamed:'/Users/kilon/Pictures/pharo.png'. form2 :=Form fromFileNamed:'/Users/kilon/Pictures/box.png'. v := RTView new. c := v canvas. s := TRBitmapShape new. s form: form1. c addShape: s. v open.
(1 to: 100) do: [ :index| s form: form1. s signalUpdate . "(Delay forMilliseconds: 1000 ) wait." s form: form2. s signalUpdate . (Delay forMilliseconds: 1000) wait.].
I looked into RTAnimation but dont know how to use it for this example. Any help ? Does Roassal 2 support such animations ?
if I do s form: and then s signalUpdate for each form separately it works fine but inside the loops does not seem to work , I tried bigger delays with no effect.
On Sun, Sep 14, 2014 at 10:57 AM, stepharo <stepharo@free.fr> wrote:
Ronie when you ready I can help writting a chapter for the nex book.
Stef
On 13/9/14 21:42, Ronie Salgado wrote:
Hello,
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
I have an adapted version of Swig for Pharo NativeBoost here: https://github.com/ronsaldo/swig
Currently I am using it to generate my Bullet bindings (available here: https://github.com/ronsaldo/bullet-pharo) that can be used as an example of using Swig. I still have to improve more my Swig generator, by writing documentation and fixing some bugs.
Greetings, Ronie
2014-09-13 16:11 GMT-03:00 stepharo <stepharo@free.fr>:
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
Stef
Almost a decade ago I did some ruby bindings by hand. It was working out of the box
Bye Enno
Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios@gmail.com
:
" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? "
yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file.
So basically its a lot like the average games out there.
"I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing."
ok
"For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."
I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things.
"Sure. The downpoint, you will depend on one additional layer."
dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large.
"Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious."
Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically.
So basically you will be using Blender as a GUI designer.
"Use fuel to store the state of your application objects."
ah nice so fuel is a good candidate.
I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
yes JAVA Swing comes with animation abilities , maybe you mean something more than that http://youtu.be/I3usNR8JrEE?t=7m41s before JAVA FX , Java had and still has Java2D. but I am no big fan of Java anyway. Dont know what it means by "ahead of its time" but back in 1998 I was coding in Delphi 1996 with a rock solid and very powerful GUI API. Delphi was an extremely powerful IDE , even more powerful than Pharo and stil is, with very mature and well documented libraries. Also if we talk about transparency animation this dates back to my days coding in DOS and C++. QT is awesome from what I see and people I ask generally have a very positive opinion about it, certainly something I may learn but my decision to swift focus from Pharo to C/C++ is not just because I having hard time coding the things I want in Pharo, its also because it makes more sense for me to contribute to Blender since my biggest interest is 3d art and blender is what I use. So re-learning C/C++ will give me full access to Blender internals which has a lot more potential for me. But yeah most likely I will learn QT and OpenGL. Its also cool that QT also supports mobile devices and even web apps. Also QML allows for live coding. I assume by 2-4 you mean full time developers. I don't know , personally I think you need more people because GUI APIs are a pain to maintain across platforms since OS define their own libraries and support. Yeap I definitely agree that Pharo needs more people using it, the problem however is that unpopularity is a vicious circle. You don't have much documentation and mature libraries because of small community and not much more new people come because you don't have much documentation and mature libraries. The problem also is fragmentation each one wants to try his own ideas and rightly so they may not be interesting in contributing to existing libraries, etc etc. These problems are common for languages. But Pharo can only get better since its in capable hands and passionate people. I have saw Pharo only improve the past year I have been using it regularly (in my free time , part time) and the community is helpful and kind if you exclude a couple of incidents here and there . About the web technology, personally I find he web is a big can of worms but a necessary evil, I always said that building pharo on top of amber would make more sense and would lift a great burden from the development of pharo. Sure pharo would inherit the problems of the web technologies and limitations but also its strengths and power and flexibility and pharo would not need to play this game of cat and mouse with other programming languages. It would at least solve the GUI API problem for Pharo and it would be a matter of mapping Spec on top of existing well documented and well tested and very powerful / flexible web technologies. But thats up to the Pharo community , my opinion is not fact and my personal choice is not the choice of other people. On Sun, Sep 14, 2014 at 8:07 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-14 18:20 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Plenty ? no
A few ? yes
Woden is certainly a project that I want it to be successful and keep going forward but at the moment I can't say its usable when each time I resize the window it corrupts the viewport.
No offense intended but lately the more I dive inside Pharo the more I feel I waste my time, I love the IDE and the environment and live coding but using the libraries is a never ending struggle for me. I agree with Nicolai the landscape is not good, Pharo really lacks mature libraries . Sure we like to bash Java but Java libs are rock solid and very well documented. I bring Java as example. Again I am not complaining at all, I knew when I came to Pharo that I will have to face these limitations. I also don't feel comfortable asking questions all the time as if I want others to do my code but I did not have much of a choice. I just cant deal with the lack of documentation any more.
I think Pharo as a general idea is great , you definitely have taken the Squeak fork one big step further but you have a very long road ahead of you to make Pharo a modern environment. Asking for animating a window with good performance is one of the very basics of a good GUI API. I know you have limited resources and once again I am not complaining at all I just present my opinion. Its clear that Pharo needs a lot more people to contribute and bring the system forward at least to solve the basic problems.
This is definitly wrong :) Especially the older squeak versions were ahead of its time with (animated) interactive UI elements. Java (Swing) does not come with an animation framework for the UI (JavaFX, yes but that took its time). There was a timing/animation framework used by Roman Guy for its FilthyRich clients, that did really look great. He created UIs that never looked like ordinary Java UIs. But I think that was done by few people only. So, doing this for pharo should be doable. (I do remember something like that was done for Morphic (maybe this one: https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/... ))
yoiu can do great thinks with Qt for C++ simple animation with the good old qwidget and the newer qml-framework. That's what I would call feature UIs (mostly what is done nowadays on mobile devices and other "platforms" have their own frameworks (java)android and Object-C (IPhone).
And I think we will see more "feature"-UI on the web with HTML5/Canvas/Web-GL.
Do we need a good new UI framework for pharo? Yes. Do we need many developers for working on this ? No, I think a handfull (2-4) people would be enough. What pharo really needs are: Many more developers *using* pharo as a platform.
nicolai
Thank you all people who helped me. But I don't think it worths to make my project in Pharo, too many problems. I feel privileged to have helped you with my contributions , I wish the Pharo the best.
I could return back to Python but I think its time for me to bite the bullet and learn C/C++, since graphics is an area that deeply interest me (more as an artist less as a coder), so I don't have much of choice. Maybe I can brings some of my code back to Pharo with NB wrappers , I definitely will keep a close eye on Pharo.
In a few months I will also present to the Pharo community a secret last contribution ;)
On Sun, Sep 14, 2014 at 6:26 PM, phil@highoctane.be <phil@highoctane.be> wrote:
Do you know anything better for futuristic UIs at the moment?
I guess that we aren't talking about commercial dev here. And if we would rely on everything being documented in Pharo, errr, we wouldn't go too far.
That being said, there are plenty of examples in the Woden code.
Phil Le 14 sept. 2014 16:28, "Nicolai Hess" <nicolaihess@web.de> a écrit :
Why should he use it, now?
I mean, is there a stable API? Or a roadmap ?
Sometimes it is a bit dangerous to trust on "bleeding edge" pharo frameworks. I did some work based on Roassal3D just to found out there won't be any further development. The same happens with Roassal and GraphET. The same can happen with Woden too :)
2014-09-14 14:13 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
Why not use Woden?
Phil Le 14 sept. 2014 12:51, "kilon alios" <kilon.alios@gmail.com> a écrit :
yeah I am afraid transparency is very important to me
On Sun, Sep 14, 2014 at 1:34 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-14 11:32 GMT+02:00 stepharo <stepharo@free.fr>:
I remember that there was an animated gif support. Now I do not remember exactly.
At least in squeak there is an AnimatedImageMorph, that can load and display animated gifs. That works and is quite fast even for multiple instances. But of course no (alpha-)transparency
for roassal2 have a look at the viva classes: this is the animation frameworks that igor designed.
Stef
On 14/9/14 10:22, kilon alios wrote:
so I tried to animate in Roassal having two different images display with a delay for few millisecond but it only displays the second image with this code
form1 :=Form fromFileNamed:'/Users/kilon/Pictures/pharo.png'. form2 :=Form fromFileNamed:'/Users/kilon/Pictures/box.png'. v := RTView new. c := v canvas. s := TRBitmapShape new. s form: form1. c addShape: s. v open.
(1 to: 100) do: [ :index| s form: form1. s signalUpdate . "(Delay forMilliseconds: 1000 ) wait." s form: form2. s signalUpdate . (Delay forMilliseconds: 1000) wait.].
I looked into RTAnimation but dont know how to use it for this example. Any help ? Does Roassal 2 support such animations ?
if I do s form: and then s signalUpdate for each form separately it works fine but inside the loops does not seem to work , I tried bigger delays with no effect.
On Sun, Sep 14, 2014 at 10:57 AM, stepharo <stepharo@free.fr> wrote:
Ronie when you ready I can help writting a chapter for the nex book.
Stef
On 13/9/14 21:42, Ronie Salgado wrote:
Hello,
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
I have an adapted version of Swig for Pharo NativeBoost here: https://github.com/ronsaldo/swig
Currently I am using it to generate my Bullet bindings (available here: https://github.com/ronsaldo/bullet-pharo) that can be used as an example of using Swig. I still have to improve more my Swig generator, by writing documentation and fixing some bugs.
Greetings, Ronie
2014-09-13 16:11 GMT-03:00 stepharo <stepharo@free.fr>:
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
Stef
Almost a decade ago I did some ruby bindings by hand. It was working out of the box
Bye Enno
Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios@gmail.com
:
" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? "
yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file.
So basically its a lot like the average games out there.
"I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing."
ok
"For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."
I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things.
"Sure. The downpoint, you will depend on one additional layer."
dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large.
"Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious."
Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically.
So basically you will be using Blender as a GUI designer.
"Use fuel to store the state of your application objects."
ah nice so fuel is a good candidate.
I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
On 14 September 2014 18:54, kilon alios <kilon.alios@gmail.com> wrote:
yes JAVA Swing comes with animation abilities , maybe you mean something more than that
http://youtu.be/I3usNR8JrEE?t=7m41s
before JAVA FX , Java had and still has Java2D. but I am no big fan of Java anyway.
Dont know what it means by "ahead of its time" but back in 1998 I was coding in Delphi 1996 with a rock solid and very powerful GUI API. Delphi was an extremely powerful IDE , even more powerful than Pharo and stil is, with very mature and well documented libraries.
Also if we talk about transparency animation this dates back to my days coding in DOS and C++.
QT is awesome from what I see and people I ask generally have a very positive opinion about it, certainly something I may learn but my decision to swift focus from Pharo to C/C++ is not just because I having hard time coding the things I want in Pharo, its also because it makes more sense for me to contribute to Blender since my biggest interest is 3d art and blender is what I use. So re-learning C/C++ will give me full access to Blender internals which has a lot more potential for me. But yeah most likely I will learn QT and OpenGL. Its also cool that QT also supports mobile devices and even web apps. Also QML allows for live coding.
I assume by 2-4 you mean full time developers. I don't know , personally I think you need more people because GUI APIs are a pain to maintain across platforms since OS define their own libraries and support.
Yeap I definitely agree that Pharo needs more people using it, the problem however is that unpopularity is a vicious circle. You don't have much documentation and mature libraries because of small community and not much more new people come because you don't have much documentation and mature libraries. The problem also is fragmentation each one wants to try his own ideas and rightly so they may not be interesting in contributing to existing libraries, etc etc. These problems are common for languages. But Pharo can only get better since its in capable hands and passionate people. I have saw Pharo only improve the past year I have been using it regularly (in my free time , part time) and the community is helpful and kind if you exclude a couple of incidents here and there .
About the web technology, personally I find he web is a big can of worms but a necessary evil, I always said that building pharo on top of amber would make more sense and would lift a great burden from the development of pharo. Sure pharo would inherit the problems of the web technologies and limitations but also its strengths and power and flexibility and pharo would not need to play this game of cat and mouse with other programming languages. It would at least solve the GUI API problem for Pharo and it would be a matter of mapping Spec on top of existing well documented and well tested and very powerful / flexible web technologies.
But thats up to the Pharo community , my opinion is not fact and my personal choice is not the choice of other people.
There is a saying that if you want something done, right you've got to do it yourself, and this means working harder at it. Stuff like that get's easier with the passage of time, but time is what you don't seem to have and you may not have enough collaborators in your project. Seeing as you mentioned Delphi, you might consider the FreePascal/Lazarus combination and consider building a Smalltalk on top if it as you need a combination which gives the ease of an interpreter and live coding, together with the facility to get down to the metal when you need it. It also has the benefit of being crossplatform. C++ is really an insane language to attempt to do something like that in. The newer languages like Nimrod and Julia may be better, but they don't have the rich library set you need. I've always felt that the design of Smalltalk/X offers a better foundation for the type of stuff you want to accomplish so long as you are willing to meet the conditions for using it for defense related and biotech purposes. You will find the going tough as even Jan Vrany is not working on it much. All in all I would say Smalltalk is the right language for what you want to do, it is just that the free versions available don't match your exact needs, both in terms of libraries and level of mass adoption. -- Frank Church ======================= http://devblog.brahmancreations.com
I don't plan to do anything complicated with C++ just contribute bug fixes to blender and maybe add a few features here and there. Definetly not implementing a Smalltalk into it :D I am also interesting in improving my mathematical knowledge about 3d graphics. I am foremost a 3d artist, but I like the idea of customising my own tools. I would not design anything from scratch since there are already tons of open source projects. Designing my own Smalltalk is out of the question, I prefer small projects easy to do and realistic / practical. Yeap I am aware of FP and Lazarus , I may play around them too but I will be facing the same problem I face with Pharo since they are not much popular either and has nothing that can compete with Blender for 3d graphics. I am not interested in commrecial Smalltalks from what I have seen Pharo looks better, maybe they have bigger libraries a bit more docs, but I dont think it would make much of a difference. If you are serious about coding 3d and 2d graphics , in the end knowning C/C++ is a big plus since most of development happens in those languages. I never said Smalltalk or Pharo is the wrong language for what I want to do , it was always a matter of tools and libraries. I may do something crazy like create a parser from Pharo to C++ , I think that would be interesting and would allow me to use Pharo for coding Blender source. Not a complete parser just something simple that can turn basic pharo syntax to C++ syntax. I would definitely being interested in something like this. I think Slang already does that so I may look at it and do maybe a few modifications here and there . I wonder if there are other parsers for Pharo to C++ , maybe a pettitparser template ? I would love to keep using Pharo syntax and the IDE and even keep contributing to it if it could generate C++ code. Actually thank you for reminding me about Slang :) On Mon, Sep 15, 2014 at 12:11 AM, vfclists . <vfclists@gmail.com> wrote:
On 14 September 2014 18:54, kilon alios <kilon.alios@gmail.com> wrote:
yes JAVA Swing comes with animation abilities , maybe you mean something more than that
http://youtu.be/I3usNR8JrEE?t=7m41s
before JAVA FX , Java had and still has Java2D. but I am no big fan of Java anyway.
Dont know what it means by "ahead of its time" but back in 1998 I was coding in Delphi 1996 with a rock solid and very powerful GUI API. Delphi was an extremely powerful IDE , even more powerful than Pharo and stil is, with very mature and well documented libraries.
Also if we talk about transparency animation this dates back to my days coding in DOS and C++.
QT is awesome from what I see and people I ask generally have a very positive opinion about it, certainly something I may learn but my decision to swift focus from Pharo to C/C++ is not just because I having hard time coding the things I want in Pharo, its also because it makes more sense for me to contribute to Blender since my biggest interest is 3d art and blender is what I use. So re-learning C/C++ will give me full access to Blender internals which has a lot more potential for me. But yeah most likely I will learn QT and OpenGL. Its also cool that QT also supports mobile devices and even web apps. Also QML allows for live coding.
I assume by 2-4 you mean full time developers. I don't know , personally I think you need more people because GUI APIs are a pain to maintain across platforms since OS define their own libraries and support.
Yeap I definitely agree that Pharo needs more people using it, the problem however is that unpopularity is a vicious circle. You don't have much documentation and mature libraries because of small community and not much more new people come because you don't have much documentation and mature libraries. The problem also is fragmentation each one wants to try his own ideas and rightly so they may not be interesting in contributing to existing libraries, etc etc. These problems are common for languages. But Pharo can only get better since its in capable hands and passionate people. I have saw Pharo only improve the past year I have been using it regularly (in my free time , part time) and the community is helpful and kind if you exclude a couple of incidents here and there .
About the web technology, personally I find he web is a big can of worms but a necessary evil, I always said that building pharo on top of amber would make more sense and would lift a great burden from the development of pharo. Sure pharo would inherit the problems of the web technologies and limitations but also its strengths and power and flexibility and pharo would not need to play this game of cat and mouse with other programming languages. It would at least solve the GUI API problem for Pharo and it would be a matter of mapping Spec on top of existing well documented and well tested and very powerful / flexible web technologies.
But thats up to the Pharo community , my opinion is not fact and my personal choice is not the choice of other people.
There is a saying that if you want something done, right you've got to do it yourself, and this means working harder at it. Stuff like that get's easier with the passage of time, but time is what you don't seem to have and you may not have enough collaborators in your project.
Seeing as you mentioned Delphi, you might consider the FreePascal/Lazarus combination and consider building a Smalltalk on top if it as you need a combination which gives the ease of an interpreter and live coding, together with the facility to get down to the metal when you need it. It also has the benefit of being crossplatform. C++ is really an insane language to attempt to do something like that in. The newer languages like Nimrod and Julia may be better, but they don't have the rich library set you need.
I've always felt that the design of Smalltalk/X offers a better foundation for the type of stuff you want to accomplish so long as you are willing to meet the conditions for using it for defense related and biotech purposes. You will find the going tough as even Jan Vrany is not working on it much.
All in all I would say Smalltalk is the right language for what you want to do, it is just that the free versions available don't match your exact needs, both in terms of libraries and level of mass adoption.
-- Frank Church
======================= http://devblog.brahmancreations.com
FWIW, Blender has its own UI toolkit. So, they designed their own thing. http://3dicc.com/ 's Terf runs on Cog + internal additions. I guess it shows that things can be done nicely when it comes to UIs. As for Java and UI toolkits, I've been programming in Swing very extensively at one point. Well, as always, when you get into something very specific, you dig into the code and see that the designers of Swing also ran into issues and under the cover, things aren't so neat and debugging event bubbling in these things (where then, there is suddenly *zero* doc) is much harder with Java than with Pharo. UI is always a can of worms. Look at all the moves from Microsoft with WinForms, Silverlight, WPF, ModernUI, and what else... I've done tons of Java and Java EE. Heck, I paid my bills for years doing that, including teaching other people on how to use it properly. Know what? I am now sick of Java. When can we focus on the real problem and not all of the scaffholding? Java is okay, Java has lots of APIs, Java covers a lot of ground. But I just can't stand its ways of writing 20x more code than needed. Pharo is fresh air. One can actually understand what's going on and not merely call APIs around without understanding what's going on inside. Is it frustrating at time, hell yes. But do I end up with better skill after that? You bet! And as for C and C++ for 3D graphics, coders do use premade engines these days, like Unreal, OGRE, or, Urho3D http://urho3d.github.io/about.html. That last one you can script ( http://urho3d.github.io/documentation/HEAD/_scripting.html). Whatever the choice or the path, it seems that massive work is needed to get something that works semi-decently out of the door. There is no silver bullet... I wish you find what you are looking for. All the best, Phil On Sun, Sep 14, 2014 at 11:29 PM, kilon alios <kilon.alios@gmail.com> wrote:
I don't plan to do anything complicated with C++ just contribute bug fixes to blender and maybe add a few features here and there. Definetly not implementing a Smalltalk into it :D I am also interesting in improving my mathematical knowledge about 3d graphics. I am foremost a 3d artist, but I like the idea of customising my own tools. I would not design anything from scratch since there are already tons of open source projects. Designing my own Smalltalk is out of the question, I prefer small projects easy to do and realistic / practical.
Yeap I am aware of FP and Lazarus , I may play around them too but I will be facing the same problem I face with Pharo since they are not much popular either and has nothing that can compete with Blender for 3d graphics. I am not interested in commrecial Smalltalks from what I have seen Pharo looks better, maybe they have bigger libraries a bit more docs, but I dont think it would make much of a difference.
If you are serious about coding 3d and 2d graphics , in the end knowning C/C++ is a big plus since most of development happens in those languages.
I never said Smalltalk or Pharo is the wrong language for what I want to do , it was always a matter of tools and libraries.
I may do something crazy like create a parser from Pharo to C++ , I think that would be interesting and would allow me to use Pharo for coding Blender source. Not a complete parser just something simple that can turn basic pharo syntax to C++ syntax. I would definitely being interested in something like this. I think Slang already does that so I may look at it and do maybe a few modifications here and there .
I wonder if there are other parsers for Pharo to C++ , maybe a pettitparser template ?
I would love to keep using Pharo syntax and the IDE and even keep contributing to it if it could generate C++ code. Actually thank you for reminding me about Slang :)
On Mon, Sep 15, 2014 at 12:11 AM, vfclists . <vfclists@gmail.com> wrote:
On 14 September 2014 18:54, kilon alios <kilon.alios@gmail.com> wrote:
yes JAVA Swing comes with animation abilities , maybe you mean something more than that
http://youtu.be/I3usNR8JrEE?t=7m41s
before JAVA FX , Java had and still has Java2D. but I am no big fan of Java anyway.
Dont know what it means by "ahead of its time" but back in 1998 I was coding in Delphi 1996 with a rock solid and very powerful GUI API. Delphi was an extremely powerful IDE , even more powerful than Pharo and stil is, with very mature and well documented libraries.
Also if we talk about transparency animation this dates back to my days coding in DOS and C++.
QT is awesome from what I see and people I ask generally have a very positive opinion about it, certainly something I may learn but my decision to swift focus from Pharo to C/C++ is not just because I having hard time coding the things I want in Pharo, its also because it makes more sense for me to contribute to Blender since my biggest interest is 3d art and blender is what I use. So re-learning C/C++ will give me full access to Blender internals which has a lot more potential for me. But yeah most likely I will learn QT and OpenGL. Its also cool that QT also supports mobile devices and even web apps. Also QML allows for live coding.
I assume by 2-4 you mean full time developers. I don't know , personally I think you need more people because GUI APIs are a pain to maintain across platforms since OS define their own libraries and support.
Yeap I definitely agree that Pharo needs more people using it, the problem however is that unpopularity is a vicious circle. You don't have much documentation and mature libraries because of small community and not much more new people come because you don't have much documentation and mature libraries. The problem also is fragmentation each one wants to try his own ideas and rightly so they may not be interesting in contributing to existing libraries, etc etc. These problems are common for languages. But Pharo can only get better since its in capable hands and passionate people. I have saw Pharo only improve the past year I have been using it regularly (in my free time , part time) and the community is helpful and kind if you exclude a couple of incidents here and there .
About the web technology, personally I find he web is a big can of worms but a necessary evil, I always said that building pharo on top of amber would make more sense and would lift a great burden from the development of pharo. Sure pharo would inherit the problems of the web technologies and limitations but also its strengths and power and flexibility and pharo would not need to play this game of cat and mouse with other programming languages. It would at least solve the GUI API problem for Pharo and it would be a matter of mapping Spec on top of existing well documented and well tested and very powerful / flexible web technologies.
But thats up to the Pharo community , my opinion is not fact and my personal choice is not the choice of other people.
There is a saying that if you want something done, right you've got to do it yourself, and this means working harder at it. Stuff like that get's easier with the passage of time, but time is what you don't seem to have and you may not have enough collaborators in your project.
Seeing as you mentioned Delphi, you might consider the FreePascal/Lazarus combination and consider building a Smalltalk on top if it as you need a combination which gives the ease of an interpreter and live coding, together with the facility to get down to the metal when you need it. It also has the benefit of being crossplatform. C++ is really an insane language to attempt to do something like that in. The newer languages like Nimrod and Julia may be better, but they don't have the rich library set you need.
I've always felt that the design of Smalltalk/X offers a better foundation for the type of stuff you want to accomplish so long as you are willing to meet the conditions for using it for defense related and biotech purposes. You will find the going tough as even Jan Vrany is not working on it much.
All in all I would say Smalltalk is the right language for what you want to do, it is just that the free versions available don't match your exact needs, both in terms of libraries and level of mass adoption.
-- Frank Church
======================= http://devblog.brahmancreations.com
Blender indeed has its own GUI called "Ghost API" which is OpenGL 1 based in order to work even with very old GPUs. Yeap I agree with your post 100% this is why I said I love Pharo and I prefer it over any other language I have coded in. I can certainly understand your frustration with Java . I also envy you that you can use Pharo to make a living maybe I can do that one day too :) I also agree there is no such thing as silver bullet. It also depends on what you want. For example I could port Blender source base as a library to pharo with NB bindings but that would be a massive amount of work and not the same as just making small contributions to Blender. I think in the end, whether you like a programming language or not you have to be realistic about your goals and what you ask from the language. I tried to fit Pharo into my workflow but just it does not fit. The good news is that at least I will be avoiding C++ for now as the part I am most interested in Blender, sculpting is coded in C. But I dont give up on pharo just yet completely, I just said it wont be anymore my main platform. I see no reason why I should not contribute a few bug fixes or enhancements to pharo per year. I would also like to finish porting the 5th chapter of PBE to Pharo 3 at some point. So no worries I will be around, just much less active :) And will definetly follow the mailing list with great interest :) On Mon, Sep 15, 2014 at 2:24 AM, phil@highoctane.be <phil@highoctane.be> wrote:
FWIW, Blender has its own UI toolkit. So, they designed their own thing.
http://3dicc.com/ 's Terf runs on Cog + internal additions. I guess it shows that things can be done nicely when it comes to UIs.
As for Java and UI toolkits, I've been programming in Swing very extensively at one point. Well, as always, when you get into something very specific, you dig into the code and see that the designers of Swing also ran into issues and under the cover, things aren't so neat and debugging event bubbling in these things (where then, there is suddenly *zero* doc) is much harder with Java than with Pharo. UI is always a can of worms. Look at all the moves from Microsoft with WinForms, Silverlight, WPF, ModernUI, and what else...
I've done tons of Java and Java EE. Heck, I paid my bills for years doing that, including teaching other people on how to use it properly. Know what? I am now sick of Java. When can we focus on the real problem and not all of the scaffholding? Java is okay, Java has lots of APIs, Java covers a lot of ground. But I just can't stand its ways of writing 20x more code than needed.
Pharo is fresh air. One can actually understand what's going on and not merely call APIs around without understanding what's going on inside. Is it frustrating at time, hell yes. But do I end up with better skill after that? You bet!
And as for C and C++ for 3D graphics, coders do use premade engines these days, like Unreal, OGRE, or, Urho3D http://urho3d.github.io/about.html. That last one you can script ( http://urho3d.github.io/documentation/HEAD/_scripting.html).
Whatever the choice or the path, it seems that massive work is needed to get something that works semi-decently out of the door. There is no silver bullet...
I wish you find what you are looking for. All the best, Phil
On Sun, Sep 14, 2014 at 11:29 PM, kilon alios <kilon.alios@gmail.com> wrote:
I don't plan to do anything complicated with C++ just contribute bug fixes to blender and maybe add a few features here and there. Definetly not implementing a Smalltalk into it :D I am also interesting in improving my mathematical knowledge about 3d graphics. I am foremost a 3d artist, but I like the idea of customising my own tools. I would not design anything from scratch since there are already tons of open source projects. Designing my own Smalltalk is out of the question, I prefer small projects easy to do and realistic / practical.
Yeap I am aware of FP and Lazarus , I may play around them too but I will be facing the same problem I face with Pharo since they are not much popular either and has nothing that can compete with Blender for 3d graphics. I am not interested in commrecial Smalltalks from what I have seen Pharo looks better, maybe they have bigger libraries a bit more docs, but I dont think it would make much of a difference.
If you are serious about coding 3d and 2d graphics , in the end knowning C/C++ is a big plus since most of development happens in those languages.
I never said Smalltalk or Pharo is the wrong language for what I want to do , it was always a matter of tools and libraries.
I may do something crazy like create a parser from Pharo to C++ , I think that would be interesting and would allow me to use Pharo for coding Blender source. Not a complete parser just something simple that can turn basic pharo syntax to C++ syntax. I would definitely being interested in something like this. I think Slang already does that so I may look at it and do maybe a few modifications here and there .
I wonder if there are other parsers for Pharo to C++ , maybe a pettitparser template ?
I would love to keep using Pharo syntax and the IDE and even keep contributing to it if it could generate C++ code. Actually thank you for reminding me about Slang :)
On Mon, Sep 15, 2014 at 12:11 AM, vfclists . <vfclists@gmail.com> wrote:
On 14 September 2014 18:54, kilon alios <kilon.alios@gmail.com> wrote:
yes JAVA Swing comes with animation abilities , maybe you mean something more than that
http://youtu.be/I3usNR8JrEE?t=7m41s
before JAVA FX , Java had and still has Java2D. but I am no big fan of Java anyway.
Dont know what it means by "ahead of its time" but back in 1998 I was coding in Delphi 1996 with a rock solid and very powerful GUI API. Delphi was an extremely powerful IDE , even more powerful than Pharo and stil is, with very mature and well documented libraries.
Also if we talk about transparency animation this dates back to my days coding in DOS and C++.
QT is awesome from what I see and people I ask generally have a very positive opinion about it, certainly something I may learn but my decision to swift focus from Pharo to C/C++ is not just because I having hard time coding the things I want in Pharo, its also because it makes more sense for me to contribute to Blender since my biggest interest is 3d art and blender is what I use. So re-learning C/C++ will give me full access to Blender internals which has a lot more potential for me. But yeah most likely I will learn QT and OpenGL. Its also cool that QT also supports mobile devices and even web apps. Also QML allows for live coding.
I assume by 2-4 you mean full time developers. I don't know , personally I think you need more people because GUI APIs are a pain to maintain across platforms since OS define their own libraries and support.
Yeap I definitely agree that Pharo needs more people using it, the problem however is that unpopularity is a vicious circle. You don't have much documentation and mature libraries because of small community and not much more new people come because you don't have much documentation and mature libraries. The problem also is fragmentation each one wants to try his own ideas and rightly so they may not be interesting in contributing to existing libraries, etc etc. These problems are common for languages. But Pharo can only get better since its in capable hands and passionate people. I have saw Pharo only improve the past year I have been using it regularly (in my free time , part time) and the community is helpful and kind if you exclude a couple of incidents here and there .
About the web technology, personally I find he web is a big can of worms but a necessary evil, I always said that building pharo on top of amber would make more sense and would lift a great burden from the development of pharo. Sure pharo would inherit the problems of the web technologies and limitations but also its strengths and power and flexibility and pharo would not need to play this game of cat and mouse with other programming languages. It would at least solve the GUI API problem for Pharo and it would be a matter of mapping Spec on top of existing well documented and well tested and very powerful / flexible web technologies.
But thats up to the Pharo community , my opinion is not fact and my personal choice is not the choice of other people.
There is a saying that if you want something done, right you've got to do it yourself, and this means working harder at it. Stuff like that get's easier with the passage of time, but time is what you don't seem to have and you may not have enough collaborators in your project.
Seeing as you mentioned Delphi, you might consider the FreePascal/Lazarus combination and consider building a Smalltalk on top if it as you need a combination which gives the ease of an interpreter and live coding, together with the facility to get down to the metal when you need it. It also has the benefit of being crossplatform. C++ is really an insane language to attempt to do something like that in. The newer languages like Nimrod and Julia may be better, but they don't have the rich library set you need.
I've always felt that the design of Smalltalk/X offers a better foundation for the type of stuff you want to accomplish so long as you are willing to meet the conditions for using it for defense related and biotech purposes. You will find the going tough as even Jan Vrany is not working on it much.
All in all I would say Smalltalk is the right language for what you want to do, it is just that the free versions available don't match your exact needs, both in terms of libraries and level of mass adoption.
-- Frank Church
======================= http://devblog.brahmancreations.com
Guys the animation of roassal2 are done really simply using viva. Stef On 14/9/14 19:07, Nicolai Hess wrote:
2014-09-14 18:20 GMT+02:00 kilon alios <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>>:
Plenty ? no
A few ? yes
Woden is certainly a project that I want it to be successful and keep going forward but at the moment I can't say its usable when each time I resize the window it corrupts the viewport.
No offense intended but lately the more I dive inside Pharo the more I feel I waste my time, I love the IDE and the environment and live coding but using the libraries is a never ending struggle for me. I agree with Nicolai the landscape is not good, Pharo really lacks mature libraries . Sure we like to bash Java but Java libs are rock solid and very well documented. I bring Java as example. Again I am not complaining at all, I knew when I came to Pharo that I will have to face these limitations. I also don't feel comfortable asking questions all the time as if I want others to do my code but I did not have much of a choice. I just cant deal with the lack of documentation any more.
I think Pharo as a general idea is great , you definitely have taken the Squeak fork one big step further but you have a very long road ahead of you to make Pharo a modern environment. Asking for animating a window with good performance is one of the very basics of a good GUI API. I know you have limited resources and once again I am not complaining at all I just present my opinion. Its clear that Pharo needs a lot more people to contribute and bring the system forward at least to solve the basic problems.
This is definitly wrong :) Especially the older squeak versions were ahead of its time with (animated) interactive UI elements. Java (Swing) does not come with an animation framework for the UI (JavaFX, yes but that took its time). There was a timing/animation framework used by Roman Guy for its FilthyRich clients, that did really look great. He created UIs that never looked like ordinary Java UIs. But I think that was done by few people only. So, doing this for pharo should be doable. (I do remember something like that was done for Morphic (maybe this one: https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/...))
yoiu can do great thinks with Qt for C++ simple animation with the good old qwidget and the newer qml-framework. That's what I would call feature UIs (mostly what is done nowadays on mobile devices and other "platforms" have their own frameworks (java)android and Object-C (IPhone).
And I think we will see more "feature"-UI on the web with HTML5/Canvas/Web-GL.
Do we need a good new UI framework for pharo? Yes. Do we need many developers for working on this ? No, I think a handfull (2-4) people would be enough. What pharo really needs are: Many more developers *using* pharo as a platform.
nicolai
Thank you all people who helped me. But I don't think it worths to make my project in Pharo, too many problems. I feel privileged to have helped you with my contributions , I wish the Pharo the best.
I could return back to Python but I think its time for me to bite the bullet and learn C/C++, since graphics is an area that deeply interest me (more as an artist less as a coder), so I don't have much of choice. Maybe I can brings some of my code back to Pharo with NB wrappers , I definitely will keep a close eye on Pharo.
In a few months I will also present to the Pharo community a secret last contribution ;)
On Sun, Sep 14, 2014 at 6:26 PM, phil@highoctane.be <mailto:phil@highoctane.be> <phil@highoctane.be <mailto:phil@highoctane.be>> wrote:
Do you know anything better for futuristic UIs at the moment?
I guess that we aren't talking about commercial dev here. And if we would rely on everything being documented in Pharo, errr, we wouldn't go too far.
That being said, there are plenty of examples in the Woden code.
Phil
Le 14 sept. 2014 16:28, "Nicolai Hess" <nicolaihess@web.de <mailto:nicolaihess@web.de>> a écrit :
Why should he use it, now? I mean, is there a stable API? Or a roadmap ?
Sometimes it is a bit dangerous to trust on "bleeding edge" pharo frameworks. I did some work based on Roassal3D just to found out there won't be any further development. The same happens with Roassal and GraphET. The same can happen with Woden too :)
2014-09-14 14:13 GMT+02:00 phil@highoctane.be <mailto:phil@highoctane.be> <phil@highoctane.be <mailto:phil@highoctane.be>>:
Why not use Woden?
Phil
Le 14 sept. 2014 12:51, "kilon alios" <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> a écrit :
yeah I am afraid transparency is very important to me
On Sun, Sep 14, 2014 at 1:34 PM, Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>> wrote:
2014-09-14 11:32 GMT+02:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
I remember that there was an animated gif support. Now I do not remember exactly.
At least in squeak there is an AnimatedImageMorph, that can load and display animated gifs. That works and is quite fast even for multiple instances. But of course no (alpha-)transparency
for roassal2 have a look at the viva classes: this is the animation frameworks that igor designed.
Stef
On 14/9/14 10:22, kilon alios wrote:
so I tried to animate in Roassal having two different images display with a delay for few millisecond but it only displays the second image with this code
form1 :=Form fromFileNamed:'/Users/kilon/Pictures/pharo.png'. form2 :=Form fromFileNamed:'/Users/kilon/Pictures/box.png'. v := RTView new. c := v canvas. s := TRBitmapShape new. s form: form1. c addShape: s. v open.
(1 to: 100) do: [ :index| s form: form1. s signalUpdate . "(Delay forMilliseconds: 1000 ) wait." s form: form2. s signalUpdate . (Delay forMilliseconds: 1000) wait.].
I looked into RTAnimation but dont know how to use it for this example. Any help ? Does Roassal 2 support such animations ?
if I do s form: and then s signalUpdate for each form separately it works fine but inside the loops does not seem to work , I tried bigger delays with no effect.
On Sun, Sep 14, 2014 at 10:57 AM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Ronie when you ready I can help writting a chapter for the nex book.
Stef
On 13/9/14 21:42, Ronie Salgado wrote:
Hello,
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
I have an adapted version of Swig for Pharo NativeBoost here: https://github.com/ronsaldo/swig
Currently I am using it to generate my Bullet bindings (available here: https://github.com/ronsaldo/bullet-pharo) that can be used as an example of using Swig. I still have to improve more my Swig generator, by writing documentation and fixing some bugs.
Greetings, Ronie
2014-09-13 16:11 GMT-03:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
Stef
Almost a decade ago I did some ruby bindings by hand. It was working out of the box
Bye Enno
Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>>:
" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? "
yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file.
So basically its a lot like the average games out there.
"I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing."
ok
"For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."
I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things.
"Sure. The downpoint, you will depend on one additional layer."
dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large.
"Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious."
Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically.
So basically you will be using Blender as a GUI designer.
"Use fuel to store the state of your application objects."
ah nice so fuel is a good candidate.
I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
On Sun, Sep 14, 2014 at 10:07 AM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-14 18:20 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Plenty ? no
A few ? yes
Woden is certainly a project that I want it to be successful and keep going forward but at the moment I can't say its usable when each time I resize the window it corrupts the viewport.
No offense intended but lately the more I dive inside Pharo the more I feel I waste my time, I love the IDE and the environment and live coding but using the libraries is a never ending struggle for me. I agree with Nicolai the landscape is not good, Pharo really lacks mature libraries . Sure we like to bash Java but Java libs are rock solid and very well documented. I bring Java as example. Again I am not complaining at all, I knew when I came to Pharo that I will have to face these limitations. I also don't feel comfortable asking questions all the time as if I want others to do my code but I did not have much of a choice. I just cant deal with the lack of documentation any more.
I think Pharo as a general idea is great , you definitely have taken the Squeak fork one big step further but you have a very long road ahead of you to make Pharo a modern environment. Asking for animating a window with good performance is one of the very basics of a good GUI API. I know you have limited resources and once again I am not complaining at all I just present my opinion. Its clear that Pharo needs a lot more people to contribute and bring the system forward at least to solve the basic problems.
This is definitly wrong :) Especially the older squeak versions were ahead of its time with (animated) interactive UI elements. Java (Swing) does not come with an animation framework for the UI (JavaFX, yes but that took its time). There was a timing/animation framework used by Roman Guy for its FilthyRich clients, that did really look great. He created UIs that never looked like ordinary Java UIs. But I think that was done by few people only. So, doing this for pharo should be doable. (I do remember something like that was done for Morphic (maybe this one: https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/... ))
yoiu can do great thinks with Qt for C++ simple animation with the good old qwidget and the newer qml-framework. That's what I would call feature UIs (mostly what is done nowadays on mobile devices and other "platforms" have their own frameworks (java)android and Object-C (IPhone).
And I think we will see more "feature"-UI on the web with HTML5/Canvas/Web-GL.
Do we need a good new UI framework for pharo? Yes. Do we need many developers for working on this ? No, I think a handfull (2-4) people would be enough. What pharo really needs are: Many more developers *using* pharo as a platform.
Agreed. But one real problem with the Squeak/Pharo UI is the lack of native windows. There is an old project Graphics-External-Ffenestri but AFAICT it isn't being used. But there /is/ a really good prototype of a native window system above Squeak done by Vassili Bykov in Newspeak. The native windows contain morphs, but anything, including MVC, can be present. This provides native Win32 Windows (doing other platforms is merely work) /and/ the ability to snapshot and bring back up windows on a different platform (e.g. open in win32, snapshot and bring up in Squeak/Pharo Morphic windows, or vice verse), and the ability to do this dynamically. Is anyone motivated to port the Newspeak code back to Squeak/Pharo? If you're interested, contact me, or Vassili, or Bob Westergaard and ask about Brazil (think plumbing). nicolai
Thank you all people who helped me. But I don't think it worths to make my project in Pharo, too many problems. I feel privileged to have helped you with my contributions , I wish the Pharo the best.
I could return back to Python but I think its time for me to bite the bullet and learn C/C++, since graphics is an area that deeply interest me (more as an artist less as a coder), so I don't have much of choice. Maybe I can brings some of my code back to Pharo with NB wrappers , I definitely will keep a close eye on Pharo.
In a few months I will also present to the Pharo community a secret last contribution ;)
On Sun, Sep 14, 2014 at 6:26 PM, phil@highoctane.be <phil@highoctane.be> wrote:
Do you know anything better for futuristic UIs at the moment?
I guess that we aren't talking about commercial dev here. And if we would rely on everything being documented in Pharo, errr, we wouldn't go too far.
That being said, there are plenty of examples in the Woden code.
Phil Le 14 sept. 2014 16:28, "Nicolai Hess" <nicolaihess@web.de> a écrit :
Why should he use it, now?
I mean, is there a stable API? Or a roadmap ?
Sometimes it is a bit dangerous to trust on "bleeding edge" pharo frameworks. I did some work based on Roassal3D just to found out there won't be any further development. The same happens with Roassal and GraphET. The same can happen with Woden too :)
2014-09-14 14:13 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
Why not use Woden?
Phil Le 14 sept. 2014 12:51, "kilon alios" <kilon.alios@gmail.com> a écrit :
yeah I am afraid transparency is very important to me
On Sun, Sep 14, 2014 at 1:34 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-14 11:32 GMT+02:00 stepharo <stepharo@free.fr>:
I remember that there was an animated gif support. Now I do not remember exactly.
At least in squeak there is an AnimatedImageMorph, that can load and display animated gifs. That works and is quite fast even for multiple instances. But of course no (alpha-)transparency
for roassal2 have a look at the viva classes: this is the animation frameworks that igor designed.
Stef
On 14/9/14 10:22, kilon alios wrote:
so I tried to animate in Roassal having two different images display with a delay for few millisecond but it only displays the second image with this code
form1 :=Form fromFileNamed:'/Users/kilon/Pictures/pharo.png'. form2 :=Form fromFileNamed:'/Users/kilon/Pictures/box.png'. v := RTView new. c := v canvas. s := TRBitmapShape new. s form: form1. c addShape: s. v open.
(1 to: 100) do: [ :index| s form: form1. s signalUpdate . "(Delay forMilliseconds: 1000 ) wait." s form: form2. s signalUpdate . (Delay forMilliseconds: 1000) wait.].
I looked into RTAnimation but dont know how to use it for this example. Any help ? Does Roassal 2 support such animations ?
if I do s form: and then s signalUpdate for each form separately it works fine but inside the loops does not seem to work , I tried bigger delays with no effect.
On Sun, Sep 14, 2014 at 10:57 AM, stepharo <stepharo@free.fr> wrote:
Ronie when you ready I can help writting a chapter for the nex book.
Stef
On 13/9/14 21:42, Ronie Salgado wrote:
Hello,
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
I have an adapted version of Swig for Pharo NativeBoost here: https://github.com/ronsaldo/swig
Currently I am using it to generate my Bullet bindings (available here: https://github.com/ronsaldo/bullet-pharo) that can be used as an example of using Swig. I still have to improve more my Swig generator, by writing documentation and fixing some bugs.
Greetings, Ronie
2014-09-13 16:11 GMT-03:00 stepharo <stepharo@free.fr>:
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
Stef
Almost a decade ago I did some ruby bindings by hand. It was working out of the box
Bye Enno
Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios@gmail.com
:
" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? "
yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file.
So basically its a lot like the average games out there.
"I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing."
ok
"For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."
I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things.
"Sure. The downpoint, you will depend on one additional layer."
dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large.
"Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious."
Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically.
So basically you will be using Blender as a GUI designer.
"Use fuel to store the state of your application objects."
ah nice so fuel is a good candidate.
I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
-- best, Eliot
...one real problem with the Squeak/Pharo UI is the lack of native windows. There is an old project Graphics-External-Ffenestri but AFAICT it isn't being used.
I'm using it, on Mac OS so far (Windows and Ubuntu Linux are the other host platforms I care about at the moment).
But there /is/ a really good prototype of a native window system above Squeak done by Vassili Bykov in Newspeak.
Hoooold on there... :) Does this mean that Vassili tried Ffenestri and found it unusable? If so, why? Details, please. thanks, -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
On Mon, Sep 15, 2014 at 12:31 PM, Craig Latta <craig@netjam.org> wrote:
...one real problem with the Squeak/Pharo UI is the lack of native windows. There is an old project Graphics-External-Ffenestri but AFAICT it isn't being used.
I'm using it, on Mac OS so far (Windows and Ubuntu Linux are the other host platforms I care about at the moment).
But there /is/ a really good prototype of a native window system above Squeak done by Vassili Bykov in Newspeak.
Hoooold on there... :) Does this mean that Vassili tried Ffenestri and found it unusable? If so, why? Details, please.
I don't want to talk for Vassili, but he had done the prototype for Pollock, the new window system for VW that was squandered by Cincom management. In this he architected full conversion between native and non-native windows, both dynamically and over snapshot. So when he came to implement the GUI for Newspeak he used that experience. I don't see the same architectural support in Graphics-External-Ffenestri it doesn't even support snapshot and resume on the same window system. Here's the relevant extract from HostWIndowProxy's class comment: "This is a proxy for a Host OS window and as such is considered a disposable item. When an image is restarted the client must recreate suitable instances from the information they hold." So I expect Vassili didn't even think of using it. Vassili's work doesn't need any VM support beyond the ability to ask the VM to /not/ respond to GUI events. It is based on the FFI and uses callbacks to receive events. In any case Vassili's work is the best candidate that I've ever seen for a proper native windows integration for Smalltalk systems that ave a history of non-native windows. thanks,
-C
-- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
-- best, Eliot
On Sep 15, 2014, at 3:54 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
The native windows contain morphs, but anything, including MVC, can be present. This provides native Win32 Windows (doing other platforms is merely work) /and/ the ability to snapshot and bring back up windows on a different platform (e.g. open in win32, snapshot and bring up in Squeak/Pharo Morphic windows, or vice verse), and the ability to do this dynamically. Is anyone motivated to port the Newspeak code back to Squeak/Pharo?
Well, a while ago in the business list Iâve raised the idea that making Pharo able to do native OS windows would help it to gain market space (as in the opposite of staying at the margins of it). So, Iâd be very positively curious about being able to use Pharo to do multiplatform native apps sebastian o/
2014-09-16 14:37 GMT-03:00 Sebastian Sastre <sebastian@flowingconcept.com>:
Well, a while ago in the business list Iâve raised the idea that making Pharo able to do native OS windows would help it to gain market space (as in the opposite of staying at the margins of it).
So, Iâd be very positively curious about being able to use Pharo to do multiplatform native apps
The trend is shifting to mobile devices, iOS and Android are eating the whole market. So if it is about the potential market size, native mobile (tablets/phones/TVs) should come as the first option, before desktop. For development, native windows could prove very useful. Regards!
On Tue, Sep 16, 2014 at 2:18 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2014-09-16 14:37 GMT-03:00 Sebastian Sastre <sebastian@flowingconcept.com>:
Well, a while ago in the business list Iâve raised the idea that making Pharo able to do native OS windows would help it to gain market space (as in the opposite of staying at the margins of it).
So, Iâd be very positively curious about being able to use Pharo to do multiplatform native apps
The trend is shifting to mobile devices, iOS and Android are eating the whole market. So if it is about the potential market size, native mobile (tablets/phones/TVs) should come as the first option, before desktop.
+1. Desktop apps are "dead" aren't they? I'm doubtful that native windows would help Smalltalk's popularity, as evidenced, I guess, by the fact VA and VW have supported them for a long time; did they take over the world yet?
For development, native windows could prove very useful.
How so? For me, one of the worst aspects of trying to develop in VisualAge or VisualWorks *is* the multiple host windows. It makes it virtually impossible to work in more than one image, and reinforces the "grand cathedral" thinking about Smalltalk; e.g. you're not supposed to want or need anything outside your one, true, image. Dinosaur! I constantly work in multiple images, not only for separate projects but for the ability to quickly and easily fork images for multicore processing on the same project. Other times simply to try something temporary and possibly dangerous. The memory isolation is critical for productivity, the UI isolation for usability, and the multi-core capability for performance. I think we should focus on how to move to more and smaller intercommunicating images rather than one big image. I understand its appeal for _deploying_ an off-the-shelf desktop app, but I'm not aware of any other use-cases where multiple host windows would be preferable to one host window per image.
On Tue, Sep 16, 2014 at 2:19 PM, Chris Muller <asqueaker@gmail.com> wrote:
On Tue, Sep 16, 2014 at 2:18 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2014-09-16 14:37 GMT-03:00 Sebastian Sastre < sebastian@flowingconcept.com>:
Well, a while ago in the business list Iâve raised the idea that making Pharo able to do native OS windows would help it to gain market space (as in the opposite of staying at the margins of it).
So, Iâd be very positively curious about being able to use Pharo to do multiplatform native apps
The trend is shifting to mobile devices, iOS and Android are eating the whole market. So if it is about the potential market size, native mobile (tablets/phones/TVs) should come as the first option, before desktop.
+1. Desktop apps are "dead" aren't they? I'm doubtful that native windows would help Smalltalk's popularity, as evidenced, I guess, by the fact VA and VW have supported them for a long time; did they take over the world yet?
For development, native windows could prove very useful.
How so? For me, one of the worst aspects of trying to develop in VisualAge or VisualWorks *is* the multiple host windows. It makes it virtually impossible to work in more than one image, and reinforces the "grand cathedral" thinking about Smalltalk; e.g. you're not supposed to want or need anything outside your one, true, image. Dinosaur!
I constantly work in multiple images, not only for separate projects but for the ability to quickly and easily fork images for multicore processing on the same project. Other times simply to try something temporary and possibly dangerous. The memory isolation is critical for productivity, the UI isolation for usability, and the multi-core capability for performance.
I think we should focus on how to move to more and smaller intercommunicating images rather than one big image. I understand its appeal for _deploying_ an off-the-shelf desktop app, but I'm not aware of any other use-cases where multiple host windows would be preferable to one host window per image.
That all makes sense from an experienced Smalltalker's POV. But for people exploring the technology the lack of native windows is usually a huge turn-off and often reason to reject the technology. The nice thing about Vassili's work is that it allows one to have *both*, without losing window state, and one can switch dynamically, and, IIRC, mix both, e.g. for development. So it isn't an exclusive choice. Re VisualWorks' support for native windows it was an essential component to VW staying in the market-place. If it hadn't supported native windows it would have died the commercial death long ago. Pre-web, one /had/ to have native windows for industry, and now with mobile native look and feel is even more important. Further, VWs huge lack in its GUI was lack of support for native widgets. We always used to tout MSWord's use of emulated widgets (apparently for performance reasons) as a defence but it didn't convince. The customer was always provided with poor emulations and a limited supply. IMO, native widgets would have made a big difference in hwo well-received VW was for GUI applications, where those using Windows could always turn to VSE. -- best, Eliot
Hi Eliot, Yes - in the past most Smalltalks did not have native widgets and usually emulated the L&F. I remember VW on a Sun Sparc with Windows or Mac look. While it was cool to run 1:1 on another machine it would have been to much manpower for the vendor to reimplement all the nice widgets to really look like the native system. Especially when the L&F changed very often between Win95/96/XP/Win7/Win8 at Microsoft. Even with good looking widgets/icons one could see from the speed and repainting issues (white rectangles for damage areas) that Smalltalk was not native. Also native widgets had other nice features like virtual modes for TreeViews/ListViews used if you want to display many nodes. Java faced the same problem - even with Swing and JavaFX today the Java UIs and especially the ugly JFileDialog never had this "Native look and easy navigation feeling". And yes there is SWT in Java providing native widgets - but how many applications are based on it? Only a few. On the ST side Smalltalk/MT and Dolphin use native widgets but were not portable. And if you look at others like VW, VAST or Smalltalk/X you will see that engineers are good at creating powerfull systems but often fail when it comes to UI design and usability. Squeak was special and flexible with Morphic (even without multiple windows) - but looked too toyish. So yes - customers of commercial Smalltalk vendors asked for "Native" because if you had built a UI in Smalltalk it was part of a rich client application and often people compared it to other native applications or new widgets found in MS Office. But in the past customer also asked for COM/COM+, CORBA and webservices while today it is often much easier to exchange data or call functionality via HTTP, REST, ... So time and expectations have changed a lot meanwhile. Especially for the UI's. Desktop platforms unite with the web and in the web it is also possible to look more like platforms or style to look like a native app. See [1] and [2] for two simple examples. While the browsers and JS engines become faster this will also change more the way we think about applications: no installation, styleable, clear look. The google chrome experiments are a good page to see how this will soon look like. And we will be independent from devices and screen resolution. In fact more and more applications we use today run on a computers webbrowser, tablet or a smartphone (often the same way). With Morphic (even when it has Fenestri) we can not compete agains HTML/CSS on the UI side. The Canvas element and WebGL will also drive this forward. Even if one does not like web technologies - it currently is the platform where you reach people easily. Smalltalk should/could have a place in this (web centric) world: 1. As a backend to serve the web 2. On the client 3. Combining 1. and 2. For the first we have Seaside, TeaPot, Aida, ... For the seond: as it will not happen that browser vendors agree and threw out JavaScript in favour of ST runtimes, maybe we can build on top like Amber or SqueakJS do. But we should also rethink Smalltalk to find a better place as a scripting language. What I still would like to see: - tiny and fast VM with a command line and REPL - one unified and easy to use FFI with callbacks so one can use the platform, maybe others will write the bindings then - single small base image but fast loadable binary code components (modules, maybe using the LoadLibrary trick), similar to what David had with SmallScript or what BeeSmalltalk is doing with SLL's - but still with the ability to bootstrap up to a full saveable image - ability to serve the web with easy callbacks into Smalltalk for implementing functionality (especially with this we may catch 90% of the usual UI cases). Bye T. [1] Metro theme Bootstrap http://talkslab.github.io/metro-bootstrap/components.html [2] jQuery Desktop http://desktop.sonspring.com/ [3] Chrome Experiments http://www.chromeexperiments.com/
2014-09-16 20:12 GMT-03:00 Torsten Bergmann <astares@gmx.de>:
Smalltalk should/could have a place in this (web centric) world:
1. As a backend to serve the web 2. On the client 3. Combining 1. and 2.
1. This is were I see it stronger today, and I'm sure it is the majority of Pharo based solutions. 2. I can't tell. I really don't know if there are any software products built with Pharo/Squeak that DEPEND on Morphic exclusive features other than Qwac/Teleplace and Pharo/Squeak itself. Unless you're building something crazy/amazing I don't see the advantage of Morphic/Custom drawn UI over traditional widgets, even HTML widgets.
But we should also rethink Smalltalk to find a better place as a scripting language. What I still would like to see:
- tiny and fast VM with a command line and REPL
The Pharo VM is really fast, and according to all I'm reading here regarding Sista and the CogVM itself is going to get faster. It's startup time is fast even for a 40 MB image, smaller images boot faster. The REPL is doable with today's version, I even think there was a REPL implementation out there. The scripting part needs some tweaks to current CommandLineHandlers, maybe using getops like parameters.
- single small base image but fast loadable binary code components (modules, maybe using the LoadLibrary trick), similar to what David had with SmallScript or what BeeSmalltalk is doing with SLL's
VisualSmalltalk also had SLL's that could load lots of code really fast. And the VM itself was fast too. I developed with VSE and it was really cool being able to deploy "parts" of your app and bind them at demand and/or update only a particular module. As any library, it also introduced some dependency hell, so it had its tradeoffs.
- but still with the ability to bootstrap up to a full saveable image
- ability to serve the web with easy callbacks into Smalltalk for implementing functionality (especially with this we may catch 90% of the usual UI cases).
You mean async I/O? If you look at the HTTP2/SPDY drafts or discussions, what I see is that it is going to speed up communications a lot, it will still be text based, but I think binary data is going to be there too, so the cost of HTTP messaging for intercommunication is going to be cheaper in the future. Regards! Esteban A. Maringolo
Le 17/09/2014 05:13, Esteban A. Maringolo a écrit : >> Smalltalk should/could have a place in this (web centric) world: >> > >> > 1. As a backend to serve the web >> > 2. On the client >> > 3. Combining 1. and 2. > 1. This is were I see it stronger today, and I'm sure it is the > majority of Pharo based solutions. > > 2. I can't tell. > I really don't know if there are any software products built with > Pharo/Squeak that DEPEND on Morphic exclusive features other than > Q Dr.Geo and iStoa are other successfull examples. But true, for DrGeo I want to move part of it to the web client. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu
Esteban A. Maringolo wrote
I don't see the advantage of Morphic/Custom drawn UI over traditional widgets, even HTML widgets.
From an "IDE for business apps" perspective, there may be little. But I only find "Pharo is a better IDE" moderately interesting. The blue plane idea is that Pharo is a Dynabook implementation. Here uniformity, liveness, and directness make all the difference in the world *.
For example, as a brand new Smalltalker, I hated that the dialog window for adding a new directory repo in the MC Browser always started in a standard directory. Since I always use the same root repo folder, this required extra work for me to navigate there every time. But how to start implementing this? Morphic provided the answer... to my dreams! Instead of asking on the list, hunting around the system code for a hook, or reading through documentation, like I would in almost any other system *I was able to do the same thing I would do to understand a physical object in the real world*!! I "took apart" the +Repository button and figured out how it worked by bringing up the halos, inspecting the model, and the button action was revealed for understanding and modification. As important as it is to find "what Pharo is good for" in the pink plane, I have certainly not invested so much time, energy, and emotion for incremental improvement, and would find a system without beautiful blue plane ideas like Morphic (or a successor that sticks to its principles) much less interesting. * My concern with Spec is that huge layers of symbol interpretation logic subvert these properties ----- Cheers, Sean -- View this message in context: http://forum.world.st/The-Dilemma-Building-a-Futuristic-GUI-for-Ephestos-tp4... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi Torsten, On Tue, Sep 16, 2014 at 4:12 PM, Torsten Bergmann <astares@gmx.de> wrote:
Hi Eliot,
Yes - in the past most Smalltalks did not have native widgets and usually emulated the L&F. I remember VW on a Sun Sparc with Windows or Mac look. While it was cool to run 1:1 on another machine it would have been to much manpower for the vendor to reimplement all the nice widgets to really look like the native system. Especially when the L&F changed very often between Win95/96/XP/Win7/Win8 at Microsoft.
Even with good looking widgets/icons one could see from the speed and repainting issues (white rectangles for damage areas) that Smalltalk was not native. Also native widgets had other nice features like virtual modes for TreeViews/ListViews used if you want to display many nodes.
Java faced the same problem - even with Swing and JavaFX today the Java UIs and especially the ugly JFileDialog never had this "Native look and easy navigation feeling". And yes there is SWT in Java providing native widgets - but how many applications are based on it? Only a few.
On the ST side Smalltalk/MT and Dolphin use native widgets but were not portable. And if you look at others like VW, VAST or Smalltalk/X you will see that engineers are good at creating powerfull systems but often fail when it comes to UI design and usability. Squeak was special and flexible with Morphic (even without multiple windows) - but looked too toyish.
So yes - customers of commercial Smalltalk vendors asked for "Native" because if you had built a UI in Smalltalk it was part of a rich client application and often people compared it to other native applications or new widgets found in MS Office.
That's a great summary. +1.
But in the past customer also asked for COM/COM+, CORBA and webservices while today it is often much easier to exchange data or call functionality via HTTP, REST, ...
Sure, but that's invisible glue; not the same as UI components for the user. So there's a bit of a non-sequitur extrapolating from UI (user to system) to system to system connectivity.
So time and expectations have changed a lot meanwhile. Especially for the UI's. Desktop platforms unite with the web and in the web it is also possible to look more like platforms or style to look like a native app. See [1] and [2] for two simple examples.
While the browsers and JS engines become faster this will also change more the way we think about applications: no installation, styleable, clear look. The google chrome experiments are a good page to see how this will soon look like. And we will be independent from devices and screen resolution. In fact more and more applications we use today run on a computers webbrowser, tablet or a smartphone (often the same way).
With Morphic (even when it has Fenestri) we can not compete agains HTML/CSS on the UI side. The Canvas element and WebGL will also drive this forward. Even if one does not like web technologies - it currently is the platform where you reach people easily.
Smalltalk should/could have a place in this (web centric) world:
1. As a backend to serve the web 2. On the client 3. Combining 1. and 2.
For the first we have Seaside, TeaPot, Aida, ... For the seond: as it will not happen that browser vendors agree and threw out JavaScript in favour of ST runtimes, maybe we can build on top like Amber or SqueakJS do.
But we should also rethink Smalltalk to find a better place as a scripting language. What I still would like to see:
- tiny and fast VM with a command line and REPL
We're getting there with fast. Tiny needs more definition, but the core Cog/Spur VM on Mac minus plugins and GUI code is 568k, 506k code, 63k data; the newspeak VM which has fewer primitives but support for two bytecode sets is 453k, 386k code, 68k data. That includes the interpreter, JIT, core primitives and memory manager/GC. Add on several k for the FFI, C library et al and a VM in a megabyte is realistic. Is that in the right ball park? - one unified and easy to use FFI with callbacks so one can use the
platform, maybe others will write the bindings then
+1. Again that's central to our efforts.
- single small base image but fast loadable binary code components (modules, maybe using the LoadLibrary trick), similar to what David had with SmallScript or what BeeSmalltalk is doing with SLL's
Yep. But personally I think Fuel is better and just as fast. Certainly that's the parcels experience.
- but still with the ability to bootstrap up to a full saveable image
+1.
- ability to serve the web with easy callbacks into Smalltalk for implementing functionality (especially with this we may catch 90% of the usual UI cases).
This we'll leave to the web framework designers, but it seems eminently doable no?
Bye T.
[1] Metro theme Bootstrap http://talkslab.github.io/metro-bootstrap/components.html [2] jQuery Desktop http://desktop.sonspring.com/ [3] Chrome Experiments http://www.chromeexperiments.com/
I love the circle game but oh boy does the implementation show through in the pauses. My old 5.x Safari pauses noticeably every two seconds or so. Chrome is smooth. -- best, Eliot
2014-09-17 14:07 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
- tiny and fast VM with a command line and REPL
We're getting there with fast. Tiny needs more definition, but the core Cog/Spur VM on Mac minus plugins and GUI code is 568k, 506k code, 63k data; the newspeak VM which has fewer primitives but support for two bytecode sets is 453k, 386k code, 68k data. That includes the interpreter, JIT, core primitives and memory manager/GC. Add on several k for the FFI, C library et al and a VM in a megabyte is realistic. Is that in the right ball park?
Those sizes are impressively small! All those features in less than a megabyte are small even if we go back in time ten years from now. I'm eager to see and use those futuristic VMs even for mundane tasks. Esteban A. Maringolo
Eliot wrote:
We're getting there with fast. Â Tiny needs more definition, but the core Cog/Spur VM on Mac minus plugins and GUI >code is 568k, 506k code, 63k data; the newspeak VM which has fewer primitives but support for two bytecode sets is >453k, 386k code, 68k data. Â That includes the interpreter, JIT, core primitives and memory manager/GC. Add on >several k for the FFI, C library et al and a VM in a megabyte is realistic. Â Is that in the right ball park?
Yes, wet's my appetite :) Tiny means easy to download and use for scripting, no other dependencies for the out of the box REPL experience. But still powerfull to built one on another and scale up to large programs. Initially you provide just a simple VM executable for a "tiny smalltalk" (ts), for simple things like: c:\myscripts\ts.exe -e 3+4 7 where ts.exe is the VM in a few kB including a small initial kernel image (as part of the PE DATA section). It should be able to run scripts: c:\myscripst\ts.exe automate.st It should be possible to easily build components (either with or without the sources): ts.exe sunit.st -o sunit.sll ts.exe sunit.st -noSource -o sunit.sll So you can either include other scripts ts.exe -i sunit.st mytests.st or link the previously built binary components to form something new. ts.exe -l junit.sll mytests.st But it should be possible to build another vm+image easily: ts.exe -i mykillerapp.st -o killerapp.exe or ts.exe -l mykillerapp.sll -o killerapp.exe by writing a new PE file for Windows either including a new kernel image or a combined one based on the already built-in initial kernel of the previous one. So I can deploy a killerapp or reassemble it to form the next language version. SmallScript was very close to that and it was a nice thing to work with. Especially since usually Smalltalk usually throws things out at the end - but one never builds a house by carving it out of a rock. We need bricks to assemble. With the above scheme you could build components, some of them portable, others explicitly non-portable as the code includes native calls. The later have to be rebuilt on the other platform - so if you have good design abstractions you can implement a UI lib on Windows and one on Mac. Some of the components are with the source code packaged in for debugging (but not changeable), for closed source components you leave it out. And still it should support pinnable objects (not moved by GC for callouts), sandboxing, Classes with UUIDs to allow for side by side loading/migration and an extensible meta-scheme as this is where Smalltalk is still the hero of all und metaprogramming will be our future. Also the VM should be available as a shared component - so it can run in-process in other programs like a web browser. Always wished to write: <script type="text/tinyscript"> BrowserLog write: 'HelloWorld'. </script> directly in HTML. And this is only the beginning of the wish list...
Yep. Â But personally I think Fuel is better and just as fast. Â Certainly that's the parcels experience. Â Â - but still with the ability to bootstrap up to a full saveable image
Yes, Fuel would be an option. At least it would be platform independent. Not sure about other options (quick loading by mapping component using memory mapped files etc.) Â Â
This we'll leave to the web framework designers, but it seems eminently doable no?
For sure. Bye Torsten
Hi Torsten, wow, what a great summary. Thanks. See below. On Wed, Sep 17, 2014 at 12:09 PM, Torsten Bergmann <astares@gmx.de> wrote:
Eliot wrote:
We're getting there with fast. Tiny needs more definition, but the core Cog/Spur VM on Mac minus plugins and GUI >code is 568k, 506k code, 63k data; the newspeak VM which has fewer primitives but support for two bytecode sets is >453k, 386k code, 68k data. That includes the interpreter, JIT, core primitives and memory manager/GC. Add on >several k for the FFI, C library et al and a VM in a megabyte is realistic. Is that in the right ball park?
Yes, wet's my appetite :)
Tiny means easy to download and use for scripting, no other dependencies for the out of the box REPL experience. But still powerfull to built one on another and scale up to large programs.
Initially you provide just a simple VM executable for a "tiny smalltalk" (ts), for simple things like:
c:\myscripts\ts.exe -e 3+4 7
where ts.exe is the VM in a few kB including a small initial kernel image (as part of the PE DATA section). It should be able to run scripts:
c:\myscripst\ts.exe automate.st
It should be possible to easily build components (either with or without the sources):
ts.exe sunit.st -o sunit.sll ts.exe sunit.st -noSource -o sunit.sll
So you can either include other scripts
ts.exe -i sunit.st mytests.st
or link the previously built binary components to form something new.
ts.exe -l junit.sll mytests.st
But it should be possible to build another vm+image easily:
ts.exe -i mykillerapp.st -o killerapp.exe or ts.exe -l mykillerapp.sll -o killerapp.exe
by writing a new PE file for Windows either including a new kernel image or a combined one based on the already built-in initial kernel of the previous one. So I can deploy a killerapp or reassemble it to form the next language version.
SmallScript was very close to that and it was a nice thing to work with. Especially since usually Smalltalk usually throws things out at the end - but one never builds a house by carving it out of a rock. We need bricks to assemble.
+1000. With the above scheme you could build components, some of them portable,
others explicitly non-portable as the code includes native calls. The later have to be rebuilt on the other platform - so if you have good design abstractions you can implement a UI lib on Windows and one on Mac.
Some of the components are with the source code packaged in for debugging (but not changeable), for closed source components you leave it out.
And still it should support pinnable objects (not moved by GC for callouts), sandboxing, Classes with UUIDs to allow for side by side loading/migration and an extensible meta-scheme as this is where Smalltalk is still the hero of all und metaprogramming will be our future.
So so far I have pinning. But I'd love to hear more detail on sandboxing. I'm not sure about UUIDs. What about other mechanisms, namespaces, ClassBoxes? UUID sounds too much like an implementation to me. No one is proposing qualifying class names with UUIDs (Array:c5c09212-0c7d-44f3-81b7-18ae5d7f14d9 new: 5 ????). How about reitierating this more abstractly? Also the VM should be available as a shared component - so it can run
in-process in other programs like a web browser. Always wished to write:
<script type="text/tinyscript"> BrowserLog write: 'HelloWorld'. </script>
directly in HTML.
And this is only the beginning of the wish list...
Please, I'd love to have you write a fuller list. We could add it to the list at Cog Projects <http://www.mirandabanda.org/cogblog/cog-projects/> or add it to a "Directions" page or some such. But capturing these ideas is importasnt.
Yep. But personally I think Fuel is better and just as fast. Certainly that's the parcels experience.
- but still with the ability to bootstrap up to a full saveable image
Yes, Fuel would be an option. At least it would be platform independent. Not sure about other options (quick loading by mapping component using memory mapped files etc.)
Well, mapping finished images a la VW's PermSpace is probably easier. The memory mapping in .Nt is extremely complex. But I get the requirement; ultra-fast start-up of small components.
This we'll leave to the web framework designers, but it seems eminently doable no?
For sure.
Bye Torsten
thanks again. And give serious thought to carefully enunciating these requirements/this design sketch? -- best, Eliot
Torsten we are 100% in sync on that vision :) Stef
Eliot wrote:
We're getting there with fast. Tiny needs more definition, but the core Cog/Spur VM on Mac minus plugins and GUI >code is 568k, 506k code, 63k data; the newspeak VM which has fewer primitives but support for two bytecode sets is >453k, 386k code, 68k data. That includes the interpreter, JIT, core primitives and memory manager/GC. Add on >several k for the FFI, C library et al and a VM in a megabyte is realistic. Is that in the right ball park? Yes, wet's my appetite :)
Tiny means easy to download and use for scripting, no other dependencies for the out of the box REPL experience. But still powerfull to built one on another and scale up to large programs.
Initially you provide just a simple VM executable for a "tiny smalltalk" (ts), for simple things like:
c:\myscripts\ts.exe -e 3+4 7
where ts.exe is the VM in a few kB including a small initial kernel image (as part of the PE DATA section). It should be able to run scripts:
c:\myscripst\ts.exe automate.st
It should be possible to easily build components (either with or without the sources):
ts.exe sunit.st -o sunit.sll ts.exe sunit.st -noSource -o sunit.sll
So you can either include other scripts
ts.exe -i sunit.st mytests.st
or link the previously built binary components to form something new.
ts.exe -l junit.sll mytests.st
But it should be possible to build another vm+image easily:
ts.exe -i mykillerapp.st -o killerapp.exe or ts.exe -l mykillerapp.sll -o killerapp.exe
by writing a new PE file for Windows either including a new kernel image or a combined one based on the already built-in initial kernel of the previous one. So I can deploy a killerapp or reassemble it to form the next language version.
SmallScript was very close to that and it was a nice thing to work with. Especially since usually Smalltalk usually throws things out at the end - but one never builds a house by carving it out of a rock. We need bricks to assemble.
With the above scheme you could build components, some of them portable, others explicitly non-portable as the code includes native calls. The later have to be rebuilt on the other platform - so if you have good design abstractions you can implement a UI lib on Windows and one on Mac.
Some of the components are with the source code packaged in for debugging (but not changeable), for closed source components you leave it out.
And still it should support pinnable objects (not moved by GC for callouts), sandboxing, Classes with UUIDs to allow for side by side loading/migration and an extensible meta-scheme as this is where Smalltalk is still the hero of all und metaprogramming will be our future.
Also the VM should be available as a shared component - so it can run in-process in other programs like a web browser. Always wished to write:
<script type="text/tinyscript"> BrowserLog write: 'HelloWorld'. </script>
directly in HTML.
And this is only the beginning of the wish list...
Yep. But personally I think Fuel is better and just as fast. Certainly that's the parcels experience. - but still with the ability to bootstrap up to a full saveable image Yes, Fuel would be an option. At least it would be platform independent. Not sure about other options (quick loading by mapping component using memory mapped files etc.)
This we'll leave to the web framework designers, but it seems eminently doable no? For sure.
Bye Torsten
Eliot Miranda-2 wrote
without losing window state, and one can switch dynamically, and, IIRC, mix both
That /is/ cool :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/The-Dilemma-Building-a-Futuristic-GUI-for-Ephestos-tp4... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 09/15/2014 11:54 AM, Eliot Miranda wrote:
Agreed. But one real problem with the Squeak/Pharo UI is the lack of native windows. There is an old project Graphics-External-Ffenestri but AFAICT it isn't being used. But there /is/ a really good prototype of a native window system above Squeak done by Vassili Bykov in Newspeak. The native windows contain morphs, but anything, including MVC, can be present. This provides native Win32 Windows (doing other platforms is merely work) /and/ the ability to snapshot and bring back up windows on a different platform (e.g. open in win32, snapshot and bring up in Squeak/Pharo Morphic windows, or vice verse), and the ability to do this dynamically. Is anyone motivated to port the Newspeak code back to Squeak/Pharo?
If you're interested, contact me, or Vassili, or Bob Westergaard and ask about Brazil (think plumbing).
By coincidence, this week I dusted off my project (shelved about a year and a half ago) to port Brazil and Hopscotch to Smalltalk. And have made some progress, though it's still very early stages. If anyone else is interested in helping move this forward more quickly, let me know... Regards, -Martin
HI martin I'm because this is important to be able to learn Stef On 19/9/14 06:36, Martin McClure wrote:
On 09/15/2014 11:54 AM, Eliot Miranda wrote:
Agreed. But one real problem with the Squeak/Pharo UI is the lack of native windows. There is an old project Graphics-External-Ffenestri but AFAICT it isn't being used. But there /is/ a really good prototype of a native window system above Squeak done by Vassili Bykov in Newspeak. The native windows contain morphs, but anything, including MVC, can be present. This provides native Win32 Windows (doing other platforms is merely work) /and/ the ability to snapshot and bring back up windows on a different platform (e.g. open in win32, snapshot and bring up in Squeak/Pharo Morphic windows, or vice verse), and the ability to do this dynamically. Is anyone motivated to port the Newspeak code back to Squeak/Pharo?
If you're interested, contact me, or Vassili, or Bob Westergaard and ask about Brazil (think plumbing).
By coincidence, this week I dusted off my project (shelved about a year and a half ago) to port Brazil and Hopscotch to Smalltalk. And have made some progress, though it's still very early stages.
If anyone else is interested in helping move this forward more quickly, let me know...
Regards,
-Martin
Le 14/09/2014 18:20, kilon alios a écrit :
Thank you all people who helped me. But I don't think it worths to make my project in Pharo, too many problems. I feel privileged to have helped you with my contributions , I wish the Pharo the best.
I could return back to Python but I think its time for me to bite the bullet and learn C/C++, since graphics is an area that deeply interest me (more as an artist less as a coder), so I don't have much of choice. Maybe I can brings some of my code back to Pharo with NB wrappers , I definitely will keep a close eye on Pharo.
I understand your frustration because I felt it a few months ago. Now, you should bet on Athens, that the less risky way and it is part of Pharo itself, and it is backed by a C library. For DrGeo, I found bitmap rendering to be much faster after Athens use. Whenever you meet issue, Igor will be helpful and this will help improving Athens. Now, I have to admit I don't understand why Igor was distracted with other task before finishing and polishing the Athens support on the image. It brings to destabilizing state for newcomer or even expert willing to invest on Athens use. I got lost many time and I was close to throw all the code through the window as well. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu
hehe you have not seen me frustrated if you not have seen me code in C++ for windows and being so frustrated at Microsoft MFC that I punched my screen :D That was 20 years ago and fortunately I have not punched a screen since then. That day was the day I realised I did not have the patience , the metal, to become a professional coder. So I can actually tell you that I prefer Pharo over C++ , 1000 times :D Coding in Pharo was the most fun I have ever had coding in any programming language. Nah I only have love for Pharo, this is why each time I contributed I did not even have a doubt. I think Pharo is awesome and deserves to be 1.000.000 times more popular. The problems I described is a natural thing for unpopular software. Its not the fault of Pharo its not anyone's fault. Actually I feel Pharo is on the right road, even on the documentation front that I always complained Pharo for the Enterprise is very active and new content is added almost daily. So Pharo is 100% on the right road to success. My problem is not Igor , or Athens or transparency animation with pngs. The problem is that Blender is way more powerful and tailor made for my needs, Pharo is not. I knew that before starting with Pharo and I knew that Pharo would something to have fun thing for some time. Blender is 1 million lines of code , speciallised to high performance 3d graphics , build on top of a language that is the most popular for 3d graphics and on top of very powerful and mature libraries for 3d. So Pharo was never trully want I wanted and I knew that. Pharo was the most beautiful distraction. I just realised it was about time to get coding Blender source. I played around with Pharo so much cause I was not eager to start coding again in C++ :D Also I think its unfair to put Athens in one developer responsibility, there is only so much one coder can do and frankly Igor has already done a lot for Pharo. Athens is certainly not the only area Pharo needs polishing. Lets talk about very basic stuff like git support , Pharo is not there yet. If you have worked with other languages there are some things that you take for granted. Igor has been more than helpful, never left any of my questions about Athens and NBOpenGL unanswered , he is a great guy :) So I have only love for Pharo I will keep playing around with it , just way less frequently. I wish you all good luck, thanks for helping me understand and enjoy Pharo. See you around :) On Sun, Sep 14, 2014 at 10:07 PM, Hilaire <hilaire@drgeo.eu> wrote:
Le 14/09/2014 18:20, kilon alios a écrit :
Thank you all people who helped me. But I don't think it worths to make my project in Pharo, too many problems. I feel privileged to have helped you with my contributions , I wish the Pharo the best.
I could return back to Python but I think its time for me to bite the bullet and learn C/C++, since graphics is an area that deeply interest me (more as an artist less as a coder), so I don't have much of choice. Maybe I can brings some of my code back to Pharo with NB wrappers , I definitely will keep a close eye on Pharo.
I understand your frustration because I felt it a few months ago.
Now, you should bet on Athens, that the less risky way and it is part of Pharo itself, and it is backed by a C library. For DrGeo, I found bitmap rendering to be much faster after Athens use. Whenever you meet issue, Igor will be helpful and this will help improving Athens.
Now, I have to admit I don't understand why Igor was distracted with other task before finishing and polishing the Athens support on the image. It brings to destabilizing state for newcomer or even expert willing to invest on Athens use. I got lost many time and I was close to throw all the code through the window as well.
Hilaire
-- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu
Le 14/09/2014 21:41, kilon alios a écrit :
My problem is not Igor , or Athens or transparency animation with pngs. The problem is that Blender is way more powerful and tailor made for my needs, Pharo is not. I knew that before starting with Pharo and I knew that Pharo would something to have fun thing for some time. Blender is 1 million lines of code , speciallised to high performance 3d graphics , build on top of a language that is the most popular for 3d graphics and on top of very powerful and mature libraries for 3d.
Euh, don't get me wrong, I have nothing to complain against Igor, as I wrote he's very helpful, talented guy with a good load of wisdom. Nevertheless, part of Athens need to be polished and from my pov it looks like it is not the priority, and I am disappointed by that. But again my vision of the situation is from outside, so definitely biased. Regarding Blender and Pharo: don't you want to control Blender engine from a Pharo model. I mean why do you want to bother with graphics and animation rendered by Pharo, it is not what Pharo is good at. What I will do is design the model in Pharo then drive Blender from it. That should be eaiser and benefit from the two worlds. Am I wrong? Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu
It depends what you mean by control blender. Blender is 2 things a) C/C++ source code that implements all features that users use b) the Python API that allows to use all features that a user can use. Ephestos already allows full access to (b) . So for example if you wanted Dr Geo to export its data to blender so Dr Geo can convert its geometry to 3D and use all the nice features of blender you can do that already with ephestos. But for modifying existing functionality you need to get your hands dirty with the source. Implementing new fuctionality like importers / exporters etc is also doable via API so its doable via Ephestos. But cpu intense new fuctionality is done by modifying the source. I am not excluding creating a parser for the blender source , at first the thought did not cross my mind. If pettitparser has already a C or C++ parser that will be doable for me. I will have to research it further. If its easy enough I may be sticking with Pharo afterall. Le 14/09/2014 21:41, kilon alios a écrit :
My problem is not Igor , or Athens or transparency animation with pngs. The problem is that Blender is way more powerful and tailor made for my needs, Pharo is not. I knew that before starting with Pharo and I knew that Pharo would something to have fun thing for some time. Blender is 1 million lines of code , speciallised to high performance 3d graphics , build on top of a language that is the most popular for 3d graphics and on top of very powerful and mature libraries for 3d.
Euh, don't get me wrong, I have nothing to complain against Igor, as I wrote he's very helpful, talented guy with a good load of wisdom. Nevertheless, part of Athens need to be polished and from my pov it looks like it is not the priority, and I am disappointed by that. But again my vision of the situation is from outside, so definitely biased. Regarding Blender and Pharo: don't you want to control Blender engine from a Pharo model. I mean why do you want to bother with graphics and animation rendered by Pharo, it is not what Pharo is good at. What I will do is design the model in Pharo then drive Blender from it. That should be eaiser and benefit from the two worlds. Am I wrong? Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu
May be I wrongly expressed: imagine a 3D game whose model world is in Pharo then rendered in Blender (I guess model data need to be share between Pahro and Blender, but graphic only reside on Blender). Now you could use the Pharo dev tools like inspector & al. to play with your games. With DrGeo analogy: it will be more like a shared 3D model between Pharo and Blender, and controlled from Pharo. Le 15/09/2014 11:02, kilon alios a écrit :
It depends what you mean by control blender. Blender is 2 things a) C/C++ source code that implements all features that users use b) the Python API that allows to use all features that a user can use. Ephestos already allows full access to (b) . So for example if you wanted Dr Geo to export its data to blender so Dr Geo can convert its geometry to 3D and use all the nice features of blender you can do that already with ephestos. But for modifying existing functionality you need to get your hands dirty with the source. Implementing new fuctionality like importers / exporters etc is also doable via API so its doable via Ephestos. But cpu intense new fuctionality is done by modifying the source.
-- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu
Yeap you can do that with Ephestos, or you will be able to do it shortly. You can send data from pharo to blender but you cannot send data from blender to pharo. But thats is just a matter of adding a small of piece of code in python side so I will implement it probably today. So yes I hope this week if not today pharo inspector to be able to inspect blender data. I am not sure about the updating though, inspector update its display when the data changes to display the latest data , that would require to keep sending messages to blender to fetch the latest data, its not hard at all just that inspector will have to be modified to do that.I am not familiar with inspector internal so that is up to pharoers to do. So you can now change any model data inside Blender , not just geometry data but anything like textures, materials, animation data and tons more. The Python API has the same access to data structures that the Blender source has so in that department Ephestos is extremely powerful. I have not hooked Ephestos to the Blender Game Engine yet, again that should not be more than an afternoon of work, so I will do it eventually. It may not even needs a change , most likely it wont , just a case of importing a python module. Shared 3d model ? sure that is also doable, when I add to Ephestos the ability to retrieve data from blender you will be able to create your own 3d model, your own pharo objects to wrap blender python objects. Generally you will be able to do anything you can do with Blender from Pharo. The only limitation is not expect the socket used by Ephestos to able to retrieve GBs or even MBs of Blender data in an instant, usually the kind of data that is that big is only the geometry data itself that can be millions of polygons. This is where a FFI solution would be better than my solution using sockets. But then would you want to play with GBs of data in pharo ? I think not. Be warned that Ephestos maps 1 by 1 to the Blender API , that means you have to learn the Blender API and if I implement support for Blender Game Engine then you will need to know the Blender Game Engine API if you want to create a game or a realtime interactive 2d or 3d demo of some sort. Some knowledge , just the basic stuff , of python is desirable too. The only difference is that instead of coding in python you code in pharo. Ephestos has access to all python libraries, and by everything I mean everything . So if you dont want to use the BGE you can use another game engine as long it supports cpython. Unity can work with ironpython from what I read, Ephestos may not work out of the box in that case but with minor modifications it should not be more than a hour of work to get Unity working with Pharo. Again I leave that to anyone that is seriously interested. Ephestos is super simple, very basic socket code, so its easy to port around. The only tricky part is how I parse Pharo syntax to python syntax using regex but I think the code is clear enough to be understood by any experienced pharo coder. Probably it can be improve in many diffirent ways too. The syntax parser however is limited to basic python syntax, like accessing objects , global variables and calling methods and functions. For more advanced stuff like defining python classes, functions, list comprehensions etc you will need to use python syntax inlined inside your Pharo code which Ephestos also offers as fallback. The parser could be expanded to more advanced python syntax I may improve that area in the future. But then I dont I have a problem writing some code in python from pharo. But as I said, the challenge is not using Ephestos but learning Blender and its API which both have a steep learning curve because they offer a ton of functionality. But then the same problem you will face using any of the very powerful Game engines out there. On Mon, Sep 15, 2014 at 12:30 PM, Hilaire <hilaire@drgeo.eu> wrote:
May be I wrongly expressed: imagine a 3D game whose model world is in Pharo then rendered in Blender (I guess model data need to be share between Pahro and Blender, but graphic only reside on Blender). Now you could use the Pharo dev tools like inspector & al. to play with your games. With DrGeo analogy: it will be more like a shared 3D model between Pharo and Blender, and controlled from Pharo.
Le 15/09/2014 11:02, kilon alios a écrit :
It depends what you mean by control blender. Blender is 2 things a) C/C++ source code that implements all features that users use b) the Python API that allows to use all features that a user can use. Ephestos already allows full access to (b) . So for example if you wanted Dr Geo to export its data to blender so Dr Geo can convert its geometry to 3D and use all the nice features of blender you can do that already with ephestos. But for modifying existing functionality you need to get your hands dirty with the source. Implementing new fuctionality like importers / exporters etc is also doable via API so its doable via Ephestos. But cpu intense new fuctionality is done by modifying the source.
-- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu
> I understand your frustration because I felt it a few months ago. > > Now, you should bet on Athens, that the less risky way and it is part > of Pharo itself, and it is backed by a C library. For DrGeo, I found > bitmap rendering to be much faster after Athens use. > Whenever you meet issue, Igor will be helpful and this will help > improving Athens. > > Now, I have to admit I don't understand why Igor was distracted with > other task before finishing and polishing the Athens support on the image. - War in Ukraina. - And igor is working on TxText: writing a texteditor is something that takes time. We need it because we want to display text with athens. - worked on OSWindow We will push it in the image as soon as we release the new integration tool that will manage configurations (like that we can update Zinc, TxText, OSWindow, Athens,.... using configuration) > It brings to destabilizing state for newcomer or even expert willing > to invest on Athens use. I got lost many time and I was close to throw > all the code through the window as well. > > Hilaire >
thanks for you kind words Ben. No the GUI I am developing for Ephestos is suppose to be separate from Blender , I have no intention of forking Blender and maintaining such fork. Regarding OSWindow that wont be necessary I will most likely use Ephestos to access pyQT which in turn will give me access to QT. So most likely I will be building the futuristic GUI on top of QT. I could also bypass python and do a C++ wrapper for pharo for QT, not full functionality but rather the parts that interest me but that will be a lot more tricky. I have changed my mind, with the advice I have been getting here and in the parser C++ thread it looks like I will keep using pharo for generation of my C code. Afterall Slang is already heavily used so I think I can rely on it. What Slang cannot do I can do it coding manually in C. So I think I can fit Pharo to my workflow quite a lot. Very happy to be proven once more wrong about Pharo :) On Mon, Sep 15, 2014 at 4:21 PM, Ben Coman <btc@openinworld.com> wrote:
kilon alios wrote:
No offense intended but lately the more I dive inside Pharo the more I feel I waste my time, I love the IDE and the environment and live coding but using the libraries is a never ending struggle for me. I agree with Nicolai the landscape is not good, Pharo really lacks mature libraries . Sure we like to bash Java but Java libs are rock solid and very well documented. I bring Java as example. Again I am not complaining at all, I knew when I came to Pharo that I will have to face these limitations. I also don't feel comfortable asking questions all the time as if I want others to do my code but I did not have much of a choice. I just cant deal with the lack of documentation any more.
You demonstrated your willingness to contribute and I think that goes a long way to balance any number of questions. Now you should appreciate that asking questions actually shows someone making use of a library, which can be good thing for a developer. And as ESR says [1], "The first thing to understand is that hackers actually like hard problems and good, thought-provoking questions about them. [...] If you give us an interesting question to chew on we'll be grateful to you; good questions are a stimulus and a gift. Good questions help us develop our understanding, and often reveal problems we might not have noticed or thought about otherwise."
[1] http://www.catb.org/esr/faqs/smart-questions.html (yes I know, my favourite again)
I think Pharo as a general idea is great , you definitely have taken the Squeak fork one big step further but you have a very long road ahead of you to make Pharo a modern environment. Asking for animating a window with good performance is one of the very basics of a good GUI API. I know you have limited resources and once again I am not complaining at all I just present my opinion. Its clear that Pharo needs a lot more people to contribute and bring the system forward at least to solve the basic problems.
Thank you all people who helped me. But I don't think it worths to make my project in Pharo, too many problems. I feel privileged to have helped you with my contributions , I wish the Pharo the best.
I can definitely understand with your main interest being an existing application like Blender written in C, then developing in C may give you the greatest power. Good luck with it!
I could return back to Python but I think its time for me to bite the bullet and learn C/C++, since graphics is an area that deeply interest me (more as an artist less as a coder), so I don't have much of choice. Maybe I can brings some of my code back to Pharo with NB wrappers , I definitely will keep a close eye on Pharo.
In a few months I will also present to the Pharo community a secret last contribution ;)
I have really appreciated your enthusiasm, your joy of Pharo, and your honest constructive criticisms. Sometimes it can be suspect that Smalltalker fanbois are blinded by their world view, but as a newcomer to Pharo your positive comparisons of Pharo versus languages-you-knew-better were a nice validation of Pharo, even if there remain things to improve. Now life is a long and winding road, so maybe opportunity will arise sometime for you to use Pharo again. I hope you have fun in the meantime!
btw, just a parting thought that I had regarding your requirement. Rather than trying to do your Blender graphics rendering on top of some layer in Pharo, you might** use OSWindow [2] to create a native-window-canvas that you pass to Blender for it to render directly into. As I understand it, you could then build a Pharo base GUI around that window. Now if that happened to be possible, your dive into programming Blender in "C" would probably be of great benefit. Maybe something to come back to later.
**Disclaimer, I haven't used OSWindow. Its just an intuitive thought. [2] http://smalltalkhub.com/#!/~OS/OS-Windows (scroll down to "The Windows User Interface" and "Graphics")
cheers -ben
2014-09-14 17:26 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
Do you know anything better for futuristic UIs at the moment?
No, I don't know anything about futuristic UI at All :) nor do I know anything about woden besides one demo video (is woden for UIs?). Anyway I think only a few people know what woden is or for what it is for, and thats the point. Your question: "Why not use Woden?" sounds like "Everyone uses woden, why don't you?"
I guess that we aren't talking about commercial dev here. And if we would rely on everything being documented in Pharo, errr, we wouldn't go too far.
That being said, there are plenty of examples in the Woden code.
Phil Le 14 sept. 2014 16:28, "Nicolai Hess" <nicolaihess@web.de> a écrit :
Why should he use it, now?
I mean, is there a stable API? Or a roadmap ?
Sometimes it is a bit dangerous to trust on "bleeding edge" pharo frameworks. I did some work based on Roassal3D just to found out there won't be any further development. The same happens with Roassal and GraphET. The same can happen with Woden too :)
2014-09-14 14:13 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
Why not use Woden?
Phil Le 14 sept. 2014 12:51, "kilon alios" <kilon.alios@gmail.com> a écrit :
yeah I am afraid transparency is very important to me
On Sun, Sep 14, 2014 at 1:34 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-09-14 11:32 GMT+02:00 stepharo <stepharo@free.fr>:
I remember that there was an animated gif support. Now I do not remember exactly.
At least in squeak there is an AnimatedImageMorph, that can load and display animated gifs. That works and is quite fast even for multiple instances. But of course no (alpha-)transparency
for roassal2 have a look at the viva classes: this is the animation frameworks that igor designed.
Stef
On 14/9/14 10:22, kilon alios wrote:
so I tried to animate in Roassal having two different images display with a delay for few millisecond but it only displays the second image with this code
form1 :=Form fromFileNamed:'/Users/kilon/Pictures/pharo.png'. form2 :=Form fromFileNamed:'/Users/kilon/Pictures/box.png'. v := RTView new. c := v canvas. s := TRBitmapShape new. s form: form1. c addShape: s. v open.
(1 to: 100) do: [ :index| s form: form1. s signalUpdate . "(Delay forMilliseconds: 1000 ) wait." s form: form2. s signalUpdate . (Delay forMilliseconds: 1000) wait.].
I looked into RTAnimation but dont know how to use it for this example. Any help ? Does Roassal 2 support such animations ?
if I do s form: and then s signalUpdate for each form separately it works fine but inside the loops does not seem to work , I tried bigger delays with no effect.
On Sun, Sep 14, 2014 at 10:57 AM, stepharo <stepharo@free.fr> wrote:
Ronie when you ready I can help writting a chapter for the nex book.
Stef
On 13/9/14 21:42, Ronie Salgado wrote:
Hello,
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
I have an adapted version of Swig for Pharo NativeBoost here: https://github.com/ronsaldo/swig
Currently I am using it to generate my Bullet bindings (available here: https://github.com/ronsaldo/bullet-pharo) that can be used as an example of using Swig. I still have to improve more my Swig generator, by writing documentation and fixing some bugs.
Greetings, Ronie
2014-09-13 16:11 GMT-03:00 stepharo <stepharo@free.fr>:
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
Stef
Almost a decade ago I did some ruby bindings by hand. It was working out of the box
Bye Enno
Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios@gmail.com>:
" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? "
yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file.
So basically its a lot like the average games out there.
"I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing."
ok
"For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."
I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things.
"Sure. The downpoint, you will depend on one additional layer."
dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large.
"Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious."
Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically.
So basically you will be using Blender as a GUI designer.
"Use fuel to store the state of your application objects."
ah nice so fuel is a good candidate.
I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
Well⦠Porting Roassal3d to Woden is almost straightforward :-) We can help on this. Effort behind Woden, Roassal, GraphET are not to simply tools. But instead producing an effective solution for a given problem. So, they will always be changing :-) Cheers, Alexandre On Sep 14, 2014, at 7:28 AM, Nicolai Hess <nicolaihess@web.de> wrote:
Sometimes it is a bit dangerous to trust on "bleeding edge" pharo frameworks. I did some work based on Roassal3D just to found out there won't be any further development. The same happens with Roassal and GraphET. The same can happen with Woden too :)
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I remember that there was an animated gif support. Now I do not remember exactly.
At least in squeak there is an AnimatedImageMorph, that can load and display animated gifs. That works and is quite fast even for multiple instances. But of course no (alpha-)transparency
Yes this is that one. Stef
Hi Kilon, Not sure what you are trying to do. Try this: -=-=-=-=-=-=-=-=-=-=-=-= forms := Form allInstances. v := RTView new. t := 1. e := (RTBitmap new form: [ :index | forms at: index ]) elementOn: t. v add: e. v open. [ 50 timesRepeat: [ t := t + 1. e model: t. e updateShape. (Delay forMilliseconds: 500) wait. v signalUpdate ] ] fork. -=-=-=-=-=-=-=-=-=-=-=-= Cheers, Alexandre On Sep 14, 2014, at 1:22 AM, kilon alios <kilon.alios@gmail.com> wrote:
so I tried to animate in Roassal having two different images display with a delay for few millisecond but it only displays the second image with this code
form1 :=Form fromFileNamed:'/Users/kilon/Pictures/pharo.png'. form2 :=Form fromFileNamed:'/Users/kilon/Pictures/box.png'. v := RTView new. c := v canvas. s := TRBitmapShape new. s form: form1. c addShape: s. v open.
(1 to: 100) do: [ :index| s form: form1. s signalUpdate . "(Delay forMilliseconds: 1000 ) wait." s form: form2. s signalUpdate . (Delay forMilliseconds: 1000) wait.].
I looked into RTAnimation but dont know how to use it for this example. Any help ? Does Roassal 2 support such animations ?
if I do s form: and then s signalUpdate for each form separately it works fine but inside the loops does not seem to work , I tried bigger delays with no effect.
On Sun, Sep 14, 2014 at 10:57 AM, stepharo <stepharo@free.fr> wrote: Ronie when you ready I can help writting a chapter for the nex book.
Stef
On 13/9/14 21:42, Ronie Salgado wrote:
Hello,
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
I have an adapted version of Swig for Pharo NativeBoost here: https://github.com/ronsaldo/swig
Currently I am using it to generate my Bullet bindings (available here: https://github.com/ronsaldo/bullet-pharo) that can be used as an example of using Swig. I still have to improve more my Swig generator, by writing documentation and fixing some bugs.
Greetings, Ronie
2014-09-13 16:11 GMT-03:00 stepharo <stepharo@free.fr>:
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
Stef
Almost a decade ago I did some ruby bindings by hand. It was working out of the box
Bye Enno
Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios@gmail.com>:
" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? "
yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file.
So basically its a lot like the average games out there.
"I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing."
ok
"For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."
I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things.
"Sure. The downpoint, you will depend on one additional layer."
dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large.
"Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious."
Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically.
So basically you will be using Blender as a GUI designer.
"Use fuel to store the state of your application objects."
ah nice so fuel is a good candidate.
I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
ah thank you ... yeah I tried something similar as a posted in a previous email of this thread. Looks like thats how fast morphic can go. Its not super bad though , I can live with this performance :) I will have to keep animations non looping and quite small and I should be fine. On Fri, Sep 19, 2014 at 2:22 AM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi Kilon,
Not sure what you are trying to do.
Try this: -=-=-=-=-=-=-=-=-=-=-=-= forms := Form allInstances. v := RTView new. t := 1. e := (RTBitmap new form: [ :index | forms at: index ]) elementOn: t.
v add: e. v open.
[ 50 timesRepeat: [ t := t + 1. e model: t. e updateShape. (Delay forMilliseconds: 500) wait. v signalUpdate ] ] fork. -=-=-=-=-=-=-=-=-=-=-=-=
Cheers, Alexandre
On Sep 14, 2014, at 1:22 AM, kilon alios <kilon.alios@gmail.com> wrote:
so I tried to animate in Roassal having two different images display with a delay for few millisecond but it only displays the second image with this code
form1 :=Form fromFileNamed:'/Users/kilon/Pictures/pharo.png'. form2 :=Form fromFileNamed:'/Users/kilon/Pictures/box.png'. v := RTView new. c := v canvas. s := TRBitmapShape new. s form: form1. c addShape: s. v open.
(1 to: 100) do: [ :index| s form: form1. s signalUpdate . "(Delay forMilliseconds: 1000 ) wait." s form: form2. s signalUpdate . (Delay forMilliseconds: 1000) wait.].
I looked into RTAnimation but dont know how to use it for this example. Any help ? Does Roassal 2 support such animations ?
if I do s form: and then s signalUpdate for each form separately it works fine but inside the loops does not seem to work , I tried bigger delays with no effect.
On Sun, Sep 14, 2014 at 10:57 AM, stepharo <stepharo@free.fr> wrote: Ronie when you ready I can help writting a chapter for the nex book.
Stef
On 13/9/14 21:42, Ronie Salgado wrote:
Hello,
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
I have an adapted version of Swig for Pharo NativeBoost here: https://github.com/ronsaldo/swig
Currently I am using it to generate my Bullet bindings (available here: https://github.com/ronsaldo/bullet-pharo) that can be used as an example of using Swig. I still have to improve more my Swig generator, by writing documentation and fixing some bugs.
Greetings, Ronie
2014-09-13 16:11 GMT-03:00 stepharo <stepharo@free.fr>:
On 13/9/14 20:11, Enrico Schwass wrote:
Hi
another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work.
There is Wig like wrapper for Pharo done by ronie salgado.
Stef
Almost a decade ago I did some ruby bindings by hand. It was working
out of the box
Bye Enno
Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios@gmail.com>:
" I am curious. You mean rendering Bitmap from blender, for later use
in Pharo UI? "
yes exactly. Blender can render in all popular graphics files, most
used are png. Animation frames can be rendered each frame in its own file.
So basically its a lot like the average games out there.
"I will suggest bare bone Morphic mainly, then Athens when you need
vectorial drawing."
ok
"For iStoa I decided to go purely Morphic, I have a lot of bitmap.
Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result."
I fail to understand how your bitmap source is SVG for me bitmap is a
raster graphic format svg is procedural graphic format. Two opposite things.
"Sure. The downpoint, you will depend on one additional layer."
dependency is not an issue. Afterall the graphic files themselves
will be far bigger download even more so if the GUI becomes very large.
"Nice. What will be the expected outcomes of such API, I am not sure
to understand and I am curious."
Well Blender besides creating 3d objects (which can be used as 2d
objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically.
So basically you will be using Blender as a GUI designer.
"Use fuel to store the state of your application objects."
ah nice so fuel is a good candidate.
I will also take a look at Dr Geo and Phratch , both apps have custom
GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (18)
-
Alexandre Bergel -
Ben Coman -
Chris Muller -
Craig Latta -
Eliot Miranda -
Enrico Schwass -
Esteban A. Maringolo -
Hilaire -
kilon alios -
Martin McClure -
Nicolai Hess -
phil＠highoctane.be -
Ronie Salgado -
Sean P. DeNigris -
Sebastian Sastre -
stepharo -
Torsten Bergmann -
vfclists .