[Sugar-devel] Change request: Fix open with API

[Tony Anderson]

As I understand it, the release of 0.106 is to be made on Monday. This 
does not seem to warrant a delay in that release. Moving a capability 
from sugar or sugar3 to the toolkit doesn't imply a visible change to 
the api as seen by an activity developer.

I don't understand the assumption that downloading a file in Browse to 
the Journal implies that the user wants to access it immediately. For 
example, if I download 'War and Peace', I may want to read it when I get 
the laptop home, not in class. For use with the schoolserver, it was 
necessary to patch Browse to download a pdf to the Journal and not load 
it into a new window. I need to do this also for txt books from Rachel. 
Fortunately, Browse downlaods epub directly to the Journal (the format 
of the Gutenberg books in Internet in a Box).

Browse itself is a problem in this scenario. It (along with the Terminal 
activity) is an exception by providing tabs. It would be useful if the 
launch facility would open a new tab and not launch a new instance of 
Browse when it is already running.

Launching activities based on mime_type is already a problem. How is one 
activity to know whether Browse or Etoys or ImageViewer or Paint  wiil 
respond to a
launch request for an image.

  How is one activity going to determine the activity id (The activity 
id (e.g., 6f7f3acacca87886332f50bdd522d805f0abbf1f) of type STRING as 
passed on the command line 
<http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API#Command_Line_Arguments>) 
of another activity?

Originally, sugar-launch was to pass through options -u (uri) and -o 
(object_id). The version I use does this, so the following code in an 
activity displays an svg:

sugar-launch -u 'file:///home/olpc/Documents/my.svg' org.laptop.WebActivity

Similarly, an activity can use the datastore class to get an object_id 
and use the -o option to, in effect, resume an activity from the Journal.

The only 'trick' is to run sugar-launch from the activity. However, this 
works:

from subprocess import call

call('sugar-launch -u 'file:///home/olpc/Documents/my.svg' 
org.laptop.WebActivity', shell=True)

In the context of the GSOC project, it is important that the Web 
Confusion activity be able to pass a specific html file to Browse for 
use with the interactive javascript shell. This capability is satisfied 
by sugar-launch  with the -u option. However, sugar-launch uses optparse 
which is deprecated in Python 2.7 so the version I am using now has been 
modified it to use argparse.

Using datastore, an activity can launch, for example, Memorize with a 
specific 'game'. So, for example, a teacher is introducing Roman 
numerals. The 'lesson' activity could resume Memorize from the Journal 
with a game on Roman numerals (previously downloaded from the school 
server).

It would seem appropriate to keep the release schedule and do some 
rethinking in the use cases for this feature. Sugar-launch launches the 
activity by the command line and so uses Sugar to perform the launch. It 
would be easy to provide this mechanism to an activity avoiding the 
'subprocess' call (although that is hardly a difficult interface). This 
new feature should at least provide the functionality of sugar-launch.

Tony



On 07/02/2015 09:33 PM, Gonzalo Odiard wrote:
> I found a problem in the implementation of 
> "Start_activity_from_another_activity" feature [1]
> Usually, when the programmer want start one activity from another,
> need display in the user interface information about the activity,
> like the name or the icon.
> One example of the use is in Browse activity [2]
>
> The problem with this is that we are using 
>  jarabe.journal.bundlelauncher.get_bundle()
> and that is part of sugar, not the sugar-toolkit.
> We should not use that code in the activities, because is internal to 
> Sugar,
> and we don't have any warranty of stability.
> I know is very late in the release cycle, but I think is a error ship 
> a release
> with a broken API. After that, activity developers need keep compatibility
> with the api provided in the broken release for ever.
> While the developer can add another try catch, is a source of errors,
> and usually difficult to understand for the developer, because the 
> activity
> will work in different ways given the sugar release.
> This feature was introduced in this cycle, would be good if is 
> provided in a fine state.
>
> I prepared prs for sugar [3] and the toolkit [4]
>
> The change needed in the Browse activity to do the test is only:
>
> --- a/downloadmanager.py
> +++ b/downloadmanager.py
> @@ -37,8 +37,7 @@ from sugar3.graphics.icon import Icon
>  from sugar3.activity import activity
>  try:
> -    from jarabe.journal.bundlelauncher import get_bundle
> -    from sugar3.activity.activity import launch_bundle
> +    from sugar3.activity.activity import launch_bundle, get_bundle
>      _HAS_BUNDLE_LAUNCHER = True
>  except ImportError:
>      _HAS_BUNDLE_LAUNCHER = False
>
> Take this as a formal request to break the freeze to solve this issue.
>
> [1] 
> http://wiki.sugarlabs.org/go/Features/Start_activity_from_another_activity
> [2] 
> https://github.com/sugarlabs/browse-activity/commit/7315fe7d9d951965a7ccd6341d9bc684517cbad8
> [3] https://github.com/sugarlabs/sugar/pull/548
> [4] https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/236
>
> -- 
> Gonzalo Odiard
>
> SugarLabs - Software [for | by] children learning
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20150703/ae98576a/attachment.html>