Move code from shell ActivityIcon to new class CanvasIcon, that will
allow to reuse it in other icons. This class inherits EventIcon and
adds state and drawing handling. The right-click callback for the
palette invoker is not needed.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
Using the deprecated GtkStyle is giving an error [1] in the sugar
alert.
[1] http://bugs.sugarlabs.org/ticket/3907#comment:3
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
Listen to the 'request-clear-area' and 'unset-clear-area'
of the widget and adjust allocation accordingly.
Signed-off-by: Carlos Garnacho <carlos@lanedo.com>
Acked-by: Simon Schampijer <simon@laptop.org>
As discused in the mailing list [1] the api to set the icon in sugar
ToolButton, RadioToolButton and ToggleToolButton is inconsistent,
and with the port to GTK+ 3 the differences are visible (SL #3849).
This patch changes the API of ToolButton, RadioToolButton and
ToggleToolButton to override the icon-name property and add an
Icon instance with the set_icon_widget method.
Signed-off-by: Gonzalo Odiard <gonzalo@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
[1] http://lists.sugarlabs.org/archive/sugar-devel/2012-September/039624.html
Sugar crashes if the sugar theme has not been set (in sugar-session)
in the set_icon_from_name method since some if the requested icons
can not be found. Handle that case cleanly.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
As Palettes can either include a Gtk.Menu or a Gtk.Window we
have to use a "false" menu when we want to have both
functionality in a Palette. This is a new class PaletteMenuItem
for those use cases.
Code highly based on the work from Gonzalo Odiard. The API is
based on the one from GtkImageMenuItem [1].
[1] http://developer.gnome.org/gtk3/3.4/GtkImageMenuItem.html
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
Make the first item of the menu a custom class, to make the children
widget allocate using all the available space. And so it can be
styled in the theme.
Remove the set_sensitive(False) from the header item, because the icon
was greyed out. This was to make it an informational, unclickeable
item. I am making it look like an informational item in the theme
instead. This has the problem that its still navigateable with
keyboard and clickeable, so it has to be fixed later.
Add a separator below the header. Is a custom class so it can be
styled in the theme.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
The styling of this toolbar elements should be ported to the theme at
one point.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
We are adding the x value twice (from the allocation and from the origin)
in get_rect of the WidgetInvoker which we derive from in the FrameInvoker.
In the toolkit-gtk2 code [1] we did add the allocation.x value when
the widget does not provide its own gtk.gdk.Window (gtk.NO_WINDOW) [2]. This
is the same check we do above if the widget has a window and we set x and y
to 0 there which sounds sane enough to me.
[1] d1f68419e7/src/sugar/graphics/palettewindow.py (line716)
[2] http://www.pygtk.org/docs/pygtk/class-gtkobject.html#method-gtkobject--flags
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
- the GtkCellRenderer (which our CellRenderer derives from) is not a
GtkWidget and therefor the 'get_display' method does not exist, we
fallback to the default display in that case [1]
- the get_rect method should return a Gdk.Rectangle now, see other
invokers
- check if event.mode is Gdk.CrossingMode.NORMAL to trigger a mouse
leave see 289787e8c6 for a similar
case
- todo: the Palette does not go away when the mouse leaves the
widget
[1] http://developer.gnome.org/gtk3/3.4/GtkCellRenderer.html
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
We do not apply the clipping rectangle in do_render, we
need to call clip on the cairo_t as well. This solves the
issue in the Journal and in the Activity List View where
the icons do only appear on hovering over them.
See gtk_cell_renderer_render [1] for background information.
[1] http://git.gnome.org/browse/gtk+/tree/gtk/gtkcellrenderer.c#n731
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
The convert script pygi-convert.sh commented out the call to
info.get_attach_points() in commit 820efa56
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
Like in the WidgetInvoker we check now first if the leave
event has the mode Gdk.CrossingMode.NORMAL, only then we trigger
a mouse leave to popdown the Palette. This stops the Palette
to appear/disappear in a loop.
Signed-off-by: Simon Schampijer <simon@laptop.org>
First of all 'Gdk.CairoContext' does not exist, this has been
made up by the conversion script in 820efa56b9
We do not need the previous gtk.gdk.CairoContext here anymore, we
do only want to set the background of the context here. See the
toolkit-gtk2 commit where this has been simplified [1].
[1] 6ce463585c
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
In pygtk custom cellrenderers were done inheriting
gtk.GenericCellRenderer, and overriding the on_* methods. Now we
inherit Gtk.CellRenderer and the methods to override changed to do_* .
The destroy signal was moved to Gtk.Widget [1] so the Gtk.CellRenderer
doesn't have it anymore. Now we do the cleanup in the python
destructor method. A testcase tests/graphics/customdestroy.py shows
how is done.
tests/graphics/cellrenderericon.py tests the usage.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
[1] http://developer.gnome.org/gtk3/stable/ch24s02.html#id1459754
Draw a black background in the buttons when the palette is up, as
commit 01a06943 did with the ToolButton. As the comment for that
commit states, we can change the prelight background color in the
theme, but not when the mouse moves over the Palette.
Also add testcase to test the three toolbuttons.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
Use clicked instead of button-pressed-event, because button-pressed-event
and the button-release-event are not emitted on a touchscreen device by
a touch in GTK+ 3.
Signed-off-by: Gonzalo Odiard <gonzalo@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
This patch solves the following problems:
* API changed in the drag and drop code in Gtk.
Drag and drop is not working yet (SL #3796)
but the code needed to enable drag and drop is ported.
* Changes in the way to get color information from the theme
this is because Gtk.Style was deprecated by Gtk.StyleContext.
* The internal button was not visible.
Signed-of-by: Gonzalo Odiard <gonzalo@laptop.org>
-----
v2: Fixed comment based on manuq feedback, and add a note
about the non working drag and drop.
The icon consists of an GtkEventBox and an IconBuffer. The
GtkEventBox is a subclass of GtkBin which has its own window and
therefor is used to catch events for our IconBuffer which does
not have it's own window. The window of the EventBox is
made invisible.
The EventIcon does not emit the 'activated' signal when clicked
anymore, you can listen to 'button-release-event' to know
when the icon has been clicked. The EventIcon uses the
CursorInvoker to invoke a palette the same way as the
CanvasIcon did.
We keep the same API as with the CanvasIcon, only the 'size'
property is changed to be called 'pixel_size' in order to
make clearer which values it expects to be passed. We don't
expect a GtkIconSize to be passed here.
Another option would have been to put a SugarIcon inside a
a GtkEventBox and make the properties available through an
icon property but the API would have not been as nice and
logically it seems to make more sense to have the IconBuffer
being the base for both the SugarIcon and the SugarEventIcon.
This patch has ben developed based on the one that is
used in the shell port.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Reviewd-by: Benjamin Berg <benzea@sugarlabs.org>
The create_palette mechanism allows to create
palettes on demand and not for each icon upfront
whether it will be needed or not.
If you hover over an EventIcon and there is no
palette already associated with the Invoker, the Invoker
will call create_palette to see if it can be created
on demand. With this patch the EventIcon will return None
here (see as well CellRendererIcon or ToggleToolButton which
are having the same default behavior).
When subclassing EventIcon the create_palette method can
be overwritten and a Palette returned (see for example
the ActivityIcon in the HomeView).
Without this patch you can see tracebacks when hovering
over the EventIcon because the Invoker tries to call
create_palette.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Reviewed-by: Benjamin Berg <benzea@sugarlabs.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
Position the event box window above the windows of its child, that way
all events inside the event box will go to the event box. If the window is
below, events in windows of child widgets will first go to that widget,
and then to its parents [1].
[1] http://developer.gnome.org/gtk3/3.4/GtkEventBox.html#gtk-event-box-set-above-child
Signed-off-by: Simon Schampijer <simon@laptop.org>
Reviewed-by: Benjamin Berg <benzea@sugarlabs.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
We do use the EventBox only to receive events, hence the
window that the even box creates should be a GDK_INPUT_ONLY
window, which means that it is invisible and only serves to
receive events [1].
[1] http://developer.gnome.org/gtk3/3.4/GtkEventBox.html#gtk-event-box-set-visible-window
Signed-off-by: Simon Schampijer <simon@laptop.org>
Reviewed-by: Benjamin Berg <benzea@sugarlabs.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
The _ToolbarPalette does get passed the invoker on
initialisation. But we do create the PaletteWindowWidget
later. We do attach the invoker to the widget when calling
_setup_widget that is why it was still working without that
patch.
This patch prevents the traceback that we had because of not
having a widget at this point.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Tested-by: Manuel Quiñones <manuq@laptop.org>
set_data/get_data not available anymore is not available anymore [1]. The
recommended approach is using a python attribute, which we do.
Changing to use the attribute in the activity class slipped by mistake
into 6330204e91.
[1] https://bugzilla.gnome.org/show_bug.cgi?id=641944
Signed-off-by: Simon Schampijer <simon@laptop.org>
Tested-by: Manuel Quiñones <manuq@laptop.org>
Sugar ToolButton inherits from Gtk.ToolButton but is not overwriting
'icon_name' property. So 'icon_name' can be passed to the constructor
of Sugar ToolButton but the result is different than setting it via
ToolButton.props.icon_name.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
In GDK3 the 'xid' attribute is gone and is replaced with
gdk_x11_window_get_xid(), or the get_xid() method in Python.
Needed to be able to open the object chooser from Browse without hassle.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
The minimum height/width requested by the GtkViewport still tries to cater
for all contained children, which makes the [VH]Tray widgets to grow as
new items are added. Instead, request a minimum width/height of 0 to avoid
the Tray from growing, and having scrolling kick in instead.
Also, fixed what seemed to be a typo in do_get_preferred_height(), where
the viewport width was requested instead.
http://bugs.sugarlabs.org/ticket/3522
Signed-off-by: Carlos Garnacho <carlos@lanedo.com>
Acked-by: Simon Schampijer <simon@laptop.org>
The accelerator in the primary information in the Palette
has not been drawn because there was not enough space
reserved for it. The preferred size we get back for the
Palette window does not include the accelerator of the
Gtk.AccelLabel. We need to include that in our calculation for
the Palette size.
In order to make that information available which is part
of the Palette class we need to pass the instance to the
PaletteWindowWidget instance.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Daniel Drake <dsd@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
First we needed to port the Palette code to use a minimum size. The default size
is two times the GRID_CELL_SIZE. Since the request-phase of the traditional GTK+
geometry management has been replaced by a height-for-width system [1] we have
to compensate for that. Furthermore we need to pass the invoker from the
PaletteWindow to the _PaletteWindowWidget for the gap calculation code for
drawing the border around the Palette.
We do the drawing of the border for the toolbutton in the base class, moved
this from the ToolbarButton and made sure we are drawing in the right order.
In the ToolButton we draw as well a black background for the ToolButton when
the Palette is up. While the mouse is over the button we can do that in the
theme, but not when the mouse moves over the Palette.
[1] http://developer.gnome.org/gtk3/3.0/ch25s02.html#id1525688
Signed-off-by: Simon Schampijer <simon@laptop.org>
This draws the grey line around the toolbutton icon with a gap at the
bottom and a grey line at the top of the subtoolbar. Furthermore it
gets the highlightning of the button correct, in the pressed and hover
state. This patch depends on the sugar-artwork patch with the id
7464b808eb12b1df650952e3c8214acff1d1360f.
Signed-off-by: Gonzalo Odiard <gonzalo@laptop.org>
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
With 820efa56b9
gtk.gdk.x11_get_server_time(window) wasn't correctly converted
to GdkX11.x11_get_server_time(window). Found when tesing
collaboration. Opened 669264 for the upstream fix of
pygi-convert.sh.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Daniel Drake <dsd@laptop.org>
- removed deprecated imports from the activity module, use the
widgets module instead
- removed the ActivityToolbox class
- removed the Stop button from the ActivityToolbar
- removed set_toolbar/get_toolbar API from the window module
Signed-off-by: Simon Schampijer <simon@laptop.org>
Reviewed-by: Gonzalo Odiard <gonzalo@laptop.org>
Acked-by: Daniel Drake <dsd@laptop.org>
The objectchooser had the 'title', 'flags' and 'buttons' parameters
deprecated for a long time, remove them now completely. The
only parameters allowed are now the 'parent' and the 'what_filter'.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Reviewed-by: Gonzalo Odiard <gonzalo@laptop.org>
Acked-by: Daniel Drake <dsd@laptop.org>
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.
Fix some trivial issues missed earlier: various missing imports,
some minor API changes to adapt to, do_size_request simple porting,
etc.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
CanvasIcon and CanvasInvoker were removed in a previous GTK3-porting commit
as they were based on hippocanvas.
However, this leaves the toolkit with some missing functionality:
there is no longer a trivial way to show an icon which can receive mouse
events and pop up a palette. Such functionality is used in various
places throughout the shell and activities.
Reimplement this functionality as EventIcon and CursorInvoker.
Instead of reimplementing much of the Icon class (like CanvasIcon did),
EventIcon opts for a more simplistic encapsulation of an Icon object.
This means trivial API changes for CanvasIcon users who must now
use the 'icon' property with the Icon API.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
Manuel Quiñones