On Feb 1, 2008 4:12 AM, Juan Vuletich juan@jvuletich.org wrote:
> > > 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 duplicatedeffort,
many bugs appears, etc. Please do readhttp://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.
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.
"Pentagrams" and logarithmic scales in music? What in the devil's name are you talking about? http://en.wikipedia.org/wiki/Pentagram_%28disambiguation%29.
I can never see the majority of people ever using the features you mention. They're all specialised applications and IMHO better suited to custom implementations in the applications themselves. The GUI is the wrong place for this functionality.
I've had a good think about the usefulness of using non-linear coordinate system. The only realistic examples I could think of are:
- Zooming in, specifically for documents or graphical applications. This is a linear transformation. - Rotating things... such as photos. Again, a linear transformation. - Silly animated window effects.
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.
These are good features, although I must say I'm most interested in the cleaner code.
Is Morphic 3 retargetable? Could I run it using the Rome-based Canvas or Sig's OpenGL implementation?
Are you considering how to best use graphics hardware, or are you doing most operations in software?
Gulik.
Michael van der Gulik wrote:
"Pentagrams" and logarithmic scales in music? What in the devil's name are you talking about? http://en.wikipedia.org/wiki/Pentagram_%28disambiguation%29.
I apologize. I made up that one. I mean http://en.wikipedia.org/wiki/Music_notation especially "Modern musical notation". And when plotting a spectrogram for working in music, the frequency scale should be logarithmic, to make height on the Display the same for all notes.
I can never see the majority of people ever using the features you mention. They're all specialised applications and IMHO better suited to custom implementations in the applications themselves. The GUI is the wrong place for this functionality.
Well, I don't agree.
I've had a good think about the usefulness of using non-linear coordinate system. The only realistic examples I could think of are:
- Zooming in, specifically for documents or graphical applications.
This is a linear transformation.
- Rotating things... such as photos. Again, a linear transformation.
- Silly animated window effects.
Saying that software for music, technical plots, maps and teaching math is non realistic sounds pretty strange to me.
> > 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.These are good features, although I must say I'm most interested in the cleaner code.
Once you support the signal processing approach to anti aliasing, supporting non-linear coordinate systems besides linear, is almost free.
Is Morphic 3 retargetable? Could I run it using the Rome-based Canvas or Sig's OpenGL implementation?
It could be done, if you restrict yourself to Cartesian coordinate systems and linear transformations. However the services offered by the canvas are not the same as existing canvases. New Canvas classes would be needed.
Are you considering how to best use graphics hardware, or are you doing most operations in software?
Currently, everything is done in software. Many of the algorithms and techniques are new. However, the rendering engine is separated from the morphs. It's no big deal to replace it with another one that uses OpenGL, Cairo or anything.
Cheers, Juan Vuletich
On Jan 31, 2008 9:10 PM, Michael van der Gulik mikevdg@gmail.com wrote:
I can never see the majority of people ever using the features you mention.
+1. For me personally, coordinates are a low level implementation detail. I don't care, or even want to know, what coordinate system is in use. If the GUI system forces me to know then I wouldn't use it (I expect to use a DSL, graphic or otherwise, to build the application). Of course *someone* will have to know, but not the majority of people.
I am interested in Juan's ideas on this since it does sound neat. It's just not a selling point for me to use Morphic 3. Being more powerful at what *I* would use it for (making GUI applications) is.
On Feb 1, 2008, at 7:17 , Jason Johnson wrote:
On Jan 31, 2008 9:10 PM, Michael van der Gulik mikevdg@gmail.com wrote:
I can never see the majority of people ever using the features you mention.
+1.
If we follow that argument we could get rid of a lot of stuff of what makes Squeak, Squeak.
- Bert -
Bert Freudenberg wrote:
On Feb 1, 2008, at 7:17 , Jason Johnson wrote:
On Jan 31, 2008 9:10 PM, Michael van der Gulik mikevdg@gmail.com wrote:
I can never see the majority of people ever using the features you mention.
+1.
If we follow that argument we could get rid of a lot of stuff of what makes Squeak, Squeak.
- Bert -
Exactly!
Since I knew about Squeak and started following its development, I've been a bit disappointed by how little emphasis is put on what makes Squeak Squeak. Also, I see a lot of cool new developer tools and librariesbut very little progress about multimedia stuff (audio, video and graphics).
Since the beginning, I was scared to put a lot of work in projects built around Morphic (which, AFAIK, is one of the core ideas and one of the most interesting things in Squeak). I perceived it as something that would have been discarded, sooner or later.
Just my two cents, but it seems to me that Juan work is one of the few promising projects in this direction.
-c.
On Feb 1, 2008 12:53 PM, Bert Freudenberg bert@freudenbergs.de wrote:
On Feb 1, 2008, at 7:17 , Jason Johnson wrote:
If we follow that argument we could get rid of a lot of stuff of what makes Squeak, Squeak.
- Bert -
I see I didn't get my point across well. I'm glad Juan is doing what he's doing and I read every new message he sends about Morphic 3. My point was that seemly all focus has been on something I personally consider an implementation detail. It's cool to know about it, but it's not really a selling point by itself (presuming he wishes to drum up interest in Morphic 3).
On 1-Feb-08, at 9:45 AM, Jason Johnson wrote:
I see I didn't get my point across well. I'm glad Juan is doing what he's doing and I read every new message he sends about Morphic 3. My point was that seemly all focus has been on something I personally consider an implementation detail. It's cool to know about it, but it's not really a selling point by itself (presuming he wishes to drum up interest in Morphic 3).
You're right - pluggable coordinate systems aren't something that's useful to users of Morphic. But that's not the point. Pluggable coordinate systems are a feature for developers, not users, and for developers it's really useful.
Colin
On Feb 2, 2008 5:47 AM, Colin Putney cputney@wiresong.ca wrote:
You're right - pluggable coordinate systems aren't something that's useful to users of Morphic. But that's not the point. Pluggable coordinate systems are a feature for developers, not users, and for developers it's really useful.
And as I said, it is interesting and I'm interested to see how it comes out. But most of the *developers* who use Morphic for their applications shouldn't see anything about coordinates. Coordinates are a low level implementation detail and if I see it in the same place I see business logic, then that's a leaky abstraction.
The developers who *will* use it are only the ones making some kind of lower level Morph that has to know, but that won't be the majority of developers (unless no one is producing any applications), which was the original statement.
"Jason Johnson" jason.johnson.081@gmail.com wrote in message
But most of the *developers* who use Morphic for their applications shouldn't see anything about coordinates.
Do you by chance mean "shouldn't see anything about pixel-based coordinates"? Or that most developers would use non-numeric layout directives and constraints?
Juan, could even Right|Left|Above|Below be (the basis of) a co-ordinate system?
Uninformed & curious - Sophie
On Feb 2, 2008 4:38 PM, itsme213 itsme213@hotmail.com wrote:
Do you by chance mean "shouldn't see anything about pixel-based coordinates"? Or that most developers would use non-numeric layout directives and constraints?
I mean shouldn't see any pixel coordinates or any other low level details. Applications should use a higher level construct for placement. Take for example HTML. A well written Seaside application may specify what types of "widgets" are present, but it says nothing about where they are placed. That is done with CSS, external to the application, making the application pretty resilient to a wide range of graphical changes.
itsme213 wrote:
Juan, could even Right|Left|Above|Below be (the basis of) a co-ordinate system?
I don't know. 2 D coordinate systems convert between 2 D coordinates, i.e. pairs of numbers (as the usual x@y). What would be the meaning of coordinates in your system?
Cheers, Juan Vuletich
Bert Freudenberg wrote:
On Feb 1, 2008, at 7:17 , Jason Johnson wrote:
On Jan 31, 2008 9:10 PM, Michael van der Gulik mikevdg@gmail.com wrote:
I can never see the majority of people ever using the features you mention.
+1.
If we follow that argument we could get rid of a lot of stuff of what makes Squeak, Squeak.
- Bert -
Sometimes it seems Smalltalk is in a everlasting loop of building tool to make tool to make tool cycle :-) Karl
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Cesare Marilungo -
Colin Putney -
itsme213 -
Jason Johnson -
Juan Vuletich -
Karl -
Michael van der Gulik