Re: [sugar] 9.1 Proposal: Printing support
On Thu, Oct 23, 2008 at 4:31 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Tue, Oct 21, 2008 at 8:57 AM, [EMAIL PROTECTED] wrote: can's mdns/avahi help with discovery? it'd be a shame to have to manually configure a server address or name. DNS-SD is the Right Answer (which is not exactly the same thing as mdns). But getting a standard one school server, and a classroom of XOs solution in place for 9.1 using a standard name (printer, say) would be a good first step; we can handle autodiscovery (via CUPs or something else) for 9.2. For the 9.1 timeframe we have several services that we'll want to coordinate XS and XO so we need a reasonably good answer at least. I hadn't heard of DNS-SD so I'll make sure we check it out. ... We should not ignore the fact that OLPCs are deployed in places like Birmingham and Montevideo, which have abundant access to paper and printers. Ah, yes. On this thread people are arguing quite strongly for their personal (and opposed) views, I can't quite figure out why. We'll add a tool, and people will be smart and use it where appropriate. And whether they print or not, the world won't end. One thing I do want to mention -- an overly simplisting printing tool will land us in hot water. If we do printing, we better pay attention to the standard dialogs and provide most of the options in there, lest we replay the Torvals-vs-gnome flamefest. (Now, flag this point for _later_ discussion. What optiosn to provide and not provide is a big flamefest of its own, but let's have it a bit later. ) cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Proposals for XO Mini-conference Due by Monday October 27
Hi All, We are planning a mini-conference at OLPC headquarters November 17 - 21. For more information, see the conference wiki page at: http://wiki.laptop.org/go/XOcamp_2 Please post any proposals for talks directly on the wiki page at: http://wiki.laptop.org/go/XOcamp_2#Proposals Starting at the end of the day US ET, Monday October 27th we will review all proposals and begin setting the agenda for the conference. Create a new section as needed and make sure your proposed subjects for the mini-conference are on the wiki by Monday, October 27! Discussion on the lists is useful but its not enough to get a proposal on the agenda. You must also, create a section in the wiki. I will review all e-mails to the [EMAIL PROTECTED] e-mail address. I will forward any that weren't copied to the devel list and I will extract the ones that look like proposals for inclusion in the wiki. In contrast to proposals for the mini-conference, well motivated feature suggestions go on our Feature Roadmap at: http://wiki.laptop.org/go/Feature_roadmap#Requirements_and_Feature_Suggestions In short, proposals for talks at the conference go on the XOcamp_2 wiki page and specific feature and coding work go on our Feature Roadmap page. This is the idea gathering phase (similar to brainstorming). Not everything on the wiki will get built but it must be on the wiki to get considered. Its up to you to add features for the roadmap and proposals for the conference! Please have at it and let me know if you have any questions. Thanks, Greg S ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 proposal: View source key everywhere
I think that any activity that goes to the trouble of building their own view source mechanism can handle the added overhead of adding a line to the activity.info file. Seems like that is the easiest path. Doesn't it have any negative repercussions in the long term? -walter On Thu, Oct 23, 2008 at 8:53 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Hi, I think that with a small effort, we could implement something much better than what we have today. We have glorious plans for the view source key, but as no resources have been devoted to them, perhaps we should scale back and make sure that we provide the best we can today. And let the future deal with the dreams. Have hacked a quick way of displaying the contents of the currently active activity bundle, along with displaying the source code if the activity ships its source inside the bundle. Screenshot of Implode's source: http://dev.laptop.org/~tomeu/viewsource.png The approach I have followed is installing a global keybinding that is handled in the shell. If you want to try it, it's a matter of dropping the file in the url below into ~/sugar-jhbuild/install/share/sugar/extensions/globalkey, if you have a recent enough sugar-jhbuild. http://dev.laptop.org/~tomeu/viewsource.py This approach has a good thing that is that works everywhere, but has a major problem: doesn't let activities override it and handle themselves the view source key event. This is very bad for activities like Etoys, the ones produced by Pippy or activities that would prefer to display the source code for the _content_ loaded in that moment (Browse). Alternative 1: Move it to sugar-toolkit, would be available to all python activities, and activities would be able to override it easily. Inconvenient: non-python activities wouldn't benefit from it. Alternative 2: Add a mechanism for the shell to know if an activity wishes to provide its own view source window. It could be done by adding one more D-Bus method or by adding one more property to activity.info. Inconvenient: adds complexity to activity development. Opinions? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 proposal: View source key everywhere
tomeu -- excellent! thanks for helping make progress on this. tomeu wrote: http://dev.laptop.org/~tomeu/viewsource.py This approach has a good thing that is that works everywhere, but has a major problem: doesn't let activities override it and handle themselves the view source key event. This is very bad for activities like Etoys, the ones produced by Pippy or activities that would prefer to display the source code for the _content_ loaded in that moment (Browse). the ultimate fallback would simply be a URL, with which Browse could take you to a (hopefully friendly) source browser on the web somewhere -- to browse CVS or git, for instance, or even just to an upstream program-specific website where more information is available. as you implied, flexibility is the key. Alternative 1: Move it to sugar-toolkit, would be available to all python activities, and activities would be able to override it easily. Inconvenient: non-python activities wouldn't benefit from it. Alternative 2: Add a mechanism for the shell to know if an activity wishes to provide its own view source window. It could be done by adding one more D-Bus method or by adding one more property to activity.info. Inconvenient: adds complexity to activity development. an addition to activity.info, with sensible defaults, would be the best bet, i think. default behaviors could include going to bundled source, as you've implemented, and/or using the activity_source URL that many activities provide on the download page on the wiki. paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 proposal: View source key everywhere
Am 23.10.2008 um 14:53 schrieb Tomeu Vizoso: Hi, I think that with a small effort, we could implement something much better than what we have today. We have glorious plans for the view source key, but as no resources have been devoted to them, perhaps we should scale back and make sure that we provide the best we can today. And let the future deal with the dreams. Have hacked a quick way of displaying the contents of the currently active activity bundle, along with displaying the source code if the activity ships its source inside the bundle. Screenshot of Implode's source: http://dev.laptop.org/~tomeu/viewsource.png The approach I have followed is installing a global keybinding that is handled in the shell. If you want to try it, it's a matter of dropping the file in the url below into ~/sugar-jhbuild/install/share/sugar/extensions/globalkey, if you have a recent enough sugar-jhbuild. http://dev.laptop.org/~tomeu/viewsource.py This approach has a good thing that is that works everywhere, but has a major problem: doesn't let activities override it and handle themselves the view source key event. This is very bad for activities like Etoys, the ones produced by Pippy or activities that would prefer to display the source code for the _content_ loaded in that moment (Browse). Alternative 1: Move it to sugar-toolkit, would be available to all python activities, and activities would be able to override it easily. Inconvenient: non-python activities wouldn't benefit from it. Alternative 2: Add a mechanism for the shell to know if an activity wishes to provide its own view source window. It could be done by adding one more D-Bus method or by adding one more property to activity.info. Inconvenient: adds complexity to activity development. Opinions? This would definitely be an improvement :) I'd add a DBus method to the activity protocol answering a boolean. If the activity answers False (or does not implement the method) the system would do its best to show the source. If it answers True, the activity handled the request on its own. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 proposal: View source key everywhere
Am 23.10.2008 um 15:15 schrieb [EMAIL PROTECTED]: an addition to activity.info, with sensible defaults, would be the best bet, i think. This would mean that sometimes the shell and sometimes the activity would have to handle that key, which is fragile. I'd opt for the shell always handling the key, then trying to invoke the activity's view source function, and if that fails, handle it itself. That not handled by activity case could of course be customized by entries in activity.info. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 proposal: View source key everywhere
bert wrote: Am 23.10.2008 um 15:15 schrieb [EMAIL PROTECTED]: an addition to activity.info, with sensible defaults, would be the best bet, i think. This would mean that sometimes the shell and sometimes the activity would have to handle that key, which is fragile. I'd opt for the shell always handling the key, then trying to invoke the activity's view source function, and if that fails, handle it itself. That not handled by activity case could of course be customized by entries in activity.info. sure, that's fine. but i think we need to keep thinking about how to support of non-, or not-fully-sugarized applications with every new feature we do (as well as with every revision of old features). paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 proposal: View source key everywhere
Am 23.10.2008 um 15:33 schrieb [EMAIL PROTECTED]: bert wrote: Am 23.10.2008 um 15:15 schrieb [EMAIL PROTECTED]: an addition to activity.info, with sensible defaults, would be the best bet, i think. This would mean that sometimes the shell and sometimes the activity would have to handle that key, which is fragile. I'd opt for the shell always handling the key, then trying to invoke the activity's view source function, and if that fails, handle it itself. That not handled by activity case could of course be customized by entries in activity.info. sure, that's fine. but i think we need to keep thinking about how to support of non-, or not-fully-sugarized applications with every new feature we do (as well as with every revision of old features). Right. Hence the fallback to the default viewer if the activity does not implement that (or any) DBus method. Or did I misunderstand you? - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 proposal: View source key everywhere
On Thu, Oct 23, 2008 at 9:33 AM, [EMAIL PROTECTED] wrote: sure, that's fine. but i think we need to keep thinking about how to support of non-, or not-fully-sugarized applications with every new feature we do (as well as with every revision of old features). I've got a half-baked idea about support 'view source' in unmodified applications using a similar mechanism to the one I'd considering for Translate. This might give a better 'default' behavior for some activities written in python, but I like Tomeu's approach for the rest. And the general idea of having a standard mechanism to register your own 'view source' handler is great. Maybe I'll get some time to hack that up before Nov 17. In any case, I look forward to Tomeu's talk! --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] GNOME journal
http://www.gnome.org/~federico/news-2008-10.html#23 It's nice to not feel alone in this space anymore, isn't it?? Also finally a little of credit which doesn't hurt :) Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Control Facility Improvements
Mikus Grinbergs wrote: I'm requesting discussion of two other improvements to control facilities: One more? Software Updates defaults all available Activities pre-selected. Their boxes checked, in other words. I would rather choose the updates I want than de-select the ones I don't. Some of the Activity Groups are huge. It's a hassle clicking on the many not wanted to download a few. -- View this message in context: http://n2.nabble.com/9.1-Proposal%3A-Control-Facility-Improvements-tp1365887p1370509.html Sent from the OLPC Sugar mailing list archive at Nabble.com. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Control Facility Improvements
I can sympathize with this perspective. Traditionally, software updates only update software which is already installed. In this perspective, I could see one expecting all those activities already installed being selected by default, and others left unchecked for one to select as desired. On the other hand, I appreciate that our primary use case is for deployments and entire schools of kids, where the set of activities chosen for the update has been carefully selected by the school, and might include a handful of new or customized activities for the upcoming school year, for instance. In such a scenario, selecting all by default is clearly desired. I'm not sure what the answer is. Offering a flag with the activity pack somehow could work, I suppose, but makes the idea less pure. Maybe adding buttons for select all/deselect all and select installed would be better, to make managing the selection easier and more exposed, could work. Or, perhaps better, we could offer a smart activity pack in the list for Installed activities which then presents a list of all installed activities (checked by default, just like the other activity packs). - Eben On Thu, Oct 23, 2008 at 9:09 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Thu, Oct 23, 2008 at 9:07 PM, genesee [EMAIL PROTECTED] wrote One more? Software Updates defaults all available Activities pre-selected. Their boxes checked, in other words. I would rather choose the updates I want than de-select the ones I don't. Some of the Activity Groups are huge. It's a hassle clicking on the many not wanted to download a few. Right-click, unselect all. Voila! If only all our 9.1 features were already implemented. ;-) --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Control Facility Improvements
Of course you are right. I see now how my perspective as an isolated G1G1 user does not always jive with the primary XO users, A.K.A. the children of the world! If specific deployments are using custom Activity Groups, then my point is moot. My experience is with the various groups on the wiki, joyride, G1G1 etc., some of which are massive. Thanks for the tip, Scott. I only feel slightly silly. Eben Eliason wrote: On the other hand, I appreciate that our primary use case is for deployments and entire schools of kids, where the set of activities chosen for the update has been carefully selected by the school, and might include a handful of new or customized activities for the upcoming school year, for instance. In such a scenario, selecting all by default is clearly desired. I'm not sure what the answer is. Offering a flag with the activity pack somehow could work, I suppose, but makes the idea less pure. Maybe adding buttons for select all/deselect all and select installed would be better, to make managing the selection easier and more exposed, could work. Or, perhaps better, we could offer a smart activity pack in the list for Installed activities which then presents a list of all installed activities (checked by default, just like the other activity packs). - Eben On Thu, Oct 23, 2008 at 9:09 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Right-click, unselect all. Voila! If only all our 9.1 features were already implemented. ;-) --scott ¡Gracias! -genesee -- View this message in context: http://n2.nabble.com/9.1-Proposal%3A-Control-Facility-Improvements-tp1365887p1370618.html Sent from the OLPC Sugar mailing list archive at Nabble.com. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
