Re: [Sugar-devel] GSoC idea: Chart/graph-making activity
> Why no collaboration-like tube between activities? > > Are you referring to a "tube" strictly between two laptops (e.g. one > student runs Measure and another runs a charting tool) or also in > the case of two activities running concurrently on the same machine? Why not follow the way it was done back in the Amiga days: an Arexx port? http://en.wikipedia.org/wiki/AREXX Many Amiga programs had an 'Arexx port': the software could output various data via the Arexx language, and this could be forwarded to other programs to use as input. A trivial example would be to use a spreadsheet to generate and then send data to a paint program, which could then draw and image-process the incoming data for various visual effects... In this context, it would mean 'tagging' on some capability similar to Arexx to various activities. Define what kind of data could be sent from a particular activity. Other (sufficiently compatible) activities could then import this data to process it. Application communication via Arexx was one of the Amiga's killer features... ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GSoC idea: Chart/graph-making activity
both -walter On Thu, Mar 26, 2009 at 1:39 PM, Garrison Benson wrote: > > > Why no collaboration-like tube between activities? > > > Are you referring to a "tube" strictly between two laptops (e.g. one student > runs Measure and another runs a charting tool) or also in the case of two > activities running concurrently on the same machine? > -- > View this message in context: > http://n2.nabble.com/GSoC-idea%3A-Chart-graph-making-activity-tp2517796p2539937.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 > -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GSoC idea: Chart/graph-making activity
Why no collaboration-like tube between activities? Are you referring to a "tube" strictly between two laptops (e.g. one student runs Measure and another runs a charting tool) or also in the case of two activities running concurrently on the same machine? -- View this message in context: http://n2.nabble.com/GSoC-idea%3A-Chart-graph-making-activity-tp2517796p2539937.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
Re: [Sugar-devel] GSoC idea: Chart/graph-making activity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Walter Bender wrote: > I thought Fred was getting at a much simpler idea. For example, > Measure, when it is collaborating, is sending a simple data stream to > each member of the collaboration. Why couldn't a chart program join in > and instead of rendering the datastream as a waveform, it would render > it as a piechart. Of course, we'd need to consider that the chart > program wouldn't be generating data, but if an activity which wants to > share its data with other activities sticks to a simple streaming > protocol, I don't think it is too difficult. That's a nice idea, really. What I'm saying is: it's not difficult to build it once, but it's difficult to ensure reliability when there are 100 versions of Measure and 100 versions of Chart, and they've each gone through countless revisions of the datastream format. Sugar is designed to encourage forking, which makes this sort of compatibility very hard. In the early days of Sugar this sort of problem happened frequently with central components of the system, causing "flag days" where multiple components of the system had to be upgraded simultaneously in order to maintain functionality. Clearly we can't achieve "flag day" upgrades of Activities, given our distributed development model. I have long pushed, and am continuing to push, a model in which any two people collaborating are using the _exact same Activity_. That is, upon joining someone's shared activity, if I don't have that precise bundle already, my system will silently download it, launch it, and join. (Bitfrost exists precisely to make this procedure safe.) That way, an Activity author only has to ensure that her code is compatible with itself. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknKtnMACgkQUJT6e6HFtqT5RgCfUhjENDiOaR9IxqhEUGXpuQYh y4AAn2nbuz4+o8C8SGm2DycmyVwEpAig =XeHc -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GSoC idea: Chart/graph-making activity
To simplify, I think MIME types are the best way to communicate between activities. Spreadsheet data can be text/csv, image data can be image/png, plain text can be text/plain etc. That's currently what's supported by the clipboard anyway. All activities have to do is implement a little more advanced version of Copy & Paste, and the clipboard needs to support everything correctly too. -Wade 2009/3/25 Frederick Grose : > Just thinking at the conceptual level. How about filtering irrelevant > method calls and signals? How about a RESTful interface > (http://en.wikipedia.org/wiki/Representational_State_Transfer)? > > I don't know. Just thinking... > > Thanks for contributing! --Fred > > On Wed, Mar 25, 2009 at 5:21 PM, Benjamin M. Schwartz > wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> For the moment, I assume you are speaking of our current network >> collaboration technologies. >> >> Walter Bender wrote: >> > Interesting idea. I don't see why this couldn't work; I am not sure of >> > the security implications, but I don't see why collaboration always >> > has to be between two identical activities. >> >> Collaboration always has to be between two identical activities. The only >> exception is if the two activities, though not identical, speak a unified, >> coherent network protocol. In order for this to work, Activities would >> have to specify their network protocol in complete detail, with each >> change in the protocol generating a new version identifier. >> >> It is not enough to specify the generic connection parameters, as done by >> Telepathy; this only gets us far enough to fail. The protocol in question >> must specify the names, types, and meanings, of all remote procedures that >> can be called from either side. This is approximately the level of >> specification required in something like an IETF RFC... and it would be >> needed for every activity. The versions would then need some sort of >> identifier, so that the two participants can, when initializing a >> connection, negotiate a mutually intelligible protocol (if one exists). >> >> Achieving this level of precision specification is difficult even for >> experienced full-time software engineers. It is often performed by >> specification specialists, who are experts in this field. >> >> Moreover, distinct activities are _different_. It should be obvious >> enough that no matter how we twist the network protocols, Video Chat and >> Write are never going to collaborate directly with each other. Their >> internal data structures are grossly incompatible, because their codebases >> are unrelated, because their purposes are entirely distinct. >> >> Now, the above is fairly obvious, so I suspect you are talking about >> something else. Perhaps you envision some way of taking the functionality >> from one Activity and embedding it in another as a kind of widget, or >> perhaps you're thinking of some other way of smushing activities together >> like objects with well-defined interfaces. If so, you may like to observe >> the history of the Component Object Model [1], the Cross Platform >> Component Object Model [2], or maybe even the GNU Network Object Model >> Environment [3]. >> >> I think such "collaborative widgets" are very powerful; I've even written >> one or two for Groupthink... but now I'm off into speculation, since I >> don't really know what you're thinking about. >> >> - --Ben >> >> [1] http://en.wikipedia.org/wiki/Component_Object_Model >> [2] http://en.wikipedia.org/wiki/Xpcom >> [3] http://en.wikipedia.org/wiki/GNOME#Name >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v2.0.9 (GNU/Linux) >> >> iEYEARECAAYFAknKoGsACgkQUJT6e6HFtqREVQCaA7m8daZOFBh2PB4/pfTRoHeX >> En4AnR6BBOZOCA8SfSu3GbA3TarQAX4a >> =YpnV >> -END PGP SIGNATURE- > > > ___ > 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] GSoC idea: Chart/graph-making activity
Just thinking at the conceptual level. How about filtering irrelevant method calls and signals? How about a RESTful interface ( http://en.wikipedia.org/wiki/Representational_State_Transfer)? I don't know. Just thinking... Thanks for contributing! --Fred On Wed, Mar 25, 2009 at 5:21 PM, Benjamin M. Schwartz < bmsch...@fas.harvard.edu> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > For the moment, I assume you are speaking of our current network > collaboration technologies. > > Walter Bender wrote: > > Interesting idea. I don't see why this couldn't work; I am not sure of > > the security implications, but I don't see why collaboration always > > has to be between two identical activities. > > Collaboration always has to be between two identical activities. The only > exception is if the two activities, though not identical, speak a unified, > coherent network protocol. In order for this to work, Activities would > have to specify their network protocol in complete detail, with each > change in the protocol generating a new version identifier. > > It is not enough to specify the generic connection parameters, as done by > Telepathy; this only gets us far enough to fail. The protocol in question > must specify the names, types, and meanings, of all remote procedures that > can be called from either side. This is approximately the level of > specification required in something like an IETF RFC... and it would be > needed for every activity. The versions would then need some sort of > identifier, so that the two participants can, when initializing a > connection, negotiate a mutually intelligible protocol (if one exists). > > Achieving this level of precision specification is difficult even for > experienced full-time software engineers. It is often performed by > specification specialists, who are experts in this field. > > Moreover, distinct activities are _different_. It should be obvious > enough that no matter how we twist the network protocols, Video Chat and > Write are never going to collaborate directly with each other. Their > internal data structures are grossly incompatible, because their codebases > are unrelated, because their purposes are entirely distinct. > > Now, the above is fairly obvious, so I suspect you are talking about > something else. Perhaps you envision some way of taking the functionality > from one Activity and embedding it in another as a kind of widget, or > perhaps you're thinking of some other way of smushing activities together > like objects with well-defined interfaces. If so, you may like to observe > the history of the Component Object Model [1], the Cross Platform > Component Object Model [2], or maybe even the GNU Network Object Model > Environment [3]. > > I think such "collaborative widgets" are very powerful; I've even written > one or two for Groupthink... but now I'm off into speculation, since I > don't really know what you're thinking about. > > - --Ben > > [1] http://en.wikipedia.org/wiki/Component_Object_Model > [2] http://en.wikipedia.org/wiki/Xpcom > [3] http://en.wikipedia.org/wiki/GNOME#Name > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.9 (GNU/Linux) > > iEYEARECAAYFAknKoGsACgkQUJT6e6HFtqREVQCaA7m8daZOFBh2PB4/pfTRoHeX > En4AnR6BBOZOCA8SfSu3GbA3TarQAX4a > =YpnV > -END PGP SIGNATURE- > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GSoC idea: Chart/graph-making activity
I thought Fred was getting at a much simpler idea. For example, Measure, when it is collaborating, is sending a simple data stream to each member of the collaboration. Why couldn't a chart program join in and instead of rendering the datastream as a waveform, it would render it as a piechart. Of course, we'd need to consider that the chart program wouldn't be generating data, but if an activity which wants to share its data with other activities sticks to a simple streaming protocol, I don't think it is too difficult. -walter On Wed, Mar 25, 2009 at 5:21 PM, Benjamin M. Schwartz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > For the moment, I assume you are speaking of our current network > collaboration technologies. > > Walter Bender wrote: >> Interesting idea. I don't see why this couldn't work; I am not sure of >> the security implications, but I don't see why collaboration always >> has to be between two identical activities. > > Collaboration always has to be between two identical activities. The only > exception is if the two activities, though not identical, speak a unified, > coherent network protocol. In order for this to work, Activities would > have to specify their network protocol in complete detail, with each > change in the protocol generating a new version identifier. > > It is not enough to specify the generic connection parameters, as done by > Telepathy; this only gets us far enough to fail. The protocol in question > must specify the names, types, and meanings, of all remote procedures that > can be called from either side. This is approximately the level of > specification required in something like an IETF RFC... and it would be > needed for every activity. The versions would then need some sort of > identifier, so that the two participants can, when initializing a > connection, negotiate a mutually intelligible protocol (if one exists). > > Achieving this level of precision specification is difficult even for > experienced full-time software engineers. It is often performed by > specification specialists, who are experts in this field. > > Moreover, distinct activities are _different_. It should be obvious > enough that no matter how we twist the network protocols, Video Chat and > Write are never going to collaborate directly with each other. Their > internal data structures are grossly incompatible, because their codebases > are unrelated, because their purposes are entirely distinct. > > Now, the above is fairly obvious, so I suspect you are talking about > something else. Perhaps you envision some way of taking the functionality > from one Activity and embedding it in another as a kind of widget, or > perhaps you're thinking of some other way of smushing activities together > like objects with well-defined interfaces. If so, you may like to observe > the history of the Component Object Model [1], the Cross Platform > Component Object Model [2], or maybe even the GNU Network Object Model > Environment [3]. > > I think such "collaborative widgets" are very powerful; I've even written > one or two for Groupthink... but now I'm off into speculation, since I > don't really know what you're thinking about. > > - --Ben > > [1] http://en.wikipedia.org/wiki/Component_Object_Model > [2] http://en.wikipedia.org/wiki/Xpcom > [3] http://en.wikipedia.org/wiki/GNOME#Name > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.9 (GNU/Linux) > > iEYEARECAAYFAknKoGsACgkQUJT6e6HFtqREVQCaA7m8daZOFBh2PB4/pfTRoHeX > En4AnR6BBOZOCA8SfSu3GbA3TarQAX4a > =YpnV > -END PGP SIGNATURE- > -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GSoC idea: Chart/graph-making activity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For the moment, I assume you are speaking of our current network collaboration technologies. Walter Bender wrote: > Interesting idea. I don't see why this couldn't work; I am not sure of > the security implications, but I don't see why collaboration always > has to be between two identical activities. Collaboration always has to be between two identical activities. The only exception is if the two activities, though not identical, speak a unified, coherent network protocol. In order for this to work, Activities would have to specify their network protocol in complete detail, with each change in the protocol generating a new version identifier. It is not enough to specify the generic connection parameters, as done by Telepathy; this only gets us far enough to fail. The protocol in question must specify the names, types, and meanings, of all remote procedures that can be called from either side. This is approximately the level of specification required in something like an IETF RFC... and it would be needed for every activity. The versions would then need some sort of identifier, so that the two participants can, when initializing a connection, negotiate a mutually intelligible protocol (if one exists). Achieving this level of precision specification is difficult even for experienced full-time software engineers. It is often performed by specification specialists, who are experts in this field. Moreover, distinct activities are _different_. It should be obvious enough that no matter how we twist the network protocols, Video Chat and Write are never going to collaborate directly with each other. Their internal data structures are grossly incompatible, because their codebases are unrelated, because their purposes are entirely distinct. Now, the above is fairly obvious, so I suspect you are talking about something else. Perhaps you envision some way of taking the functionality from one Activity and embedding it in another as a kind of widget, or perhaps you're thinking of some other way of smushing activities together like objects with well-defined interfaces. If so, you may like to observe the history of the Component Object Model [1], the Cross Platform Component Object Model [2], or maybe even the GNU Network Object Model Environment [3]. I think such "collaborative widgets" are very powerful; I've even written one or two for Groupthink... but now I'm off into speculation, since I don't really know what you're thinking about. - --Ben [1] http://en.wikipedia.org/wiki/Component_Object_Model [2] http://en.wikipedia.org/wiki/Xpcom [3] http://en.wikipedia.org/wiki/GNOME#Name -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknKoGsACgkQUJT6e6HFtqREVQCaA7m8daZOFBh2PB4/pfTRoHeX En4AnR6BBOZOCA8SfSu3GbA3TarQAX4a =YpnV -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GSoC idea: Chart/graph-making activity
Interesting idea. I don't see why this couldn't work; I am not sure of the security implications, but I don't see why collaboration always has to be between two identical activities. -walter 2009/3/25 Frederick Grose : > Why no collaboration-like tube between activities? > > --Fred > > On Wed, Mar 25, 2009 at 1:51 PM, Eben Eliason wrote: >> >> Seconding Walter...more inline. >> >> On Wed, Mar 25, 2009 at 10:19 AM, Wade Brainerd wrote: >> > This whole thing brings to mind something that I've been curious about >> > for >> > awhile. >> > >> > What's the "recommended" way to transfer data between activities? >> > >> > Say, I record some data in Measure and want to import it into Chart. Or >> > I >> > generate some data in Finance and want to import it into Chart. >> > >> > Is the Clipboard the way to do it? IE, should we support specialize >> > "copy >> > as text/csv" (or whatever) and "paste text/csv" in our activities? >> >> I don't think we should be adding specific data formats to the copy >> action, if we can avoid it. This is better suited to the "Keep as..." >> (some other format) action. However, I do think that basic copy/paste >> within a given activity, or between activities, should be strongly >> encouraged. Sugar adds a visual, multi-item clipboard (with >> forthcoming previews/descriptions) in order to make even better suited >> to this task. >> >> It should never be _necessary_ to save something to the Journal in >> order to move data into another activity, for common image/text/media >> formats. >> >> > Same goes for transferring of pictures. If I take a picture in Record >> > and >> > want to paint over it in Colors!, is Copy in Record and then Paste in >> > Colors! the way to go, or should I have Colors! open the Record Journal >> > entry? >> >> I'm in support of adding "import" buttons for particular media formats >> which make sense within the context of an activity. However, this >> shouldn't be confused with "open" buttons. The difference there is >> that importing an image should place an image file onto the canvas; it >> shouldn't replace the canvas, or change the canvas size, etc. >> >> In your specific example, taking a photo in Record already results in >> a Journal entry, so I think it's perfectly natural to say that one >> should go to that photo and resume it with Colors! in order to modify >> it there. >> >> I should also mention that I'd like to see the OS provided file >> chooser dialogs grow basic recording functionality, so that an "insert >> image" button could quickly snap a photo from the camera, and an >> "insert audio" button record a quick audio snippet, etc. This would >> prevent need for saving data to the Journal OR copying it from another >> activity, in some cases. >> >> - Eben >> >> > Thanks, >> > Wade >> > >> > On Wed, Mar 25, 2009 at 10:16 AM, Walter Bender >> > >> > wrote: >> >> >> >> The Measure activity is another approach to consider: data collection >> >> from multiple sources are shared and displayed in the same >> >> visualization space. >> >> >> >> -walter >> >> >> >> On Mon, Mar 23, 2009 at 11:02 AM, Eben Eliason wrote: >> >> > 2009/3/23 Jameson Quinn : >> >> >> >> >> >> >> >> >> On Mon, Mar 23, 2009 at 8:44 AM, Garrison Benson >> >> >> >> >> >> wrote: >> >> >>> >> >> >>> >> >> >>> Jameson Quinn wrote: >> >> >>> > >> >> >>> > Implementing a whole spreadsheet is a big enough chore. We do >> >> >>> > really >> >> >>> > care >> >> >>> > about collaboration, but I would advise you to limit your >> >> >>> > ambitions >> >> >>> > to >> >> >>> > something achievable, so worrying too much about collaboration >> >> >>> > right >> >> >>> > now >> >> >>> > is >> >> >>> > not vital. >> >> >>> > >> >> >>> >> >> >>> I don't plan to create a spreadsheet, just a graph/chart tool. >> >> >>> Obviously a >> >> >>> full-featured spreadsheet (with functions, formulas, etc.) would be >> >> >>> great >> >> >>> for Sugar, but I think a simple, user-friendly charting activity >> >> >>> would >> >> >>> be >> >> >>> much more feasible and more likely to actually be used in a primary >> >> >>> school/middle school environment. (Full spreadsheet applications >> >> >>> are >> >> >>> pretty >> >> >>> daunting to learn.) I was just throwing out the idea of a >> >> >>> spreadsheet-style >> >> >>> interface as the most obvious (but not necessarily best) type of >> >> >>> interface >> >> >>> for this kind of program. >> >> >> >> >> >> OK, understood. I think that you're right, a spreadsheet-style >> >> >> interface is >> >> >> best - when you're doing charts by hand, you start with data tables. >> >> >> Still, >> >> >> I recommend that you plan your main deliverable as something that is >> >> >> polished but without collaboration, and keep collaboration as >> >> >> something >> >> >> that >> >> >> you'll work on if you have the time. Collaboration is actually >> >> >> harder >> >> >> to get >> >> >> right than formulas, IMO. >> >> > >> >> > Agreed. I'd simply encourage y
Re: [Sugar-devel] GSoC idea: Chart/graph-making activity
Why no collaboration-like tube between activities? --Fred On Wed, Mar 25, 2009 at 1:51 PM, Eben Eliason wrote: > Seconding Walter...more inline. > > On Wed, Mar 25, 2009 at 10:19 AM, Wade Brainerd wrote: > > This whole thing brings to mind something that I've been curious about > for > > awhile. > > > > What's the "recommended" way to transfer data between activities? > > > > Say, I record some data in Measure and want to import it into Chart. Or > I > > generate some data in Finance and want to import it into Chart. > > > > Is the Clipboard the way to do it? IE, should we support specialize > "copy > > as text/csv" (or whatever) and "paste text/csv" in our activities? > > I don't think we should be adding specific data formats to the copy > action, if we can avoid it. This is better suited to the "Keep as..." > (some other format) action. However, I do think that basic copy/paste > within a given activity, or between activities, should be strongly > encouraged. Sugar adds a visual, multi-item clipboard (with > forthcoming previews/descriptions) in order to make even better suited > to this task. > > It should never be _necessary_ to save something to the Journal in > order to move data into another activity, for common image/text/media > formats. > > > Same goes for transferring of pictures. If I take a picture in Record > and > > want to paint over it in Colors!, is Copy in Record and then Paste in > > Colors! the way to go, or should I have Colors! open the Record Journal > > entry? > > I'm in support of adding "import" buttons for particular media formats > which make sense within the context of an activity. However, this > shouldn't be confused with "open" buttons. The difference there is > that importing an image should place an image file onto the canvas; it > shouldn't replace the canvas, or change the canvas size, etc. > > In your specific example, taking a photo in Record already results in > a Journal entry, so I think it's perfectly natural to say that one > should go to that photo and resume it with Colors! in order to modify > it there. > > I should also mention that I'd like to see the OS provided file > chooser dialogs grow basic recording functionality, so that an "insert > image" button could quickly snap a photo from the camera, and an > "insert audio" button record a quick audio snippet, etc. This would > prevent need for saving data to the Journal OR copying it from another > activity, in some cases. > > - Eben > > > Thanks, > > Wade > > > > On Wed, Mar 25, 2009 at 10:16 AM, Walter Bender > > > wrote: > >> > >> The Measure activity is another approach to consider: data collection > >> from multiple sources are shared and displayed in the same > >> visualization space. > >> > >> -walter > >> > >> On Mon, Mar 23, 2009 at 11:02 AM, Eben Eliason wrote: > >> > 2009/3/23 Jameson Quinn : > >> >> > >> >> > >> >> On Mon, Mar 23, 2009 at 8:44 AM, Garrison Benson > >> >> > >> >> wrote: > >> >>> > >> >>> > >> >>> Jameson Quinn wrote: > >> >>> > > >> >>> > Implementing a whole spreadsheet is a big enough chore. We do > really > >> >>> > care > >> >>> > about collaboration, but I would advise you to limit your > ambitions > >> >>> > to > >> >>> > something achievable, so worrying too much about collaboration > right > >> >>> > now > >> >>> > is > >> >>> > not vital. > >> >>> > > >> >>> > >> >>> I don't plan to create a spreadsheet, just a graph/chart tool. > >> >>> Obviously a > >> >>> full-featured spreadsheet (with functions, formulas, etc.) would be > >> >>> great > >> >>> for Sugar, but I think a simple, user-friendly charting activity > would > >> >>> be > >> >>> much more feasible and more likely to actually be used in a primary > >> >>> school/middle school environment. (Full spreadsheet applications are > >> >>> pretty > >> >>> daunting to learn.) I was just throwing out the idea of a > >> >>> spreadsheet-style > >> >>> interface as the most obvious (but not necessarily best) type of > >> >>> interface > >> >>> for this kind of program. > >> >> > >> >> OK, understood. I think that you're right, a spreadsheet-style > >> >> interface is > >> >> best - when you're doing charts by hand, you start with data tables. > >> >> Still, > >> >> I recommend that you plan your main deliverable as something that is > >> >> polished but without collaboration, and keep collaboration as > something > >> >> that > >> >> you'll work on if you have the time. Collaboration is actually harder > >> >> to get > >> >> right than formulas, IMO. > >> > > >> > Agreed. I'd simply encourage you to keep future collaboration in > >> > mind, such that large reorganization of the code isn't needed later on > >> > to add it. You might also look into > >> > http://wiki.sugarlabs.org/go/Groupthink, which could be a potential > >> > solution to adding collaboration in the long run. > >> > > >> > - Eben > >> > > >> >> > >> >> ___ > >> >> Sugar-devel mailing list > >> >>
Re: [Sugar-devel] GSoC idea: Chart/graph-making activity
Seconding Walter...more inline. On Wed, Mar 25, 2009 at 10:19 AM, Wade Brainerd wrote: > This whole thing brings to mind something that I've been curious about for > awhile. > > What's the "recommended" way to transfer data between activities? > > Say, I record some data in Measure and want to import it into Chart. Or I > generate some data in Finance and want to import it into Chart. > > Is the Clipboard the way to do it? IE, should we support specialize "copy > as text/csv" (or whatever) and "paste text/csv" in our activities? I don't think we should be adding specific data formats to the copy action, if we can avoid it. This is better suited to the "Keep as..." (some other format) action. However, I do think that basic copy/paste within a given activity, or between activities, should be strongly encouraged. Sugar adds a visual, multi-item clipboard (with forthcoming previews/descriptions) in order to make even better suited to this task. It should never be _necessary_ to save something to the Journal in order to move data into another activity, for common image/text/media formats. > Same goes for transferring of pictures. If I take a picture in Record and > want to paint over it in Colors!, is Copy in Record and then Paste in > Colors! the way to go, or should I have Colors! open the Record Journal > entry? I'm in support of adding "import" buttons for particular media formats which make sense within the context of an activity. However, this shouldn't be confused with "open" buttons. The difference there is that importing an image should place an image file onto the canvas; it shouldn't replace the canvas, or change the canvas size, etc. In your specific example, taking a photo in Record already results in a Journal entry, so I think it's perfectly natural to say that one should go to that photo and resume it with Colors! in order to modify it there. I should also mention that I'd like to see the OS provided file chooser dialogs grow basic recording functionality, so that an "insert image" button could quickly snap a photo from the camera, and an "insert audio" button record a quick audio snippet, etc. This would prevent need for saving data to the Journal OR copying it from another activity, in some cases. - Eben > Thanks, > Wade > > On Wed, Mar 25, 2009 at 10:16 AM, Walter Bender > wrote: >> >> The Measure activity is another approach to consider: data collection >> from multiple sources are shared and displayed in the same >> visualization space. >> >> -walter >> >> On Mon, Mar 23, 2009 at 11:02 AM, Eben Eliason wrote: >> > 2009/3/23 Jameson Quinn : >> >> >> >> >> >> On Mon, Mar 23, 2009 at 8:44 AM, Garrison Benson >> >> >> >> wrote: >> >>> >> >>> >> >>> Jameson Quinn wrote: >> >>> > >> >>> > Implementing a whole spreadsheet is a big enough chore. We do really >> >>> > care >> >>> > about collaboration, but I would advise you to limit your ambitions >> >>> > to >> >>> > something achievable, so worrying too much about collaboration right >> >>> > now >> >>> > is >> >>> > not vital. >> >>> > >> >>> >> >>> I don't plan to create a spreadsheet, just a graph/chart tool. >> >>> Obviously a >> >>> full-featured spreadsheet (with functions, formulas, etc.) would be >> >>> great >> >>> for Sugar, but I think a simple, user-friendly charting activity would >> >>> be >> >>> much more feasible and more likely to actually be used in a primary >> >>> school/middle school environment. (Full spreadsheet applications are >> >>> pretty >> >>> daunting to learn.) I was just throwing out the idea of a >> >>> spreadsheet-style >> >>> interface as the most obvious (but not necessarily best) type of >> >>> interface >> >>> for this kind of program. >> >> >> >> OK, understood. I think that you're right, a spreadsheet-style >> >> interface is >> >> best - when you're doing charts by hand, you start with data tables. >> >> Still, >> >> I recommend that you plan your main deliverable as something that is >> >> polished but without collaboration, and keep collaboration as something >> >> that >> >> you'll work on if you have the time. Collaboration is actually harder >> >> to get >> >> right than formulas, IMO. >> > >> > Agreed. I'd simply encourage you to keep future collaboration in >> > mind, such that large reorganization of the code isn't needed later on >> > to add it. You might also look into >> > http://wiki.sugarlabs.org/go/Groupthink, which could be a potential >> > solution to adding collaboration in the long run. >> > >> > - Eben >> > >> >> >> >> ___ >> >> 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 >> > >> >> >> >> -- >> Walter Bender >> Sugar Labs >> http://www.sugarlabs.org >> ___
Re: [Sugar-devel] GSoC idea: Chart/graph-making activity
Wade Brainerd wrote: > This whole thing brings to mind something that I've been curious about > for awhile. > What's the "recommended" way to transfer data between activities? > Say, I record some data in Measure and want to import it into Chart. > Or I generate some data in Finance and want to import it into Chart. > Is the Clipboard the way to do it? IE, should we support specialize > "copy as text/csv" (or whatever) and "paste text/csv" in our activities? > Same goes for transferring of pictures. If I take a picture in Record > and want to paint over it in Colors!, is Copy in Record and then Paste > in Colors! the way to go, or should I have Colors! open the Record > Journal entry? Me too! I have just recently read this pdf which is about recommending IT for science education and promoting the usage of office suites (mostly spreadsheets / word processors / databases / paint programs) for education. http://www.concord.org/publications/detail/itsme-98.html They effectively recommend that for a student to have meaningful reports or presentations the programs have to support inserting pictures and spreadsheets into text documents. So my question is: What is the "official" plan to support something like OLE or KPart or Bonobo? Personally I hope that the plan is not to support them but who thought out the perfect user story for data exchange? My issue is that how to import models from something like Paint into my educational application which teaches kids how to defend the planet in case of an alien invasion... ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GSoC idea: Chart/graph-making activity
The clipboard and the Journal are two recommended mechanisms. I would think that in the case of the Chart activity, the Journal would generally be more appropriate: you gather/generate some data in one activity, save to Journal, and then open the data file in Chart to explore various visualizations. Chart might export a PNG file to the Journal or clipboard, where it could be imported into Write or Turtle Art (Portfolio) for a report. Distance, which generates small, discrete chucks of data, exports directly to the clipboard. Of course, there are times when you would want to do the visualization as part of the data gathering process, a la Measure. Pipes we currently don't support. -walter On Wed, Mar 25, 2009 at 10:19 AM, Wade Brainerd wrote: > This whole thing brings to mind something that I've been curious about for > awhile. > > What's the "recommended" way to transfer data between activities? > > Say, I record some data in Measure and want to import it into Chart. Or I > generate some data in Finance and want to import it into Chart. > > Is the Clipboard the way to do it? IE, should we support specialize "copy > as text/csv" (or whatever) and "paste text/csv" in our activities? > > Same goes for transferring of pictures. If I take a picture in Record and > want to paint over it in Colors!, is Copy in Record and then Paste in > Colors! the way to go, or should I have Colors! open the Record Journal > entry? > > Thanks, > Wade > > On Wed, Mar 25, 2009 at 10:16 AM, Walter Bender > wrote: >> >> The Measure activity is another approach to consider: data collection >> from multiple sources are shared and displayed in the same >> visualization space. >> >> -walter >> >> On Mon, Mar 23, 2009 at 11:02 AM, Eben Eliason wrote: >> > 2009/3/23 Jameson Quinn : >> >> >> >> >> >> On Mon, Mar 23, 2009 at 8:44 AM, Garrison Benson >> >> >> >> wrote: >> >>> >> >>> >> >>> Jameson Quinn wrote: >> >>> > >> >>> > Implementing a whole spreadsheet is a big enough chore. We do really >> >>> > care >> >>> > about collaboration, but I would advise you to limit your ambitions >> >>> > to >> >>> > something achievable, so worrying too much about collaboration right >> >>> > now >> >>> > is >> >>> > not vital. >> >>> > >> >>> >> >>> I don't plan to create a spreadsheet, just a graph/chart tool. >> >>> Obviously a >> >>> full-featured spreadsheet (with functions, formulas, etc.) would be >> >>> great >> >>> for Sugar, but I think a simple, user-friendly charting activity would >> >>> be >> >>> much more feasible and more likely to actually be used in a primary >> >>> school/middle school environment. (Full spreadsheet applications are >> >>> pretty >> >>> daunting to learn.) I was just throwing out the idea of a >> >>> spreadsheet-style >> >>> interface as the most obvious (but not necessarily best) type of >> >>> interface >> >>> for this kind of program. >> >> >> >> OK, understood. I think that you're right, a spreadsheet-style >> >> interface is >> >> best - when you're doing charts by hand, you start with data tables. >> >> Still, >> >> I recommend that you plan your main deliverable as something that is >> >> polished but without collaboration, and keep collaboration as something >> >> that >> >> you'll work on if you have the time. Collaboration is actually harder >> >> to get >> >> right than formulas, IMO. >> > >> > Agreed. I'd simply encourage you to keep future collaboration in >> > mind, such that large reorganization of the code isn't needed later on >> > to add it. You might also look into >> > http://wiki.sugarlabs.org/go/Groupthink, which could be a potential >> > solution to adding collaboration in the long run. >> > >> > - Eben >> > >> >> >> >> ___ >> >> 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 >> > >> >> >> >> -- >> Walter Bender >> Sugar Labs >> http://www.sugarlabs.org >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel > > -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GSoC idea: Chart/graph-making activity
This whole thing brings to mind something that I've been curious about for awhile. What's the "recommended" way to transfer data between activities? Say, I record some data in Measure and want to import it into Chart. Or I generate some data in Finance and want to import it into Chart. Is the Clipboard the way to do it? IE, should we support specialize "copy as text/csv" (or whatever) and "paste text/csv" in our activities? Same goes for transferring of pictures. If I take a picture in Record and want to paint over it in Colors!, is Copy in Record and then Paste in Colors! the way to go, or should I have Colors! open the Record Journal entry? Thanks, Wade On Wed, Mar 25, 2009 at 10:16 AM, Walter Bender wrote: > The Measure activity is another approach to consider: data collection > from multiple sources are shared and displayed in the same > visualization space. > > -walter > > On Mon, Mar 23, 2009 at 11:02 AM, Eben Eliason wrote: > > 2009/3/23 Jameson Quinn : > >> > >> > >> On Mon, Mar 23, 2009 at 8:44 AM, Garrison Benson < > benson.garri...@gmail.com> > >> wrote: > >>> > >>> > >>> Jameson Quinn wrote: > >>> > > >>> > Implementing a whole spreadsheet is a big enough chore. We do really > >>> > care > >>> > about collaboration, but I would advise you to limit your ambitions > to > >>> > something achievable, so worrying too much about collaboration right > now > >>> > is > >>> > not vital. > >>> > > >>> > >>> I don't plan to create a spreadsheet, just a graph/chart tool. > Obviously a > >>> full-featured spreadsheet (with functions, formulas, etc.) would be > great > >>> for Sugar, but I think a simple, user-friendly charting activity would > be > >>> much more feasible and more likely to actually be used in a primary > >>> school/middle school environment. (Full spreadsheet applications are > >>> pretty > >>> daunting to learn.) I was just throwing out the idea of a > >>> spreadsheet-style > >>> interface as the most obvious (but not necessarily best) type of > interface > >>> for this kind of program. > >> > >> OK, understood. I think that you're right, a spreadsheet-style interface > is > >> best - when you're doing charts by hand, you start with data tables. > Still, > >> I recommend that you plan your main deliverable as something that is > >> polished but without collaboration, and keep collaboration as something > that > >> you'll work on if you have the time. Collaboration is actually harder to > get > >> right than formulas, IMO. > > > > Agreed. I'd simply encourage you to keep future collaboration in > > mind, such that large reorganization of the code isn't needed later on > > to add it. You might also look into > > http://wiki.sugarlabs.org/go/Groupthink, which could be a potential > > solution to adding collaboration in the long run. > > > > - Eben > > > >> > >> ___ > >> 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 > > > > > > -- > Walter Bender > Sugar Labs > http://www.sugarlabs.org > ___ > 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] GSoC idea: Chart/graph-making activity
The Measure activity is another approach to consider: data collection from multiple sources are shared and displayed in the same visualization space. -walter On Mon, Mar 23, 2009 at 11:02 AM, Eben Eliason wrote: > 2009/3/23 Jameson Quinn : >> >> >> On Mon, Mar 23, 2009 at 8:44 AM, Garrison Benson >> wrote: >>> >>> >>> Jameson Quinn wrote: >>> > >>> > Implementing a whole spreadsheet is a big enough chore. We do really >>> > care >>> > about collaboration, but I would advise you to limit your ambitions to >>> > something achievable, so worrying too much about collaboration right now >>> > is >>> > not vital. >>> > >>> >>> I don't plan to create a spreadsheet, just a graph/chart tool. Obviously a >>> full-featured spreadsheet (with functions, formulas, etc.) would be great >>> for Sugar, but I think a simple, user-friendly charting activity would be >>> much more feasible and more likely to actually be used in a primary >>> school/middle school environment. (Full spreadsheet applications are >>> pretty >>> daunting to learn.) I was just throwing out the idea of a >>> spreadsheet-style >>> interface as the most obvious (but not necessarily best) type of interface >>> for this kind of program. >> >> OK, understood. I think that you're right, a spreadsheet-style interface is >> best - when you're doing charts by hand, you start with data tables. Still, >> I recommend that you plan your main deliverable as something that is >> polished but without collaboration, and keep collaboration as something that >> you'll work on if you have the time. Collaboration is actually harder to get >> right than formulas, IMO. > > Agreed. I'd simply encourage you to keep future collaboration in > mind, such that large reorganization of the code isn't needed later on > to add it. You might also look into > http://wiki.sugarlabs.org/go/Groupthink, which could be a potential > solution to adding collaboration in the long run. > > - Eben > >> >> ___ >> 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 > -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GSoC idea: Chart/graph-making activity
2009/3/23 Jameson Quinn : > > > On Mon, Mar 23, 2009 at 8:44 AM, Garrison Benson > wrote: >> >> >> Jameson Quinn wrote: >> > >> > Implementing a whole spreadsheet is a big enough chore. We do really >> > care >> > about collaboration, but I would advise you to limit your ambitions to >> > something achievable, so worrying too much about collaboration right now >> > is >> > not vital. >> > >> >> I don't plan to create a spreadsheet, just a graph/chart tool. Obviously a >> full-featured spreadsheet (with functions, formulas, etc.) would be great >> for Sugar, but I think a simple, user-friendly charting activity would be >> much more feasible and more likely to actually be used in a primary >> school/middle school environment. (Full spreadsheet applications are >> pretty >> daunting to learn.) I was just throwing out the idea of a >> spreadsheet-style >> interface as the most obvious (but not necessarily best) type of interface >> for this kind of program. > > OK, understood. I think that you're right, a spreadsheet-style interface is > best - when you're doing charts by hand, you start with data tables. Still, > I recommend that you plan your main deliverable as something that is > polished but without collaboration, and keep collaboration as something that > you'll work on if you have the time. Collaboration is actually harder to get > right than formulas, IMO. Agreed. I'd simply encourage you to keep future collaboration in mind, such that large reorganization of the code isn't needed later on to add it. You might also look into http://wiki.sugarlabs.org/go/Groupthink, which could be a potential solution to adding collaboration in the long run. - Eben > > ___ > 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] GSoC idea: Chart/graph-making activity
On Mon, Mar 23, 2009 at 8:44 AM, Garrison Benson wrote: > > > Jameson Quinn wrote: > > > > Implementing a whole spreadsheet is a big enough chore. We do really care > > about collaboration, but I would advise you to limit your ambitions to > > something achievable, so worrying too much about collaboration right now > > is > > not vital. > > > > I don't plan to create a spreadsheet, just a graph/chart tool. Obviously a > full-featured spreadsheet (with functions, formulas, etc.) would be great > for Sugar, but I think a simple, user-friendly charting activity would be > much more feasible and more likely to actually be used in a primary > school/middle school environment. (Full spreadsheet applications are pretty > daunting to learn.) I was just throwing out the idea of a spreadsheet-style > interface as the most obvious (but not necessarily best) type of interface > for this kind of program. OK, understood. I think that you're right, a spreadsheet-style interface is best - when you're doing charts by hand, you start with data tables. Still, I recommend that you plan your main deliverable as something that is polished but without collaboration, and keep collaboration as something that you'll work on if you have the time. Collaboration is actually harder to get right than formulas, IMO. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GSoC idea: Chart/graph-making activity
Jameson Quinn wrote: > > Implementing a whole spreadsheet is a big enough chore. We do really care > about collaboration, but I would advise you to limit your ambitions to > something achievable, so worrying too much about collaboration right now > is > not vital. > I don't plan to create a spreadsheet, just a graph/chart tool. Obviously a full-featured spreadsheet (with functions, formulas, etc.) would be great for Sugar, but I think a simple, user-friendly charting activity would be much more feasible and more likely to actually be used in a primary school/middle school environment. (Full spreadsheet applications are pretty daunting to learn.) I was just throwing out the idea of a spreadsheet-style interface as the most obvious (but not necessarily best) type of interface for this kind of program. -- View this message in context: http://n2.nabble.com/GSoC-idea%3A-Chart-graph-making-activity-tp2517796p2521470.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
Re: [Sugar-devel] GSoC idea: Chart/graph-making activity
Implementing a whole spreadsheet is a big enough chore. We do really care about collaboration, but I would advise you to limit your ambitions to something achievable, so worrying too much about collaboration right now is not vital. Your job right now is to look under the hood and ask questions about the three approaches Benjamin Schwarz (bemasc) mentioned, decide which one you'd prefer to work with, and figure out a plan of work. We'd be happy to answer questions, but you're going to have to get your hands dirty and use your own judgement, I think. When you choose your plan of attack, that will help you get a mentor who shares similar interests. Cheers, Jameson On Mon, Mar 23, 2009 at 8:05 AM, Garrison Benson wrote: > > Would someone be interested in mentoring me in this project? > > Also, a thought about collaboration: > I think it would be quite useful to allow a group of students to share data > and edit it collaboratively in real time. Students working on an experiment > in class could each be assigned to collect a portion of the data, then they > could watch the whole data set be populated piece by piece by their peers. > (We do this kind of thing all the time in my networking class, where we get > response times, packet sizes, whatever, and each fill in one row of a table > using DyKnow.) > -- > View this message in context: > http://n2.nabble.com/GSoC-idea%3A-Chart-graph-making-activity-tp2517796p2521249.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 mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GSoC idea: Chart/graph-making activity
Would someone be interested in mentoring me in this project? Also, a thought about collaboration: I think it would be quite useful to allow a group of students to share data and edit it collaboratively in real time. Students working on an experiment in class could each be assigned to collect a portion of the data, then they could watch the whole data set be populated piece by piece by their peers. (We do this kind of thing all the time in my networking class, where we get response times, packet sizes, whatever, and each fill in one row of a table using DyKnow.) -- View this message in context: http://n2.nabble.com/GSoC-idea%3A-Chart-graph-making-activity-tp2517796p2521249.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
Re: [Sugar-devel] GSoC idea: Chart/graph-making activity
On Sun, Mar 22, 2009 at 1:20 PM, Benjamin M. Schwartz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Garrison Benson wrote: >> A traditional spreadsheet kind of interface would work (something like MS >> Excel or OO.o Calc) but I think a more basic, application-specific interface >> may be more accessible. >> >> Anyway, who's got comments or suggestions? Thanks in advance! > > I think that's a great idea! Many people have started projects to create > spreadsheets for Sugar, but none have finished. > > Some pointers: > http://lists.laptop.org/pipermail/sugar/2008-February/004225.html > http://lists.laptop.org/pipermail/community-news/2008-February/97.html > > Three classes of approaches have been attempted, roughly: > > 1. Sugarize Gnumeric > 2. Socialcalc > 3. A python-based spreadsheet using numpy, matplotlib, pylab, etc. Ben, Any thought on which of these approaches is the most promising or has the most bang for the buck? david > - --Ben > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.9 (GNU/Linux) > > iEYEARECAAYFAknGgYAACgkQUJT6e6HFtqTnEACcCYlbjwFDLOI95Ckhz5qQC9vN > QAUAnRvLaQSrsI2ycjk4IWD0LbRrWRv/ > =m4V9 > -END PGP SIGNATURE- > ___ > 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] GSoC idea: Chart/graph-making activity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Garrison Benson wrote: > A traditional spreadsheet kind of interface would work (something like MS > Excel or OO.o Calc) but I think a more basic, application-specific interface > may be more accessible. > > Anyway, who's got comments or suggestions? Thanks in advance! I think that's a great idea! Many people have started projects to create spreadsheets for Sugar, but none have finished. Some pointers: http://lists.laptop.org/pipermail/sugar/2008-February/004225.html http://lists.laptop.org/pipermail/community-news/2008-February/97.html Three classes of approaches have been attempted, roughly: 1. Sugarize Gnumeric 2. Socialcalc 3. A python-based spreadsheet using numpy, matplotlib, pylab, etc. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknGgYAACgkQUJT6e6HFtqTnEACcCYlbjwFDLOI95Ckhz5qQC9vN QAUAnRvLaQSrsI2ycjk4IWD0LbRrWRv/ =m4V9 -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] GSoC idea: Chart/graph-making activity
My name is Garrison Benson and I'm an undergraduate computer science student at Hope College in Holland, Michigan, USA. I'm interested in participating in Google Summer of Code and I'd like some feedback on my idea... I want to make a Sugar activity that will allow students to create charts and graphs (e.g. pie charts, line graphs, etc.). I haven't been able to find such an activity (SocialCalc can create bar graphs, but nothing else). I see it being useful for formal science experiments, such as the classic "chart the growth of plants over the course of time" experiment that everybody does in primary school. It'd also be cool if it allowed students to view the graph and the data at the same time, so they could modify the data and immediately see the effect on the graph. (It would help students to gain a fundamental understanding of the relationship between the graph and the source data.) It'd also be pretty cool if it could somehow interact with existing activities such as Measure, Ruler, Poll Builder, etc. A traditional spreadsheet kind of interface would work (something like MS Excel or OO.o Calc) but I think a more basic, application-specific interface may be more accessible. Anyway, who's got comments or suggestions? Thanks in advance! -- View this message in context: http://n2.nabble.com/GSoC-idea%3A-Chart-graph-making-activity-tp2517796p2517796.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
