Morphic 3.0: The future of the Gui

> Hi Folks,
>
> I started to write a "paper to be" about my Morphic 3.0 project. The
> objective is to convince you that Morphic 3.0 is the coolest thing
> around :). The first draft is available at www.jvuletich.org. I hope you
> enjoy it. Any comment is welcome.
>
> Cheers,
> Juan Vuletich
> www.jvuletich.org
>
>

> Hi Juan,
>
>
>
> 1.3 Direct Manipulation
>
>
> Have you seen this video about image resizing
> http://www.youtube.com/watch?v=qadw0BRKeMk
>
>
> 1.4 Framework Structure
> What's the thinking behind this?
>
>
>
> "Class Morph should not include general concepts of color, border, etc. Each morph class decides what are the relevant properties for its instances. "
>
>
>
>
> Another thought: I always wanted to be able to have _any_ object that communicates to the user to be a morph. This would be any graphic object, but also any video object, audio object, anything that deals with the senses of the user. What do you think about this idea?
>

>
> ----- Original Message ----
>
> From: Juan Vuletich <[hidden email]>
>
> To: The general-purpose Squeak developers list <[hidden email]>
>
> Sent: Wednesday, August 29, 2007 8:14:03 PM
>
> Subject: Morphic 3.0: The future of the Gui
>
>
>
> Hi Folks,
>
>
>
> I started to write a "paper to be" about my Morphic 3.0 project. The
>
> objective is to convince you that Morphic 3.0 is the coolest thing
>
> around :). The first draft is available at www.jvuletich.org. I hope you
>
> enjoy it. Any comment is welcome.
>
>
>
> Cheers,
>
> Juan Vuletich
>
> www.jvuletich.org
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

> Forgot to add..
>
> Morphs must not rely on any current display medium state such as
> background color or results of previous drawings, because some media
> types cannot hold or provide its current state in form, which can be
> easily accessible or manipulated.
> Any internal/current state of display medium can be accessible and
> manageable only by its canvas object.
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

>>> Another thought: I always wanted to be able to have _any_ object  
>>> that communicates to the
>>> user to be a morph. This would be any graphic object, but also  
>>> any video object, audio object,
>>> anything that deals with the senses of the user. What do you  
>>> think about this idea?
>>
>
>> This is already so. see #asMorph message :)
>> You can build up any morph(s) for representing your object.
>
> I'm not referring to building a graphic object to represent a sound  
> (for instance), I want to manipulate a sound or video just like I  
> can a morph graphic object.

> Thanks,
> Josh
>
>
> On Aug 29, 2007, at 10:17 PM, Igor Stasenko wrote:
>
> > Forgot to add..
> >
> > Morphs must not rely on any current display medium state such as
> > background color or results of previous drawings, because some media
> > types cannot hold or provide its current state in form, which can be
> > easily accessible or manipulated.
> > Any internal/current state of display medium can be accessible and
> > manageable only by its canvas object.
> >
> > --
> > Best regards,
> > Igor Stasenko AKA sig.
> >
>
>
>

> Hi Folks,
>
> I started to write a "paper to be" about my Morphic 3.0 project. The
> objective is to convince you that Morphic 3.0 is the coolest thing
> around :). The first draft is available at www.jvuletich.org. I hope you
> enjoy it. Any comment is welcome.
>
> Cheers,
> Juan Vuletich
> www.jvuletich.org
>
>

> On Thu, Aug 30, 2007 at 12:14:03AM -0300, Juan Vuletich wrote:
> > Hi Folks,
> >
> > I started to write a "paper to be" about my Morphic 3.0 project. The
> > objective is to convince you that Morphic 3.0 is the coolest thing
> > around :). The first draft is available at www.jvuletich.org. I hope you
> > enjoy it. Any comment is welcome.
>
> Nice. I just had one question: would gamma correction be taken
> into account at all?
>
> Especially when rendering text, light-on-dark always looks
> bigger than dark-on-light for exactly the same shape. Is it
> possible to (in general) render a shape with constant "mass" in
> the face of gamma inconsistencies? For text, this would involve
> procedural bolding/thinning.
>

