Instead of issuing g_warning, fill the provided GError.
This lets us test this error handling, and is the right
thing to do. Use the new GtkBuilder helpers and
g_markup_collect_attributes to do so.
The gtk_label_set_text() and gtk_label_set_markup() functions have
various side effects that ought to be documented, especially for
non-C developers using properties directly.
https://bugzilla.gnome.org/show_bug.cgi?id=747121
Instead of drawing text for selections and links manually, use the
gtk_render_background() and gtk_render_layout() functions.
As a side effect, this allows shadows on selected text and links
and real backgrounds (like gradients or images), too.
Since it turns out that x/yalign can't be quite equivalently
replaced by h/valign, bring them back as label properties, so
we can eventually get rid of GtkMisc.
https://bugzilla.gnome.org/show_bug.cgi?id=735841
When links are entirely hidden in an ellipsis, don't let
them be activated by clicking and skip them when moving
the focus around.
This commit depends on enhancements in pango 1.36.7 which
make it possible to find the ellipsed runs in a PangoLayout.
With older pango, things will work the same way as before.
https://bugzilla.gnome.org/show_bug.cgi?id=668258
GtkGestureSingle::button is set to 0 on the multipress gesture, as several
buttons are managed by that gesture. Also avoid some extra lines of code
setting what nowadays are default values.
https://bugzilla.gnome.org/show_bug.cgi?id=734285
The previous code for computing the clip rectangle forgot to respect
the text-shadow CSS property. This is usually not very visible because
text shadows usually don't extend the ink rectangle by very much.
See attached testcase for an example.
Otherwise, the CSS background we draw would be clipped if the ink rect
was smaller than the allocation (a very common thing).
Broken since 37030a7710 where we clipped
to the ink rect.
A multipress gesture takes care of link handling, and char/word/all
selection mode on selectable labels. A drag gesture is used for both
text selection and DnD checks on selectable labels.
Go back to respecting GtkMisc::xpad/ypad. Not doing so breaks
the misc-alignment reftest. As long as we still derive from
GtkMisc, we may as well do this.
We see an active link when creating the menu, but by the time
the menuitem is activated, we've received a leave notify that
makes the label clear its active link. Instead, give the
menuitems a direct reference to the link that is active when
the menu is created.
Problem pointed out by Tim Baedert
gnome-terminal is still using this setting, so we'll let
applications override it for another cycle. It is no longer
backed by a system-wide setting, though, and it will still
go away eventually.
This partically reverts 7e3a494fac
We should only eat button release events when the label is
actually selectable, since the comment indicates that we
want to eat the release events belonging to press events
that triggered a selection. This fixes problems with actions
on parent widgets that are triggered by button release,
as seen in this bug:
https://bugzilla.gnome.org/show_bug.cgi?id=724541
Try to do a better job of keeping example content
from being too wide. It is often rendered as <pre>
text so the only time we can wrap it is in the source.
It is best to full break lines at all punctuation and
to try to keep the width under 70 chars or so.
This commit makes the label accessible implement AtkHypertext,
which returns a AtkHyperlink object for each link in the text.
At the same time, add AtkHyperlinkImpl objects as children
to the label accessible.
Also some private API to indicate that links have changed, and
call that from GtkLabel when needed.
Adjust expected output of the affected a11y tests.
https://bugzilla.gnome.org/show_bug.cgi?id=721410https://bugzilla.gnome.org/show_bug.cgi?id=721421
When setting the lines property, the label will be ellipsized
to that many lines, with the ellipsis only appearing in the
last line. This is different from how ellipsization of multi-line
labels normally works in GTK+.
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
When trying to drag, we currently the position of the first motion
event to determine where the drag came from. This might be alright
in the case of the old animation, but the data will be inaccurate
if the user has moved the pointer quite a bit since pressing the
cursor to start dragging. While we could monkey patch the GdkEvent
at the widget layer, this is unintuitive and strange.
Add a new API that takes a set of pointer coordinates describing
the origin of the drag. Additionally, adapt most widgets to use
it and use it with correct coordinates.
https://bugzilla.gnome.org/show_bug.cgi?id=705605
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
