Re: [sugar] 9.1 proposal: View source key everywhere
On Thu, Oct 23, 2008 at 9:19 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote: > 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! I actually don't know what else to add that hasn't been mentioned already in this thread. Maybe Scott would like to do the talk instead as he seems to have something more exciting than me? Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] 9.1 proposal: View source key everywhere
bert wrote: > > 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? sorry i wasn't more clear -- we're in complete agreement. (it was when you said "add a method to the dbus activity protocol" that you pushed my "Must Defend Traditional Apps" button. :-) paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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 - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 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 - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 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 - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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 > [EMAIL PROTECTED] > http://lists.laptop.org/listinfo/sugar > -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
9.1 proposal: View source key everywhere
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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
