AD> Would I be correct in thinking that real Squeak developers must not use AD> the interactive gui-building tools in Squeak because those tools don't AD> produce results that can be easily packaged?
that depends what you mean by packaged.
I packaged means an application you will just deliver an image with the gui set up the way you want it. Nobody cares how you built that gui.
One drawback of images is that they tend to be quite large. The .pr files are small so that strikes as better way of distributing programs.
Personally I start with interactively building a gui (often only a proposal of a gui) and then I switch to code.
I understand you to mean that you test out an interface design interactively, but then do start over coding the whole gui from scratch in smalltalk.
That's kind of tragic. Squeak is wonderful environment for building things, it shouldn't be necessary still do all the coding of the final product textually. Many WYSIWYG gui builders exist, I would have thought Squeak would be a leader there.
I think for my purposes (building simple apps, no ambition to be a professional grade developer) I ought to use the 3.8 image and work with projects. I hope that projects will be supported in later versions of the image.
Hi!
Andrew Dabrowski dabrowsa@indiana.edu wrote:
AD> Would I be correct in thinking that real Squeak developers must not use AD> the interactive gui-building tools in Squeak because those tools don't AD> produce results that can be easily packaged?
that depends what you mean by packaged.
I packaged means an application you will just deliver an image with the gui set up the way you want it. Nobody cares how you built that gui.
One drawback of images is that they tend to be quite large. The .pr files are small so that strikes as better way of distributing programs.
Mmmm, a .pr file is a so called ImageSegment. It needs to be loaded into an image. So distributing .pr files only work if the receiver already has an image. But you knew that I guess. :)
And btw, an ImageSegment is simply a "chunk of objectmemory". Or in other words a really fast serialization mechanism (fast because it uses primitives to actually write out the contents of memory for most of its contents).
Personally I start with interactively building a gui (often only a proposal of a gui) and then I switch to code.
I understand you to mean that you test out an interface design interactively, but then do start over coding the whole gui from scratch in smalltalk.
That's kind of tragic. Squeak is wonderful environment for building things, it shouldn't be necessary still do all the coding of the final product textually. Many WYSIWYG gui builders exist, I would have thought Squeak would be a leader there.
There have been several UI building tools/frameworks over the years. I can't really comment much on them. The continuous issue for all UI building tools is of course what the heck they should produce in the end (code? serialized objects? XML? etc).
I think for my purposes (building simple apps, no ambition to be a professional grade developer) I ought to use the 3.8 image and work with projects. I hope that projects will be supported in later versions of the image.
I think we will have projects for quite some time - but unfortunately they are not inherently backwards compatible. For example, loading projects from 3.7 into 3.8 causes problems (due to the new wide String stuff). This is the current reason SqueakMap only works in 3.8+. SqueakMap needs to move away from using ImageSegments in order to be compatible with more Squeak versions.
Btw, if you intend to build "end user regular apps" then you might want to look into either wxSqueak or possibly even the GtkPlugin:
http://www.wxsqueak.org/ http://squeakgtk.pbwiki.com/
Then you can use other UI building tools (Glade etc) to build the UIs.
regards, Göran
Hello Göran,
gks> There have been several UI building tools/frameworks over the years. I gks> can't really comment much on them.
I tried some of them and none was satisfactory imo.
I'm used to think of a gui as nested rows and columns in which to put widgets. Nice auto-layout, always aligned (think resizing and localisation). We are just doing localisation in a VC/VB project and it is a pain. Lucky I don't have to do it.
I've learned that from AutoDesk's dcl (dialogue control language) but they don't have a gui builder.
gks> The continuous issue for all UI building tools is of course what the gks> heck they should produce in the end (code? serialized objects? XML? gks> etc).
As long as it's ascii and the concepts are clear it's easy to build an interpreter for it. The Ascii only contains layout and widget names, at load time the app plugs the target and the method name into each widget.
gks> Btw, if you intend to build "end user regular apps" then you might want gks> to look into either wxSqueak or possibly even the GtkPlugin:
Haven't tried those.
Cheers,
Herbert mailto:herbertkoenig@gmx.net
Hello Andrew,
AD> One drawback of images is that they tend to be quite large. The .pr AD> files are small so that strikes as better way of distributing programs.
as I said it depends on what you (and I :-)) mean by packaged. I meant a shrinkwrapped Windows app, You seemed to talk about distributing to squeakers.
In this case Monticello and SqueakMap are kind of standard tools. But as Edgar pointed out sar is a good way too, if you want to include media. For MC distribution you have to stuff media into a method (search squeak dev) which I find cumbersome. I will change that opinion of mine as soon as i need versioned media.
AD> I understand you to mean that you test out an interface design AD> interactively, but then do start over coding the whole gui from scratch AD> in smalltalk.
Not quite. I come from a history of sketching the gui with pencil and paper. That's what I do by placing morphs in a project. There it's easier to move them and check for "mouse miles". Mouse miles maybe is my private invention but I check for mouse movements necessary to perform typical tasks.
Then I put in magenta Strings for the names I intend to give to the elements (ivars in the app) and blue strings for the methods I plan to send. I then print it and start coding.
AD> That's kind of tragic. Squeak is wonderful environment for building AD> things, it shouldn't be necessary still do all the coding of the final AD> product textually. Many WYSIWYG gui builders exist, I would have AD> thought Squeak would be a leader there.
I used Delphi (Versions 2 to 5) and I don't think so. It's ok for simple things and you still have to note the name of the elements of the gui on a printout if you don't want to look them up. mainForm.myLabel.text := 'asdf'. Yuck.
VC++ and VB where worse in those times.
AD> I think for my purposes (building simple apps, no ambition to be a AD> professional grade developer) I ought to use the 3.8 image and work with AD> projects. I hope that projects will be supported in later versions of AD> the image.
I use projects for more than one app in one image. Context menu of the world contains the the app's name and jumps to the project.
Be aware that imho 3.8 and earlier projects don't load into 3.9. But I guess projects will be continued, at least in the squeakland image, for very long.
Cheers
Herbert mailto:herbertkoenig@gmx.net
El 4/3/07 5:08 AM, "Herbert König" herbertkoenig@gmx.net escribió:
Be aware that imho 3.8 and earlier projects don't load into 3.9. But I guess projects will be continued, at least in the squeakland image, for very long.
You and Góran are wrong.
Some 3.7 and 3.8 projects loads into 3.9 (and 3.10 also) Those what don't load , if you take time could find what change between versions and do what load again.
I resurrect MorphicWrappers and MathMorphs from as old as 2.1 !! (some parts) and success to load Fabrik from last images what have it into 3.10.
My plans is when we reach 3.10beta is rip the Etoys and Nebraska from 3.10 for have proper .mcz what loads again, and possible do a "compatibility guesser" what could load older things. At this time 3.10 have problems with Etoys .pr from earlier versions.
About using Monticello as kind of .sar for distribution, also I have a "unapproved" version and a version of Rompecabezas with this format.
Edgar
On Apr 3, 2007, at 11:25 , Edgar J. De Cleene wrote:
El 4/3/07 5:08 AM, "Herbert König" herbertkoenig@gmx.net escribió:
Be aware that imho 3.8 and earlier projects don't load into 3.9. But I guess projects will be continued, at least in the squeakland image, for very long.
You and Góran are wrong.
Some 3.7 and 3.8 projects loads into 3.9 (and 3.10 also) Those what don't load , if you take time could find what change between versions and do what load again.
I resurrect MorphicWrappers and MathMorphs from as old as 2.1 !! (some parts) and success to load Fabrik from last images what have it into 3.10.
My plans is when we reach 3.10beta is rip the Etoys and Nebraska from 3.10 for have proper .mcz what loads again, and possible do a "compatibility guesser" what could load older things. At this time 3.10 have problems with Etoys .pr from earlier versions.
Edgar is right about that one - when loading a .pr in a newer image you can do all sorts of adjustments to make it work. This works in the Squeakland line of images for example - but it takes dedicated efforts to ensure loadability.
- Bert -
El 4/3/07 8:44 AM, "Bert Freudenberg" bert@freudenbergs.de escribió:
Edgar is right about that one - when loading a .pr in a newer image you can do all sorts of adjustments to make it work. This works in the Squeakland line of images for example - but it takes dedicated efforts to ensure loadability.
- Bert -
Bert you always inspire me , as all what Squeakland do
I got the etoys-2.0-1217.image , but I can found any way of get Tools , World menu, etc.
The final product could have a "programmer mode" (Morphic)?
Could the Squeakland people have interest in OLPC to 3.10 and 3.10 to OLPC way of loading things ?
Edgar
On Apr 3, 2007, at 13:53 , Edgar J. De Cleene wrote:
El 4/3/07 8:44 AM, "Bert Freudenberg" bert@freudenbergs.de escribió:
Edgar is right about that one - when loading a .pr in a newer image you can do all sorts of adjustments to make it work. This works in the Squeakland line of images for example - but it takes dedicated efforts to ensure loadability.
- Bert -
Bert you always inspire me , as all what Squeakland do
I got the etoys-2.0-1217.image , but I can found any way of get Tools , World menu, etc.
It's hidden - press Cmd-Shift-W.
The final product could have a "programmer mode" (Morphic)?
Actually we do think about this, yes. Our original thinking was to avoid support issues - if we only expose etoys and not the Smalltalk browser, we only need to worry about etoys, and not about generic smalltalk stuff. Besides, the OLPC folks want kids to switch from Etoys to Python once they are older and we do not want to interfere with that goal.
However, it would be a waste to completely hide the power of Smalltalk. We want to hide it a little bit so as to not confuse beginners, but it should be possible. There are problems however - etoys projects are not ideal for dealing with source code for one. So ideas and contributions are appreciated.
Could the Squeakland people have interest in OLPC to 3.10 and 3.10 to OLPC way of loading things ?
Interest yes, but we don't have any resources to spare for this, unfortunately.
- Bert -
El 4/3/07 1:27 PM, "Bert Freudenberg" bert@freudenbergs.de escribió:
It's hidden - press Cmd-Shift-W.
Wooooow. A very nice collection of stuff.... Some of this is new to me.
Besides, the OLPC folks want kids to switch from Etoys to Python once they are older and we do not want to interfere with that goal.
Very sad to know they don't believe in Smalltalk.
Interest yes, but we don't have any resources to spare for this, unfortunately.
- Bert -
Once what 3.10 was in beta could you have time to supervise me like Ralph do now ?
Edgar
Edgar,
Interest yes, but we don't have any resources to spare for this, unfortunately.
- Bert -
Once what 3.10 was in beta could you have time to supervise me like Ralph do now ?
For the "interest" part, I'm writing an externalization scheme for EToys that doesn't so much depend on the internal structure of Squeak objects. This is more portable than current ImageSegment.
The main purpose of this is to carry Etoys contents beyond Squeak, but for among different Squeak versions, this externalized format should help to get projects migrated.
-- Yoshiki
El 4/6/07 7:11 PM, "Yoshiki Ohshima" yoshiki@squeakland.org escribió:
Edgar,
Interest yes, but we don't have any resources to spare for this, unfortunately.
- Bert -
Once what 3.10 was in beta could you have time to supervise me like Ralph do now ?
For the "interest" part, I'm writing an externalization scheme for EToys that doesn't so much depend on the internal structure of Squeak objects. This is more portable than current ImageSegment.
The main purpose of this is to carry Etoys contents beyond Squeak, but for among different Squeak versions, this externalized format should help to get projects migrated.
-- Yoshiki
If you could share any docs, or perhaps you do the coaching, I wish know. I addressing Bert for he is advising on the 3dot10 list and have huge experience.
Regards.
Edgar
On 2007 April 3 12:27, Bert Freudenberg wrote:
On Apr 3, 2007, at 13:53 , Edgar J. De Cleene wrote:
<<...>>
The final product could have a "programmer mode" (Morphic)?
Actually we do think about this, yes. Our original thinking was to avoid support issues - if we only expose etoys and not the Smalltalk browser, we only need to worry about etoys, and not about generic smalltalk stuff. Besides, the OLPC folks want kids to switch from Etoys to Python once they are older and we do not want to interfere with that goal.
How very disappointing .... this is not the first time I understand politics, not results, are driving the OLPC software future. So instead of "kids first" we will have "python first". There is of course, absolutely nothing wrong with competition, but for some to advocate Python to the point that others feel they need to step back and not do the best their language and environment can do, and hide it, that is wrong. (Especially without proven results in python based child education such as eToys have.)
In the 90's I often heard in business "we are a VB shop, so we do not do (Java, C++, whatever) projects" and I hated it, but to find it in a project that should be above this, that is sad.
Milan
However, it would be a waste to completely hide the power of Smalltalk. We want to hide it a little bit so as to not confuse beginners, but it should be possible. There are problems however - etoys projects are not ideal for dealing with source code for one. So ideas and contributions are appreciated.
Could the Squeakland people have interest in OLPC to 3.10 and 3.10 to OLPC way of loading things ?
Interest yes, but we don't have any resources to spare for this, unfortunately.
- Bert -
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Hi,
Milan Zimmermann escribió:
On 2007 April 3 12:27, Bert Freudenberg wrote:
On Apr 3, 2007, at 13:53 , Edgar J. De Cleene wrote:
<<...>>
The final product could have a "programmer mode" (Morphic)?
Actually we do think about this, yes. Our original thinking was to avoid support issues - if we only expose etoys and not the Smalltalk browser, we only need to worry about etoys, and not about generic smalltalk stuff. Besides, the OLPC folks want kids to switch from Etoys to Python once they are older and we do not want to interfere with that goal.
How very disappointing .... this is not the first time I understand politics, not results, are driving the OLPC software future. So instead of "kids first" we will have "python first". There is of course, absolutely nothing wrong with competition, but for some to advocate Python to the point that others feel they need to step back and not do the best their language and environment can do, and hide it, that is wrong. (Especially without proven results in python based child education such as eToys have.)
In the 90's I often heard in business "we are a VB shop, so we do not do (Java, C++, whatever) projects" and I hated it, but to find it in a project that should be above this, that is sad.
Milan
Yep its very disappointing and sad. I think that Squeak needs to be less "self contained" and play nicely and more transparently with other languages/environments, but the idea it to make bridges instead of "this or that but not both" decisions, at least in place where inclusion makes sense. I have been using Squeak with my students and going from eToys to Bots Inc to Smalltalk is a nice path in the learning of informatics and the use of computers as a media for learning and expressing powerful ideas (at this point would be nice to thing in bridges between Smalltalk and other languages, like python). ¿Who are this OLPC folks and why they decide for us?, I mean, if this project it's for improving education on "developing nations", we, the people who live in that nations, wouldn't be the ones who are taking an active part on the decisions instead of being passive receptors of others silent decisions?
XO machines need to mature with the children as the time goes on, and continuity is a key factor on that. We need bridges instead of abyss, inclusion instead of exclusion.
Cheers,
Offray
On Apr 8, 2007, at 19:17 , Offray Vladimir Luna Cárdenas wrote:
Hi,
Milan Zimmermann escribió:
On 2007 April 3 12:27, Bert Freudenberg wrote:
On Apr 3, 2007, at 13:53 , Edgar J. De Cleene wrote:
<<...>>
The final product could have a "programmer mode" (Morphic)?
Actually we do think about this, yes. Our original thinking was to avoid support issues - if we only expose etoys and not the Smalltalk browser, we only need to worry about etoys, and not about generic smalltalk stuff. Besides, the OLPC folks want kids to switch from Etoys to Python once they are older and we do not want to interfere with that goal.
How very disappointing .... this is not the first time I understand politics, not results, are driving the OLPC software future. So instead of "kids first" we will have "python first". There is of course, absolutely nothing wrong with competition, but for some to advocate Python to the point that others feel they need to step back and not do the best their language and environment can do, and hide it, that is wrong. (Especially without proven results in python based child education such as eToys have.)
In the 90's I often heard in business "we are a VB shop, so we do not do (Java, C++, whatever) projects" and I hated it, but to find it in a project that should be above this, that is sad.
Milan
Yep its very disappointing and sad. I think that Squeak needs to be less "self contained" and play nicely and more transparently with other languages/environments, but the idea it to make bridges instead of "this or that but not both" decisions, at least in place where inclusion makes sense. I have been using Squeak with my students and going from eToys to Bots Inc to Smalltalk is a nice path in the learning of informatics and the use of computers as a media for learning and expressing powerful ideas (at this point would be nice to thing in bridges between Smalltalk and other languages, like python). ¿Who are this OLPC folks and why they decide for us?, I mean, if this project it's for improving education on "developing nations", we, the people who live in that nations, wouldn't be the ones who are taking an active part on the decisions instead of being passive receptors of others silent decisions?
XO machines need to mature with the children as the time goes on, and continuity is a key factor on that. We need bridges instead of abyss, inclusion instead of exclusion.
Agreed. But, as I wrote before:
However, it would be a waste to completely hide the power of Smalltalk. We want to hide it a little bit so as to not confuse beginners, but it should be possible. There are problems however - etoys projects are not ideal for dealing with source code for one. So ideas and contributions are appreciated.
So everybody interested in making the "Smalltalk experience" on the OLPC machine an enjoyable one, please help. The VPRI group focuses on etoys and system integration, but you are invited to contribute. And, in case this has not been clear, you do *not* need an OLPC prototype to run this. It's Squeak, after all.
- Bert -
Hi,
Bert Freudenberg escribió:
On Apr 8, 2007, at 19:17 , Offray Vladimir Luna Cárdenas wrote:
[...]
XO machines need to mature with the children as the time goes on, and continuity is a key factor on that. We need bridges instead of abyss, inclusion instead of exclusion.
Agreed. But, as I wrote before:
However, it would be a waste to completely hide the power of Smalltalk. We want to hide it a little bit so as to not confuse beginners, but it should be possible. There are problems however - etoys projects are not ideal for dealing with source code for one. So ideas and contributions are appreciated.
So everybody interested in making the "Smalltalk experience" on the OLPC machine an enjoyable one, please help. The VPRI group focuses on etoys and system integration, but you are invited to contribute. And, in case this has not been clear, you do *not* need an OLPC prototype to run this. It's Squeak, after all.
I'm already helping. I have the OLPC image running on my laptop and we're making test (one problem is that the content generated on larger and different aspect ratio displays gets messed on the machine, as we already tested, and we reported a bug with bookmarks on the Squeak beginner list that was patched for OLPC and we test the patch on other Squeak images). Next thing that we're going to probe is some interactive content (fables and child tales) made, may be on Scratch in the same sense of "Speak Up" projects (we'll see how this is supported by the display) and we're going to test how to pass from eToys to Bots Inc in the OLPC image (or may be having alternative images... I don't know yet). I was not criticizing the VPRI focus and I understand the lack of resources and need for volunteer effort, I was talking about "from eToys to python" silent decision without any continuity and reflection from the people who will be using the machines.
Cheers,
Offray
On 2007 April 8 13:30, Bert Freudenberg wrote:
So everybody interested in making the "Smalltalk experience" on the OLPC machine an enjoyable one, please help. The VPRI group focuses on etoys and system integration, but you are invited to contribute. And, in case this has not been clear, you do *not* need an OLPC prototype to run this.
Some instructions on how to run OLPC version of eToys (and squeak) on your system :
http://wiki.laptop.org/go/Etoys#Running_OLPC_eToys_if_you_do_not_have_OLPC_l...
Milan
It's Squeak, after all.
- Bert -
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Hi!
Bert Freudenberg bert@freudenbergs.de wrote:
On Apr 3, 2007, at 11:25 , Edgar J. De Cleene wrote:
El 4/3/07 5:08 AM, "Herbert König" herbertkoenig@gmx.net escribió:
Be aware that imho 3.8 and earlier projects don't load into 3.9. But I guess projects will be continued, at least in the squeakland image, for very long.
You and Góran are wrong.
Some 3.7 and 3.8 projects loads into 3.9 (and 3.10 also) Those what don't load , if you take time could find what change between versions and do what load again.
I resurrect MorphicWrappers and MathMorphs from as old as 2.1 !! (some parts) and success to load Fabrik from last images what have it into 3.10.
My plans is when we reach 3.10beta is rip the Etoys and Nebraska from 3.10 for have proper .mcz what loads again, and possible do a "compatibility guesser" what could load older things. At this time 3.10 have problems with Etoys .pr from earlier versions.
Edgar is right about that one - when loading a .pr in a newer image you can do all sorts of adjustments to make it work. This works in the Squeakland line of images for example - but it takes dedicated efforts to ensure loadability.
Ok, perhaps I should have expressed myself a bit clearer - I wrote "not inherently backwards compatible" which still is true IMHO - and especially the other way around (loading say a 3.8 IS into a 3.7 image).
And I said "For example, loading projects from 3.7 into 3.8 causes problems (due to the new wide String stuff).". That was not correctly expressed. First of all I meant the other way around and secondly I agree that it doesn't HAVE to fail.
regards, Göran
beginners@lists.squeakfoundation.org
-
Andrew Dabrowski -
Bert Freudenberg -
Edgar J. De Cleene -
goran＠krampe.se -
Herbert König -
Milan Zimmermann -
Offray Vladimir Luna Cárdenas -
Yoshiki Ohshima