[sugar] [Sugar-devel] View Source
Bert Freudenberg
bert at freudenbergs.de
Wed Nov 26 06:20:54 EST 2008
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
> > 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 -
More information about the Sugar
mailing list