http:/piumarta.com/software/cola/canvas.pdf
BTW one of these days it would be good to - identify the core of morphic (should not that be difficult) - rethink these parts Because we need a small better done UI framework or simply implement lessphic in Squeak
I is hard to get excited about adopting something when the author includes a statement like
"Please, please replace the system described herein at your earliest convenience with something infinitely better (maybe using generalised relationships and constraints rather than hard-wired structure)"
But I am all for replacing the current pile of goo.
On Jan 29, 2008, at 11:25 AM, stephane ducasse wrote:
http:/piumarta.com/software/cola/canvas.pdf
BTW one of these days it would be good to
- identify the core of morphic (should not that be difficult)
- rethink these parts
Because we need a small better done UI framework or simply implement lessphic in Squeak
Hi Stef,
stephane ducasse wrote:
http:/piumarta.com/software/cola/canvas.pdf
BTW one of these days it would be good to - identify the core of morphic (should not that be difficult) - rethink these parts
This looks exactly what I'm doing with Morphic 3. Anybody willing to do as you say is welcome to check what I'm doing, and work together. I believe Morphic 3 can be the next UI framework for Squeak. Do you?
To read about Morphic 3, see http://www.jvuletich.org/Smalltalks2007/St2007VuletichMorphic3TalkProposal.p... and http://www.jvuletich.org/Morphic3/TheFutureOfTheGUI_01.html .
Because we need a small better done UI framework or simply implement lessphic in Squeak
Sure!
Cheers, Juan Vuletich
On Jan 30, 2008 3:01 PM, Juan Vuletich juan@jvuletich.org wrote:
Hi Stef,
stephane ducasse wrote:
http:/piumarta.com/software/cola/canvas.pdf
BTW one of these days it would be good to - identify the core of morphic (should not that be difficult) - rethink these parts
This looks exactly what I'm doing with Morphic 3. Anybody willing to do as you say is welcome to check what I'm doing, and work together. I believe Morphic 3 can be the next UI framework for Squeak. Do you?
To read about Morphic 3, see
http://www.jvuletich.org/Smalltalks2007/St2007VuletichMorphic3TalkProposal.p... and http://www.jvuletich.org/Morphic3/TheFutureOfTheGUI_01.html .
Some time in the next couple of years, I'll need a secure graphics API for my SecureSqueak project. The basic idea is that I need as thin a layer of abstraction as possible over various 2-D graphics targets: X11, MS Windows, Mac, Postscript/other printer APIs, OpenGL, VNC and possibly libraries such as Cairo. It would also need to do some event handling, as many events rely on a particular coordinate system. GUIs such as Morphic or Tweak would run on top of this.
Does your Morphic3 project have a base which could target all these? So far all I'm seeing is talk about bizarre coordinate systems.
Gulik.
Hi Gulik,
Morphic 3 supports arbitrary non-linear coordinate systems. I don't understand how you envision rendering over those targets. Morphic 3 has a rendering engine that renders on Squeak Display, as current Morphic's canvases with Balloon 2D and BitBlt.
Please read my documents, and let's talk about coordinate systems! Currently I have implemented Cartesian, LogX and a few cartographic. Watch the demo at Smalltalks 2007 at http://www.youtube.com/watch?v=90TGhRZUSOo . It is worth watching even if you don't understand my Spanish.
Cheers, Juan Vuletich
Michael van der Gulik wrote:
Some time in the next couple of years, I'll need a secure graphics API for my SecureSqueak project. The basic idea is that I need as thin a layer of abstraction as possible over various 2-D graphics targets: X11, MS Windows, Mac, Postscript/other printer APIs, OpenGL, VNC and possibly libraries such as Cairo. It would also need to do some event handling, as many events rely on a particular coordinate system. GUIs such as Morphic or Tweak would run on top of this.
Does your Morphic3 project have a base which could target all these? So far all I'm seeing is talk about bizarre coordinate systems.
Gulik.
-- http://people.squeakfoundation.org/person/mikevdg http://gulik.pbwiki.com/
No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.16/1250 - Release Date: 1/29/2008 10:20 PM
On Jan 31, 2008 12:04 AM, Juan Vuletich juan@jvuletich.org wrote:
Hi Gulik,
Morphic 3 supports arbitrary non-linear coordinate systems. I don't understand how you envision rendering over those targets. Morphic 3 has a rendering engine that renders on Squeak Display, as current Morphic's canvases with Balloon 2D and BitBlt.
Please read my documents, and let's talk about coordinate systems! Currently I have implemented Cartesian, LogX and a few cartographic. Watch the demo at Smalltalks 2007 at http://www.youtube.com/watch?v=90TGhRZUSOo . It is worth watching even if you don't understand my Spanish.
Could you give a few examples of where the arbitrary coordinate systems would actually be useful? This is the part I'm confused about - you're focussing on them a lot, but I don't see why.
I would have thought it would be up to the application to provide the logorithmic coordinate mappings rather than the GUI.
Gulik.
Hi Gulik,
Michael van der Gulik wrote:
On Jan 31, 2008 12:04 AM, Juan Vuletich <juan@jvuletich.org mailto:juan@jvuletich.org> wrote:
Hi Gulik, Morphic 3 supports arbitrary non-linear coordinate systems. I don't understand how you envision rendering over those targets. Morphic 3 has a rendering engine that renders on Squeak Display, as current Morphic's canvases with Balloon 2D and BitBlt. Please read my documents, and let's talk about coordinate systems! Currently I have implemented Cartesian, LogX and a few cartographic. Watch the demo at Smalltalks 2007 at http://www.youtube.com/watch?v=90TGhRZUSOo . It is worth watching even if you don't understand my Spanish.Could you give a few examples of where the arbitrary coordinate systems would actually be useful? This is the part I'm confused about
- you're focussing on them a lot, but I don't see why.
I would have thought it would be up to the application to provide the logorithmic coordinate mappings rather than the GUI.
That how it is usually done. So that code is repeated in various applications, the behavior is neither consistent nor correct (see my approach to pixel independent rendering), there is duplicated effort, many bugs appears, etc. Please do read http://www.jvuletich.org/Smalltalks2007/St2007VuletichMorphic3TalkProposal.p... . Also read http://www.jvuletich.org/Morphic3/TheFutureOfTheGUI_02.html and http://www.jvuletich.org/Morphic3/TheFutureOfTheGUI_032.html . I try to make my point there. I don't know what to say but repeat what I wrote there. If I'm not clear enough or you don't agree with me, tell me!
Cheers, Juan Vuletich
On Jan 31, 2008 2:27 PM, Juan Vuletich juan@jvuletich.org wrote:
Hi Gulik,
Michael van der Gulik wrote:
On Jan 31, 2008 12:04 AM, Juan Vuletich <juan@jvuletich.org mailto:juan@jvuletich.org> wrote:
Hi Gulik, Morphic 3 supports arbitrary non-linear coordinate systems. I don't understand how you envision rendering over those targets. Morphic 3 has a rendering engine that renders on Squeak Display, as current Morphic's canvases with Balloon 2D and BitBlt. Please read my documents, and let's talk about coordinate systems! Currently I have implemented Cartesian, LogX and a few cartographic. Watch the demo at Smalltalks 2007 at http://www.youtube.com/watch?v=90TGhRZUSOo . It is worth watchingeven
if you don't understand my Spanish.Could you give a few examples of where the arbitrary coordinate systems would actually be useful? This is the part I'm confused about
- you're focussing on them a lot, but I don't see why.
I would have thought it would be up to the application to provide the logorithmic coordinate mappings rather than the GUI.
That how it is usually done. So that code is repeated in various applications, the behavior is neither consistent nor correct (see my approach to pixel independent rendering), there is duplicated effort, many bugs appears, etc. Please do read
http://www.jvuletich.org/Smalltalks2007/St2007VuletichMorphic3TalkProposal.p... . Also read http://www.jvuletich.org/Morphic3/TheFutureOfTheGUI_02.html and http://www.jvuletich.org/Morphic3/TheFutureOfTheGUI_032.html . I try to make my point there. I don't know what to say but repeat what I wrote there. If I'm not clear enough or you don't agree with me, tell me!
Could you give some examples of where a non-linear coordinate system would be useful? I don't understand why you would want them in the GUI rather than the application.
What other features does Morphic 3 have? All I'm seeing is "non-linear coordinate systems".
Gulik.
> > > Could you give a few examples of where the arbitrary coordinate > systems would actually be useful? This is the part I'm confused about > - you're focussing on them a lot, but I don't see why. > > I would have thought it would be up to the application to provide the > logorithmic coordinate mappings rather than the GUI. > That how it is usually done. So that code is repeated in various applications, the behavior is neither consistent nor correct (see my approach to pixel independent rendering), there is duplicated effort, many bugs appears, etc. Please do read http://www.jvuletich.org/Smalltalks2007/St2007VuletichMorphic3TalkProposal.pdf . Also read http://www.jvuletich.org/Morphic3/TheFutureOfTheGUI_02.html and http://www.jvuletich.org/Morphic3/TheFutureOfTheGUI_032.html . I try to make my point there. I don't know what to say but repeat what I wrote there. If I'm not clear enough or you don't agree with me, tell me!Could you give some examples of where a non-linear coordinate system would be useful? I don't understand why you would want them in the GUI rather than the application.
Yes. Logarithmic scales in music and technical applications, pentagrams in music, geographic in maps, polar in math. Having that in the GUI offers the same advantages of having Morphic instead of implementing an ad hoc idea of graphic object in each application.
What other features does Morphic 3 have? All I'm seeing is "non-linear coordinate systems".
Morph specification that is agnostic about pixels and resolution. This is the key to building GUIs that look good on screen with different dpi's.
Theorically correct antia aliasing ("the signal processing approach to anti aliasing").
Better design that current Morphic, with simpler and smaller code.
Cheers, Juan Vuletich
On Jan 31, 2008 4:12 PM, Juan Vuletich juan@jvuletich.org wrote:
Better design that current Morphic, with simpler and smaller code.
What is the appropriate place discuss the class/api/etc. design? If others had an idea about that then they might be able to help building.
Hi Jason,
The place is here. If most people think we get way off topic, we could set up a mail list.
Cheers, Juan Vuletich
Jason Johnson wrote:
On Jan 31, 2008 4:12 PM, Juan Vuletich juan@jvuletich.org wrote:
Better design that current Morphic, with simpler and smaller code.
What is the appropriate place discuss the class/api/etc. design? If others had an idea about that then they might be able to help building.
thansk for the video I always wanted to see it running.
Stef
On Jan 30, 2008, at 12:04 PM, Juan Vuletich wrote:
Hi Gulik,
Morphic 3 supports arbitrary non-linear coordinate systems. I don't understand how you envision rendering over those targets. Morphic 3 has a rendering engine that renders on Squeak Display, as current Morphic's canvases with Balloon 2D and BitBlt.
Please read my documents, and let's talk about coordinate systems! Currently I have implemented Cartesian, LogX and a few cartographic. Watch the demo at Smalltalks 2007 at http://www.youtube.com/watch?v=90TGhRZUSOo . It is worth watching even if you don't understand my Spanish.
Cheers, Juan Vuletich
Michael van der Gulik wrote:
Some time in the next couple of years, I'll need a secure graphics API for my SecureSqueak project. The basic idea is that I need as thin a layer of abstraction as possible over various 2-D graphics targets: X11, MS Windows, Mac, Postscript/other printer APIs, OpenGL, VNC and possibly libraries such as Cairo. It would also need to do some event handling, as many events rely on a particular coordinate system. GUIs such as Morphic or Tweak would run on top of this.
Does your Morphic3 project have a base which could target all these? So far all I'm seeing is talk about bizarre coordinate systems.
Gulik.
-- http://people.squeakfoundation.org/person/mikevdg http://gulik.pbwiki.com/
No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.16/1250 - Release Date: 1/29/2008 10:20 PM
I liked the earth spinning :)
Please read my documents, and let's talk about coordinate systems! Currently I have implemented Cartesian, LogX and a few cartographic. Watch the demo at Smalltalks 2007 at http://www.youtube.com/watch?v=90TGhRZUSOo . It is worth watching even if you don't understand my Spanish.
So when will we get a version 1.0 of Morphic 3.0?
stephane ducasse wrote:
I liked the earth spinning :)
Thanks!
Please read my documents, and let's talk about coordinate systems! Currently I have implemented Cartesian, LogX and a few cartographic. Watch the demo at Smalltalks 2007 at http://www.youtube.com/watch?v=90TGhRZUSOo . It is worth watching even if you don't understand my Spanish.
So when will we get a version 1.0 of Morphic 3.0?
Hopefully during this year.
Cheers, Juan Vuletich
Hi Michael,
Some time in the next couple of years, I'll need a secure graphics API for my SecureSqueak project. The basic idea is that I need as thin a layer of abstraction as possible over various 2-D graphics targets: X11, MS Windows, Mac, Postscript/other printer APIs, OpenGL, VNC and possibly libraries such as Cairo. It would also need to do some event handling, as many events rely on a particular coordinate system. GUIs such as Morphic or Tweak would run on top of this.
You said "secure". Can you elaborate on this?
Cheers, Alexandre
On Jan 30, 2008 1:41 PM, Bergel, Alexandre bergel@iam.unibe.ch wrote:
You said "secure". Can you elaborate on this?
I'm also confused by this. For me a "secure" whatever means a whatever that can't be broken into.
Do mean an API written with your namespace solution or do you actually mean "stable"?
On Jan 31, 2008 1:41 AM, Bergel, Alexandre bergel@iam.unibe.ch wrote:
Hi Michael,
Some time in the next couple of years, I'll need a secure graphics API for my SecureSqueak project. The basic idea is that I need as thin a layer of abstraction as possible over various 2-D graphics targets: X11, MS Windows, Mac, Postscript/other printer APIs, OpenGL, VNC and possibly libraries such as Cairo. It would also need to do some event handling, as many events rely on a particular coordinate system. GUIs such as Morphic or Tweak would run on top of this.
You said "secure". Can you elaborate on this?
Untrusted code will be loaded, in bytecode form with dynamically rebound literals, from an untrusted remote server and executed locally. It would be able to render graphics, but not use the graphics / event-handling API to otherwise affect the running of any other remotely loaded untrusted code.
This includes the untrusted code being denied access to important objects and using excessive resources (cpu/memory/disk/network) such that the running of other code is affected.
For example, untrusted code will only be able to draw within the bounds of a Canvas passed to it. Draw commands outside this area will be clipped.
More here: http://gulik.pbwiki.com/SecureSqueak.
Gulik.
On Jan 31, 2008 9:27 AM, Michael van der Gulik mikevdg@gmail.com wrote:
On Jan 31, 2008 1:41 AM, Bergel, Alexandre bergel@iam.unibe.ch wrote:
Hi Michael,
Some time in the next couple of years, I'll need a secure graphics API for my SecureSqueak project. The basic idea is that I need as thin a layer of abstraction as possible over various 2-D graphics targets: X11, MS Windows, Mac, Postscript/other printer APIs, OpenGL, VNC and possibly libraries such as Cairo. It would also need to do some event handling, as many events rely on a particular coordinate system. GUIs such as Morphic or Tweak would run on top of this.
You said "secure". Can you elaborate on this?
Untrusted code will be loaded, in bytecode form with dynamically rebound literals, from an untrusted remote server and executed locally. It would be able to render graphics, but not use the graphics / event-handling API to otherwise affect the running of any other remotely loaded untrusted code.
This includes the untrusted code being denied access to important objects and using excessive resources (cpu/memory/disk/network) such that the running of other code is affected.
For example, untrusted code will only be able to draw within the bounds of a Canvas passed to it. Draw commands outside this area will be clipped.
More here: http://gulik.pbwiki.com/SecureSqueak.
Sorry... I answered the question but didn't explain why.
I was hoping that Juan
On Jan 31, 2008 9:27 AM, Michael van der Gulik mikevdg@gmail.com wrote:
On Jan 31, 2008 1:41 AM, Bergel, Alexandre bergel@iam.unibe.ch wrote:
Hi Michael,
Some time in the next couple of years, I'll need a secure graphics API for my SecureSqueak project. The basic idea is that I need as thin a layer of abstraction as possible over various 2-D graphics targets: X11, MS Windows, Mac, Postscript/other printer APIs, OpenGL, VNC and possibly libraries such as Cairo. It would also need to do some event handling, as many events rely on a particular coordinate system. GUIs such as Morphic or Tweak would run on top of this.
You said "secure". Can you elaborate on this?
Untrusted code will be loaded, in bytecode form with dynamically rebound literals, from an untrusted remote server and executed locally. It would be able to render graphics, but not use the graphics / event-handling API to otherwise affect the running of any other remotely loaded untrusted code.
This includes the untrusted code being denied access to important objects and using excessive resources (cpu/memory/disk/network) such that the running of other code is affected.
For example, untrusted code will only be able to draw within the bounds of a Canvas passed to it. Draw commands outside this area will be clipped.
More here: http://gulik.pbwiki.com/SecureSqueak.
Sorry... I answered the question but didn't explain why.
I was hoping that Juan would have made an architectural separation at some point between a hardware abstracting API, with his Morphic 3 running on top of it. Ideally, these would be two separate projects; the hardware API would use handle basic drawing and event management, and Morphic 3 would process those events and do the fancy transformations.
Gulik.
To do rendering that is really pixel independent and support the non linear geometric deformations implied by arbitrary coordinate systems you can not use standard drawing primitives. Morphic 3 really needs a new, custom rendering engine. Check the video of my demo. You'll understand you can not do that with, for example, OpenGL.
Cheers, Juan Vuletich
Michael van der Gulik wrote:
Sorry... I answered the question but didn't explain why.
I was hoping that Juan would have made an architectural separation at some point between a hardware abstracting API, with his Morphic 3 running on top of it. Ideally, these would be two separate projects; the hardware API would use handle basic drawing and event management, and Morphic 3 would process those events and do the fancy transformations.
Gulik.
-- http://people.squeakfoundation.org/person/mikevdg http://gulik.pbwiki.com/
No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.17/1252 - Release Date: 1/30/2008 8:51 PM
On Jan 31, 2008, at 2:27 , Juan Vuletich wrote:
To do rendering that is really pixel independent and support the non linear geometric deformations implied by arbitrary coordinate systems you can not use standard drawing primitives. Morphic 3 really needs a new, custom rendering engine. Check the video of my demo. You'll understand you can not do that with, for example, OpenGL.
The way I would do your demo in OpenGL would be that every morph renders to its own off-screen surface, and when compositing, it would apply the non-linear transformation. This is now a standard implementation technique, except it usually is not used for projective geometry but for fancy effects (like the Genie effect when minimizing Mac OS X windows).
Mind I did not understand what you said in the talk, just commenting on the visuals ...
- Bert -
I'd like to hear, how this highly abstract structures and coordinate systems can be designed in such manner, that it will be efficient for rendering with high speed using pixel blitting operations and/or hardware accelerated libraries (such as OpenGL).
Igor Stasenko wrote:
I'd like to hear, how this highly abstract structures and coordinate systems can be designed in such manner, that it will be efficient for rendering with high speed using pixel blitting operations and/or hardware accelerated libraries (such as OpenGL).
If all the coordinate systems are cartesian, then it is possible to use OpenGL or Cairo. However you'd lose "the signal processing approach to anti aliasing".
Cheers, Juan Vuletich
Bert Freudenberg wrote:
The way I would do your demo in OpenGL would be that every morph renders to its own off-screen surface, and when compositing, it would apply the non-linear transformation. This is now a standard implementation technique, except it usually is not used for projective geometry but for fancy effects (like the Genie effect when minimizing Mac OS X windows).
Mind I did not understand what you said in the talk, just commenting on the visuals ...
- Bert -
Yes. But you would be doing only a part of it in OpenGL. The geometric deformations would still be needed, but working only on bitmaps. The quality would not be as good (for things like CurveMorphs) because the off-screen surface would have some specific resolution, that could be too coarse for those areas that are enlarged by the non-linear transformation. Think for example on a graph with logarithmic X. Pixels in the off-screen surface would be too big at the left of the graph and too small at the right.
Cheers, Juan Vuletich
On Jan 31, 2008, at 16:12 , Juan Vuletich wrote:
Bert Freudenberg wrote:
The way I would do your demo in OpenGL would be that every morph renders to its own off-screen surface, and when compositing, it would apply the non-linear transformation. This is now a standard implementation technique, except it usually is not used for projective geometry but for fancy effects (like the Genie effect when minimizing Mac OS X windows).
Mind I did not understand what you said in the talk, just commenting on the visuals ...
- Bert -
Yes. But you would be doing only a part of it in OpenGL. The geometric deformations would still be needed, but working only on bitmaps. The quality would not be as good (for things like CurveMorphs) because the off-screen surface would have some specific resolution, that could be too coarse for those areas that are enlarged by the non-linear transformation. Think for example on a graph with logarithmic X. Pixels in the off-screen surface would be too big at the left of the graph and too small at the right.
I am beginning to understand your point :) Yes, having that power in the base system would be cool. I still think it can be implemented on latest-gen OpenGL hardware (which can do the non-linear transform and adaptively tesselate curves to pixel resolution) but that then would be just an optimization.
- Bert -
On 31/01/2008, Bert Freudenberg bert@freudenbergs.de wrote:
I am beginning to understand your point :) Yes, having that power in the base system would be cool. I still think it can be implemented on latest-gen OpenGL hardware (which can do the non-linear transform and adaptively tesselate curves to pixel resolution) but that then would be just an optimization.
What i'm against, is to bind rendering subsystem to specific hardware. There should be a layer, which should offer a rendering services to application, and number of layers to deliver graphics to device(s). In perfect, it should be able to render itself using any device: screen or printer or remote (networked) canvas. There also can be a different options in what a rendering media is: it's wrong to assume that rendering surface is planar (it can be a 3D holo-projector, for instance). What is hard, is to design such system to be fast and optimal and still be generic enough to be able to render anywhere.
Igor Stasenko wrote:
On 31/01/2008, Bert Freudenberg bert@freudenbergs.de wrote:
I am beginning to understand your point :) Yes, having that power in the base system would be cool. I still think it can be implemented on latest-gen OpenGL hardware (which can do the non-linear transform and adaptively tesselate curves to pixel resolution) but that then would be just an optimization.
What i'm against, is to bind rendering subsystem to specific hardware. There should be a layer, which should offer a rendering services to application, and number of layers to deliver graphics to device(s). In perfect, it should be able to render itself using any device: screen or printer or remote (networked) canvas. There also can be a different options in what a rendering media is: it's wrong to assume that rendering surface is planar (it can be a 3D holo-projector, for instance). What is hard, is to design such system to be fast and optimal and still be generic enough to be able to render anywhere.
Morphic 3 is not tied to any hardware! It only assumes the Display in Squeak. And it will not be too hard to separate it from the rendering engine. Non planar targets could be addressed by a custom coordinate system.
Cheers, Juan Vuletich
On 31/01/2008, Juan Vuletich juan@jvuletich.org wrote:
What i'm against, is to bind rendering subsystem to specific hardware. There should be a layer, which should offer a rendering services to application, and number of layers to deliver graphics to device(s). In perfect, it should be able to render itself using any device: screen or printer or remote (networked) canvas. There also can be a different options in what a rendering media is: it's wrong to assume that rendering surface is planar (it can be a 3D holo-projector, for instance). What is hard, is to design such system to be fast and optimal and still be generic enough to be able to render anywhere.
Morphic 3 is not tied to any hardware! It only assumes the Display in Squeak. And it will not be too hard to separate it from the rendering engine. Non planar targets could be addressed by a custom coordinate system.
I didn't examined your Morphic 3 design precisely, but using a Display (as it currently represented in Squeak) is exactly what i'm against. It's like interacting with hardware directly, bypassing software drivers. Display should represent a device with own set of capabilities. Canvas providing a generic abstract layer for interacting it. Morphs should use canvas , but assume nothing about existence of Display or Printer or Whatever. Otherwise, once you start using Display, soon it will become too tied together, and you start mixing things in one cup, just because you assuming that everything what you doing will be rendered using Display, so you starting care less about other devices/surfaces, limiting it and finally bury it down under heap of optimizations :)
Cheers, Juan Vuletich
And some notes about input. Again, morphic should not assume that there are standard input devices , like keyboard and mouse, it's should be able to interact with any available input devices. For this, i think, we should think twice on how introduce different events in future morphic system.
For instance, what is the point in having #handlesMouseDown: , #keyDown: methods, when there is no mouse/keyboard on platform (assume i run squeak on touchpad)?
These layers should be detached from each other, i think, and morphs should react on more abstract (or generalised) events.
Igor Stasenko wrote:
And some notes about input. Again, morphic should not assume that there are standard input devices , like keyboard and mouse, it's should be able to interact with any available input devices. For this, i think, we should think twice on how introduce different events in future morphic system.
For instance, what is the point in having #handlesMouseDown: , #keyDown: methods, when there is no mouse/keyboard on platform (assume i run squeak on touchpad)?
These layers should be detached from each other, i think, and morphs should react on more abstract (or generalised) events.
I still haven't thought much about this, but I fully agree. If you have further ideas on this, I'd like to know.
Cheers, Juan Vuletich
Igor Stasenko wrote:
I didn't examined your Morphic 3 design precisely, but using a Display (as it currently represented in Squeak) is exactly what i'm against.
Ok.
It's like interacting with hardware directly, bypassing software drivers.
Not at all. I did interact with hardware directly. The result is non-portable. Assuming the Display might have some limitations, but portability is not an issue.
Display should represent a device with own set of capabilities. Canvas providing a generic abstract layer for interacting it. Morphs should use canvas , but assume nothing about existence of Display or Printer or Whatever.
Sure. Morphic 3 assumes Display. But not the morphs. Only the Canvas and rendering engine. Morphs only know about Canvas services. Writing the kinds of canvases you mention is perfectly possible.
Otherwise, once you start using Display, soon it will become too tied together, and you start mixing things in one cup, just because you assuming that everything what you doing will be rendered using Display, so you starting care less about other devices/surfaces, limiting it and finally bury it down under heap of optimizations :)
Sure.
Cheers, Juan Vuletich
Bert Freudenberg wrote:
I am beginning to understand your point :) Yes, having that power in the base system would be cool. I still think it can be implemented on latest-gen OpenGL hardware (which can do the non-linear transform and adaptively tesselate curves to pixel resolution) but that then would be just an optimization.
- Bert -
Yes!
Cheers, Juan Vuletich
Bert Freudenberg wrote:
I am beginning to understand your point :) Yes, having that power in the base system would be cool. I still think it can be implemented on latest-gen OpenGL hardware (which can do the non-linear transform and adaptively tesselate curves to pixel resolution) but that then would be just an optimization.
- Bert -
Do you have any links on this OpenGL stuff?
Cheers, Juan Vuletich
Juan Vuletich wrote:
Bert Freudenberg wrote:
I am beginning to understand your point :) Yes, having that power in the base system would be cool. I still think it can be implemented on latest-gen OpenGL hardware (which can do the non-linear transform and adaptively tesselate curves to pixel resolution) but that then would be just an optimization.
- Bert -
Do you have any links on this OpenGL stuff?
http://en.wikipedia.org/wiki/Geometry_shader
Cheers, - Andreas
Am Feb 1, 2008 um 3:27 schrieb Juan Vuletich juan@jvuletich.org:
Bert Freudenberg wrote:
I am beginning to understand your point :) Yes, having that power in the base system would be cool. I still think it can be implemented on latest-gen OpenGL hardware (which can do the non- linear transform and adaptively tesselate curves to pixel resolution) but that then would be just an optimization.
- Bert -
Do you have any links on this OpenGL stuff?
google for "geometry shader"
- Bert -
You could also do "this sort of thing" using pixel shaders. GPU Gems 3 has an article by Charles Loop and Jim Blinn entitled "Rendering Vector Art on the GPU". They directly render cubic and quadratic Bezier segments (ie: without tesselation). Although I haven't given much thought to extending the technique to support non-linear coordinate systems, but my first guess is that this is plausible.
Of course, the proportion of world-wide computer users who have this kind of hardware is quite small. Hopefully this will change as 3D becomes more generally useful (not just for gamers).
Josh
On Feb 1, 2008, at 2:17 AM, Bert Freudenberg wrote:
Am Feb 1, 2008 um 3:27 schrieb Juan Vuletich juan@jvuletich.org:
Bert Freudenberg wrote:
I am beginning to understand your point :) Yes, having that power in the base system would be cool. I still think it can be implemented on latest-gen OpenGL hardware (which can do the non- linear transform and adaptively tesselate curves to pixel resolution) but that then would be just an optimization.
- Bert -
Do you have any links on this OpenGL stuff?
google for "geometry shader"
- Bert -
Hi juan
I know your project now I told you that several times so I repeat it again: If we cannot load Morphic 3 beside Morphic 2 then really few people will be able to load it. The transition phase will be difficult. So think again about it. If you force people to chose then you will not gain from them. Now if I can load Morphic 3 beside Morphic2 then I'm sure people may help to port elements from one to the other. Look at the stream of Craig.
Stef
On Jan 30, 2008, at 3:01 AM, Juan Vuletich wrote:
Hi Stef,
stephane ducasse wrote:
http:/piumarta.com/software/cola/canvas.pdf
BTW one of these days it would be good to
- identify the core of morphic (should not that be difficult)
- rethink these parts
This looks exactly what I'm doing with Morphic 3. Anybody willing to do as you say is welcome to check what I'm doing, and work together. I believe Morphic 3 can be the next UI framework for Squeak. Do you?
To read about Morphic 3, see http://www.jvuletich.org/Smalltalks2007/St2007VuletichMorphic3TalkProposal.p... and http://www.jvuletich.org/Morphic3/TheFutureOfTheGUI_01.html .
Because we need a small better done UI framework or simply implement lessphic in Squeak
Sure!
Cheers, Juan Vuletich
Hi Stef,
It is all about objectives, priorities and resources. I'm not against running M3 beside M2. And I'm not forcing people to chose. If you have options (Morphic 2 / lessphic / Tweak / Morphic 3 / whatever) then you need to chose. Don't blame me of that.
It is just that I don't want to spend my very little time on that. I prefer to think and develop the design. However anyone can help. Let's get to your objectives:
If your objective is to "- identify the core of morphic and - rethink these parts" then whether you can load M3 beside M2 or not is pretty irrelevant. You can just use my image. That's what I expect from people wanting to discuss the ideas and help developing it. I mean, if you want to rethink the core of Morphic, just start criticizing my documents and what I've done so far.
If your objective is "Need to load it beside M2" then you can help. You can: - work on it - get a student or someone to work on it - get Esug to sponsor me. If I could work full time on M3, things would go much faster.
Cheers, Juan Vuletich
Ps. What do you mean by "the stream of Craig"?
stephane ducasse wrote:
Hi juan
I know your project now I told you that several times so I repeat it again: If we cannot load Morphic 3 beside Morphic 2 then really few people will be able to load it. The transition phase will be difficult. So think again about it. If you force people to chose then you will not gain from them. Now if I can load Morphic 3 beside Morphic2 then I'm sure people may help to port elements from one to the other. Look at the stream of Craig.
Stef
On Jan 30, 2008, at 12:31 PM, Juan Vuletich wrote:
- get Esug to sponsor me. If I could work full time on M3, things
would go much faster.
How much?
Cheers, Juan Vuletich
Ps. What do you mean by "the stream of Craig"?
A while ago craig reimplemented a subpart of stream but to use them you have to destroy the default library. Net result we lost his work. Now with Nile this is different you can load Nile and use it if you want and migrate from stream to Nile when you want. For Morphic 3 I imagine well that event processing can be difficult to get m2 and m3 working but this was not what I asked. Just the fact that people want to be able to load your code in their image.
Stef
A while ago craig reimplemented a subpart of stream but to use them you have to destroy the default library.
That's not true. I wrote a complete hierarchy. There were a few class name conflicts; one can simply rename one group or the other. In the meantime I have been working on a way to make class name conflicts irrelevant.
Net result we lost his work.
Not all of us did. :)
thanks,
-C
-- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]
I will answer in private email.
Cheers, Juan Vuletich
stephane ducasse wrote:
On Jan 30, 2008, at 12:31 PM, Juan Vuletich wrote:
- get Esug to sponsor me. If I could work full time on M3, things
would go much faster.
How much?
Cheers, Juan Vuletich
Ps. What do you mean by "the stream of Craig"?
A while ago craig reimplemented a subpart of stream but to use them you have to destroy the default library. Net result we lost his work. Now with Nile this is different you can load Nile and use it if you want and migrate from stream to Nile when you want. For Morphic 3 I imagine well that event processing can be difficult to get m2 and m3 working but this was not what I asked. Just the fact that people want to be able to load your code in their image.
Stef
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bergel, Alexandre -
Bert Freudenberg -
Craig Latta -
Igor Stasenko -
Jason Johnson -
Joshua Gargus -
Juan Vuletich -
Michael van der Gulik -
stephane ducasse -
Todd Blanchard