[Sugar-devel] Sugar App Launcher

[Tony Anderson]

We are supporting XOs with two architectures. Many of the interesting 
programs are compiled to object code. Therefore, it is not trivial to 
install and test that they work on an XO in gnome. In practice I do this 
on the gnome side. I then switch to Sugar to see that it also works there.

With the limited storage capacity of the XO, installing programs must be 
done selectively. Currently, on XOs with 4GB, I install Libre Office 
because of the obsession education has that computing means Office. 
Gimp, gnumeric, audacity are installed by default. Since Libre Office 
includes calc, gnumeric seems redundant. However, on XOs with 2GB or 1GB 
(XO-1.5, XO-1), Libre Office is not available and gnumeric is an 
alternative.

The wrapper is just that. It enables the gnome application to appear on 
the home view with an icon and be launched from there. Like etoys, 
scratch and other activities, there is no specific sugar adaptation with 
toolbars, saving to the Journal, and so on. It has a byproduct that the 
application itself must be terminated (typical gnome button) and then 
the wrapper must be terminated. In the lists someone made a wrapper with 
subprocess that detected when the application terminated and then 
terminated the wrapper. I haven't explored that because clicking twice 
to quit doesn't seem to pose a problem for users.

I use zim desktop wiki. The wrapper there has some extra capabilities to 
help with export of Zim notebooks to the Journal (requires the notebook 
be zipped as the Journal stores one file per object.

"My understanding of Sebastian's approach is that it would, in fact, be 
a wrapper for these programs, but instead of requiring bespoke wrappers 
be written for each application, it would leverage existing .desktop 
files. This seems further reaching, more sustainable, and better 
integrated with other desktop efforts."

In a standard laptop with 300GB store, the idea of being able to execute 
a wide range of applications in Sugar is appealing.  My understanding 
that Sebastian provides an activity which then offers a menu of the 
installed applications. This may have the advantage of emphasizing the 
difference between Sugar activities and these programs and could make it 
easier to explain the different toolbars, buttons, why the activity 
doesn't show up in the Journal, or support collaboration and so on. On 
the other hand, these activities (audacity, gimp, gnumeric, blender) 
have steep learning curves. I don't know how to address that for an 
open-ended set of programs. For example, I would love to be able to have 
the learners use audacity to edit audio clips made in Record. However, 
this means the learners understand the connection between sound 
frequency and volume and the display on the screen. They would need to 
learn a complicated ui to make clips. On the XO, fine control of the 
cursor is difficult.

Here is an example for GCompris.

         # label with the text, make the string translatable
         label = Gtk.Label(_("GCompris!"))
         self.set_canvas(label)
         label.show()

         # launch GCompris
         pid = Popen('gcompris',shell=True)
         pid.communicate()

This is activity.py from HelloWorld where the only change is to 
substitute GCompris for Hello in the label and to launch GCompris. At 
the top, there is

from subprocess import Popen, PIPE, call

Tony

Tony


On 05/21/2017 10:27 PM, D. Joe wrote:
> On Sun, May 21, 2017 at 08:00:47AM +0800, Tony Anderson wrote:
>
>> On 05/20/2017 08:32 PM, D. Joe wrote:
>>> On Sat, May 20, 2017 at 02:06:55PM +0800, Tony Anderson wrote:
>>>
>>>> Also not disagreeing. I am curious as to the limitation you see in the direct
>>>> execution model and how what you are doing will improve on it. Gnome is the
>>>> desktop we get with Sugar (13.2.8) but I suspect the command line (subprocess)
>>>> technique would work with xfce and others.
>>> If command-line tools were considered acceptable for use by young learners,
>>> we wouldn't have Sugar in the first place. But they're not. What's more,
>>> command line tools are largely seen as unacceptable for the majority of
>>> computer users, whether young learners or not.
>>>
>>> I'm truly befuddled why this is even a question, and I say this as someone
>>> who spends more time than most in a command line.
>> I think you missed the point. The fact that a gnome application runs in
>> sugar from the command line means it works there.
> So far, so good.
>
>> The next step is to write a simple wrapper so that it can be executed from
>> the Home View as an activity.
> Good, I think we're getting to the heart of this question here, which is to
> say, why should this remain the next step?
>
>> I usually start with HelloWorld and insert a subprocess call to
>> the gnome application.
>> This allows the learner to execute Libre Office, gimp, and other
>> applications in the familiar Sugar environment.
> My understanding of Sebastian's approach is that it would, in fact, be a
> wrapper for these programs, but instead of requiring bespoke wrappers be
> written for each application, it would leverage existing .desktop files.
>
> This seems further reaching, more sustainable, and better integrated with
> other desktop efforts.
>
> That is, unless the wrappers you write do something other than launch the
> programs? Say, offer a more native Sugar interface? Are these wrappers
> available somewhere in a public repository better to allow us to compare and
> contrast what they do with what Sebastian proposes?
>