Commit Graph

55 Commits

Author SHA1 Message Date
Sam Parkinson
824e6dcb69 Set css class on toolitems when a palette or toolbar popsdown 2016-02-19 07:18:45 +11:00
Sam Parkinson
8d0cc98e43 Set css name for widgets
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.
2016-01-01 12:28:42 +11:00
James Cameron
7ba120fe25 Fix persistent tree view palettes
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.
2015-12-22 09:49:16 +11:00
Sam Parkinson
739dacbd01 Position palette based on event coords, fixes #4897
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.
2015-12-15 12:51:42 -03:00
Gonzalo Odiard
9314fd89fa Do not calculate palette height on PaletteWindowWidget - Fixes #4792
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
2015-08-07 12:58:07 -03:00
Sam Parkinson
ecc2f491b6 Merge branch 'fix_mousedetector_stop' of https://github.com/godiard/sugar-toolkit-gtk3 2015-07-26 09:32:02 +10:00
Gonzalo Odiard
fd15e76dab MouseDetector timeout_id need reset
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
2015-07-24 15:07:09 -03:00
Gonzalo Odiard
a8e75af790 Check release mouse postion in CursorInvoker
This affect when a palette will be opened, by example in the BuddyIcon
in the Sugar home.
2015-07-24 12:00:02 -03:00
Sam Parkinson
78dcd5a7e4 Fix GtkMenu palette positioning in Gtk 3.16 2015-06-29 13:53:19 -03:00
James Cameron
4c22ba5b35 Add escape key to palette windows
Popdown a palette window in response to escape key.
2015-05-25 12:41:24 +10:00
Gonzalo Odiard
7a9510a187 Remove CellRendererInvoker
This invoker is not used anymore, now is replaced by TreeViewInvoker.
2015-05-14 19:05:34 -03:00
Gonzalo Odiard
49365e132c New invoker, TreeViewInvoker
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
2015-05-14 12:04:07 -03:00
Martin Abente Lahaye
85b173eb25 Remove Palette logic out of PaletteWindow
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>
2014-06-24 16:27:05 -03:00
Gonzalo Odiard
c70e5c678d Fix regression introduced by b9d6b628a9
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>
2014-05-30 15:51:11 -04:00
Gonzalo Odiard
dfeba6184e Fix drawing of gap on palettes attached to widget - Fixes #4776
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>
2014-05-30 15:50:37 -04:00
Gonzalo Odiard
b9d6b628a9 Show palettes at the screen bottom with the right size - Fixes #4673
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>
2014-05-28 14:35:20 -04:00
Martin Abente Lahaye
6c64a7d020 Revert "Keep updated CellRendererInvoker self.path updated - Fixes #4717"
This reverts commit 353e05a086.
2014-01-23 00:57:27 -03:00
Gonzalo Odiard
353e05a086 Keep updated CellRendererInvoker self.path updated - Fixes #4717
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>
2014-01-17 17:41:46 -03:00
Gonzalo Odiard
dee29c0e75 Be able to click in a tooltip - Fixes #991
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>
2013-12-18 22:49:21 +01:00
William Orr
edbc8f53b3 pep8'd sugar3.graphics 2013-06-11 15:18:15 +02:00
William Orr
e649070aa2 Replaced deprecated GObject methods with GLib methods 2013-06-10 15:46:53 +02:00
William Orr
3a8760c9e4 Fixed crash in journal when mousing over activity icons 2013-06-10 15:46:53 +02:00
Simon Schampijer
b3048112d6 Palette: handle the case where setting the transient window does fail, SL #4221
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>
2013-03-14 16:14:55 +01:00
Carlos Garnacho
3596e8c6cb palettemenuwidget: Ensure the widget is realized before popping it up, SL #4388
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>
2013-01-17 18:17:43 +01:00
Simon Schampijer
3859ff0022 WidgetInvoker: do not handle the clicked signal when there is no user interaction, part of SL #4307
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>
2012-12-20 14:40:28 +01:00
Manuel Quiñones
0231969bba PaletteWindowWidget: set border width to make outer space in the container - SL #4295
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>
2012-12-15 10:23:10 -03:00
Simon Schampijer
6a01d9228d Follow up fixes for the lockable Palette support
- 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>
2012-11-23 17:38:05 +01:00
Simon Schampijer
6064fb30cc Add support for locking Palettes, SL #4008
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>
2012-11-21 20:21:46 +01:00
Simon Schampijer
c64d5590b0 CellRendererInvoker: no need to reset the controller manually anymore
This got fixed properly in b2df135844
2012-11-08 10:34:48 +01:00
Manuel Quiñones
5505eb30bf Set correct padding and size for the palette, window implementation - SL #4144
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>
2012-11-07 09:57:33 -03:00
Simon Schampijer
811676ef4e CellRendererInvoker: always reset the long-press controller
Follow up of: ad9b0e9866
2012-11-07 00:45:58 +01:00
Simon Schampijer
ad9b0e9866 CellRendererInvoker: add support for long-press events
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>
2012-11-06 23:36:57 +01:00
Simon Schampijer
a515976dff WidgetInvoker: add support for long-press events, part of #4127
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>
2012-11-05 14:45:53 +01:00
Simon Schampijer
8af0d49591 GtkMenu: use point_in_cell_renderer for CellRendereInvoker to check if a point is in, part of SL #3921
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>
2012-10-31 08:49:22 +01:00
Simon Schampijer
a36ada99fd CursurInvoker: add long-press gesture to raise Palette
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>
2012-10-25 15:55:02 +02:00
Simon Schampijer
1224ab1451 Palettes: move PRIMARY and SECONDARY constant to the base class
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
2012-10-23 11:29:02 +02:00
Simon Schampijer
1a8f89226b Add toggle_palette property for Palette invoker, SL #4065
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>
2012-10-23 11:28:15 +02:00
Simon Schampijer
5cb4a48c5b Subtoolbar Palettes do not display at correct position, SL #3891
GTK_WIDGET_NO_WINDOW has been deprecated but we can use
gtk_widget_get_has_window() instead [1]. This brings back the
old code.

