Problem #1, buddy menu appears on Sugar startup on physical hardware, or
when mouse is centre of display.
Problem #2, Terminal toolbar steals keyboard focus, when mouse is left
in home view search box at activity start time.
Regressions were introduced in the port from Gtk2 to Gtk3.
Cause is enter-notify-events that arrive because cursor is already
present in widgets as they are realised and mapped.
Fix is to capture cursor position when the widget is being created, and
ignore enter-notify-event if the same position is seen.
The log message "PaletteWindowWidget popup get_visible True" is not
useful, and is removed. It can be made to occur in Terminal by repeated
right-click on any of the first three toolbar button.
Previously there was the concept of having 2 popdowns for a palette.
The first popdown showed the of tooltip the palette, and the 2nd
showed the content of the palette. However, this was confusing
to new users, and made users wait for little reason.
This commit removes the 2nd popdown. An example of this is when you
mouse over an icon to invoke the palette. Previously, it showed
the tooltip, then made you wait, then showed the content of the
palette. With this patch, the whole palette is shown at the
first popdown, making a snappy UX.
Steps to reproduce:
1. Long press on home view favorite icon (an event icon)
Expected: Palette invoker where finger is
Actuall: Palette invokes in top left corner
This is because the long press controller emits coords relative
to the widget's window, and EventIcons sometimes have their own
windows. We can't change the long press controller, as it is a
public api. But we fix this by translating the coords to the
root window coords in the CursorInvoker. Using root coords is
consistent with the right click handleing in the cursor invoker.
Currently, the ToolInvoker code passes the button child in such a
way that the WidgetInvoker queues only the child's draw. In previous
Gtk+ versions, this magically resulted in redrawing the parent as well.
However, Gtk+ 3.20 is probably trying to save power and not randomly
redraw widgets. To fix this, we must queue the redraw of the widget
that we want to redraw explicitly.
In Gtk+ 3.20, you need to use the css name to select elements,
rather than the gtype name. Therefore, these must be added.
The css name must be set before the class instances are created, as
it effects the class rather than the instance. This is why it must
be places after the class definition.
A rework of the TreeViewInvoker used by the journal and activity list.
Fixes a persistent journal entry palette that reappears in journal or
home view. https://bugs.sugarlabs.org/ticket/4918
Also fixes an over-sensitive journal icon; with the journal mostly
empty, rapidly move the mouse from the bottom of the screen into the
lowest icon and then out again. Before this patch, the palette was
shown. After this patch, the mouse must rest in the icon.
Changes made:
- override _ensure_palette_exists in parent class Invoker,
- remove reference to MouseSpeedDetector, it is no longer required,
- remove enter and leave events; they are for the TreeView as a whole,
and are not required,
- properly detect that None is returned by get_path_at_pos, when the
coordinates are outside the TreeView cells.
Not fixed:
- moving the mouse out of the journal icon invoker does not popdown the
palette, but it does when moving the mouse out of the activity icon in
the activity list; so this is a problem beyond the invoker,
Tested on Fedora 18 and Ubuntu 15.10.
Test cases:
- check a click will activate item,
- check a right-click will show palette,
- check a mouse hover will show palette,
- check a brief mouse passing will not show palette,
- check if mouse leaving palette will popdown.
Instead of getting the position of the mouse later in the code,
this commit uses the coords given to sugar by Gtk that say where
the event happened. This means that if the system is busy, or
the user is fast with the mouse, the palette will pop up where
they originally clicked.
To solve ticket #4673, we calculate the palette size using the size
of all the widgets [2]. That solves the problem on Palettes based on
_PaletteMenuWidget but on _PaletteWindowWidget produce a wrong value
when the secondary_label is not null, and as a consequence
the palette position is wrong.
The solution is do the calculation only for _PaletteMenuWidget based
palettes.
[1] https://bugs.sugarlabs.org/ticket/4673
[2] b9d6b628a9
The mouse detector have a variable to store the id for the timeout.
The stop() method check if the id is null but do not set the id to null
after remove the GObject timeout, then try to remove the timeout multiple times.
The efect can be seen if a user move the mouse slowly over the icons
in the Sugar home, in shell.log we see many lines like:
sugar3/graphics/palettewindow.py:443: Warning: Source ID 2464 was not found
when attempting to remove it
This new invoker is able to handle all the palettes on a treeview,
removing the need of one invoker per cell renderer (CellRendererInvoker).
This simplifies the code and makes it more efficient.
Also removes the logic from the CellRendererIcon, which
should only care about drawing itself. [1]
Is important to note than in Gtk3 a CellRenderer is not a GtkWidget
then can't know when the mouse is over it or have the usual events
used by other invokers, making the implementation CellRendererInvoker
very complicate.
This commit also removes the invoker of CellRendererIcon.
The ScrollingDetector logic is simplified too,
because now there are only one invoker instead of one by renderer
and the example code updated.
[1] https://developer.gnome.org/gtk3/stable/GtkCellRenderer.html
PaletteWindow is the parent class of two different subclases,
Palette and _ToolBarPalette. Palette uses state changes intensively
in order to display secondary content, but _ToolBarPalette does not.
Because of this, Palette overwrites PaletteWindow's popup and popdown
methods adding one extra param called "state". This param is not required
either in PaletteWindow and specially not in _ToolBarPalette.
Therefore, any piece of code inside PaletteWindow which is meant for
Palette subclassing, should be moved out of PaletteWindow and placed
in the Palette class, where it corresponds.
This patch fixes the cases where _ToolBarPalette breaks because of this
mismatch.
Signed-off-by: Martin Abente Lahaye <tch@sugarlabs.org>
When calculated the palette height based in the size of children,
forgoten add the border size. That moved the palette in the device icons
4 pixels to the bottom, then the gap was miscalcuated and the border
button border was not draw.
Signed-off-by: Gonzalo Odiard <godiard@sugarlabs.org>
In Gtk 3.10, Gtk.Window is drawing a gray border around the palette.
This patch draw a black rectangle defore we draw Gtk.render_frame_gap
to draw the border but with a gap to connect to the attached widget.
Signed-off-by: Gonzalo Odiard <godiard@sugarlabs.org>
On Gtk 3.10, Gtk.Menu at the bottom of the screen are resized
to avoid fall out of the screen, then report a wrong height.
We need calculate the size of the children and move the Menu up.
This problem is visible on the Clipboard icon palettes,
and in journal objects palettes at the bottom of the screen.
This patch also rename a variable 'rect' to 'req', because is
a Requisition (width, height) and not a Rectangle (x, y, width, height).
Finally, to avoid a error with the secondary text on the palette,
when copy text from the terminal, reove the '¬r' character.
Signed-off-by: Gonzalo Odiard <godiard@sugarlabs.org>
Since CellRendererInvoker can set the path at None if a mouse event
is out of the area of the renderer, can break the use of touch,
if happen after the mouse movement. This patch set the path,
in the point_in_cell_renderer test, for the positive case,
solving the issue.
Signed-off-by: Gonzalo Odiard <godiard@sugarlabs.org>
This issue was reported many times, when new users see a tooltip
try to click, and are confused when there are no action.
Signed-off-by: Gonzalo Odiard <gonzalo@laptop.org>
The expected parent window did likely change, for example
this can happen when we switch the Home Views while a Palette
of a canvas icon is popping up (SL #4221). In that case
send the 'popdown' signal so that for example the hovering
state feedback can be cleared.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
Otherwise the internal state is messed up, GTK+ grabs may be held on
unrealized widgets.
Signed-off-by: Carlos Garnacho <carlos@lanedo.com>
Acked-by: Simon Schampijer <simon@laptop.org>
There are cases where there is no user interaction but we do
receive a clicked signal: in the clipboard we do have
GtkRadioToolButton which are derived from the GtkToggleToolButton [1].
The 'clicked' signal is emitted when the 'active' property
changes [2]. We use the 'active' property to indicate the
current active clipping. In the Invoker we do check now
if the event originated a user interaction or if it was
generated due to a for example a property change.
[1] http://developer.gnome.org/gtk3/3.4/GtkToggleToolButton.html
[2] http://developer.gnome.org/gtk3/3.4/GtkToggleToolButton.html#GtkToggleToolButton--active
Signed-off-by: Simon Schampijer <simon@laptop.org>
Reviewed-by: Carlos Garnacho <carlos@lanedo.com>
Acked-by: Manuel Quiñones <manuq@laptop.org>
In the palette reimplamentation, commit 48ad255a, set_border_width was
removed. Add it again to the corresponding widget, and get the value
from the theme. Previously the value was given by:
self.get_style().xthickness . Now we can use the widget border.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
- do not call set_expanded when the parent does not
have that attribute, this is the case in the custom
abacus Palette in the Abacus activity
- add the same code in the button release event callback
that we have as well in the click event callback
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
This adds a property that indicates that a Palette should
behave in a locking manner. The behaviour is the same
as with the secondary Toolbars: when you hover over the invoking
widget the Palette will popdown and react to mouse movements,
leaving the invoker area or the Palette itself will popdown
the Palette again. When you click the invoking widget
the Palette will be locked. You have to unlock it again
to pop it down.
This patch makes the DescriptionButton and the Colorbutton
work.
If the DescriptionButton or the Colorbutton are placed in
the primary toolbar they will share the locked state with
the secondary toolbars. Only one can be locked at a time.
When a secondary toolbar is unlocked we do force that the
open Palettes are closed. Having a locking Palette in
a subtoolbar will also work (Activity Toolbar case or
ColorButton case in a few examples). There is no state
sharing implemented here at the moment, but so far we
do only have cases with one lockable Palette in a
subtoolbar.
This will also fix the case where we want to use the
OSK to edit the description of the activity SL #3887.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@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>
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>
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 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>
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>
Pro-Panda