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
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
With multiple GDK backends in the process, we run into problems where
we try to use the Wayland im module on X, which crashes. This commit
adds a quick backend filter that removes the wayland, xim and ime
input methods from consideration unless the corresponding GDK backend
is in use.
This code is called early on, without a window, and then later on
with a window. Currently, it returns different results for these
cases when the setting contains a value. That leads to pointless
construction and destruction of im contexts. Instead, just look
at the settings of the default screen. In practice, there is only
one screen, ever.
... to make it possible to insert rows in the middle of the list without having
to fiddle with the sort functions. One of the first users is going to be Glade.
https://bugzilla.gnome.org/show_bug.cgi?id=705558
To handle hidpi support we need to make sure we don't
downscale scaled css images.
Note: If cairo_surface_create_similar starts doing this
by itself we need to back this out.
A problem with the zoom scroll mode is that you have to restart
if you hit the bottom of the screen before you hit the bottom
of your document.
This commit adds an autoscroll feature to the zoom scroll: if
you move outside the window while in zoom scroll mode, we keep
scrolling in the direction you were going until you let go
of the mouse button.
https://bugzilla.gnome.org/show_bug.cgi?id=704703
Triggering zoom scroll mode by Shift click was too much
of an easter egg. It also requires using keyboard and
mouse together, which is hard to do for many users.
Instead, we now trigger zoom scroll mode by click-and-hold
(or touch-and-hold).
https://bugzilla.gnome.org/show_bug.cgi?id=704703
The internal class GtkPressAndHold was so far only
reacting to touch events. But in most cases where
a touch-and-hold or 'long press' pattern is useful,
click-and-hold can also be used.
This patch makes GtkPressAndHold react to mouse
clicks as well.
https://bugzilla.gnome.org/show_bug.cgi?id=704703
Add a boolean property that controls whether a window close button
will be shown in the header bar or not. Doing this in the toolkit
will ensure consistency of the visual apperance.
https://bugzilla.gnome.org/show_bug.cgi?id=702971
These files are generated, so adding them to git is somewhat
icky, but it helps translators who currently can't use intltool-update
on a fresh git checkout.
Don't specify packing properties for internal children.
This doesn't work unless the internal children are actually
direct children of the container (which we are about to
change for GtkInfoBar). Also, it is redundant, since we
just set the properties to the values they already have
anyway.
Packing properties in ui files are parsed and handled by
the container, which assumes that the child is a direct
descendant. For internal children, this is inconvenient,
because we don't want to reconstruct the entire internal
structure between the container and the child in the ui
file.
It would be best to not specify packing properties
in that case, but since existing ui files do this for
GtkInfoBar and we are about to change the internal
structure of GtkInfoBar, be more forgiving here.
This reverts commit fbbcb5c01b.
We will be doing this in gnome-settings-daemon itself instead,
as some X11 based platforms using GTK+ will want to override this.
We checked for G_IS_LOADABLE_ICON() before GDK_IS_PIXBUF().
Since we made GdkPixbuf implement GLoadableIcon, the special case for
pixbufs is never used, and the much much slower GLoadableIcon path is
taken instead. Move the GdkPixbuf one to be first to fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=705320
Add the Visual Studio 2010 projects to build the GDK Broadway backend, just
like the Visual Studio 2008 project files in the last commit. Similarly,
split up the property sheets so that they are easier to maintain and can
be made more flexible for different build types. Also remove some unneeded
stuff from some of these items.
Also, fix the filter file completion for GTK, as a source file was excluded
for that and this was overlooked as it seemingly did not cause any trouble.
The cell out argument to gtk_icon_view_get_cursor is a pass-through
for gtk_cell_area_get_focus_cell which is transfer none. Without
this explicit annotation, transfer full is defaulted and introspection
bindings will assume ownership of the GtkIconViews reference to the
cell, causing crashes. Additionally add explicit transfer full to
the path parameter because it is expected the caller will free the
returned memory.
https://bugzilla.gnome.org/show_bug.cgi?id=704700
We add a GtkSearchEntry::search-changed signal which gets emitted
with a 150 millisecond delay. The ::change signal goes back to its
expected semantics.
https://bugzilla.gnome.org/show_bug.cgi?id=700229
Applications have no way of finding out if a session manager proxy was
successfully created in gtk_application_startup_session_dbus(), so it's not
appropriate for certain public GtkApplication functions to be asserting the
presence of a session manager proxy as if it were a programmer error.
This affects:
gtk_application_inhibit()
gtk_application_is_inhibited()
If sm_proxy is NULL, the function should just return silently.
In the case of gtk_application_uninhibit(), the application should only be
calling this if it obtained a valid cookie, which implies the presence of a
session manager proxy. I noted that with a comment.
https://bugzilla.gnome.org/show_bug.cgi?id=701365
We toss a g_warning() if we can't find the user's signal handler. A good chunk
of the time this will be because they didn't use -rdynamic. Add a note about
that.
We rename the gtk_widget_class_bind_template_child{_internal}
macros by appending a _private to their name. Otherwise, it
would be too magic to pass the 'public' names as arguments,
but affect a member of the Private struct. At the same time,
Add two new macros with the old names,
gtk_widget_class_bind_template_child{_internal} that operate
on members of the instance struct.
The macros and functions are inconsistently named, and are not tied to
the "template" concept - to the point that it seems plausible to use
them without setting the template.
The new naming scheme is as follows:
gtk_widget_class_bind_template_child_full
gtk_widget_class_bind_template_callback_full
With the convenience macros:
gtk_widget_class_bind_template_child
gtk_widget_class_bind_template_child_internal
gtk_widget_class_bind_template_callback
https://bugzilla.gnome.org/show_bug.cgi?id=700898https://bugzilla.gnome.org/show_bug.cgi?id=700896
Using an offset from the struct means you can have children in
both the public and private (via G_PRIVATE_OFFSET) parts of the
instance. It also matches the new private macros nicer.
https://bugzilla.gnome.org/show_bug.cgi?id=702563
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Plug windows weren't redrawing properly because the embedded
window was expecting to get messages for each frame from the
compositor, but the compositor doesn't know about embedded
windows. Simply disable frame sync for GtkPlug's GdkWindow -
extending XEMBED to handle frame sync isn't interesting
at this point.
A new API gdk_x11_window_set_frame_sync_enabled() is added
to allow this to be done.
https://bugzilla.gnome.org/show_bug.cgi?id=701613
Add introspection friendly version of gtk_tree_model_rows_reordered
with a "_with_length" suffix. This allows language bindings to
safely pass an array with length argument. Use the "Rename to:"
annotation to expose as "gtk_tree_model_rows_reordered".
https://bugzilla.gnome.org/show_bug.cgi?id=684558
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
Declare variables at the top to the block.
G_GNUC_BEGIN_IGNORE_DEPRECATIONS and G_GNUC_END_IGNORE_DEPRECATIONS with
a ';' at the end is still considered a statement, even if these macros
expand to nothing, which C89 compilers don't really like (oddly speaking)-
but this is life.
A vertical action area causes the info bar to be imposingly large.
This defeats the whole point of the info bar which is to be
unobtrusive. Not to mention it is impossible to make it look
and feel good.
When the icon-release signal is emitted on a GtkSearchEntry, the
contents is now cleared only if it's for the secondary icon. The primary
icon can be used for another purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=704164
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.
Fixed the documentation to clarify that gtk_recent_info_get_visited
and gtk_recent_info_get_modified are actually about the recent info
meta-data rather than the resource itself.
https://bugzilla.gnome.org/show_bug.cgi?id=703827
In add_preedit_attrs, don't free foreground/background colors already
set in the underlying text attributes (style). They will be free'd by
release_style.
https://bugzilla.gnome.org/show_bug.cgi?id=703533
Other code assumes that the widget has a window if it is realized.
Since we might trigger such code indirectly from gtk_window_realize,
don't mark the window as realized before we've registered its window.
Since we now do all drawing propagation on the cairo_t (rather than
exposing multiple independent times on the GdkWindows) we no longer
need the opacity 0.999 hack.
We render the source into a cairo_surface_t so that we can render it
with cairo directly, rather than having to convert it from a pixbuf
every time. We also specify the target window when creating the cairo
surface so that rendering can be faster.
Using cairo surfaces also allows us to seamlessly support window scales.
We also add a GTK_IMAGE_SURFACE source type.
Support scales when falling back to loading icons from the
icon theme.
In order to actually render scaled icons we add
gtk_icon_set_render_icon_surface which renders to a cairo_surface_t
which includes whatever scaling you need for scaled icons.
This draws an icon from a cairo_surface. We want to use this more rather
than render_icon as this means we can skip the pixbuf to surface
conversion (including allocation and alpha premultiplication) at
render time, plus we can use create_similar_image which may allow
faster rendering.
An optional OutputScale integer key has been added to index.theme
subdirs description, so icon themes may provide icons that are
more suitable to render at a (typically 2x) integer upscaled
resolution. This way it is possible to make eg. a 16x16@2x icon has a
real size of 32x32, but contains a similar level of detail to the
16x16 icon so things don't look any more cluttered on high-dpi
screens.
The pixbuf lookup has changed so it prefers a minimal scale change
that yields the minimal real size difference, so if looking up for
a 16x16 icon at 2x, it would first prefer 16x16@2x, then 32x32, and
then any other icon that's closest to match
There is now *_for_scale() variants for all GtkIconTheme ways
to directly or indirectly fetch a GdkPixbuf.
This is based on code by Carlos Garnacho with changes by Alexander
Larsson
We need to be able to compute different GtkCssImage values
depending on the scale, and we need this at compute time so that
we don't need to read any images other than the scale in used (to
e.g. calculate the image size). GtkStyleProviderPrivate is shared
for all style contexts, so its not right.
This is very useful for hidpi where the dpi is scaled to make
non-dpi aware apps larger. In that case a dpi aware gtk+ using
GDK_SCALE will be getting huge fonts. You can the set GDK_DPI_SCALE
to compensate for this.
Group the buttons on each side in a box, and give them different
style classes, so themes can differentiate (this is partially a
workaround for limitations in our css selectors). The boxes also
let us add a margin below the buttons, without affecting the
allocation of the buttons themselves.
We have to uglify the deprecation messages to make gtk-doc
handle them. The get turned into XML attributes, and there
is no automatic quoting to protect quotes in the text.
If a menu is opened and it doesn't fit entirely below or above
the menu bar, gtk+ will place it on top. The button release will
then activate the popup item that happens to appear under the
cursor. Avoid this by ignoring release events if they originated
in the parent menu bar and the duration of the press was too short.
https://bugzilla.gnome.org/show_bug.cgi?id=703069
Removing object properties is too much of an API break, even for
properties we don't expect to be used outside of GTK itself.
This reverts commit 8b811b623c.
When creating separators we were binding the "label" property on the
tracker to the "label" property on the GtkSeparatorMenuItem.
This was problematic for two reasons.
First, it was pointless. The section header label will never change.
Second, it was causing problems: doing the binding caused the value to
be initially synced up, even if it was NULL. Doing this caused
GtkMenuItem to create a GtkAccelLabel and add it as a child, which
prevented the separator from being shown normally.
Change the code a bit so that we just call gtk_menu_item_set_label()
when creating the item, if we find the label to be non-NULL.
Also, show() the separator item at first. GtkMenu manages visibility of
separators internally, but it seems "more correct" to show it ourselves
at first.
This invariant stopped being guaranteed when we moved the visible area
validation from a high priority idle to a tick callback.
Fixes redrawing bugs like row expanding sometimes not having any visual
effect.
When the search is case sensitive, g_utf8_normalize() is not called, so
the skip_decomp argument of the function forward_chars_with_skipping()
must be FALSE.
To verify that, when searching "éb", the count parameter of
forward_chars_with_skipping() have a different value:
- case sensitive: count = 2
- case insensitive: count = 3 (g_utf8_normalize() has been called)
The commit adds unit tests that didn't pass before, and that now pass
(without known regression, obviously).
https://bugzilla.gnome.org/show_bug.cgi?id=702977
In the non-submenu case we bind the 'visibility' attribute to the
tracker, which takes care of showing the item. In the submenu case, we
don't bind all of the properties, so we miss this one.
Deal with it by just show()ing the submenu item.
https://bugzilla.gnome.org/show_bug.cgi?id=702332
When the file chooser changes directories, it tells the GtkFileChooserEntry to
change its base folder (i.e. the folder from which relative pathnames are resolved).
GtkFileChooserEntry then starts loading a GtkFileSystemModel asynchronously.
In the finished_loading_cb(), however, it would always ask the GtkEntryCompletion
to insert the completion prefix, since that finished_loading_cb() is what is also used
while the user is typing *in the entry*.
But when the entry doesn't have the focus (e.g. the user changed directories by double-clicking
on the file list in the file chooser), there's no reason to insert completions at all.
https://bugzilla.gnome.org/show_bug.cgi?id=672271
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
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
The function must return TRUE only if there is a tag toggle _after_ the
iter, not _at_ the iter. So for the end iter, the function must always
return FALSE.
Add also unit tests for gtk_text_iter_forward_to_tag_toggle().
https://bugzilla.gnome.org/show_bug.cgi?id=691266
It was not possible to know if the @limit was for @match_start or
@match_end. It was documented for backward_search(), but not for
forward_search().
https://bugzilla.gnome.org/show_bug.cgi?id=390048
Currently you can only set the current filename, but not
get it. It's useful to be able to get it in save
dialogs, where the user has typed the desired filename
and you are not in a real directory (recent used, for
example).
https://bugzilla.gnome.org/show_bug.cgi?id=702497
By delaying the emission to an idle we avoid a lot of tricky
reentrancy issues. For instance, a normal gtk_icon_theme_choose_icon()
call could in very rare cases (when a user updated an icon theme) emit
a signal which could affect the icon currently being looked up. This
kind of reentrancy is very hard to test against, especially when it is
so rare, so we're better of avoiding it.
There is no real value to get the change signal directly anyway. All
it can do is affect which icon is rendered the next frame, and we will
handle the queued emission before rendering. Not to mention that icon
theme change detection is polled anyway, so it is already delayed.
https://bugzilla.gnome.org/show_bug.cgi?id=694755
When we're reloading the theme in ensure_valid_themes (due to noticing
that a theme dir has changed) we need to also clear the icon cache
as it will not be valid for the new theme.
We already do this in do_theme_change(), but ensure_valid_themes()
was missing this.
https://bugzilla.gnome.org/show_bug.cgi?id=702598
The icon data in GttkIconInfo->data is currently owned by the
IconThemeDir->icon_data hashtable. However, on e.g. a theme change
blow_themes() destroys the dirs and thus the data, meaning any
outstanding GtkIconInfo points to stale data.
We solve this by adding a refcount to GtkIconData and reffing it
from GtkIconInfo.
https://bugzilla.gnome.org/show_bug.cgi?id=702598
GtkBuilder returns GError for _add_from_{file,resource,string}(),
implying that the user should be able to recover from these errors.
Mention in the docs that it's unreasonable to try to do this.
https://bugzilla.gnome.org/show_bug.cgi?id=679930
There's probably an expectation from the app developers that
Ctrl+F or similar common shortcuts for starting a search will
be handled by the widget, when this is not the case. Explicitely
mention it in the docs to avoid confusion.
https://bugzilla.gnome.org/show_bug.cgi?id=701523
We already take care to not track headers when the listbox is hidden,
because that can be very expensive during creation, so we might as
well skip reseparate() too. The only time we don't want to skip it
is when we're about to show the list.
This was added from https://bugzilla.gnome.org/show_bug.cgi?id=691979
where it was wanted in order to get a "all children filtered" kind
of row. However, the solution is not really generic enough, because
filtering can happen for other reasons than a full refilter (i.e. due
to a row change), and the partial fix you can get by counting children
after refilter can be achieved by manually doing it whenever you manually
called refilter anyway.
Its possible we should have some better solution for the "empty state"
though.