Follow up of: 5ab2b80546

[1] http://developer.gnome.org/gtk/stable/GtkWidget.html#GTK-WIDGET-NO-WINDOW:CAPS

Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
2012-09-12 21:22:57 +02:00
Simon Schampijer
5ab2b80546 Frame Device icons: Palette is not drawn at the correct position
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>
2012-09-12 15:40:54 +02:00
Simon Schampijer
9b391fa3cf CellRendererInvoker: various fixups
- 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>
2012-09-12 15:40:26 +02:00
Simon Schampijer
289787e8c6 CursorInvoker: check if event.mode is Gdk.CrossingMode.NORMAL to trigger a mouse leave
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>
2012-09-06 18:14:56 +02:00
Simon Schampijer
447cfc2df1 CellRendererInvoker: in Gtk.TreeViewColumn get_cell_renderers is now get_cells
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
2012-09-06 18:14:56 +02:00
Simon Schampijer
d57212a040 Make sure we have a widget before attaching an invoker, SL #3460
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>
2012-06-06 14:57:52 +02:00
Simon Schampijer
af320f91f8 Replacing set_data/get_data with a python attribute
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>
2012-06-06 14:56:44 +02:00
Simon Schampijer
7a07bb1001 Draw accelerator in Palette SL #3459
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>
2012-04-19 18:37:15 +02:00
Simon Schampijer
16040b2f30 Draw border for palette all the time SL #3383
gtk_render_frame_gap [1] does expect an initial and an end
coordinate for the gap. paint_box_gap [2] which we used
before expected a starting position of the gap and the width
of the gap as parameter.

The patch does calculate the end coordinate parameter for
the gap from the initial coordinate and the width of the
gap.

Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Daniel Drake <dsd@laptop.org>

[1] http://developer.gnome.org/gtk3/3.0/GtkStyleContext.html#gtk-render-frame-gap
[2] http://developer.gnome.org/gtk/2.24/GtkStyle.html#gtk-paint-box-gap
2012-04-19 17:15:01 +02:00
Simon Schampijer
01a06943a2 Mimic the behaviour and style of the Sugar GTK+ 2 toolbutton palettes in GTK+ 3
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>
2012-03-15 18:25:08 +01:00
Daniel Drake
48ad255a78 Reimplement Palettes for GTK3
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.
2011-12-20 19:19:16 +01:00
Daniel Drake
827ab7218a Add EventIcon/CursorInvoker similar to CanvasIcon/CanvasInvoker
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>
2011-12-20 18:35:25 +01:00
Sascha Silbe
c82a775267 Use accessor functions for data fields
The following data fields that were provided by PyGTK are not accessible
directly in GTK3+pygi and need to be replaced by accessor calls:

Adjustment.lower
Adjustment.page_size
Adjustment.upper
Adjustment.value
Bin.child
Widget.parent
Widget.style
Widget.window

Based on patches by Daniel Drake <dsd@laptop.org>.

Signed-off-by: Sascha Silbe <silbe@activitycentral.com>
2011-12-13 17:19:53 -03:00