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.
The placeholder string is truncated when there's no
room for it in entry's width.
So, by ellipsizing it, the user can notice the text
was truncated so that they can workaround that by,
for example, maximizing the window.
https://bugzilla.gnome.org/show_bug.cgi?id=702763
Focusing the text entry without selecting all the text is needed in
some places (GtkTreeView, and some uses of GtkSearchEntry) so
create a private helper to avoid replicating the hacks.
https://bugzilla.gnome.org/show_bug.cgi?id=700787
We do this by making the ::populate-popup signals a little more
flexible. They used to just accept a GtkMenu as argument, now
they can take a menu or a toolbar. To not break the expectations
of existing callbacks, we only emit ::populate-popup with a toolbar
if the :populate-toolbar property is TRUE.
Don't set handles mode to none if the event has send_event set.
For consistency with GtkEntry, also make GtkTextView keep the
handle mode on buffer changes.
We only draw the main entry on should_draw (widget->window), because
otherwise we also draw it on the GtkTextHandle widgets.
This is necessary due to the recent change for that to not return
TRUE and swallow the rest of the drawing operation.
This replaces the previously hardcoded calls to gdk_window_set_user_data,
and also lets us track which windows are a part of a widget. Old code
should continue working as is, but new features that require the
windows may not work perfectly.
We need this for the transparent widget support to work, as we need
to specially mark the windows of child widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
With pango handling changes to the PangoLayout there now is no
style changes that can affect the layout for the entry, so we don't
have to reset the layout whenever the style is updated.
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.
GtkTextHandle is used to indicate both the cursor position
and the selection bound, dragging the handles will modify
the selection and scroll if necessary.
Backwards text selection is also blocked for touch devices,
so the handles don't get inverted positions (This is more
important though on GtkTextView, as inverted handles may
obscure portions of the selected text, good for consistence
though)
This commit moves all the entry completion implementation
into gtkentrycompletion.c. It also gets rid of an unnecessary
completion_device member in GtkEntryPrivate.
