[Sugar-devel] View Source
tomeu at sugarlabs.org
Tue Dec 9 04:21:16 EST 2008
On Wed, Nov 26, 2008 at 12:20 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 26.11.2008, at 12:07, Tomeu Vizoso wrote:
>> [cc'ing sugar at laptop.org because this subject is of importance to
>> activity authors and I know many haven't yet subscribed to
>> sugar-devel at sugarlabs.org. Please subscribe!]
>> On Tue, Nov 25, 2008 at 5:16 PM, Bert Freudenberg <bert at freudenbergs.de>
>>> 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
>> Sorry, announcing this properly is something that has been in my TODO
>> for a while, but hadn't managed to get to it yet.
>> 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()?
>>> 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 ...
Agreed, I'm starting to think that we are going to have to add a
similar parameter to all functions in sugar that accept a temp file
path, so we can make very clear what the surrounding code needs to do
in order to properly dispose temp files.
>>> 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.
Yes, one more policy decision I'm thinking of lately is to only guess
mime types as fallbacks and do all that is possible to pass mime types
Thanks for the ideas,
>>> 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 -
More information about the Sugar-devel