| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
We can now use the PaletteMenuBox.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
|
| |
|
|
| |
This got fixed properly in b2df1358447c39e3a4720af2286846d516ea3b02
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This event means that the widget being listened won't receive
further input events as something else grabbed devices, reset
event controllers in this case.
This helps with SL #4128 where we did reset the long press
controller manually.
Signed-off-by: Carlos Garnacho <carlos@lanedo.com>
Acked-by: Simon Schampijer <simon@laptop.org>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A new API is provided: PaletteMenuBox is a container to be used in
Palette.set_content(). This is to hide the implementation details and
set the corresponding paddings and sizes.
Usage:
box = PaletteMenuBox()
palette.set_content(box)
Then we can append items to it, like:
item = PaletteMenuItem(text_label, icon, xo_color=xo_color)
box.append_child(item)
separator = PaletteMenuItemSeparator()
box.append_child(item)
We can also append any widget, and the box will handle the paddings:
box.append_child(widget)
style.DEFAULT_PADDING for horizontal and vertical padding is the
default. But can be overriden:
box.append_child(widget, horizontal_padding=0, vertical_padding=0)
Details:
- move palettemenuitem.py to palettemenu.py
- Width of palette: make it a minimun size of 3 Sugar grid cells.
- Padding of content, secondary box: we need top and bottom padding,
which can be set when packing the items container inside the
secondary box.
- Padding of menu items: needs to be just for left and right, so move
the padding to a new horizontal box.
- Padding of separators: unlike GtkSeparatorMenuItem, GtkSeparator
doesn't support padding. But we can wrap it in a GtkEventBox and
force the height of the widget there.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
|
| |
|
|
| |
Follow up of: ad9b0e98668954022a98cb5fdc63196d947c1b38
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
1a8f89226b4f979000d80edc7123b7d22b23dc91 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>
|
| |
|
|
| |
Discussed and compared options with Gary.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We do need to add the mask if we want to receive
the 'touch-event' signal. The Gtk.EventBox does
set the touch event mask by default.
[1] http://developer.gnome.org/gtk3/3.4/GtkWidget.html#GtkWidget-touch-event
[2] http://git.gnome.org/browse/gtk+/tree/gtk/gtkeventbox.c#n411
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
|
| |
|
|
| |
Signed-off-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>
|
