The new etoys package is in builds starting at 537, please test thoroughly. In particular downloading projects and running them, and saving and loading projects from journal.
I'm not sure if the Sugar fix for resuming went into this build, if not, you could apply it manually:
http://dev.laptop.org/ticket/2477
Hopefully everything works and we can leave it at that for Trial-2.
I'm a bit concerned about the UI which may be confusing to kids. To fit better with Sugar, we might want to remove the "load" button, and possibly the "prev" button, too (at least for "user-made" projects). At least load and save should not show the normal file directories but only the journal, and save actually could skip the directory choosing dialog completely.
If we change the buttons, we might also update them to use the new icons (the design was changed this week to have gray outlines with white fill). Also the share button should change its appearance once shared ... guess that will have to wait, we need a better idea for sharing for trial-3 anyway.
- Bert -
Hello,
I found a mysterious phenomenon in #537.
1. paint something with a paint activity and keep it. 2. open a journal and click the activity of above painting. 3. click 'Copy to clipboard' icon on the top. 4. choose 'Open' from a clipboard menu for this image on the left. 5. Etoys startup automatically and failed to load. (see attached log)
I don't know this phenomenon is related with your ticket #2477 or not.
Best regards, Kazuhiro Abe
On Jul 27, 2007, at 14:30 , Kazuhiro ABE wrote:
Hello,
I found a mysterious phenomenon in #537.
- paint something with a paint activity and keep it.
- open a journal and click the activity of above painting.
- click 'Copy to clipboard' icon on the top.
- choose 'Open' from a clipboard menu for this image on the left.
- Etoys startup automatically and failed to load. (see attached log)
I don't know this phenomenon is related with your ticket #2477 or not.
No, #2477 would prevent etoys from even starting. Apparently this is indeed what happens, if you just press the resume button when showing an etoys entry in the journal (that round button with a square in the tool bar) then etoys does not start. Tonight's next build should have that fixed, or patch the file /usr/lib/python2.5/site-packages/sugar/ activity/activityfactory.py yourself as in the ticket.
Anyway, your find is indeed an etoys bug. It appears as if the clipboard thinks that Etoys is the default activity for handling PNG files. And it then of course runs Etoys with that argument ... never thought of that. We then try to load that png file as project which fails of course.
We should check the mime-type when resuming a journal entry, and if it is not a squeak project, invoke the drop handler instead I guess, so we open the the file. Presumably we want to do that in a newly created project?
I'm reporting this as a bug here:
http://dev.laptop.org/ticket/2535
Thanks for testing, and reporting back!
- Bert -
On Jul 26, 2007, at 22:55 , Bert Freudenberg wrote:
The new etoys package is in builds starting at 537, please test thoroughly. In particular downloading projects and running them, and saving and loading projects from journal.
I'm not sure if the Sugar fix for resuming went into this build, if not, you could apply it manually:
http://dev.laptop.org/ticket/2477
Hopefully everything works and we can leave it at that for Trial-2.
I'm a bit concerned about the UI which may be confusing to kids. To fit better with Sugar, we might want to remove the "load" button, and possibly the "prev" button, too (at least for "user-made" projects). At least load and save should not show the normal file directories but only the journal, and save actually could skip the directory choosing dialog completely.
If we change the buttons, we might also update them to use the new icons (the design was changed this week to have gray outlines with white fill). Also the share button should change its appearance once shared ... guess that will have to wait, we need a better idea for sharing for trial-3 anyway.
Anyone objecting to removing/disabling the load button if we run in Sugar (that is, "SugarLauncher isRunningInSugar" is true)?
And for not showing a file dialog but always keeping in Journal if we run in Sugar?
If not, could Yoshiki or whoever used to fix the toolbar do this and push an update?
- Bert -
Bert,
Anyone objecting to removing/disabling the load button if we run in Sugar (that is, "SugarLauncher isRunningInSugar" is true)?
And for not showing a file dialog but always keeping in Journal if we run in Sugar?
If not, could Yoshiki or whoever used to fix the toolbar do this and push an update?
I'll give it a shot.
-- Yoshiki
Hello,
I think we should keep the load button in any mode. I like the activity-stop-resume cycle, I think kids may accept this concept. But sometimes projects aren't build in time series. For example, we should have a method to load example and tutorial projects without journal. Also we need to access external server such like a SuperSwiki. It suits for Etoys slogan, 'build and share'.
Best regards, Kazuhiro Abe
On Fri, 27 Jul 2007 19:10:35 +0200 Bert Freudenberg bert@freudenbergs.de wrote:
Anyone objecting to removing/disabling the load button if we run in Sugar (that is, "SugarLauncher isRunningInSugar" is true)?
And for not showing a file dialog but always keeping in Journal if we run in Sugar?
If not, could Yoshiki or whoever used to fix the toolbar do this and push an update?
I now think that load button itself is ok. For the normal click, we can still show the same dialog but just select "Projects in Journal". Since "Keep" is a concept that will be around, there is not much reason for it to be confusing. We can show the button-hold menu to choose more projects (if it will be possible).
BTW, "Projects in Journal" shows all version of the project. Should it show only the latest (by default)?
-- Yoshiki
I think we should keep the load button in any mode. I like the activity-stop-resume cycle, I think kids may accept this concept. But sometimes projects aren't build in time series. For example, we should have a method to load example and tutorial projects without journal. Also we need to access external server such like a SuperSwiki. It suits for Etoys slogan, 'build and share'.
Best regards, Kazuhiro Abe
On Fri, 27 Jul 2007 19:10:35 +0200 Bert Freudenberg bert@freudenbergs.de wrote:
Anyone objecting to removing/disabling the load button if we run in Sugar (that is, "SugarLauncher isRunningInSugar" is true)?
And for not showing a file dialog but always keeping in Journal if we run in Sugar?
If not, could Yoshiki or whoever used to fix the toolbar do this and push an update?
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
On Jul 27, 2007, at 20:21 , Yoshiki Ohshima wrote:
I now think that load button itself is ok. For the normal click, we can still show the same dialog but just select "Projects in Journal". Since "Keep" is a concept that will be around, there is not much reason for it to be confusing. We can show the button-hold menu to choose more projects (if it will be possible).
Yes, that's what I thought, too.
BTW, "Projects in Journal" shows all version of the project. Should it show only the latest (by default)?
I thought it only showed the latest version? Although ... thinking about it, when you load a project from the Load dialog, its #sugarId parameter does not get set. That means when saving, another entry will be made in the Journal, rather than updating the existing entry. This is a bug, but I can't really do much about it I guess.
This comes from SugarDatastoreDirectory which has to fake filenames. The datastore does not retain filenames, so we make up a filename by taking the title+uid+'.pr'. When someone tries to open that file, we extract the uid and load the file from the datastore. It has to be deleted when done, that's why it returns a SugarDatastoreTempFile which deletes the actual file on #close.
As you can see this is a major hack. It's extremely ugly to see those uids in the list ... I hope we will find a better way to integrate with the journal, while still preserving the ability to handle projects on a regular machine.
- Bert -
-- Yoshiki
I think we should keep the load button in any mode. I like the activity-stop-resume cycle, I think kids may accept this concept. But sometimes projects aren't build in time series. For example, we should have a method to load example and tutorial projects without journal. Also we need to access external server such like a SuperSwiki. It suits for Etoys slogan, 'build and share'.
Best regards, Kazuhiro Abe
On Fri, 27 Jul 2007 19:10:35 +0200 Bert Freudenberg bert@freudenbergs.de wrote:
Anyone objecting to removing/disabling the load button if we run in Sugar (that is, "SugarLauncher isRunningInSugar" is true)?
And for not showing a file dialog but always keeping in Journal if we run in Sugar?
If not, could Yoshiki or whoever used to fix the toolbar do this and push an update?
Bert,
At Fri, 27 Jul 2007 21:49:06 +0200, Bert Freudenberg wrote:
On Jul 27, 2007, at 20:21 , Yoshiki Ohshima wrote:
I now think that load button itself is ok. For the normal click, we can still show the same dialog but just select "Projects in Journal". Since "Keep" is a concept that will be around, there is not much reason for it to be confusing. We can show the button-hold menu to choose more projects (if it will be possible).
Yes, that's what I thought, too.
At least, the dialog shouldn't show the update stream server directory. I published a change set to hide it. ExampleEtoys directory doesn't have to be shown now because of the Gallery of projects. If you remove the file in prefs directory, that will be gone.
-- Yoshiki
Hello,
On Thu, 26 Jul 2007 22:55:08 +0200 Bert Freudenberg bert@freudenbergs.de wrote:
If we change the buttons, we might also update them to use the new icons (the design was changed this week to have gray outlines with white fill).
I painted new look icons and sent them to Ohshima-san. He will integrate them.
Best regards, Kazuhuro Abe
Bert and Abe san,
I pushed a change set to etoys 2.0 stream. But these buttons are now ******* uglier than before. I'm now tempting to revert them to the previous versions, including the stop button...
-- Yoshiki
At Sat, 28 Jul 2007 18:32:31 +0900, Kazuhiro ABE wrote:
Hello,
On Thu, 26 Jul 2007 22:55:08 +0200 Bert Freudenberg bert@freudenbergs.de wrote:
If we change the buttons, we might also update them to use the new icons (the design was changed this week to have gray outlines with white fill).
I painted new look icons and sent them to Ohshima-san. He will integrate them.
Best regards, Kazuhuro Abe _______________________________________________ Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
Hello,
On Sat, 28 Jul 2007 18:46:24 -0700 Yoshiki Ohshima yoshiki@squeakland.org wrote:
I pushed a change set to etoys 2.0 stream. But these buttons are now ******* uglier than before. I'm now tempting to revert them to the previous versions, including the stop button...
I agree. I love the previous look. I confuse the gray border means disable function.
Kazuhiro Abe
Well, ugly or not, consistency with other apps is more important. You could file a ticket about the look ...
- Bert -
On Jul 29, 2007, at 3:46 , Yoshiki Ohshima wrote:
Bert and Abe san,
I pushed a change set to etoys 2.0 stream. But these buttons are now ******* uglier than before. I'm now tempting to revert them to the previous versions, including the stop button...
-- Yoshiki
At Sat, 28 Jul 2007 18:32:31 +0900, Kazuhiro ABE wrote:
Hello,
On Thu, 26 Jul 2007 22:55:08 +0200 Bert Freudenberg bert@freudenbergs.de wrote:
If we change the buttons, we might also update them to use the new icons (the design was changed this week to have gray outlines with white fill).
I painted new look icons and sent them to Ohshima-san. He will integrate them.
Best regards, Kazuhuro Abe _______________________________________________ Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
Well, ugly or not, consistency with other apps is more important. You could file a ticket about the look ...
Sure, I did file a ticket. So far, we'll keep the icons look same, and I'll probably add a text area that shows the current project name in the title (Abe-san's suggestion), but I would really hesitate to add the tabs under the bar that take even more space and distracting. Since Watch and Listen took liberty to make a mode to eliminate the bar, a better UI for us to control the positioning and color of the bar would be acceptable...
-- Yoshiki
On Jul 29, 2007, at 21:41 , Yoshiki Ohshima wrote:
Well, ugly or not, consistency with other apps is more important. You could file a ticket about the look ...
Sure, I did file a ticket. So far, we'll keep the icons look same, and I'll probably add a text area that shows the current project name in the title (Abe-san's suggestion), but I would really hesitate to add the tabs under the bar that take even more space and distracting. Since Watch and Listen took liberty to make a mode to eliminate the bar, a better UI for us to control the positioning and color of the bar would be acceptable...
Agreed. And we have a lot bigger fish to fry ...
- Bert -
etoys-dev@lists.squeakfoundation.org