> 1.2. Rendering.
>
> I want high quality rendering on any Display, regardless of size or
> pixel resolution. Therefore, I need complete independence of those
> Display properties. The programmer must never deal with the concept of
> pixel. The GUI is thought at a higher level. All the GUI is
> independent of pixel resolution. All the rendering is anti aliased.
> But in order to be able to render equally well on very high resolution
> as on medium resolution devices, the objects to be rendered (i.e.
> morphs) must be specified in a way that doesn't depend on the
> resolution of the target device at all. The ultimate way to do this is
> by thinking of them as continuous functions. This applies to geometric
> shapes, but also to digital images (photos) and textures.
>
> ----
>
> Very, very promising description.
> But maybe you should add this:
>
> Morph rendering must not be dependent from any concrete display-medium
> properties including: shape, dimensions, internal organization and
> capabilities. A display medium for morph can be a display screen or
> printer or anything else, which provides canvas object. All morphs
> visualization must be presented as a stream of commands to canvas
> object. Different types of canvases will provide an interface for
> rendering morphs on particular display medium.
>
> Also, zooming sometimes is not quite same as resizing. When resizing
> text window i making larger area for text, so i can see more lines of
> text instead of seeing same number of text lines but with higher
> resolution.
> So, i think that some morphs mush have both dimensions (in its own
> coordinate system) and  transformation (relatively to parent morph
> coordinate system). And them resizing is changing dimensions, and
> zooming is changing transformation.
>
>
> On 30/08/2007, Juan Vuletich <[hidden email]> wrote:
>  
>> Hi Folks,
>>
>> I started to write a "paper to be" about my Morphic 3.0 project. The
>> objective is to convince you that Morphic 3.0 is the coolest thing
>> around :). The first draft is available at www.jvuletich.org. I hope you
>> enjoy it. Any comment is welcome.
>>
>> Cheers,
>> Juan Vuletich
>> www.jvuletich.org
>>
>>
>>    
>
>
>  

> Hi Juan,
>
>
>
> 1.3 Direct Manipulation
>
>
> Have you seen this video about image resizing
> http://www.youtube.com/watch?v=qadw0BRKeMk
>
>
> 1.4 Framework Structure
> What's the thinking behind this?
>
>
>
> "Class Morph should not include general concepts of color, border, etc. Each morph class decides what are the relevant properties for its instances. "
>  

> On 30/08/2007, Joshua Gargus <[hidden email]> wrote:
>  
>> Squeak currently includes a fisheye morph that provides a distorted
>> view of what is underneath it.  What you have written sounds like it
>> would not support such morphs.  If I'm misunderstanding you, could
>> you try to restate your thought to give me another chance to understand?
>>
>>    
> Well, i think you understood correctly. Morph can't rely on results of
> previous drawings.
> There are some morphs, like magnifying lens which use current state of
> screen to draw effects.
> But suppose that you rendering a lens morph in PostScript file, or on
> canvas which translates drawings to the network, or you using a HUGE
> drawing surface which simply cannot fit in operative memory. This is a
> simple reasons why morph should not access any current state.
> To get around the problem you can, instead redraw a portion of world
> using your own (applied before redrawing) transformations/effects.
>
>  
>> Thanks,
>> Josh
>>
>>
>> On Aug 29, 2007, at 10:17 PM, Igor Stasenko wrote:
>>
>>    
>>> Forgot to add..
>>>
>>> Morphs must not rely on any current display medium state such as
>>> background color or results of previous drawings, because some media
>>> types cannot hold or provide its current state in form, which can be
>>> easily accessible or manipulated.
>>> Any internal/current state of display medium can be accessible and
>>> manageable only by its canvas object.
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>>      
>>
>>    
>
>
>  

