Commit d05191a010 change the height
requisition to be completely dependent on the PangoLayout, but that
breaks when the font has special characters with different metrics.
Use the maximum between the two instead.
https://bugzilla.gnome.org/show_bug.cgi?id=728054
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.
We don't want the size request to change as icons come and
go (thinking e.g. about the caps lock warning). Just make
sure that we have enough room for showing the icons.
This property is TRUE by default, when a popover is modal, it
will automatically set a GTK+ grab on the popover, and grab
the keyboard focus into the popover.
GdkWindows are gone now from the API, the pointed_to rectangle
is from now on relative to the widget allocation. GtkTextView
and GtkEntry were updated to adapt to this change.
I'm currently working on porting view::FieldEntry (from libview) to C for use in
upstream GTK+. FieldEntry is a widget which allows users to enter structured
text such as IPv4 addresses or serial numbers. The way that FieldEntry
delineates the fields within the entry is with tabstops, using PangoTabArray
entries to precisely position the fields and delimiters. Because GtkEntry
rebuilds its internal PangoLayout fairly frequently, this requires a property in
the entry that will set the tabs on the layout whenever that happens. This API
looks very similar to one in GtkTextView.
Patch by David Trowbridge <trowbrds@gmail.com>. Updated for Gtk+ 3.10.
https://bugzilla.gnome.org/show_bug.cgi?id=697399
GtkEntry currently draws exactly the same no matter what the state of the
'editable' property. This is pretty confusing for users because there's
no visual feedback at all, it just seems like their keyboard is broken.
This change adds a "read-only" class to the StyleContext, which will
continue to allow the user to select/copy the text, but will draw the
entry as if it were insensitive, providing some indication that the
contents can't be changed.
Signed-off-by: David Trowbridge <trowbrds@gmail.com>
http://bugzilla.gnome.org/show_bug.cgi?id=694831
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
This reverts commit b2e666bf8f.
We need to keep cursor blinking configurable for accessibility
reasons.
https://bugzilla.gnome.org/show_bug.cgi?id=704134
Conflicts:
gdk/win32/gdkproperty-win32.c
gdk/x11/gdksettings.c
gtk/gtksettings.c
gtk/gtktextview.c
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
This feature offers a number of benefits related to providing
feedback to the user when the password is masked. Some experts have
argued that password masking is harmful. I tend to agree with this
setting providing a better and more moderate solution. Some agree:
https://www.schneier.com/blog/archives/2009/07/the_pros_and_co.html
In order to further lessen the impact I've only enabled the feature
on the primary display since the likelyhood of a non-primary display
being visible by others is higher.
