[Pharo-project] Helping with Athens development
So after diving in common lisp and take a look at various alternative I decided that Pharo is the best place for me to start for my Ephestos project. The first thing that got my attention is Athens , it seems to be very close to my own goal for Ephestos. So my question is how may I help Athens involve by contributing code to it ? Are there specific features I can work on ? The first part of my Ephestos project I call it Morpheas and its basically a GUI API based on morphic specialised on customised guis, meaning guis that do not look native . Athens seems a good library to base Morpheas on, so I am actually interested in expanding it. In the future I would also like to port Athens to opengl , but if cairo is fast enough for me, I may avoid it and instead focus more on porting Morphic to Athens. So my post here is to clarify the way I can contribute to Athens . I want my project Ephestos to be a contribution to the existing Pharo image and offer more GUI widgets, maybe a gui designer and some more graphic and audio tools. I think that Athens can be the base for my project so naturally I want to contribute.
On 23 November 2012 12:11, dimitris chloupis <thekilon@yahoo.co.uk> wrote:
So after diving in common lisp and take a look at various alternative I decided that Pharo is the best place for me to start for my Ephestos project. The first thing that got my attention is Athens , it seems to be very close to my own goal for Ephestos. So my question is how may I help Athens involve by contributing code to it ?
Are there specific features I can work on ? The first part of my Ephestos project I call it Morpheas and its basically a GUI API based on morphic specialised on customised guis, meaning guis that do not look native . Athens seems a good library to base Morpheas on, so I am actually interested in expanding it.
In the future I would also like to port Athens to opengl , but if cairo is fast enough for me, I may avoid it and instead focus more on porting Morphic to Athens.
So my post here is to clarify the way I can contribute to Athens . I want my project Ephestos to be a contribution to the existing Pharo image and offer more GUI widgets, maybe a gui designer and some more graphic and audio tools. I think that Athens can be the base for my project so naturally I want to contribute.
Hi, Dimitris. yes, you're welcome to contribute. There's a lot of areas: Documentation The most important thing today is documentation and examples. This will open doors to users and future contributors. Without it, things will stay a bit arcane, and behind closed doors. Development: - delivery of rendered stuff to screen estate. Right now, we do it via morphic: so first you render on surface, then you blit results on Display form, and then VM blits bits again on screen. To improve frame rate, we should certainty think how to avoid copying things twice and deliver results directly on screen avoiding transferring/copying big chunks of data. - SVG importer: it works for simple SVG documents, but it is not finished and more work is needed. Some svgs are not imported correctly, we need to improve that. Of course full SVG coverage is not a goal (no animaiton nor fancy filter stuff).. But we should have a robust solution for importing vector graphics made by artists. - integration with morphic: the goal is to be able to render everything using Athens canvas. The work is already started, but there's many morphs which has own custom draw methods, and waiting to be ported for athens. Apart from it is text layout/rendering.. it is the main hurdle for us, but we're working on it, by implementing new text model, and rendering/layout engine for it. - implementing more backends. Currently there's only Cairo backend which is more or less functional. We need more. I am looking forward to implement quartz backend on mac os. Also, opengl backend would be good to have. Another thing: Amber. If someone interested, i think it will be good to port it on Amber and make Athens working in web browsers using HTML5 canvas. If you need details about any of the above, feel free to ask. -- Best regards, Igor Stasenko.
Thank you Igor , this was the type of answer I wanted . Ok I think I will work first on documenting the code and creating a pdf that helps the user understand how to use Athens. After I gain a very good insight through documentation of how Athens works I start contributing code. I assume for documenting code (adding doc strings to methods missing them) files out and attaching them here will do or you want me to upload to my own project in ss3 ? ________________________________ From: Igor Stasenko <siguctua@gmail.com> To: Pharo-project@lists.gforge.inria.fr; dimitris chloupis <thekilon@yahoo.co.uk> Sent: Friday, 23 November 2012, 14:07 Subject: Re: [Pharo-project] Helping with Athens development On 23 November 2012 12:11, dimitris chloupis <thekilon@yahoo.co.uk> wrote:
So after diving in common lisp and take a look at various alternative I decided that Pharo is the best place for me to start for my Ephestos project. The first thing that got my attention is Athens , it seems to be very close to my own goal for Ephestos. So my question is how may I help Athens involve by contributing code to it ?
Are there specific features I can work on ? The first part of my Ephestos project I call it Morpheas and its basically a GUI API based on morphic specialised on customised guis, meaning guis that do not look native . Athens seems a good library to base Morpheas on, so I am actually interested in expanding it.
In the future I would also like to port Athens to opengl , but if cairo is fast enough for me, I may avoid it and instead focus more on porting Morphic to Athens.
So my post here is to clarify the way I can contribute to Athens . I want my project Ephestos to be a contribution to the existing Pharo image and offer more GUI widgets, maybe a gui designer and some more graphic and audio tools. I think that Athens can be the base for my project so naturally I want to contribute.
Hi, Dimitris. yes, you're welcome to contribute. There's a lot of areas: Documentation The most important thing today is documentation and examples. This will open doors to users and future contributors. Without it, things will stay a bit arcane, and behind closed doors. Development: - delivery of rendered stuff to screen estate. Right now, we do it via morphic: so first you render on surface, then you blit results on Display form, and then VM blits bits again on screen. To improve frame rate, we should certainty think how to avoid copying things twice and deliver results directly on screen avoiding transferring/copying big chunks of data. - SVG importer: it works for simple SVG documents, but it is not finished and more work is needed. Some svgs are not imported correctly, we need to improve that. Of course full SVG coverage is not a goal (no animaiton nor fancy filter stuff).. But we should have a robust solution for importing vector graphics made by artists. - integration with morphic: the goal is to be able to render everything using Athens canvas. The work is already started, but there's many morphs which has own custom draw methods, and waiting to be ported for athens. Apart from it is text layout/rendering.. it is the main hurdle for us, but we're working on it, by implementing new text model, and rendering/layout engine for it. - implementing more backends. Currently there's only Cairo backend which is more or less functional. We need more. I am looking forward to implement quartz backend on mac os. Also, opengl backend would be good to have. Another thing: Amber. If someone interested, i think it will be good to port it on Amber and make Athens working in web browsers using HTML5 canvas. If you need details about any of the above, feel free to ask. -- Best regards, Igor Stasenko.
On 2012-11-23, at 09:57, dimitris chloupis <thekilon@yahoo.co.uk> wrote:
Thank you Igor , this was the type of answer I wanted . Ok I think I will work first on documenting the code and creating a pdf that helps the user understand how to use Athens.
if you could, it would be nice to have the text also for Pharo's internal help system. In my opinion that is more smalltalk-like, since we ship everything together :)
After I gain a very good insight through documentation of how Athens works I start contributing code. I assume for documenting code (adding doc strings to methods missing them) files out and attaching them here will do or you want me to upload to my own project in ss3 ?
I guess the highest priority here is class comments, that is kind of a must (though I catch myself too often not adding one). nice to see additional support for athens!
internal help , no problemo I can do that too. Its an opportunity to see how pharo internal help system works , last time I checked it seemed simple enough. Class docstrings first seems like a good priority. I love your work with pharo and I was itching to contribute back to the community. I love smalltalk mainly because of the great environment and I think that there is still a lot more to be done to improve it and make it even more user friendly , I only hope I play my own small part in this. ________________________________ From: Camillo Bruni <camillobruni@gmail.com> To: "Pharo-project@lists.gforge.inria.fr Development" <Pharo-project@lists.gforge.inria.fr> Sent: Friday, 23 November 2012, 15:02 Subject: Re: [Pharo-project] Helping with Athens development On 2012-11-23, at 09:57, dimitris chloupis <thekilon@yahoo.co.uk> wrote:
Thank you Igor , this was the type of answer I wanted . Ok I think I will work first on documenting the code and creating a pdf that helps the user understand how to use Athens.
if you could, it would be nice to have the text also for Pharo's internal help system. In my opinion that is more smalltalk-like, since we ship everything together :)
After I gain a very good insight through documentation of how Athens works I start contributing code. I assume for documenting code (adding doc strings to methods missing them) files out and attaching them here will do or you want me to upload to my own project in ss3 ?
I guess the highest priority here is class comments, that is kind of a must (though I catch myself too often not adding one). nice to see additional support for athens!
On 2012-11-23, at 10:17, dimitris chloupis <thekilon@yahoo.co.uk> wrote:
internal help , no problemo I can do that too. Its an opportunity to see how pharo internal help system works , last time I checked it seemed simple enough.
Class docstrings first seems like a good priority.
I love your work with pharo and I was itching to contribute back to the community. I love smalltalk mainly because of the great environment and I think that there is still a lot more to be done to improve it and make it even more user friendly , I only hope I play my own small part in this.
oh, definitely our whishlist of things we want to improve is quite large, and most of it is not even in the issue tracker :P so whenever you feel bored working on athens => http://code.google.com/p/cog/issues ;)
CogVM ? sounds very hard for me to do. I am not that good as a coder and VM development looks very difficult to me. I am sticking with Athens for the time being. I love graphics , sound and music. Getting bored is not an option :D ________________________________ From: Camillo Bruni <camillobruni@gmail.com> To: "Pharo-project@lists.gforge.inria.fr Development" <Pharo-project@lists.gforge.inria.fr> Sent: Friday, 23 November 2012, 15:31 Subject: Re: [Pharo-project] Helping with Athens development On 2012-11-23, at 10:17, dimitris chloupis <thekilon@yahoo.co.uk> wrote:
internal help , no problemo I can do that too. Its an opportunity to see how pharo internal help system works , last time I checked it seemed simple enough.
Class docstrings first seems like a good priority.
I love your work with pharo and I was itching to contribute back to the community. I love smalltalk mainly because of the great environment and I think that there is still a lot more to be done to improve it and make it even more user friendly , I only hope I play my own small part in this.Â
oh, definitely our whishlist of things we want to improve is quite large, and most of it is not even in the issue tracker :P so whenever you feel bored working on athens => http://code.google.com/p/cog/issues ;)
On 2012-11-23, at 10:46, dimitris chloupis <thekilon@yahoo.co.uk> wrote:
CogVM ? sounds very hard for me to do. I am not that good as a coder and VM development looks very difficult to me.
I am sticking with Athens for the time being. I love graphics , sound and music. Getting bored is not an option :D
sorry I randomly copied strings :D => http://code.google.com/p/pharo/issues ;)
in the long way, an OpenGL backend seems more important to me than a Quartz backend (of course both are good, but OpenGL is portable and "de facto standard", Quartz is not...) On Nov 23, 2012, at 1:07 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 23 November 2012 12:11, dimitris chloupis <thekilon@yahoo.co.uk> wrote:
So after diving in common lisp and take a look at various alternative I decided that Pharo is the best place for me to start for my Ephestos project. The first thing that got my attention is Athens , it seems to be very close to my own goal for Ephestos. So my question is how may I help Athens involve by contributing code to it ?
Are there specific features I can work on ? The first part of my Ephestos project I call it Morpheas and its basically a GUI API based on morphic specialised on customised guis, meaning guis that do not look native . Athens seems a good library to base Morpheas on, so I am actually interested in expanding it.
In the future I would also like to port Athens to opengl , but if cairo is fast enough for me, I may avoid it and instead focus more on porting Morphic to Athens.
So my post here is to clarify the way I can contribute to Athens . I want my project Ephestos to be a contribution to the existing Pharo image and offer more GUI widgets, maybe a gui designer and some more graphic and audio tools. I think that Athens can be the base for my project so naturally I want to contribute.
Hi, Dimitris. yes, you're welcome to contribute.
There's a lot of areas:
Documentation
The most important thing today is documentation and examples. This will open doors to users and future contributors. Without it, things will stay a bit arcane, and behind closed doors.
Development:
- delivery of rendered stuff to screen estate. Right now, we do it via morphic: so first you render on surface, then you blit results on Display form, and then VM blits bits again on screen. To improve frame rate, we should certainty think how to avoid copying things twice and deliver results directly on screen avoiding transferring/copying big chunks of data.
- SVG importer: it works for simple SVG documents, but it is not finished and more work is needed. Some svgs are not imported correctly, we need to improve that. Of course full SVG coverage is not a goal (no animaiton nor fancy filter stuff).. But we should have a robust solution for importing vector graphics made by artists.
- integration with morphic: the goal is to be able to render everything using Athens canvas. The work is already started, but there's many morphs which has own custom draw methods, and waiting to be ported for athens. Apart from it is text layout/rendering.. it is the main hurdle for us, but we're working on it, by implementing new text model, and rendering/layout engine for it.
- implementing more backends. Currently there's only Cairo backend which is more or less functional. We need more. I am looking forward to implement quartz backend on mac os. Also, opengl backend would be good to have.
Another thing: Amber. If someone interested, i think it will be good to port it on Amber and make Athens working in web browsers using HTML5 canvas.
If you need details about any of the above, feel free to ask.
-- Best regards, Igor Stasenko.
On 23 November 2012 14:22, Esteban Lorenzano <estebanlm@gmail.com> wrote:
in the long way, an OpenGL backend seems more important to me than a Quartz backend (of course both are good, but OpenGL is portable and "de facto standard", Quartz is not...)
OpenGL does not have high level abstractions for paths/paints. But NVidia extension released lately, called nv_path is the way to go, i think. Using OpenGL without this extension will require sufficient effort to implement everything. Because you will need to do a lot of processing to convert paths to something which opengl understands - triangles. It is doable, of course, but not as fast and as easy as doing backend for cairo or openvg or quartz. But i agree, that if we would have opengl backend , we would not need to care much about others. Because it is best thing what you can have: GPU acceleration :) -- Best regards, Igor Stasenko.
yeah, you are the boss :) I was just saying :) On Nov 23, 2012, at 3:01 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 23 November 2012 14:22, Esteban Lorenzano <estebanlm@gmail.com> wrote:
in the long way, an OpenGL backend seems more important to me than a Quartz backend (of course both are good, but OpenGL is portable and "de facto standard", Quartz is not...)
OpenGL does not have high level abstractions for paths/paints. But NVidia extension released lately, called nv_path is the way to go, i think.
Using OpenGL without this extension will require sufficient effort to implement everything. Because you will need to do a lot of processing to convert paths to something which opengl understands - triangles. It is doable, of course, but not as fast and as easy as doing backend for cairo or openvg or quartz.
But i agree, that if we would have opengl backend , we would not need to care much about others. Because it is best thing what you can have: GPU acceleration :)
-- Best regards, Igor Stasenko.
participants (4)
-
Camillo Bruni -
dimitris chloupis -
Esteban Lorenzano -
Igor Stasenko