> Hi Juan -
>
> One thing I'm curious about is whether you consider this a research
> project or if you plan to produce a practical artifact. There is
> nothing wrong with the former of course but if you aim for a practical
> artifact I would reconsider some issues, like writing your own
> renderer. It can be done but it will take just as much time (if not
> more) than the rest of the architecture. Been there, done that ;-)
>
> Cheers,
>   - Andreas
>
> Juan Vuletich wrote:
>> Hi Folks,
>>
>> I started to write a "paper to be" about my Morphic 3.0 project. The
>> objective is to convince you that Morphic 3.0 is the coolest thing
>> around :). The first draft is available at www.jvuletich.org. I hope
>> you enjoy it. Any comment is welcome.
>>
>> Cheers,
>> Juan Vuletich
>> www.jvuletich.org
>>
>>
>
>
>

> On Thu, Aug 30, 2007 at 12:14:03AM -0300, Juan Vuletich wrote:
>  
>> Hi Folks,
>>
>> I started to write a "paper to be" about my Morphic 3.0 project. The
>> objective is to convince you that Morphic 3.0 is the coolest thing
>> around :). The first draft is available at www.jvuletich.org. I hope you
>> enjoy it. Any comment is welcome.
>>    
>
> Nice. I just had one question: would gamma correction be taken
> into account at all?
>
> Especially when rendering text, light-on-dark always looks
> bigger than dark-on-light for exactly the same shape. Is it
> possible to (in general) render a shape with constant "mass" in
> the face of gamma inconsistencies? For text, this would involve
> procedural bolding/thinning.
>
> Just throwing that out.
>
>  

> Juan Vuletich schrieb:
> "
> I want high quality rendering on any Display, regardless of size or
> pixel resolution. Therefore, I need complete independence of those
> Display properties. The programmer must never deal with the concept of
> pixel. The GUI is thought at a higher level. All the GUI is
> independent of pixel resolution. All the rendering is anti aliased.
> But in order to be able to render equally well on very high resolution
> as on medium resolution devices, the objects to be rendered (i.e.
> morphs) must be specified in a way that doesn't depend on the
> resolution of the target device at all. The ultimate way to do this is
> by thinking of them as continuous functions. This applies to geometric
> shapes, but also to digital images (photos) and textures.
> "
>
> This will pose a problem with fonts - it was one of Fresco's
> (www.fresco.org) bigger issues when it came to the drawing model, as
> Fresco used a device independent layout, too.
>
> Bitmap fonts are pixel based, so those wouldn't work properly (how to
> translate a font pixel into a pixel-less world in a resolution
> independent way, so that the font always looks good?)
>
> Vector fonts have the issue that their features only incidentally will
> align to the pixel grid of your target device (when it comes down to
> rendering). (and compared to drawing, the human brain seems much more
> sensitive to that when it comes to text, maybe because it's more
> necessary detail per cm^2 than for the average drawing)
>
> Either, you just handle fonts like everything else and anti-alias them.
> See Acrobat Reader 5 (or so) with small fonts to see how it looks -
> you'll get a mathematically correct, unreadable grey pixel soup.
>
> Or you take hinting into account - but that forces you to think about
> a pixel grid again (hints help align glyph features to some grid), and
> you'll have to choose, which grid to take.
>
> Unfortunately, you can't just defer that decision until it's rendered
> to the device, as hinting can (to some extend) change the size of a
> glyph, depending on its location and the target resolution (and
> neighbor glyphs, I think, so you couldn't just render them one-by-one
> to given locations).
>
> Usually, the impact is minor, but you might get to the situation where
> a group of glyphs in a line get small enough due to changes in hinting
> that another word fits into their line (when it missed it before by
> just a minimum amount) and so you get to rewrap the whole text from
> that point (or ignore that by pinning text to fixed locations in some
> way, making that a special case)
>
> Anyway, when taking text into account, more thought might be necessary
> on that move.
>
> I'm very much in favor of a truly device independent graphic
> subsystem, though.
>
>
> Regards,
> Patrick Georgi
>
>
>