This one is tricky because where the CellRendererInvoker is
used (Home View activity list and Journal list view) we do
use Palettes based on a GtkMenu. In the Journal list view
this Palette has submenus so it can not be easily replaced
with our custom Palette. That is why I am trying to make this
case work with a GtkMenu.
When the Palette does pop up it grabs the focus. This means that
the invoker does not see a TOUCH_END event. Same is the longpress
controller that is why we have to reset the controller when
the long-press is detected, otherwise it is not usable a second
time.
The default behavior of a GtkMenu is that it does pop down
on a long press/release event. So when doing a long press
on the icon the Palette was popping down directly. We can
stop this by listening on the button-release event in the
Menu and return True when the event happens in the invoker
coordinates.
Finally there are several issues with motion events: in the
invoker we listen to motion events on the treeview in order to
be able to popup/popdown the Palette on hovering over the
icon. This event is triggered as well when the icon is
tapped. We do check the origin of the event and do not trigger
the enter/leave when originated from a touchscreen. We do setup
the path for the CellRenderer however.
The second case where the motion events are triggered is
when you tap somewhere in the Palette when it is up. For
example you want to get to one of the submenues. Since the
Palette tracks motion events to work for the hover case [2]
we do get a leave event when the Palette is tapped and the
Palette does pop down. Same here, we check if the event
originated from a touchscreen and do discard it in that
case.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
Setting this option will popup the Palette on left click or tap
and popdown the Palette if it is up. This functionality has been
added with c4165967d5e05607db8b3e0969b516da87855431.
The ShareButton, which derrives from the RadioMenuButton, had the
desired behavior already overriding the on_clicked method, we
do this now in the invoker.
The DescriptionButton did only handle the popup part so far, with
this change the Palette will also popdown when the button is clicked
and the Palette is up.
Since both are Toolbuttons we have to set the hide_tooltip_on_click
property to False otherwise the popdown part would not function, see
1a8f89226b for more info.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
The theme will display the insensitive items grayed out.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
The WidgetInvoker will decide if a long press has been made
or not. We watch out for TOUCH_END events and when a long-press
event has been seen before we stop further propagation of the
event, hence there won't be any button-release or clicked
events available to the user of the widget.
There are several widgets using the WidgetInvoker, and those
handle differently touch events. The GtkButton does have a widget
implementation to handle touch events, it does stop further
propagation and emits the pressed/released signal for further
consumption [1]. We will not get a button-press/button-release
event for a touch event in this case.
The default behaviour for widgets e.g. a TreeView is to transform
the touch events into pointer events [2], for those widgets we do get
a button-press/button-release event for a touch events.
[1] http://git.gnome.org/browse/gtk+/tree/gtk/gtkbutton.c#n1809
[2] http://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.c#n5876
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
- remove set_app_paintable from _Box to fix the bad coloring of
subtoolbars. The documentation say we can't rely on it to paint the
themed background when this is set [1].
- don't call Gtk.EventBox.do_draw in the _Box do_draw because that
will not paint the child toolbar. Call the child do_draw instead.
- revert 7fc29c9d which was a workaround for the most frequent usage
[1] http://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-set-app-paintable
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
We use get_rect to check if the mouse is still over the invoker
in order to know when to popdown the Palette. The CellRendererInvoker
did return the allocation of the TreeView so far.
We already have a point_in_cell_renderer method in the
CellRendererInvoker so we can use this to check if the mouse pointer
is over the cell or not. The method point_in_cell_renderer is made
public to make it clearer that it can be used from the outside.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
For press feedback. Do this connecting to the treeview press and
release signals, as the palette invoker does. After this, the active
state can be styled in the artwork.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
This adds long-press gesture detection to the CursorInvoker
used in the EventIcon. This will make this gesture available
for the View icons for example.
We need to keep a boolean around to detect when a lon-press
event has happened and ignore the button-release event in
that case.
We add as well checks in the CursorInvoker and WidgetInvoker
for the enter events if they are of type Gdk.CrossingMode.NORMAL,
otherwise the Gdk.CrossingMode.TOUCH_BEGIN enter events that are detected
when a touch starts are handled and interfere.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
Without this patch when tapping on an EventIcon
we do get a GDK_CROSSING_UNGRAB leave event when
the Palette is raised. Because of this the Invoker
does not know how to popdown the Palette when
you tap outside or when clicking on actions in the
Palette itself.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
We found out that the animation does not solve the issue
of visually indicating the long-press gesture to our
satisfaction. This is because you do not know upfront
which icon does have a primary action and more options
that can be revealed with the long-press gesture and
the animation itself. We would need to theme the gesture
better first as well. That the animation is a separate
window does raise several side effects as well which we
would need to solve first.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Reviewed-by: Carlos Garnacho <carlos@lanedo.com>
We did track mouse motion events so far to show the unfullscreen
button. This adds the tracking of button events (left, middle, right
click) and touch tap.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
Setting this option will popup the Palette on left click or tap
and popdown the Palette if it is up. This functionality has been
added with c4165967d5e05607db8b3e0969b516da87855431.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
The property does specify whether the invoker will popup/popdown
the Palette on button left click/touch tap. It defaults to False.
In the toolbutton we add a property if the tooltip should be popped
down on a click, this is set to true to have the same behavior as
before.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
Don't mix up coordinates when calculating the bounding box center
Signed-off-by: Carlos Garnacho <carlos@lanedo.com>
Acked-by: Simon Schampijer <simon@laptop.org>
Tested-by: Manuel Kaufmann <humitos@gmail.com>
set_state is deprecated [1] and using flags improves the code and
makes it less error prone, because there is no need to handle the
prelight state in a variable _in_prelight_state .
[1] http://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-set-state
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
The buddy icon in the home view has the mouse pointer inside at boot,
moving the pointer outside provokes an error because the icon doesn't
have a palette attached yet.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
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>
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>
The allowed swipe directions can be specified now at construct time,
so the swipe-ended signal is only emitted for those directions.
Signed-off-by: Carlos Garnacho <carlos@lanedo.com>
Acked-by: Simon Schampijer <simon@laptop.org>
The 'pressed' signal does emit the x and y coordinates
of the position where the event occurred. This can be used
for example in the Browser where we need to know at which
exact position the long-press event occurred.
Signed-off-by: Carlos Garnacho <carlos@lanedo.com>
Acked-by: Simon Schampijer <simon@laptop.org>
These calls are occasionally failing with BadAccess on seemingly
still valid (not yet notified upon) touch sequences. Workaround
this Xorg bug with error traps at the moment, those would catch
no error when this is working properly.
Fixing this bug will be tracked at SL #3981
Signed-off-by: Carlos Garnacho <carlos@lanedo.com>
Acked-by: Simon Schampijer <simon@laptop.org>
The passive touch grab is set on the root window, so if touch
events get to a different window it's best to leave those for
GTK+ to handle.
Signed-off-by: Carlos Garnacho <carlos@lanedo.com>
Acked-by: Simon Schampijer <simon@laptop.org>
