Instead of allowing people to pass a uint user-data, insist on them
comparing mime types.
The user data was a uint instead of a pointer anyway, so uniqueness
could not be guaranteed and it caused more issues than it was worth.
And that's ignoring the fact that it basically wasn't used.
Change constructors to reflect that.
While doing so, also add a fallback argument to the cursor constructors,
so it is now possible to create cursors with fallback.
It is not necessary to (re)set the cursor on every crossing
event, and can probably yield the wrong results if there are
multiple master devices involved. Just set it on init(), and
let the inner machinery update the cursor whenever necessary.
This patch is an adaption of commit 0daf79676 in gtk-3-22, the
side effects are not as bad here because the cursor was already
being set on the widget specifically instead of the parent
widget's, but there's still some nonetheless (plus, it's simpler)
https://bugzilla.gnome.org/show_bug.cgi?id=785375
Attached widgets inherit from the style of the widget they are
attached to. This can sometimes have unintended consequences,
like a context menu in the main view of gedit inheriting the font
that is configured for documents, or the context menu of the preview
in the font chooser coming up with humongous font size.
To fix this problem, we introduce a context menu style class
and use it for all menus that are used like that. The theme
can then set a font for this style class.
https://bugzilla.gnome.org/show_bug.cgi?id=697127
We've recently a number of classes wholly. For these cases,
move the headers and sources to gtk/deprecated/ and adjust
Makefiles and includes accordingly.
Affected classes:
GtkAction
GtkActionGroup
GtkActivatable
GtkIconFactory
GtkImageMenuItem
GtkRadioAction
GtkRecentAction
GtkStock
GtkToggleAction
GtkUIManager
Not setting a URI but catching the activate-link signal is a
valid use of GtkLinkButton, but we shouldn't allow showing a
popup menu which offers to copy the URI if there's none.
Add _gtk_button_event_triggers_context_menu() and use it instead
of checking for event->button == 3, so context menus are invoked
correctly on the Mac.
We cannot use the GtkButton::clicked signal to override the default
behavior of GtkLinkButton (i.e. call gtk_show_uri()), because
GtkButton::clicked is registered as a RUN_FIRST signal, which obviously
prevents any other signal handler connected to it to stop the
propagation before the class handler has a chance to run.
For this reason we can add a GtkLinkButton::activate-link signal, which
will be emitted by the default GtkButton::clicked signal handler; the
::activate-link signal has a boolean return value, which allows simpler
code for stopping the propagation to the next signal handler.
https://bugzilla.gnome.org/show_bug.cgi?id=632150
It doesn't make sense to keep them separate as GtkSizeRequest requires a
GtkWidget and GtkWidget implements GtkSizeRequest, so you can never have
one without the other.
It also makes the code a lot easier because no casts are required when
calling functions.
Also, the names would translate to gtk_widget_get_width() and people
agreed that this would be a too generic name, so a "preferred" was added
to the names.
So this patch moves the functions:
gtk_size_request_get_request_mode() => gtk_widget_get_request_mode()
gtk_size_request_get_width() => gtk_widget_get_preferred_width()
gtk_size_request_get_height() => gtk_widget_get_preferred_height()
gtk_size_request_get_size() => gtk_widget_get_preferred_size()
gtk_size_request_get_width_for_height() =>
gtk_widget_get_preferred_width_for_height()
gtk_size_request_get_height_for_width() =>
gtk_widget_get_preferred_height_for_width()
... and moves the corresponding vfuncs to the GtkWidgetClass.
The patch also renames the implementations of the vfuncs in widgets to
include the word "preferrred".
