| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
GnomeCanvas will stash the GdkDevice and reuse it in the subsequent
gnome_canvas_item_ungrab() call.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prefer dealing with GdkEvent pointers and using accessor functions like
gdk_event_get_button().
This is complicated by the fact that some GtkWidget method declarations
still use GdkEventButton pointers, and synthesizing button events pretty
much requires direct GdkEventButton access. But GDK seems to be nudging
itself toward sealing the GdkEvent union. Likely to happen in GDK4.
Mainly clean up signal handlers and leave method overrides alone for now.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to [1], we don't need to worry about GDK's global lock since
we don't call gdk_threads_init() or gdk_threads_set_lock_functions().
The GDK threads API is being aggressively deprecated by GTK+ developers
so let's just abandon it entirely. I've never really understood when
you're supposed to use it or not use it anyway, so it's good to be rid
of this confusion.
[1] https://mail.gnome.org/archives/desktop-devel-list/2012-August/msg00005.html
|
| |
|
|
|
|
| |
G_DEFINE_TYPE macros define a static "parent_class" variable.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
synth_crossing() in gtkwidget.c does not set valid pointer coordinates,
but GnomeCanvas relies on these coordinates to figure out what canvas
item the event applies to.
Detect these synthesized GDK_ENTER_NOTIFY and GDK_LEAVE_NOTIFY events
and disregard them.
This was breaking drag-and-drop of EMinicards and probably elsewhere.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
As of GLib 2.28 all GObject virtual methods, including constructed(),
are safe to chain up to unconditionally. Remove unnecessary checks.
|
| |
|
|
|
|
| |
GCC learned how to find dead assignments.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Simplifies the drawing code a bit.
Public API removed:
GnomeCanvas.center_scroll_region (is always TRUE)
GnomeCanvas.pixels_per_unit (is always 1.0)
gnome_canvas_set_center_scroll_region()
gnome_canvas_get_center_scroll_region()
gnome_canvas_set_pixels_per_unit()
|
|
|
|
|
|
| |
Yes, the GtkScrollable interface is implemented by more than just
GtkLayout, but it turns out GtkLayout is the only thing Evolution
uses the GtkScrollable API for on the gtk3 branch.
|
| |
|
|
|
|
|
| |
To clarify the semantics: the method may be called multiple times
so pointers should be set to NULL after freeing or unreferencing.
|
|
|
|
| |
Was returning an inverted matrix: i2w instead of w2i.
|
|
|
|
|
|
| |
Cairo doesn't need allocated colors.
Yay, gnome-canvas now compiles with GDK_DISABLE_DEPRECATED.
|
| |
|
| |
|
|
|
|
|
| |
Instead of keeping oour own invalid area, trust GDK to do the right
thing.
|
|
|
|
| |
It's not necessary anymore. Use gnome_canvas_w2c_matrix() instead.
|
| |
|
|
|
|
|
| |
1) Don't ever force an update
2) There's GTK API to force an update if you need to. Use that.
|
|
|
|
|
| |
Also update the GnomeCanvasItem.update vfunc to take a cairo_matrix_t
and no longer pass the clip_path (what was it used for anyway?).
|
|
|
|
|
| |
Dashing properties were commented out in the process. They are not used
inside Evolution.
|
|
|
|
|
|
|
|
| |
Previously the function returned the distance to the nearest item. Now
it only returns an item that is hit. This slightly changes semantics
(button events are no longer dispatched to the nearest item, but only to
the item actually clicked on), but makes the code way simpler and
actually does what one would expect.
|
|
|
|
| |
It's never set, so just replace it with its default value 0 everywhere.
|
| |
|
|
|
|
| |
It's unused now
|
|
|
|
| |
The anti-aliased code was never used, so remove it.
|
| |
|
| |
|
|
|
|
|
|
|
| |
In GTK+ 2.21.8, the keysym names were renamed from GDK_* to GDK_KEY_*.
I've added backward-compatibility macors to gtk-compat.h, which can be
dumped as soon as we require GTK+ >= 2.22.0.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
According to CallCatcher.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Work around the issue of GnomeCanvasItem amending its own flags to
GtkObject::flags (which is sealed) by giving it its own flags field.
This breaks libgnomecanvas ABI and API, but I see no other way.
This commit didn't work the first time because gnome-pilot libraries
were still pulling in the system-wide libgnomecanvas, and that was
interfereing with our bundled version which has a different ABI.
But gnome-pilot integration was dropped in the previous commit, so
everything is now using the bundled libgnomecanvas.
|
|
|
|
|
|
|
| |
This reverts commit fd8b55edaa88906b588aa07d9eadcacd34a7a774.
Something in this commit seriously hosed ETable, making Evolution pretty
much unusable. Reverting this until I can track down the problem.
|
|
|
|
|
|
| |
Work around the issue of GnomeCanvasItem amending its own flags to
GtkObject::flags (which is sealed) by giving it its own flags field.
This breaks libgnomecanvas ABI and API, but I see no other way.
|
|
Both of these modules are deprecated and going away in GNOME 3 but we
still rely heavily on them for GnomeCalendar and ETable. So, welcome
to the island of unwanted libraries...
|