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

[Gonzalo Odiard]

Ok, I will do.
Thanks all for the review and comments.

Gonzalo

On Fri, Jul 3, 2015 at 2:55 PM, Martin Abente <
martin.abente.lah...@gmail.com> wrote:

> Considering that James, Sam and I have reviewed and tested these changes,
> the consensus is to include them to fix the API. Therefore, Gonzalo has
> green light for merge.
>
> On Fri, Jul 3, 2015 at 5:41 AM, Tony Anderson 
> wrote:
>
>>  Thanks James and Sam for your replies.
>>
>> The references to Rainbow Security model are a bit confusing. The Rainbow
>> model was dropped by the second G1G1 as I recollect. As far as I can tell,
>> Browse launches child processes (pdfviewer). These typically are
>> represented in the frame by a grey circle.
>>
>> I apologize on the argparse issue, I am still with 13.2. I was confused
>> by the documentation:
>> http://wiki.sugarlabs.org/go/Features/Start_activity_from_another_activity
>>
>> "An activity can start other activity by:
>>
>>- knowing the activity ID - starts that specific activity"
>>
>> I assume that is a typo and bundle_id is meant.
>>  By having sugar-launch pass the -u (uri) and -o (object_id) options, it
>> is possible now (and possibly since 0.82) to launch an activity by activity
>> bundle_id either with a Journal object or a file from the Documents
>> directory (visible in Journal) or a USB key (also visible in Journal).  I
>> have been using the -o and -u options in sugar-launch for at least five
>> years. This was discussed when this feature was first proposed.
>>
>> In effect, the api added to 106 is simply an alternate way to perform
>> existing functions.
>>
>> Tony
>>
>> On 07/03/2015 09:29 AM, Sam P. wrote:
>>
>> Hi Tony,
>>
>> I think you have misunderstood the capabilities of the api.
>>
>> The api does not support launching with uris (which is something to look
>> into for 108) or "activity ids".
>>
>> The api supports bundle ids (open a new terminal activity) and object ids
>> (open this memorize set).  This allows for many of the use cases you
>> described although being very simple.
>>
>> Directly using sugar-launch from activity processes is suboptimal, as
>> activities should not launch child processes (Rainbow security model).
>> This was discussed when the feature was being implemented.
>>
>> I do not see why a feature that has some use cases and does not
>> destabilise the rest of the system should be dropped so late in the cycle.
>>
>> Thanks,
>> Sam
>>
>>
>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>


-- 
Gonzalo Odiard

SugarLabs - Software [for | by] children learning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

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

[Martin Abente]

Considering that James, Sam and I have reviewed and tested these changes,
the consensus is to include them to fix the API. Therefore, Gonzalo has
green light for merge.

On Fri, Jul 3, 2015 at 5:41 AM, Tony Anderson  wrote:

>  Thanks James and Sam for your replies.
>
> The references to Rainbow Security model are a bit confusing. The Rainbow
> model was dropped by the second G1G1 as I recollect. As far as I can tell,
> Browse launches child processes (pdfviewer). These typically are
> represented in the frame by a grey circle.
>
> I apologize on the argparse issue, I am still with 13.2. I was confused by
> the documentation:
> http://wiki.sugarlabs.org/go/Features/Start_activity_from_another_activity
>
> "An activity can start other activity by:
>
>- knowing the activity ID - starts that specific activity"
>
> I assume that is a typo and bundle_id is meant.
>  By having sugar-launch pass the -u (uri) and -o (object_id) options, it
> is possible now (and possibly since 0.82) to launch an activity by activity
> bundle_id either with a Journal object or a file from the Documents
> directory (visible in Journal) or a USB key (also visible in Journal).  I
> have been using the -o and -u options in sugar-launch for at least five
> years. This was discussed when this feature was first proposed.
>
> In effect, the api added to 106 is simply an alternate way to perform
> existing functions.
>
> Tony
>
> On 07/03/2015 09:29 AM, Sam P. wrote:
>
> Hi Tony,
>
> I think you have misunderstood the capabilities of the api.
>
> The api does not support launching with uris (which is something to look
> into for 108) or "activity ids".
>
> The api supports bundle ids (open a new terminal activity) and object ids
> (open this memorize set).  This allows for many of the use cases you
> described although being very simple.
>
> Directly using sugar-launch from activity processes is suboptimal, as
> activities should not launch child processes (Rainbow security model).
> This was discussed when the feature was being implemented.
>
> I do not see why a feature that has some use cases and does not
> destabilise the rest of the system should be dropped so late in the cycle.
>
> Thanks,
> Sam
>
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

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

[Tony Anderson]

Thanks James and Sam for your replies.

The references to Rainbow Security model are a bit confusing. The 
Rainbow model was dropped by the second G1G1 as I recollect. As far as I 
can tell, Browse launches child processes (pdfviewer). These typically 
are represented in the frame by a grey circle.


I apologize on the argparse issue, I am still with 13.2. I was confused 
by the documentation: 
http://wiki.sugarlabs.org/go/Features/Start_activity_from_another_activity


"An activity can start other activity by:

 * knowing the activity ID - starts that specific activity"

