The PaletteWindow lost the horizontal padding when it started to be
used as replacement of palette menus. So now each implementation has
to add the padding.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
This is currently breaking the activity list unit test where
the profile has not been initialized. But, more in general,
it seems like we should not be crashing if our settings has
unexpected values.
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>
This is the same behaviour as for the RadioToolButton and the
ToolButton. See 5a1b380dd6 where
we did the same for the RadioToolbutton.
Updated the toolbuttons.py test to be able to test that code
path.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
Remove the vertical padding from the box that contain the toolbar, and
change the order of drawings in the container widget so that the
outline looks right. This has been tested with screenshots, see the
gif animation attached to the ticket.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
A new icon widget useful to display progress. It is compatible with
sugar3.graphics.icon.Icon . The progress is represented filling the
icon.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@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>
This was lost when PaletteMenuItem was added in
2d0ac2a952 of sugar source code.
That class does not handle the text_maxlen argument (default to 60). I
used this argument to set the Gtk.Label's size:
label.set_max_width_chars and use MIDDLE for its EllipSizeMode as
sugar3.graphics.palette.Palette does for its title and subtitle.
With these settings, the title of the palette and its items share the
same behaviour and are rendered with the same width.
Signed-off-by: Manuel Kaufmann <humitos@gmail.com>
Acked-by: Manuel Quiñones <manuq@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 callback, the allocation can be 1x1 if it is yet unknown [1].
This is the case of trays that start hidden by default, like the one
in Browse activity.
[1] http://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-size-allocate
Signed-off-by: Manuel Kaufmann <humitos@gmail.com>
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@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>
1. if the palette is up, draw the black background
2. draw the button itself
3. if the palette is up, draw the grey outline
Exactly as the ToolButton does. Otherwise the outline is not visible.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
The Palette is popped down when an item is activated. We can
listen on the 'button-release-event' on that widget. We make
sure the widget is of type PaletteMenuItem. This is similar
to what the GtkMenu is doing, see gtk_menu_shell_button_release [1].
[1] http://git.gnome.org/browse/gtk+/tree/gtk/gtkmenushell.c#n915
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
Do the same as in ToolButton, update do_draw method to do the drawing
in the code.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
Now the do_draw method is exactly the same as the one for ToolButton.
This considers the border that the radio button can have, which is
needed for the changes made in the theme to get back the original
style.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
When a CanvasIcon is right-clicked __button_press_event_cb and
__palette_popup_cb are called but not __button_release_event_cb. So,
ACTIVE flag is set but immediately removed by __palette_popup_cb and
PRELIGHT is set.
Now, if the user right-click it again while the palette is popped up,
__button_press_event_cb is called and it sets ACTIVE flag but
__palette_popup_cb is not called again because the palette is already
shown and that makes the icon to keep in ACTIVE state.
This patch checks if the palette is popped up when
__button_press_event_cb is called and if the palette is not popped up
the ACTIVE flag is set.
Signed-off-by: Manuel Kaufmann <humitos@gmail.com>
Acked-by: Manuel Quiñones <manuq@laptop.org>
We have to convert the boxes to EventBoxes because otherwise the
background is not themeable [1]
[1] https://bugzilla.gnome.org/show_bug.cgi?id=678790
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
If we pass the active property to the constructor do_clicked seem
to get called. Before chaining up to the Gtk.RadioToolButton
constructor we need to initialize the variable.
This is a followup of 5a1b380dd6
Signed-off-by: Simon Schampijer <simon@laptop.org>
Tested-by: Gonzalo Odiard <gonzalo@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
Now it suffices to have the widget and osk rectangles intersect,
to have "clear-request-area" emitted, so cater for the situations
where the focus rect lies outside the osk area.
Signed-off-by: Carlos Garnacho <carlos@lanedo.com>
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>
The Gtk.StyleContext get_background_color method needs a
Gtk.StateFlags as a parameter. Feeding it with a GtkStateType doesn't
work anymore in recent gtk+.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@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>
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 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>
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>
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>
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>
In Pango 'Pango.attr_weight_new' is not yet introspectable [1].
[1] https://bugzilla.gnome.org/show_bug.cgi?id=646788
Signed-off-by: Simon Schampijer <simon@schampijer.de>
[changed description]
Signed-off-by: Sascha Silbe <silbe@activitycentral.com>
GtkWidget "expose-event" signal has been replaced by
a new "draw" signal [1]. The context is already
clipped [2], so do not base it on the values returned by
get_allocation like before.
[1] http://developer.gnome.org/gtk3/3.0/ch25s02.html#id1467092
[2] http://developer.gnome.org/gtk3/3.0/GtkWidget.html#GtkWidget-draw
Signed-off-by: Simon Schampijer <simon@schampijer.de>
[squashed with a patch by Benjamin Berg <benjamin@sipsolutions.net>;
removed useless additions]
Signed-off-by: Sascha Silbe <silbe@activitycentral.com>
With PyGTK, all parameters of the Alignment constructor had defaults [1].
With GTK3+pygi, when using the explicit constructor (Alignment.new() resp.
gtk_alignment_new() [2]), all values would need to be passed. However when
using the GObject constructor, named properties can be passed in instead and
we only need to pass those that different from the default.
[1] http://developer.gnome.org/pygtk/stable/class-gtkalignment.html#constructor-gtkalignment
[2] http://developer.gnome.org/gtk/stable/GtkAlignment.html#gtk-alignment-new
Signed-off-by: Simon Schampijer <simon@schampijer.de>
[assembled from several patches; replaced description]
Signed-off-by: Sascha Silbe <silbe@activitycentral.com>
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>
The previous set_source_pixbuf() invocation (on a Cairo context) involves
Gdk data types, so in the new introspection world we need to call a Gdk
function rather than operating on the Cairo object (even if Cairo had already
been converted to introspection).
Signed-off-by: Daniel Drake <dsd@laptop.org>
[added description; split out from another patch]
Signed-off-by: Sascha Silbe <silbe@activitycentral.com>
GTK3 has replaced [1] the GTK2 geometry management with Height-for-width
Geometry Management [2]. This means we need to replace size_request() methods
with get_preferred_{width,height}().
[1] http://developer.gnome.org/gtk3/3.0/ch25s02.html#id1525688
[2] http://developer.gnome.org/gtk3/3.0/GtkWidget.html#geometry-management
Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net>
[assembled from several patches; fixed up left-over plus sign; added
description]
Signed-off-by: Sascha Silbe <silbe@activitycentral.com>
This is only on a best-effort basis; the code will be in a broken state after
this patch and need to be fixed manually.
The purpose of committing the intermediate, non-working output is to make it
reproducible. It's impractical to manually review the changes.
The exact version used was 4f637212f13b197a95c824967a58496b9e3b877c from the
main pygobject repository [1] plus a custom patch [2] that hasn't been sent
upstream yet.
[1] git://git.gnome.org/pygobject
[2] https://sascha.silbe.org/patches/pygobject-convert-sugar-20111122.patch
Signed-off-by: Sascha Silbe <silbe@activitycentral.com>
Some parts of GTK moved to GDK, so we need to import the latter for things to
work after the conversion script runs.
Signed-off-by: Sascha Silbe <silbe@activitycentral.com>
hippo-canvas isn't available in the GTK3 world, so we need to remove
anything that depends on it. Activities that still use it will need replace
hippo-canvas based widgets with native GTK ones before they can be ported to
GTK3.
[replaced description]
Signed-off-by: Sascha Silbe <silbe@activitycentral.com>
hippo-canvas isn't available in the GTK3 world and we can do fine without it
for rendering pixbufs.
[split out from another patch; added description]
Signed-off-by: Sascha Silbe <silbe@activitycentral.com>
Make sure can_close_tabs can be passed in as a keyword parameter (to be set
by the GObject constructor).
[split out from another patch]
Signed-off-by: Sascha Silbe <silbe@activitycentral.com>
The old gtk-2 based module will be present in
the 0.94 branch in the sugar-toolkit.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Sascha Silbe <silbe@activitycentral.com>
