I noticed yesterday that Yoshiki updated the FishAndPlankton example project a year ago in the Sugar release, but that was still not in the Squeakland repository. Same for the Guides and translations, which were not updated for quite some time. Conversely, the launcher/ tutorials/demo projects were only updated in the Squeakland repository.
I (manually) synced the two repositories on Sunday but we need to find a way to only have one repo, really.
I think the Sugar release and Squeakland release are virtually indistinguishable now, right? Off the top of my head the only difference is the swapControlAndAltKeys preference, which is enabled for Sugar but not for Squeakland. But we really should set this to the platform default anyway:
http://tracker.squeakland.org/browse/SQ-304
Other than for that, do we still need two different release images? Or can we simply share the whole image folder now?
- Bert -
On Aug 31, 2009, at 6:05 AM, Bert Freudenberg wrote:
I noticed yesterday that Yoshiki updated the FishAndPlankton example project a year ago in the Sugar release, but that was still not in the Squeakland repository. Same for the Guides and translations, which were not updated for quite some time. Conversely, the launcher/ tutorials/demo projects were only updated in the Squeakland repository.
I (manually) synced the two repositories on Sunday but we need to find a way to only have one repo, really.
I think the Sugar release and Squeakland release are virtually indistinguishable now, right? Off the top of my head the only difference is the swapControlAndAltKeys preference, which is enabled for Sugar but not for Squeakland. But we really should set this to the platform default anyway:
http://tracker.squeakland.org/browse/SQ-304
Other than for that, do we still need two different release images? Or can we simply share the whole image folder now?
If there's no need, let's merge (please!)
Could be another Big Feature of Etoys 4.0 ... back under the same roof again. (again, this sends a message for people to stop looking for OLPC)
We of course need to update the OLPC wiki with newest info:
http://tracker.squeakland.org/browse/SQ-36
Tim
At Mon, 31 Aug 2009 12:05:21 +0200, Bert Freudenberg wrote:
I think the Sugar release and Squeakland release are virtually indistinguishable now, right? Off the top of my head the only difference is the swapControlAndAltKeys preference, which is enabled for Sugar but not for Squeakland. But we really should set this to the platform default anyway:
http://tracker.squeakland.org/browse/SQ-304
Other than for that, do we still need two different release images? Or can we simply share the whole image folder now?
The different is only preferences and currently the following are the difference (written in #chicago method):
(sugarNavigator true) (swapControlAndAltKeys false) (unlimitedPaintArea true) (useArtificialSweetenerBar true) (usePopUpArrows false)
The navigator's buttons may still have to be different to conform the Sugar's strange document model. PopUpArrows is not-so-effective workaround for the XO's touch pad. Unlimited paint area can be off.
-- Yoshiki
On Monday 31 Aug 2009 10:39:20 pm Yoshiki Ohshima wrote:
The different is only preferences and currently the following are the difference (written in #chicago method): .. (useArtificialSweetenerBar true)
This is a noop in the current version. I liked the greenbar better than the Sugar bar :-(.
Subbu
On 31.08.2009, at 19:09, Yoshiki Ohshima wrote:
At Mon, 31 Aug 2009 12:05:21 +0200, Bert Freudenberg wrote:
I think the Sugar release and Squeakland release are virtually indistinguishable now, right? Off the top of my head the only difference is the swapControlAndAltKeys preference, which is enabled for Sugar but not for Squeakland. But we really should set this to the platform default anyway:
http://tracker.squeakland.org/browse/SQ-304
Other than for that, do we still need two different release images? Or can we simply share the whole image folder now?
The different is only preferences and currently the following are the difference (written in #chicago method):
(sugarNavigator true) (swapControlAndAltKeys false) (unlimitedPaintArea true) (useArtificialSweetenerBar true) (usePopUpArrows false)The navigator's buttons may still have to be different to conform the Sugar's strange document model.
Can't we enable that on startup?
PopUpArrows is not-so-effective workaround for the XO's touch pad.
But since scaling is on we should enable them anyway? Or just under Sugar? In any case that could be done at startup as well.
Unlimited paint area can be off.
In fact it must be off - that's what causes the Welcome demo to fail. Or can we force it for that specific project?
- Bert -
At Mon, 31 Aug 2009 20:20:42 +0200, Bert Freudenberg wrote:
The navigator's buttons may still have to be different to conform the Sugar's strange document model.
Can't we enable that on startup?
Ah, yes. That is an idea.
PopUpArrows is not-so-effective workaround for the XO's touch pad.
But since scaling is on we should enable them anyway? Or just under Sugar? In any case that could be done at startup as well.
Yes.
Unlimited paint area can be off.
In fact it must be off - that's what causes the Welcome demo to fail. Or can we force it for that specific project?
I never figured out how the project local preferences work. Come to think of it, we probably should stick to limited paint area for XO, including XO 1.5, and Squeakland.
-- Yoshiki
On 31.08.2009, at 20:31, Yoshiki Ohshima wrote:
At Mon, 31 Aug 2009 20:20:42 +0200, Bert Freudenberg wrote:
The navigator's buttons may still have to be different to conform the Sugar's strange document model.
Can't we enable that on startup?
Ah, yes. That is an idea.
PopUpArrows is not-so-effective workaround for the XO's touch pad.
But since scaling is on we should enable them anyway? Or just under Sugar? In any case that could be done at startup as well.
Yes.
Unlimited paint area can be off.
In fact it must be off - that's what causes the Welcome demo to fail. Or can we force it for that specific project?
I never figured out how the project local preferences work. Come to think of it, we probably should stick to limited paint area for XO, including XO 1.5, and Squeakland.
Could you do that? I'm somewhat lost in the ReleaseBuilder maze - there seem to be lots of methods doing the same thing, and others not being called at all. And do we need all these themes? Redefine chicago? Add a new city? ... I'll attach what I have so far:
"Change Set: releaseSpecifics-bf Date: 31 August 2009 Author: Bert Freudenberg
- fix update stream URL - fix default font size - set SystemVersion date when doing a release"
And maybe we should integrate some stuff I put in the external release script until now:
http://svn.squeakland.org/installers/buildImage.st
- Bert -
At Mon, 31 Aug 2009 20:53:42 +0200, Bert Freudenberg wrote:
Could you do that? I'm somewhat lost in the ReleaseBuilder maze - there seem to be lots of methods doing the same thing, and others not being called at all. And do we need all these themes? Redefine chicago? Add a new city? ... I'll attach what I have so far:
- fix update stream URL
Did we agree on to re-instate the update stream? (especially the developers' etoys update stream/)
- fix default font size
- set SystemVersion date when doing a release"
And maybe we should integrate some stuff I put in the external release script until now:
This .st or some parts of it should be in the image as a method.
-- Yoshiki
On 01.09.2009, at 00:23, Yoshiki Ohshima wrote:
At Mon, 31 Aug 2009 20:53:42 +0200, Bert Freudenberg wrote:
Could you do that? I'm somewhat lost in the ReleaseBuilder maze - there seem to be lots of methods doing the same thing, and others not being called at all. And do we need all these themes? Redefine chicago? Add a new city? ... I'll attach what I have so far:
- fix update stream URL
Did we agree on to re-instate the update stream? (especially the developers' etoys update stream/)
No, but did you simply want to leave it broken because of the wrong URL? If we want to disable it then properly I thought ...
- fix default font size
- set SystemVersion date when doing a release"
And maybe we should integrate some stuff I put in the external release script until now:
This .st or some parts of it should be in the image as a method.
That's what I meant :)
Not quite sure how much of it though.
- Bert -
At Tue, 1 Sep 2009 00:29:26 +0200, Bert Freudenberg wrote:
On 01.09.2009, at 00:23, Yoshiki Ohshima wrote:
At Mon, 31 Aug 2009 20:53:42 +0200, Bert Freudenberg wrote:
Could you do that? I'm somewhat lost in the ReleaseBuilder maze - there seem to be lots of methods doing the same thing, and others not being called at all. And do we need all these themes? Redefine chicago? Add a new city? ... I'll attach what I have so far:
- fix update stream URL
Did we agree on to re-instate the update stream? (especially the developers' etoys update stream/)
No, but did you simply want to leave it broken because of the wrong URL? If we want to disable it then properly I thought ...
Well, it just says "0 new update(s)", which was thought to be a correct behavior, and if somebody really would like to put some critical patches in the stream, "squeakland" one was meant to be the place.
- fix default font size
- set SystemVersion date when doing a release"
And maybe we should integrate some stuff I put in the external release script until now:
This .st or some parts of it should be in the image as a method.
That's what I meant :)
Ah, I see^^;
Not quite sure how much of it though.
Compiling a method certainly looks strange.
Could be just:
DisplayScreen primitiveWindowSize: 1 width: 800 heigth: 600.
World submorphs do: [:m | m isSystemWindow ifTrue: [m delete]]. ReleaseBuilderSqueakland new updateAll; prepareReleaseImageForSqueakland; buildInitialScreenForSqueakland. ] valueSuppressingAllMessages.
CursorWithAlpha allInstancesDo: [:c | c == CursorWithAlpha biggerNormal ifFalse: [c becomeForward: CursorWithAlpha biggerNormal]].
WorldState addDeferredUIMessage: [ SmalltalkImage current snapshot: true andQuit: true. ]
(Hmm, with 3.11.3 beta Windows VM, it still doesn't resize...)
-- Yoshiki
On 01.09.2009, at 00:43, Yoshiki Ohshima wrote:
At Tue, 1 Sep 2009 00:29:26 +0200, Bert Freudenberg wrote:
On 01.09.2009, at 00:23, Yoshiki Ohshima wrote:
At Mon, 31 Aug 2009 20:53:42 +0200, Bert Freudenberg wrote:
Could you do that? I'm somewhat lost in the ReleaseBuilder maze - there seem to be lots of methods doing the same thing, and others not being called at all. And do we need all these themes? Redefine chicago? Add a new city? ... I'll attach what I have so far:
- fix update stream URL
Did we agree on to re-instate the update stream? (especially the developers' etoys update stream/)
No, but did you simply want to leave it broken because of the wrong URL? If we want to disable it then properly I thought ...
Well, it just says "0 new update(s)", which was thought to be a correct behavior, and if somebody really would like to put some critical patches in the stream, "squeakland" one was meant to be the place.
I missed that discussion apparently.
- fix default font size
- set SystemVersion date when doing a release"
And maybe we should integrate some stuff I put in the external release script until now:
This .st or some parts of it should be in the image as a method.
That's what I meant :)
Ah, I see^^;
Not quite sure how much of it though.
Compiling a method certainly looks strange.
Could be just:
DisplayScreen primitiveWindowSize: 1 width: 800 heigth: 600.
It was meant to be used on a not updated toys-dev image, which does not have these methods yet.
World submorphs do: [:m | m isSystemWindow ifTrue: [m delete]]. ReleaseBuilderSqueakland new updateAll; prepareReleaseImageForSqueakland; buildInitialScreenForSqueakland. ] valueSuppressingAllMessages.
In prepareReleaseImageForOLPC the buildInitialScreen call is already included ...
CursorWithAlpha allInstancesDo: [:c | c == CursorWithAlpha biggerNormal ifFalse: [c becomeForward: CursorWithAlpha biggerNormal]].
And this should maybe get put into an update.
WorldState addDeferredUIMessage: [ SmalltalkImage current snapshot: true andQuit: true. ]
And is that the right way to save? I wasn't sure, but I did not want to snapshot from within the file-in code.
(Hmm, with 3.11.3 beta Windows VM, it still doesn't resize...)
Works on the Mac. Does Win have the HostWindowPlugin? I though it did since the window title gets changed, doesn't it?
- Bert -
At Tue, 1 Sep 2009 01:04:18 +0200, Bert Freudenberg wrote:
WorldState addDeferredUIMessage: [ SmalltalkImage current snapshot: true andQuit: true. ]
And is that the right way to save? I wasn't sure, but I did not want to snapshot from within the file-in code.
I looked at it and couldn't think of any potential pitfall, (especially when there is no ticking script or anything).
(Hmm, with 3.11.3 beta Windows VM, it still doesn't resize...)
Works on the Mac. Does Win have the HostWindowPlugin? I though it did since the window title gets changed, doesn't it?
Windows VM has HostWindowPlugin in the built in modules list. Changing the title doesn't work and I can't remember seeing it worked.
-- Yoshiki
On 01.09.2009, at 16:51, Yoshiki Ohshima wrote:
At Tue, 1 Sep 2009 01:04:18 +0200, Bert Freudenberg wrote:
(Hmm, with 3.11.3 beta Windows VM, it still doesn't resize...)
Works on the Mac. Does Win have the HostWindowPlugin? I though it did since the window title gets changed, doesn't it?
Windows VM has HostWindowPlugin in the built in modules list. Changing the title doesn't work and I can't remember seeing it worked.
Try using window index 0 then.
- Bert -
On 01.09.2009, at 01:04, Bert Freudenberg wrote:
On 01.09.2009, at 00:43, Yoshiki Ohshima wrote:
At Tue, 1 Sep 2009 00:29:26 +0200, Bert Freudenberg wrote:
On 01.09.2009, at 00:23, Yoshiki Ohshima wrote:
At Mon, 31 Aug 2009 20:53:42 +0200, Bert Freudenberg wrote:
Could you do that? I'm somewhat lost in the ReleaseBuilder maze - there seem to be lots of methods doing the same thing, and others not being called at all. And do we need all these themes? Redefine chicago? Add a new city? ... I'll attach what I have so far:
- fix update stream URL
Did we agree on to re-instate the update stream? (especially the developers' etoys update stream/)
No, but did you simply want to leave it broken because of the wrong URL? If we want to disable it then properly I thought ...
Well, it just says "0 new update(s)", which was thought to be a correct behavior, and if somebody really would like to put some critical patches in the stream, "squeakland" one was meant to be the place.
I missed that discussion apparently.
- fix default font size
- set SystemVersion date when doing a release"
And maybe we should integrate some stuff I put in the external release script until now:
This .st or some parts of it should be in the image as a method.
That's what I meant :)
Ah, I see^^;
Not quite sure how much of it though.
Compiling a method certainly looks strange.
Could be just:
DisplayScreen primitiveWindowSize: 1 width: 800 heigth: 600.
It was meant to be used on a not updated toys-dev image, which does not have these methods yet.
World submorphs do: [:m | m isSystemWindow ifTrue: [m delete]]. ReleaseBuilderSqueakland new updateAll; prepareReleaseImageForSqueakland; buildInitialScreenForSqueakland. ] valueSuppressingAllMessages.
In prepareReleaseImageForOLPC the buildInitialScreen call is already included ...
CursorWithAlpha allInstancesDo: [:c | c == CursorWithAlpha biggerNormal ifFalse: [c becomeForward: CursorWithAlpha biggerNormal]].
And this should maybe get put into an update.
WorldState addDeferredUIMessage: [ SmalltalkImage current snapshot: true andQuit: true. ]
And is that the right way to save? I wasn't sure, but I did not want to snapshot from within the file-in code.
(Hmm, with 3.11.3 beta Windows VM, it still doesn't resize...)
Works on the Mac. Does Win have the HostWindowPlugin? I though it did since the window title gets changed, doesn't it?
Did you try 3.11.4 in the meantime?
And what about my other suggested changes above? Maybe we can at least fix the font size? ;)
- Bert -
On 08.09.2009, at 22:32, Bert Freudenberg wrote:
Maybe we can at least fix the font size? ;)
If so, please approve
http://tracker.squeakland.org/browse/SQ-336
- Bert -
At Tue, 8 Sep 2009 22:32:26 +0200, Bert Freudenberg wrote:
Did you try 3.11.4 in the meantime?
3.11.5 and Window title change is working.
And what about my other suggested changes above? Maybe we can at least fix the font size? ;)
Thank you for doing bunch, including this one!
-- Yoshiki
On 10.09.2009, at 14:17, Yoshiki Ohshima wrote:
At Tue, 8 Sep 2009 22:32:26 +0200, Bert Freudenberg wrote:
Did you try 3.11.4 in the meantime?
3.11.5 and Window title change is working.
Great! Care to update it in svn?
And what about my other suggested changes above? Maybe we can at least fix the font size? ;)
Thank you for doing bunch, including this one!
No problem ;) The font size change is in by now because it was not really controversial.
- Bert -
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
K. K. Subramaniam -
Timothy Falconer -
Yoshiki Ohshima