I assume that is a typo and bundle_id is meant.

By having sugar-launch pass the -u (uri) and -o (object_id) options, it 
is possible now (and possibly since 0.82) to launch an activity by 
activity bundle_id either with a Journal object or a file from the 
Documents directory (visible in Journal) or a USB key (also visible in 
Journal).  I have been using the -o and -u options in sugar-launch for 
at least five years. This was discussed when this feature was first 
proposed.


In effect, the api added to 106 is simply an alternate way to perform 
existing functions.


Tony

On 07/03/2015 09:29 AM, Sam P. wrote:


Hi Tony,

I think you have misunderstood the capabilities of the api.

The api does not support launching with uris (which is something to 
look into for 108) or "activity ids".


The api supports bundle ids (open a new terminal activity) and object 
ids (open this memorize set).  This allows for many of the use cases 
you described although being very simple.


Directly using sugar-launch from activity processes is suboptimal, as 
activities should not launch child processes (Rainbow security 
model).  This was discussed when the feature was being implemented.


I do not see why a feature that has some use cases and does not 
destabilise the rest of the system should be dropped so late in the cycle.


Thanks,
Sam



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

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

[Sam P.]

Hi Tony,

I think you have misunderstood the capabilities of the api.

The api does not support launching with uris (which is something to look
into for 108) or "activity ids".

The api supports bundle ids (open a new terminal activity) and object ids
(open this memorize set).  This allows for many of the use cases you
described although being very simple.

Directly using sugar-launch from activity processes is suboptimal, as
activities should not launch child processes (Rainbow security model).
This was discussed when the feature was being implemented.

I do not see why a feature that has some use cases and does not destabilise
the rest of the system should be dropped so late in the cycle.

Thanks,
Sam

On Fri, 3 Jul 2015 3:15 pm Tony Anderson  wrote:

>  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
> )
> 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 a

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

[James Cameron]

On Fri, Jul 03, 2015 at 07:14:47AM +0200, Tony Anderson wrote:
> As I understand it, the release of 0.106 is to be made on Monday.

Yes.

> This does not seem to warrant a delay in that release.

This is maintainer Martin's decision that you're offering your opinion
on, but I'll offer a countering opinion; the delay is warranted
because:

1.  the problem at hand is a defect in a new feature being added to
the release, and it need not be.  The feature can be dropped or fixed.

2.  the delay, if any, is minimal, of the order of hours to break the
code freeze to either revert patches or merge the pull requests.

The risk is low.  The new pull requests have been reviewed, and tested
on Fedora 18, 21, 22, and Ubuntu.

The benefit is good.

I'm fine with either feature drop or fix.  I prefer fix.  I'm against
releasing 0.105.3 as 0.106 without change.

Thanks to Sam for pushing the feature through the process.

http://wiki.sugarlabs.org/go/Development_Team/Release#Hard_code_freeze
http://wiki.sugarlabs.org/go/Features/Start_activity_from_another_activity

> 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.

The new patch is not a moving of capability, but adding a capability
that does not exist in the activity toolkit.

Gonzalo is correct that activities should not use the Sugar internal
API, because it is not controlled, and not intended for use by
activities.

Until Browse 157.1, none of the activities have "from jarabe".  Jarabe
is a reference to the internal API.

@Gonzalo, we will also need a new Browse release.

@Tony, the rest of your mail is orthogonal; a discussion of the
feature and use case.  It's a bit late for that, unless the feature is
dropped and needs to go back to design phase.  I'd like to rule it out
of order, but there's a couple of things to say ...

> I don't understand the assumption that downloading a file in Browse
> to the Journal implies that the user wants to access it
> immediately.

It doesn't assume that.  I doubt you've even tested this?  It offers
to access it, but does not require it.  There's no new dialog; it used
to be the download completed dialog.

> 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 [1] command line) 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.

No, sugar-launch uses argparse, please catch up.

> 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

Re: [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 
) 
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] 

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

[Martin Abente]

Hello Gonzalo,

To me this is basically a new feature, in terms of how it does impact sugar
(adding new method to the activity class and adding a new dbus endpoint to
the shell).

It breaks feature, API and code freezes. I believe the change is kind of
sensible considering what it does and specially since we are 3 days away
from the final release. Last week we landed a lot of trivial fixes, and
even then we needed an extra week to discover a serious issue with
sugar-artwork caused by one of these fixes, so certainly this could be more
dangerous.

Regarding the broken API, I see this differently, I don't think its about
adding an extra "try catch". If the API is broken (because its use depends
on other method which shouldn't be allowed), then this feature should only
be used when both "launch_bundle" _and_ "get_bundle" are present (since
using the other method shouldn't be allowed anyway). Technically, this can
be seen as if this feature was not release yet (and we should not allow or
recommend its use until its really complete).

Now, if you still want to include it before Monday, then I think that you
should test it extensively in fc18 (and newer) and ubuntu 14.04, making
sure it works OK and that there are no other unwanted side effects (e.g, on
activities that does not this feature it or other services that consumes to
that dbus service).

Let me know what you want to do,
Martin.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

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

[Gonzalo Odiard]

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@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel