Now that Pango tracks changes to the context automatically there is
no need to do it manually in e.g. style-updated or direction-changed,
in fact the only case we have to care about is when we re-create
the PangoContext due to a screen change, so we only have to clear
the layouts in GtkLabel in screen-changed.
This means we're not clearing all the layouts whenever the state changes,
which happens to every widget when the window is unfocused, which helps
performance a lot.
https://bugzilla.gnome.org/show_bug.cgi?id=340066
Instead of using gtk_style_context_get_font() in
pango_context_get_metrics(), use pango_context_get_font_description().
The context contains the font description we are about to use after all.
If the "wider" label is the smaller one, use the wider size for both
cases. This can happen when ellipsizing a single character, which is
often smaller than the ellipsizing glpyph(s).
With ellipsizing, the ellipsized text can have a smaller height than the
non-ellipsized text. So the wider text is also higher. Example:
.<big>TEXT</big>
will ellipsize to the small text.
Reported-By: Rico Tzschichholz <ricotz@t-online.de>
The label code assumed that Pango treats this as "wrap to as much space
as possible and then ellipsize all the lines", but for Pango, ellipsize
takes precedence over wrap. So do the same thing in GtkLabel.
Also updated is the reftest that checked this behavior.
When we are re-setting the same text for internal reasons
(e.g. when applying the mnemonics-visible change upon Alt press),
we should not needlessly loos the selection.
https://bugzilla.gnome.org/show_bug.cgi?id=671588
The new semi-private function will allow to implement support for css
padding and border in widgets inheriting from GtkMisc.
Use the new function for GtkLabel, GtkArrow and GtkImage.
Instead of "attribute with later start index wins, make sure the
attribute list that is merged from takes precedence. This now gives the
multiple attribute lists we use in the label an order:
1) gtk_label_set_attributes()
These attributes override everything. It's what the function's there
for after all.
2) markup of label
Other user-specified attributes come next.
3) attributes for links
When we apply custom attributes on parts of the text, we put them
last. We don't want to mess with what the user does. Also, we change
color and underline, so we usually have something to show.
- Don't compute link color attributes until layout creation
This is useful as a performance enhancement, because we don't have to
lookup the property after setting the text, so multiple markup sets
don't cost style lookups.
- Don't merge attrs into effective_attrs
We do this when applying link colors now. Keeping them separate allows
invalidating them separately.
Instead of getting confused by applied underline or color tags in the
regular markup, we store the link start/end when we actually parse the
text. As a bonus, we can avoid rescanning links when creating the
markup.
The new function provides an API that takes the PangoLayout and index
as input params, this way it handles strong and weak cursors internally
factoring out all code duplicated in the widgets that need to render
cursors.
https://bugzilla.gnome.org/show_bug.cgi?id=640317
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.
It's possible the GtkLabel receives drag'n'drop related signals
if it was setup to receive them by a container or other external
code, just avoid dereferencing priv->select_info in this case.
gtk/gtkborderimage.c, gtk/gtklabel.c and gtk/gtkstyleproperty.c call
round() and/or rint(), which was only available in C99 compilers.
This adds the inclusion of the fallback implementation (gtk/fallback-c89.c)
to define these functions if they are not initially made available by the
compiler.
Also remove the rint() implementation in gtk/gtklabel.c as it is now in
the fallback implmentation.
This commit introduces a new setting, gtk-visible-focus, backed
by the Gtk/VisibleFocus X setting. Its three values control how
focus rectangles are displayed.
'always' is equivalent to the traditional GTK+ behaviour of always
rendering focus rectangles.
'never' does what it says, and is intended for keyboardless
situations, e.g. tablets.
'automatic' hides focus rectangles initially, until the user
interacts with the keyboard, at which point focus rectangles
become visible.
https://bugzilla.gnome.org/show_bug.cgi?id=649567
A first experimental conversion from the gail namespace to gtkaccessible.
At the same time, use gtk_widget_class_set_accessible_type() to register
the accessible type for GtkLabel.
