Re: [Sugar-devel] Design help needed for web applications within Sugar
On Tue, Aug 11, 2009 at 22:02, Gary C Marting...@garycmartin.com wrote: On 11 Aug 2009, at 18:25, Eben Eliason wrote: On Tue, Aug 11, 2009 at 1:13 PM, Lucian Branesculucian.brane...@gmail.com wrote: 2009/8/11 Simon Schampijer si...@schampijer.de: On 08/11/2009 12:14 PM, Lucian Branescu wrote: In fact, there is the option to install the SSB activity as well, http://dl.getdropbox.com/u/317039/create%20ssb.png Yes seen that. rgs on IRC suggested that the 'Keep in Journal' button could either save an offline version by itself or there could be a drop down with several options. Do you mean the activity keep button? Like the one in Write - where we have the options to save a richt text format or others? If yes - yeah that sounds like a good option actually. I'll go ahead and try to implement that, then. About modifying SSBs, right now all the tools for modification are inside the actul activity. I'd like to see modification of userscripts and userstyles done in 'View Source' (as well). Oh, yeah view source. Sounds interesting to me, too. We just need to make sure to not overload it. I mean editing text is easy. When it comes to changing the icon it gets more complicated, though. Perhaps the Sugar shell should allow users to change activity icons? It's an unfortunate fact that there is no activity suitable for creating SVG icons for Sugar. We need a Draw activity to fill this gap and compliment Paint... In any case, View Source already has Document view and Bundle view. We could either expand Document view to have a TreeView on the left like Bundle view or create a separate Editables view. I hesitate to overload the view source mechanism this way, actually. Should we instead be providing a seamless mechanism for modifying code, icons, etc. with other activities, so that users (eventually) have choices regarding their editors? View source is a logical step in the process, so we should certainly expose the ability to launch into editing from there, of course. I suppose an alternative argument can be made for the level of integration we could provide when editing within the view source dialog. If we could hook it up to have real-time effect on the running activity, so that making a change couldbe tested right away, that may make it worth doing... If View Source makes it to Edit Source, it could be reasonable to expect that if you do modify and then close the source editor you would raise an Activity like alert bar with something like Activity needs to re-start for changes to take effect (Discard changes) (Re- start activity). I understand that Guido van Rossum had some proposals for Sugar to pick up live Python edit changes, but I guess that's water long under the bridge now given current Sugar Labs resources. Didn't looked as something so ground breaking, I would say it's just waiting for someone to spend a weekend and come up with a prototype. Regards, Tomeu Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design help needed for web applications within Sugar
On 08/10/2009 11:56 PM, Lucian Branescu wrote: This a bit long-winded, but please bear with me. If you know my project, skip to the end. I've been working on Browse in the context of GSoC. http://wiki.sugarlabs.org/go/Webified Here's my blog http://honeyweb.wordpress.com and you can get the code from here http://git.sugarlabs.org/projects/browse/repos/webified. I can prepare an .xo bundle if needed. I've implemented Site Specific Browser creation and 'save complete page' functionality for Browse. An example of SSB is Mozilla Prism; Firefox has the option to save a page, complete with resources. Site Specific Browsers in Sugar are instances of Browse with a static home-page and a few extra capabilities, like bookmarklets, userscripts and userstyles (http://honeyweb.wordpress.com/2009/07/06/bookmarklets-userstyles-userscriptssort-of/). The web site loaded inside an SSB works just like it would normally, but it happens to be the default and it can be (easily) customised. This works very well for GMail, for example. In fact, I use GMail inside an SSB all the time (http://fluidapp.com). With Gears, you can even work with GMail offline. Saving a complete web page is useful for keeping a web page for offline viewing, of course. But for web apps with behaviour that does not depend on a having a network, they are similar in a way to SSBs. This would work very well for things like Karma lessons (see Felipe and Bryan's project http://karmaproject.wordpress.com/) and Paint Web http://code.google.com/p/paintweb/. Both ways produce a Journal object that can be run and opens a Browse instance with the desired web page, but they are very different technically. Both would be very useful and for different purposes, but they have some overlapping usage. How should these features be presented to the user? The screenshots on my blog show the current situation. So saving the current page, could be a button, like shown in the screenshot now. If we want to special case the SSB creation, it could be an option in the button palette. The SSB can be installed to the system as well. We want maybe an install option in the alert. And maybe there should be an install option from the journal as well. Activities we install directly when downloaded, we could handle it the same way, with the SSB as well. The entries could have a badged browse icon. To distinguish them from the rest of the Browse activity entries. When you click on an 'offline webpage' entry a Browse instance could be opened showing that entry. One could think about opening it in a new tab, when a Browse instance is already running, in the future. One thing that needs thinking as well is the modifying of the SSB (other icon etc). Maybe an activity could handle that? Maybe an option in a develop activity? Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design help needed for web applications within Sugar
In fact, there is the option to install the SSB activity as well, http://dl.getdropbox.com/u/317039/create%20ssb.png rgs on IRC suggested that the 'Keep in Journal' button could either save an offline version by itself or there could be a drop down with several options. About modifying SSBs, right now all the tools for modification are inside the actul activity. I'd like to see modification of userscripts and userstyles done in 'View Source' (as well). 2009/8/11 Simon Schampijer si...@schampijer.de: On 08/10/2009 11:56 PM, Lucian Branescu wrote: This a bit long-winded, but please bear with me. If you know my project, skip to the end. I've been working on Browse in the context of GSoC. http://wiki.sugarlabs.org/go/Webified Here's my blog http://honeyweb.wordpress.com and you can get the code from here http://git.sugarlabs.org/projects/browse/repos/webified. I can prepare an .xo bundle if needed. I've implemented Site Specific Browser creation and 'save complete page' functionality for Browse. An example of SSB is Mozilla Prism; Firefox has the option to save a page, complete with resources. Site Specific Browsers in Sugar are instances of Browse with a static home-page and a few extra capabilities, like bookmarklets, userscripts and userstyles (http://honeyweb.wordpress.com/2009/07/06/bookmarklets-userstyles-userscriptssort-of/). The web site loaded inside an SSB works just like it would normally, but it happens to be the default and it can be (easily) customised. This works very well for GMail, for example. In fact, I use GMail inside an SSB all the time (http://fluidapp.com). With Gears, you can even work with GMail offline. Saving a complete web page is useful for keeping a web page for offline viewing, of course. But for web apps with behaviour that does not depend on a having a network, they are similar in a way to SSBs. This would work very well for things like Karma lessons (see Felipe and Bryan's project http://karmaproject.wordpress.com/) and Paint Web http://code.google.com/p/paintweb/. Both ways produce a Journal object that can be run and opens a Browse instance with the desired web page, but they are very different technically. Both would be very useful and for different purposes, but they have some overlapping usage. How should these features be presented to the user? The screenshots on my blog show the current situation. So saving the current page, could be a button, like shown in the screenshot now. If we want to special case the SSB creation, it could be an option in the button palette. The SSB can be installed to the system as well. We want maybe an install option in the alert. And maybe there should be an install option from the journal as well. Activities we install directly when downloaded, we could handle it the same way, with the SSB as well. The entries could have a badged browse icon. To distinguish them from the rest of the Browse activity entries. When you click on an 'offline webpage' entry a Browse instance could be opened showing that entry. One could think about opening it in a new tab, when a Browse instance is already running, in the future. One thing that needs thinking as well is the modifying of the SSB (other icon etc). Maybe an activity could handle that? Maybe an option in a develop activity? Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design help needed for web applications within Sugar
Hi Lucian Can you explain to me what SSB means? Sorry for my naivete, it's probably perfectly clear to everyone else. Generally these look fine, but I think we could probably clarify the interaction a bit after you give me a few pointers on what you are trying to do. Thanks! Christian On Mon, Aug 10, 2009 at 6:21 PM, Lucian Branescu lucian.brane...@gmail.comwrote: Sorry, I should have pointed that out more clearly. In this image (http://files.getdropbox.com/u/317039/userscript%20hello%20world.png), the button in the top right, next to the bookmark button, is the button used for creating SSBs. Here (http://dl.getdropbox.com/u/317039/create%20ssb.png) is an even better screenshot. 2009/8/10 Benjamin M. Schwartz bmsch...@fas.harvard.edu: Lucian Branescu wrote: How should these features be presented to the user? The screenshots on my blog show the current situation. They do? I don't see anything there that shows the current SSB creation or site-zip-saving UI. --Ben -- anyth...@christianmarcschmidt.com http://www.christianmarcschmidt.com 917/ 575 0013 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design help needed for web applications within Sugar
Silly me. Here's the proper link http://en.wikipedia.org/wiki/Site-specific_browser 2009/8/11 Lucian Branescu lucian.brane...@gmail.com: Sorry, it's my fault. Here http://en.wikipedia.org/wiki/SSB It's a specialised Browser that runs a single web site. It may be customised for that certain web site. An example is Mozilla Prism. If you want more info, read the webified wiki page and my blog, but it's a lot to read. 2009/8/11 Christian Marc Schmidt christianm...@gmail.com: Hi Lucian Can you explain to me what SSB means? Sorry for my naivete, it's probably perfectly clear to everyone else. Generally these look fine, but I think we could probably clarify the interaction a bit after you give me a few pointers on what you are trying to do. Thanks! Christian On Mon, Aug 10, 2009 at 6:21 PM, Lucian Branescu lucian.brane...@gmail.com wrote: Sorry, I should have pointed that out more clearly. In this image (http://files.getdropbox.com/u/317039/userscript%20hello%20world.png), the button in the top right, next to the bookmark button, is the button used for creating SSBs. Here (http://dl.getdropbox.com/u/317039/create%20ssb.png) is an even better screenshot. 2009/8/10 Benjamin M. Schwartz bmsch...@fas.harvard.edu: Lucian Branescu wrote: How should these features be presented to the user? The screenshots on my blog show the current situation. They do? I don't see anything there that shows the current SSB creation or site-zip-saving UI. --Ben -- anyth...@christianmarcschmidt.com http://www.christianmarcschmidt.com 917/ 575 0013 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design help needed for web applications within Sugar
Sorry, it's my fault. Here http://en.wikipedia.org/wiki/SSB It's a specialised Browser that runs a single web site. It may be customised for that certain web site. An example is Mozilla Prism. If you want more info, read the webified wiki page and my blog, but it's a lot to read. 2009/8/11 Christian Marc Schmidt christianm...@gmail.com: Hi Lucian Can you explain to me what SSB means? Sorry for my naivete, it's probably perfectly clear to everyone else. Generally these look fine, but I think we could probably clarify the interaction a bit after you give me a few pointers on what you are trying to do. Thanks! Christian On Mon, Aug 10, 2009 at 6:21 PM, Lucian Branescu lucian.brane...@gmail.com wrote: Sorry, I should have pointed that out more clearly. In this image (http://files.getdropbox.com/u/317039/userscript%20hello%20world.png), the button in the top right, next to the bookmark button, is the button used for creating SSBs. Here (http://dl.getdropbox.com/u/317039/create%20ssb.png) is an even better screenshot. 2009/8/10 Benjamin M. Schwartz bmsch...@fas.harvard.edu: Lucian Branescu wrote: How should these features be presented to the user? The screenshots on my blog show the current situation. They do? I don't see anything there that shows the current SSB creation or site-zip-saving UI. --Ben -- anyth...@christianmarcschmidt.com http://www.christianmarcschmidt.com 917/ 575 0013 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design help needed for web applications within Sugar
On 08/11/2009 12:14 PM, Lucian Branescu wrote: In fact, there is the option to install the SSB activity as well, http://dl.getdropbox.com/u/317039/create%20ssb.png Yes seen that. rgs on IRC suggested that the 'Keep in Journal' button could either save an offline version by itself or there could be a drop down with several options. Do you mean the activity keep button? Like the one in Write - where we have the options to save a richt text format or others? If yes - yeah that sounds like a good option actually. About modifying SSBs, right now all the tools for modification are inside the actul activity. I'd like to see modification of userscripts and userstyles done in 'View Source' (as well). Oh, yeah view source. Sounds interesting to me, too. We just need to make sure to not overload it. I mean editing text is easy. When it comes to changing the icon it gets more complicated, though. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design help needed for web applications within Sugar
2009/8/11 Simon Schampijer si...@schampijer.de: On 08/11/2009 12:14 PM, Lucian Branescu wrote: In fact, there is the option to install the SSB activity as well, http://dl.getdropbox.com/u/317039/create%20ssb.png Yes seen that. rgs on IRC suggested that the 'Keep in Journal' button could either save an offline version by itself or there could be a drop down with several options. Do you mean the activity keep button? Like the one in Write - where we have the options to save a richt text format or others? If yes - yeah that sounds like a good option actually. I'll go ahead and try to implement that, then. About modifying SSBs, right now all the tools for modification are inside the actul activity. I'd like to see modification of userscripts and userstyles done in 'View Source' (as well). Oh, yeah view source. Sounds interesting to me, too. We just need to make sure to not overload it. I mean editing text is easy. When it comes to changing the icon it gets more complicated, though. Perhaps the Sugar shell should allow users to change activity icons? In any case, View Source already has Document view and Bundle view. We could either expand Document view to have a TreeView on the left like Bundle view or create a separate Editables view. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design help needed for web applications within Sugar
On Tue, Aug 11, 2009 at 1:13 PM, Lucian Branesculucian.brane...@gmail.com wrote: 2009/8/11 Simon Schampijer si...@schampijer.de: On 08/11/2009 12:14 PM, Lucian Branescu wrote: In fact, there is the option to install the SSB activity as well, http://dl.getdropbox.com/u/317039/create%20ssb.png Yes seen that. rgs on IRC suggested that the 'Keep in Journal' button could either save an offline version by itself or there could be a drop down with several options. Do you mean the activity keep button? Like the one in Write - where we have the options to save a richt text format or others? If yes - yeah that sounds like a good option actually. I'll go ahead and try to implement that, then. About modifying SSBs, right now all the tools for modification are inside the actul activity. I'd like to see modification of userscripts and userstyles done in 'View Source' (as well). Oh, yeah view source. Sounds interesting to me, too. We just need to make sure to not overload it. I mean editing text is easy. When it comes to changing the icon it gets more complicated, though. Perhaps the Sugar shell should allow users to change activity icons? It's an unfortunate fact that there is no activity suitable for creating SVG icons for Sugar. We need a Draw activity to fill this gap and compliment Paint... In any case, View Source already has Document view and Bundle view. We could either expand Document view to have a TreeView on the left like Bundle view or create a separate Editables view. I hesitate to overload the view source mechanism this way, actually. Should we instead be providing a seamless mechanism for modifying code, icons, etc. with other activities, so that users (eventually) have choices regarding their editors? View source is a logical step in the process, so we should certainly expose the ability to launch into editing from there, of course. I suppose an alternative argument can be made for the level of integration we could provide when editing within the view source dialog. If we could hook it up to have real-time effect on the running activity, so that making a change couldbe tested right away, that may make it worth doing... Eben Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design help needed for web applications within Sugar
On 11 Aug 2009, at 08:17, Simon Schampijer wrote: On 08/10/2009 11:56 PM, Lucian Branescu wrote: This a bit long-winded, but please bear with me. If you know my project, skip to the end. I've been working on Browse in the context of GSoC. http://wiki.sugarlabs.org/go/Webified Here's my blog http://honeyweb.wordpress.com and you can get the code from here http://git.sugarlabs.org/projects/browse/repos/webified. I can prepare an .xo bundle if needed. I've implemented Site Specific Browser creation and 'save complete page' functionality for Browse. An example of SSB is Mozilla Prism; Firefox has the option to save a page, complete with resources. Site Specific Browsers in Sugar are instances of Browse with a static home-page and a few extra capabilities, like bookmarklets, userscripts and userstyles (http://honeyweb.wordpress.com/2009/07/06/bookmarklets-userstyles-userscriptssort-of/ ). The web site loaded inside an SSB works just like it would normally, but it happens to be the default and it can be (easily) customised. This works very well for GMail, for example. In fact, I use GMail inside an SSB all the time (http://fluidapp.com). With Gears, you can even work with GMail offline. Saving a complete web page is useful for keeping a web page for offline viewing, of course. But for web apps with behaviour that does not depend on a having a network, they are similar in a way to SSBs. This would work very well for things like Karma lessons (see Felipe and Bryan's project http://karmaproject.wordpress.com/) and Paint Web http://code.google.com/p/paintweb/. Both ways produce a Journal object that can be run and opens a Browse instance with the desired web page, but they are very different technically. Both would be very useful and for different purposes, but they have some overlapping usage. How should these features be presented to the user? The screenshots on my blog show the current situation. So saving the current page, could be a button, like shown in the screenshot now. If we want to special case the SSB creation, it could be an option in the button palette. The SSB can be installed to the system as well. We want maybe an install option in the alert. And maybe there should be an install option from the journal as well. Activities we install directly when downloaded, we could handle it the same way, with the SSB as well. The entries could have a badged browse icon. To distinguish them from the rest of the Browse activity entries. When you click on an 'offline webpage' entry a Browse instance could be opened showing that entry. One could think about opening it in a new tab, when a Browse instance is already running, in the future. Random thought, well not so random – blame Michael Stone if you don't like it ;-) How about a Browse badged identicon? http://en.wikipedia.org/wiki/Identicon I've been perusing the possibilities of identicons as an alternative to titles now that we plan to HIDE THE BLASTED THINGS IN A SUBMENU now ;-p But, this use may actually make more sense. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design help needed for web applications within Sugar
View source would only be used for editing small things, like TurtleArt code blocks and userstyles, but no actual activity code. The activity would offer a list of pseudo-files that are to be edited by users. Changes to these would be applied immediately in the activity, so it would be easier to switch between View source and the activity. Would you consider this case too much overloading? 2009/8/11 Eben Eliason eben.elia...@gmail.com: On Tue, Aug 11, 2009 at 1:13 PM, Lucian Branesculucian.brane...@gmail.com wrote: 2009/8/11 Simon Schampijer si...@schampijer.de: On 08/11/2009 12:14 PM, Lucian Branescu wrote: In fact, there is the option to install the SSB activity as well, http://dl.getdropbox.com/u/317039/create%20ssb.png Yes seen that. rgs on IRC suggested that the 'Keep in Journal' button could either save an offline version by itself or there could be a drop down with several options. Do you mean the activity keep button? Like the one in Write - where we have the options to save a richt text format or others? If yes - yeah that sounds like a good option actually. I'll go ahead and try to implement that, then. About modifying SSBs, right now all the tools for modification are inside the actul activity. I'd like to see modification of userscripts and userstyles done in 'View Source' (as well). Oh, yeah view source. Sounds interesting to me, too. We just need to make sure to not overload it. I mean editing text is easy. When it comes to changing the icon it gets more complicated, though. Perhaps the Sugar shell should allow users to change activity icons? It's an unfortunate fact that there is no activity suitable for creating SVG icons for Sugar. We need a Draw activity to fill this gap and compliment Paint... In any case, View Source already has Document view and Bundle view. We could either expand Document view to have a TreeView on the left like Bundle view or create a separate Editables view. I hesitate to overload the view source mechanism this way, actually. Should we instead be providing a seamless mechanism for modifying code, icons, etc. with other activities, so that users (eventually) have choices regarding their editors? View source is a logical step in the process, so we should certainly expose the ability to launch into editing from there, of course. I suppose an alternative argument can be made for the level of integration we could provide when editing within the view source dialog. If we could hook it up to have real-time effect on the running activity, so that making a change couldbe tested right away, that may make it worth doing... Eben Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design help needed for web applications within Sugar
On 11 Aug 2009, at 18:25, Eben Eliason wrote: On Tue, Aug 11, 2009 at 1:13 PM, Lucian Branesculucian.brane...@gmail.com wrote: 2009/8/11 Simon Schampijer si...@schampijer.de: On 08/11/2009 12:14 PM, Lucian Branescu wrote: In fact, there is the option to install the SSB activity as well, http://dl.getdropbox.com/u/317039/create%20ssb.png Yes seen that. rgs on IRC suggested that the 'Keep in Journal' button could either save an offline version by itself or there could be a drop down with several options. Do you mean the activity keep button? Like the one in Write - where we have the options to save a richt text format or others? If yes - yeah that sounds like a good option actually. I'll go ahead and try to implement that, then. About modifying SSBs, right now all the tools for modification are inside the actul activity. I'd like to see modification of userscripts and userstyles done in 'View Source' (as well). Oh, yeah view source. Sounds interesting to me, too. We just need to make sure to not overload it. I mean editing text is easy. When it comes to changing the icon it gets more complicated, though. Perhaps the Sugar shell should allow users to change activity icons? It's an unfortunate fact that there is no activity suitable for creating SVG icons for Sugar. We need a Draw activity to fill this gap and compliment Paint... In any case, View Source already has Document view and Bundle view. We could either expand Document view to have a TreeView on the left like Bundle view or create a separate Editables view. I hesitate to overload the view source mechanism this way, actually. Should we instead be providing a seamless mechanism for modifying code, icons, etc. with other activities, so that users (eventually) have choices regarding their editors? View source is a logical step in the process, so we should certainly expose the ability to launch into editing from there, of course. I suppose an alternative argument can be made for the level of integration we could provide when editing within the view source dialog. If we could hook it up to have real-time effect on the running activity, so that making a change couldbe tested right away, that may make it worth doing... If View Source makes it to Edit Source, it could be reasonable to expect that if you do modify and then close the source editor you would raise an Activity like alert bar with something like Activity needs to re-start for changes to take effect (Discard changes) (Re- start activity). I understand that Guido van Rossum had some proposals for Sugar to pick up live Python edit changes, but I guess that's water long under the bridge now given current Sugar Labs resources. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design help needed for web applications within Sugar
I would suggest a mechanism to export all or just the selected SSB sites and the import feature Gary C Martin wrote: On 11 Aug 2009, at 18:25, Eben Eliason wrote: On Tue, Aug 11, 2009 at 1:13 PM, Lucian Branesculucian.brane...@gmail.com wrote: 2009/8/11 Simon Schampijer si...@schampijer.de: On 08/11/2009 12:14 PM, Lucian Branescu wrote: In fact, there is the option to install the SSB activity as well, http://dl.getdropbox.com/u/317039/create%20ssb.png Yes seen that. rgs on IRC suggested that the 'Keep in Journal' button could either save an offline version by itself or there could be a drop down with several options. Do you mean the activity keep button? Like the one in Write - where we have the options to save a richt text format or others? If yes - yeah that sounds like a good option actually. I'll go ahead and try to implement that, then. About modifying SSBs, right now all the tools for modification are inside the actul activity. I'd like to see modification of userscripts and userstyles done in 'View Source' (as well). Oh, yeah view source. Sounds interesting to me, too. We just need to make sure to not overload it. I mean editing text is easy. When it comes to changing the icon it gets more complicated, though. Perhaps the Sugar shell should allow users to change activity icons? It's an unfortunate fact that there is no activity suitable for creating SVG icons for Sugar. We need a Draw activity to fill this gap and compliment Paint... In any case, View Source already has Document view and Bundle view. We could either expand Document view to have a TreeView on the left like Bundle view or create a separate Editables view. I hesitate to overload the view source mechanism this way, actually. Should we instead be providing a seamless mechanism for modifying code, icons, etc. with other activities, so that users (eventually) have choices regarding their editors? View source is a logical step in the process, so we should certainly expose the ability to launch into editing from there, of course. I suppose an alternative argument can be made for the level of integration we could provide when editing within the view source dialog. If we could hook it up to have real-time effect on the running activity, so that making a change couldbe tested right away, that may make it worth doing... If View Source makes it to Edit Source, it could be reasonable to expect that if you do modify and then close the source editor you would raise an Activity like alert bar with something like Activity needs to re-start for changes to take effect (Discard changes) (Re- start activity). I understand that Guido van Rossum had some proposals for Sugar to pick up live Python edit changes, but I guess that's water long under the bridge now given current Sugar Labs resources. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- View this message in context: http://n2.nabble.com/Design-help-needed-for-web-applications-within-Sugar-tp3420222p3427921.html Sent from the Sugar Development mailing list archive at Nabble.com. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Design help needed for web applications within Sugar
This a bit long-winded, but please bear with me. If you know my project, skip to the end. I've been working on Browse in the context of GSoC. http://wiki.sugarlabs.org/go/Webified Here's my blog http://honeyweb.wordpress.com and you can get the code from here http://git.sugarlabs.org/projects/browse/repos/webified. I can prepare an .xo bundle if needed. I've implemented Site Specific Browser creation and 'save complete page' functionality for Browse. An example of SSB is Mozilla Prism; Firefox has the option to save a page, complete with resources. Site Specific Browsers in Sugar are instances of Browse with a static home-page and a few extra capabilities, like bookmarklets, userscripts and userstyles (http://honeyweb.wordpress.com/2009/07/06/bookmarklets-userstyles-userscriptssort-of/). The web site loaded inside an SSB works just like it would normally, but it happens to be the default and it can be (easily) customised. This works very well for GMail, for example. In fact, I use GMail inside an SSB all the time (http://fluidapp.com). With Gears, you can even work with GMail offline. Saving a complete web page is useful for keeping a web page for offline viewing, of course. But for web apps with behaviour that does not depend on a having a network, they are similar in a way to SSBs. This would work very well for things like Karma lessons (see Felipe and Bryan's project http://karmaproject.wordpress.com/) and Paint Web http://code.google.com/p/paintweb/. Both ways produce a Journal object that can be run and opens a Browse instance with the desired web page, but they are very different technically. Both would be very useful and for different purposes, but they have some overlapping usage. How should these features be presented to the user? The screenshots on my blog show the current situation. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design help needed for web applications within Sugar
Sorry, I should have pointed that out more clearly. In this image (http://files.getdropbox.com/u/317039/userscript%20hello%20world.png), the button in the top right, next to the bookmark button, is the button used for creating SSBs. Here (http://dl.getdropbox.com/u/317039/create%20ssb.png) is an even better screenshot. 2009/8/10 Benjamin M. Schwartz bmsch...@fas.harvard.edu: Lucian Branescu wrote: How should these features be presented to the user? The screenshots on my blog show the current situation. They do? I don't see anything there that shows the current SSB creation or site-zip-saving UI. --Ben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
