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
For backwards compat support we don't want old implementations not
supporting scaling to see the new scaled directories, so move these
to a separate list.
Keyboard activation relies on the menu not being visible,
so ensure that it isn't when the menu is attached.
Problem tracked down by Vincent Le Garrec,
https://bugzilla.gnome.org/show_bug.cgi?id=688738
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
The rsvg loader now restricts what external files it will
allow to load from an svg. Thus our xinclude trick doesn't work
anymore. To work around that, embed the payload in a data: uri.
This is somewhat ugly, but the best we could come up with.
The current theme just makes all text bold that appears anywhere
in a headerbar, which is not great. We add 'title' and 'subtitle'
style classes to allow more targeted overriding of the font.
Commits the pre-edit string on receipt of focus_out and reset
commands.
Patch refinements by Cody Russell <bratsche@gnome.org> and
Ek Kato <ek.kato@gmail.com>
-For the binary "installation", look for the DLL files with their file
names consistent with the ones that are generated with the respective
Visual Studio projects.
-Remove any stray GDK DLLs that were left over from a Broadway-enabled
GDK when building a non-Broadway-enabled GTK+ binary set.
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
Fixes:
(rhythmbox:22802): Gtk-CRITICAL **:
_gtk_widget_get_preferred_size_for_size: assertion 'size >= -1' failed
that is gtk_paned_get_preferred_size_for_opposite_orientation calls
_gtk_widget_get_preferred_size_for_size on child2 with a negative
size.
As gtkpaned size was (32), child1 minimum size was (55) then
for_child1 became (32) for an handle_size of (5). Thus for_child2
ended up as (-5).
https://bugzilla.gnome.org/show_bug.cgi?id=705624
Just as for GtkRangeAccessible, we were not even trying to disconnect
the signal handler from the adjustment. The same fix works here:
override the widget_set and widget_unset vfuncs.
https://bugzilla.gnome.org/show_bug.cgi?id=705692
We were only disconnecting the signal in finalize, when
the widget was already unset. Instead, override the widget_set
and widget_unset vfuncs of GtkAccessible, and keep a reference
to the adjustment.
https://bugzilla.gnome.org/show_bug.cgi?id=705692
Move all the system includes, defines and function prototypes into a
separate header gdkwin32misc.h, so that we could keep gdkwin32.h as simple
as possible.
Replace the deprecated API calls with the updated APIs, and fix the build
of modules/input/gtkimcontextime.c, as we really needed
gdk/gdkkeysyms-compat.h (gdk/gdkkeysyms.h was already included)
https://bugzilla.gnome.org/show_bug.cgi?id=705068
...this was split into two commits as this source file has different
line endings (for some reason) from the other GDK-Win32 source files that
were updated in the quest to refrain from using deprecated APIs
Make sure we always deal with the same screen when
connecting / disconnecting the theme-variant changed handler.
Pointed out by Morten Welinder in
https://bugzilla.gnome.org/show_bug.cgi?id=705640
When an icon is requested as symbolic, our generic fallback algorithm
uses fullcolor icons when the specified icon name is not found, treating
the "-symbolic" suffix as another component of the icon name.
Change the algorithm to check beforehand if the icon is symbolic, remove
the suffix if so, and re-add it at the end for all the generated icon
names.
https://bugzilla.gnome.org/show_bug.cgi?id=680926
