Hi folks,
On Dec 10^th to Dec 12^th we had Smalltalks 2007, the first Smalltalk conference in Buenos Aires, Argentina. There I gave a talk and demo of Morphic 3. You can read more, get the updated Morphic 3 Squeak image, and even see a video of my talk at www.jvuletich.org
I hope you like it!
Cheers, Juan Vuletich
El 12/23/07 12:04 PM, "Juan Vuletich" juan@jvuletich.org escribió:
Hi folks,
On Dec 10^th to Dec 12^th we had Smalltalks 2007, the first Smalltalk conference in Buenos Aires, Argentina. There I gave a talk and demo of Morphic 3. You can read more, get the updated Morphic 3 Squeak image, and even see a video of my talk at www.jvuletich.org
I hope you like it!
Cheers, Juan Vuletich
And if you don't, could miss the future Squeak.
Edgar
Can you talk about Morphic 3 in relation to Tweak? I don't know much about this but it seems that another group is building a successor to Morphic that purports to be a best of both worlds (from MVC and Morphic). I'm just curious to know more.
On Dec 23, 2007, at 7:04 AM, Juan Vuletich wrote:
Hi folks,
On Dec 10^th to Dec 12^th we had Smalltalks 2007, the first Smalltalk conference in Buenos Aires, Argentina. There I gave a talk and demo of Morphic 3. You can read more, get the updated Morphic 3 Squeak image, and even see a video of my talk at www.jvuletich.org
I hope you like it!
Cheers, Juan Vuletich
Hi Randy,
The objectives of Morphic 3 and Tweak are quite different. I wrote a little bit about this at http://www.jvuletich.org/DirectManipulation.html . At http://www.jvuletich.org/Morphic3/TheFutureOfTheGUI_01.html you can read quite a bit about the Morphic 3 objectives.
Tweak doesn't address my concerns, especially about non linear coordinate systems. The 3 main features of Tweak as it says at http://tweakproject.org/ are asynchronous events, language extensions and a viewing architecture. I don't find any of them especially useful so I'm not pursuing any integration with Tweak.
Hope this helps.
Juan Vuletich
Randy Siler wrote:
Can you talk about Morphic 3 in relation to Tweak? I don't know much about this but it seems that another group is building a successor to Morphic that purports to be a best of both worlds (from MVC and Morphic). I'm just curious to know more.
On Dec 23, 2007, at 7:04 AM, Juan Vuletich wrote:
Hi folks,
On Dec 10^th to Dec 12^th we had Smalltalks 2007, the first Smalltalk conference in Buenos Aires, Argentina. There I gave a talk and demo of Morphic 3. You can read more, get the updated Morphic 3 Squeak image, and even see a video of my talk at www.jvuletich.org
I hope you like it!
Cheers, Juan Vuletich
On Jan 22, 2008 3:51 AM, Juan Vuletich juan@jvuletich.org wrote:
Hi Randy,
Tweak doesn't address my concerns, especially about non linear coordinate systems.
But I think the state-of-the-art system should be good for Gurus and average programmers as well. That is, it should be really good at pumping out the average GUI that usually gets made.
For most programmers, a non-linear coordinate system is totally irrelevant. What will Morphic 3 have that makes it fast and effective for developing GUI's? Sad to say, but so far the best system I have seen for letting one build a GUI "directly" is probably C#.
Hi Jason,
I'm not doing Morphic 3 to suit the average programmer needs, in the same way Morphic was not built for that. You (everybody!) should watch the ARK and Self videos.
If all you want is a GUI buider, don't waste your time with Squeak. Most other Smalltalk dialects include WindowBuilder, the father of all GUI builders. Consider Visual Smalltalk, Smalltalk Express, VisualWorks, Dolphin or VA Smalltalk. I believe all of them are free or have non-commercial variants.
If you still believe the world needs another GUI builder, I see two ways. You could work on it (I'd be happy to integrate your work in Morphic 3), or you could raise money to allow me to leave my paid job and work on it. As Tim says "one MILLION euros"! Also, I believe that anyone working on a Squeak GUI builder should do it for ToolBuilder.
Cheers, Juan Vuletich
Jason Johnson wrote:
On Jan 22, 2008 3:51 AM, Juan Vuletich juan@jvuletich.org wrote:
Hi Randy,
Tweak doesn't address my concerns, especially about non linear coordinate systems.
But I think the state-of-the-art system should be good for Gurus and average programmers as well. That is, it should be really good at pumping out the average GUI that usually gets made.
For most programmers, a non-linear coordinate system is totally irrelevant. What will Morphic 3 have that makes it fast and effective for developing GUI's? Sad to say, but so far the best system I have seen for letting one build a GUI "directly" is probably C#.
Hi Jaun, thanks for the reply (comments below)
On Jan 22, 2008 8:03 PM, Juan Vuletich juan@jvuletich.org wrote:
Hi Jason,
I'm not doing Morphic 3 to suit the average programmer needs, in the same way Morphic was not built for that. You (everybody!) should watch the ARK and Self videos.
That I will. But by saying "this system is not built for the average programmer" sounds like "this system is not really relevant in the real world"/"this is an academic system". The fact is, either Morphic is the state-of-the-art, best GUI developing system there is, or it's not. If you can't use it to build a standard GUI application rapidly, then I can't imagine what makes it better, or even as good as what we have today.
I'm not saying we should follow the lowest common denominator. I truly believe that Smalltalk is a better system and leaps and bounds above other environments. But if that is truly the case there should be some evidence of it. It should *do* something better then other systems do. In Smalltalk's case, for me the interactive nature of it is that evidence. But in Morphic's case, I'm still looking.
If all you want is a GUI buider, don't waste your time with Squeak. Most other Smalltalk dialects include WindowBuilder, the father of all GUI builders. Consider Visual Smalltalk, Smalltalk Express, VisualWorks, Dolphin or VA Smalltalk. I believe all of them are free or have non-commercial variants.
I want more then a GUI builder. I want to graphically piece together a living application in a graphical manner. I have used Dolphin, and I have to say that so far C# is closer to that vision then anything I've seen from Smalltalk yet. C#'s "cult of the dead" nature is the main thing holding it back. Since Smalltalk doesn't have that anchor I expect it to be more capable.
If you still believe the world needs another GUI builder, I see two ways.
It does because the existing ones are not good enough. But how do you envision graphical applications being created? By writing code that generates them? How can we claim to have an advanced system when even C (!!!!!) had more efficient mechanisms years ago?
You could work on it (I'd be happy to integrate your work in Morphic 3), or you could raise money to allow me to leave my paid job and work on it. As Tim says "one MILLION euros"! Also, I believe that anyone working on a Squeak GUI builder should do it for ToolBuilder.
Cheers, Juan Vuletich
At some point I probably will work on a "next gen" GUI builder, but it's going to be a long time. To be honest, I'm just trying to understand what's so great about Morphic. So many people I respect (including you) think it is state-of-the-art so I'm hoping conversation will point me somewhere that explains why. At this point it just looks to me like an idea that was great and made sense in Self that was shoe-horned in somewhere it didn't really fit.
Hi Jason,
Jason Johnson wrote:
But by saying "this system is not built for the average programmer" sounds like "this system is not really relevant in the real world"/"this is an academic system". The fact is, either Morphic is the state-of-the-art, best GUI developing system there is, or it's not.
This sounds like advertising talk. I don't think there is well defined meaning for such words as "average programmer", "real world", "academic", "state-of-the-art", "best", etc. I prefer talking about actual ideas. I try to do that when I write.
If you can't use it to build a standard GUI application rapidly, then I can't imagine what makes it better, or even as good as what we have today.
Well, many, including me, have written quite a bit on that. A lot has been talked at this list about the pink plane vs. blue plane tension, etc. You can start at http://www.jvuletich.org/Squeak/IntroductionToMorphic/Morphic.html .
I'm not saying we should follow the lowest common denominator. I truly believe that Smalltalk is a better system and leaps and bounds above other environments. But if that is truly the case there should be some evidence of it. It should *do* something better then other systems do. In Smalltalk's case, for me the interactive nature of it is that evidence. But in Morphic's case, I'm still looking.
Then pay more attention. Squeak already includes a lot of morphs that would be really hard to write in other language / environments. EnvelopeEditorMorph is one of my favorites.
I want more then a GUI builder. I want to graphically piece together a living application in a graphical manner. I have used Dolphin, and I have to say that so far C# is closer to that vision then anything I've seen from Smalltalk yet. C#'s "cult of the dead" nature is the main thing holding it back. Since Smalltalk doesn't have that anchor I expect it to be more capable.
Well, I helped write an application that way in 1997 using VisualAge Smalltalk (now VA Smalltalk). Also VisualWorks and Visual Smalltalk supported or still support that way of programming. In my experience, and that of many others, code is much better at tackling real complex applications and at building a mainteinable system. I believe the whole "visual programming" idea failed for professional developers.
If you still believe the world needs another GUI builder, I see two ways.
It does because the existing ones are not good enough. But how do you envision graphical applications being created? By writing code that generates them? How can we claim to have an advanced system when even C (!!!!!) had more efficient mechanisms years ago?
As I said, use WindowBuilder. I've been using it for about ten years now, in Visual Smalltalk. Take a look at www.caesarsystems.com (my employer). PetroVR is a pretty sophisticated and good looking software. I think WindowBuilder is pretty good. Anyway, I don't think Squeak really needs something like that, because GUI builders only help on the easiest part of a GUI. The real complexity is in the dynamic behavior of the GUI, and on GUI elements that are not "widgets on a form". I write most of the PetroVR code for non widget-based GUIs. For these things, Smalltalk code is the best, and Morphic is much better than other frameworks I know.
At some point I probably will work on a "next gen" GUI builder, but it's going to be a long time. To be honest, I'm just trying to understand what's so great about Morphic. So many people I respect (including you) think it is state-of-the-art so I'm hoping conversation will point me somewhere that explains why.
Well, I gave some pointers. Most of the stuff at http://www.jvuletich.org/ could be useful. Also read squeak.org, the wikis, use google, etc. Besides, study the system. It's all there.
At this point it just looks to me like an idea that was great and made sense in Self that was shoe-horned in somewhere it didn't really fit.
I don't think why would you think that. I really believe you need more reading and studying Squeak.
Cheers, Juan Vuletich
On Jan 23, 2008 12:42 AM, Juan Vuletich juan@jvuletich.org wrote:
This sounds like advertising talk. I don't think there is well defined meaning for such words as "average programmer", "real world", "academic", "state-of-the-art", "best", etc. I prefer talking about actual ideas. I try to do that when I write.
You're the one who said Morphic isn't for the "average programmer". :) As you may have noticed from the list, I like to talk about ideas myself. But just because an idea exists, doesn't mean it's good or effectively applied, so these things still have to be looked into.
Well, many, including me, have written quite a bit on that. A lot has been talked at this list about the pink plane vs. blue plane tension, etc. You can start at http://www.jvuletich.org/Squeak/IntroductionToMorphic/Morphic.html .
Best link I've seen yet. Thanks, I'm going through it.
But the information is somewhat dated though. For example, in the C# system (sorry to harp on it, but this is the one I'm currently most familiar with) you program about how you have described as "Classic morphic" (the documentation indicated that other systems just have canned widgets to use). That is, you go find a component close to what you want, subclass it and specialize it. Then it appears on the tool box and can be applied visually. The IDE services are totally available to you so you can take this as far as you want. As I mentioned, the biggest problem I've seen is the fact that the language still has to differentiate between "compile/design time" and "run time". A limitation Smalltalk doesn't have.
Then pay more attention.
Oh I do. I read every message I see about Morphic on the list, trying to see what it's "kill feature" is.
Squeak already includes a lot of morphs that would be really hard to write in other language / environments. EnvelopeEditorMorph is one of my favorites.
I looked at that class and I saw a Morph containing a piano, a view on a musical scale and a few menus. If I get time I may take a crack at it in the C# or Dolphin environment because it seemed pretty straight forward (and one always learns why it isn't in implementation :).
Well, I helped write an application that way in 1997 using VisualAge Smalltalk (now VA Smalltalk). Also VisualWorks and Visual Smalltalk supported or still support that way of programming. In my experience, and that of many others, code is much better at tackling real complex applications and at building a mainteinable system.
Well, is that because it is the best way to do it, or because the tools don't help us constructing the interfaces enough? Of course building applications via code must be supported, but in a system built in itself like Smalltalk, of course it will be. I watched the Self video and they seemed to be building some pretty interesting and complicated things in a largely graphical way.
I believe the whole "visual programming" idea failed for professional developers.
That's a rather bold statement. It depends again on how you're going to define "professional developers" but if you define them as people who get paid to program then I suspect that the vast majority of all developers writing native GUIs are doing so in a mostly graphical manner and have been for decades.
Well, I gave some pointers. Most of the stuff at http://www.jvuletich.org/ could be useful. Also read squeak.org, the wikis, use google, etc. Besides, study the system. It's all there.
Yep, thanks for those. At one point I had read everything on your site on the subject, but I haven't look at it in for a couple of months.
I don't think why would you think that. I really believe you need more reading and studying Squeak.
Mainly because having read the tutorials and papers on Self and Morphic from Sun's research web site, it seemed that Morphic gained a lot of power from the object instance modification capabilities. Since Smalltalk is a class based system you lose much of that (e.g. adding a method ad-hoc to a morph you're working on). The way one has to do it in Smalltalk is by programatically generating classes, which I dislike. In Etoys, one programs at a higher level so it doesn't matter so much how things are implemented at the lower levels you don't see, but at the Smalltalk level it doesn't strike me as very elegant.
And I'm sure you're right that I do need to read more. Squeak is quite vast with a great deal to learn.
Hi Jason,
Jason Johnson wrote:
On Jan 23, 2008 12:42 AM, Juan Vuletich juan@jvuletich.org wrote:
You're the one who said Morphic isn't for the "average programmer". :)
Well, I said "I'm not doing Morphic 3 to suit the average programmer needs". That doesn't mean that Morphic isn't for the average programmer. It means that my objectives are not finding out what are the needs of the average programmer. I really don't know what they are. And I don't care too much.
http://www.jvuletich.org/Squeak/IntroductionToMorphic/Morphic.html .
Best link I've seen yet. Thanks, I'm going through it.
Thanks!
Then pay more attention.
Oh I do. I read every message I see about Morphic on the list, trying to see what it's "kill feature" is.
Quoted alone, my phrase sounds rude. I apologize. I meant that Squeak itself is a great place to study and learn. I don't think the point is about a "kill feature". I think it is about flexibility and openness. I've never used C#, or anything but Smalltalk in the last 10 years, but I don't believe something like EnvelopeEditorMorph could be done with so little and simple code. Anyway, I might be wrong. If C# is so good, then why not use it? If its GUI framework and tools are that good, why not port them to Squeak?
I looked at that class and I saw a Morph containing a piano, a view on a musical scale and a few menus. If I get time I may take a crack at it in the C# or Dolphin environment because it seemed pretty straight forward (and one always learns why it isn't in implementation :).
It also has actual envelopes you can grab with the mouse to modify the sound. If you can do something like that in C# or Dolphin, with as little code as in Morphic, please tell me, and let me see the code.
Well, I helped write an application that way in 1997 using VisualAge Smalltalk (now VA Smalltalk). Also VisualWorks and Visual Smalltalk supported or still support that way of programming. In my experience, and that of many others, code is much better at tackling real complex applications and at building a mainteinable system.
Well, is that because it is the best way to do it, or because the tools don't help us constructing the interfaces enough?
I don't know, but if you have hope on "visual programming" I suggest using Parts in VisualWorks, or the VisualBuilder in VisualAge, write an application (without code, only arrows connecting objects), maintain it (i.e. modify it and keep it working) and find out for yourself if a better tool could make that way of programming useful.
Of course building applications via code must be supported, but in a system built in itself like Smalltalk, of course it will be. I watched the Self video and they seemed to be building some pretty interesting and complicated things in a largely graphical way.
I believe the whole "visual programming" idea failed for professional developers.
That's a rather bold statement. It depends again on how you're going to define "professional developers" but if you define them as people who get paid to program then I suspect that the vast majority of all developers writing native GUIs are doing so in a mostly graphical manner and have been for decades.
Decades? The first visual programming tools commercially available are about 15 years old. And most people build guis with gui builders, but almost nobody use visual programming tools. May be we are not speaking about the same, visual programming means defining the application behavior without code (not only the GUI, the model too). I say this idea failed, because (almost) nobody uses it, and tool vendors don't sell it as the future anymore.
I don't think why would you think that. I really believe you need more reading and studying Squeak.
Mainly because having read the tutorials and papers on Self and Morphic from Sun's research web site, it seemed that Morphic gained a lot of power from the object instance modification capabilities. Since Smalltalk is a class based system you lose much of that (e.g. adding a method ad-hoc to a morph you're working on). The way one has to do it in Smalltalk is by programatically generating classes, which I dislike. In Etoys, one programs at a higher level so it doesn't matter so much how things are implemented at the lower levels you don't see, but at the Smalltalk level it doesn't strike me as very elegant.
I see. However, I don't agree. I think programming in Smalltalk by defining classes is both powerful and elegant.
And I'm sure you're right that I do need to read more. Squeak is quite vast with a great deal to learn.
:)
Cheers, Juan Vuletich
On Jan 23, 2008 8:09 PM, Juan Vuletich juan@jvuletich.org wrote:
Hi Jason,
Jason Johnson wrote:
On Jan 23, 2008 12:42 AM, Juan Vuletich juan@jvuletich.org wrote:
You're the one who said Morphic isn't for the "average programmer". :)
Well, I said "I'm not doing Morphic 3 to suit the average programmer needs". That doesn't mean that Morphic isn't for the average programmer. It means that my objectives are not finding out what are the needs of the average programmer. I really don't know what they are. And I don't care too much.
To be clear I fully respect your free time and choices so if none of this matters to you it's fine by me. I just think that when you say you are working on Morphic 3.0 with the implication that it is the future of the Squeak GUI you're inviting input.
There are a lot of "average programmers" who are very bright and motivated people that happen to have other full time professions. What they want are a set of rock-solid components they can use out of the box to code basic interfaces - the list of Widgets/V componentshttp://www.ddj.com/184408550?pgno=3#011f_0005, though 17 years old isn't far off the mark. The GUI builder in Widgets/V left a lot to be desired - which is how/why it evolved into WindowBuilder, but the components opened a new world of possibilities for "average programmers". None of the current Squeak GUIs - Morphic, E-Toys or Tweak provide these rock-solid components out of the box, but it seems like Morphic 3.0 could as a matter of course. I like many of the ideas in Morphic 3.0 and don't see having a set of practical, core components as being in conflict with them. In fact, I think they are complimentary in many respects - they provide excellent test suites and broaden the base of testers which always helps any GUI.
Cheers, Laurence
http://www.jvuletich.org/Squeak/IntroductionToMorphic/Morphic.html .
Best link I've seen yet. Thanks, I'm going through it.
Thanks!
Then pay more attention.
Oh I do. I read every message I see about Morphic on the list, trying to see what it's "kill feature" is.
Quoted alone, my phrase sounds rude. I apologize. I meant that Squeak itself is a great place to study and learn. I don't think the point is about a "kill feature". I think it is about flexibility and openness. I've never used C#, or anything but Smalltalk in the last 10 years, but I don't believe something like EnvelopeEditorMorph could be done with so little and simple code. Anyway, I might be wrong. If C# is so good, then why not use it? If its GUI framework and tools are that good, why not port them to Squeak?
I looked at that class and I saw a Morph containing a piano, a view on a musical scale and a few menus. If I get time I may take a crack at it in the C# or Dolphin environment because it seemed pretty straight forward (and one always learns why it isn't in implementation :).
It also has actual envelopes you can grab with the mouse to modify the sound. If you can do something like that in C# or Dolphin, with as little code as in Morphic, please tell me, and let me see the code.
Well, I helped write an application that way in 1997 using VisualAge Smalltalk (now VA Smalltalk). Also VisualWorks and Visual Smalltalk supported or still support that way of programming. In my experience, and that of many others, code is much better at tackling real complex applications and at building a mainteinable system.
Well, is that because it is the best way to do it, or because the tools don't help us constructing the interfaces enough?
I don't know, but if you have hope on "visual programming" I suggest using Parts in VisualWorks, or the VisualBuilder in VisualAge, write an application (without code, only arrows connecting objects), maintain it (i.e. modify it and keep it working) and find out for yourself if a better tool could make that way of programming useful.
Of course building applications via code must be supported, but in a system built in itself like Smalltalk, of course it will be. I watched the Self video and they seemed to be building some pretty interesting and complicated things in a largely graphical way.
I believe the whole "visual programming" idea failed for professional developers.
That's a rather bold statement. It depends again on how you're going to define "professional developers" but if you define them as people who get paid to program then I suspect that the vast majority of all developers writing native GUIs are doing so in a mostly graphical manner and have been for decades.
Decades? The first visual programming tools commercially available are about 15 years old. And most people build guis with gui builders, but almost nobody use visual programming tools. May be we are not speaking about the same, visual programming means defining the application behavior without code (not only the GUI, the model too). I say this idea failed, because (almost) nobody uses it, and tool vendors don't sell it as the future anymore.
I don't think why would you think that. I really believe you need more reading and studying Squeak.
Mainly because having read the tutorials and papers on Self and Morphic from Sun's research web site, it seemed that Morphic gained a lot of power from the object instance modification capabilities. Since Smalltalk is a class based system you lose much of that (e.g. adding a method ad-hoc to a morph you're working on). The way one has to do it in Smalltalk is by programatically generating classes, which I dislike. In Etoys, one programs at a higher level so it doesn't matter so much how things are implemented at the lower levels you don't see, but at the Smalltalk level it doesn't strike me as very elegant.
I see. However, I don't agree. I think programming in Smalltalk by defining classes is both powerful and elegant.
And I'm sure you're right that I do need to read more. Squeak is quite vast with a great deal to learn.
:)
Cheers, Juan Vuletich
Exact! Now what would be a nice step in that direction would be to have a small tutorial on the UiBuilder that already exists in Squeak ToolBuilder. Once brian started but I could never put my hand on it to read it/ improve it/ build on it.
Stef
On Jan 24, 2008, at 3:32 AM, Laurence Rozier wrote:
On Jan 23, 2008 8:09 PM, Juan Vuletich juan@jvuletich.org wrote: Hi Jason,
Jason Johnson wrote:
On Jan 23, 2008 12:42 AM, Juan Vuletich juan@jvuletich.org wrote:
You're the one who said Morphic isn't for the "average
programmer". :)
Well, I said "I'm not doing Morphic 3 to suit the average programmer needs". That doesn't mean that Morphic isn't for the average programmer. It means that my objectives are not finding out what are the needs of the average programmer. I really don't know what they are. And I don't care too much. To be clear I fully respect your free time and choices so if none of this matters to you it's fine by me. I just think that when you say you are working on Morphic 3.0 with the implication that it is the future of the Squeak GUI you're inviting input.
There are a lot of "average programmers" who are very bright and motivated people that happen to have other full time professions. What they want are a set of rock-solid components they can use out of the box to code basic interfaces - the list of Widgets/V components, though 17 years old isn't far off the mark. The GUI builder in Widgets/V left a lot to be desired - which is how/why it evolved into WindowBuilder, but the components opened a new world of possibilities for "average programmers". None of the current Squeak GUIs - Morphic, E-Toys or Tweak provide these rock-solid components out of the box, but it seems like Morphic 3.0 could as a matter of course. I like many of the ideas in Morphic 3.0 and don't see having a set of practical, core components as being in conflict with them. In fact, I think they are complimentary in many respects - they provide excellent test suites and broaden the base of testers which always helps any GUI.
Cheers, Laurence
Morphic.html .
Best link I've seen yet. Thanks, I'm going through it.
Thanks!
Then pay more attention.
Oh I do. I read every message I see about Morphic on the list,
trying
to see what it's "kill feature" is.
Quoted alone, my phrase sounds rude. I apologize. I meant that Squeak itself is a great place to study and learn. I don't think the point is about a "kill feature". I think it is about flexibility and openness. I've never used C#, or anything but Smalltalk in the last 10 years, but I don't believe something like EnvelopeEditorMorph could be done with so little and simple code. Anyway, I might be wrong. If C# is so good, then why not use it? If its GUI framework and tools are that good, why not port them to Squeak?
I looked at that class and I saw a Morph containing a piano, a
view on
a musical scale and a few menus. If I get time I may take a crack at it in the C# or Dolphin environment because it seemed pretty
straight
forward (and one always learns why it isn't in implementation :).
It also has actual envelopes you can grab with the mouse to modify the sound. If you can do something like that in C# or Dolphin, with as little code as in Morphic, please tell me, and let me see the code.
Well, I helped write an application that way in 1997 using
VisualAge
Smalltalk (now VA Smalltalk). Also VisualWorks and Visual Smalltalk supported or still support that way of programming. In my
experience,
and that of many others, code is much better at tackling real
complex
applications and at building a mainteinable system.
Well, is that because it is the best way to do it, or because the tools don't help us constructing the interfaces enough?
I don't know, but if you have hope on "visual programming" I suggest using Parts in VisualWorks, or the VisualBuilder in VisualAge, write an application (without code, only arrows connecting objects), maintain it (i.e. modify it and keep it working) and find out for yourself if a better tool could make that way of programming useful.
Of course building applications via code must be supported, but in a system built in itself like Smalltalk, of course it will be. I watched the Self video and they seemed to be building some pretty interesting
and
complicated things in a largely graphical way.
I believe the whole "visual programming" idea failed for professional developers.
That's a rather bold statement. It depends again on how you're
going
to define "professional developers" but if you define them as people who get paid to program then I suspect that the vast majority of all developers writing native GUIs are doing so in a mostly graphical manner and have been for decades.
Decades? The first visual programming tools commercially available are about 15 years old. And most people build guis with gui builders, but almost nobody use visual programming tools. May be we are not speaking about the same, visual programming means defining the application behavior without code (not only the GUI, the model too). I say this idea failed, because (almost) nobody uses it, and tool vendors don't sell it as the future anymore.
I don't think why would you think that. I really believe you need
more
reading and studying Squeak.
Mainly because having read the tutorials and papers on Self and Morphic from Sun's research web site, it seemed that Morphic
gained a
lot of power from the object instance modification capabilities. Since Smalltalk is a class based system you lose much of that ( e.g. adding a method ad-hoc to a morph you're working on). The way one
has
to do it in Smalltalk is by programatically generating classes,
which
I dislike. In Etoys, one programs at a higher level so it doesn't matter so much how things are implemented at the lower levels you don't see, but at the Smalltalk level it doesn't strike me as very elegant.
I see. However, I don't agree. I think programming in Smalltalk by defining classes is both powerful and elegant.
And I'm sure you're right that I do need to read more. Squeak is quite vast with a great deal to learn.
:)
Cheers, Juan Vuletich
Here is the email sent by andreas
- It appears that the Morphic tree widget from ToolBuilder doesn't
support drag and drop yet. Is this correct? Is there a version out there of ToolBuilder with a Morphic tree widget that supports drag and drop, or is this something I'll have to fix up?
The latest version at http://squeaksource.com/ToolBuilder should support drag and drop.
- ToolBuilder uses a lot of configurable method callbacks: when
constructing a UI, the constructor specifies which methods on the model respond to which events. Was it ever considered to hard-code these method names so that the model *must* implement them, or subclass something which does? Arguably that would make code more readable - it is guaranteed that a method of a particular name implements that particular callback making the callback easier to find.
Wouldn't that mean you can only have a single widget of each type per model? What would happen (for example) to browsers which utilize four lists out of the box?
Cheers, - Andreas
On Jan 24, 2008, at 3:32 AM, Laurence Rozier wrote:
On Jan 23, 2008 8:09 PM, Juan Vuletich juan@jvuletich.org wrote: Hi Jason,
Jason Johnson wrote:
On Jan 23, 2008 12:42 AM, Juan Vuletich juan@jvuletich.org wrote:
You're the one who said Morphic isn't for the "average
programmer". :)
Well, I said "I'm not doing Morphic 3 to suit the average programmer needs". That doesn't mean that Morphic isn't for the average programmer. It means that my objectives are not finding out what are the needs of the average programmer. I really don't know what they are. And I don't care too much. To be clear I fully respect your free time and choices so if none of this matters to you it's fine by me. I just think that when you say you are working on Morphic 3.0 with the implication that it is the future of the Squeak GUI you're inviting input.
There are a lot of "average programmers" who are very bright and motivated people that happen to have other full time professions. What they want are a set of rock-solid components they can use out of the box to code basic interfaces - the list of Widgets/V components, though 17 years old isn't far off the mark. The GUI builder in Widgets/V left a lot to be desired - which is how/why it evolved into WindowBuilder, but the components opened a new world of possibilities for "average programmers". None of the current Squeak GUIs - Morphic, E-Toys or Tweak provide these rock-solid components out of the box, but it seems like Morphic 3.0 could as a matter of course. I like many of the ideas in Morphic 3.0 and don't see having a set of practical, core components as being in conflict with them. In fact, I think they are complimentary in many respects - they provide excellent test suites and broaden the base of testers which always helps any GUI.
Cheers, Laurence
Morphic.html .
Best link I've seen yet. Thanks, I'm going through it.
Thanks!
Then pay more attention.
Oh I do. I read every message I see about Morphic on the list,
trying
to see what it's "kill feature" is.
Quoted alone, my phrase sounds rude. I apologize. I meant that Squeak itself is a great place to study and learn. I don't think the point is about a "kill feature". I think it is about flexibility and openness. I've never used C#, or anything but Smalltalk in the last 10 years, but I don't believe something like EnvelopeEditorMorph could be done with so little and simple code. Anyway, I might be wrong. If C# is so good, then why not use it? If its GUI framework and tools are that good, why not port them to Squeak?
I looked at that class and I saw a Morph containing a piano, a
view on
a musical scale and a few menus. If I get time I may take a crack at it in the C# or Dolphin environment because it seemed pretty
straight
forward (and one always learns why it isn't in implementation :).
It also has actual envelopes you can grab with the mouse to modify the sound. If you can do something like that in C# or Dolphin, with as little code as in Morphic, please tell me, and let me see the code.
Well, I helped write an application that way in 1997 using
VisualAge
Smalltalk (now VA Smalltalk). Also VisualWorks and Visual Smalltalk supported or still support that way of programming. In my
experience,
and that of many others, code is much better at tackling real
complex
applications and at building a mainteinable system.
Well, is that because it is the best way to do it, or because the tools don't help us constructing the interfaces enough?
I don't know, but if you have hope on "visual programming" I suggest using Parts in VisualWorks, or the VisualBuilder in VisualAge, write an application (without code, only arrows connecting objects), maintain it (i.e. modify it and keep it working) and find out for yourself if a better tool could make that way of programming useful.
Of course building applications via code must be supported, but in a system built in itself like Smalltalk, of course it will be. I watched the Self video and they seemed to be building some pretty interesting
and
complicated things in a largely graphical way.
I believe the whole "visual programming" idea failed for professional developers.
That's a rather bold statement. It depends again on how you're
going
to define "professional developers" but if you define them as people who get paid to program then I suspect that the vast majority of all developers writing native GUIs are doing so in a mostly graphical manner and have been for decades.
Decades? The first visual programming tools commercially available are about 15 years old. And most people build guis with gui builders, but almost nobody use visual programming tools. May be we are not speaking about the same, visual programming means defining the application behavior without code (not only the GUI, the model too). I say this idea failed, because (almost) nobody uses it, and tool vendors don't sell it as the future anymore.
I don't think why would you think that. I really believe you need
more
reading and studying Squeak.
Mainly because having read the tutorials and papers on Self and Morphic from Sun's research web site, it seemed that Morphic
gained a
lot of power from the object instance modification capabilities. Since Smalltalk is a class based system you lose much of that ( e.g. adding a method ad-hoc to a morph you're working on). The way one
has
to do it in Smalltalk is by programatically generating classes,
which
I dislike. In Etoys, one programs at a higher level so it doesn't matter so much how things are implemented at the lower levels you don't see, but at the Smalltalk level it doesn't strike me as very elegant.
I see. However, I don't agree. I think programming in Smalltalk by defining classes is both powerful and elegant.
And I'm sure you're right that I do need to read more. Squeak is quite vast with a great deal to learn.
:)
Cheers, Juan Vuletich
Hi Laurence,
I really welcome everybody's opinion. I want to know how the Squeak community sees my project.
And I fully agree with all you say. Morphic 3 will have a set of standard widgets. Not to please some "average programmer", but because I find it useful. What I don't have in my current plans is to work on a GUI builder. But this doesn't mean that it can not be done. I welcome not only input, but code. If people likes Morphic 3 and want to help, this is something that can be done.
Cheers, Juan Vuletich
Laurence Rozier wrote:
To be clear I fully respect your free time and choices so if none of this matters to you it's fine by me. I just think that when you say you are working on Morphic 3.0 with the implication that it is the future of the Squeak GUI you're inviting input.
There are a lot of "average programmers" who are very bright and motivated people that happen to have other full time professions. What they want are a set of rock-solid components they can use out of the box to code basic interfaces - the list of Widgets/V components http://www.ddj.com/184408550?pgno=3#011f_0005, though 17 years old isn't far off the mark. The GUI builder in Widgets/V left a lot to be desired - which is how/why it evolved into WindowBuilder, but the components opened a new world of possibilities for "average programmers". None of the current Squeak GUIs - Morphic, E-Toys or Tweak provide these rock-solid components out of the box, but it seems like Morphic 3.0 could as a matter of course. I like many of the ideas in Morphic 3.0 and don't see having a set of practical, core components as being in conflict with them. In fact, I think they are complimentary in many respects - they provide excellent test suites and broaden the base of testers which always helps any GUI.
Cheers, Laurence
Juan and all Squeakers:
Morphic 3.0 deserves lot more as "your stuff lack my XYZ needs" attitude.
In fact, is a beauty waiting gentlemen come to help !
I'm very sorry can't meet in person often and work together.
If you need I test some in Mac, XP, and Linux, I'm here.
Edgar
On Jan 24, 2008 10:29 AM, Juan Vuletich juan@jvuletich.org wrote:
What I don't have in my current plans is to work on a GUI builder.
Well, I guess I understand more about Morphic now. I was expecting some big "wow!" with it like I had with the rest of Smalltalk, but it seems like it is a GUI system that the "designer" is part of the display medium itself (world) instead of a separate application.
Having said that, I think what would really help Morphic be more accessible would simply be a "toolbox" application that showed all Morphs. But not just a trivial dump of the morphs like is done now in the menus, but a context sensitive toolbox. That is, if I have a Morph that works with Music, then the toolbox will present Morphs that are registered to work with Music Morphs. If I am working with Database-aware Morphs, then applicable other Database-aware Morphs show up. Of course I would want this toolbox to also show other applicable components that don't have a graphical display, but their only function is adding some feature to Morphs present on the form they are added to.
Maybe we could design some protocol that would allow Morphs to answer questions about themselves to allow this sort of contextual classification.
El 1/25/08 2:27 PM, "Jason Johnson" jason.johnson.081@gmail.com escribió:
Maybe we could design some protocol that would allow Morphs to answer questions about themselves to allow this sort of contextual classification.
you have the Objects flap ?
Is that not static? And I just see application-looking things in there. I
On Jan 25, 2008 7:32 PM, Edgar J. De Cleene edgardec2001@yahoo.com.ar wrote:
El 1/25/08 2:27 PM, "Jason Johnson" jason.johnson.081@gmail.com escribió:
Maybe we could design some protocol that would allow Morphs to answer questions about themselves to allow this sort of contextual classification.
you have the Objects flap ?
I do. That is the right idea (re-looked at the implementation to see how dynamic it is), but what I'm missing is context for it. E.g. when I first start a new Morphic there are only certain morphs that apply. Once a "top level" morph has been dropped, other "top level" morphs are no longer displayed.
I know this doesn't make as much sense in the Morphic concept, but perhaps something to think about for people who just want to build another bank account application.
El 1/28/08 2:46 PM, "Jason Johnson" jason.johnson.081@gmail.com escribió:
I know this doesn't make as much sense in the Morphic concept, but perhaps something to think about for people who just want to build another bank account application.
People with serious money should hire some of us here :=)
Edgar
We just need to pull a "Paul Graham", then we'll have all the time we need. :)
On Jan 28, 2008 7:53 PM, Edgar J. De Cleene edgardec2001@yahoo.com.ar wrote:
El 1/28/08 2:46 PM, "Jason Johnson" jason.johnson.081@gmail.com escribió:
I know this doesn't make as much sense in the Morphic concept, but perhaps something to think about for people who just want to build another bank account application.
People with serious money should hire some of us here :=)
Edgar
To me, the big WOW! is: "The framework is fully in Smalltalk; there are no "primitive" widgets or hidden functionality. This means that there are no restrictions to how a morph will appear and react. There are morphs that behave like the widgets usually found, and therefore conventional interfaces can be built. But there are more interesting visual metaphors like CurveMorph, FishEyeMorph, EnvelopeEditorMorph, or SpectrumAnalyzerMorph (see the next section with a Squeak at hand to know them). And the framework is open end extensible. It s not difficult to make new visual metaphors for our own objects, which are perfectly integrated in the system. This makes Morphic the ideal environment to experiment, learn and write new styles in user interfaces, breaking away from what commercial programming tools allows us to do."
Have you seen the ARK and Self videos? Maybe they enlighten you.
Jason Johnson wrote:
On Jan 24, 2008 10:29 AM, Juan Vuletich juan@jvuletich.org wrote:
What I don't have in my current plans is to work on a GUI builder.
Well, I guess I understand more about Morphic now. I was expecting some big "wow!" with it like I had with the rest of Smalltalk, but it seems like it is a GUI system that the "designer" is part of the display medium itself (world) instead of a separate application.
On Jan 25, 2008 8:09 PM, Juan Vuletich juan@jvuletich.org wrote:
To me, the big WOW! is: "The framework is fully in Smalltalk; there are no "primitive" widgets or hidden functionality.
Most of the GUI frameworks I work with are like this, so that's why I wasn't wowed by it.
This means that there are no restrictions to how a morph will appear and react. There are morphs that behave like the widgets usually found, and therefore conventional interfaces can be built.
Yes, Morphs are definitely more "alive" then components from other systems (though in a live system like Smalltalk I would expect nothing less).
But there are more interesting visual metaphors like CurveMorph, FishEyeMorph, EnvelopeEditorMorph, or SpectrumAnalyzerMorph (see the next section with a Squeak at hand to know them). And the framework is open end extensible. It s not difficult to make new visual metaphors for our own objects, which are perfectly integrated in the system. This makes Morphic the ideal environment to experiment, learn and write new styles in user interfaces, breaking away from what commercial programming tools allows us to do."
Commercial programming tools allow you to do much of this now. In fact C# can even add methods to built in classes. The rest of the world is catching up! :)
Have you seen the ARK and Self videos? Maybe they enlighten you.
I did. Honestly after using your pointers to dig a bit deeper, I guess I like Morphic over all and see it already has some of the things I wanted to implement. Needs a major spring cleaning though (hence the millions of projects to do so). :)
Ah, now I see the confusion. Part of the reason my messages get so long is I try to clarify things as much as I can to avoid confusion, but here I see I didn't explain what I meant by "programming visually".
I meant what I'm doing now, dropping components onto a form to build the view of an application. When no component exists that does what I want, I subclass something as close as I can find, add the behaviors it needs then move back to the designer and drop the new component onto the form. Of course the view only generates events or method calls, one has to write code to actually do something with it.
And I think this is how most what I have been calling "graphical developing systems" have worked (including Squeak-Morphic, even if it has proven the most difficult to get started in), but what has been missing in all the systems I had previously looked at was this ability for these components to be extendable and first class. Creating a semi-complex layout for a form, then "inheriting" that form to create other forms and factor the common behavior into the base forms. I.e., OO programming but in the graphical designer as well as the programming language.
(comments below)
On Jan 24, 2008 2:09 AM, Juan Vuletich juan@jvuletich.org wrote:
Well, I said "I'm not doing Morphic 3 to suit the average programmer needs". That doesn't mean that Morphic isn't for the average programmer. It means that my objectives are not finding out what are the needs of the average programmer. I really don't know what they are. And I don't care too much.
Ah ok. In that case I would agree. As Paul Graham said "a lot of the best ones were languages designed for their own authors to use, and a lot of the worst ones were designed for other people to use." [1]. And this idea holds for designing systems as well no doubt. My point was just that one also must balance this with practicality. Make it for yourself, but make it so *you* can do real world common things with it as well as anything your mind can imagine.
Quoted alone, my phrase sounds rude. I apologize. I meant that Squeak itself is a great place to study and learn. I don't think the point is about a "kill feature".
"killer feature". Can't believe I typoed that. :)
I think it is about flexibility and openness. I've never used C#, or anything but Smalltalk in the last 10 years, but I don't believe something like EnvelopeEditorMorph could be done with so little and simple code.
Well, my presumption here was that the piano and the chart were already created as separate components (as appears to be the case in Morphic). If so, it would indeed be trivial to add them to a form and slap together those menus. Of course you have to write the code that wires it together, and C# isn't a concise language, but I would expect it to be none-the-less straight forward once one has those two complex components.
Anyway, I might be wrong. If C# is so good, then why not use it?
Simple: Smalltalk is a superior language and superior environment. It is only this one aspect that is currently more intuitive in C# and that is fixable. What I'm trying to understand is how big is the gap.
If its GUI framework and tools are that good, why not port them to Squeak?
I suspect I will port certain features of it, though Smalltalk being a truly live environment removes the need for some of C#s more innovative features.
It also has actual envelopes you can grab with the mouse to modify the sound.
But the chart-like morph is a stand alone morph that views on an envelope using a variation of the standard MVC, no? In this case, I would expect it to behave exactly the same, though it will obviously be more lines of code in C#. But the hard part is in defining the Envelope viewer, not in putting it on the form or wiring it up.
I don't know, but if you have hope on "visual programming" I suggest using Parts in VisualWorks, or the VisualBuilder in VisualAge, write an application (without code, only arrows connecting objects), maintain it (i.e. modify it and keep it working) and find out for yourself if a better tool could make that way of programming useful.
I don't actually have much hope on "visual programming" as in "build everything graphically and write no code what so ever".
A picture is worth a thousand words, but the book is always better then the movie. I see programming more like a book/movie then a static picture. But I also am a strong believer in DSLs, and for me a graphical designer is the DSL if you will for low level uninteresting details about how components are laid out on a display. So I want to do with my "graphical" DSL what I can do with my "textual" DSL: extend it to be more powerful and factor common patterns into the DSL.
I say this idea failed, because (almost) nobody uses it, and tool vendors don't sell it as the future anymore.
Now that I know what you mean, I agree. :)
[1] http://www.paulgraham.com/langdes.html (2. Design for Yourself and Your Friends.)
Jason Johnson wrote:
Ah, now I see the confusion. Part of the reason my messages get so long is I try to clarify things as much as I can to avoid confusion, but here I see I didn't explain what I meant by "programming visually".
:)
As Paul Graham said "a lot of the best ones were languages designed for their own authors to use, and a lot of the worst ones were designed for other people to use." [1]. And this idea holds for designing systems as well no doubt. My point was just that one also must balance this with practicality. Make it for yourself, but make it so *you* can do real world common things with it as well as anything your mind can imagine.
Fully agreed. Great quote!
If its GUI framework and tools are that good, why not port them to Squeak?
I suspect I will port certain features of it, though Smalltalk being a truly live environment removes the need for some of C#s more innovative features.
:)
It also has actual envelopes you can grab with the mouse to modify the sound.
But the chart-like morph is a stand alone morph that views on an envelope using a variation of the standard MVC, no? In this case, I would expect it to behave exactly the same, though it will obviously be more lines of code in C#. But the hard part is in defining the Envelope viewer, not in putting it on the form or wiring it up.
The envelope viewer is the morph itself. That's the good part!
A picture is worth a thousand words, but the book is always better then the movie. I see programming more like a book/movie then a static picture.
Great phrase! I really love it!
Cheers, Juan Vuletich
squeak-dev@lists.squeakfoundation.org
-
Edgar J. De Cleene -
Jason Johnson -
Juan Vuletich -
Laurence Rozier -
Randy Siler -
stephane ducasse