[Sugar-devel] Sugar App Launcher
tony_anderson at usa.net
Sun May 21 20:58:11 EDT 2017
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
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!"))
# launch GCompris
pid = Popen('gcompris',shell=True)
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
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?
More information about the Sugar-devel