On 26.11.2008, at 12:07, Tomeu Vizoso wrote: > [cc'ing [EMAIL PROTECTED] because this subject is of importance to > activity authors and I know many haven't yet subscribed to > [EMAIL PROTECTED] Please subscribe!] > > On Tue, Nov 25, 2008 at 5:16 PM, Bert Freudenberg <[EMAIL PROTECTED] > > wrote: >> On 22.11.2008, at 16:35, Simon Schampijer wrote: >> >>> Some great work has been going into this release regarding the 'View >>> source' support. The source of all the activities can be shown, and >>> browse does still support showing the source of the document. >>> >>> === sugar-toolkit === >>> * Add view-source-related methods HandleViewSource and >>> GetDocumentPath >>> >>> === sugar === >>> * Implement a global handler for the view source key >> >> Since I could not find any discussion, let alone documentation about >> this, I (again) got out my rusty Emacs, fed it with some grep'ed >> source files, and reverse-engineered the whole thing. My findings are >> here: > > Sorry, announcing this properly is something that has been in my TODO > for a while, but hadn't managed to get to it yet. > >> http://wiki.laptop.org/go/Low-level_Activity_API#D-Bus_Methods > > All looks good to me. > >> I like the idea so far, but here are the issues I have with the >> current implementation: >> >> 1. HandleViewSource should return a boolean to indicate whether the >> request was handled or not. >> This would also get rid of the Python-specific dbus error handling >> code in viewsource.py because handle_view_source in activity.py could >> simply answer False. > > Hmm, but we still need to handle the case where a non-python activity > hasn't implemented the method, right?
Oh certainly, the logic is sound, it's just the "not implemented" Pythonism there that is not necessary. >> 2. GetDocumentPath is a poor name for what it does. >> It should contain "source" because it's not the document that is >> viewed, but its source. How about GetSourcePath()? > > Well, the idea is that, by default, sugar will show the activity's > source. This method is intended for displaying a textual > representation of the sources behind a document, be it html for > browse, logo for turtleart, etc. So perhaps getDocumentSourcePath()? Sure. >> Also, this file is deleted unconditionally when the source view is >> closed. I'd add a boolean "transfer_ownership" flag to indicate that >> it's okay to delete (similar to the datastore API). > > Sounds good, if activity authors think this added complexity is ok, I > can add it. Well, it's more complexity to having to make a copy just so Sugar can delete it ... >> Also, what kinds of source does this support? I noticed the >> Browser's HTML source was highlighted. Is that determined by the file >> name extension? > > The sugar shell tries its best to display a formatted view of the > source code based on the extension and the contents of the file. > Currently, it uses gtksourceview2 for that. If an activity author > would like an improved or new formatter, we should talk to the > upstream maintainers to add it. It's quite configurable and should be > a matter of editing some xml files. Also, the call could additionally answer a mime type which would override the guessing. >> On a more general note, activityservice.py should be annotated with >> the actual DBus signatures. > > True, added it to my TODO at http://sugarlabs.org/go/User:Tomeu :) - Bert - _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar