As described in SL#4307 Gtk.Clipboard.set_with_data is not
introspectable, therefore it can't be accessed though python
Gtk bindings.
Therefore, as a workaround for this issue, we provide acesss
to this method though a custom SugarExt binding.
This solution uses Carlos Garnacho annotations as described in
https://bugzilla.gnome.org/show_bug.cgi?id=656312#c18
Fixes SL#4307.
Signed-off-by: Martin Abente Lahaye <tch@sugarlabs.org>
In some network environments, suspend/reume can make loose
messages and break collaboration. This patch inhibit suspend
when collaboration start. The implementation can be used by activities
or Sugar to inhibit suspend/resume when needed.
More information in http://dev.laptop.org/ticket/10363
Signed-off-by: Gonzalo Odiard <gonzalo@laptop.org>
This drops a lot of code at the same time. The code in
__init__ was:
* Using a SUGAR_PREFIX environment variable that is not
defined anywhere
* Hardcoding prefix to /usr
* Setting up the sugar-base domain which doesn't exist anymore
The i18n module code was overcomplex because it was thought
for language packs which we don't support anymore, it was
not handling correctly locales with a country prefix, it
was hard coding the python prefix and it was not sorting
the directories as it intended too anyway.
The logic is very simple now. Use the locale directory in
the same prefix sugar-toolkit-gtk3 was installed, unless
SUGAR_LOCALEDIR is defined (for self contained bundles).
This extension is used by Sugar to set the HIDDEN attribute for
.Sugar-Metadata. By creating an extension, we avoid the need to add an
additional dependency (fatattr) to Sugar. The code is modeled after
fatattr, using an IOCTL call get and set FAT file attributes.
There is a corresponding patch for model.py in sugar/src/jarabe/journal
And use it in the sugar3.mime modules. This allows
to get rid of the pygtk generated sugarbase module,
along with the wrapping code.
Also add more cases to test_time to make sure
everything is still working.
The uitree module exposes the at-spi tree. We can use it to do
functional tests of the UI, by checking if the expected
widgets exists, clicking them etc.
A simple example of how this can be used is in the test, which
runs a window and check that it has the expected button.
In the GTK3 port we mistakenly moved from using the EggSMClientXSMP
class to the (stub-like) EggSMClient base class for Sugar's XSMPClient
class, instantiated for every activity.
This meant that the GTK3 activities weren't registering with the
session manager, meaning that they won't automatically save their work
when the user shuts down, and they can't inhibit shutdown, etc.
Restore this functionality by adding the appropriate header so that
EggSMClientXSMP is introspectable, and then use it from the Python code.
Acked-by: Simon Schampijer <simon@laptop.org>
Listen on RawEvents: listen for raw events on the root
window and decide whether the cursor is shown or not. A
touch begin event will hide the cursor a motion or button
press event will show it.
There is no API in XFixes to know whether a cursor is shown
or not so we keep track of the current state. Furthermore
we trap X errors if any bad access should happen.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Reviewed-by: Carlos Garnacho <carlos@lanedo.com>
Acked-by: Manuel Quiñones <manuq@laptop.org>
The new API is added to SugarExt. Similar to the
KeyGrabber we listen on the root window for the
events. We then filter for gestures recognized by
an event controller.
You can add any event controller of the ones recently
added to the toolkit to be tracked and can pass a
specific area where the starting point of the gesture
should be, it's then allowed to go out of bounds as
it moves.
Signed-off-by: Carlos Garnacho <carlos@lanedo.com>
Acked-by: Simon Schampijer <simon@laptop.org>
SugarEventController is an abstract object that attaches to a widget
and interprets an arbitrary set of events. Implementations of that
object get to define the sequence of events that trigger these.
The basic touch gestures (long press, rotate, swipe, zoom) have
been implemented on top of that object.
Signed-off-by: Carlos Garnacho <carlos@lanedo.com>
Acked-by: Simon Schampijer <simon@laptop.org>
The wm module in sugar-toolkit-gtk3 has been reimplemented
in C and made available through introspection. The same was
hard to achieve directly using the Gdk API.
We can drop wm.py and the wrapper around gdk_property_change.
Signed-off-by: Daniel Narvaez <dwnarvaez@gmail.com>
Acked-by: Simon Schampijer <simon@laptop.org>
gobject introspection bindings for librsvg have been pushed to librsvg
master [1] in 2.35.0, which solved [2]. We only have slight adopts to
make in our usage, for example we can not pass the data property
to the default constructor anymore and get_width and get_height is not
available anymore for the handle, but we can use the properties
instead.
The sugar-toolkit-gtk3 and therefore Activities that have been ported
to it do need a version of librsvg >= 2.35.0 to be able to work,
which ships for example with Fedora 17.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Daniel Drake <dsd@laptop.org>
[1] http://git.gnome.org/browse/librsvg/
[2] https://bugzilla.gnome.org/show_bug.cgi?id=663049
[3] http://developer.gnome.org/rsvg/stable/RsvgHandle.html
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
Probably needs cleaning up a bit. And we use pygtk-codegen, ugh...
This is the commit id when we imported sugar-base:
b9406e5c9c9df5404c5b0d995178b5edb4d93628
Signed-off-by: Daniel Drake <dsd@laptop.org>
[squashed two patches into one]
Signed-off-by: Sascha Silbe <silbe@activitycentral.com>
This makes sugarext accessible through introspection. It is used
from the shell (key grabber, sound volume management) and the
shell session management.
Making the sugarext introspectable was done following the
descriptions at: http://live.gnome.org/GObjectIntrospection#Using_GI
Signed-off-by: Simon Schampijer <simon@schampijer.de>
The old gtk-2 based module will be present in
the 0.94 branch in the sugar-toolkit.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Sascha Silbe <silbe@activitycentral.com>
Martin Abente Lahaye