Drawing text with Pango is quite expensive, and drawing text and also
blurring it is *really* expensive. To prevent us from drawing a lot of
text and then blurring it a lot is *really* expensive.
We now cache the blurred pixels for the last layout and shadow we made,
which means we can repeatedly draw labels with a blurred text-shadow
extremely fast.
To detect whether the shadow is up-to-date, we track the serial of the
PangoLayout alongside the radius of the box shadow. We don't support
inset shadows nor spread on text-shadow, so we don't need to track
these.
_gtk_css_shadow_value_paint_layout is always called from
gtk_theming_engine_render_layout, which always moves the current point
on the context.
Since we should always have a current point before calling this
function, add an assert do validate that assumption.
These turned out to break existing ui files, concretely
GWeatherLocationEntry was no longer guessed correctly.
Update the testcases to reflect this, and add a testcase
for GWeather.
"Hey I know, let's do an easter egg!"
"What kind of easter egg?"
"We can nest lots of textviews!"
"Sounds cool!"
...
"But how does one see a textview inside a textview?"
"What do you mean?"
"Well, it just looks like black text on a white background."
"You mean it's the same as if we just duplicated the text?"
"Yeah!"
"Hrm, maybe we can put a frame around it."
"Sounds good. I'll stuff the textviews in a GtkFrame."
"What? Why? Let's use a GtkEventBox and override its background"
"Why is that a good idea when we have GtkFrame?"
"Because I said so!"
"Okay."
Overriding the background color for a color swatch is wrong. The color
is not the background, it's the foreground, so it should be painted in
a draw signal handler.
- gtk_style_context_get_background_color()
- gtk_style_context_get_border_color()
Those functions shouldn't be used anymore, because they don't represent
anything from the CSS styling we support. The background color often
isn't used due to background images and there are actually 4 different
border colors (1 for each side) - if there isn't also a border image in
use.
Instead of drawing a gradient in the background color, draw a CSS box.
And change the theme so instead of setting just a background color it
draws a gradient.
The resulting visuals are the same.
Instead of drawing text for selections and links manually, use the
gtk_render_background() and gtk_render_layout() functions.
As a side effect, this allows shadows on selected text and links
and real backgrounds (like gradients or images), too.
I tried asking but nobody knew why it is necessary to set the background
color of the first cell. It seems with CSS styling this is completely
unnecessary.
This fixes shadows that are animated not updating the clip of the widget
they are drawn on. An example of this are the buttons in the CSS shadows
example in gtk-demo.
Reftest included
With buttons at the bottom, things were not looking good here:
no spacing, and a gray background. Add spacing, and put the buttons
on the white background.
It turns out that GtkBuilder will sometimes set a property
twice. Normally, this is harmless, but for GtkRadioButton:group,
it triggered a critical. Remove that.
Remove checks for NULL before g_free() and g_clear_object().
Merge check for NULL, freeing of pointer and its setting
to NULL by g_clear_pointer().
https://bugzilla.gnome.org/show_bug.cgi?id=733157
When allocated more than the requested height, GtkCalendar
was 'falling apart'. Not only was the main part rendered
at the far end of the allocation, clicking on days was
broken in this scenario.
Fix this by always placing the main part directly under
the header and day names.
https://bugzilla.gnome.org/show_bug.cgi?id=737670
The warning may have had some value at some point, but if
people uninstall large icons just to make the warning go
away, it does more harm than good. So just remove it.
Context menus inherit their style from the widget they are attached
to. This can have unexpected effects in particular for font, as can
be seen in gedit or gnome-calculator. Prevent this by resetting
the font of context-menus to the initial value.
GtkSidebar behaves internally much like GtkStackSwitcher, providing a vertical
sidebar like widget. It is virtually identical in appearance to the widget
currently used in GNOME Tweak Tool.
This widget is connected to a GtkStack, and builds its own contents as a
GtkListBox subclass, using the "title" child property to provide a consistent
navigatable widget.
Being a subclass of GtkListBox it benefits immediately from strong keyboard
navigation, and minimal changes are required for theming.
https://bugzilla.gnome.org/show_bug.cgi?id=735293
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Tell people that they need to download and install the Adwaita icon theme,
by following the instructions given on
https://live.gnome.org/GTK%2B/Win32/MSVCCompilationOfGTKStack.
Also tell people they can either use IJG JPEG or libjpeg-turbo for non-GDI+
builds of GDK-Pixbuf.
Since it turns out that x/yalign can't be quite equivalently
replaced by h/valign, bring them back as label properties, so
we can eventually get rid of GtkMisc.
https://bugzilla.gnome.org/show_bug.cgi?id=735841
This adds both a compile time check for the SDK version being
compiled against, as well as a runtime check in the case the
resulting binary is run against an older SDK.
https://bugzilla.gnome.org/show_bug.cgi?id=735054
Add some docs/example about the possible event handling ordering issues
that may appear on GtkGesture::begin between multiple gesture groups.
Mostly relevant for state changes.
The remaining code assumes that the dialog doesn't get destroyed, but
it actually does on delete-event.
In particular, the filter function and the preview text are lost as
soon as the dialog is created and thus when we create a new dialog we
don't have those properties to set on it anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=719936
Factor out the typename-to-get-type mangling as a separate
function, for easier testing.
Also fix some cases where it doesn't, currently, like
GString -> g_string_get_type and
GdkRGB -> gdk_rgb_get_type
The scale in the selectable listbox in page 2 of gtk3-widget-factory
has the flaw that the row is getting selected even when one only
interacts with the scale - unlike e.g. the checkbutton and button
further down in the listbox.
The problem is that GtkRange is trying to claim the sequence for
the drag gesture from the ::pressed handler of a multipress
gesture. Since the drag gesture hasn't seen the sequence at this
point, that is ineffective.
The fix here is to rearrange the gestures so that the multipress
gesture sees the sequence before the drag gesture, and then
claim the sequence from the ::drag-begin handler.
Binding signals can return a boolean indicating whether they
handled the event. Use that here and return FALSE if the
inspector keybinding is disabled.
Loading a builder file with a window leaves a ghost behind, since
windows need to be explicitly destroyed. Avoid that by using
gtk_builder_add_objects_from_resource.
When closing the inspector before the main window, we must take
care to sever all signal connections and weak refs, otherwise
things will go bad when the window is closed later.
When GtkGestureMultiPress::released happens, in_button should be unset
after emitting GtkButton::released, whose default implementation uses it.
Moreover, in_button should only be unset there for real touch events, not
guaranteed to trigger crossing events, as opposed to every pointer/touch
events from touchscreens.
https://bugzilla.gnome.org/show_bug.cgi?id=737297
Instead of hardcoding these actions, consult the settings.
Note that not all of the actions supported by gnome-shell are
implemented here, only maximize, minimize, lower, and menu.
https://bugzilla.gnome.org/show_bug.cgi?id=729782
These match the GSettings that mutter/metacity/gnome-shell have
for this. We change the default for the middle-click action to
none, since lower is just a terrible default.
We're slightly bending the rules here, since we're adding new
settings after .0, but a) it is just barely after .0, and b) settings
are not really application API.
https://bugzilla.gnome.org/show_bug.cgi?id=729782
Some recent refactoring changed things so that in_button is no
longer TRUE when released() is called for touch events. As a minimal
fix, let GtkButton do more of the work by chaining up to its
pressed and released handlers, which know how to handle touch
events. This could be further improved by leaving more of the
state handling to GtkButton, like it was done for GtkToggleButton.
If we have a fullscreen window that covers a monitor, desktop
chrome is not relevant for placing of menus and other popups.
Therefore, return the full monitor geometry instead of the
workarea in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=737251
A popover can go unmanaged for 2 reasons, when the widget it points to
gets destroyed, or transitionally in gtk_popover_set_relative_to(). In
both of these cases it makes sense to only unset popover information
about the previous widget managing it, if the popover is meant to
survive the unmanaging through extra refs.
Also, the focus widget prior to a modal popover being shown is considered
information about the relative_to widget, unset it on
gtk_popover_update_relative_to() with the rest.
https://bugzilla.gnome.org/show_bug.cgi?id=736193
This gives an opportunity for implementations to handle these events
differently, instead of hardcoding the WM-triggering behavior.
gtk_window_event() only forwards events for WM management if the event
widget is not the window (ie. caught when bubbling), so is safe to be
called here without triggering gtk_window_handle_wm_event() twice.
This commit is an adaption to master of
https://bugzilla.gnome.org/show_bug.cgi?id=736702#c1 by Cosimo Cecchi.
If !owner_events, the pointer window has been usually set to NULL if
the pointer fell outside the grabbing widget, but it was not being
checked that the pointer_window is actually a child of the grab
window, in which case it should be obtained as if ungrabbed.
https://bugzilla.gnome.org/show_bug.cgi?id=735749
On regular scrolling (ie. not natural scrolling), positive deltas in the
Y axis (downwards) should actually move the value towards the adjustment
minimum value to be more intuitive. This also makes the scrolling
directions match between the button and the popped up scale.
https://bugzilla.gnome.org/show_bug.cgi?id=736830
Settings have a little more metadata than plain properties. They
can come from different sources. Make this information available
so we can show it in the inspector.
https://bugzilla.gnome.org/show_bug.cgi?id=736971
Windows needs a shared library to link the modules against, otherwise
the undefined symbols make it not work.
So build a shared library on Windows.
We don't want a library elsewhere, as that just complicates things, so
we only make the library shared on Windows and keep it as a noinst
library otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=736338
For symbolic icons, we prefer symbolics in inherited themes over
generic icons in the theme itself. So far this was implemented
by looking at icon_name[0] and looking that up in inherited themes
if it is symbolic. But with automatic rtl/ltr handling, the first
icon name will always have an -rtl or -ltr suffix, and an icon
with that suffix is not going to exist in most cases. To fix this,
look for shorter icon names too, as long as they are still symbolic.
https://bugzilla.gnome.org/show_bug.cgi?id=737000
This is a noinst library for now, but the idea is to turn it into a
proper DLL on Windows, so that we can install it and properly link the
modules to it. Windows doesn't allow undefined symbols in modules.
https://bugzilla.gnome.org/show_bug.cgi?id=736338
Otherwise, they might not be properly set before the window is mapped.
For the opaque region and border window, it means that they won't get
set before the next size allocation, which tends to not be a bit deal.
For the shadow width, though, _GTK_FRAME_EXTENTS has a different meaning
when it's set before the window is mapped, so we need to make sure that
it's properly set when the window is mapped.
- Move the class to the Deprecated section.
- Warning at the bottom of the class description.
- A missing property was not marked as deprecated.
- Update doc of gtk_container_set_border_width() to not mention
GtkAlignment.
https://bugzilla.gnome.org/show_bug.cgi?id=736622
This updates the property sheets that are used to "install" builds of GTK+
after the libraries and the gtk3-demo programs are built. Note that these
are generated with scripts in regards to the headers part, so that we can
move the header installation part to use autocompletion by the autotools
build files in the next dev cycle or so, like the "gdk" and "gtk" project
files.
This allows us to access otherwise hidden windows, which can be
useful to provide better debug information than would be available
through other means.
https://bugzilla.gnome.org/show_bug.cgi?id=736557
There was some X11-specific code before an early exit
in the functions that grab and ungrab keys during DND.
It seems to not cause a problem under Wayland, but moving
it out of the way seems right anyway.
If the query fails because it has been cancelled, it means that
dispose() has been called, so don't try and update anything.
This fixes a segfault with Nautilus in certain situations.
https://bugzilla.gnome.org/show_bug.cgi?id=736512
fr(bepo) XKB keymap sends dead_stroke with AltGr+l keys
and gtk-im-simple-context should send '/' with
dead_stroke+dead_stroke keys but gtkimcontextsimpleseqs.h
was not sorted in the descending order and failed to get
dead_stroke.
Also need to add dead_currency for Shift+AltGr+e and
dead_belowcomma for Shift+AltGr+Cedilla.
https://bugzilla.gnome.org/show_bug.cgi?id=736250
This is an expected keybinding, and it is not hard to support.
Note that we use a private ::escape signal instead of using
::cancel directly, since we want to be able to suppress the
cancellation when we are on a progress page.
https://bugzilla.gnome.org/show_bug.cgi?id=579625
When closing the application window before closing the inspector window,
the selected widget will be set to NULL once and all the property pages
will try to g_object_weak_unref that NULL widget, so bail out in
gtk_inspector_prop_list_set_object if it's NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=736201
When GtkApplicationWindow has a menubar, we don't chain up
to the GtkWindow size_allocate, which used to position the
popovers. Move that to _gtk_window_set_allocation() which
is always called by GtkApplicationWindow.
https://bugzilla.gnome.org/show_bug.cgi?id=736205
... just because there is no style context instantiated yet. Instead,
instantiate a style context during realize() and ask it.
Fixes problems with dim labels not being dimmed on first show.
Testcase included.
https://bugzilla.gnome.org/show_bug.cgi?id=735240
Just pretend that the main widget is an empty widget the size of the
overlay.
Makes it possible to write testcases where no size requests are run on
overlay widgets before size_allocate() is called.
Testcase included.
(gnome-shell-extension-prefs:22382): GLib-GObject-WARNING **: invalid cast from 'GtkInvisible' to 'GtkWindow'
(gnome-shell-extension-prefs:22382): Gtk-CRITICAL **: gtk_window_set_transient_for: assertion 'parent == NULL || GTK_IS_WINDOW (parent)' failed
#1 0x00007fffeeb81a12 in g_log (log_domain=log_domain@entry=0x7fffeeea3464 "GLib-GObject", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x7fffeeeaa878 "invalid cast from '%s' to '%s'") at gmessages.c:1079
#2 0x00007fffeee9c2a9 in g_type_check_instance_cast (type_instance=0xb314c0, iface_type=iface_type@entry=9020048) at gtype.c:4021
#3 0x00007ffff0a06e25 in gtk_tooltip_set_last_window (tooltip=tooltip@entry=0xbb8c10, window=<optimized out>) at gtktooltip.c:910
#4 0x00007ffff0a08dfd in _gtk_tooltip_handle_event (event=event@entry=0xbf72c0) at gtktooltip.c:1538
#5 0x00007ffff090d7a9 in gtk_main_do_event (event=0xbf72c0) at gtkmain.c:1785
#6 0x00007ffff0496ab2 in gdk_event_source_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at gdkeventsource.c:364
#7 0x00007fffeeb7a8c3 in g_main_dispatch (context=0x807300) at gmain.c:3067
https://bugzilla.gnome.org/show_bug.cgi?id=736131
The list of devices was being scanned over incorrectly, causing us to
never actually fetch the keymap from the keyboard, as the keyboard was
the second device in the list, not the first.
This causes us to create a new temporary keymap every time, which is
quite expensive, because it involves parsing the entire XKB
file. Scanning the list correctly will cause us to use the XKB rules
file that was passed to us.
The "too dark" background was caused by box-shadow inherited by
window-frame.csd, so box-shadow: none and the right background
color on tooltip selector.
This is a temporary workaround for scrolling units being amplified
on quartz, due to the assumption that smooth scrolling deltas are
always in some abstract unit similar to the one from xi2.
A proper solution for the situation is described in bug #736121, but
since we are close to release, this patch solves the issue temporarily.
https://bugzilla.gnome.org/show_bug.cgi?id=736121
Those used to work indirectly due to GtkEntry not setting GDK_TOUCH_MASK,
so pointer emulation would happen on those, but the event handlers on icons
and its icon-pressed/released signals have never been explicitly touch
aware, and this broke since the GDK_TOUCH_MASK can be set indirectly by
GtkGestures.
So make the icon event handler handle touch events, each icon can get hold
of one GdkEventSequence, reacting exclusively to it. This is still not
ported to GtkGesture due to GdkEvent exposure in these icon signals, as
users might expect GDK_2/3BUTTON_PRESS while GtkGesture ignores those.
Also, unset all icon pressed/sequence state on grab-notify, this used to
happen ad-hoc when initiating icon DnD, but that doesn't cut it for
user-defined reasons to initiate a grab (eg. popovers).
https://bugzilla.gnome.org/show_bug.cgi?id=736004
- cover missing statusses in selection-mode and the like
- button drawing functions cleanup and extension
- remove inline toolbar (ugly) special case not needed anymore
- button selector structure simplification and rationalization
- add back shadow to window control buttons
This is so signal handlers have an opportunity to undo its effect by
returning GDK_EVENT_STOP on ::button-press-event, just like they used
to do pre-gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=735965
This was forgotten when making DnD use a GtkGesture in the handlers
attached to the widget in gtk_drag_source_set(). The gesture must obey
the specified button mask, and switch to denied state if the pressed
button isn't part of the given mask.
https://bugzilla.gnome.org/show_bug.cgi?id=735965
Using the setting for this property conflicts with the documentation
for gtk_entry_completion_set_text_column() which explicitly states
that setting the property directly behaves differently. Concretely,
this caused the file chooser entry completion popup to have two
columns (with identical content).
This partially reverts 331c28b369.
When links are entirely hidden in an ellipsis, don't let
them be activated by clicking and skip them when moving
the focus around.
This commit depends on enhancements in pango 1.36.7 which
make it possible to find the ellipsed runs in a PangoLayout.
With older pango, things will work the same way as before.
https://bugzilla.gnome.org/show_bug.cgi?id=668258
The entry mixin now allows to specify the color of the widget bottom
edge hilight, istead then just enable/disable it, so `$noegde: true`
now is `$egde: none` or `$edge: $somecolor`, not setting it draws
the edge with the default theme color.
Add rows with buttons and checkboxes to the listbox example
on page 2, and make the switch in row 1 toggle selection mode,
to test various cases of widgets in 'selected context'.
Calling this on an Xlib surface allows us to keep this in SHM memory,
giving it a potential speedup so we don't have to copy it to SHM memory
for the Composite when we mask later.
When recursing the update area down into native subwindows we forgot
to apply the native window position. This caused us to repaint the
wrong thing in certain cases. I noticed this when playing with the
wip/gdk-gl branch, because it was triggering unnecessary repaints
of the (native window) gl widgets.
Tools like damn-lies rely on being able to generate .pot files
from pristine checkouts, so everything that goes into the .pot
file has to be in git. This is not ideal, but we already do
the same for other .ui.h files in GTK+.
Otherwise, git.mk will add them to .gitignore, and we want to
add them to source control for the benefit of tools like damn-lies
which rely on being able to generate a .pot file from a pristine
checkout.,
A surface may be hidden when a frame is already scheduled, which may cause
crashes on on_frame_clock_after_paint() when calling commit() on a NULL
surface. To fix this, ensure commit_pending is also set to FALSE when the
surface is gone.
https://bugzilla.gnome.org/show_bug.cgi?id=735226
When a printer requires auth_info (e.g. a printer connected
over the samba protocol) it is now possible to save the
credentials necessary for printing if a secrets service
is available over dbus.
The auth_info is then stored / loaded from the default
collection of that secrets service.
If no such service is available the user is not shown
the option to remember the password and the behavior
remains the same as before.
https://bugzilla.gnome.org/show_bug.cgi?id=674264
Only static cursors are supported in gdk_device_grab() so far. Obey the
cursor that gdk_device_grab() specifies, which may be different to
the pointer window one. As soon as the grab is gone, the pointer window
cursor will be restored as usual.
https://bugzilla.gnome.org/show_bug.cgi?id=735831
On DnD, pointer_handle_leave may be triggered without the pointer actually
leaving the window, and pointer_handle_enter() happening after intra-window
DnD won't actually manage to update the cursor (it does nothing directly,
and to the upper layers the cursor is still the same and consistent, so no
attempt will happen).
To fix this, keep the pointer cursor on leave, and ensure it is updated
on enter. The pointer cursor will be updated to any current new one through
the enter/motion events generated if it needs be.
https://bugzilla.gnome.org/show_bug.cgi?id=735831
cairo_surface_destroy() is called after the buffer is released, for every
wl_buffer. Windows usually reference their cairo surface before rendering,
so that extra reference is consumed after the buffer is released, so do
the same with cursor surfaces and add an extra reference whenever a cursor
surface change is about to be scheduled.
Otherwise, the GdkWaylandCursor is left with an invalid cairo_surface_t,
which causes crashes the next time it is used.
https://bugzilla.gnome.org/show_bug.cgi?id=735830
This must be called while the window is not realized yet, and sets the
GdkWindow that will be used for the next GtkWindow's realize/unrealize
cycle. The GtkWindow takes ownership on the GdkWindow, and as such it
will be destroyed when the widget is unrealized.
https://bugzilla.gnome.org/show_bug.cgi?id=697855
On wayland the DnD surface must be created early when starting the drag
operation, so offer API for GTK+ to get the GdkWindow used as a DnD
surface on the drag operation.
https://bugzilla.gnome.org/show_bug.cgi?id=697855
The wl_data_source is retrieved from the selection object for the DnD
selection, and used to initiate a drag. When the drag is finished, a
button release or touch end event is synthesized to finish the DnD
operation after the compositor grab is gone.
https://bugzilla.gnome.org/show_bug.cgi?id=697855
The wayland specific clipboard functions have been replaced by something
more similar to the hooking the win32 backend does, which allows for just
using the default GtkClipboard code in GTK+. As a consequence, the
wayland-specific GtkClipboard implementation is now gone.
https://bugzilla.gnome.org/show_bug.cgi?id=697855
This has been made to work similarly to X11, requests for the data device
contents are notified through GDK_SELECTION_REQUEST events, the data stored
in the GDK_SELECTION property as a reaction to that event is then stored
into the wayland selection implementation, and written to the fd when
requested/available.
https://bugzilla.gnome.org/show_bug.cgi?id=697855
This implementation makes the destination side of selections work
similarly to X11's, gdk_selection_convert() triggers data fetching,
which is notified through GDK_SELECTION_NOTIFY events on arrival,
the buffered data is then available through gdk_selection_property_get().
https://bugzilla.gnome.org/show_bug.cgi?id=697855
What was happening that the button press event that we use
to select a widget caused another clicked signal emission of
the inspect button, starting another pick action.
Both Owen Taylor and I, the originators of this code, allow the code
herein be relicensed to the LGPL, which is what GTK+ ships with. This
prevents GTK+ from being GPL-only.
Add yet another set of checks and radios assets used in selected
treeview cells and selected list-rows, the standard dark variant assets
work well in those cases so no need for special casing there.
Use the left border color for tree lines. This is similar to
our use of top border color for grid lines. As a side-effect,
tree lines now get recolored when they are in a selected row.
https://bugzilla.gnome.org/show_bug.cgi?id=415415
We need to be a little more forthcoming with showing and hiding
the separators - their visibility now depends on the the visibility
and pack type of the regular headerbar children. This was observed
in gnome-contacts, where headerbar buttons are shown and hidden.
We used to move help buttons to the secondary position regardless
how they were added to the action area. Keep doing that, to avoid
breaking existing dialogs that rely on this behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=735119
The previous way to invalidate was meant to work on the overshoot window
so it wouldn't be as taxing. Since the overshoot window is gone, this
would invalidate way more than intended. So constrain invalidated areas
to the sides where overshoot is happenning at that moment.
https://bugzilla.gnome.org/show_bug.cgi?id=735223
Using `font: Bold` will override the font with whatever the system
resolves a `Bold` font name to, including the font's own default size.
We want the font weight to be bold, but we want the default font name
and size to come from the GtkSettings:font-name property, like we do for
the rest of the system.
with non-installed tests the build would get an empty $(reftestdir)
which would screw up the LDFLAGS.
An rpath seems to be required to make libtool build a shared object.
Without an rpath line, it only builds a static object.
https://bugzilla.gnome.org/show_bug.cgi?id=735401
... for displaying resources. Instead use the proven and way more
reliable method of trial and error.
It's less code and more portable for a start.
But most of all it displays PNM files as text if you fail to compile
the gdk-pixbuf loader for it.
Subsurface position is deemed part of the state of the parent surface, so
ensure wl_surface_commit() happens on the parent surface if none is
scheduled, so the repositioning takes place.
The pre-gestures code used to compare the current button press with the
previous one on !activate_on_single_click, and unset the previous event
data so ::row-activated would be emitted every 2 clicks.
So do the same with the multipress gesture and reset it after every 2nd
click to have ::row-activated emitted multiple times while manic clicking.
https://bugzilla.gnome.org/show_bug.cgi?id=735353
Since GLib ≥ 2.41, attempting to release an unlocked mutex will abort(),
as it happens on most systems already.
Given the lack of proper documentation on how to use GDK with threads,
there is code in the wild that does:
gdk_threads_init ();
gdk_init ();
...
gtk_main ();
instead of the idiomatically correct:
gdk_threads_init ();
gdk_threads_enter ();
gtk_init ();
...
gtk_main ();
...
gdk_threads_leave ();
Which means that gtk_main() will try to release the GDK lock, and thus
trigger an error from GLib.
we cannot really fix all the wrong code everywhere, and since it does
not cost us anything, we can work around the issue inside GDK itself, by
trying to acquire the GDK lock inside gdk_threads_leave() with
trylock().
https://bugzilla.gnome.org/show_bug.cgi?id=735428
This makes the active state work invariably with both mouse/touch, and
regardless of X11 pointer emulation being friendly and sending crossing
events for the emulated pointer events in the latter.
This makes GtkButtons' active state look correct when pressing on
touchscreens on wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=731380
This is a rather hackish way to let GTK+ widgets declare popup windows
as subsurfaces, so they may work on wayland without the need of xdg_popup,
and without many changes yet on the GTK+ side.
https://bugzilla.gnome.org/show_bug.cgi?id=695504
The latest implicit grab serial is used in order to start the compositor
grab, If it belongs to a touch event, remove that touch sequence, as the
rest of the sequence will be gone for good.
This avoids stale sequences (and implicit grab info) after a window is
moved/resized.
https://bugzilla.gnome.org/show_bug.cgi?id=731380
_gdk_wayland_device_get_button_press_serial() has been replaced by
_gdk_wayland_device_get_implicit_grab_serial(), which takes a touch/pointer
event and figures out the relevant serial, and
_gdk_wayland_device_get_last_implicit_grab_serial() which returns
the most recent serial.
The button press serial was currently used when operating popping up
xdg_shell/surface popups and window menus, so this is now touch aware, of
some sort.
https://bugzilla.gnome.org/show_bug.cgi?id=734374
If the compositor sends a keymap that fails on "compilation",
xkb_keymap_new_from_string() returns NULL, which makes xkb_state_new()
crash when assuming there is a keymap.
In these cases, gdk must remain with a xkb_state to handle modifiers/keys
properly, so warn about the invalid keymap string, and keep the previous
keymap (currently initialized to "us")
https://bugzilla.gnome.org/show_bug.cgi?id=735389
To all effects each window has its own "root" coordinates system, so set
toplevels at 0,0 in that coordinate system, so root coordinate calculations
are locally right.
https://bugzilla.gnome.org/show_bug.cgi?id=729215
Try to tidy up how the background is set on the textview:
*) the .view class should be applied only to the text window, not
to the margins
*) when setting the background on the margins we must use .left etc
*) use context_set_bg instead of manually setting the color
https://bugzilla.gnome.org/show_bug.cgi?id=735368
gtk_css_section_get_end_position() can return a position one byte beyond
the end of the last line.
gtk_text_buffer_get_iter_at_line_index() accepts only valid
line_number/byte_index pairs. Another solution is to make the
GtkTextBuffer function less strict, by returning a boolean if the exact
position was found.
The CSS parser should also be fixed to always return valid positions.
But it's better to have a safety net in the CSS editor, just in case (a
warning could be print).
https://bugzilla.gnome.org/show_bug.cgi?id=735337
This implements native fullscreen mode on OS X >= 10.7. This patch
adds tracking of the fullscreen mode if externally modified, as well
as toggling the native fullscreen mode of the window as needed.
The timeout ID used to be unset after we got the targets from the
clipboard, but there's still a moment between the clipboard request and
the GDK_SELECTION_NOTIFY event that the ID points to an already gone
timeout.
There is an insensitive label in widget-factory which was
not getting any different from the sensitive label next
to it. With this patch, it does, again.
Use U+00D7 MULTIPLICATION SIGN and U+200A HAIR SPACE instead of plain
old 'x' and ' ', following https://wiki.gnome.org/Design/OS/Typography.
Sadly, many fonts don't have space variations, so Pango/harfbuzz fall
back to using the regular space glyph anyway.
NULL was returned in case of an empty last line. Every users needed to
special-case this. Now it will return the expected result: char_len of 0
with one PangoLogAttr.
In compute_log_attrs(), 'paragraph' will be the empty string "" with
'char_len' == 0.
pango_get_log_attrs() works fine with an empty string, it will return
one correct PangoLogAttr (because there is one text position for the
empty string).
It fixes the unit tests for gtk_text_iter_is_cursor_position().
https://bugzilla.gnome.org/show_bug.cgi?id=156164
For functions using _gtk_text_buffer_get_line_log_attrs():
- gtk_text_buffer_backspace()
- some gtk_text_iter functions (word/sentence/cursor boundaries)
As the FIXME comments show, there is a bug with
gtk_text_iter_is_cursor_position() for an empty last line.
https://bugzilla.gnome.org/show_bug.cgi?id=156164
There was some confusion between unflipped and flipped positions.
Both final_position and current_position are meant to be unflipped,
and get_effective_position() needs to be applied to them to get
a flipped position. _gtk_window_set_popover_position() also expects
an unflipped position.
https://bugzilla.gnome.org/show_bug.cgi?id=735014
This was introduced as a hackish way in 3.6 to make font updates
propagate properly. But since then, font handling has been changed and
this flag is no longer necessary.
gtk_style_context_invalidate_internal() will respect only the current
saved state of the style context, which is wrong when updating the scale.
In that case, the whole style context needs updating.
- only one blank line is enough to separate code sections.
- the 'signals' variable was in the middle of function prototypes.
- compare pointers to NULL in some conditions ("if(blah) should be used
only if blah is a boolean variable). It makes the code clearer.
- various other things.
This is a hack to get around the optimizations done by the CSS engine.
The CSS engine will notice that no CSS properties changed on the
widget itself when going from one state to another and not queue
a redraw.
And the reason for no properties changing will be that only the
checkmark itself changes, but that is hidden behind a
gtk_style_context_save()/_restore() pair, so it won't be caught.
This is more for GTK developers to catch when they forgot to change
GTK_STATE_FLAGS_BITS after adding a new state flag than to prevent
widget developers from using the wrong flags.
This was a hack we added in early 3.x to allow themes to customize their
checkmarks.
Now that we want to properly support real backgrounds everywhere,
supporting this feature would cause double draws of backgrounds.
... in places where we draw a background. This was changed for GTK 3.0.0
to allow animations, but these days it doesn't make sense anymore to use
gtk_render_activity() for backgrounds.
All buttons should always be marked as :active when they are pressed.
That includes checkboxes (which are never activated in real code anyway,
so this change pretty much doesn't matter).
It doesn't make sense to support child displacement in a world where
pseudoclasses behave different from the actual displacement states.
Nobody would ever understand why a widget is displaced.
It is easily possible to simulate child displacement by using padding
CSS properties.
on:
- GtkToggleButton
- GtkCheckButton
- GtkRadioButton
- GtkModelButton
- GtkCellRendererToggle
- GtkCheckMenuItem
also update themes:
- Adwaita
- Raleigh
but not the win32 theme.
The new :checked state replaces :active for the actual checkedness of
the widgets and :active is now used exclusively while the button is being
pressed.
https://bugzilla.gnome.org/show_bug.cgi?id=733967
The font chooser constructs the display name for the font from
the family and face names. Do the same in the font button, so
we don't end up calling the same font by different names, which
would be confusing.
Instead of reconstructing a display name from the
PangoFontDescription, use the font family and face
objects, which have the original font. This lets us
get the names of fonts like Noto Sans CJK DemiLight
right, which would be shown as Noto Sans CJK SemiLight
when mangled via PangoFontDescription, since Pango
treats 'DemiLight' as an alias for the SemiLight weight.
https://bugzilla.gnome.org/show_bug.cgi?id=733832
GtkStatusIcon is using a problematic, XEmbed-based protocol under X,
and we want to get rid of it eventually. Document our intentions by
marking GtkStatusIcon as deprecated.
https://bugzilla.gnome.org/show_bug.cgi?id=734826
That gesture is meant to handle clicks on multiple buttons, so unset
the GDK_BUTTON_PRIMARY default. Also, remove unnecessary boilerplate
with the new GtkGestureSingle/GtkEventController defaults.
https://bugzilla.gnome.org/show_bug.cgi?id=734285
That gesture is meant to handle clicks on multiple buttons, so unset
the GDK_BUTTON_PRIMARY default. Also, remove unnecessary boilerplate
with the new GtkGestureSingle/GtkEventController defaults.
https://bugzilla.gnome.org/show_bug.cgi?id=734285
That gesture is meant to handle clicks from several buttons, so unset
the new GDK_BUTTON_PRIMARY default. Also, remove unnecessary boilerplate
with the new default values.
https://bugzilla.gnome.org/show_bug.cgi?id=734285
GtkGestureSingle::button is set to 0 on the multipress gesture, as several
buttons are managed by that gesture. Also avoid some extra lines of code
setting what nowadays are default values.
https://bugzilla.gnome.org/show_bug.cgi?id=734285
GtkGestureSingle::button is set to 0 on the drag/multipress gestures, as several
buttons are managed by these gestures. Also, avoid some extra lines of code
setting what nowadays are default values.
https://bugzilla.gnome.org/show_bug.cgi?id=734285
GtkGestureSingle::button is set to 0 on the multipress gesture, as several
buttons are managed by that gesture. Also avoid some extra lines of code
setting what nowadays are default values.
https://bugzilla.gnome.org/show_bug.cgi?id=734285
GtkGestureSingle::button is set to 0, as multiple buttons are managed by
the same gesture. Also avoid some extra lines of code setting what nowadays
are default values.
https://bugzilla.gnome.org/show_bug.cgi?id=734285
At the present time broadway listens only for TCP/IP incoming
display connections. This patch implements the support for listening
on unix domain sockets too, adding the broadway_server_on_unix_socket_new()
constructor and the commandline option --unixsocket [path] to broadwayd.
https://bugzilla.gnome.org/show_bug.cgi?id=734420
gtk_statusbar_remove_all() was popping the top message if its
context_id matched before removing other matching messages from the
stack. This meant that if the context_id of the second top message
matched it was still displayed when the top message was popped and
then removed from the list of messages without updating the display.
Fix this by removing all the matching messages below the top one
before popping it if it matches.
https://bugzilla.gnome.org/show_bug.cgi?id=724281
Changing adjustment via the property setter would not emit
value-changed, however changing it via gtk_spin_button_configure would.
This inconsistency had the following side-effects:
- Setting an adjustment with a different value would not update the
value shown by the spin button.
- Creating a spin button like this (common in GtkBuilder XML) will
not show the initial value:
g_object_new (GTK_TYPE_SPIN_BUTTON, "adjustment", adj, NULL);
Let's use the same code path (ie. gtk_spin_button_configure) for all
public facing API for setting adjustment. The code that handled the
details of swapping out the old adjustment with the new has been split
into an unset_adjustment method and the rest has been folded into
gtk_spin_button_configure.
A spin button really needs an adjustment to work, so we don't need
most of the NULL checks. However we do need to check in
unset_adjustment because setting a new adjustment during object
creation might try to unset a non-existent one.
https://bugzilla.gnome.org/show_bug.cgi?id=734660
As a noinst_PROGRAMS, the libtool generated for cross-compiling will be
used, which will mess up the linking. Create a all-local target instead.
Also ensure that building uses always a native version of the tool by
specifying a GTK_UPDATE_ICON_CACHE automake variable.
Finally "config.h" has been created to work for the target platform and
causes problem when cross-compiling. So we temporarily generate a basic
config.h which contains only the strict minimum.
It is actually a bad idea to use noinst_PROGRAMS for build tools,
because it adds a $(EXEEXT). It is best to override the all target
with all-local to trigger the tool build.
When using the pre-rendered png symbolics it seems that we're off a
tiny bit in a few of the pixels on the antialiased borders of a
stroke. To fix this we switch the icon to media-playback-stop-symbolic
which has no such antialiased borders.
I don't quite understand why the pixels are off, this needs more
research.
https://bugzilla.gnome.org/show_bug.cgi?id=734668
If the foreground color has an alpha != 1 we used to just pass that into
the svg. This is useful to e.g. render an insensitive icon. However,
that is not an ideal model for symbolics. For instance, if the icon uses
overlapping areas when drawing, expecting these to be opaque then the
transparent color will result in a different alpha value for the overlapping
area. Also, non-foreground symbolic colors are still rendered opaque, and
the recoloring of pngs can't handle transparent colors.
So, instead we extract any alpha from the foreground, render using the
opaque colors and then apply the foreground alpha to the entire result.
This means we get an even transparency, even for other colors, and we
can apply alpha for the pngs too.
https://bugzilla.gnome.org/show_bug.cgi?id=734668
_gtk_icon_helper_get_size() is often used during size request and may
not necessary mean that the icon will be displayed immediately. In
many common cases we know the size without having to ensure a surface.
In many cases this means we can avoid loading an icon until needed, and
in the case of stateless IconHelpers such as GtkCellRendererPixbuf this
is very important as otherwise it will constantly be reloading icons
if the displayed set is larger than the in-memory icon cache.
https://bugzilla.gnome.org/show_bug.cgi?id=734651
If a child has set_has_window == FALSE, it purely relies on the events set on
the parent window, for which the bin window used to just ensure the exposure
mask, eating all input events.
https://bugzilla.gnome.org/show_bug.cgi?id=734357
gtk_widget_get_events() must indeed tell about events enabled purely through
a GtkEventController, those events will most surely trigger event handlers.
https://bugzilla.gnome.org/show_bug.cgi?id=734357
Change the initial value to something that is not a multiple of 3, so
that dismissing the notification on reset makes sense. Let's use 50
because that is already being used elsewhere.
https://bugzilla.gnome.org/show_bug.cgi?id=734614
This check used to be present in the pre-gestures code, but was unintentionally
removed when splitting code into drag/multiclick gestures. The policy used to
be that if clicking happened on an already selected node, DnD would happen
instead of rubberband selection, so this behavior is resuscitated.
https://bugzilla.gnome.org/show_bug.cgi?id=734143
Make gtk-reftest consult the REFTEST_MODULE_DIR environment
variable to find out where to look for modules, and fix the
libtool hack to construct the .libs subdirectory correctly.
This was another victim of clipping changes - the labels were
overdrawing each other, leading to test failure. Prevent this
by separating the grid columns.
I found that setting margins to zero makes the textview clip
away some overshooting pixels. So, instead of a 0/10 split,
do this test with a 2/8 split of margins, to avoid the clipping
issue.
AM_PATH_GTK_3_0([3.4], [], [], [gthread]) results in calling
"pkg-config --atleast-version 3.4 gtk+-3.0 gthread-2.0".
With pkg-config 0.28, that test fails, because the version of
gthread-2.0 is smaller than 3.4. This appears to be a behaviour
change since 0.26, but matches what the documentation said in 0.26.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=641638
Bug-Debian: https://bugs.debian.org/756476
Reviewed-by: Matthias Clasen <mclasen@redhat.com>
This shows what one currently has to do manually to get the typical
selection mode with blue headerbar and checkboxes in list rows.
The goal is to make this easier.
Make the Visual C++-related build files contain the actual GTK+ version, by
generating them during the configure stage and dist'ing them in the release
tarballs. This is especially important for builds of introspection files,
as one may need to look at the release version of GTK+ in those files.
Define ISOLATION_AWARE_ENABLED for the build of the GTK DLL so that visual
style can be applied to the Windows print dialog for all applications using
gtkprintoperation.
Update the script for the generation of gtk-win32.rc for MSVC to not try to
embed the manifest from it (but embed libgtk3.manifest by including it in
the project files, as we are now doing), and embedding the manifest file is
really not supported in MSVC 2010 and later.
Also fix up formatting in the GTK DLL projects.
https://bugzilla.gnome.org/show_bug.cgi?id=733773
gtk_gesture_drag_get_start_point and gtk_gesture_drag_get_offset
have out args that need to be annotated.
This commit adds the (out) and (nullable) annotations as appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=734292
Use the Python script that was used to create gtk-win32.rc from
gtk-win32.rc.in to similarly create libgtk3.manifest. As the wildcard
character can be used for all architectures, use that.
The libgtk3.manifest file needs to be specified explicitly in the projects,
so that it will be recognized and built into the GTK dll, so update the
project files as well on this part.
https://bugzilla.gnome.org/show_bug.cgi?id=733773
For that to happen the libgtk3 is embedded with a manifest that requests
common controls library 6.x, and GTK lazily calls InitCommonControlsEx()
to initialize those. Then this manifest is used to temporarily override
the process activation contest when loading comdlg32 (which contains the
code for the print dialog), ensuring that it too depends on common
controls 6.x, even if the application that uses GTK does not.
https://bugzilla.gnome.org/show_bug.cgi?id=733773
handle_x always corresponds to the visible position of the handle,
which is where we want to start the animation. Without this, repeated
keyboard activation will not always animate.
Since we are storing positions here that depend on the allocation,
we need to update them in size-allocate. This fixes incorrect
positioning of the handle if the switch is active initially.
https://bugzilla.gnome.org/show_bug.cgi?id=734213
This adds a new test which can be scripted to trigger various
event and action sequences, and record state changes in the
accessibility layer.
So far, there are a few tests verifying state changes when
focus changes.
Related to https://bugzilla.gnome.org/show_bug.cgi?id=715176
This utility would likely be useful for Windows builds of GTK+, given the
reasons Alex cited for coming up with this utility[1], and MSVC build
support for librsvg is not available at this time (possible, but not
implemented yet).
[1]: https://bugzilla.gnome.org/show_bug.cgi?id=730450
In bug 733773, gtk-win32.rc was removed from the dist in the attempt to
make the print dialog on Windows themed, so this script was added so that
the gtk-win32.rc file can be generated during the Visual Studio builds of
GTK+ from the autotools scripts. This is also intended for filling in the
arch of the build for MSVC builds for the manifest that is also required
for fixing bug 733773. Python is used as it is already needed for
This is done as a custom build rule in the Visual Studio projects so that
it is easy to clean and rebuild gtk-win32.rc upon an update.
https://bugzilla.gnome.org/show_bug.cgi?id=733773
Rows are not necessarily selected via select_row_internal(), add
the missing signal emissions there. Also the signal should be emitted
when removing the selection altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=729809
This counterpart to gtk_application_get_accels_for_action() lets you
find out if a particular accelerator has one or more actions associated
with it. This might be useful from an accelerator editor or plugin
system to prevent the the installation of conflicting accelerators.
https://bugzilla.gnome.org/show_bug.cgi?id=721367
Currently, jhbuild-ing GTK+ on Ubuntu 14.04 LTS and gcc 4.8.2 errors out with
/usr/bin/ld: encodesymbolic.o: undefined reference to symbol 'g_file_new_for_path'
/opt/gnome/lib/libgio-2.0.so.0: error adding symbols: DSO missing from command line
when trying to build gtk-encode-symbolic-svg. This is because $(GTK_DEP_LIBS) isn't defined in $(gtk_encode_symbolic_svg_LDADD) in gtk/Makefile.am. This patch should fix that.
Thanks to b4n and gregier in irc.gimp.net/#gtk+ for help.
https://bugzilla.gnome.org/show_bug.cgi?id=734201
An animation may be scheduled while the textview content changed in size, so the resize
queued would just unset the animation and set the adjusments with a current value,
defeating gtk_text_view_scroll_to_iter(). In this case, just avoid the adjustment change,
as there is a target value on the way.
https://bugzilla.gnome.org/show_bug.cgi?id=733406
Popovers may get relocations optimized away if only x/y changed
in the GtkAllocation. So make sure the toplevel updates popover
positions on all situations.
https://bugzilla.gnome.org/show_bug.cgi?id=729140
It is bad if the image that is used as a fallback for missing
images goes missing itself, so include it as a resource. This
way, it will always be available.
The rules-hint property has always been a fairly bad application API, as
it set some wrong expectations for the developers; deferring to the
theme makes it impossible to design application reliably, and if this is
a usability setting we should either impose this setting on every theme,
or simply drop it.
Our own default theme does not honour the zebra striping, which makes
this function even more questionable.
In practice, usability studies on zebra striping have demonstrated that
alternating colors on a list it improves readability just as much as
clear ruling between rows, or by visually differentiating the selected
row. Zebra striping improves readability (or, at least, it does not
hinder it) on static displays, like a table on paper or a document; on a
dynamic display, like an application's UI, there are different
strategies that yield similar, if not better, results.
https://bugzilla.gnome.org/show_bug.cgi?id=733312
The next call to gtk_list_box_get_selection_mode just expected the
GtkListBoxRow's parent to be a GtkListBox and failed when the row was
added to something other than a GtkListBox.
https://bugzilla.gnome.org/show_bug.cgi?id=733782
If an icon theme has a file called "foo-symbolic.symbolic.png" which
was converted from svg using gtk-encode-symbolic-svg we will read
it in an recolor, allowing symbolic icons without using librsvg.
https://bugzilla.gnome.org/show_bug.cgi?id=730450
If the same position is requested on a popover, it should at least ensure
the window is realized and raised, even if no resizes are queued on the
content. Otherwise other widgets being mapped might raise the windows over
the popover's if its original position is unchanged.
https://bugzilla.gnome.org/show_bug.cgi?id=734129
It turns out that when we were painting the shadows, we painted the them
with the base color once, which contained the alpha, and then blurred it
and used it as a mask for the fill, which has the fill again.
To fix this, always paint the base surface with full alpha. The existing
code applies the blur conditionally sometimes in weird ways, so the code
shuffling fix may not look correct, but be assured it is. If the blur
happens, the new cr we return has the *default* color applied, which is
fully opaque black, which works perfectly against the A8 surface.
The fallback spinner code needs some modification, since it is
intentionally using the alpha to paint the lobes which are "in the past".
Since we shouldn't be hitting this fallback path very often, we use a
temporary group and paint it with paint_with_alpha, even though it is
slow.
Introduce a new debug category "actions" and write some messages from
GtkActionHelper about if we can find the actions or not.
We will probably soon want to add some similar messages to
GtkMenuTrackerItem.
https://bugzilla.gnome.org/show_bug.cgi?id=733965
X11 backend doesn't, and for good reason - main code body does not check
that the window it sets opacity for is, in fact, toplevel.
Just silently fail to do anything for non-toplevel windows.
https://bugzilla.gnome.org/show_bug.cgi?id=733769
This leads to an assertion failure, because parent window is never registered
in the first place, widget's own GdkWindow is. But that window is unregistered
in a generic fashion by GtkWidget code, so there's nothing for us to do here.
https://bugzilla.gnome.org/show_bug.cgi?id=733766
Instead of slavishly following the naming spec, group the icons
into categories that are more likely to be useful for application
developers. Based on input from Allan Day and Jakup Steiner.
So far, gtk_window_set_focus just did not work when called on
a hidden window. Change it to record the desired focus widget
for hidden windows, and apply it when the window gets shown.
This is similar to how we tread other window properties that
can't be set before the window is realized, like maximized
or fullscreen.
This is related to
https://bugzilla.gnome.org/show_bug.cgi?id=734033
The previous code for computing the clip rectangle forgot to respect
the text-shadow CSS property. This is usually not very visible because
text shadows usually don't extend the ink rectangle by very much.
See attached testcase for an example.
Support environment variable GDK_WIN32_FONT_RESOLUTION that can be set to
a desired dpi (72, 96, 130, etc) to override system settings. Useful for
debugging, since changing system font scaling requires the user to log off
and log on again.
https://bugzilla.gnome.org/show_bug.cgi?id=734038
Although there is the "changed" signal, it is more correct to notify the
"text" property too. It can be useful for a small text view, where the
text is saved e.g. to gsettings with a binding to the text property.
The "text" property includes only the text, not child widgets or images,
so the notify signal is sent too many times (also for child widgets and
images), but it's not a big problem.
https://bugzilla.gnome.org/show_bug.cgi?id=624791
Currently, when loading an image from a GResource or file we don't take
the scale factor of the display into consideration, and let
GtkIconHelper scale it accordingly.
While this in general works for non-scalable images, we can take
advantage of the native loader's scaling for e.g. SVG images, and load
them at the right scale factor automatically.
This is achieved by switching to a pixbuf loader instead of using the
native function.
https://bugzilla.gnome.org/show_bug.cgi?id=733416
Use (cairo) input shape of the window to check whether a point is inside or not
inside the window.
If it is, let the default window procedure do its thing (which seems to be
working all right in all known cases).
If it isn't, override the default window procedure and tell WM what we think.
Don't do any of the above if the window has CSD-incompatible styles (WS_BORDER
or WS_THICKFRAME).
This is a crude kind of substitute for window input shape support (which W32
does not seem to have). Still probably enough to be positive about input shapes
support.
https://bugzilla.gnome.org/show_bug.cgi?id=733679
This allows subclasses to render things below and above the text
in the text view. This allows e.g. GtkSourceView to highlight the
cursor row and to render overlays for colum 80. This used to be done
by rendering before/after chaining up to the parent, but that doesn't
work anymore since the view now renders a background, and due to the
use of the pixel cache.
This reverts commit 1ac13435b7.
We want to instead replace this with special vfunc for drawing
below/above the main text so that gtksourceview can use it.
Delay the keyboard settings creation until we're delivering the key
press. This means we don't have to create the settings for a server that
sends us repeat information.
This function currently calls gdk_win32_window_shape_combine_region(),
which is wrong, because it leads to SetWindowRgn() being called with
non-NULL region, which makes W32 disable theming (particularly - decoration
theming), which makes decorations revert back to old GDI-drawn Windows 2000
variant, which looks out of place and interacts *badly* with alpha channel
(because GDI).
https://bugzilla.gnome.org/show_bug.cgi?id=733671
This was silently broken - the code was just assuming that the
text cell renderer is item no. 6 on the list of all cells. That
doesn't work so well if the cell renderers are set up elsewhere
and get rearranged.
Fix this by keeping an explicit pointer to the the text cell.
For images without a concrete size but with an aspect ratio, we took the
wrong code path.
(I even copied the documentation that said "Otherwise" but didn't put an
else clause there, go me!)
The widget path code copies elements only in gtk_widget_path_copy() -
which is essentially unused - and in
gtk_widget_path_append_with_siblings() - which is used by GtkBox.
So stuff the widget we are testing in a GtkBox to reroduce the problem.
Now that widget paths are allowed to have a state, use that state when
querying style properties. This uses a fast path in gtkcssprovider.c and
that is great.
Header-bar and action-bar buttons used to be bigger then others
now everything is as big as those, maintaining two different sizes
for default widgets depending on the placement is a maintainance
nightmare and having controls the same size is good from a usability
point of view.
The toplevel_window was never set, and the only place where it
was used was causing us to hide tooltips needlessly. So removing
it is a double win.
https://bugzilla.gnome.org/show_bug.cgi?id=733321
Add yet another tab for showing information about a widget that
does not quite fit into any of the other tabs (not a property,
not style information, etc...).
For now, we show the widget state, as well as the default and
focus widget for windows.
GtkArrow is deprecated and is not used internally anymore by the
menu button. Document also the fact that if no direction is specified
then the view-context-menu icon is shown.
https://bugzilla.gnome.org/show_bug.cgi?id=733441
People expect to be able to call gtk_widget_show_all on the dialog
to make action widgets visible, as seen e.g. in
https://bugzilla.gnome.org/show_bug.cgi?id=733431
To keep this working, we can't always set no-show-all on the
action_box. Only set it when the action_area is not used and empty.
With this, Ctrl-Q will close the window, and Ctrl-D will
toggle the dark theme. The accelerators are currently not
shown in the (manually constructed) menus.
The accel label in menus was getting a small allocation that
caused its draw code to always omit the accelerator string.
Fix that by setting halign to fill. To keep the menu label
left-aligned, set xalign to 0 to compensate.
Make gtk_widget_path_append_for_widget() add the state flags of the
widget, too.
This enables the ability to select pseudoclasses on all elements in a
selector.
Don't take a state when constructing the CSS matcher. Instead, rely on
the newly introduced state in the widget path.
This way, the state can be queried not only on the first element, but on
all elements of the widget path.
Set the widget path state flags with the state flags of the style
context.
We do not update the state flags but replace the previous one because we
want to be able to have save()/restore() unset state flags.
Make backdrop insensitive state more similar to the focused
windows one, mostly to make dark variant more usable and
focused -> backdrop transition less distracting.
Add left/right/top/bottom style classes according to which edge(s)
of the progressbar the progress is adjacent to. Only for a fraction
of 1.0 will we set more than one edge.
xdg-shell has moved on and replaced set_margin with set_window_geometry.
To properly support set_window_geometry requires a full rewrite of how
we've been dealing with toplevel windows for now, so just don't set any
margin until we can have a proper toplevel window abstraction in GTK+.
Don't shadow existing variables. Instead of sharing the allocation and
then overwriting the width/height when convenient, declare it in the
block we use it in, as, really, the three different paths are all
extremely different, and there's no sense in sharing the variable.
We can't avoid calling set_titlebar in buildable_add_child, since
GtkBuilder assumes that it can e.g. call grab_default at the end,
which only works if the widget is inside a toplevel at that point.
Instead, drop the titlebar and clean up priv->headerbar in constructed
if we find that we don't want a headerbar.
find_by_log_attrs() can return true only in this case:
return moved && !gtk_text_iter_is_end (arg_iter);
So if the iter moved (i.e. something has been found), but is the end
iter, find_by_log_attrs() returns false.
Now the same checks are made in find_visible_by_log_attrs(). The public
functions using find_visible_by_log_attrs() say in their documentation
that false is returned for the end iter, hence the check with
gtk_text_iter_is_end().
https://bugzilla.gnome.org/show_bug.cgi?id=618852
attrs[len] is the last PangoLogAttr available, at the iter position after the
last character of the line.
For a line in the middle or the start of the buffer, the '\n' is taken
into account by 'len'. For example the is_word_end is generally reached
before the '\n', not after. But for the last line in the buffer, where
there is no trailing '\n', it is important to test until attrs[len].
The bug didn't occur before because find_by_log_attrs() worked directly
on the iter passed as the function argument. But now it is no longer the
case.
https://bugzilla.gnome.org/show_bug.cgi?id=618852
- Return true (found) and false (not found) explicitly.
- Set found_offset only when something has been found.
find_backward_cursor_pos_func() was a bit different, the while loop had
the condition "offset > 0" but the return was "offset >= 0". Probably a
micro-optimization, since offset == 0 is always a cursor position.
Anyway now the code is the same as the other functions.
https://bugzilla.gnome.org/show_bug.cgi?id=618852
Do not work with the iter passed as the function argument. Work with
another iter, and set it back to the function argument only if something
has been found.
This fixes a few unit tests. But there are regressions for a few others.
https://bugzilla.gnome.org/show_bug.cgi?id=618852
The Adwaita icon theme ships spinners in a scalable directory
with MaxSize=32 and Scale=1. One way to make them scale up in
hi-dpi would be to add an @2 directory with MaxSize=32 and Scale=2,
but that directory would also be consulted in non hi-dpi situations
and give us an effective spinner max size of 64.
Instead, treat svg icons implicitly as hi-dpi, and scale them
up to MaxSize * 2 when in hi-dpi.
This was causing menus to show up in the wrong position in case the menu
popped up towards the top and/or left.
The change to the requisition was in error; it is the allocated size
of the menu, not the toplevel, and doesn't include the shadow.
https://bugzilla.gnome.org/show_bug.cgi?id=591258
This had originally been added to Adwaita in the gnome-themes-standard
commit 7bf01517bc2 but was lost during 3.13 theme changes, causing bug
591258 to reappear.
Like the autotools builds of the introspection files, don't include gtkx.h
in the introspection prepropcessing as it should not be included by other
GTK+ headers.
We now apply the .button style class to rows that are either
activatable or selectable. Selectable rows only get the .button
if the listbox allows selection. This implies that we need to
update row styles when the selection mode changes, or when the
row gets added to a listbox.
Having an explicit property for this will make it easier
to have a hover style only for rows which are activatable
or selectable.
Rows are selectable by default, to preserve compatibility.
It's hard to figure out what the "expected_reply" means except under
close examination -- it's actually talking about whether this was a
reply to a ConfigureRequest or not. The inversion in the check doesn't
help either.
Make the code cleaner by moving it above the freeze/thaw case, and
making the check more explicit and without a confusing variable. If we
haven't sent any ConfigureRequests out, then it must be a gratuitous
ConfigureNotify.
Some windows, like GtkWindow and some other apps, set a transparent
background. The guarantee for begin_paint_region is that there should
be a full clear to the specified background color, not a composite
against what was there before.
This fixes repaint artifacts in Wayland and Weston in a better way than
76922c169f.
Slapping file:// in front of a path does not guarantee a working
uri (e.g. if you are on windows and the path looks like F:\\...).
Therefore, go back to using g_file_new_for_path if we don't have
to deal with a resource.
It turns out that activate-on-single-click interferes with the
expected multi-selection behavior. Turn it off, since there's nothing
to activate in this list, anyway.
The animated scrolling interferes with incremental validation.
As short-term solution, disable scrolling animation during
incremental validation. This is not a proper solution, but
it avoids broken behavior like scrollbars that are not reacting
to clicks. The problem was visible, e.g. in the list view
example in gtk3-demo.
The animated scrolling interferes with incremental validation.
As short-term solution, disable scrolling animation during
incremental validation. This is not a proper solution, but
it avoids broken behavior like scrollbars that are not reacting
to clicks. The problem was visible, e.g. in the list view
example in gtk3-demo.
gdk_x11_display_set_window_scale() affects the interpretation of the
Xft/DPI XSETTING - it is substituted inside GDK with the value of
Gdk/UnscaledDPI xsetting. However, this change is not propagated to
GTK+ and from GTK+ back to gdk_screen_set_resolution() until the
main loop is run.
Fix this by handling the screen resolution directly in gdk/x11.
This requires duplication of code between GDK and GTK+ since we still
have to handle DPI in GTK+ in the case that GdkSettings:gtk-xft-dpi
is set by the application.
https://bugzilla.gnome.org/show_bug.cgi?id=733076
Conceptually, text handles are boxes, whose content is a 'handle',
so draw background, frame and handle. With this, and the previous
commit, the cursor-handle theming in Adwaita now works as intended.
The text handles reuse the style context from their parent widget,
and just add .cursor-handle. That means that the more specific
entry selectors override the .cursor-handle theming unless we
select for .entry.cursor-handle. We also need to work harder to
keep the .entry styling from drawing decorations around the outlines.
The listbox code relies on the container focus adjustment handling
to scroll the cursor row on screen. But GtkContainer has no idea
about row headers, so ensure that we scroll the header on screen too.
Use gtk_text_iter_set_line_offset (&tmp_iter, 0) instead of
gtk_text_iter_get_line(). The difference should not be big. In the first
case the line doesn't need to be traversed thanks to the offset 0. For
get_line(), the btree must be traversed.
A temporary iter is needed to not break the behavior. But the behavior
is quite strange, the function works directly on the iter passed as an
argument to the function, even if the function returns FALSE (not
found). So maybe a later commit will fix this strange behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=629129
find_by_log_attrs() was a recursive function. It is replaced by an
iteration.
The already_moved_initially parameter was TRUE only for the recursive
call, so the paramater is removed.
There is also a small cleanup of the find_visible_by_log_attrs()
(remove trailing spaces, fix indentation).
There is still a part to optimize for a later commit.
https://bugzilla.gnome.org/show_bug.cgi?id=629129
This is fallout from the recent dialog changes. We don't set the
headerbar as titlebar early enough anymore, so when the window title
gets set, it does not get passed on to the headerbar. So, re-set it
manually when the titlebar is put in place.
https://bugzilla.gnome.org/show_bug.cgi?id=733099
This will let us theme activatable rows differently.
We also avoid emitting the ::row-activated signal for
rows that are not activatable. For compatibility reasons,
rows are activatable by default.
https://bugzilla.gnome.org/show_bug.cgi?id=733112
Move the touchscreen switch to the other debug switches, and
move the hidpi spin to the other graphical controls. Since the
Visual tab is getting large, make it scroll. The General tab
is purely informational again.
Otherwise, the CSS background we draw would be clipped if the ink rect
was smaller than the allocation (a very common thing).
Broken since 37030a7710 where we clipped
to the ink rect.
The paned examples on page 2 were implicitly relying on labels
drawing unclipped. Instead of setting the view class only on the
labels, set it on the paned's instead.
The overlap was caused by using pack-end for the arrow, which
causes it to be allocated from the other end. Avoid the problem
by using pack-start for both the title and the arrow, and
reordering them according to xalign.
... so that it works with wide separators. Or rather: with separators
that don't request 1px size but any other number. Do that by making the
placeholder request the same size by indeed stuffing (hidden) separators
in it.
Some of the features we expose can be hardcoded via environment
variables. In that case, don't confuse the user by letting them
change settings that have no effect.
The displacement animation has been replaced by edge gradients, that
have a stronger color the harder overshooting is hit. This makes it
possible to remove the internal overshoot window, which was merely
used to have contents displaced when overshooting to top/left.
Overshooting to bottom/right used to cause queue_resize() to be
called on the scrolled window, this isn't necessary anymore either.
https://bugzilla.gnome.org/show_bug.cgi?id=731297
There was this hack, taken verbatim from GtkCList according to the comment,
that would recursively translate the allocation during scrolling, and set
it on children widgets through the direct gtk_widget_set_allocation() setter.
Since commit 4f89eb05cf, this has caused the wrong clipping areas to children
widgets of a textview. The reasons for this seem lost in time, and the approach
seems indeed wrong for windowed widgets as the repositioning of those windows
couldn't happen.
So replace all of this with just a gtk_widget_size_allocate() call, which does
work ok for the children widgets embedded in the "multiple views" gtk demo, and
ought to work for every other widget.
https://bugzilla.gnome.org/show_bug.cgi?id=732900
The reparenting happening on the column header so it gets a movable
window breaks the implicit grab, so this is one situation were we
want a pointer grab, if just to replace it.
https://bugzilla.gnome.org/show_bug.cgi?id=732933
Code was expecting view coordinates, not widget ones, as we're
only dealing with horizontal displacements, just adding the
horizontal adjustment value suffices.
https://bugzilla.gnome.org/show_bug.cgi?id=732933
This saves some code and lets us reuse the color swatch styling.
Among other things, this fixes a lack of discernible border when
the selected color is very similar to the background.
https://bugzilla.gnome.org/show_bug.cgi?id=680885
The recent reshuffling caused an ordering problem where we would
hide the action area before relocating the buttons to the header
bar. But hiding makes the default button loose its defaultness.
Rearrange things so that we move the buttons before hiding the
action area, and thus preserve the default.
If the drag gesture gets a GtkGesture::updated signal, the user
is directly interacting through pointer/touch with the range slider,
animating the adjustment value change in this situation can produce
perceived lag, so set the value immediately when this is happening.
Use the adjustment target value when repositioning the cursor, and remove the
checks that ensured the cursor was made onscreen immediately, as there will
be definitely a delay on animated adjustment changes.
When moving the cursor, compare current adjustment value with the post-animation
target value, in order to avoid false "keynav failed" positives as the animation
hasn't started yet, so dx/dy are still 0 at that time.
We move our menus.ui file into Gtk's namespace so that it will get
picked up. Accordingly, we no longer have to do any of the work for
ourselves...
https://bugzilla.gnome.org/show_bug.cgi?id=722092
Use the new ::resource-base-path property on #GApplication to attempt to
load the menu layout of the application.
We look first at gtk/menus-appmenu.ui or gtk/menus-traditional.ui
depending on the setting of gtk_application_prefers_app_menu(). Failing
that, we fall back to the common case of gtk/menus.ui (which should
always be given). This provides a convenient way for application
authors to provide a different set of menus, depending on the desktop
environment they find themselves in.
As is the intention with other resources, if the resource base path is
unset, nothing will be loaded. Additionally, if the expected files are not
found, it is not an error -- just nothing happens.
https://bugzilla.gnome.org/show_bug.cgi?id=722092
Move bloatpad to ./examples/bp/ so that we can start treating it as more of a
"normal" app instead of just jamming everything into a single .c file.
We don't use the name "bloatpad" for the directory in order not to
create 'git pull' pain with the probably-already-existing executable of
the same name.
https://bugzilla.gnome.org/show_bug.cgi?id=722092
For the transition to work the box-shadows types in the shadow list
needs to be matched in various states so I'm using transparent shadows
istead of resetting them when not needed.
Keep Ctrol-Shift-D as a straight toggle-the-inspector keybinding,
but make Ctrl-Shift-I always bring up the inspector, and point
it at the widget under the pointer.
When clicking 'Action' in the 'Act' dialog, we mark the third
page as needing attention a second later. This unveils that we
currently don't have any theming for needs-attention in Adwaita.
The way that GtkTextView et al pop up their context menu is to first
query to see if the clipboard has some text, and if so, enable the Paste
menu item. But since the Wayland backend hasn't had the greatest
selection and clipboard code, the callback for the clipboard got dropped
on the floor.
Add some simple code to respond to the TARGETS selection.
This makes right-clicking on a GtkTextView work fine.
Resize grips were introduced for GNOME 3.0, before we had any of the
"new GNOME app" features like invisible borders and CSD. With OS X 10.6
and 10.7, Apple has replaced the classic grips in their applications
with invisible borders as well.
New GNOME app designs don't use resize grips anymore and the new
default theme for GTK+, Adwaita, disables them entirely by forcing their
width and height to 0.
They're past their time. Remove the code to support them. This can
always be reverted if some app relies on them.
The resize grip code in GTK+ likes to call gdk_window_raise a lot. The
unfortunate side effect of gdk_window_raise is that it queues an
invalidation on the entire window, even if it's already the topmost
child.
Add a return value to gdk_window_raise_internal, and only queue the
invalidation if the raise had an effect.
Otherwise, a user that calls gdk_window_resize (window, 0, 0); over and
over won't properly fizzle out, and will queue a redraw. Clipped, but
still. These redraws can be chatty on some platforms like Wayland, and
there's no good reason to not avoid them.
This was the case for resize grips.
We decided in f8412eca34 that
we still need to react to these for a11y reasons, but left
the (then) harmless property deprecation in place. Now, the
deprecation causes runtime warnings for merely reading the
property, so drop it.
https://bugzilla.gnome.org/show_bug.cgi?id=732667
.scrollbars-junction borders were removed by setting border-stylei: none,
it interacted (why?) with the scrollbars on sidebar, making the border
transparent seems not to have side effects there.
When showing and hiding the inspector window repeatedly without
dismissing the dialog, we were hiding the inspector, but not
the dialog, leading to a confusing user experience.
https://bugzilla.gnome.org/show_bug.cgi?id=732443
Applications can call this to determine if they should an app menu.
This will be %FALSE on desktop environments that do not have an
application menu like the one in gnome-shell. It is %FALSE on Windows
and Mac OS.
Applications are completely free to totally ignore this API -- it is
only provided as a hint to help applications that may be interested in
supporting non-GNOME platforms with a more native 'look and feel'.
https://bugzilla.gnome.org/show_bug.cgi?id=722092
We were only setting the state transiently in ::draw, leading
to various drawing anomalies, such as labels not picking up
the appropriate color from BUTTON styles.
This is expected to happen on wayland and other platforms with no primary selection,
and just leads to the selected text being cleared after any attempt to change the
text selection itself through either mouse/keyboard.
This is expected to happen on wayland and other platforms with no primary selection,
and just leads to the selected text being cleared after any attempt to change the
text selection itself through either mouse/keyboard.
When there area explicitly added buttons in the action area,
we were trying to ensure that the action area is visible,
but failed, since we are now hiding the action_box. Fix it
by showing the action_box when things are left in the action
area.
We need to enclose paths containing $(BinDir) with double quotes as it
points to something like c:\foo\gtk+-x.yy.zz, which the copy command on
Windows does not like "+" in paths unless enclosed in quotes.
As the Visual Studio 2012/2013 are only slightly different from the Visual
Studio 2010 projects, we can provide support for them by using scripts to
copy the Visual Studio 2010 projects, and update the specific parts as
necessary.
Thus, there would be little maintenance overhead for these as only the 2010
projects need to be kept up-to-date as a result. This might change when we
do get the stack working with WinRT/Metro, but that's going to be another
totally different issue.
The stock icons are now built into the GTK+ DLL via resources, so don't
try to install the stock icons, and the icons don't reside in their former
positions anymore, causing messages indicating that the files cannot be
found.
This reverts commit 2e0ce67f8a.
Since g-i 1.40.0 we are using the .lib file(s) to determine the DLL(s) that
the introspection files should look for, instead of directly using the
DLL(s) directly, so it is no longer necessary to make copies of the GDK
.lib file to match the <namespace-name>-<namespace-version> convention when
we are building the introspection files for GdkWin32. Remove that from the
introspection build process as a result.
We don't set use-header-bar for message dialogs, since we
want the buttons in the action area, but we do want a nice
rounded csd titlebar. Add back the box that was used before
to achieve this, when appropriate.
Give GtkAboutDialog buttons in the action area instead of hard-coding
use-header-bar to TRUE. This is for environments which don't have the
Gtk/DialogsUseHeader xsetting turned on.
https://bugzilla.gnome.org/show_bug.cgi?id=730893
We use gtk_adjustment_enable_animation to enable animated
updates of the adjustments. Currently, this is enabled
unconditionally, and with a duration that is hardcoded.
https://bugzilla.gnome.org/show_bug.cgi?id=732376
Add a private API that lets widget opt-in to animated updates of
the adjustment value. When enabled, all calls to
gtk_adjustment_set_value will smoothly transition from the old
value to the new value, using a fixed easing function and a
configurable duration. The animation is tied to the frame clock
of the widget.
By implementing this in GtkAdjustment, we can enable animation
for both scrollbars and keybindings, which are often implemented
in the child widget of the scrolled window.
https://bugzilla.gnome.org/show_bug.cgi?id=732376
This makes it possible to look up icons in resources using
the icon theme api, and should be used as a replacement
for installing icons below $pkgdatadir/icons and adding
that location to the search path.
Make icon lookup from resources work without the extra hicolor
component in the path. It is redundant, since we always treat
builtin icons as part of hicolor anyway.
Otherwise, we get every icon twice. To switch between symbolic
and non-symbolic icons, this css fragment comes in handy:
* { -gtk-icon-style: symbolic; }
Grabbing on a non-toplevel might not do what we want it to do, since it
will go on the focused widget, not the grabbed widget. Since we don't
focus the widget before clicking on it, that means that putting the
focus somewhere else and then clicking on the accelerator editor will
freeze the app. Additionally, since it's a global system grab that can't
be exited except by a key press that we won't ever get, it effectively
locks up your system as well unless you know how to break the grab or
kill the app. Ouch.
Since doing a device grab on a non-toplevel is generally considered a
bad idea, just don't do it. Use a GtkInvisible and take a grab on that
instead.
When validating the style context, we are copying the animations
from one StyleValues instance to another, and cancel the old ones.
It turns out that sometimes the old and the new StyleValues are
the same, and in this case, we end up cancelling the animations
for good.
One case where breakage from this was observed is that the spinners
in gtk3-widget-factory stop spinning when you open and close a modal
dialog on page 2. This depends a bit on the window manager; the problem
can only be seen if opening the dialog causes a transition to backdrop.
This changes the calculation of activity mode progress in the
same way as was done in GtkProgressBar a while ago, and make it
smooth, using a tick callback.
We want to stop people from using configure events
entirely. GtkDrawingArea synthesizes a configure event, but we can just
make the only user of this functionality stop it, and correct the
documentation to not mention it.
GtkCheckButton sets a different initial value for this property without
actually changing the declared default, and then relies on change notification
to update other properties (such as xalign). This, combined with glades
insistance on putting default values into ui files creates a situation
where we can't remove the redundant notification for ::draw-indicator
without causing lots of checkboxes to suddenly have centered labels.
This was seen in gnome-terminal, evolution, and other applications.
Therefore, keep the extra notification for now. This can be revisited
when we clean up the button hierarchy.
Instead of code that internally does weird things, use the FLAT style
class if has-frame is FALSE and remove it otherwise.
Based on a patch by Benjamin Otte.
https://bugzilla.gnome.org/show_bug.cgi?id=732256
fixup entry
This commit makes button always draw background and frame.
Buttons with relief none get a new style class, FLAT, which
allows themes to style these buttons as they like.
We also (finally) mark GTK_RELIEF_HALF as deprecated. It
has never done anything different from GTK_RELIEF_NORMAL.
https://bugzilla.gnome.org/show_bug.cgi?id=732256
Translate shadow != None into the FRAME style class.
This doesn't change the style classes used for drawing,
it only sets the style class permanently instead of
saving and restoring in draw().
https://bugzilla.gnome.org/show_bug.cgi?id=732256
Translate shadow != None into the FRAME style class.
This doesn't change the style classes used for drawing,
it only sets the style class permanently instead of
saving and restoring in draw().
https://bugzilla.gnome.org/show_bug.cgi?id=732256
Since we have a paint clock, we shouldn't be sending out EXPOSE events
for OR windows inside the ALLOCATE cycle. The idea here was that we
would have to wait for a map to get an OR window to paint to, but since
then this has been abstracted away inside GDK and the paint clock.
We already update the grip position in _gtk_window_set_allocation, which
is done through the size_allocate above. Receiving a ConfigureNotify
also won't ever change a grip's visibility, so there's no point in
refreshing it.
We want to stop people from using configure events
entirely. GtkDrawingArea synthesizes a configure event, but we can just
make the only user of this functionality stop it, and correct the
documentation to not mention it.
The template documentation is lacking inlined examples on how to use the
templates API, like binding children and callbacks. This makes looking
for best practices a bit harder than it ought to be, for a feature this
useful.
These non-standard icons were dropped from Adwaita. Eventually,
the icon-browser code should be changed to show all standard
icons + whatever is actually in the icon theme, instead of
hardcoding a list of non-standard names.
If the event triggers GtkGesture::begin, and the handler ends up resetting
the gesture (say, due to taking a grab somewhere else within the handler),
still take the event as "managed", as it actually triggered recognition,
even if just to end abruptly.
https://bugzilla.gnome.org/show_bug.cgi?id=731711
Prevent a segfault in unknown circumstances, and break the ignore
deprecations wrapper out from the if statement so that we don't
cover too much ground by accident.
This reverts commit b875572f2a.
Apps like Abiword, gnumeric and gnome-chess, and toolkits like
ClutterGTK were all using this for various purposes, and this made them
break. Bring back this feature for now.
It still won't work under Wayland.
Apps had quite a bit of difficulty getting used to the new rules.
While we weren't expecting anything too deadly, it seemed that
gnumeric and Abiword both used gdk_cairo_create like this.
If a window both has an impl and its impl_window is of type offscreen,
that must mean that it is the offscreen window, and the impl window is
itself. We can reduce the indirection here and make it more clear.
This functionality is only exercised by gnome-shell, currently.
Therefore, forgetting to copy a field here means an instant
gnome-shell crash :-(. More tests needed.
Recent changes made it a breaking mistake to install symbolic icons
of the wrong size into a theme directory, or into the legacy unthemed
icon location.
Since this change affects many apps, do the extra work to keep these
icons working, but emit warnings, in the hope that this will lead to
cleaning up the mess over time.
The -gtk-icontheme() function not have any automatism for
symbolic or rtl variants built-in, instead, we expect the theme
to use selectors to provide the right icon for each situation.
The recent icon theme scaling changes make the code more
sensitive to mis-sized icons (e.g. application icons in
the app chooser). A single row whose size gets blown out
of proportion by a big icon is never wanted in a list.
We can avoid this situation by telling GtkIconHelper to
force-scale the pixbuf to the requested size.
When force_scale_pixbuf is set, the icon helper will scale the
icon to the requested size (either the pixel size, or the resolved
icon size), so we can just as well instruct the icon theme code
to do the scaling for us.
Reuse the scale information that we have from loading icons
normally, when loading a symbolic icon, so that we apply the
same size constraints.
This commit assumes that svgs have the nominal size of the
directory they are in, which will be true for all current
symbolic icons.
Previously, we were taking thresholds and min/max sizes into
account when choosing the best theme dir, but when it came
to loading the icon, we always scaled icons from scalable
directories all the way, ignoring the min/max size limits.
This commit changes things around so that we now load icons
in Threshold directories at their nominal size, and scale
icons in Scalable directories only up to the specified limits.
To override this and keep the previous behaviour of scaling
all the way to the desired size, use the GTK_ICON_THEME_FORCE_SIZE
flag.
Since the Win32 code never actually called InvalidateRgn or used the
Win32 update area at all, that meant the only thing that could possibly
invalidate the window was the Win32 window manager as part of scrolling
or resizing, which would also send it a WM_PAINT message.
But the WM_PAINT handling called BeginPaint / EndPaint, which clears the
update area completely! We also draw out-of-band, not directly when
handling WM_PAINT, so there's no way that the update area inside the
Win32 WM would match our local one.
There is no possible way that this queue_antiexpose implementation could
do anything. Remove it.
We removed the parameter from callers and from the implementation, but
not from the signature up top. I didn't notice because the branch I was
working on removed the signature entirely.
This code is only called with the current paint region as its argument.
Instead of having to copy it and do a no-op intersect against itself,
just use the current paint directly.
There's nothing better we can do for this case, now that we always
redirect drawing to a temporary pixmap. Maybe since this is already
X11-specific code, we should just do everything with Xlib directly.
cairo_surface_create_for_rectangle takes a ref on the parent surface,
so we need to drop ours.
Rename get_window_surface to ref_window_surface to make the code more
clear and to stop this error from happening again.
Previously, each begin_paint_region added to a stack of current paints,
and when end_paint was called, the paint was popped off of the stack and
the surface was composited into the parent paint surface.
However, the code was broken in the case of a backend like Wayland which
didn't keep track of nested calls and simply wiped and returned the
native impl backing surface every time.
Since this feature is flat out unused by GTK+ and we don't want to
really support tricksy things like these for other clients, just remove
the feature. If somebody does call begin_paint_region more than once,
warn and return without doing anything.
Traditionally, the way painting was done in GTK+ was with the
"expose-event" handler, where you'd use GDK methods to do drawing on
your surface. In GTK+ 2.24, we added cairo support with gdk_cairo_create,
so you could paint your graphics with cairo.
Since then, we've added client-side windows, double buffering, the paint
clock, and various other enhancements, and the modern way to do drawing
is to connect to the "draw" signal on GtkWidget, which hands you a
cairo_t. To do double-buffering, the cairo_t we hand you is actually on
a secret surface, not the actual backing store of the window, and when
the draw handler completes we blit it into the main backing store
atomically.
The code to do this is with the APIs gdk_window_begin_paint_region,
which creates the temporary surface, and gdk_window_end_paint which
blits it back into the backing store. GTK+'s implementation of the
"draw" signal uses these APIs.
We've always sort-of supported people calling gdk_cairo_create
"outside" of a begin_paint / end_paint like old times, but then you're
not getting the benefit of double-buffering, and it's harder for GDK to
optimize.
Additionally, newer backends like Mir and Wayland can't actually support
this model, since they're based on double-buffering and swapping buffers
at various points in time. If we hand you a random cairo_t, we have no
idea when is a good time to swap.
Remove support for this.
This is technically a GDK API break: a warning is added in cases where
gdk_cairo_create is called outside of a paint cycle, and the returned
surface is a dummy that won't ever be composited back onto the main
surface. Testing with complex applications like Ardour didn't produce
any warnings.
gtk_widget_set_double_buffered is now deprecated, and we don't support
non-double-buffered widgets. This means that under normal circumstances,
paints are never outside of a begin_paint / end_paint sequence, which
natively-double-buffered backends like Wayland can't possibly support.
Weston releases buffers almost immediately after they're done, which
means that GTK+ doesn't use a temporary surface and instead paints
directly onto the SHM backing store that Weston will use.
Normally, after painting to the temporary surface, GTK+ *replaces*
the existing backing surface with CAIRO_OPERATOR_SOURCE. However,
if we immediately paint to the backing surface, it might have junk
from the last paint in it. So clear out the backing surface whenever
somebody calls begin_paint_region().
Maybe we should just always use the temporary surface like the X11
codepath, since that prevents us from having to do weird things like
this, but oh well.
Add /org/gtk/libgtk/icons as a resource path, and ensure
that we always parse an index.theme file for hicolor which
makes the builtin icons available as part of the hicolor theme.
We add a new API, gtk_icon_theme_add_resource_path, which
can be used to add resource path as a base location for
icon theme content, similar to gtk_icon_theme_append_search_path.
We're going to require a complete icon theme, and we have
a test that checks for all the icons we use, so there is
no need to include all these fallback icons.
Regions are done in a very non-css way. They don't fit the DOM in that
they don't integrate into the CSS tree and they have very weird matching
behavior in selectors.
So I'm deprecating them now. GtkNotebook and GtkTreeview will continue
to use them and as long as they do, we can't remove the code for it.
But once those are ported it might be safe to remove the code as it will
clean up lots of places in the code by quite a bit.
wl_surfaces can't switch roles, so destroying the xdg_surface but not
the wl_surface means that we could get an error when trying to re-map
the surface.
We could fix this by not destroying the xdg resource and only do it at
finalization time, but it's just as easy to just create a new wl_surface.
Since the xdg roles are a special case of the surface, some compositors
like Weston destroy them automatically when the wl_surface is destroyed.
Thus, we need to destroy these first.
The Wayland compositor is completely allowed to send us configure
events for the same size, and this validly happens if we're changing
states. Fizzle these out.
The rubberband rendering code was assuming that we just have
a 1-pixel border and the rest of the rubberband is uniform.
That is not a safe assumption to make with css-styled
rubberbands, so remove it.
The rubberband rendering code was assuming that we just have
a 1-pixel border and the rest of the rubberband is uniform.
That is not a safe assumption to make with css-styled
rubberbands, so remove it.
Paradoxically, we were loading svgs at the nominal size when
FORCE_SIZE is specified, while scaling them exactly when it
isn't.
../build/win32/vs10/gtk.vcxproj
When we switched the default for gtk-update-icon-cache to
not include image data, we should have thought about the
builtin icons. For them, we rely on image data being included.
This made the notify test fail in gnome-continuous, where we
build from git and always regenerate the builtin cache.
This pushes the initialization of is_svg to an earlier point
when the GtkIconInfo is created. This is needed because an icon
info doesn't necessarily always have a filename that we can later
extract the suffix from. For instance, builtin icons have NULL
filename.
https://bugzilla.gnome.org/show_bug.cgi?id=721895
Copy the icons in stock_icons accordingly, so that the built-in icons can
be found by GTK, as it seems that not all of them are built into
gtkbuiltincache.h.
We want to have the "-gtk-" prefix for our custom CSS properties. But
we also want to parse names starting with a "-" as style properties.
So make sure that "-gtk-" is treated like a normal property and we emit
errors when somebody uses it wrong.
This is to catch errors with people typing
-gtk-iconsource: none;
instead of the correct
-gtk-icon-source: none;
We want to make sure that the submenu action is changed back to FALSE
_after_ the menu item has been activated. This prevents the menu
teardown handler from deleting the menu item before it can be activated.
Unfortunately, GtkMenuShell emits "hide" before the item activation.
This is probably done to prevent the application from doing things like
showing dialogs when the menu is still holding the grab.
In the case where we are doing an activate, set a boolean flag on each
of the open menus (following the parent stack) indicating that we'll be
emitting another signal soon (selection done). If that flag is set, we
defer the setting of the submenu action until we receive the second
signal.
https://bugzilla.gnome.org/show_bug.cgi?id=729820
That test is not working anymore by design since commit 57c4f01e.
It was introduced pre-3.0.0 in commit 12d6b588 and the feature was never
utilized. So it seems safe to just remove the test.
When duplicating the icon_info, we forgot to set is_svg. This meant that
any application that used gtk_icon_info_load_icon_async wouldn't have
is_svg set properly.
This fixes blurry icons in the gnome-shell app picker.
TextView border windows are internal windows used to draw on the gutter
of the textview (e.g. line numbers). The test uses the gmodule hook to
programmatically draw on the border-windows at each side of the textview
and compares the result with 3x3 grid of labels.
add a reftest that checks GtkTextView text margin property comparing
with the normal margin added to the widget (they are the same when there
is nothing drawn in the gutter like line numbers etc).
Previously GtkMenuTracker tried to access "gtk_menu_tracker_item_get_is_visible",
but the correct getter is "_gtk_menu_tracker_item_is_visible". This commit
corrects this reference
https://bugzilla.gnome.org/show_bug.cgi?id=731430
Since large images are in the icon cache, and apps don't tend to use that
many icons anymore, simply don't include image data and instead make apps
load files from disk. Additionally, since they're stored in GdkPixbuf data,
that means that we have to first convert them either to a cairo_surface_t,
which requires converting pixel data to be premulitplied, or an OpenGL
texture, which requires a whole GPU upload anyway.
So, even with the icon cache, the goal of icons through zero-copy, mmap()'d
data from disk just isn't doable with the icon cache format we have. The
icon cache on my disk is nearing 100MB, since we include a bunch of
high-resolution application icons, that I doubt would be used by apps at all.
Removing this inefficient pixel data makes memory usage for all applications
go down, with no speed loss.
The icon cache also, however, has an index of what icons are in each folder,
which prevents a readdir() and allows GTK+ to know what icon is where without
having to do a bunch of stat(); calls. Keeping this data is good for GTK+,
so we should still keep the index.
It doesn't make sense to remove any code for mapping pixel data from the icon
cache. There's a plan in the works to have a symbolic icon cache that does
pixel math on 16x16 icons to prevent slow SVG rendering. 16x16 pixels are
fairly small, and such images are flat colors, which should compress easily,
so the icon cache would be worthwhile here. So let's keep the code around
in preparation for that case.
https://bugzilla.gnome.org/show_bug.cgi?id=721895
This changes makes svg icons go through the same scale calculation
code as png icons. As a consequence, an svg that is put into the
32x32 directory will actually be loaded at size 32, even if it
gets requested at a bigger size. This will let us avoid giant
spinners.
https://bugzilla.gnome.org/show_bug.cgi?id=731658
Having the same, usable, default appearance acroll platforms
trumps having a more-or-less working native theme. The default
will be Adwaita on all platforms. The native ms-windows theme
is of course still available.
Making gtk.gresource.xml generated was causing a problem for
srcdir!=builddir builds from git. Builds from tarballs are
not affected, because the tarball contains the generated file.
The former can be called individually on each sequence, and the latter will
always call the former on all currently active sequences, so only implementing
resetting on cancel() works for both cases. Also, chain up on subclasses
implementing cancel.
This fixes clicking on nautilus' file list after popping up a menu, as broken
grabs are one of those situations where sequences get cancelled individually,
the "current button" wasn't properly reset, and further clicks with button != 3
were ignored.
This used to be done before the gestures port, and was removed
accidentally, so keep the motion_notify_event handler just for
this, and fallback to having those events handled by gestures
too.
This way plain clicks can be handled in gtkmain through the usual delivery mechanism,
and get possibly handled too by widgets holding a GTK+ grab. If window dragging is to
be started, the sequence will be claimed (and a grab will happen afterwards), notifying
properly the grabbing widget that event delivery was interrupted.
This makes it possible to dismiss popovers by clicking on window headerbars, while
still making it possible to drag the window with the popover opened.
Weston numbers its touch sequences ids starting from 0, thus simply
setting the GtkEvents touch.sequence to the touch id value typically
causes gdk_event_get_event_sequence to return NULL. Unfortunately this
confuses other parts of GDK.
As both weston & mutter keep the sequence id between 0..max_dev_touches
-1 simply use + 1 to keep the id > 0. While this isn't entirely correct
(compositor could send -1 as the touch id), this keeps the touch id in
gtk tied to the touch id from weston which is useful for debugging. A
more thorough solution could be done when it turns out this is an issue
in practise
https://bugzilla.gnome.org/show_bug.cgi?id=731371
The non-zero default default-border was causing buttons to shrink as
the focus moves around them. Themes which want a default-border should
define it explicitly.
The code is actually prepared for that, the gesture was initially limited
to only handling GDK_BUTTON_PRIMARY because it only used to handle row
activation.
This gesture acts only on events from the bin window, and checks that
either the pressed row is draggable, or the conditions for rubberband
selection apply.
A multipress gesture takes care of autosizing on double click, and
a drag gesture is used for both column dragging/resizing (only one
can happen at a time).
When placing tooltips, the csd shadow will get 'pushed up' and
may end up underneath the pointer. We don't want this to cause
the tooltip to be hidden, because that leads to flickering, so
ignore the shadow when finding the widget under the pointer.
For csd override-redirect windows, we don't set up resize handles,
but we were not ignoring the margin in all places, causing some
size calculations to go wrong.
... from per style data to only existing once per style context. This is
technically an API break because it no longer allows getting different
style properties between save()/restore() pairs, but I don't think this
was ever intended to work that way, as the style property API was to be
used and is used via gtk_widget_get_style().
And it simplifies code a lot.
We used to accept the same syntax for text-shadow and icon-shadow as
we accept for box-shadow. However, box-shadow does accept a spread and
the inset keyword while the others should not.
The signal needs to be emitted after the text insertion as at-spi gets
the text to compute the inserted text due to the AtkText::insert-text
signal not containing it.
Also adjust position to reflect changes to the offsets.
https://bugzilla.gnome.org/show_bug.cgi?id=731429
This is old code from dating back many years. Nowadays, we can
just use css drawing and csd windows to achieve much the same
effect.
Themes will need some adjustment for this change.
https://bugzilla.gnome.org/show_bug.cgi?id=731187
This commit makes it possible to use client-side decorations for
override-redirect windows by calling _gtk_window_request_csd()
before realizing the window. Since the wm won't do interactive
resizing for us in this case anyway, don't bother creating
the border windows we use for this purpose on regular toplevels.
To make this accessible to themes, we set a "csd" style class
on client-side decorated windows. With this, .window-frame.csd.menu
can be used to define the shadow for csd menus, and .menu can be
used to define a border for menus under non-composited wms.
https://bugzilla.gnome.org/show_bug.cgi?id=731187
This tests just a few basic things for now. Mainly, that we don't
emit redundant notifications for enum, flags, int and boolean
properties. It also checks that we do emit the expected notifications
when the value actually changes. This is checked for string, double
and float properties as well.
There is a large number of exceptions in the test, and a lot more
checks that could be done. One class of exceptions is all the places
where we have -set booleans to go along with another property. We
should have a dedicated test for these pairs. Another class of
exceptions is where naked objects created by g_object_new () just
don't have the full functionality - e.g. a tree selection without
a tree view does not work very well. We set up the instance object
better for these situations.
A few properties here are special, and can't benefit from it:
those which are just shorthands, like ::margin and ::expand,
and those that have explicit -set properties, like::hexpand
and ::vexpand.
This one is a little tricky, since we override this property
in many places, and you cannot add flags when overriding. So,
all places where this is overridden will have to make sure to
notify explicitly.
When we expanded the GtkLicense enumeration in 3.12, we forgot
to update the limit check in gtk_about_dialog_set_license_type.
Caught by testing property notification for enum properties.
The reftest is testing "transparent" works as expected by drawing a
purple background once with purple and once with transparent and
expecting the same result. This works fine unless anti-aliasing happens
at rounded corners. The overdraw of the 2nd background changes the
antialiased pixels.
Fix this by explicitly setting the border radius to 0.
Also reindent the file to make it more readable.
The a11y headers are now listed with the main Makefile.am of GTK, and
GDK introduced deprecated headers, so we need to account for them for the
build of the introspection files.
Currently, due to the way that Visual Studio 2010+ projects are handled,
the "install" project does not re-build upon changes to the sources, as it
does not believe that its dependencies have changed, although the changed
sources are automatically recompiled. This means that if a part or more
of the solution does not build, or if the sources need some other fixes
or enhancements, the up-to-date build is not copied automatically, which
can be misleading.
Improve on the situation by forcing the "install" project to trigger its
rebuild, so that the updated binaries can be copied. This does trigger an
MSBuild warning, but having that warning is way better than not having an
up-to-date build, especially during testing and development.
Otherwise, it is pretty hard to keep track of what
classes are missing from the list. As a consequence,
several of the existing classes were missing. Add those
at the same time.
We were applying response based heuristics, even if the button
is explicitly put in the headerbar. That broke button placement
in some epiphany dialogs, such as the Cookies one. Therefore,
restrict the heuristics to action widgets that are added through
gtk_widget_add_action_widget() or <child type="action">, where it
is not possible to specify placement explicitly.
There are plans to add session-dependent defaults to GSettings
(based on the newly standardized XDG_CURRENT_DESKTOP); until
then, the WM uses a different schema for its button-layout
setting in classic mode. So for the time being, do the same
and pick the alternative schema when XDG_CURRENT_DESKTOP
indicates that we are in a classic session.
(It's not pretty, but hopefully won't be with us for too long ...)
https://bugzilla.gnome.org/show_bug.cgi?id=731273
Pick up the setting from the org.gnome.desktop.wm.preferences schema
if available. It is slightly more involved than other settings, as
the actual button names used in the schema differ from the ones we
use, so we need an additional translation step.
https://bugzilla.gnome.org/show_bug.cgi?id=731273
When combining action child type with <action-widgets> to assign
response ids, we were not properly updating buttons that ended up
getting added to the headerbar before they have a response id.
Fix this by reapplying the headerbar button setup after parsing
<action-widgets>, and make sure to also update the suggested-action
style class.
If called when already popped down, warnings would be issued due
to priv->grab_pointer being unexpectedly NULL, this would happen
in regular operation when selecting items in appears-as-list mode.
So both add a NULL check for priv->grab_pointer, and bail out early
if the popup window is already hidden.
GtkKineticScrolling implements the actual physics laws for friction
and springs. When created, position/velocity/boundaries/constants are
given, so at every gtk_kinetic_scrolling_tick() it returns the current
position, and whether the system is in rest.
https://bugzilla.gnome.org/show_bug.cgi?id=729608
A multipress gesture takes care of link handling, and char/word/all
selection mode on selectable labels. A drag gesture is used for both
text selection and DnD checks on selectable labels.
A multipress gesture takes care of clicks, and where those happened.
If the click is meant to move the slider while pressed, the drag gesture
takes over, dragging the slider while active.
Widgets becoming insensitive won't receive further events, but there
could be chances the controllers don't get properly notified and reset
in those situations.
The signal handler for the visibility of menu items changing had the
wrong signature, resulting in the GParamSpec from the notify signal
being treated as a boolean (which was always true). This resulted in
items being added over and over and never being removed.
Fix that...
Since commit 872fbfac the GtkWindowGroup was split out from the GtkWindow
sources, so include gtkwindowgroup.h to avoid C4013 warnings/errors
(implicit declaration of ...) on gtk_window_group_add_window().
We were setting the next-tab properly, but were trying to
read it off the wrong object. Now, going from a cell renderer
attribute mapping to the model, or from an action-name to the
action actually works.
The touch_event handler was missing those when emulating pointer events
for the widgets that get GDK_TOUCH_MASK set, but have no specialized
touch handlers.
This code is a product of early stages in the gestures branch, where
capturing would have an effect outside grab boundaries. But this isn't
really the case, so every gesture outside the grab scope must be reset
to avoid keeping stale data.
This tests both a sequence being claimed early to be then denied
(and handled deeper in propagation chain), and a sequence being
claimed late in the capture phase (and thus being cancelled deeper
in the propagation chain)
Before this change, a sequence being claimed deep in the event propagation
chain would make the sequence go denied on every ancestor, regardless of
previous state.
To make things more consistent, only deny the sequence if it was previously
claimed, so the behavior is the same for gesture groups within the widget
than for those outside the widget.
The gestures testsuite has been updated to reflect this new behavior.
It might happen that a gesture claims a sequence before any other gesture
in its group even handled a single event from that sequence. In that case,
ensure the state is set accordingly right when the sequence is handled in
those.
The "group" gesture testcase has been updated to observe this behavior.
The CSS editor was feeling a little sluggish, because it was
reparsing and reapplying the CSS on every keystroke. Add a small
delay, to make this feel smoother.
Like the GDK and GTK portions, use autotools scripts to generate the
complete projects for gtk-inspector as sources there seem to change from
time to time.
It might be so that this, like the a11y sources, will be referenced from
the main Makefile.am of GTK directly, but just do this so that the
projects can build properly.
This test check that resizing the window when expanding
the expander yields the same end result as having the
expander expanded to begin with. The test uses the inhibit
mechanism introduced in the previous commit.
This adds an inhibit api that code from the reftest module
can use to delay the taking of the snapshot. Also refactor
the code in gtk-reftest to use the inhibit mechanism for
its own delaying of the snapshot until after the first
expose.
Every button press/release event reaching the the multipress gesture in GtkWindow
and happening in the "title" region must be handled, regardless of the event widget.
Children there wanting the event(s) for themselves are (and were always) expected
to stop event propagation.
So the only place to check for the event widget's "window-dragging" style property
is the "content" region, which matches the pre-gestures behavior.
This fixes some issues with sequences being mistakenly claimed (and events not
propagated further) on situations it shouldn't.
The multipress gesture must react to either direct events on the
GtkWindow (special cased through _gtk_widget_check_handle_wm_event),
or bubbled events from child widgets. Ensure bubbled events go
through the gesture, those are fed manually to make sure events are
only handled once, in either one or other place. The implicit grab
will ensure that doesn't change mid-action.
Otherwise the event is possibly handled, but still propagated further anyway.
Ensure the event is consumed by claiming the current sequence on the
GtkGestureMultiPress::pressed handler.
::row-activated only used to be triggered by GDK_BUTTON_PRIMARY, so make
the multipress gesture handling this now to be only triggered by that same
button.
https://bugzilla.gnome.org/show_bug.cgi?id=731020
This gesture was only meant to react on GDK_BUTTON_PRIMARY (either
through real pointer events, or implicitly assumed from touch events),
as it used to behave before gestures. Otherwise the gtk_drag_begin*()
call assumes being triggered by button 1, and the drag misbehaves
because that button isn't really in the state mask.
https://bugzilla.gnome.org/show_bug.cgi?id=731016
When going from attribute mapping to model, it makes most sense
to go directly to the data tab, and when going from an action
name to the owner, we want to show the actions tab. Make it so.
This reftest makes use of the new feature to add signal handlers.
It adds a libreftest.so module containing all the code for the reftests.
When adding a test named reftest.ui, please keep code contained in a
source file names reftest.c and add that file to Makefile.am.
https://bugzilla.gnome.org/show_bug.cgi?id=730833
When connecting signal names, gtk-reftest now allows you to use a colon
in the signal handler name like so:
module:function_name
where module is a module loaded from the same directory (or the .libs
subdirectory for compatibility with uninstalled libtool) as the running
test and the function is resolved in that module. Of course, normal
function names work as before.
The extra condition here that caused the current child to
not redraw during reordering was introduced in f383e1f1
during the port to ::draw, but was not explained in the
commit message, and removing it has no obvious negative
effect.
https://bugzilla.gnome.org/show_bug.cgi?id=730767
Just calling get_type() does not ensure that the signals, properties
and everything else gets set up properly. Ensure it is, by calling
g_type_class_ref() before using the type. This fixes the testcase
added in the previous commit.
Those might trigger the destruction of some widget that would dispose the
event controller while the event is still being handled, so keep an extra
ref on the controller during event processing.
Without this information introspection-based consumers don't realize
they can include context information, but instead think that they
receive an extra gpointer argument (which they don't know how to
handle).
https://bugzilla.gnome.org/show_bug.cgi?id=730745
This will hopefully help resolve the circular dependency between
libgtk linking against inspector/libgtkinspector and inspector/
needing extract-strings from gtk/.
I didn't preserve the EXEEXT decorations in this operation -
automake gave me stern warnings about it, so I just dropped them
all. Somebody who cross-builds GTK+ will have to reconstruct this.
This prevents some of our generic object implementation tests
from working with gesture objects. Instead, add g_return_if_fail
checks in all the gesture constructors.
Mainly doing s/TARGET/BUBBLE/ on the fully ported widgets, but GtkTreeView
where the double click handler has moved to GTK_PHASE_TARGET so it runs
parallelly to the still existing event handlers.
Previously, there would be globally just a capture and a bubble phase,
with the event just going down the hierarchy once, and the up once.
GTK_PHASE_TARGET actually meaning "run within event handlers", so in
a hierarchy of 3 widgets, emission would be:
Capture(C)
Capture(B)
Capture(A)
Target(A) (if event handlers allow)
Bubble(A)
Target(B) (if event handlers allow)
Bubble(B)
Target(C) (if event handlers allow)
Bubble(C)
This commit changes this behavior and uses GTK_PHASE_TARGET in a less
misleading way, running only on the widget that was meant to receive
the event. And GTK_PHASE_BUBBLE has taken over the execution place of
GTK_PHASE_TARGET, so the emission remains:
Capture(C)
Capture(B)
Capture(A)
Target(A)
Bubble(A) (if event handlers allow)
Bubble(B) (...)
Bubble(C) (...)
As it was, GTK_PHASE_BUBBLE was useful for running event controllers
paralelly to event handlers, without modifying a single line in those.
For those mixed scenarios, Any of the other phases will have to be
used at discretion, or the event handlers eventually changed to chain
up and let the default event handlers in GtkWidget to be run.
The events to those are fed outside the regular event propagation scheme,
through _gtk_window_check_handle_wm_event(), so set the controller to
GTK_PHASE_NONE so events aren't processed first manually, and then
automatically.
Event controllers now auto-attach, and the GtkCapturePhase only determines
when are events dispatched, but all controllers are managed by the widget wrt
grabs.
All callers have been updated.
Go back to respecting GtkMisc::xpad/ypad. Not doing so breaks
the misc-alignment reftest. As long as we still derive from
GtkMisc, we may as well do this.
The icontheme lookup code has a special-case that prefers builtin icons
if the theme name is "hicolor". This is problematic for our reftests,
which run in a barebones environment with not settings.
Drop the ref on the action muxer in finalize, and also make sure
shutdown() tears down the muxer setup done in startup().
When GtkApplication adds itself to a muxer, it causes the muxer to take
a ref on the GtkApplication. This has to be undone in shutdown() to make
sure the GtkApplication doesn't end up holding a ref on itself.
https://bugzilla.gnome.org/show_bug.cgi?id=730383
And handle the fact that drawing bounds are now handled by this API and
the corresponding gtk_widget_get_clip().
Also add _gtk_widget_supports_clip() function to check if a widget has
been ported to the new world.
Now that labels and images no longer use x/yalign in their code,
we need to make gtk_misc_set_alignment set the h/valign for these
widgets, to keep it stumbling along until its final demise.
https://bugzilla.gnome.org/show_bug.cgi?id=730613
Those get in the middle more than help on these widgets, the widget
is already packed with clickable areas and having handles (and their
invisible clickable area around) hovering above don't help, plus the
purpose in most likely numeric values is a bit doubtful.
All touch events are either consumed by the up/down panels, or
the swipe gesture, all GtkEntry handling of touch events on the text
window is avoided, so handles to not appear anymore.
the "bubble" phase used to run before event handlers before GTK_PHASE_TARGET
was added, in order to keep phases in the expected order, move GTK_PHASE_BUBBLE
to be run (still invariably) after event handlers.
The only behavioral change should be wrt widgets wanting mixed event handler/
gesture handling, they could previously attach the gesture to the bubble phase
and check for gtk_gesture_is_active() in the event handler to bail out, they'll
have to use GTK_PHASE_CAPTURE for that purpose from now on.
The handle is still centered horizontally, but the extra vertical
space wasn't taken into account, leading to misplacing the dragging
point (and the handle) during motion events.
GtkPaned may just capture pointer events because the child widget
doesn't happen to have GDK_TOUCH_MASK set, resort to checking the
device in that case.
Dragging is all handled by a GtkGesturePan now, matching the
paned orientation.
On touch events, a wider area is listened for, so touch events
don't need to be as accurate to initiate dragging, if no dragging
is truly initiated in this case, events are just forwarded for
child widgets to handle.
A pan gesture is used to handle switch dragging, which is only triggered
by horizontal panning movements. A multipress gesture handles the cases
where clicking without dragging happens, just toggling the switch.
A pan gesture is optionally attached if there is only one scrolling direction, the pan
gesture orientation is changed so movements tangential to the scroll direction get
scrolling cancelled (The pan gesture is automatically denied when that happens, and
that state change spreads to the others gestures in the group). If the pan direction
happens in the expected directions, no cancellation happens, and scrolling eventually
takes place.
Multiple calls are supposedly allowed to change the phase (although
unlikely to happen), so remove the g_return_if_fail() checking whether
the controller was already added.
Presses alternatively show and dismiss the popover, the popover is still
always shown invariably after any dragging happens (either text selection,
or dragging a text handle)
Presses alternatively show and dismiss the popover, the popover is still
always shown invariably after any dragging happens (either text selection,
or dragging a text handle)
Similarly to GtkTextView, a GtkGestureMultiPress gesture handles
button/touch presses to initiate one selection mode or other, and
a GtkGestureDrag is used to handle text selection and DnD checks.
The code from button press/release, motion, and grab_notify handlers
has been shuffled into the actions triggered by those gestures.
A GtkGestureDrag is used for color selection, removing also the
need to track the pointer state in widget data. The GDK grab performed
just to set the crosshair cursor has been replaced by a call
to gdk_window_set_device_cursor(), which will be unset if the
drag operation is finished, or cancelled due to the implicit grab
being broken.
When the pointer cursor is updated on CSW, lookup for either a device
cursor, or a global one. It would previously lookup for windows with
a global cursor, and then check if it had a device cursor, which would
skip windows with only device cursors set, and unexpectedly set the
global cursor.
All "exclusive" gestures listen for either pointer events, or
"pointer emulating" touch events, so only a single sequence at
a time can make these run.
This signal will always be paired with a ::pressed signal, unless
the sequence is cancelled, or the controller is reset. the n_press
argument in the signal always matches the ::press signal one, even
if GtkGestureMultiPress::stopped was emitted in between.
The current sequence (as per gtk_gesture_single_get_current_sequence)
is used to find out the coordinates. And only emit ::pressed if the
gesture began through a GDK_BUTTON_PRESS/TOUCH_BEGIN (eg. not due to
an extra touch being lifted)
Just call the controllers on that phase if the default widget handlers
are run.
For compatibility reasons, in the touch event handler, let the pointer
emulating touch be transformed to a pointer event as usual, in order to
have widget handlers a chance to run at all. If they have to be managed
by a controller in that phase, it'll have to be through the default pointer
event handlers.
This phase is meant to run in the default widget handlers, as opposed
to externally as in the bubble/capture phase. This will be most usually
the expected phase for every controller replacing code in event handlers
in GTK+, just so invocation and triggering order is kept unaltered.
That may happen separately from grab-notify, and also due to external
reasons, so ensure all sequences are cancelled if a grab is taken
in some GdkWindows that would obscure events on the controller.
We can end up with _gtk_widget_remove_controller getting called
while we are iterating over the list in _gtk_widget_run_controllers.
To avoid trouble, only mark the event controller as dead by
setting data->controller to NULL, and defer the actual freeing
and list manipulation to the loop in _gtk_widget_run_controllers.
Update other places that operate on controllers to handle
data->controller being NULL.
Make it really sure that the event is only emitted after every gesture
that consumed the button press is done with the sequence.
The event must only be emulated if a gesture in the capture phase happened
to consume the event, be cancelled, and
Sequences may be cancelled within the ::sequence-state-changed handler, which
would change the points hashtable as it's being iterated in this function. So
iterate over a list of sequences and let the hashtable change freely.
The propagation phase property/methods in GtkEventController are gone,
This is now set directly on the GtkWidget add/remove controller API,
which has been made private.
The only public bit now are the new functions gtk_gesture_attach() and
gtk_gesture_detach() that will use the private API underneath.
All callers have been updated.
Within a widget, if a gesture accepts a sequence, it would previously
cancel every other gesture that not in the same group. Change this to
only cancelling gestures that previously claimed the gesture, and let
gestures with state=NONE for that sequence remain like that.
This enables late recognition of gestures, even on the presence of
another gesture group that was more eager at claiming the gesture.
One usecase is user-defined panning gestures on scrolledwindows,
if ::capture-button-press is TRUE (eg. the default), the gesture is
claimed early in order to consume the button press, but that would
tipically make every other gesture group deny the sequence. With
this change, the pan gesture can keep state=NONE, and later claim
the sequence for itself if the panning gesture is recognized.
Also, do not propagate state=DENIED to every gesture in the widget,
that was unintended.
If no match is found with the gesture widget when poking the event
window parents, bail out safely instead of falling in an infinite
loop. This was seen on Mutter.
The utility of those signals is somewhat dubious now that there is
gtk_gesture_group(), so make that the only way to coordinate gestures.
The cooperation model offered by gtk_gesture_group() is flexible
enough,
Listen for notify::sequence-state-changed on the controller, so the
only way to manipulate a sequence state are gtk_gesture_set_sequence_state()
and gtk_gesture_set_state().
Also, make use of gesture groups, so the sequence state is set at once
on all gestures pertaining to a single group. Within a widget, if a sequence
is claimed on one group, it is made to be denied on every other group.
This API eliminates the need for overriding
GtkWidget::sequence-state-changed virtually everywhere. Grouped
gestures share common states for a same GdkEventSequence, so the
state of sequences stay in sync across those.
A multipress gesture is used to control all this, replacing
single/double click custom code, and triggering window dragging
when the multipress is stopped, yet active (ie. the sequence remains
pressed).
This gesture is used by gtk_drag_source_set() to determine
whether dragging moved past the threshold. The gesture events
are handled via the usual ::event callbacks, so we don't mess
up with callers expecting that to happen in a signal handler.
If the sequence gets claimed somewhere else in the event widget
stack, the DnD gesture will be cancelled.
With gtk_gesture_get_point() returning events in
gtk_event_controller_get_widget() coordinates, we no longer need
to compensate for the overshoot here.
GtkEventController may be certainly useful to keep event
handling self-contained in other places than gestures, but
the current widget API is highly related to gestures, so
just using GtkGesture as the argument there will be quite
more convenient. The other places where GtkEventController
make sense as a base object will better provide their own
hooks.
Gestures attached with this phase will expect callers to have it
receive events through gtk_event_controller_handle_event(), but
the gesture will still be notified of sequence state changes,
grabs, etc...
Translate events meant for other widgets/windows, so gtk_gesture_get_point()
always returns coordinates based on the gtk_event_controller_get_widget()
allocation.
If a gesture has denied sequences (so those are presumably handled above/below
the widget), it shouldn't attempt to handle extra touches, even if those end
up matching the expected number of touches.
Gestures should always receive one of such events in order to be activated,
and the propagation mechanism will ensure they do so if the original event
was caught up the widget hierarchy by another gesture that is now declining
the sequence.
If the captured touch begin or button press event have been consumed
for the given sequence, propagate it upwards if the sequence goes from
claimed to denied, so the widgets on the way to the event widget receive
a coherent event stream now that they're going to receive events.
The policy of sequence states has been made tighter on GtkGesture,
so gestures can never return to a "none" state, nor get out of a
"denied" state, a "claimed" sequence can go "denied" though.
The helper API at the widget level will first emit
GtkWidget::sequence-state-changed on the called widget, and then
notify through the same signal to every other widget in the captured
event chain. So the effect of that signal is twofold, on one hand
it lets the original widget set the state on its attached controllers,
and on the other hand it lets the other widgets freely adapt to the
sequence state changing elsewhere in the event widget chain.
By default, that signal updates every controller on the first usecase,
and propagates the default gesture policy to every other widget in the
chain on the second. This means that, by default:
1) Sequences start out on the "none" state, and get propagated through
all the event widget chain.
2) If a widget in the chain denies the sequence, all other widgets are
unaffected.
3) If a widget in the chain claims the sequence, then:
3.1) Every widget below the claiming widget (ie. towards the event widget)
will get the sequence cancelled.
3.2) Every widget above the claiming widget that had the sequence as "none"
will remain as such, if it was claimed it will go denied, but that should
rarely happen.
This behavior can be tweaked through the GtkWidget::sequence-state-changed and
GtkGesture::event-handled vmethods, although this should be very rarely done.
The kinetic scrolling feature is now implemented using a
GtkGestureDrag and a GtkGestureSwipe, plus a GtkGestureLongPress
in order to denying the sequence, so it is possibly handled
underneath.
A controller can be optionally hooked on the capture or the bubble
phase, so the controller will automatically receive and handle events
as they arrive without further interaction.
Now, all captured events run from the toplevel to the deepmost widget,
regardless of GTK+ grabs. This makes captured events more useful to
event controllers if used together in the hierarchy with widgets doing
old fashioned event handling and GTK+ grabs.
This gesture handles any number of clicks, ensuring multiple presses
stay within thresholds and timeouts. When anything of that happens,
the gesture is reset and press count starts from 1 again.
Optionally, the gesture can be given a rectangle, used in in presses > 1
to ensure the consecutive presses happen on user imposed areas.
This gesture implementation recognices swipes on any direction.
The "swipe" signal has the X/Y velocity vector components, so
those can be used for direction guessing and velocity thresholds.
This test just checks that all the icon names that GTK uses are present
in the default icon theme.
As icon names are not checked programmatically and we do not want to run
into missing-icon icons in the code, this test seems necessary.
For now, it's just a stub that tests stock icons.
The change to take out unneeded NULL checks requires some care
at startup: we check both adjustments when any of them changes;
we need to do those checks in the same order in which we create
the scrollbars, otherwise we'll try to get the adjustment of
the vscrollbar when we just set the up the hscrollbars' adjustment.
When the color editor is visible, there is no way for the
application to know about the changes that are happening.
Fix this by emitting property notification for the "rgba"
property.
http://bugzilla.gnome.org/show_bug.cgi?id=708037
This avoids a bunch of policy problems with deciding how to lay
out the window menu under different WMs.
For now, we use the special event _GTK_SHOW_WINDOW_MENU, but we
hope to have this standardized in wm-spec quite soon, as KDE wants
it as well.
To make the icontheme test run successfully when installed,
we need to use the correct test-framework-provided location,
and we need to install the test theme without stripping its
subdirectory structure.
We see an active link when creating the menu, but by the time
the menuitem is activated, we've received a leave notify that
makes the label clear its active link. Instead, give the
menuitems a direct reference to the link that is active when
the menu is created.
Problem pointed out by Tim Baedert
We know the objects in a size group are always widgets, so we
can avoid hard-to-track down problems with weak references by
just cleaning up when the object gets destroyed. There is still
a chance that we show a widget as part of the group after it
has been removed, but size groups simply have no signals that
would let us avoid that.
Add a tab that shows size groups of a widget. The properties
of the size group are available here, as well as the widgets
that are part of the size group. We highlight the widgets in
the application when their row in the inspector is hovered.
In contrast to the flashing, where we blink the widget a
few times, this is explicitly turned on and off.
It will be used for indicating widgets that are part of
a size group, in the next commit.
The focus widget might be unset, just to be set again on a widget inside
the popover. Have the popover wait till the focus is actually moved outside
before dismissing.
Move away from cell editing, and use a popover instead. This makes
it easier to e.g. use a color chooser - there's just not enough room
in a cell for many things.
Much of this code is adapted from tests/prop-editor.c.
The child properties in GtkAssistant are somewhat broken, since
they are not on direct children - but that is no reason to crash
if somebody does ask for child properties of direct children.
When a model is sortable, but the the column is not currently used
for sorting, we want to reserve the space for showing the sort
indicator. But we currently set the icon to 'missing-image', which
is not great to show all over the place. So, just set the opacity
to 0.
With the keybinding, it is possible that users may trigger the
inspector unintentionally. Show a dialog that informs them about
whats going on and gives them a chance to back out.
The warning dialog can be bypassed with the
org.gtk.Settings.Debug inspector-warning setting.
All the globals we care about should appear before doing anything
else, up-front, so a single round-trip after adding the registry
should be more than enough.
Update visual.c to use Windows themes rather than the stock Raleigh theme,
and avoid hardcoding data paths for Windows (and Mac). As the dlfcn.h
functions are only used when Python is enabled, move its inclusion there[*].
Also ensure that variables are declared on the top of the block.
[*] Python support Windows needs to be investigated, as POSIX signal
handling is used there.
https://bugzilla.gnome.org/show_bug.cgi?id=730236
Add project files to build the GtkInspector sources, as gtk-inspector is a
required portion for GTK+. "Install" the
org.gtk.Settings.Debug.gschema.xml gsettings schema file as well, so that
people can trigger GtkInspector as they develop and test their GTK+-based
programs.
Since you can't take grabs on unmapped windows, GtkMenu takes a grab on
the menu in a convoluted way: it first grabs another window, shows the
menu window, and then transfers the grab over to the GtkMenu widget.
For normal menubars, this is perfectly fine, as the first window it grabs
is our toplevel, and that gets picked up in our transient path. For
GtkMenuButton or other spurious uses of gtk_menu_popup, it creates a new
temporary input-only window which it takes the grab on, known as the "grab
transfer window". Since this window isn't a transient-for of our new menu
widget window, the grab isn't noticed when we go to show it, and thus the
menu ends up as a new toplevel.
Add a special hack to GtkMenu and the Wayland backend which lets us notice
this "grab transfer window", and include it in our grab finding path.
It's sort of terrible to have to hack up the widgets instead of just the
backend, but the alternative would be an entirely new window type which is
managed correctly by GDK. I don't want to write that.
The entire UI is constructed with templates, so the wrapper
constructors are never called, except for gtk_inspector_window_new,
which gets called from the GTK+ code.
Show the actions that are added to GtkApplication and
GtkApplicationWindows, as well as action groups that are
inserted elsewhere with gtk_widget_insert_action_group.
https://bugzilla.gnome.org/show_bug.cgi?id=730095
Moving the inspector into libgtk lets use reuse internals without
having to add public API for everything or inventing awkward private
call conventions.
https://bugzilla.gnome.org/show_bug.cgi?id=730095
Add two new icon lookup flags, GTK_ICON_LOOKUP_DIR_LTR and _RTL,
which tell GtkIconTheme to look for icon variants which have a
-ltr or -rtl suffix. GtkIconHelper adds these lookup flags when
looking up icons.
Note that due to the way this overlaps with symbolic icon lookup,
directional variants of symbolic icons must be called -symbolic-rtl, not
-rtl-symbolic.
https://bugzilla.gnome.org/show_bug.cgi?id=729980
Provide API to query the matrix instead of API that applies the matrix
directly. This makes the API more flexible.
See the commits implementing shadows.
This test is a bit brittle because it doesn't properly rely on CSS
properties but needs to use widget style properties to turn of extra
sizing from widgets.
It might break in the future when porting widgets to draw properly.
When forcing regular or symbolic icons, fall back to the default
specified icons. This ensures that when no symbolic icon is present, an
icon will still appear - the regular one.
GTK_ICON_LOOKUP_FORCE_REGULAR and GTK_ICON_LOOKUP_FORCE_SYMBOLIC can be
used to force a regular or symbolic icon to be loaded, even if the icon
names specify a different version.
This is intended to support the CSS property -gtk-icon-style.
The values can be:
"requested" - the style as requested
"regular" - use a regular full-color icon
"symbolic" - use a symbolic icon
The property defaults to "requested", so no changes should be seen
unless CSS overrides it.
It is also inherited, so that using this CSS
.toolbar { -gtk-icon-style: symbolic; }
is enough to force the whole toolbar to use symbolic icons.
The value implements the 2D parts of CSS transforms. See
http://www.w3.org/TR/css3-transforms/
For the specification.
All it does is give us an expressive way to define Cairo matrices (and
their transforms)
This allows using icons from the icontheme as images in CSS. The
reasoning is that this allows to give the image control about how it's
scaled (by using the icon theme's scaling method. So we can get crisp
images at different resolutions.
Replace them by GtkWidget h/valign. The only remaining uses
are those where a size group is involved; they can't be replaced
until GtkLabel stops looking at GtkMisc alignment for size
allocation.
Wayland's mechanism tells us all of our new states, rather than
telling us which ones were added and removed. Add a new private
interface so that we can simply specify the new states as a
bitfield directly rather than having to compute which ones were
added and removed.
Make the relative_to widget the parent for a GtkPopover's
GtkActionGroup. This, for example, makes the menu model of a
GtkMenuButton find action groups attached to the button.
https://bugzilla.gnome.org/show_bug.cgi?id=729915
Returns NULL in case of a duplicated tag name in the tag table. It is
still a programmer error to duplicate a name, but if it happens the
behavior is a little nicer (and hopefully doesn't crash).
https://bugzilla.gnome.org/show_bug.cgi?id=614717
The user doesn't need to check the return value, because if FALSE is
returned it is a programmer error. But it permits a nicer behavior for
gtk_text_buffer_create_tag() in case of failure.
https://bugzilla.gnome.org/show_bug.cgi?id=614717
Instead of manually doing it everywhere, just call set_object (NULL)
from the selection_changed handler. Fix all the set_object() functions
to deal with NULL.
Nice to have a quick way of testing this everywhere.
The implementation is not quite perfect: due to the way text
direction works in GTK+, widgets that appear in the inspector
window while we are flipped will inherit the flipped direction
instead of the fixed direction of the inspector window.
The widget-tree was not safe against object just going away.
Fix this by using row references instead of iters where
necessary, and by using weak refs to clean up when objects
die.
It does not really add much over the sensitive/insensitive rendering
that is already indicating which widget is mapped. At the same time,
set up signal handlers so we can update that when the widget changes.
Not only was the property list connecting to notify::bla for
each property individually, it was also leaking the signal
handlers when the selected object changed. Fix both.
When showing the objects in the tree, use the property name
as the name thats shown in the list. This makes it easier
to differentiate e.g. hadjustment and vadjustment in a
GtkScrolledWindow.
Add a tab that shows available signals for each object. For now,
we only show if each signal has handlers connected or now. More
functionality will be added later.
The list of toplevels also includes hidden combobox popups
and the like, so we have to be a little careful. To ensure
the right choice, we now pick the first visible window
that is not a GtkInspectorWindow.
Instead, we want to let GTK+ open a window whose life-cycle
it can control. We just ensure that all our types are registered
when the module is loaded, so GTK+ can find them.
The positioning of the highlight window was not reliable; instead
just use a after-handler for the draw signal, in the same way that
drag highlights are drawn by GTK+ itself.
And copy the code for grabbing a widget via pointer from testgtk;
that code is known to work.
Quoting the spec:
If the cascaded value of a property is the unset keyword,
then if it is an inherited property, this is treated as
inherit, and if it is not, this is treated as initial.
Spec in question:
http://dev.w3.org/csswg/css-cascade/
Also use unset in the reset-to-defaults.css we use to reset css in
reftests.
In the GTK_IMAGE_ICON_NAME case, instead of keeping around the icon_name,
create a GThemedIcon and use that. This way, we can reuse the code paths
for the GTK_IMAGE_GICON case.
We have to use the internal accessor to the visible flag, instead of
calling gtk_widget_set_visible(), from within the show() and hide()
implementations - otherwise we'll recurse.
https://bugzilla.gnome.org/show_bug.cgi?id=721069
We now use a narrower trough and paint the optional text
beside the trough instead of inside it. This makes for a much
cleaner appearance and more readable text.
The documentation for GtkFileChooser references the button which allows
the user to create new folders as the New Folder button, although the
label actually says Create Folder.
Update the documentation to say Create Folder instead of New Folder.
https://bugzilla.gnome.org/show_bug.cgi?id=729475
This small refactor makes the code more readable when adding more
transition types that have left, right, up, and down variations.
It adds inline boolean functions to tell information about transition
types (avoiding long if clauses) and changes long chains of "else if
(transition_type == ...)" into switch statements. Both are only likely
to get longer as more transition types are added.
https://bugzilla.gnome.org/show_bug.cgi?id=726676
Added GTK_BUILDER_ERROR_INVALID_PROPERTY and GTK_BUILDER_ERROR_INVALID_SIGNAL
error codes
ObjectInfo: Use a GType instead of a char * for the class name.
PropertyInfo: Use a GParamSpec instead of a char * for the property name.
SignalInfo: Use signal id and detail quark instead of a detailed signal name string.
This not only save us a few malloc in each case but lets us simplify the code
and report unknown properties and signals as a parsing error instead of just
printing a warning.
Fixed memory leaks in parse_object(), parse_template() and parse_signal() functions.
Parameters value where strduped before the last posible return and not freed.
...unless they are labeled.
To implement this, keep track of the nesting depth of section boxes,
starting from 0 for the toplevel and the submenu ones, and only
insert unlabeled separators if the depth is at most 1.
When the adjustment changes (due to e.g. a mouse wheel scroll) we update
the prelight. The part that un-prelights the previous prelight was
broken by the the pixel cache, as it called update_prelight in the
middle of the scrolling operation, where the windows were moved
but the tree_view->priv->dy was not changed to the new value. This
caused the updates to the pixel cache to go to the wrong place.
We fix this by fully doing the scroll before we update_prelight().
https://bugzilla.gnome.org/show_bug.cgi?id=728284
GtkMenuTrackerItem::visible was removed a few commits ago.
It is not necessary to bind visible anyway, since the menu
tracker will insert and remove items as their visibility
changes.
Rendering doesn't do much about clipping drawing operations to the window shape,
although invalidation applies the shape to every window, leaving possibly trails
of "overrendered" content. So ensure the shape portions get invalidated too when
the window is moved/resized.
https://bugzilla.gnome.org/show_bug.cgi?id=729095
Now that popovers may snap to any side with enough space, make enough
room on every side when requesting size, so that there's no w/h differences
at the time of setting the child allocation.
https://bugzilla.gnome.org/show_bug.cgi?id=729097
When activating an item using mnemonics GtkRecentChooserMenu does not select a
item before calling the item-activated signal thus
gtk_recent_chooser_get_current_uri() always return the last selected item
instead of the activated one.
Fixes Bug 495105 "Open recent file keyboard shortcuts do not work correctly"
The real reason for the problem that the just reverted change
was supposed to address is that testfilechooser uses show_all
to tease out places where composite dialogs don't properly
protect their internals against unintended showing. Well,
lets do that, then.
In iconic mode, model buttons will be styled like regular icon
buttons, preferring to show only the icon if one is set, falling
back to showing the label.
https://bugzilla.gnome.org/show_bug.cgi?id=727477
When rendering iconic sections, we want to use icons for verbs,
and we want to differentiate these in the menu model, to keep
the icon attribute reserved for nouns.
https://bugzilla.gnome.org/show_bug.cgi?id=727477
Instead of using GtkMenuTracker to flatten the sections into a single
linear menu, handle the sections ourselves by nesting boxes.
Each section gets an inner and outer box. The inner box numbers its
children in the way that the tracker instructs. The outer box
containes the inner box and the separator, if appropriate.
Having the two separate boxes will allow us to change the orientation of
the inner box if we want to pack widgets horizontally within a section.
Add the possibility of a GtkMenuTracker that performs no section
merging. Instead, it will report an item in the form of a separator for
subsections. It is then possible to get a separate tracker for the
subsection contents by using gtk_menu_tracker_new_for_item_link().
We have some API in GtkMenuTracker and GtkMenuTrackerItem that is
specifically designed to deal with submenus.
Generalise these APIs to take a 'link_name' parameter that we always
give as G_MENU_SUBMENU for now. In the future, this will allow creating
trackers for other types of links, such as sections.
Make this a property just like all of the other things and make the APIs
for accessing it non-private (but add a note that they are not intended
to be used).
This is not a great name to use in themes; instead, add the
menuitem class, so themes can use .button.menuitem for styles
that are specific to menuitem-like buttons.
We were not really handling all cases correctly here. We want
the suggested-action style class to only be set on headerbar
buttons, and it should be set on the default widget. Ensure
this by syncing the suggested-action style class with the
default style class. As a side-effect, setting has-default
on an action widget in ui files will now have the expected
effect.
https://bugzilla.gnome.org/show_bug.cgi?id=728846
GtkDialog has convenience API for adding action widgets that are
either placed in the action area or the headerbar. This commit
makes the same functionality available from GtkBuilder ui files
by specifying "action" as the child type.
https://bugzilla.gnome.org/show_bug.cgi?id=728846
When constructing from a menu model, use popovers by default.
This change has the potential to cause some size problems for
applications with big gear menus, so we're doing it early in
the cycle to uncover and fix those.
It may happen that the received clipboard data is empty, but
if it's of type image/bmp, gtk+ will crash:
gdk_property_change: 00030AD4 GDK_SELECTION image/bmp REPLACE 8*0 bits:
... delayed rendering
gdk_selection_send_notify_for_display: 00030AD4 CLIPBOARD image/bmp
GDK_SELECTION (no-op)
_gdk_win32_selection_convert_to_dib: 1252003C image/bmp
Program received signal SIGSEGV, Segmentation fault.
0x749a9f40 in msvcrt!memmove () from C:\Windows\syswow64\msvcrt.dll
Thread 1 (Thread 2248.0x1b34):
target=0xc07b) at gdkselection-win32.c:1292
at gdkevents-win32.c:3498
wparam=8, lparam=0) at gdkevents-win32.c:232
message=773, wparam=8, lparam=0)
at gdkevents-win32.c:263
C:\Windows\syswow64\user32.dll
C:\Users\rugoosse\AppData\Local\virt-viewer\bin\libpangocairo-1.0-0.dll
wparam=0, lparam=-1687549457)
at gdkevents-win32.c:248
C:\Users\rugoosse\AppData\Local\virt-viewer\bin\libpangocairo-1.0-0.dll
https://bugzilla.gnome.org/show_bug.cgi?id=728745
According to what i've been told, modelbuttons are supposed to look
flat, like menu items.
This is basically an improved copy of the menuitem styles.
https://bugzilla.gnome.org/show_bug.cgi?id=728810
This prevents checkmarks in modelbuttons from being styled as buttons
(apparently, modelbuttons apply "focused" to their children, unlike
normal buttons).
https://bugzilla.gnome.org/show_bug.cgi?id=728808
The events are routed through a new slave device with type
GDK_SOURCE_TOUCHSCREEN, minimal tracking of touches is done
to keep the state for each of those.
https://bugzilla.gnome.org/show_bug.cgi?id=728426
The master pointer/keyboard pair should never disappear or be
inconsistent. The seat capabilities are now reflected through
slave devices, those may come and go freely as the seat
capabilities change. This also enables adding further capabilities
to handle eg. touch.
https://bugzilla.gnome.org/show_bug.cgi?id=728426
When making the entire window a drop target, as file-roller does,
we don't want to draw the drag highlight around the CSD window
decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=728526
Please enter the commit message for your changes. Lines starting
This should allow theme developers to use a very small width for
the resize handle, but still let users easily move the handle by
defining a wider resize area.
The additional resize area follows the "margin" style property.
https://bugzilla.gnome.org/show_bug.cgi?id=728073
Binding an object sensitive property with a check button active property will look like this:
<object class="GtkButton" id="button">
<property name="sensitive" bind-source="checkbutton" bind-property="active"/>
</object>
This is based on the original work done by Denis Washington for his GSoC project
This closes Bug 654417 "[GSoC] Add <binding> element to GtkBuilder syntax"
Get monitor on which the most of the window is located (nearest monitor if
window is not on screen), get its work area (area not occupied by taskbar or
any other bars) and use that for maxsize.
Previous default of 30000 meant that windows maximized onto full screen,
even covering the area where taskbar is.
https://bugzilla.gnome.org/show_bug.cgi?id=726592
When selecting a swatch in a GtkColorChooserWidget the previously
selected swatch and the currently selected swatch are not redrawn. This
can leave the old swatch still marked with a checkbox even though a new
swatch has been selected.
Redraw the swatches after changing the selection.
https://bugzilla.gnome.org/show_bug.cgi?id=727487
The documentation for the GtkWidget::size-allocate signal is missing the
description of the "allocation" parameter. Add the missing description
to the parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=726179
Use GSlice to allocate all types of segments:
- char
- toggle
- mark
- pixbuf
- child widget
Char segments are a bit more complicated because the length of the text
is determined at run time and stored in the 'byte_count' field. If the
text is long, GSlice will call the system malloc() anyway, so it's
better to always use GSlice for GtkTextLineSegment.
Toggle segments are also freed in gtktextbtree.c, hence the function
_gtk_toggle_segment_free() (for a later commit it would be nice to
rename those functions with the _gtk_text prefix).
https://bugzilla.gnome.org/show_bug.cgi?id=727908
There is a possible confusion with the sentence:
"@iter is inside a natural-language word"
The iter should be viewed here as the pointed character (i.e. on the
right of the iter), not as a position between two characters.
Instead of improving the documentation, another solution would have been
to change the implementation so it is interpreted as an iter position
inside a word, i.e. between two characters that are part of a
natural-language word. But maybe some applications rely on the current
implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=727908
- As the tests show, some of the functions have a strange and
inconsistent behavior for corner cases.
- Rename test_full_buffer() -> test_search_full_buffer() because
textiter.c is used for other GtkTextIter unit tests.
https://bugzilla.gnome.org/show_bug.cgi?id=727908
We are using the actionbar in the middle of the window, which
is not really what it is designed for. To avoid the unfinished
appearance on the sides, move it into the frame that we have
around the stack below. This fixes the sides, but gives the top
a double stroke. Too bad.
The text view is resizing several times after the window is mapped.
Not setting a hscrollbar-policy of never avoids that, and a
scrollbar still doesn't appear. Magic
The incremental loading was broken by GtkIconHelper - queuing a
redraw is no longer sufficient to cause GtkImage to redraw with
the new pixbuf contents.
Pointed out by Jasper St. Pierre.
The keynav dialog is transient to the example window; since the
example window is now modal, we need to make the keynav dialog
modal as well, so it can receive input.
Problem pointed out by Jasper St. Pierre.
We are keeping references on the widget we are handling as we
are iterating up, but that doesn't protect us against the entire
tree being axed from inside gtk_widget_handle_event.
https://bugzilla.gnome.org/show_bug.cgi?id=727644
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
The use of border-width-set here was an attempt to differentiate
between explicitly set (from code / ui files) border width from
theme changes. But when we are calling gtk_window_set_border_width
to apply the theme value, the -set property gets set, and all
further theme changes are ignored. This has the effect of only
letting the default value of these properties get applied.
Fix this by unsetting border-width-set after applying theme values.
Because GTK does not invalidate windows that aren't mapped, we cannot
update the pixel cache when the window it handles isn't mapped. So we
add API to call when GDK windows get mapped/unmapped.
https://bugzilla.gnome.org/show_bug.cgi?id=726475
This commit makes it possible for GtkSwitch to indicate when
the underlying state changes with a delay, causing the switch
to temporarily go 'out of sync' with the underlying change.
https://bugzilla.gnome.org/show_bug.cgi?id=725648
This commit adds API for dealing with multi-selection. It is identical
to the flow box API for this purpose. The implementation is still limited
to single-selection, and will be updated in subsequent commits.
It can happen that we get a size request when the main widget
is still NULL. Currently we hit a critical in this case, and
stumble on. We can do better.
Opening a new tab in nautilus is hitting this case.
https://bugzilla.gnome.org/show_bug.cgi?id=727643
We are getting bug reports from people who are irritated that
dialogs now have 'double headers' under any wm but gnome-shell.
As an example, xfwm4 seems to do ok with csd windows, and
on balance it seems better to have some invisible border issues
than to have double headers.
https://bugzilla.gnome.org/show_bug.cgi?id=727414
Add support to build the introspection files for GdkWin32, as done recently
in the autotools builds and clean up the NMake Makefile for building the
introspection files a bit.
For some reason, gdk_win32_display_manager_get_type() was not exported in
gdk-3.0.lib, force its export, so that the GdkWin32-3.0.gir can be built
properly with the Visual C++ builds. This is a known problem that some
symbols in static libraries that are linked into a DLL in Visual C++, even
if they were marked with __declspec(dllexport) via _GDK_EXTERN.
* Makes listbox background white instead of default grey
* Uses gradients or W32 theme parts to draw sexy selection/prelight
rectangle instead of changing selected/prelighted item background
* Removes blanket button text color, allowing buttons to inherit
text color from their parents. Non-normal buttons DO get specific
text color though. This partially fixes text color propagation from
listbox rows to their children.
https://bugzilla.gnome.org/show_bug.cgi?id=727244
The arrow is part of the background image drawn by the theme, don't draw
GTK's own arrow. This also applies to non-entry comboboxes.
On XP the arrow-and-nothing-else part does not exist (W32 XP theme draws a
white rectangle) and has to be subtituted for a simple dropdown button even
for non-entry comboboxes.
https://bugzilla.gnome.org/show_bug.cgi?id=727035
It seems that the dec-button no longer has a "bottom" selector-thingy to
select for. Use "last-child" instead.
Use .vertical to style vertical instance differently, as last-child/first-child
meaning is inverted there.
Increase (towards 0) margins a bit, to avoid clipping the pre-light rectangle.
Use dir(rtl) selector to style horizontal instance differently for RTL locales,
where first-child is "inc".
https://bugzilla.gnome.org/show_bug.cgi?id=727022
...on Windows 8+ and when the system setting for non-Unicode programs do
not match the language version of Windows by falling back to using Pango.
This ensures that the correct font is used during these scenarios, so that
we minimize the risk of seeing garbled characters for texts that the system
code page does not support due to system peculiarties. There might be a
way to support gtk-font-name handling using the native Windows APIs
directly on Windows 8+, but that needs to be investigated.
https://bugzilla.gnome.org/show_bug.cgi?id=726298
GTK_TREE_VIEW_TIME_MS_PER_IDLE is currently 30 milliseconds, meaning
that validate_rows will validate rows up until all the validations have
taken over 30 msecs. So it's likely to block redrawing via the clock
frame update mechanism, as that tops at 16.66 milliseconds per frame
(1/60th of a second).
Stop validating rows if we've spent more than 3/5 of our allotted budget
for inter-frame processing, so as to avoid blocking.
In the future, we would probably want to calculate how long we would
have left until the next frame, especially if higher priority idles
and timeouts have already consumed a portion of that allotted time.
https://bugzilla.gnome.org/show_bug.cgi?id=726871
A "typo" led to using a wrong GtkTreePath when converting the path of the
virtual root to check the ancestors, which would lead to either no checks being
performed, or maybe segfaulting when using an invalid path as result.
https://bugzilla.gnome.org/show_bug.cgi?id=722058
Signed-off-by: Olivier Brunel <jjk@jjacky.com>
These AtkRelation types are added automatically for widgets with a label
specified (e.g. via gtk_label_set_mnemonic_widget, gtk_frame_set_label,
and gtk_frame_set_label_widget). When such specification is absent, the
accessible relationship must be manually set.
https://bugzilla.gnome.org/show_bug.cgi?id=726996
Commit faba7df4fe changed the logic in
apply_emblems() so that GtkIconInfo->emblems_applied would be set to
TRUE even in case there was no emblem info available, which confuses the
theme cache.
This commit changes the logic back, so that NULL is returned from
apply_emblems_to_pixbuf() when there are no emblems available, fixing
the bug.
https://bugzilla.gnome.org/show_bug.cgi?id=726830
The compositing that is meant here is really specific to the
X11 Composite extension, and does not apply to Wayland.
This is very rarely used functionality anyway, and none of
the other backends support it.
This way, we don't create lots of cell accessibles when creating the
first one (because surely one is the parent/child of another who again
is a parent/child of another who again....)
Nobody was reffing those related object in the first place and that
was causing random crashes.
And if somebody had reffed those related objects, they'd have caused
reference cycles.
https://bugzilla.gnome.org/show_bug.cgi?id=726838
This fixes an issue where the theme-provided border-width prevents
dialog contents from lining up properly with the headerbar. To make
this work in message dialogs, we have to explicitly set the border-
width of the action area to 0.
In select-folder mode, we are putting the directory name into the
entry ourselves. Then the entry appends a /. If we react to this
'spontaneous' change of the entry by clearing the list selection,
this will in turn make us clear the entry. We don't want that.
https://bugzilla.gnome.org/show_bug.cgi?id=726855
Setting windows undecorated was broken by some of the recent
shadow width changes. We need to ensure that shadow width is
zero for undecorated windows, then things work again.
If the delete event ends up destroying the widget, unsetting
priv->delete_event_handler will happen on invalid memory, so
unset it before the widget is possibly destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=726825
Theoretically, we apply the shape mask client-side ourselves
with an ARGB32 pixmap and intersect it to get a union shape,
but I don't particularly care enough to write that code.
Realistic application code using bounding shapes in 2014 is
quite rare.
Widgets should only call set_realized() after having created and
registered their GDK windows. In this case, the creation of the style
context (or more exactly: figuring out the scale factor for it) requires
knowing if the widget is already realized. Which it isn't.
https://bugzilla.gnome.org/show_bug.cgi?id=726717
expected a valid semicolon
sounds kinda not so great. Make it say
expected semicolon
Unless somebody can tell me the difference between valid and invalid
semicolons?
We had a margin of 30 before/after the text. Put that add around
the icon as well, and separate the icon and text by 30 pixels.
This does not affect the appearance of message dialogs without
icons.
It seems that some backends implemented get_root_origin wrong
and returned the client window coordinates, not the frame window
coordinates. Since it's possible to implement generically for all
windows, let's do that instead of having a separate impl vfunc.
Lots of code, including dragging code in GtkWindow, use these
fields. Setting them to 0 causes lots of strange and weird bugs.
Use the same "hack" from query_device_state of just using
win_x / win_y for now. We'll convert this to the proper fake root
coordinate system used by get_root_coords in the next commit.
If a textview had lateral windows that might displace the text window, the
handles and popovers would appear displaced. Those lateral windows aren't
affected by RTL/LTR settings, so just checking for left/top is ok here.
And the counterpart to unmaximize when dragging a maximized window, if
touch devices aren't going to use EWMH moveresize, having this one at least
makes things feel a bit less awkward.
https://bugzilla.gnome.org/show_bug.cgi?id=709914
Sadly, EWMH moveresize mechanism can't work with touch devices for two
reasons:
1) As a mutter implementation detail, the device is queried in order
to check whether the dragging button is still pressed. Touch devices
won't report the button 1 being pressed through pointer emulation.
2) Even bypassing that check, on X11 touch events are selected prior
to sequences being started, either through XISelectEvents or
XIGrabTouchBegin, no late registering through active grabs is allowed,
as WMs do on reaction to EWMH moveresize messages.
So for the time being, make touch devices fallback on emulated window
dragging, which at least allows for moving windows.
https://bugzilla.gnome.org/show_bug.cgi?id=709914
We want to present a clean, rounded top when there is nothing
else to show, but many dialogs in applications rely on showing
information in their title, so add a label and show the title
when it is not empty.
Add gdk_device_get_last_event_window(), and use to implement the window
tracking we need for synthesizing crossing events for sensitivity changes
and gtk grabs, rather than keeping the information in qdata and updating
it based when GTK+ gets events.
https://bugzilla.gnome.org/show_bug.cgi?id=726187
Stop ignoring various crossing events from grabs:
Enter events with type GRAB/GTK_GRAB/GTK_UNGRAB/STATE_CHANGED:
Ignoring these events was added as a workaround for synthesized
events not having the right coordinates (see bug 555109) but
now they do have the right coordinates. (see bug 704456)
Leave events with types types GTK_GRAB/GTK_UNGRAB:
Ignoring these events was added because since we were ignoring
the enter events as above, ignoring the leave events meant we
could lose the prelighted row in a grab-triggered leave/enter
pair. (See bug 653676. It's also now impossible to
reproduce the leave events that were reported in that bug as causing
problems.)
Leave events of type GRAB.
Ignoring these events was added without a ChangeLog entry in 2001,
possibly to keep the prelight from flashing when activating menus.
But ignoring these events could lead to stuck prelighting, and we don't
do it for any other widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=726209
The bug this patch is fixing is that currently if you have a GtkPopover in
clicking off the popover to dismiss it on a GtkTreeView (which triggers
a synthetic enter event on the GtkTreeView) will leave the GtkTreeView
in a confused state until the user moves the mouse again.
That doesn't make sense.
And it causes issues, because when holding down the tab key, we
show/hide a lot of windows and cause a lot of map/unmap events that
stall the event pipeline.
We did not set an input shape on the window, so the region outside
the invisible border where we draw the outer edges of the shadow
were still part of the window, as far as clicks and cursors were
concerned. Fix this by setting an input shape that makes all clicks
outside of the resize borders go through to the underlying window.
https://bugzilla.gnome.org/show_bug.cgi?id=726125
eb1ab0dac2 removed support for authentication
based on crypt()-hashed passwords but it didn't remove the header.
Finish up with the removal.
This allows the broadway backend to build on FreeBSD (which has no
crypt.h).
https://bugzilla.gnome.org/show_bug.cgi?id=726149
And let GtkPopover use it as its GtkAccessible implementation, this
accessible sets the POPUP_FOR relationship to the relative-to widget,
and keeps track of changes there.
https://bugzilla.gnome.org/show_bug.cgi?id=725864
As those are internal children, there's no signal that GtkWindowAccessible
could catch when those are added or removed, so make GtkWindow use the private
GtkContainerAccessible methods to add/remove the child accessible when that
happens.
https://bugzilla.gnome.org/show_bug.cgi?id=725864
window->x / window->y are in "root window coordinates", e.g. relative
to the topmost toplevel. However, the coordinates in get_xdg_popup are
relative to the passed-in surface, so we need to do the reverse
translation here.
As discussed on desktop-devel-list [1], "There should be an intuitive,
consistent, immediate way to jump to the widgets that live in the
header bar." F10 has been suggested for this as it is already used to
active menubars.
F10 will focus the custom titlebar widget if the window has one and it
isn't already focused. If the titlebar widget doesn't exist or is
already focused then F10 focuses the menubar if there is one.
[1] https://mail.gnome.org/archives/desktop-devel-list/2014-February/msg00176.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=725141
It turns out popovers are already smart enough to cope with this
situation, so let popovers be internal children so things that rely
on gtk_container_forall(), like DnD, work without modifications.
https://bugzilla.gnome.org/show_bug.cgi?id=725727
We have a hack in the XSETTINGS code to substitute gtk-xft-dpi
with gdk-unscaled-dpi unless the screen has a fixed window scale,
in which case we just use gtk-xft-dpi.
But if the screen is changed to have a fixed window scale, then
the substituted value of gdk-unscaled-dpi will stick around until
the next (coincidental) change to XSETTINGS. To fix this, force
an immediate reread of the XSETTINGS property when
gdk_x11_display_set_window_scale() is used.
https://bugzilla.gnome.org/show_bug.cgi?id=725754
It may be unusual, but handlers of day-selected may want to transfer
focus somewhere else, without getting it reset back right after by/to
the calendar. This makes popovers demo work on the calendar again, for
one...
Make the popover temporarily undo the GTK+ grab, so it remains modal
to its window, but does not attempt to steal focus on other non-modal
windows that get the focus.
This was most confusing with keyboard navigation, as the focus would
remain stuck on the popover, and not move to the newly focused window
after the popover was dismissed. It didn't have as much effect on
pointer operations as only the first click would be consumed in order
to hide the popover.
There are early returns in this method before the completion timeout
is set later on, so set the source to 0 to avoid trying to remove it
later again.
https://bugzilla.gnome.org/show_bug.cgi?id=725824
This is not necessary for the popover itself, but helps tooltips
code confine the widget lookup within the popover if the pointer
is inside it, otherwise the widget lookup may turn out wrong for
motion events, starting the tooltip widget lookup from the toplevel
window, mistakenly triggering tooltips on the natural window
descendants (ie. the widget below the popover)
https://bugzilla.gnome.org/show_bug.cgi?id=724785
gnome-terminal is still using this setting, so we'll let
applications override it for another cycle. It is no longer
backed by a system-wide setting, though, and it will still
go away eventually.
This partically reverts b26c74e5da
gnome-terminal is still using this setting, so we'll let
applications override it for another cycle. It is no longer
backed by a system-wide setting, though, and it will still
go away eventually.
This partically reverts 7e3a494fac
Add documentation for GtkTreeView::move-cursor
Add links to GtkTreeModel::row-inserted and GtkTreeModel::row-deleted
in the documentation for gtk_tree_view_set_reorderable ().
https://bugzilla.gnome.org/show_bug.cgi?id=725560
If we aren't using a header bar then put a fake titlebar
box on it so we can round the corners.
One of the advantages of this is so that the styling of the dialog
is completely within one theme framework. This prevents skew between
the theming expectations from the window manager and GTK+.
https://bugzilla.gnome.org/show_bug.cgi?id=725345
GOBJECT_INTROSPECTION_CHECK macro can be missing if introspection
is not installed, so this way the following error is prevented:
"gtk/Makefile.am:1324: error: HAVE_INTROSPECTION does not appear
in AM_CONDITIONAL"
https://bugzilla.gnome.org/show_bug.cgi?id=723438
This is a web service provided by Google that allows people to
share their printers (https://www.google.com/cloudprint/learn/).
In addition to being able to print to printers shared on Google Cloud
Print, there is an equivalent of "Print to file" in the form of "Save to
Google Drive".
The cloudprint module uses gnome-online-accounts to obtain the OAuth 2.0
access token for the Google account.
Currently it can discover available printers, get simple details about
them such as display name and status, and submit jobs without any
special options.
https://bugzilla.gnome.org/show_bug.cgi?id=723368
Restore the drawing order in GtkFixed to what it was in 3.8. With the
GDK drawing changes this will not be correct in some cases (un-windowed
children can now overlap windowed children and native children overlap
everything), but fixes Eclipse drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=725089
The point of GdkWindowImpl::get_root_coords is to translate the passed
in coordinates against the passed-in impl window. For a child window,
in fact, window->abs_x and window->abs_y already track the child
window's coordinates against the impl window.
If we pass in a child window, and backends don't explicitly get the impl
window from it, we'll double-count the child window.
Really, we should *always* be passing impl windows to backends, and
never child windows. However, I'm a bit worried for regressions late
in the cycle if we want to fix up the rest of the callers, like
gdk_window_get_geometry, so I'm only going to touch get_root_coords
for now after careful review of all the backends.
GtkWindow calls set_shadow_width then maps the window, meaning
that we never set the margin. Save it when we set and then set
it when we create the XDG surface.
In the unlikely case that there is another GPL released in the future
it would be best if we link directly to the 3.0 version of the
license description instead of the alias to the latest
version.
Old code assumed that AT-SPI would keep track of references and
therefore tried to only hold weak references. On the other hand it also
tried to keep objects alive so it referenced objects very randomly. All
of that lead to cycles and leaking.
As AT-SPI does not keep track of objects at all, the treeview now does.
The refcounting looks as follows:
GtkTreeViewAccessible
=> creates per row/column
GtkTreeViewAccessibleCellInfo
=> which references 1
GtkCellAccessible
If there is only one cell, this accessible is a
GtkRendererCellAccessible, otherwise a GtkContainerCellAccessible is
created and that accessible holds references to the
GtkRendererCellAccessibles that are created for every cell renderer.
https://bugzilla.gnome.org/show_bug.cgi?id=554618
Instead of destroying the surface in the backend if this is
unable to resize, let the core code do it, and do it properly.
Based on a patch by Benjamin Otte.
https://bugzilla.gnome.org/show_bug.cgi?id=725172
GObject-Introspection was recently changed to support acquiring the name of
the DLL from a library (.lib, etc) that was passed into g-ir-scanner on
Windows, like the *nix builds, instead of directly passing in the name of
the DLL.
This updates the introspection build process, so that introspection files
for GTK+ can continue to be properly built.
The code in GDK is incredibly broken and nobody is quite sure what's
right-side-up and what's upside down, but this breaks mutter-wayland
now, so let's remove it. It might leak, but we should probably do a
full restructuring of GDK drawing to fix it.
Like in other backends (except X) we can't resize cairo image surfaces
so let's sync the code here with what the other backends do.
This prevents the painting machinery above us to paint on the wrong
buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=724968
The new() function is supposed to return an empty fully initialized
GtkCssKeyframes object, while the alloc() function just allocates and
initializes static values. So alloc() can be used for copying or
resolving keyframes.
Fixes a memleak when resolving keyframes.
With the code as written, use-popover has to be set first,
before the model. To avoid this ordering dependency, re-set
the model when use-popover changes.
The convention we follow is that the PROP_foo define should
match the property name. Therefore, change PROP_MODEL to
PROP_MENU_MODEL to match "menu-model".
gtk_tree_view_remove_column was first removing the column from
its list, then call gtk_tree_view_column_unset_tree_view, which
would then call gtk_container_remove to remove its button from
the treeview. But the treeview remove implementation relied
on the column being still in the list in order to recognize
the button as 'special', so in effect the button was never
properly removed and thus, leaked.
Fix this by callling unset_tree_view before removing the
column from the list.
https://bugzilla.gnome.org/show_bug.cgi?id=724891
c287845240 was trying to fix
the memory leak caused by popovers begin destroyed in
gtk_window_destroy before chaining up to gtk_widget_destroy,
which unrealizes the window, and would clean up the popover
windows if the popovers were still around.
Fix this in a better way by moving the popover destruction
after the chaining up, so we unrealize first, and then
destroy the popovers.
Also, make _gtk_window_remove_popover unrealize the popover,
for symmetry with _gtk_window_add_popover.
This should fix
https://bugzilla.gnome.org/show_bug.cgi?id=724921
Normally, a GtkAboutDialog is shown using the convenience
API. But if you manually construct one and show it by calling
gtk_widget_show_all() on it, the license tab would show up
uninvited. Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=724411
Add some flexibility in the property sheets for one building GTK+ that it
also searches for a settable installation path of Python, in addition to
searching the PATH for an installation of the Python interpretor. This
currently defaults to Python 2.7.x, which is normally installed in
c:\python27 on Windows by default. Also tell people in the README.txt's
for the Visual Studio builds
In practice this shape is only used to outline the popover when it is
above native windows, in the most normal full-csw case the shape won't apply
visibly, so popovers will still be able to cast a shadow there.
If there are native windows below the popover, the shape will exclude the
shadow, so there are no alpha contents above the window. One worst case that
might happen is that the popover lays above patches of native/client-side
windows, so the shadow could come and go around the border. But first let's
see whether that happens often or visibly enough before adding something more
convoluted.
The update of the needs-attention state is done via its own property,
so it doesn't need to be done via visibility changes.
This patch is largely the result of inspecting the code due to a warning
and not a result of testing. So if issues pop up that bisect back to
this patch, that's why.
And document the fact that the popover will get destroyed if
a NULL relative-to is given on a parented popover, if no extra
references are kept.
For gtk_popover_new*(), a NULL relative-to will leave the widget
as a floating object, to be sunk by a later call to
gtk_widget_set_relative_to().
https://bugzilla.gnome.org/show_bug.cgi?id=724407
The recursion in map needs to follow the actual physical
widget tree, otherwise we violate invariants. The generic
container map implementation uses gtk_container_forall to
operate on the children, and thus is not suitable for
containers where the children are inside some internal
container.
We should only eat button release events when the label is
actually selectable, since the comment indicates that we
want to eat the release events belonging to press events
that triggered a selection. This fixes problems with actions
on parent widgets that are triggered by button release,
as seen in this bug:
https://bugzilla.gnome.org/show_bug.cgi?id=724541
Suprisingly, this bug has been there for a very long time.
I'm fixing it now because we now use a custom search entry
in the app chooser dialog, and this is causing the templates
cleanup test to fail.
The with_separators argument does not really make sense
for popovers, it was just copied from the menu implementation.
Drop it now, before it becomes part of the public API.
Dragging windows was not working on widgets in the titlebar
region unless they had the window-dragging style property
set. Fix this by looking at the region for motion notify
events as well as for buton press events.
The code setting up the button has been move a little later
in the dialog construction, with the effect that the entry
is already insensitive when we set up the binding.
We had already set the image to be hidden in the .ui file.
This patch removes the image altogether, and deprecates the
property, setter and getter.
If an image is explicitly put with the setter, it is still
shown, so to not break existing users of this API.
Based on a patch by Jon McCann.
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.
Improve the algorithm to determing popover placement:
If it fits in the preferred direction or its opposite,
do that, otherwise use the direction that causes the least
of the popover to be cut off.
Add api to allow explicitly setting a GtkPopover instead of
a GtkMenu as the popup of a GtkMenuButton. Also, add api to
instruct the menu button to construct a popover when given
a menu model.
We set the style class "menu-button" on the button only when
it pops up a menu, to allow different treatment for the active
state of the button in the two cases.
https://bugzilla.gnome.org/show_bug.cgi?id=723878
cairo_rectangle_int_t replaced by GdkRectangle whenever it is used.
Also, rect parameter in public method gtk_popover_set_pointing_to
made const.
Bug #723394
Replace GTK_TYPE_WIDGET with more specific GTK_TYPE_FLOW_BOX_CHILD
for GtkFlowBox::child-activated. This matches signature of
child_activated slot in class struct.
https://bugzilla.gnome.org/show_bug.cgi?id=723716
The properties are declared read-write, but only the setter
was hooked up. This was leading to criticals in test apps using
the prop-editor.c code. Complete the implementation by adding the
getter side too.
This adds a new function, gtk_popover_new_from_model, which creates
a popover and populates it with suitable content according to the
menu model. The current implementation uses GtkModelButton for the
individual items, and a GtkStack for submenus.
https://bugzilla.gnome.org/show_bug.cgi?id=723014
Similar in spirit to GtkModelMenuItem, this private GtkButton subclass
can connect to a GtkMenuTrackerItem and present itself as either a
regular button, a check button, or a radio button. Activation and
state tracking is done through the GAction that is associated with
the menu tracker item.
https://bugzilla.gnome.org/show_bug.cgi?id=723014
Popovers aren't direct children of the widget they point to, but yet
they act as children of it, so do the same with state propagation,
so the flags that propagate across the hierarchy reach popovers too.
Anytime ::grab-notify comes across, the popover visibility and GTK+
grab ownership are checked, so the popover is hidden when it loses
the GTK+ by any reason.
Previously we did a semi-successful job at ignoring it. Unfortunately
this job was bad enough that we could lose the direction.
We still allow passing in the enum values, because we want code like
this to work:
set_state_flags (get_state_flags() | SOME_FLAGS)
Heavy duty can prevent this idle function from being called before
the window is destroyed, so make sure that the source is removed
when the window is finalized.
https://bugzilla.gnome.org/show_bug.cgi?id=723771
This hideous hack is necessary so far because the main users of
GtkScaleButton are also clutter users, so the GtkScaleButton popover
will be very likely shaped against a clutter-enabled native window.
https://bugzilla.gnome.org/show_bug.cgi?id=723556
Popovers no longer sets a shape, unless this function is called. This
function exists so widgets that are potentially placed on top of other
native windows can get a popover that's nicely shaped, even if it has
no border shadow around.
https://bugzilla.gnome.org/show_bug.cgi?id=723556
Since realize does a lot of the heavy lifting of setting up
csd, we have to re-realize the window if we go from no-custom
titlebar to a custom titlebar or vice versa.
https://bugzilla.gnome.org/show_bug.cgi?id=722919
When gtk_window_set_titlebar is called, we need to set up
client-side decorations properly, and the easiest way to do
so is to realize the window again. Really, you should call
set_titlebar before the window is realized.
https://bugzilla.gnome.org/show_bug.cgi?id=722919
10b5ec20 made sure not to set focus_child to NULL all the way up to the
top, but only up to the common ancestor. However, it would never set it
on the common ancestor itself, which would therefore remain with a
focus_child set when it shouldn't.
A manifestation of the bug: focus column headers of a treeview, press Tab.
Now pressing Shift+Tab will go to another widget and not the column
headers, and Tab will (appear to) do nothing, all because the treeview
still has a focus_child set to column headers after a grab_focus().
Signed-off-by: Olivier Brunel <jjk@jjacky.com>
https://bugzilla.gnome.org/show_bug.cgi?id=723402
We can't destroy buffers if they're in-use by the compositor. Well,
technically we can, but that is considered undefined by Wayland and
mutter won't cope with it very well -- it simply kills the client.
To solve this, we need to delay the destroy operation until the
compositor tells us that it's released the buffer. To do this, hold
an extra ref on the cairo surface as long as the surface is in-use
by the compositor.
This reverts commit ba6128f8af.
This change breaks emacs drawing entirely. Since GtkFixed is
somewhat of a legacy widget anyway, lets just not bother doing
this modernization there, at least for now.
Showing tooltips on top of a transient popup does not work
out well, and is not really necessary here. At the same time,
remove the unnecessary repetitions of properties. In particular,
setting the label of the buttons here defeats the scale buttons
use of symbolic icons.
https://bugzilla.gnome.org/show_bug.cgi?id=723181
This prevents warnings like
(gtk3-demo:14948): Gdk-CRITICAL **: _gdk_frame_clock_thaw: assertion 'GDK_IS_FRAME_CLOCK (clock)' failed
(gtk3-demo:14948): Gdk-CRITICAL **: gdk_frame_clock_get_timings: assertion 'GDK_IS_FRAME_CLOCK (frame_clock)' failed
We need to do this, as the compositor might have already sent us a frame
event, in-flight, at the same time we destroy our window. In this case, we'll
receive the then-in-flight "done" event, and then warn as we try to look
up the frame clock on a destroyed window.
disconnect_by_func() is slow, and this becomes particularly evident
when disposing a number of widgets (and their associated style
context) at once, such as when using a language binding which
uses a GC.
https://bugzilla.gnome.org/show_bug.cgi?id=723183
It seems that alternate implementations of GtkFileChooserWidget
never materialized. The split between GtkFileChooserWidget and
GtkFileChooserDefault is awkward. The immediate problem is that
it makes it difficult to document the keybinding signals. So it
makes sense to drop the abstraction and just have one thing.
https://bugzilla.gnome.org/show_bug.cgi?id=723157
The button press/release handlers did invariably return FALSE, even
though it shouldn't if a row was found on the event coordinates. Also,
use GDK_EVENT_* defines for the return values.
The minimal size if no child widget was present/shown was far too small
to have enough room for the arrow width plus border radii, so
gtk_render_frame_gap would spew warnings about the gap being out of
boundaries.
Fixes issues seen in
https://bugzilla.gnome.org/show_bug.cgi?id=723031#c2
If the grab is released during button press, the button release is
just then sent to the widget below the pointer. Depending on the
widget implementation, this could already trigger actions if the
widget does not perform any kind of button state tracking. It is
safer to ungrab on button release so no extra actions are possibly
triggered, and the behavior is uniform across widgets.
But the opposite situation may also happen, that a popover is
shown/grabbed on a button press event, so it'd get the sole button
release event after being shown, so prepare for that case by making
popover ignore single button release events with no preceding button
press.
Fixes issues seen in
https://bugzilla.gnome.org/show_bug.cgi?id=723031#c2
Removable USB drives or memory sticks should be powered down
when the eject button is pressed. For this, we need to call
g_drive_stop() instead of g_drive_eject(), provided the drive
can be stopped.
https://bugzilla.gnome.org/show_bug.cgi?id=723121
Add printer_compare() function for comparing printers according
to their names and locations. It is possible to search by multiple
keys separated by space or tabulator using logical conjunction.
Based on patch by William Hua.
https://bugzilla.gnome.org/show_bug.cgi?id=692931
The root window is a fairly X-centric concept, and it
really has no place in the GtkWidget API. Plus, this
is a rarely-used one-line convenience function with
poor documentation.
Put dialogs and utility windows in the same level as normal and
toolbar windows so that Gtk can control their stacking instead of
forcing them, rather unnaturally, to be on top of all other windows,
even other application windows, even when another application has
focus.
Instead of setting "use-header-bar" from gtk_about_dialog_new(),
override its default value by inspecting the properties at constructor()
time. This makes it work from bindings as well, since they don't use the
convenience C constructor.
https://bugzilla.gnome.org/show_bug.cgi?id=722574
GtkWindow has 4 (!) APIs for setting window icons, and we
have to try them all in the right order to find the right
icon. This commit makes it so, and keeps the icon list
manipulation inside gtkwindow.c by adding a private API
for getting a single icon at the right size.
https://bugzilla.gnome.org/show_bug.cgi?id=722515
This is needed to show the gtk3-demo icon and is needed for the "Multiple
Views" demo to work. Hmm, why couldn't I do a for loop for a batch in a
property sheet ? :|
It was only done so the background would connect visually to the popover
tail, but then it brings aliasing issues when the border is drawn over the
background. Instead, overdraw the tail, so it also fills the gap left by
the border.
If pointing_to starts falling outside of the parent scrollable allocation,
the popover will be automatically hidden, and shown back again when
pointing_to scrolls back to visibility.
If the rect a handle points to starts falling outside of the parent
scrollable allocation, the handle will be automatically hidden, and
shown again when the rectangle is visible too.
When all popovers are removed on destroy(), if a popover is nested into
(eg. with relative_to within) another popover, the removal of one can
lead to the other being removed while the hashtable is being iterated,
which would lead to undefined behavior in further iterations.
Then, use a GList to store popovers, iterating can be made more resilient
on these situations, and unless on pathological cases there's not going
to be as many of those popovers as to cause performance decreases at the
times those are iterated.
The popovers may return keyboard grabs to previous widgets, so if
called after unsetting the focus, the window may be left with a
dangling GtkWidget that would cause crash at later dispose() calls.
With only get_preferred_width and get_preferred_height implemented,
we end up calling the GtkBin height_for_width implmementation, which
knows nothing about the margins and paddings that GtkPopover needs.
As a result, a listbox added to a popover was getting cut off
at the bottom.
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.
The GtkBuilder window containing the complex popover UI was left
dangling, and with a dangling pointer to its former child, causing
crashes on gtk_grab_notify() after the popover was destroyed.
Popovers are strange in the sense that they aren't attached to a
parent directly, they rely on the relative_to widget so the toplevel
is shared, and when they have a parent, it is the toplevel itself,
not relative_to. This also means that there are conditions where the
popover loses it's parent, so they must survive unparenting.
The previous code would be floating the last reference as soon as the
parent is gone, but it was non-obvious who'd own that reference. So
fix this situation by granting the ownership of popovers to their
relative_to widget, an extra reference may be held by the toplevel
when the popover has a parent, but the popover object will be
guaranteed to be alive as long as the parent lives.
This way, memory management of popovers is as hidden from the user
as regular widgets within containers are, users are free to call
gtk_widget_destroy() on a popover, but it'd eventually become
destructed when relative_to is.
When a popover is focused, the focus is forwarded so the first
child what would get the focus actually gets it. Also, implement
correct focus chain, so the keyboard focus stays within the popover
when navigating with keyboard.
This makes it possible to move/resize client-side decorated windows that are
otherwise obscured by a GTK+ grab somewhere else, either a popover within the
window itself or a modal dialog above the window.
This offers the same behavior, but GDK_WINDOW_TEMP windows aren't used
anymore, involving less translations from/to root coordinates, plus no
glitches in having handles snap to content as windows move.
If there is a GTK+ grab on the popover, ensure that it's removed when it's
unmapped. If no GTK+ grab was performed on the popover, this function will
do nothing.
Those functions aren't as useful anymore, hiding/showing can be
controlled by setting the widget visibility, and grabbing can be
achieved by performing a GTK+ grab.
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.
This is not as necessary now that bubble windows are popovers, if
a modal behavior is wanted on popover contents, a GTK+ grab on the
popover widget will suffice.
Popovers are transient floating widgets that are confined to the
window space. These have their own GdkWindow that is set on top
of the regular window contents, so they can be used for popup menu
alike UIs with custom popup/popdown/grabs behavior.
The color chooser test is constantly running into the
problem that the custom color setting is not empty.
Avoid that by using the memory settings backend.
This new method allows getting a widget from a GtkStack when we know its
name, and will also return NULL if there is no widget going by that
name.
Usage example would be to check if a child with a given name exists
before calling gtk_stack_set_visible_child_name().
https://bugzilla.gnome.org/show_bug.cgi?id=722588
It would be nicer if we could have the tests specify what environment
their expected output was created in, then we could test multiple
scenarios. For now, just fix the setting to avoid test failures.
When running on quartz, it is no longer expected for applications to
provide their own application menu. Instead, they should simply ensure
that they provide "app.about", "app.preferences" and "app.quit" actions
(which many apps are already doing).
A default menu will be shown that looks like the one presented by all
other Mac OS applications, containing menu items for the above actions,
as well as the typical "Hide app", "Hide Others and "Show All" items and
the "Services" submenu.
If an application does explicitly set an application menu (via
gtk_application_set_app_menu()) then it will be respected, as before.
https://bugzilla.gnome.org/show_bug.cgi?id=720552
Add support for extracting strings from GMenu markup in GtkBuilder
files.
This means that we have to support translatable <attribute/> tags.
Unfortunately, <attribute> is also used by GtkTreeViewColumn and
GtkLabel for other purposes, and those other purposes use a value=''
(XML) attribute, so we must accept (and ignore) that in order not to
have errors. Nothing will happen in those cases because they do not
also specify translatable='yes', so we ignore them.
https://bugzilla.gnome.org/show_bug.cgi?id=720552
Add a new private API to GtkApplication akin to
gtk_widget_insert_action_group().
We'll use this to insert a few extra actions at the app level with a
separate namespace for the special items in the Mac OS application menu.
https://bugzilla.gnome.org/show_bug.cgi?id=720552
Add a private hack to allow the insertion of the name of the application
into the label of menu items.
If it appears in the label of any menu item, "%s" will be replaced with
the name of the application.
We will use this for the "Hide myapp", "Quit myapp" and "About myapp"
labels typically found on Mac OS programs.
https://bugzilla.gnome.org/show_bug.cgi?id=720552
Allow the possibility for items to be marked with a special attribute and
expose this via GtkTrackerMenuItem. For internal use only.
We will use this to implement the special 'Hide', 'Hide Others' and 'Show All'
items and the 'Services' submenu in the Mac OS application menu.
https://bugzilla.gnome.org/show_bug.cgi?id=720552
By default, Mac OS scans menus as they are opened, updating the
sensitivity of each item in the menu.
The current code in gtkapplication-menu-quartz disables this behaviour,
preferring to manually control the sensitivity of each item in the menu
(when told by the tracker that it has changed internally).
Change the way that this works to more closely follow the usual Mac OS
regime.
This will allow us to construct a typical "application menu" on Mac OS
containing the items that are typically found there ("Hide", "Hide
Others", "Show All", "Services") and have the OS automatically update
their sensitivity.
https://bugzilla.gnome.org/show_bug.cgi?id=720552
Add a custom title had the side-effect of showing the widget.
That is not right, adding children and managing their visibility
should be independent. The headerbar size allocation code also
made the assumption that a custom title is always visible.
With these changes, GtkHeaderBar should be usable in situations
where the centering functionality is not required, and it is
important to freely pack content at both ends, such as in nautilus.
https://bugzilla.gnome.org/show_bug.cgi?id=722340
Use a GtkHeaderBar for the credits and about buttons.
It makes less sense here than in other places to go back to
the buttons on the bottom, considering we only have a close
button, so we always use a header bar.
https://bugzilla.gnome.org/show_bug.cgi?id=720059
This commit introduces a private convenience API that derived
dialogs can call in their instance init. This is necessary to
make the setting work as intended in the face of 3rd party
dialogs derived e.g. from GtkFileChooserDialog, which are
created with g_object_new.
This setting will let us keep traditional appearance
of dialogs on platforms where this is expected.
The new setting is called gtk-dialogs-use-header, backed
by the Gtk/DialogsUseHeader xsetting.
This change makes it possible for GtkDialog to pack
its action widgets into a header bar, instead of the
traditional action area. This change is controlled
by the use-header-bar construct-only property.
https://bugzilla.gnome.org/show_bug.cgi?id=720059
Stop trying to deal with "theoretical possibilities".
We can't possibly continue to be a faithful GActionGroup implementation
across dispose because dispose has a side effect of removing everyone's
signal handlers.
The code that we ran after the dispose chainup to do all of the fancy
signal emulation was therefore dead. The test that aimed to verify this
was buggy itself due to an uninitialised variable, so really, it never
worked at all.
We keep the re-ordering of the chainup from the original commit to avoid having
trouble with GtkActionMuxer and keep the checks in place that will prevent an
outright segfault in the case that someone else tries to use the interface
post-dispose.
https://bugzilla.gnome.org/show_bug.cgi?id=722189
With proper notifications, plus an accessor method for that state. This
allows client to just listen to notify::is-maximized instead of tracking
window-state-event.
https://bugzilla.gnome.org/show_bug.cgi?id=698786
This leads to disastruous results, since each menu is itself
in a GtkWindow, so holding down the menu key leads to a neverending
cascade of menus on top of menus.
https://bugzilla.gnome.org/show_bug.cgi?id=722106
Theming code gets confused when computing the spacing for 0px wide dots
and then divides by 0. And then cairo complains and stops drawing
anything forever out of spite and then we end up with a single color
screen.
https://bugzilla.gnome.org/show_bug.cgi?id=721800
Rename testsrules_msvc.mak to detectenv_msvc.mak and remove some package-
specific stuff from it, to reflect on the nature that this NMake Makefile
is shared.
The current approach of building the introspection files for GTK works, but
is often cumbersome as one needs to set many environmental variables before
launching a solution file, which runs a Windows batch script to generate
the .gir/.typelib files. It was also possible to hand-run the batch script
from the Visual Studio command prompt, but even more environmental
variables need to be set.
This changes the approach to build the introspection files using an NMake
Makefile (but elimating from the Visual Studio Project Files the part to
build the introspection files) to:
-Make it clearer to the person building the introspection files what
environmental variables are needed, specifically for PKG_CONFIG_PATH and
MINGWDIR and CFG (formerly CONF). Setting stuff like VSVER, PLAT and BASEDIR
is no longer required, which was a bit clunky.
-Allows some more easier flexibility on the build of the intropsection files.
Make sure the needed public headers for GTK master is "installed", and re-
order some items so that it is easier when the headers lists are
automatically acquired from the various Makefile.am's.
The EWMH defines _NET_WM_MOVERESIZE_SIZE_KEYBOARD and
_NET_WM_MOVERESIZE_MOVE_KEYBOARD for operations that are not
initiated by a button-press event. Allow using these by passing
a button of 0 to gdk_window_begin_move/resize_drag.
The window-dragging code had a number of issues: The code was
starting a drag on every button press, never bothering to cancel
them. This leads to the odd hand cursor occurring between the two
clicks to maximize. We relied on GDK's multi-click detection, which
gives us triple-clicks when we really want sequences of double-clicks.
Lastly, we didn't propery restrict double-click handling to the primary
button, so e.g. if you had a window on an empty workspace, double-right
click on the titlebar would maximize it, which is not intended.
This commit solves all three problem by a doing our own double-click
detection, and only starting a drag when the pointer goes out of
'double-click range'. We change the way dragging is implemented for
menubars and toolbars to just letting events bubble up, so they
get the same behaviour as the titlebar. To make this work, we
have to select for pointer motion events in a few more places.
Two changes that sneaked in during the GtkApplication port
made it so that the window would not let you shrink it again
after you've made it larger. This also yielded very surprising
results when unmaximizing the window: it would come back to
have a minimum width slightly larger than the screen, making
maximization fail from then on.
The behaviour of gtk_text_view_add_child_in_window() used to be
quite broken. It scrolled with the window during scrolling, then
jumped to the absolute position when the widget resized. Furthermore,
in 3.10 we broke the first feature, making it always be fixed.
The "proper" way to handle this is to always follow scrolling. This
is what the only user so far (gedit) wants, and if you want some
kind of overlay you should use GtkOverlay instead.
So, this changes the behaviour to something that is internally consistent
and works. I.e. all added widgets scroll with the textview as needed.
https://bugzilla.gnome.org/show_bug.cgi?id=711826
Cook up some silly cases to test out the hidden-when='' attribute.
- make sure hidden-when='action-missing' shows/hides items based on
actions being created and destroyed
- make sure hidden-when='action-disabled' shows/hides items based on
actions being enabled and disabled
- make sure hidden-when='action-missing' doesn't hide items when the
action is merely disabled
https://bugzilla.gnome.org/show_bug.cgi?id=688421
Modify the tracker so that it manages the visibility of
GtkMenuTrackerItem by issuing insert and remove callbacks to the
user of the tracker.
This works by treating the GtkMenuTrackerItem as a virtual section which
contains 1 item when the item is visible and 0 items when it is hidden.
For efficiency reasons, we only employ this trick in the case that the
item has a hidden-when='' attribute set on it.
https://bugzilla.gnome.org/show_bug.cgi?id=688421
Add an internal API for checking if a GtkMenuTrackerItem is visible,
along with a signal for reporting changes in that flag. The item will
become invisible in situations according to the new hidden-when=''
attribute, which can be set to 'action-disabled' or 'action-missing'.
This new flag doesn't actually do anything yet, and none of the
consumers of GtkMenuTracker do anything with it (nor should they). A
followup patch will address the issue.
https://bugzilla.gnome.org/show_bug.cgi?id=688421
Refactor the code in the action observer remove function in order to
make way for the (efficient) handling of hiding of the item in the case
that hidden-when='' is given.
https://bugzilla.gnome.org/show_bug.cgi?id=688421
Strictly speaking, can_activate should always be set back to FALSE when
the action disappears from the muxer (since we can't activate it
anymore) but we forgot to do that.
This 'bug' could never cause a problem because 'can_activate' is never
directly queried for anything at all and the item would get marked
insensitive anyway. As soon as the action was re-added, can_activate
would be recalculated based on the new action before anything else could
happen.
All the same, this should be cleared here.
https://bugzilla.gnome.org/show_bug.cgi?id=688421
Remove a hash lookup from the separator sync logic (which is run every
time we change a menu). Instead, we do the lookup when creating the
section and cache the result.
This refactor will also help us in a future commit to add support for
hiding menu items based on missing actions.
https://bugzilla.gnome.org/show_bug.cgi?id=688421
This adds save/restore calls to the clear-to-transparent call in
the pixel cache, to avoid changing the default color of the
cairo_t. It also removes a call set_operator call that is no longer
necessary (it was trying to manually restore the state).
https://bugzilla.gnome.org/show_bug.cgi?id=721480
The signal callbacks are defined to take pointers as their arguments, but the
callbacks found in testsuite/gtk/builder.c are passing a GParamSpec by value
as the second argument. This confuses and angers the compiler on ppc64el,
resulting in segfaults after return from the function due to stack-smashing
by the (completely-unused) argument.
https://bugzilla.gnome.org/show_bug.cgi?id=721700
GtkApplicationWindow frees its internal action group on dispose for the
usual reasons: to avoid the possibility of reference cycles caused by
actions referring back to the window again.
Unfortunately, if it happens to be inside of a GtkActionMuxer at the
time that it is disposed, it will (eventually) be removed from the muxer
after it has been disposed. Removing an action group from a muxer
involves a call to g_action_group_list_actions() which will crash
because the internal action group to which we normally delegate the call
has been freed.
A future patch that reworks the quartz menu code will introduce a use of
GtkActionMuxer in a way that causes exactly this problem.
We can guard against the problem in a number of ways.
First, we can avoid the entire situation by ensuring that we are removed
from the muxer before we destroy the action group. To this end, we
delay destruction of the action group until after the chain-up to the
dispose of GtkWindow (which is where the window is removed from the
GtkApplication).
Secondly, we can add checks to each of our GActionGroup and GActionMap
implementation functions to check that the internal action group is
still alive before we attempt to delegate to it.
We have to be careful, though: because our _list_actions() call will
suddenly be returning an empty list, people watching the group from
outside will have expected to see "action-removed" calls for the
now-missing items. Make sure we send those. but only if someone is
watching.
https://bugzilla.gnome.org/show_bug.cgi?id=710351
A widget intended to offer contextual actions for a given view.
It allows packing children into the start or end as well as offering
a single centered child box.
https://bugzilla.gnome.org/show_bug.cgi?id=721665
Notifications can only be associated with application actions,
but clear is a window action. Introduce a "clear-all" action
that forwards to clear on all windows.
https://bugzilla.gnome.org/show_bug.cgi?id=721633
Add gtk_tree_path_new_from_indicesv which takes an array of
integers with a length. Use "Rename to" annotation to rename the
method as gtk_tree_path_new_from_indices. This is needed because
the original method takes variadic arguments which is not supported
by introspection.
https://bugzilla.gnome.org/show_bug.cgi?id=706119
GtkMenuItemAccessible was assuming that an accel label is
always the immediate child of a menu item. It also did not
deal with manually set accels. Fix both of these.
https://bugzilla.gnome.org/show_bug.cgi?id=721086
Improve the color swatch accessible to set a proper role
depending on whether the swatch is selectable or not, and
set the checked atk state when appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=721048
The initial state of GtkModelMenuItem is that of a normal menu
item, but the accessible we are using, GtkCheckMenuItemAccessible,
starts out with a role of 'check menu item'. Fix that up by
explicitly setting the initial accessible role.
GtkModelMenuItem does not emit the ::toggled signal when a radio
item is activated, so listen for property notification for that
property. We still keep the ::toggled signal handler, in order
to not break other uses of check and radio menu items.
https://bugzilla.gnome.org/show_bug.cgi?id=720983
GtkModelMenuItem emits no property notification, since none of its
properties are readable. But the toggled property is just a proxy
for GtkCheckMenuItem::active, so we should ensure that property
notification is emitted for the ::active property.
Ensure the hscrollbar & vscrollbar at gtk_scrolled_window_add() time,
this allows one to subclass GtkScrolledWindow with templates and add
children, as this will happen at instance initialization time before
the construct adjustment properties take effect.
And update the colorchooser a11y test to a) use GtkColorChooser
instead of the deprecated GtkColorSelection and b) match this
change. Pointed out in
https://bugzilla.gnome.org/show_bug.cgi?id=721045
fvwm seems to have problems keeping _NET_WORKAREA in sync with
the number of desktops. Instead of reading garbage, silently use
the full screen as workarea for desktops that are not covered
by the _NET_WORKAREA property.
https://bugzilla.gnome.org/show_bug.cgi?id=698248
This commit makes the label accessible implement AtkHypertext,
which returns a AtkHyperlink object for each link in the text.
At the same time, add AtkHyperlinkImpl objects as children
to the label accessible.
Also some private API to indicate that links have changed, and
call that from GtkLabel when needed.
Adjust expected output of the affected a11y tests.
https://bugzilla.gnome.org/show_bug.cgi?id=721410https://bugzilla.gnome.org/show_bug.cgi?id=721421
The get_end_index implementation was casting the accessible
to AtkText even though GtkLinkButtonAccessible does not
implement this interface. This did not show up in the a11y
tests because the they were not dumping the affected AtkHyperlinkImpl
properties. Oops.
Ignacio Casal Quinteiro reported a problem whereby an empty section at
the start of a menu has a separator placed after it. This was caused by
the implementation of the logic that separators should be inserted at
the top of all non-empty sections that are not the first section. This
logic is obviously incorrect in the case that the first section is empty
(in which case we would not expect to see a separator at the top of the
second section).
Change the logic so that we only insert separators when we see a
non-zero number of actual items in the menu before us.
https://bugzilla.gnome.org/show_bug.cgi?id=721119
When not doing cross-builds, use the values of CFLAGS, CPPFLAGS and
LDFLAGS as the default value for CFLAGS_FOR_BUILD, CPPFLAGS_FOR_BUILD
and LDFLAGS_FOR_BUILD, respectively.
This avoids having to manually specify these variables in order to get
extract-strings to build properly.
This should really be handled by ax_prog_cc_for_build.m4. That has been
reported upstream. This is a workaround for now.
https://bugzilla.gnome.org/show_bug.cgi?id=721346
If the platform data passed with actions and activations includes
a startup notify ID, we should read it and pass it down to GDK.
This ensures that the right startup notify is completed after the
signal emission, and that the user time of the GdkDisplay is properly
updated (which in turn makes sure the windows are not subjected
to focus-stealing-prevention)
https://bugzilla.gnome.org/show_bug.cgi?id=721304
Add a utility project to get config.h and gdkconfig.h from their *.h.win32
(or win32_broadway, if applicable) counterparts, using custom build rules,
so that these "generated" files can also be removed on clean and
"regenerated" upon update. This also enables the removal of configs in
certain projects that isn't really needed as a result.
Also update and merge the projects and property sheets to include a single
property sheet that it needs, which will then in turn include the other
property sheets that is needed, so that things are cleaner.
Add a utility project to get config.h and gdkconfig.h from their *.h.win32
(or win32_broadway, if applicable) counterparts, using custom build rules,
so that these "generated" files can also be removed on clean and
"regenerated" upon update. This also enables the removal of configs in
certain projects that isn't really needed as a result.
Also update and merge the projects and property sheets to include a single
property sheet that it needs, which will then in turn include the other
property sheets that is needed, so that things are cleaner.
Updates to the Visual Studio 2010 projects will follow later.
This header, which is not universally available, is accidently made to be
included unconditionally during the refactoring of gtkapplication.c,
so restore the #ifdef check.
Applications need a way to fix or adapt the decoration layout,
for situations like split header bars. Setting the layout from
the theme with a style property did not offer a good way to do
this, and the ::show-close-button property does not provide
fine-grained control.
To improve the situation, move the layout string to a property of
GtkHeaderBar which is backed by a setting. This allows platforms to
set a default button layout independent of the theme, while applications
can override the default.
The style GtkWindow style property is now deprecated and ignored.
The button now claims its menu as a child for a11y purposes,
which makes it possible for ATs to see it when the navigate
the tree top-down.
Update the a11y test to match.
We go to extra length to set the desktop_uri to NULL when
desktop == home, but then we were adding the (non-functional)
place item anyway. Don't do that.
A number of C99 math.h functions, along with inttypes.h were included for
Visual C++ 2013, along with much improved C99 capabilities, so update
config.h.win32.in to reflect this.
Fixes a tiny typo in commit f51c9d4154
which manifested itself in GtkSpinButton's panels being drawn with an
incorrect, not updated state.
This patch took me more hours than you might think! :P
https://bugzilla.gnome.org/show_bug.cgi?id=709491
The reason why some of the strings in gtkprintunixdialog.ui
were missing is that we did not extract translatable string
from <item> elements. Fix that.
gtkapplication.c has turned into a bit of an #ifdef mess over time, and
many of the current checks are incorrect. As an example, if you build
Gtk for wayland, and exclude the X11 backend, much of the functionality
required by wayland (such as exporting menu models) will be disabled.
Solve that by introducing a backend mechanism to GtkApplication (named
GtkApplicationImpl) similar to the one in GApplication. Add backends
for Wayland, X11 and Quartz, with X11 and Wayland sharing a common
'DBus' superclass.
GtkApplicationImpl
|
/--------------+-------------------\
| |
GtkApplicationImplDBus GtkApplicationImplQuartz
|
/-----------+-----------------\
| |
GtkApplicationImplX11 GtkApplicationImplWayland
GtkApplicationImpl itself is essentially a bunch of vfuncs that serve as
hooks for various things that the platform-specific backends may be
interested in doing (startup, shutdown, managing windows, inhibit, etc.)
With this change, all platform specific code has been removed from
gtkapplication.c and gtkapplicationwindow.c (both of which are now free
of #ifdefs, except for a UNIX-specific use of GDesktopAppInfo in
gtkapplicationwindow.c).
Additionally, because of the movement of the property-setting code out
of GtkApplicationWindow, the _GTK_APPLICATION_ID properties (and
friends) will be set on non-GtkApplicationWindows, such as dialogs.
https://bugzilla.gnome.org/show_bug.cgi?id=720550
Since update_windows list is a static variable in GdkWindow.c which
contains pointers to windows which needs to be updated, it can happen
that it contains a pointer to a window even after quit from a gtk_main().
If another gtk_main() is called in the same process it tries to process
windows in the list which leads to a crash.
Correct reference count handling of added windows prevents such applications
from crash.
https://bugzilla.gnome.org/show_bug.cgi?id=711552
We don't want the maximum size to be smaller than the minimum size. Not
just because it's wrong but also because when this happens the rest of
GTK gets mighty confused and infloops resizing to min-size and
max-size in turns causing a flickering window. Well, at least if you
run X without a window manager. Or your window manager hasn't finished
starting up.
Private RHEL bug finding this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1035409
This could happen if data was requested from a separate screen now that
multi-screen is no longer supported.
Ideally, we'd want to support copying to other screens, but that
requires solving in GDK as that's X-specific so cannot be well
abstracted by GDK (without the reintroduction of multiple screens).
https://bugzilla.gnome.org/show_bug.cgi?id=719314
Both GtkApplicationWindow and GtkHeaderBar listen for changes
of the gtk-shell-shows-app-menu setting, so they need to somehow
coordinate who is going to take action and show a fallback.
We prefer the menu button in the title over the menubar, so
let GtkApplicationWindow opt out if it finds that the header bar
has been configured to show window controls.
If we don't have a window icon, we hide the titlebar_icon,
we still add it, so we can't simply go by the number of
children when deciding whether to show the separator or
now. Instead, update the separator visibility as we create
the various buttons.
And deprecate the X11-specific version of it.
We call this new API _set_shadow_width() and not _set_frame_extents()
because we already have a gdk_window_get_frame_extents() with a
different meaning and different type of value.
https://bugzilla.gnome.org/show_bug.cgi?id=720374
Turn this into a GtkApplication with an app menu.
Allow to override the gtk-shell-shows-app-menu setting
and the decoration-button-layout style property.
This is one of the few cases where it makes some sense to blur
the line between and empty string and NULL: without this, it is
hard to reset the subtitle e.g. from a builder file. And we
have the has-subtitle property now to enforce subtitle size
allocation independently.
Only fill the location entry with the file name of the tree view's
selected file when the selection was done by the user.
When the file chooser's action is GTK_FILE_CHOOSER_ACTION_OPEN, it
selects the first file in the tree view once loading has finished. For
this case we don't want it to insert the file name in the location
entry, as it hinders efficient navigation using the location entry. To
achieve this, use a priv flag to keep track of whether the
selection-changed signal was caused by the file chooser itself.
https://bugzilla.gnome.org/show_bug.cgi?id=386569
Now that the nice titlebar example is in gtk3-demo, we can
use testtitlebar as an actual testbed for headerbar stuff.
This immediately reveals size allocation issues when titlebar
widgets change size.
It is a fairly common case to just want a title, and not
reserve extra space for a subtitle. This is much easier
to get right by setting a boolean property than by
constructing a custom title widget.
When setting a custom titlebar that happens to be a GtkHeaderBar,
we connect to notify::title to pick up title changes on the headerbar,
but we forgot to sync the title initially. Fix that.
You can still hover a mouse on insensitive elements; it's up to the
theme to disable that.
This is in line with the HTML/CSS interpretation of :hover.
Insensitive elements still cannot be clicked.
https://bugzilla.gnome.org/show_bug.cgi?id=719486
Failing to load a thumbnail returns a NULL pixbuf. Since the hidpi
patches this wasn't checked when creating the surface. Result: assertion
failure.
https://bugzilla.gnome.org/show_bug.cgi?id=719977
This demo condenses the essentials of advanced management of
input events. Depending on the information available in input events,
this demo will try to represent as much information as possible for
those.
https://bugzilla.gnome.org/show_bug.cgi?id=719987
The focus handling code is shared between core and XI2 implementations,
so just handle the extra XI2 types for passive grabs. Those must be dealt
with in the same way than active grabs. Focus events with this crossing
mode could happen currently through the XIGrabFocusIn passive grab.
https://bugzilla.gnome.org/show_bug.cgi?id=719762
This fixes potential assertions if a GTK+ app gets to receive
a XINotifyPassiveGrab/Ungrab pointer crossing event, currently
triggerable by XIGrabEnter passive grabs.
http://bugzilla.gnome.org/show_bug.cgi?id=719762
The bin window's background would have to be drawn in the bin window's
size and inside the pixel cache draw function to not cause transparency
issues.
But because it's unnecessary as the view window draws the same
background, we just skip it.
https://bugzilla.gnome.org/show_bug.cgi?id=709027
...for all files except the README.txt and the .sln files, which have to
have DOS/Windows line endings. This makes application of patches, when
applicable, easier.
Make sure that the tests don't access the host's session bus or
installed gsettings schemas.
Also disable tests for some classes that leak a connection to the
session bus.
https://bugzilla.gnome.org/show_bug.cgi?id=711715
This allows themes do whatever they want as separators, with
paddings, borders and backgrounds.
If "wide-separators" property is true, then, instead of just draw
a frame, also render its background, and take into account the
padding property for its limits.
https://bugzilla.gnome.org/show_bug.cgi?id=719713
g_file_new_for_uri() is guaranteed to return a non-NULL value, so this
check was redundant, and was confusing the static analyser into
returning a false positive, where it thought the file could be NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=712760
At this point, segments[1] is always uninitialised, and is used to
initialise itself. Looking at the code in the branch above, this appears
to have been a typo from segments[0], as segments[1] seems to typically
be 2 * segments[0].
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=712760
When animation is disabled, we use 'none' as the effective
transition type. So far, this transition type failed to change
the size request, causing the revealer to always take up the
space of the child, even when the child is not shown.
https://bugzilla.gnome.org/show_bug.cgi?id=719568
Use (out caller-allocates) annotation for the "value" argument to
GtkTreeModelFilterModifyFunc. This is needed because GI based language
bindings coerce GValue input args into native types and there is no
opportunity to set the value within the GValue itself.
https://bugzilla.gnome.org/show_bug.cgi?id=719460
The call to gtk_button_set_relief() in gtk_toolbar_init() indirectly
used the style context of the half-created widget, before we had a
chance to add the "toolbar" style class to it.
Reorder gtk_toolbar_init() to ensure that the proper style class is
set first.
https://bugzilla.gnome.org/show_bug.cgi?id=719595
When enable-animations is false, the revealer's child-revealed property is
notified immediately, so make sure to connect to it before toggling the
revealer.
https://bugzilla.gnome.org/show_bug.cgi?id=719510
Win32 does not have alpha channel currently ; fix the check
for this, so trying to enable CSDs on this platform will
not "succeed" and crash the app anymore.
Partially fixes gtk3-widget-factory.
Since commit 7c2a5072 the gtkdbusgenerated.[c|h] are not included in the
dist tarball and thus have to be generated, which broke the Visual C++
builds.
This patch adds property sheets and custom build rules for the Visual C++
projects so that gtkdbusgenerated.[c|h] will be generated upon building the
GTK+ DLL sources.
This also tells people building GTK+ from the projects that they need to
have Python 2/3 installed and the Python interpretor needs to be in their
PATH before building GTK+ from the projects.
-Improve optimization a bit for broadwayd, by enabling link time code
generation
-Add PlatformToolset tag for the Visual C++ 2010 projects, to ease
transition to Visual C++ 2012/2013
Ignore the "show-desktop" property on GtkPlacesSidebar for the
defaultvalue test.
Currently, "make check" is passing because it runs the test under a xvfb
with no XSETTINGS provider, so we see the Gtk default value. No matter
what we set the default value to in Gtk, however, there will be some
desktop environment in which someone running the installed test outside
of an xvfb will get the wrong result. Best to ignore it.
https://bugzilla.gnome.org/show_bug.cgi?id=712302
Change the GtkSettings default for "shell-shows-desktop" back to TRUE
and also change the default value of the "show-desktop" property on
GtkPlacesSidebar so that the defaultvalue test passes.
https://bugzilla.gnome.org/show_bug.cgi?id=712302
This is so we always have the latest information given by XRandR (or other), and not
rely on Core protocol information that might not have been updated yet.
This is specially visible when a monitor is connected (less frequent) or disconnected
(much more frequent), callbacks on GdkScreen::monitors-changed that call
gdk_screen_get_width/height() could get the screen size previous to the monitor
rearrangement.
So in order to fix this, keep track of the latest monitors information, and calculate
the bounding box in order to know the screen size.
https://bugzilla.gnome.org/show_bug.cgi?id=715029
Return values of g_variant_get_child_value() were not unreffed
correctly together with one value returned by g_variant_get().
Use g_variant_get_data() instead of copying each byte separately.
https://bugzilla.gnome.org/show_bug.cgi?id=712799
Instead, use the monitor's work area.
This might have unforseen side effects that warrant a later revert, such
as:
- Apparently some WMs assume maximizing when a window is maximum screen
size.
- WMs might not shrink the window by the decorations' size when it tries
to be fullscreen.
- Applications might have buggy size request code that causes weirdly
sized windows.
Scroll valuators were being just appended again and again, leading
to 1) a growing memory issue anytime a device changed 2) the first
scroll valuators to stay permanent on the application lifetime, as
the first stored valuators would always match.
https://bugzilla.gnome.org/show_bug.cgi?id=705203
Use info available in Avahi TXT records for creation of gtk printer
and request details when needed (through gtk_printer_request_details()).
If there is a printer advertised on Avahi by a remote CUPS server
try to get its PPD file at first or get its capabilities through an IPP
request if it fails.
https://bugzilla.gnome.org/show_bug.cgi?id=712751
When downscaling images, Cairo apparently uses algorithms different
enough to make this test trip over. So add the downscaled image as the
reference instead of downscaling the previous reference image.
Fixes the border-image reftest. For real now.
The new downscaling code in Cairo doesn't allow this test, so we remove
the CSS that made the border downscaled.
So the test does test less now, but it still tests the repeat modes of
border images.
Passive grabs may take pointer focus out of the application, even though
the pointer didn't leave the window, but those events still trigger resetting
of the scroll axes. This is most visible with compiz, and possibly other
reparenting WMs, where passive grabs happen on the WM-managed window that
is a parent of the application toplevel.
As it is not possible to have scrolling happening on the timespan a passive
grab takes action, it is entirely safe for GTK+ to assume none happened if
it gets a crossing event of that nature.
https://bugzilla.gnome.org/show_bug.cgi?id=699574#c33
One requirement of .ui files is that each object must have an ID,
even if it is never referred to or directly loaded from the code.
This makes editing .ui files much more onerous than it has to be,
due to the frequent need to invent new IDs, while avoiding
clashes.
This commit makes IDs optional in the XML. They only need to
be provided for objects which are referred to or explictly loaded
from the code. Since GtkBuilder needs IDs for its own internal
accounting, we create IDs of the form ___object_N___ if not
specified in the XML.
https://bugzilla.gnome.org/show_bug.cgi?id=712553
This information will be useful in case someone stumbles on a situation
similar to https://bugzilla.gnome.org/show_bug.cgi?id=699574, so we can
figure out where do the crossing events come from or go to easily.
It's been reported in several applications that scrolling feels jerky
since commit cc7b3985b3.
Investigation reported that the combination of passive 4-7 button grabs
on the toplevel and the presence of native subwindows might trigger
too often crossing events from the child window to the toplevel and
back as scroll "buttons" trigger the passive grab. Those crossing events
would reset the scroll valuators rendering scrolling from jerky on
touchpads (where there's intermediate smooth events between the emulated
button ones) to ineffective on regular mouse wheels (where the crossing
event would reset the valuators right before the single smooth scroll
event we get is delivered)
So, only reset scroll valuators when the pointer enters the toplevel
(we only care about this when the pointer is on the window after it's
been possibly scrolling somewhere else), and it doesn't come from an
inferior.
The situations where this happened varied though, the native subwindow
could be one created explicitly by the application, or created indirectly
through gdk_window_ensure_native(). The latter was mainly the case for
evolution (through gtk_selection_set_owner()) and any GtkScrolledWindow
under the oxygen-gtk3 theme (through gdk_window_set_composited())
https://bugzilla.gnome.org/show_bug.cgi?id=699574
When the menubar inserted by GtkApplicationWindow is the widest
widget in a csd window, its allocation gets cut short. Fix this
by taking the decoration size into account while calculating
the size request (it is implicitly taken into account in the
size allocation phase by _gtk_window_set_allocation).
Do the menubutton for app menu fallback ourselves in GtkWindow
for the csd, non-custom titlebar case. This fits better with
the way we handle other title buttons. Themes have control
over the placement of this button by placing menu in the
decoration-button-layout style property.
Make the sunny example useful by giving it a header bar
with app menu fallback. To test this under gnome-shell,
set APP_MENU_FALLBACK=1 in the environment.
Allow showing the fallback app menu with a menu button
in the header bar. Applications have to explicitly enable
this by calling gtk_header_bar_set_show_fallback_app_menu.
GtkAboutDialog highlights emails written as <...> and
urls written as http://... . gnome-terminal manages to
put <http://...> into its license text, which sadly
confuses the parser into running evolution on http://...
Fix things up far enough that <http://...> is now
recognized as url, and only the part inside the <> is
underlined (for email addresses, we include the <> in
the underline).
Commit 719dd636a9 replaces
margin-left/right with margin-start/end. CSS does not have
margin-start/margin-end properties, the sed script was a bit overeager.
Fwiw, CSS implements RTL margin styling via :dir(rtl) selectors.
Add margin-{start,end} and gtk_widget_{get,set}_margin_{start,end}
and drop margin-{left,right} and gtk_widget_{get,set}_margin_{left,right}.
margin-{start,end} handle right also in RTL.
https://bugzilla.gnome.org/show_bug.cgi?id=710238
Add a GtkSetting for whether the desktop shell is showing the desktop
folder icons.
This is on by default because most desktop shells do show the icons on
the desktop. We already have a patch in gnome-settings-daemon to bind
this to the org.gnome.desktop.background show-desktop-icons GSettings
key which is off by default on GNOME.
https://bugzilla.gnome.org/show_bug.cgi?id=712302
Printing a file with to PDF/etc. with the virtual printer option doesn't add
the file to the list of recently used files. It should be there, so I can
easily access it.
https://bugzilla.gnome.org/show_bug.cgi?id=668598
We add a custom im module for broadway that calls some broadway
specific APIs to show/hide the keyboard on focus in/out. We then forward this
to the browser, and on the ipad we focus an input field to activate
the keyboard.
gtk_menu_tracker_add_items() fetched the action-namespace from the menu
item, but didn't pass it into gtk_menu_tracker_section_new() when its
internal namespace was still NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=712164
The broadway backend would move the focus from one window to another based on
where the mouse was (i.e. 'focus-follows-mouse' approach). Handling the focus
this wait didn't play well with widgets which rely on focus-in-event and
focus-out-event, like the GtkEntry when using a completion popup window, see
e.g:
https://bugzilla.gnome.org/show_bug.cgi?id=708984
So instead, setup broadway to require a click in a window to move the focus
(i.e. 'click-to-focus' approach):
* The implicit GDK_FOCUS_CHANGE events that were generated upon reception of
BROADWAY_EVENT_ENTER or BROADWAY_EVENT_LEAVE are removed.
* The broadway daemon will now keep track of which is the focused window
* Whenever the daemon detects an incoming BROADWAY_EVENT_BUTTON_PRESS, it will
trigger the focused window switch, which sends a new BROADWAY_EVENT_FOCUS to
the client, specifying which windows holds the focus.
* Upon reception of a BROADWAY_EVENT_FOCUS, the client will generate a new
GDK_FOCUS_CHANGE.
* gdk_broadway_window_focus() was also implemented, which now requests the
focus to the broadway server using a new BROADWAY_REQUEST_FOCUS_WINDOW.
This is based on an initial patch from Aleksander Morgado <aleksander@lanedo.com>.
If a motion event handler (or other handler running from the flush-events
phase of the frame clock) recursed the main loop then flushing wouldn't
complete until after the recursed main loop returned, and various aspects
of the state would get out of sync.
To fix this, change flushing of the event queue to simply mark events as
ready to flush, and let normal event delivery handle the rest.
https://bugzilla.gnome.org/show_bug.cgi?id=705176
Don't recurse the mainloop in _gtk_tree_view_column_start_drag().
It doesn't serve any discernible purpose, and recursing the
mainloop from the flush-events phas of the frame clock breaks
frame synchronization with mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=705176
If a queue_redraw() (invalidating a region, or the whole widget) was
called from the draw() call, it could get ignored if surface_dirty
existed, as it would then be updated, but destroyed right at the end of
the _gtk_pixel_cache_repaint(), leading the next call to
_gtk_pixel_cache_draw() have its call to repaint() be a no-op
(since there's no surface_dirty) and then simply draw from (non
updated) surface.
Signed-off-by: Olivier Brunel <jjk@jjacky.com>
https://bugzilla.gnome.org/show_bug.cgi?id=711545
Arrange for the scales to control the speed of the activity
mode progress bar in gtk3-widget-factory. This will be useful
in demonstrating smoother progress bar animation in the future.
Add an application shortcut for the Music folder in testfilechooser.
The file chooser used to filter duplicates out, but this broke
in the sidebar merge.
currently it's using the same sizes for natural and minimum, but it
happens that, when it's allowed to use the arrow, the minimum size
can be smaller than natural.
https://bugzilla.gnome.org/show_bug.cgi?id=693227
Although I can't find explicit documentation for clipboard pointer, it
seems to be possible to modify clibpoard memory without side-effects.
According to MSDN,
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366596%28v=vs.85%29.aspx
"The global and local functions are supported for porting from 16-bit
code, or for maintaining source code compatibility with 16-bit
Windows. Starting with 32-bit Windows, the global and local functions
are implemented as wrapper functions that call the corresponding heap
functions using a handle to the process's default heap."
"Memory objects allocated by GlobalAlloc and LocalAlloc are in private,
committed pages with read/write access that cannot be accessed by other
processes. Memory allocated by using GlobalAlloc with GMEM_DDESHARE is
not actually shared globally as it is in 16-bit Windows. This value has
no effect and is available only for compatibility. "
https://bugzilla.gnome.org/show_bug.cgi?id=711553
Setting event compression to false will allow inter-frame
mouse motion events to be delivered, which are necessary
for painting applications to produce smooth strokes.
https://bugzilla.gnome.org/show_bug.cgi?id=702392
This is based on the rolling hashes code from
http://cgit.freedesktop.org/~krh/weston/log/?h=remote
It works by incrementally calculating hashes for every 32x32 block
in each frame sent, and then refering back to such blocks when
encoding the next frame. This means we detect when a block matches
an existing block in the previous frame in a different position.
This is great for detecting scrolling, which we need now that
the gdk level scrolling is neutered.
* gtk/gtkprintunixdialog.c (printer_status_cb): Do not reset the
waiting_for_printer on status change as the default printer might
get added later.
https://bugzilla.gnome.org/show_bug.cgi?id=577642
Call gtk_cell_layout_clear() on the area instead of the completion in
gtk_entry_completion_clear_text_column_renderer(), because it is also
called from within gtk_entry_completion_clear().
gtk_entry_completion_set_text_column() always added a cell renderer,
regardless of whether there was an existing one already installed. This
patch reuses an old renderer if it exists, but only if it was added by a
previous call to this function.
To avoid conflicts, all renderers that were added manually are removed
when calling this function. Also, the renderer added by this function is
removed when manually adding new renderers. This effectively gives
GtkEntryCompletion two modes (managed and manual cell renderers) and
allows seamless switching between the two.
This is a minor API break. However, this shouldn't be an issue in
practice as applications couldn't call set_text_column() more than once
because of this bug. Also, it is unlikely that many applications mix
set_text_column() and custom cell renderers. The interaction between the
two modes was erratic and not documented well.
https://bugzilla.gnome.org/show_bug.cgi?id=635499
Call gtk_entry_completion_set_text_column() when setting the
"text-column" property directly.
The completion appeared empty when setting "text-column" directly (for
example from a GtkBuilder file), because the setter creates and adds the
GtkCellRendererText.
https://bugzilla.gnome.org/show_bug.cgi?id=710533
The MINMAXINFO struct was being populated based upon geometry hints when
GDK_HINT_MAX_SIZE flag was enabled, then promptly having its values blown
away with default values.
https://bugzilla.gnome.org/show_bug.cgi?id=711110
_gtk_widget_draw_internal() was clipping by passing the subwindow
sizes as a path to cairo_clip(). This was breaking for windows
larger than 23 bits in width/height, due to cairo using fixed point
(24.8) for the path coordinates.
We fix this by pre-clipping the subwindow region to the existing
cairo clip region in the full 32bit gdkwindow precision. This fixes
the GooCanvas Large Items test.
https://bugzilla.gnome.org/show_bug.cgi?id=710958
I have been convinced that it is a bad idea to change the behaviour
at the same time as deprecating it, so go back to respecting the
Gtk/ButtonImages xsetting in buttons created with
gtk_button_new_from_stock() when it is set.
The setting as well as the function are still deprecated, and the
default value of the setting will remain FALSE.
I have been convinced that it is a bad idea to change the behaviour
at the same time as deprecating it, so go back to respecting the
Gtk/MenuImages xsetting in GtkImageMenuItem when it is set.
The setting as well as the widget are still deprecated, and the
default value of the setting will remain FALSE.
Since 49c4ad2f the order between "Page_Down" & "Next" had been changed (due to
sorting) and this resulted in the Page Down key being identified as "Next"
instead of "Page_Down"
"Page_Up" wasn't affected, since it comes before "Prior"
Signed-off-by: Olivier Brunel <jjk@jjacky.com>
https://bugzilla.gnome.org/show_bug.cgi?id=710411
For some widgets, like GtkTreeView, which setup a clock frame
update during realize, it was possible to call
gdk_frame_clock_begin_updating() twice, but only ever disconnecting
from it once. This happens because the realized flag is set at an
unpredictable time by the GtkWidget's realize implementation.
Keep the signal handler ID from us connecting to the "update" signal
to avoid connecting to it twice.
This fixes high wake-up count from any application using GtkTreeView,
even idle ones.
https://bugzilla.gnome.org/show_bug.cgi?id=710666
This is what we used to get through the Net/FallbackIcontheme
setting. Nobody has ever set this setting to a different value,
and people have come to rely on GTK+ applications getting their
icons this way.
The objective is simplify the semantics of the code so that we don't
need to check for "(iter != NULL && !g_sequence_iter_is_end (iter))"
in the callers.
When doing fallback for symbolic icons, we first shorten
the name at dashes while preserving the -symbolic suffix.
But after exhausting that, we should also try stripping
the suffix.
https://bugzilla.gnome.org/show_bug.cgi?id=708163
When showing a tooltip on the edge of a monitor, the tooltip could be wrongly
placed and be shown going from one monitor to the next.
This happened because the current_window wasn't set visible, and when it wasn't
the returned allocated size would be 1, hence wrong calculations.
Signed-off-by: Olivier Brunel <jjk@jjacky.com>
https://bugzilla.gnome.org/show_bug.cgi?id=698730
Some symbols in the generated Wayland code were getting
decorated with WL_EXPORT, causing them to show up in the
libgdk exports. We don't want that.
https://bugzilla.gnome.org/show_bug.cgi?id=710141
We may get a NULL region passed to the backend, which means
'nothing is opaque'. In that case, don't crash, but pass
the information on to the compositor.
http://bugzilla.gnome.org/show_bug.cgi?id=709854
Rework how accels are handled on GtkApplicationWindow.
Instead of having GtkApplication fill the GtkAccelMap which is then used
by GtkApplicationWindow to create a GtkAccelGroup filled with closures
that is then associated with the window, do it directly.
GtkApplication now keeps a list of accels and their actions.
Accelerators on a GtkApplicationWindow ask GtkApplication to execute the
appropriate action.
This saves a fair bit of complexity and memory use (due to not having to
create all those closures and accelmap entries). The new approach also
supports multiple accels per action (although there is not yet a public
API for it).
This patch (and the ones before) Reviewed and ACK'd by Matthias Clasen.
Add support for pulling the primary accel out of the GtkActionMuxer.
With this change, it is no longer necessary to have the accel=''
attribute hardcoded onto each menu item (and, in fact, it should be left
off if you intend to have support for dynamic accelerator changing).
Specifying accel='' is a good way to force an accelerator not to be
displayed on a menu item.
Store "action and target" format inside each GtkMenuTrackerItem. This
makes action invocation more efficient (no hash table lookups or
allocations) and slightly simplifies handling of action namespace.
More importantly, this will be used when we start to get accels from
GtkActionMuxer.
Reuse the existing infrastructure in GtkActionMuxer for propagation of
accelerator information: in particular, what accel label ought to appear
on menu items for a particular action and target.
This is a good idea because we want accels to travel along with the
actions that they're tied to and reusing GtkActionMuxer will allow us to
do that without creating another hierarchy of a different class for the
sole purpose of filling in accel labels on menu items.
Doing it this ways also allows those who copy/paste GtkActionMuxer to
insert the accels for themselves.
Add a new method on the GtkActionObserver interface to report changes.
This patch introduces a new concept: "action and target" notation for
actions. This format looks like so:
"'target'|app.action"
or for non-targeted actions:
"|app.action"
and it is used over a number of possible alternative formats for some
good reasons:
- it's very easy to get a nul-terminated action name out of this format
when we need it, by using strrchr('|') + 1
- we can also get the target out of it using g_variant_parse() because
this function takes a pointer to a 'limit' character that is not
parsed past: we use the '|' for this
- it's extremely easy to hash on this format (just use a normal string
hash) vs. attempting to hash on a string plus a GVariant
A close contender was to use detailed action strings here, but these are
not used for two reasons:
- it's not possible to easily get the action name or target out of the
strings without more work than the "action and target" format
requires
- we still intend to use detailed action strings on API (since they are
a lot nicer to look at) but detailed action strings can be given in
non-canonical forms (eg: 'foo::bar' and 'foo("bar")' are equivalent)
so we'd have to go through a normalisation step anyway. Since we're
doing that already, we may as well convert to a more convenient
internal format.
This new "action and target" format is going to start appearing in a lot
more places as action descriptions are introduced.
I suspect that nobody is using '|' in their action names, but in case I
am proven wrong, we can always switch to using something more exotic as
a separator character (such as '\x01' or '\xff' or the like).
Previously, GtkWindow would add the "app" action group to its own
toplevel muxer.
Change the setup so that GtkApplication creates the toplevel muxer and
adds itself to it as "app". Use this muxer as the parent muxer of any
GtkWindow associated with the application.
This saves a small amount of memory and will allow for accels to be
propagated from the application through to all of the windows.
With the stock system being deprecated now, we should provide
meaningful accessible names for buttons that are constructed
from icon names or GIcons. This commit reuses the existing
translations.
It is possible that some common icon names are not covered
here because they were not present as stock items. These can
be added to the table later.
Discovered via a crash because b's (dest's) toplevel was NULL;
ensuring that the dest is actually a GdkWindow or setting b to NULL
prevents that path from being taken.
Spinners are essentially animated symbolic icons. We don't really
want them being rendered to arbitrary sizes. Also the current
technique for rendering the activity is not suitable for larger
sizes. Until we have a better technique we should limit the size
to the MENU icon size or exactly twice that size.
The 'direction' parameter to gtk_widget_keynav_failed() is based on
gtk_list_box_move_cursor()'s 'count' parameter. However if the passed
in movement is GTK_MOVEMENT_DISPLAY_LINES, 'count' is modified by
the keynav handling and will always be 0. To avoid messing up the
'direction' parameter, use a local variable for keynav handling and
leave 'count' untouched.
https://bugzilla.gnome.org/show_bug.cgi?id=709687
Previous commit wrongly identified "active" as containing the new
value. Instead, applications must determine the new value to
update the model with manually based on the value currently in the
model.
Clarify that applications are expected to handle updating the model
from the 'active' property, like GtkCellRendererText does for the
'edited' property.
This test demonstrates that various deprecated ways
to construct buttons and menuitems still work as they
are supposed to, including always-show-image functionality.
If a range goes all the way to the edge of the screen then we don't
have any way to activate autoscrolling. By adding a small region
at the ends of the range we can handle this case. This is the same
approach used in treeviews.
If we're going to run off the end due to an invalid message,
we're going to run off the end. We'll protect this by doing
proper bounds checking in the future, but the malloc gives
us nothing for now.
The newly-added gtk_flow_box_child_is_selected() needed to return a
gboolean, so use g_return_val_if_fail() to return FALSE when an invalid
GtkFlowBoxChild* is passed in.
Make flowbox selection more orthodox. Control and Shift now
modify the selection behaviour pretty much in the same way
they do in a tree view, and clicking without modifiers will
clear the selection.
When dealing with touch devices, we treat modifier-less events
as modifying the selection.
This commit also adds a few other selection necessities, such
as catching Escape key presses to cancel rubberband selection,
and handling grab notify.
GtkFlowBox is a container that its children in a reflowing
grid, which can be oriented horizontally or vertically.
It is similar to GtkListBox in that the children can
be sorted and filtered, and by requiring a dedicated child
widget type, GtkFlowBoxChild. It is similar to GtkTreeView
in that is supports a full set of selection modes, including
rubberband selection.
This is the culmination of work that has happened in the
egg-list-box module, and earlier in libegg. The origins of
this code are the EggSpreadTable in libegg, which was written
by Tristan van Berkom. It was moved to egg-list-box and
renamed EggFlowBox by Jon McCann, and I gave it some finishing
touched in the flowbox-improvements branch of that module.
Previously, the "Places" sidebar was populated by the update_places()
call from within gtk_places_sidebar_style_set(). After
742a2f11a9, update_places() is never called
and the sidebar is never populated unless gtk_places_sidebar_add_shortcut()
happens to be called. This commit fixes this by calling update_places()
at the end of gtk_places_sidebar_init().
https://bugzilla.gnome.org/show_bug.cgi?id=709522
The docs for GtkPlug/GtkSocket were not generated if any
of the win32, quartz, wayland backends were enabled. What
we really mean though, is that we want the docs to be generated
whenever GtkPlug/GtkSocket are included in the library, which
is when the x11 backend is enabled.
As long as we are not ready to switch over the default backend,
arrange ./configure without explicit backend options makes the
x11 backend mandatory and the wayland backend optional (depending
on whether we find Wayland dependencies).
http://bugzilla.gnome.org/show_bug.cgi?id=709212
GtkWidget had a hack where if opacity is 0.999 we set up an opacity group when
rendering the widget. This is no longer needed in 3.10, and GtkStack doesn't
use it anymore.
GdStack is using it, so applications should be ported from GdStack to GtkStack
in 3.12.
https://bugzilla.gnome.org/show_bug.cgi?id=703603
Resize modes don't work anymore, both because nobody ever uses them and
because the frame clock changed the way things work quite a bit. So we
don't want to advertise them as a good idea.
https://bugzilla.gnome.org/show_bug.cgi?id=708787
Add a has-tab-gap style property to GtkNotebook so that we can
disable drawing the gap between tabs and the page in the Adwaita
theme without breaking existing themes.
https://bugzilla.gnome.org/show_bug.cgi?id=707920
GtkSourceView draws before chaining upo to GtkTextView and assumes
that this will be visible, but the pixelcache will just overdraw
that with background.
So, we stop drawing the background to the pixel cache and instead
make it an CAIRO_CONTENT_COLOR_ALPHA surface to make the previously
drawn content see through.
This is slower, but more backwards compatible.
https://bugzilla.gnome.org/show_bug.cgi?id=708423
Previously, we were showing and hiding the custom titlebar
widget in response to state changes such as maximization.
Instead, use gtk_widget_set_child_visible() and leave
show/hide to applications. This makes it possible to set
a custom titlebar and hide it, for a titlebar-less appearance.
https://bugzilla.gnome.org/show_bug.cgi?id=707132
When loading a symbolic icon, g_file_get_contents() is currently used
with the icon pathname, to load its SVG data. This won't work when the
icon is not a local file, for instance when a symbolic icon is loaded
from a GFileIcon with a GResource path.
Fortunately GtkIconInfo already holds a GFile, so we can just use
g_file_load_contents() to load the data instead.
https://bugzilla.gnome.org/show_bug.cgi?id=709056
Updated documentation to specify that '0' should be specified if
one does not need to automatically assign a bound child to a public
or private instance member (now that negative values are private
structure offsets).
If we start with a padding of -1 then it can leak out of the size
allocation request for the column when the treeview is empty. The
GtkTreeView will then collect these -1 values and add them together,
returning -n where 'n' is the number of columns.
This is usually not a problem because treeviews tend to be used with a
scrollbar and the width of the scrollbar will be added to this number
bringing it into positive territory again. On Ubuntu, with overlay
scrollbars, this is not the case, however.
https://bugzilla.gnome.org/show_bug.cgi?id=703062
The size of the shadow and invisible borders can (and usually
will) change between backdrop and focused windows, while the
overall window size remains unchanged. This causes the visible
window to visually 'jump'. We can avoid this by always reserving
the maximum of the focused and unfocused border sizes. The code
for positioning the input-only windows making up the invisible
border is adjusted to deal with this. We now always place the
invisible border right outside the visible content, even if the
shadow extends out much farther.
https://bugzilla.gnome.org/show_bug.cgi?id=707524
And use the "header" style class to do that.
This allows themes to set e.g. the background of the tab header
differently.
Themes will need slight adjustment to make things appear
as before.
https://bugzilla.gnome.org/show_bug.cgi?id=643914
This allows subclasses of GtkTextView that require a corresponding
subclass of GtkTextBuffer to automatically do the right thing when
constructed with a NULL buffer. An example of this is GtkSourceView
which requires a GtkSourceBuffer.
https://bugzilla.gnome.org/show_bug.cgi?id=708584
Improve optimization, by re-enabling WholeProgramOptimization but changing
the linker optimization to not drop items that are not referenced in code
(such as compiled gresource sources that are not directly referenced in
code, as they are still needed for the demos to run properly).
The GtkStack and GtkStackSwitcher code did not really
follow GTK+ conventions for includes. Fix that, and also
fix up a case of gpointer vs gpointer* confusion
in gtkstack.c.
This adds new 'over' and 'under' transitions which work by moving
the new page over the previous one, or moving the previous page off
to reveal the new one. We also add an over/under combination that
is going to be used in GtkAboutDialog.
https://bugzilla.gnome.org/show_bug.cgi?id=707187
Some of the labels were not marked as no-show-all. But the
code clearly tries to manage their visibility, so gtk_widget_show_all()
should not affect them.
https://bugzilla.gnome.org/show_bug.cgi?id=681484
The child property is watched by the StackSwicther which in turns sets a
needs-attention css class on the corresponding button, so that the theme
can for instance show a throbbing animation if one of the hidden pages
needs the user attention.
https://bugzilla.gnome.org/show_bug.cgi?id=707153
So far, this is just supposed to be gdk_cairo_set_source_pixbuf().
Note that this is usually not an API guarantee but courtesy to
applications that used these APIs without a gtk_init() call.
https://bugzilla.gnome.org/show_bug.cgi?id=708547
If an icon is in a Fixed or Threshold directory we normally don't
scale it. However, in the case of HiDPI scaling we *do* want to
scale it, to avoid different layouts in Lo/HiDPI. We look up whatever
the size of the icon would have been in LoDPI and scale to that
in the no-scaling case, thus getting the same layout as the
unscaled case.
https://bugzilla.gnome.org/show_bug.cgi?id=708384
GdkPixbuf will fail returning %NULL if we try to scale a pixbuf to (0, 0),
which will then trigger an assertion in gtk_icon_info_load_icon_finish();
we never want a scale of 0, so ensure it is at least 1.
https://bugzilla.gnome.org/show_bug.cgi?id=708384
We need to subtract border_width from the size we're passing to the
children hfw functions as those are added by ourselves.
Fixes the window-border-width.ui reftest.
The headerbar test and the buttons tests changed because we've
recently changed accessible names, descriptions and roles of
GtkHeaderBar and GtkSwitch.
Previously, when you clicked and held the button down on a
GtkExpander's label or disclosure triangle, then moved the mouse
away and released the button, the expander would still activate.
This brings the behavior in line with the more generally expected
behavior, as exhibited by GtkButton for example.
https://bugzilla.gnome.org/show_bug.cgi?id=706345
The surface is destroyed when we hide a window, but
gdk_window_set_opaque_region can be called before the window is
shown again, so we need to ensure the surface exits.
https://bugzilla.gnome.org/show_bug.cgi?id=707328
This allows GTK+ applications with headerbars to fit in
better in platforms that have window controls on the left.
To use this, set -GtkWindow-decoration-button-layout: 'close:'
in the theme.
https://bugzilla.gnome.org/show_bug.cgi?id=706708
At least for header bars, there's often application controls
in this area, which should be included in the focus chain.
We make it so that the initial focus avoids the titlebar,
but tabbing around will eventually get there.
https://bugzilla.gnome.org/show_bug.cgi?id=708067
This reverts commit 7cecc8e524.
It is impossible to use the selection object of the menu while it is
collapsed (collapsed menus deselect everything for a start), so even
though the original patch was correct, the followup issues are too big
to solve this quickly to a release.
https://bugzilla.gnome.org/show_bug.cgi?id=707786
* gtk/gtkwidget.c: drag-leave signal: Document that it is called before
drag-drop.
drag-data-received signal: Document that it is up to the application
to know why the data was requested (e.g. drag motion or drop).
* demos/gtk-demo/toolpalette.c: interactive_canvas_drag_drop():
Do not transform the drop_item created in the drag-motion handler.
Instead caused drag-data-received to be called, remembering why,
and create a new item there.
interactive_canvas_drag_leave(): Remove the idle-handler hack,
now that we do not need to keep the drag-motion drop_item alive until
the drop.
I noticed that this patch was sitting in bug #605611 from 2009
though it had been approved. I do not remember much about why I
created it.
Pass the master device instead if the last slave is NULL. This is
unlikely to happen in most of the cases, but can happen when running
unit tests where there's no pointer interaction to update the last
slave.
https://bugzilla.gnome.org/show_bug.cgi?id=696756
This is the same behaviour as gtk_widget_get_valign, except
we have no gtk_wiget_get_halign_with_baseline, as baselines make
no sense for halign.
Without this some widgets (like e.g. GtkOverlay) crash if you accidentally
set a BASELINE halign.
It tests gtk_text_buffer_paste_clipboard(),
gtk_text_buffer_copy_clipboard() and gtk_text_buffer_cut_clipboard() in
various situations, including when GtkTextTags are applied to the
selection.
The last test didn't pass.
https://bugzilla.gnome.org/show_bug.cgi?id=339539
It is more logical to first delete the selection and then pasting the
text. When the selection and the text contain tags, the new behavior is
more natural.
A segfault in paste_from_buffer() is also avoided. The segfault occurs when
the text to paste is deleted because it is the selection.
https://bugzilla.gnome.org/show_bug.cgi?id=339539
Move GtkWrapMode from GtkTextTag to the GtkTextView section. The wrap
mode property is in the text view.
Links to the "mark-set" and "mark-deleted" signals.
Add a precision about gtk_text_buffer_get_iter_at_line().
Fix typo in gtk_text_tag_set_priority().
https://bugzilla.gnome.org/show_bug.cgi?id=708076
A proper name or label is required. In the same way, if the
widget is labelled, ATs uses to expose both the label and the
name, making the final output not really user-friendly.
https://bugzilla.gnome.org/show_bug.cgi?id=707872
keyboard navigation didn't support activation since we moved
the keynav to the child row widgets. We fix this by adding a
activate signal handler for the row and setting
widget_class->activate_signal to it.
https://bugzilla.gnome.org/show_bug.cgi?id=707778
Like the install projects that were fixed few days ago, the gengir projects
did not have info on the intermediate and output directories as a result of
the split up of the property sheets. Fix this by including the appropriate
property sheet in the gtk-gengir property sheet so that we can avoid
confusing messages from Visual Studio on whether to reload the gengir
project as it was modified, at least on 2008.
This reverts commit 70ac2b24c3.
It turns out the correct fix is to make pango_layout_get_text() not
return NULL. This has been done, so we can drop this patch.
I won't bump the Pango dependency in configure.ac for this as I don't
consider the crash critical enough.
Use the pixelcache rendered area to inform what part of the cache should
be invalidated upon changes to the underlying textlayout.
By rendering the background to the pixelcache, we can avoid the need to
use RGBA content.
Also, we're using the pixel cache on the text windows bin_window (see
gtk_text_view_get_window) so we need to register the invalidation handler
on that, otherwise the region passed to the invalidate handler will get
clipped to the visible region.
https://bugzilla.gnome.org/show_bug.cgi?id=707244
nth-child() is 1-indexed, not 0-indexed.
It doesn't matter for this test really, but better do it right to not confuse
poor developers who wonder why the first image is highlighted when nth-child(0)
clearly states "none".
We added code to look for settings.ini in system config dirs,
and then proceeded to move it to /usr/share/gtk-3.0 :-(. So,
look in that location as well.
We now pass NULL when the current color should be the default value of
the "color" property and we haven't looked up any value yet. This way we
don't need to look it up all the time and more importantly we can
resolve the default color, which is required because it's a
GtkCssColorValue and not a GtkCssRgbaValue.
Fixes assertions triggering at Polari startup.
The version of device scale that landed in upstream cairo
master already inherits the device scale in cairo_create_similar,
so no need to do that in gtk anymore.
The reftest is a bit flaky because it compares cell renderers with
GtkImage and therefor an icon view with a GtkBox, but it's the best I
can come up with.
https://bugzilla.gnome.org/show_bug.cgi?id=702423
Even when not following states, blacklist the states we don't follow
instead of whitelisting the ones we do. This way, we don't accidentally
eat new ones like the text direction flags.
Fixes a bug where text direction wasn't available when rendering stock
items.
https://bugzilla.gnome.org/show_bug.cgi?id=702423
Due to the split up of the property sheets, the install projects did not
have info on the Intermediate and Output Paths, which caused confusing
messages from Visual Studio to show up upon completing build+"install" and
closing Visual Studio on whether to reload the install project, at least on
Visual Studio 2008.
Also clean up the Visual Studio 2008 install project a bit.
Include the property sheet which defines these properties to fix this.
In the gnome-ostree model builddir contains all generated files not in
git (unless the build system explicitly overrides that). Here the
wayland-client-protocol.h was in $(builddir)/wayland, so we need to
find it using our already extant -I$(top_builddir)/gdk, rather than
relying on same-directory lookup.
Add the concept of shell capabilities, which allow the compositor
to advertise support for the app menu and the global menubar,
which are then propagated as GdkSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=707129
If the compositor supports the gtk-shell interface, use it to
export the application ID, dbus name and paths that can be used
for the application menu.
https://bugzilla.gnome.org/show_bug.cgi?id=707129
Call gtk_widget_get_mapped() in a couple of places before looking at the
widget's parent, since it might be set to a widget that has been
finalized, causing an invalid read.
GTK+ tries to automatically assign the best input module based on the
'system locale'. In the specific case of the IME input method, it will
be the default for the whole GTK+ application if the system locale is
either Japanese (ja), Korean (ko) or Chinese (zh). Other defaults are
equally applicable, e.g. if system locale is Catalan (ca), the special
'Cedilla' input module is chosen.
System locale can be changed (e.g. Win7) through the following sequence
(reboot required):
Control Panel
Region and Language
Administrative
Language for non-Unicode Programs
Change system locale...
The problem with this behaviour is that changing the 'default input
language' (e.g. from English to Japanese+IME) doesn't affect the GTK+
application. Therefore, I can have an English system locale (where GTK+
will choose Simple IM by default) but then have Japanese+IME as input
language.
Default input language can be changed (e.g. Win7) through the following
sequence (no reboot required):
System locale can be changed (e.g. Win7) through:
Control Panel
Region and Language
Keyboards and Languages
Keyboards and other input languages
Change keyboards...
Default input language can also be changed using the language bar directly.
So, instead of using the system-wide default locale to decide which input
method to use as default, better use the input language specified by the
user, which may be the same as the system-wide default locale, or different.
Following the previous example, with an English system locale and a
Japanese+IME input language, the default input method will now be IME
instead of Simple, which is closer to what's expected by the user.
This change only affects the application during startup; i.e. if the user
changes the input language while the application is running, we wouldn't be
changing the default input method to use. We could do this processing the
WM_INPUTLANGCHANGE messages, though.
https://bugzilla.gnome.org/show_bug.cgi?id=700428
The fix for child properties made the a11y dump for the assistant
case change. After close inspection, the new output is what the
code intends to produce, so update the expected result.
Call gtk_widget_get_mapped() in a couple of places before looking at the
widget's parent, since it might be set to a widget that has been
finalized, causing an invalid read.
GtkAssistant is bending the rules about child properties
of non-direct children, and the recent fix to accomodate
GtkInfoBar changes broke things. The effect was that child
properties of assistant pages in ui files were just not
applied, so all pages ended up without titles and with
the normal page type, leading to broken assistants all
over the place.
https://bugzilla.gnome.org/show_bug.cgi?id=706756
We need to copy the GDK .lib/.dll from Release_Broadway\<Platform>\bin
or Debug_Broadway\<Platform>\bin to Release\<Platform>\bin or
Debug\<Platform>\bin respectively during the build of Broadway flavors of
GDK, as the MSVC introspection builds expects the GDK .lib/.dll to be
in Release\<Platform>\bin or Debug\<Platform>\bin.
Use a new property sheet to do so for Broadway builds of GDK-during the
builds of Win32-only GDK, the broadway builds of the GDK .lib/.dll would
be cleared out prior to the build of the Win32-only GDK.
GtkAssistant supports not showing the sidebar with the page
titles (if the page have no titles). Unfortunately, we were
hiding the sidebar in this case, but still rendering the frame
behind it, leading to a broken appearance.
Horizontal scrolling is unusual, but specifying some extra offscreen
space for it in free in the normal case where the viewport is the
same width as the canvas anyway, so lets do it.
If the new requested surface size is enough larger than the previous
one (but the old is still larger than the absolute minimum),
reallocate it anyway.
This fixes an issue where the text view initially requested a really
small extra size which was then increased but that didn't "take".
This patch uses GtkPixelCache to render the contents of the widget,
and typically a bit more, to an offscreen surface. The pixel cache in
turn manages rendering to the actual surface for the widget.
The current strategy for the size to render is the size of the widget
plus half the height.
https://bugzilla.gnome.org/show_bug.cgi?id=701125
There were some code added to this file that is meant for the X11 backend,
but they are being unconditionally built. Add build-time checks for the
X11 backend for these to fix the build on non-X11 platforms.
...for the gdk_cursor_new_from_surface work (commit b2113b73) where the
types of some parameters were changed, and also to silence a critical
GDK_IS_DEVICE when a menu item is selected (courtesy of LE GARREC Vincent
from bug 696756).
https://bugzilla.gnome.org/show_bug.cgi?id=705980
Due to the work on gdk_cursor_new_from_surface (commit b2113b73),
get_cursor_for_pixbuf() in GdkDisplayClass was converted to
get_cursor_for_surface(), which means the GDK Win32 backend needs to be
updated for the code to build and run on Windows, plus some function
prototypes and declarations/calls need to be updated as well.
https://bugzilla.gnome.org/show_bug.cgi?id=705980
We'll use a style class to be able to give this a different appearance,
but for the time being we don't really need to give this such different
margin.
https://bugzilla.gnome.org/show_bug.cgi?id=706592
When setting the lines property, the label will be ellipsized
to that many lines, with the ellipsis only appearing in the
last line. This is different from how ellipsization of multi-line
labels normally works in GTK+.
"title_box" is used for both a custom header bar and for a titlebar.
Since we want to help differentiate these cases in the code, rename
everything titlebar-internal to use "titlebar_".
https://bugzilla.gnome.org/show_bug.cgi?id=706529
This used to point to the GtkPathBar, which doesn't accept mnemonic activation, anyway.
This whole thing was a leftover from when we had a combo box to select a folder, but
this is no longer the case.
https://bugzilla.gnome.org/show_bug.cgi?id=706448
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This way, the Wayland and the regular clipboard implementation can both
be compiled in and selected based on the display in use.
One thing potentially broken now is text mime type handling as Wayland
seemed to use different mime types in some places.
This lets you force a specific window scale, this is needed
for mutter to be able to disable the scaling as it needs access
to unmangled X window/screen sizes. It can also be useful to
force a specific scale in e.g. tests.
The state of the widget is not enough now to cache the pixbuf - we also
have to take into consideration the image effect itself, since the state
on the actual GtkStyleContext we use might not change, e.g. because the
change was on a parent context.
https://bugzilla.gnome.org/show_bug.cgi?id=705443
We should set the appropriate style classes when we have
constructed the content and know if it is a label, an image,
or both. Doing this in the convenience constructors is
problematic for language bindings, and misses out when the
content is changed after construction.
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
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
We want a surface so we can properly represent the scale factor for it.
All backends are converted to use surfaces and we reimplement the
backwards compat code in the generic code.
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
If we don't dispatch the pending events then we can enter poll with events
still requiring to be processed and which can then lead to us deadlocking
there.
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.
Xsun is no longer shipped to customers, and Oracle/Sun's Xorg distribution
uses "Sun Microsystems" as the vendor name, so this hack is incorrect in
the more common recent cases.
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
Update the gtk-install-bin property sheets so that it does not "install"
the wrong GDK DLL/LIB when building a broadway-enabled GDK
when the non-Broadway GDK had been previously built.
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.
-Add Visual Studio 2008 projects and pre-configured gdkconfig.h for
Broadway builds
-Decouple the Visual Studio property sheets, to simplify maintenance and
enhance flexibility for different builds
Visual Studio 2010 projects updates will follow later.
The IME input method has been both ignoring keypresses of
non-spacing characters (ditching these as non displayable),
and not letting IME do anything about those.
Even though, the sparse documentation on IMM/IME seems to
hint that applications can't pipe non-spacing characters to
the input method manager, and experimentation shown that
those characters are indeed handled differently than how
it'd be expected.
Then, add basic handling of dead keys on the IME input method
itself , as it's not mutually exclusive with regular keymaps
with dead keys.
https://bugzilla.gnome.org/show_bug.cgi?id=704937
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.
When an application translates a key event and drop its native event
before passing to imquartz, it can't recognize the NSEvent. On this
case imquartz doesn't emit any signals such as "commit" signal so
that the application doesn't insert any text. To avoid no response,
at least imquartz should fallback to slave GtkIMContextSimple.
https://bugzilla.gnome.org/show_bug.cgi?id=694273#c27
(cherry picked from commit c064e18894)
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>
Many parts of GTK+ assume that all windows have a cairo surface
assoicated with them. This change provides a logically 1x1 cairo surface
(respecting scale) for the root window.
https://bugzilla.gnome.org/show_bug.cgi?id=704554
Setting up the icon and desktop file is a pretty central part
of making an application work, so we should do it for our example.
The fact that the examples are uninstalled makes this a little
more complicated.
I disconnected signals in dispose() to avoid a visible-tab
change notification during destruction, but this is clunky.
Instead, make the notify::visible-tab signal handler bail out
early when called during destruction.
This value is highly sensitive to changes in the theme; we
don't want to have to tweak hardcoded integers in this test case
every time we rev gnome-themes-standard.
Future iterations could do more heuristic matching, but this
is enough for now.
https://bugzilla.gnome.org/show_bug.cgi?id=704747
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
Add a new example to the getting started part of the docs. The focus
of this example is on 'new stuff': GtkApplication, templates, settings,
gmenu, gaction, GtkStack, GtkHeaderBar, GtkSearchBar, GtkRevealer,
GtkListBox, GtkMenuButton, etc.
It is being developed in several steps. Each step is put in a separate
directory below examples/: application1, ..., application8. This is a
little repetitive, but lets us use the code of all examples in the
documentation.
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.
If we bind to a global with an higher version than implemented, or
we make requests that appeared in a later version, we would get
fatal wayland errors.
https://bugzilla.gnome.org/show_bug.cgi?id=704104
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
With the introduction of the use of buffer scaling in ed4fcee4ct we
must request version 3 of the compositor as that is the version of the
surface interface that adds this new functionality. See the following
commit in weston:
commit a85118c1b85df6fbf8f896dca971a5b79a94da71
Author: Jason Ekstrand <jason@jlekstrand.net>
Date: Thu Jun 27 20:17:02 2013 -0500
Use wl_resource_create() for creating resources
This commit sets the version numbers for all added/created objects. The
wl_compositor.create_surface implementation was altered to create a surface
with the same version as the underlying wl_compositor. Since no other
"child interfaces" have version greater than 1, they were all hard-coded to
version 1.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
https://bugzilla.gnome.org/show_bug.cgi?id=703817
We should mention that newly written code should not have the private
data pointer in the instance structure, and that private data should be
added using the new GObject macros.
https://bugzilla.gnome.org/show_bug.cgi?id=702996
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.
Ths allows the retrieval of the wl_surface before the window is shown.
The surface is still created in the original places since the surface
and shell surface is destroyed when the surface is programmatically
hidden.
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.
We've long had double precision mouse coordinates on wayland (e.g.
when rotating a window) but with the new scaling we even have it on
X (and, its also in Xinput2), so convert all the internal mouse/device
position getters to use doubles and add new accessors for the
public APIs that take doubles instead of ints.
This lets use use a scaled Xft/DPI for old apps while not
blowing up the size of scaled windows. Only apps supporting
Gdk/WindowScaleFactor should supprt Gdk/UnscaledDPI.
If you set GDK_SCALE=2 in the environment then all windows will be
scaled by 2. Its not an ideal solution as it doesn't handle
multi-monitors at different scales, and only affects gtk apps.
But it is a good starting points and will help a lot on HiDPI
laptops.
We track the list of outputs each window is on, and set the
scale to the largest scale value of the outputs. Any time the scale
changes we also emit a configure event.
We bind to the newer version of the wl_output which supports
the new done and scale events, and if we use this to get the
scale for each monitor (defaulting to 1 if not supported).
If a cairo_surface for a window has a device scale set we need
to respect this when creating a similar window. I.e. we want
to then automatically create a larger window which inherits
the scale from the original.
We also need to calculate a different device_offset if there
is a device_scale set.
This adds a crypt(3) implementation for use with broadwayd as Visual Studio
does not support crypt(3) out of the box.
The public domain implementation is taken from the following URL,
http://michael.dipperstein.com/crypt/, where AFAICT this implementation
would not be subject to licensing restrictions that would prevent it from
being bundled.
-Don't include unistd.h unconditionally as it's not available in Visual
Studio, but include io.h where necessary.
-Avoid C99isms, and use _chsize_s in place of ftruncate when unistd.h is
not available (as in the case of Visual Studio)
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.
Only look at "impl" windows in gdk_window_process_updates_with_mode()
since these are the only ones we care about. This avoids a lot of
unnecessary calls to g_list_copy() and g_object_ref().
We don't want to recurse into children that are clipped, as that is
wasted work. We handle this by moving the empty check to the top
of the function and only using the clipped region everywhere.
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
Move the call to gdk_x11_atom_to_xatom_for_display() outside of the
search loop in gdk_x11_screen_supports_net_wm_hint(). In my test case
(running Audacious for about a minute), this reduced the total number of
hash table lookups performed from 370,000 to 230,000.
https://bugzilla.gnome.org/show_bug.cgi?id=702913
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>
It would default to GTK_FILE_CHOOSER_ACTION_OPEN if the user's specified --action could not be
parsed. I can never remember what the right options are, so make the program bail out
if the user specifies an unrecognized option.
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 file chooser does not show the hours for files modified today
when using it & hu locales on Win32. This is due to the %k format conversion
for strftime() that is in Olson's Timezone Package, which msvcrt.dll doesn't have.
Cygwin has it, though.
So for now, we just use a %H format. While %k would render
six-in-the-morning as " 6" (6 preceded by a space), %H will render it
as "06".
https://bugzilla.gnome.org/show_bug.cgi?id=560337
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
and not on each keystroke, which for some IMs apparently caused a full
update on each keystroke, not just a check for changes. Patch from
Takuro Ashie, bug #698183.
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.
Historically the following states propagated to children:
GTK_STATE_FLAG_ACTIVE
GTK_STATE_FLAG_PRELIGHT
GTK_STATE_FLAG_SELECTED
GTK_STATE_FLAG_INSENSITIVE
GTK_STATE_FLAG_INCONSISTENT
GTK_STATE_FLAG_BACKDROP
However, several of these are problematic on containers like GtkListBox.
For instance, if a row is ACTIVE or SELECTED then all children (like e.g
a button) inside the row will *also* look active/selected. This is almost
never right. The right way to theme this is to catch e.g. SELECTED on the
container itself and set e.g. the color and let the children inherit
the color instead of the flag.
We now propagate only these flags:
GTK_STATE_FLAG_INSENSITIVE
GTK_STATE_FLAG_BACKDROP
Which make sense to be recursive as they really affect every widget
inside the container.
However, this is a CSS theme break, and while most things continue working
as-is some themes may need minor tweaks.
Now that we automatically set up the focus_vadjustment we only
need the adjustment to handle the page-up/down scroll length correctly.
We use parent_set to automatically pick up the adjustment from a
scrollable (i.e. viewport) parent which makes add_to_scrolled useless, so
it can be removed.
When adding with a viewport we automatically set the focus
adjustments on the viewport from the scrolled window, so that
when any child widget gets focused we automatically scroll to it.
This is generally nice, but its particularly important for GtkListBox
where focus changing is how we navigate between rows.
We also ensure that the adjustments are always set before adding the
child to the viewport, which we will need later to pick up the
adjustments on add.
Unhighlight rows if they are removed.
Drop the automatic drag motion based auto-scrolling. This is not really
right, as it e.g. hardcodes auto-scroll regions and assumes we're the only
widget inside the scrolled container. Its also imho in the wrong place,
autoscrolling if any should be done on the scrolled-window or viewport.
All the removed code is implementable outside Gtk+ though.
Use g_string_assign to avoid issues with assigning GString's internal
buffer back to the same string. This can happen when no translations are
available and _gtk_builder_parser_translate returns back the same
pointer that was passed in.
This fixes a regression from commit e9f182e37a
that caused GtkComboBoxText <items> from GtkBuilder to show up empty if
no translations are available.
https://bugzilla.gnome.org/show_bug.cgi?id=700629
window_type_hint_to_level(): applied patch from Paul Davis which moves
dialogs to NSFloatingWindowLevel. This is not quite the perfect
solution, but it's a pragmatic fix that makes apps which have both
window types much more usable, and prevents dialog from disappearing
under an application's main window.
(cherry picked from commit 59d49e1566)
Include config.h first so that _GDK_EXTERN may be defined once
and only once during the build, so that we do not get warnings/
errors for macro redefinition.
https://bugzilla.gnome.org/show_bug.cgi?id=701251
Include gdkwin32.h (which includes gdkprivate-win32.h and gdkwin32cursor.h
during the build of GDK-Win32) so that
gdk_win32_icon_to_pixbuf_libgtk_only() and
gdk_win32_pixbuf_to_hicon_libgtk_only() get exported, so that the GTK
DLL can link correctly.
-Update the pre-configured config.h.win32(.in) to define _GDK_EXTERN as
__declspec (dllexport) as we are not using .def files to export symbols
anymore.
-Update the GDK/GTK DLL projects and the property sheets to stop using
the .symbols/.def files
-Update the property sheets to "install" the newly-introduced GTK headers
-Update the gtk3-demo project to build the new demo sources that must be
built
-Avoid defining variables in the middle of the block
-Include fallback-c89.c in gtkrevealer.c in place of math.h as
fallback-c89.c includes math.h itself, and is needed for round()
Add a PlatformToolset tag for each configuration for project files that
do not yet have them. This is to ease support for Visual Studio 2012 as
we can copy and easily replace a few items with automated scripts as
project files for Visual Studio 2010 and 2012 are very similar.
This might change when we eventually support the Metro (aka Windows 8
Modern UI), but this will suffice for the time being.
Do not unref mount has we grabbed its pointer without taking
a reference.
Otherwise the following call to g_list_free_full on network_mounts
frees it a second time. Segfault in nautilus ensue.
https://bugzilla.gnome.org/show_bug.cgi?id=700979
gtk_widget_get_allocated_height returns the adjusted
allocation, so we can't use it as measure for how much
room to leave when drawing the window background.
The intention of the expand widget flags was to in fact propagate
legacy expand child properties as well. Due to implementation errors,
this was only happening in some cases, but not in others. To avoid
breaking old code assuming traditional expand flag behavior, this
commit removes all attempts to propagate GtkBox::expand.
This was discussed in
https://bugzilla.gnome.org/show_bug.cgi?id=698656 and
https://bugzilla.gnome.org/show_bug.cgi?id=628902
This patch was written by Tristan Van Berkom.
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
Work around this by introspecting gtkclipboard.c and gtkdnd.c instead
of the quartz alternatives.
Note that this is temporary: The implementation of GdkSelection
will make the quartz alternatives unnecessary. See bug 571582.
Calling XIQueryPointer() on a slave device is going to trigger a
BadDevice X error. So in case we query a slave device state, ask the
master device instead.
https://bugzilla.gnome.org/show_bug.cgi?id=700233
Add missing check in gdk_x11_device_manager_xi2_get_window(), returning
NULL if no valid XI2Event* has been found. Calling code seems to be
prepared to handle NULLs coming from this function, so it should be
safe enough (e.g. check gdk_event_source_get_filter_window()).
https://bugzilla.gnome.org/show_bug.cgi?id=700465
I notice that a reference to GtkStrengthBar had been left in this file
when it was renamed to GtkLevelBar. On closer inspection, it looks like
it's been unused for 13 years. To quote docs/reference/ChangeLog:
> 2000-10-23 Havoc Pennington <hp@redhat.com>
>
> [...] Removed objects_grouped.sgml from gtk-docs.sgml for now, it
> doesn't seem useful anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=700575
Mouse events that we do not handle should bubble up to the parent
widget, so they can be handled there, instead of disappearing inside
the button. Also use GDK_EVENT_{STOP,PROPAGATE} to make return
values clearer.
https://bugzilla.gnome.org/show_bug.cgi?id=696640
Instead of storing the rect in the bin window, store the row and column
the editable belongs to and compute the rect lazily. This way, we don't
need to keep the rect up to date.
Fixes /TreeView/scrolling/new-row-mixed/path-500 test.
Emit the "changed" signal after 150 msecs, so that searching
through big lists, or doing online searches feels more responsive.
This is something already done in various applications to make
search-as-you type more responsive (gnome-shell, gnome-documents,
gnome-control-center, etc.). The 150 msecs is the value currently
used by gnome-shell, so keep it (invisibly) consistent.
https://bugzilla.gnome.org/show_bug.cgi?id=700229
Change "Englihs" to "English"
Change "Page up" to "Page Up"
Change "Page up (keypad)" to "Page Up (keypad)"
Change "Page down" to "Page down"
Change "Page down (keypad)" to "Page Down (keypad)"
Now that we're not drawing the GdkWindows by themeselves we need to
propagate into children in the same order as the windows were painted
otherwise apps can't rely on stacking order to overlay children.
This is still not 100% the same as the old behaviour, because we're
treating all windows that are part of a window at the same time (to allow
e.g. opacity groups), and we're only looking at order for the main
windows of a widget. However, this fixes at least the ordering
of the gnome-boxes fullscreen overlay toolbar.
https://bugzilla.gnome.org/show_bug.cgi?id=699970
We don't track the full clip for each window anymore, as this
is not useful when no windows are opaque. However, we still
need the full clip for the shape, so its calculated manually.
However, it was previously only recalculated when the clip changes
which doesn't correctly handle the case of a sibling geometry changing.
So, instead of doing this directly when geometry changes we just
set a bit in the toplevel whenever some window geometry changes, and
we then handle this in process_updates, updating the shape for all
native windows. This should be ok performance-wise because we don't
expect a lot of native children.
Instead of making clients inspect the submenu action and decide what
to do based upon that, always request the submenu open and let the
tracker decide what to do.
Add a new class, GtkMenuTrackerItem that represents a menu item, to be
used with GtkMenuTracker.
GtkMenuTracker's insert callback now works in terms of this new type
(instead of passing reference to the model and an index to the item).
GtkMenuShell now handles all of the binding tasks internally, mostly
through the use of property bindings. Having bindings for the label and
visibility attributes, in partiular, will help with supporting upcoming
extensions to GMenuModel.
GtkModelMenu has been reduced to a helper class that has nothing to do
with GMenuModel. It represents something closer to an "ideal" API for
GtkMenuItem if we didn't have compatibility concerns (eg: not emitting
"activate" when setting toggle state, no separate subclasses per menu
item type, supporting icons, etc.) Improvements to GtkMenuItem could
eventually shrink the size of this class or remove the need for it
entirely.
Some GtkActionHelper functionality has been duplicated in
GtkMenuTracker, which is suboptimal. The duplication exists so that
other codebases (such as Unity and gnome-shell) can reuse the
GtkMenuTracker code, whereas GtkActionHelper is very much tied to
GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs.
supporting the full range of GMenuModel features for menu items turns
out to be two overlapping but not entirely similar problems. Some of
the duplication (such as roles) can be removed from GtkActionHelper once
Gtk's internal Mac OS menubar support is ported to GtkMenuTracker.
The intent to reuse the code outside of Gtk is also the reason for the
unusual treatment of the enum type introduced in this comment.
This adds no new "public" API to the Gtk library, other than types that
we cannot make private due to GType limitations.
Rename our internal GActionMuxer, GActionObserver and GActionObservable
classes and interfaces to have names in our own namespace.
These classes were originally intended for GIO but turned out to be too
special-purpose to be useful there, so we never made them public API but
have just been copying them around (without bothering to properly rename
them). Now that other people will be copying them out of Gtk, it's even
more important to prevent this namespace abuse from spreading further.
We were using gtk_menu_item_get_label() from a testcase to determine the
label associated with a menu item. Future changes to GtkModelMenuItem
will cause this to stop working, so try a bit harder to find a label
inside of the item.
GtkApplicationWindow would only update its list of captured accels
when realizing the window. This meant that keyboard shortcuts added
after the window was realised (for example, added by plugins) would
be non-functional.
Solve this by updating our accels every time the accel map changes,
not only when realizing the window.
https://bugzilla.gnome.org/show_bug.cgi?id=700079
Items that act on the selection should not be sensitive if the
selection is empty. This was already the case for the 'Copy file
location' item, but not for the 'Add bookmark' and 'Visit file'
items.
https://bugzilla.gnome.org/show_bug.cgi?id=699104
Usually, educated GtkContainers' forall() implementation returns children
in an order that's safe for the default draw() implementation in GtkContainer.
So for widgets with some stacking notions (eg. GtkOverlay),
_gtk_widget_find_at_coords() needs to recurse within containers in reverse
order so it finds the topmost widget.
As this function is used in both tooltips and DnD code, this improves behavior
of "floating" widgets wrt those two. This could for example be seen in the
"Transparent" GTK+ demo, where dropping text on the entry results on the text
going to the textview.
https://bugzilla.gnome.org/show_bug.cgi?id=699239
Also removed a bogus FIXME comment which might have been true
a long time ago. Clarification: the "domain" attribute specified
in the builder script overrides any domain previously set with
gtk_builder_set_translation_domain(), so the translation of items
here is perfectly correct and does not need to be fixed.
Bring back need_default_size. We need it to preserve this
documented behavior:
The default size of a window only affects the first time a window is
shown; if a window is hidden and re-shown, it will remember the size
it had prior to hiding, rather than using the default size.
With this patch, all of the window sizing tests in
gtk/tests/window pass again.
gtk_widget_preferred_size() is only useful if you want to quickly port a
widget from GTK2 sizing code to GTK3 but does not properly work with
height-for-width as used in GTK. So we don't want to encourage people to
use it. In particular we want people to convert to height-for-width
before adding baseline support to their widgets.
This is left over from an old effort to bundle gtk and its dependencies
into a Mac OS X Framework. The effort was more or less successful but
proved difficult to maintain and impractical to use because gtk programs
don't use the special Framework include syntax.
GtkMenu calls gtk_widget_size_allocate on its GtkWindow during
gtk_menu_popup_for_device if the menu has not been realised. This can cause the
allocation of the GtkWindow and the size of the GdkWindow to become out of sync
because a top level GtkWindow does not attempt to re-size the GdkWindow when
its allocation is set.
https://bugzilla.gnome.org/show_bug.cgi?id=695120
In the ancient X days you could have Xservers that had multiple active windows, like
one truecolor and one 8bit palette. Then most apps ran in 8bpp but a single window
would use truecolor. This is done by specifying different visuals for the windows.
To make this work we ensured that a window with a visual different from its parent
gets a native subwindow, so that X can tell the hardware to do its magic.
These days the only real time we get two different visual is when one is a rgba visual
and the other is not. So, the code to check this doesn't really do anything but
get in the way when someone accidentally manages to not get a rgba visual on
a child window (see bb7054b508). So, to avoid
such errors we just remove the "different visual than parent" check.
We need to send exposes for all native windows, even the ones
without an exposure mask set, because otherwise non-native
children of the native window with an exposure mask will
not be drawn.
We should only draw the cross-fade on the bin window, not doing this
was causing us to draw it multiple times using ADD which resulted
in weird colors.
This removes the typechecks in GDK_WINDOW_TYPE and GDK_WINDOW_DESTROYED. These
are only used internally in gdkwindow.c and gdkdisplay.c anyway, and these
functions check for typesafety of arguments on function entry.
This makes iterating over the children a lot faster, as we're
not doing lots of intra-library calls and type checks. We're still
in some sence O(n^2) since we iterate over each child window for each
widget, but the profiles look much better.
This function returns all the children that has a specific user_data set.
This is used a lot in the new GtkWidget drawing code and doing
it this way is faster than getting every child and calling get_user_data
on each (which was a non-neglible part of the profiles). Additionally it
also allows use to use some kind of hashtable to make this operation even
faster if needed in the future.
We register an invalidate handler on the bin window to get told
of child widget invalidations, although we manually need to discard
invalidates from the scroll operation.
Additionally we invalidate all of the pixel cache whenever
the TreeView itself is queue_draw()n to handle e.g. style (bg)
changes, or changes due to model changes causing queue_draw() in
the tree view.
Since gdk_window_move() no longer uses XCopyArea all scrolling
now re-renders everything in the window. To get performance
back we use a GtkPixelCache to store already drawn children,
and we when we expose the viewport we just blit the
offscreen to the right place.
GtkPixelCache is a helper utility that lets you implement
faster scrolling of a viewport of a canvas by using an
offscreen pixmap cache.
You call _gtk_pixel_cache_draw with a callback function that
does the drawing, and additionally you specify the size and the
position of the viewport in the widget, and the position and size
of the canvas wrt the viewport. The callback will be called to
draw on an offscreen surface, and the surface will be drawn
on the window. The next time you do the same, any already drawn
pieces of the surface are re-used from the offscreen and need
not be rendered again.
If things inside the canvas change you need to call
_gtk_pixel_cache_invalidate to tell the cache about this.
Some other details:
* The offscreen surface is generally a bit larger than
the viewport, so scrolling a small amount can often
be done without redrawing children.
* If the canvas is not larger than the viewport no
offscreen surface is used.
GtkPixelCache: Make sure we always copy using SOURCE
We were using OVER for the first copy (from source to group surface.
GtkPixelCache: Fix x/y typos
GtkPixelCache: Allow NULL for invalidate region
gtkpixelcache: Use CONTENT_COLOR for solid bg windows
Since widgets now cache drawn state we allow them to override
queue_draw_region to detect when some region of the widget
should be redrawn. For instance, if a widget draws the
background color in a pixel cache we will need to invalidate
that when the style context changes which queues a repaint.
This lets you register callbacks for when child widgets invalidate
areas of the window read it and/or change it.
For instance, this lets you do rendering effects and keeping offscreen
caches uptodate.
If we got the release event for the last buffer then we're
fine with writing directly to the window surface, as wayland
will not be looing at it. This saves us from allocating
and copying more data.
First of all, we now only do paints on native windows, as there is
really no reason anymore to do it for subwindows. Secondly, we
keep track of the paints even for GtkPaintable windows, but for
that case we don't create the offscreen surface, but rather
assume the windowing system does the backing store.
We do the save/restore when emitting ::draw rather than in a custom
marshaller, as this saves an extra stack frame, which is helpfull now
that we do painting fully recursive. This is also likely to save a few
cycles.
In the case where the layout phase queued a layout we don't
want to progress to the paint phase with invalid allocations, so
we loop the layout. This shouldn't normally happen, but it may
happen in some edge cases like if user/wm resizes clash with
natural window size changes from a gtk widget. This should not
generally loop though, so we detect this after 4 cycles and
print a warning.
This was detected because of an issue in GtkWindow where it
seems to incorrectly handle the case of a user interactive resize.
It seems gtk_window_move_resize() believes that configure_request_size_changed
changed due to hitting some corner case so it calls
gtk_widget_queue_resize_no_redraw(), marking the window as need_alloc
after the layout phase. This commit fixes the issue, but we should
also look into if we can fix that.
Now that all windows are non-opaque we can simplify the invalidation
a lot. There is no need to clip the invalidate area to child regions,
because we will always redraw everything under all the children.
We only have to handle native childen specially.
We now only do one expose event per native window, so there will
only be one begin/end_paint() call. This means all the work with
implicit paints to combine the paints on a single double buffer
surface is unnecessary, so we can just delete it.
We now consider non-native windows non-opaque, which means any invalid
area in a subwindow will also be invalid all the way up to the nearest
native windows. We take advantage of this by ignoring all expose events
on non-native windows (which typically means just the toplevel) and instead
propagating down the draw() calls to children directly via
gtk_container_propagate_draw.
This is nice as it means we always draw widgets the same way, and it
will let us do some interesting ways in the future.
We also clean up the GtkWidget opacity handling as we can now always
rely on the draing happening via cairo.
We can't really just draw by walking down the widget hierarchy, as
this doesn't get the clipping right (so e.g. widgets doing cairo_paint
may draw outside the expected gdkwindow subarea) nor does it let
us paint window backgrounds.
So, we now do multiple draws for each widget, once for each GdkWindow,
although we still do it on the same base cairo_t that we get for the
toplevel native window. The difference is only the clipping, the rendering
order, and which other widgets we propagate into.
We also collect all the windows of a widget so we can expose them inside
the same opacity group if needed.
NOTE: This change neuters gtk_widget_set_double_buffered for
widgets without native windows. Its impossible to disable
the double buffering in this model.
Since we dropped the move region optimization there is really no need
to try carefully keep track of opaque non-overlapped regions, as we
don't use this information to trigger the optimization anymore.
So, by assuming that all windows are non-opaque we can vastly simplify
the clip region stuff. First of all, we don't need clip_region_with_children,
as each window will need to draw under all children anyway. Secondly, we
don't remove overlapping sibling areas from clip_region, as these are
all non-opaque anyway and we need to draw under them
Finally, we don't need to track the layered region anymore as its
essentially unused. The few times something like it is needed we can
compute it explicitly.
For the case of native children of widgets we may cause a repaint
under native windows that are guaranteed to be opaque, but these
will be clipped by the native child anyway.
This basically neuters gdk_window_move_region, gdk_window_scroll
and gdk_window_move_resize, in that they now never copy any bits but
just invalidate the source and destination regions. This is a performance
loss, but the hope is that the simplifications it later allows will let
us recover this performance loss (which mainly affects scrolling).
Turns out our blurring function isn't very nice, it has a lot
of energy past the blur radius, so clipping at exactly the
blur radius causes ugly gradient stops. This just adds 4
extra pixels of slop, which makes this better in most cases.
We split up the rendering of blurred shadows into 9 parts, the
corners, the sides and the rest. This lets us only blur the "blurry"
part, and it lets us completely skip blurry parts that are fully
clipped.
As per css3-background 7.2. Drop Shadows: the ‘box-shadow’ property:
An outer box-shadow casts a shadow as if the border-box of the element
were opaque. The shadow is drawn outside the border edge only: it
is clipped inside the border-box of the element.
Also verified vs firefox behaviour.
Change the visibility handling to be the same way we do it in
GLib now. We pass -fvisibility=hidden to gcc and decorate public
functions with __attribute__((visibility("default"))).
This commit just does this for GDK, GTK+ will follow later.
glib-mkenums is not currently clever enough to know which version an
enum type was added in, so just mark all the _get_type() functions as
available in all versions.
Make all GDK_DEPRECATED and GDK_AVAILABLE macros use a
new _GDK_EXTERN macro. _GDK_EXTERN defaults to just 'extern'
but a subsequent commit will add visibility handling to it
while building GTK+.
glib-mkenums is not currently clever enough to know which version an
enum type was added in, so just mark all the _get_type() functions as
available in all versions.
Add a macro to declare that a particular symbol is available in all
versions of GTK+.
All newly-added symbols should have proper version macros (like
GDK_AVAILABLE_IN_3_4).
This avoids an evil trap when doing MAX (..., ... - 2 * border_width)
and the expression on the right gets promoted to unsigned, instead
of going negative as you would expect.
https://bugzilla.gnome.org/show_bug.cgi?id=699633
These tests check that a toplevel window ends up with the expected
size after setting default sizes or resizing. It currently passes
on X, but fails with client-side decorations under X and Wayland.
When we call _gdk_wayland_display_load_cursor_theme during
the initial opening of the first display, gdk_setting_get does
not work yet, since it relies on the default display/screen
being set, which only happens after open returns.
Instead, just use the screen of this display.
It's not necessary anymore because gdk_display_manager_get() always
succeeds and the value is independant of when it was called as it's no
longer backend specific.
AtkSelection requires that the immediate children of the object are the
selectable items. The combobox however is implemented with just 1 child:
The popup menu.
The popup menu is implementing the selectable interface.
Test are updated to reflect this change.
Move it from GdkDisplayManagerX11.init to GdkDisplay.class_init.
This shouldn't cause any problems, but who knows, so keep this patch
small.
Reason for this is the unification of display managers.
The gtk-launch tool can be build without gio-unix (although it
will not really do much without an alternative implementation for
g_desktop_app_info).
So there is no need to not build gtk-launch anymore.
This reverts commit 9a1235bf0d.
https://bugzilla.gnome.org/show_bug.cgi?id=682824
Newer versions of GCC/binutils must have the source file come before the
preprocessor and linker flags on the compiler command line, and this is
also compatible with previous versions.
https://bugzilla.gnome.org/show_bug.cgi?id=680241
Pointed out in https://bugzilla.gnome.org/show_bug.cgi?id=699016
The fix here is slightly different. We make
_gtk_builder_parser_translate return a const char * instead of
a dup'ed string, and fix up the callers.
These tests may have some assumptions on reasonable window manager
behaviour. For now, we just test that the default size of the
window ends up as the allocated size of the content. This test
currently fails with client-side decorations, because we are
not properly discriminating between overall window size and
content size.
There is currently no Wayland protocol for providing presentation
timestamps or hints about when drawing will be presented onscreen.
However, by assuming the straightforward algorithm used by the
DRM backend to Weston, we can reverse engineer the right values.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
Combine duplicate code for creating and destroying surfaces.
To make the operation of the destroy() operation more obvious, the
destruction of the (fake) root window at display dispose time is
changed to not be a "foreign" destroy.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
Use wl_surface_frame() to get notification when the compositor paints
a frame, and use this to throttle drawing to the compositor's refresh
cycle.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
Lazily creating the cairo surface that backs a window when we
first paint to it means that the call to
gdk_wayland_window_attach_image() in
gdk_wayland_window_process_updates_recurse() wasn't working the
first time a window was painted.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
When exposing an area, we were individually damaging and committing
each rectangle, *before* drawing. Surprisingly, this almost worked.
Order things right and only commit once.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
Cache the style contexts for the up and down panels, instead of recreating
them each time they are drawn or size requested. GtkSpinButtons were
many times slower to draw than other widgets because of the constant
style matching.
https://bugzilla.gnome.org/show_bug.cgi?id=698682
If a subclass (say a child of GtkButton) overrides the non-baseline
size request methods we need to call these, rather than the new
get_height_and_baseline_for_width method.
In order to handle this we make the default for this method to be
NULL, and instead check at runtime which method to call. If any
non-baseline vfunc has changed in a class but the baseline one
hasn't, then we can't use the baseline one.
We now report any baselines from the child, and allocate it.
Also, in the case of a baselign aligned child we ignore yscale/yalign
as that is not supportable.
Report a baseline based height and baseline whenever there
are children with ALIGN_BASELINE.
Assign baseline to childen in size_allocate. Either the one inherited
from the parent if set, or otherwise calculate one based on any
ALIGN_BASELINE children.
This modifies the size machinery in order to allow baseline support.
We add a new widget vfunc get_preferred_height_and_baseline_for_width
which queries the normal height_for_width (or non-for-width if width
is -1) and additionally returns optional (-1 means "no baseline")
baselines for the minimal and natural heights.
We also add a new gtk_widget_size_allocate_with_baseline() which
baseline-aware containers can use to allocate children with a specific
baseline, either one inherited from the parent, or one introduced due
to requested baseline alignment in the container
itself. size_allocate_with_baseline() works just like a normal size
allocation, except the baseline gets recorded so that the child can
access it via gtk_widget_get_allocated_baseline() when it aligns
itself.
There are also adjust_baseline_request/allocation similar to the
allocation adjustment, and we extend the size request cache to also
store the baselines.
Setting this means baseline aware containers should align the widget
according to the baseline. For other containers this behaves like
FILL.
In order to not suprise old code with a new enum value we always
return _FILL for _BASELINE unless you specifically request it via
gtk_widget_get_valign_with_baseline().
Instead of having three different boxes and style classes, we can just
get away with the regular background box, plus a window-frame, which
contains the external frame, together with the window drop shadows.
GtkWindow now has special code to ensure the backing actual window is
allocated big enough to accomodate the shadows (using the shadow size
calculations introduced in the previous commit). We also use the margin
value to determine the size of the invisible borders (which can then be
different than the shadow).
This reverts commit f4438a1ffc.
The calculation of the delta between parent and child widget
is required in order to automate height-for-width and width-for-height
requests for various GtkBin widgets.
GtkButton, GtkCheckButton, GtkRadioButton, etc, all have different
requests for space around the content which can not be satisfied
with a simple calculation of GtkContainer border-width.
Add separate GtkStack and GtkStackSwitcher widgets that are an
alternative to GtkNotebook. Additionally, GtkStack supports
animated transitions when changing pages.
These widgets were initially developed in libgd.
We still need to respect this border value even when we're not running
under CSD, since we support setting a custom titlebar in all cases.
The border/style magic in gtk_window_draw() really needs to be separated
out into logical pieces soon, but for now let's keep a consistent
behavior with the previous code.
Instead of reparenting the content, use input-only windows to
set cursors and capture clicks on the window frame. This avoids
some of the problems that were introduced by content_window, such
as black flashes and non-working opacity.
Since ::drag-leave gets emitted before ::drag-drop, we can't just remove the drop feedback row
in drag-leave, as we *need* it during drag-drop. So, we use the same trick as in testdnd.c - we
install a timeout handler in our drag-leave callback, and remove the feedback in the timeout callback.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This lets us keep the new_bookmark_index untouched even when the drop state goes from armed to unarmed.
That will in turn let us drop in the right place...
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This commit is very similar to 8c8853a1f5
We update the keynames.txt file from gdkkeynames.h, and we update
keynames-translate.txt to include all the keysym names that we want
to have translations for. Also strip the XF86 from the translatable
keysym names, since we are returning those names now from
gdk_keyval_name().
keyname-table.h is regenerated from these updated files.
We used to divide the row in thirds vertically, and use the outer thirds for GTK_TREE_VIEW_DROP_BEFORE and AFTER, respectively.
Now we use *fourths*. This is so that we get equal areas for these:
GTK_TREE_VIEW_DROP_BEFORE
GTK_TREE_VIEW_DROP_INTO_OR_BEFORE
GTK_TREE_VIEW_DROP_INTO_OR_AFTER
GTK_TREE_VIEW_DROP_AFTER
This makes hovering tree rows much more positive.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This makes the feedback accurate and without hysteresis. Haven't I written this code ten times before?
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Instead of GdkDisplay::init, only add the display to the display manager
in GdkDisplay::opened. This avoids spurious changes of the default
display in gtk_init() when we're trying to find the one that works and
try to open lots of different ones.
Commit dcad786ba0 introduced "tg" but
didn't add po-properties/tg.po, which is necessary in order for the
build to not break.
Therefore I'm removing tg until the file is added.
For now it is the old, simple call to gtk_tree_view_set_drag_dest_row(). We'll do something
fancier in the following commits.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We want to show a little animation when a DnD operation is happening and the user hovers
between existing bookmarks. The animation should indicate the user that he's about to
create a new bookmark from the file right there.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
It's pretty useless to make a menu without actions behind it and people
who are using gtk_menu_shell_bind_model() directly are probably not
interested in doing it the GtkApplicationWindow way (so they won't get
the "app" and "win" groups for free). People are going to need to call
gtk_widget_insert_action_group(), so mention this in the docs to help
them along.
This makes Wayland and X11 no longer call into XKB and libX11 for these
functions but use GDK's own copy of these functions, just like the
win32, quartz and broadway backends.
A function was doing nothing but calling a function that was in its own
source file doing nothing but calling a function in its own source file
that did nothing.
This is the new GtkPlacesSidebar widget, which is the sidebar used in
GtkFileChooser to display a list of places/folders that the user may
want to use. File managers are encouraged to use this widget for
their own global list of folders.
This is Tristan's *excellent* work, minus the old code for the shortcuts bar - that is all done
in GtkPlacesSidebar now.
The UI gets loaded from a Glade resource; most of the old code to create the UI by hand is gone.
There is still code for save_widgets_create(); this needs to be moved into the UI file, but it
is not a big deal.
gtk_file_chooser_default_init() calls a new post_process_ui() that takes care of all the things
that cannot be done directly in Glade.
Although GtkPlacesSidebar is a public widget, we can't have that in Glade's general catalog
as this branch is not merged into GTK+ proper yet. We'll move the widget to Glade's
catalog when this is done.
This is another step towards making GdkDisplayManager backend-agnostic.
Most of the backends profit from this as their atom implementations
where generic anyway - x11 needed that to allow multiple X displays and
broadway, quartz and wayland don't have the concept of displays.
The X11 backend still did things, so I only #if 0'd some code but did
not actually update anything.
Printing a web page without window.print (which still segfault),
that is Ctrl+P is fixed (does not attempt to execute the
source_changed_handler on a printeroptionwidget that has been
destroyed) by disconnecting this handler in the printeroptionwidget
finalize.
https://bugzilla.gnome.org/show_bug.cgi?id=696622
If the GtkPrintJob is freed too early when the surface has been created
but the job hasn't been sent to the printer, it's possible that the
file print backend tries to write to the io chaneel when it is already
closed. This produces runtime critical warnings:
GLib-CRITICAL **: g_io_channel_write_chars: assertion `channel->is_writeable' failed
https://bugzilla.gnome.org/show_bug.cgi?id=685420
It can happen if the io channel has been closed. In that case
g_io_channel_write_chars() returns early because of a g_return macro
that checks if the io channel is writable. When returning from g_return
macros, the bytes written output parameter is not updated and the error
is not filled, so the error is not detected and the written variable is
used uninitialized. We should check the return value of
g_io_channel_write_chars() to break the loop.
https://bugzilla.gnome.org/show_bug.cgi?id=685419
This reverts commit 666d10ec76.
This change severely broke any treeviews without horizontal
scrollbars. Basically, ellipsization never kicks in, and instead
the treeview content just extends outside the visible area,
rendering it inaccessible. This broke e.g. the control-center
keyboard shortcuts panel, the gnome-disks device list, etc etc.
In the case that the client is started directly by the compositor the
WAYLAND_SOCKET environment variable is set containing the fd to use that was
created by a socketpair.
This environment variable is consumed by a call to wl_display_connect so a
second call will not take advantage of it.
https://bugzilla.gnome.org/show_bug.cgi?id=697673
The creation is async, and the sidebar could be destroyed while the D-Bus proxy is being created.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Having the changes for composite widget templates makes it impossible
to merge the places-sidebar branch. So, we will merge that branch,
and *then* apply the changes for composite templates.
This reverts commit bf909f5615.
If gdk_window_flush_outstanding_moves() creates new update area
we handle this directly in the same draw to avoid flashing.
This mainly affects win32 as X11 does its exposes from moves async.
However, its important for win32 since ScrollDC seems to sometimes
invalidate (and not copy) unexected regions.
http://bugzilla.gnome.org/show_bug.cgi?674051
Rather than set the window update region and repaint this region
when we get a WM_PAINT we just directly add it to the update
region. No need to roundtrip via win32.
This lets us also make sure we do this drawing in the same update
cycle. This seems especially important on Win7, because ScrollDC
seems to act kind of weird there, not using bitblt in areas where
it seemingly could, which makes scrolling look really flashy.
http://bugzilla.gnome.org/show_bug-cgi?id=674051
On crossing events resulting from moving windows (eg. workspace switch),
deviceid equals sourceid, so make those reset scroll valuators on all
slave devices to avoid misleading jumps in scroll events
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=690275
Non-inset box-shadows are no longer ignored by the GTK+ theming engine,
outset shadows are supported.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
Adds conditional code paths to GdkCssShadowValue for painting outset
shadows, and allows shadows to be applied in two passes (first outset
then inset). This can be used to draw csd shadows in outer window
borders.
https://bugzilla.gnome.org/show_bug.cgi?id=695998
Signed-off-by: Rob Bradford <rob@linux.intel.com>
Under Wayland we don't know the absolute position of the device but there are
some API calls that expect to get an root window position. Previously we were
not assigning any value to these out parameters potentially leaving the values
undefined.
This change returns the current surface relative position of the device.
This patch can be considered a leftover of commit 6f607fc8b4 ,
replace the no longer existing function with the GDK function
meant to replace it.
This was noticeable on regular clipboard operations in quartz
Don't just look at previously remembered sizes, also look at the current
size.
This is useful for cases where the window was resized by the user or WM
and not by the application itself.
https://bugzilla.gnome.org/show_bug.cgi?id=696882
We don't want to remember sizes in the not resizable case. Also a
function named "guess_default_size" should not look at previous sizes,
it should guess.
Old code assumed the size was stored in widget.allocation. This is no
longer true as the allocation is cleared upon hide. However, we store
the last configure request, and that one tracks the last size, so we can
just use that number.
Sometimes things are so easy - once you figure them out...
https://bugzilla.gnome.org/show_bug.cgi?id=696882
As the first composite widget in GTK+, this patch also
adds some Makefile mechanics to list the ui files as
dependencies of the global GTK+ resources, and adds the
initial test case where composite classes should be tested.
This catalog can be used to work with GTK+'s private widget types,
this patch exposes a private function gtk_glade_catalog_init() which
Glade will use for the sole purpose of initializing some private widget
types in GTK+ that are referenced from various GTK+ composite widget
xml files.
This commit implements the needed machinery for GtkWidget
to build it's composite content from GtkBuilder XML and
adds the following API:
o gtk_widget_init_template()
An api to be called in instance initializers of any
GtkWidget subclass that uses template XML to build it's components.
o gtk_widget_class_set_template()
API to associate GtkBuilder XML to a given GtkWidget subclass
o gtk_widget_class_automate_child()
API to declare an object built by GtkBuilder to be associated
with an instance structure offset and automatically set.
o gtk_widget_get_automated_child()
API for bindings to fetch a child declared to be automated by
gtk_widget_class_automate_child(), for the case where bindings
do not generate GObjects under the hood and cannot use structure
offsets to resolve composite object pointers.
o gtk_widget_class_declare_callback[s]()
Declare static functions to be used in signal callbacks from
a given class's template XML
o gtk_widget_class_set_connect_func()
API for bindings to override the signal connection machinery
for a given GtkWidget derived class.
This patch allows properties of type G_PARAM_CONSTRUCT to be set
on internal children or explicitly constructed objects (built
with <constructor>) while previously, G_PARAM_CONSTRUCT properties
being set on already constructed objects would result in an misinformed
warning that "construct-only properties cannot be set".
G_PARAM_CONSTRUCT_ONLY properties are still refused as parameters
to already constructed children.
This adds the definition of the <template> tag with some documentation
on the variant of the format.
_gtk_builder_extend_with_template() is to be used while GtkContainer
builds from composite templates. A couple of error codes are also added
to handle a few new possible failure cases.
DTD Files gtkbuilder.rnc and gtkbuilder.rng have been updated to include
the new <template> tag and it's attributes.
In preperation for composite objects, for better encapsulation
the following APIs are added to allow handling of signals declared
in the XML with callbacks declared statically.
o gtk_builder_add_callback_symbol[s]()
Adds a symbol to the internal symbol hash
o gtk_builder_lookup_symbol()
Looks up a symbol, exposed in case added symbols are used
in conjunction with gtk_builder_connect_signals_full()
The default implementation of gtk_builder_connect_signals() now
does not have a strong requirement on GModule (or a strong requirement
on symbols being declared in the global namespace). Instead GModule
is used as a fallback in the case that symbols are not declared
explicitly.
Some utilities such as GIR and gtk-doc, initialize class vtables without
initializing GTK+, with composite templates accessing resources this
causes a hand full of unneeded warnings.
The workaround for now is the use a private function _gtk_ensure_resources()
which is both called while initializing GTK+, and at the beginning of
gtk_widget_class_set_template_from_resource() (the private function
ensures that the resource will only ever be registered GOnce).
Deprecate gtk_widget_push_composite_child, gtk_widget_pop_composite_child,
gtk_widget_set_composite_name, gtk_widget_get_composite_name.
This API is just bloat and was never useful, this patch deprecates
it and removes all internal calls to the composite child APIs
The is_modifier field is supposed to be set if the key
would act as a modifier, not if any modifiers are currently
active. To fix this, introduce a private
_gdk_wayland_keymap_key_is_modifier function.
At the same time, make the hardware_keycode field in key
events actually contain the hardware keycode, not a copy
of the keyval.
When the GtkActivatable sets the related action, the activatable
properties are sync'ed. In this case the null check is important
to avoid updating from a NULL action.
While GtkRecentChooser implementations accept for the "filter" property
to unset the current filter, the API fires an unneeded assertion.
This patch removes the assertion.
The test case uses a weak ref to assert objects can finalize,
and then spins the main loop shortly after finalizing to assert
that the finalized object did not leak GSources into the main context
causing latent crashes.
We always emit direction-changed when we get a new keymap, but
for state changes, we compare old and new direction and only
emit the signal when the direction actually changes.
When the window has no mnemonics modifier set, as in the case of a
GtkMenu, never schedule a display of mnemonics on focus-in.
Previously, for those windows, the GdkModifierType mask fetched from the
device would typically have been zero, leading to the
mnemonic_modifier == (mask & gtk_accelerator_get_default_mod_mask ())
check to succeed, so we would always trigger a display for popup menus.
https://bugzilla.gnome.org/show_bug.cgi?id=697144
Don't mention "auto mnemonics", since those methods are purely about
scheduling a delayed display, and that makes understanding the code a
bit harder.
https://bugzilla.gnome.org/show_bug.cgi?id=697144
Some functions in gtkstyle.h were overlooked when we added the
GDK_DEPRECATED macros.
Also add IGNORE_DEPRECATIONS to the few remaining callers of those
functions.
First of all, that call is deprecated. Second, we don't have RC styles
anymore. Third, what that function does today is invalidate style
contexts, but that happens automatically when setting the screen on the
style context later.
So this function is completely unnecessary.
Don't just create a menushell and populate it with random data -- verify that
the resulting menu layout is actually correct.
This is introduced in a separate commit because the old code was failing this
part of the test.
https://bugzilla.gnome.org/show_bug.cgi?id=696468
GtkMenuTracker folds a nested structure of sections in a GMenuModel into
a single linear menu, which it expresses to its user by means of 'insert
item at position' and 'remove item at position' callbacks.
The logic for where to insert separators and how to handle action
namespaces is contained within the tracker, removing the need to have
this logic duplicated in the 3 or 4 places that consume GMenuModel.
In comparison with the previous code, the tracker no longer completely
destroys and rebuilds menus every time a single change occurs. As a
result, the new gtkmenu testcase now runs in approximately 3 seconds
instead of ~60 before.
https://bugzilla.gnome.org/show_bug.cgi?id=696468
It's more logical to have the GtkTextAttributes and GtkTextAppearance
structs together. And it creates a separation between gtk_text_tag and
gtk_text_attributes functions.
https://bugzilla.gnome.org/show_bug.cgi?id=697048
We can get G_IO_HUP and G_IO_IN at the same time, if the compositor writes
data to us and then closes our connection. Make sure that we dispatch events
always if we have G_IO_IN and then error out if we get G_IO_HUP after that.
This way we don't have to reopen all the time for pure updates,
and we can immediately unlink the shm file to avoid "leaking" them
on improper shutdown.
We now only update surface data after we have painted. Before we painted
in an idle, which meant we might send black data some times if we e.g.
resized the window and had not painted yet. Also, it means we're updating
less often to the daemon, saving resources.
We still have to queue a flush in the idle for non-draw operations,
otherwise e.g. resize of a toplevel will never be flushed if the clock
is frozen (e.g. during toplevel resize).
We don't want to update the window size on configure event, only
the position, as the size is client side controlled. We were
updating to an old size during resizes which causes us to send
surfaces of the wrong size to the daemon.
The following CSS would infloop:
@define-color self @self
as it would infinitely lookup the color named "self" and try to resolve
it. This patch adds detection of such cycles to the resolve function by
keeping a list of currently resolving colors in the cycle_list variable.
If a named color references a nonexistant named color, we didn't catch
that error and ended up crashing on a NULL-dereference.
This crashed Boxes, because its CSS referenced values from the theme
that didn't exist in any theme.
The cursor buffer is only non-null when a cursor is created from pixbuf,
so it is not necessary to keep track of whether to free this buffer on
finalize.
By keeping a pointer to the wl_cursor struct in GdkWaylandCursor, it is
no longer necessary to duplicate cursor data (width, height, hotspots,
etc.) between wl_cursor and GdkWaylandCursor.
We were calling gtk_overlay_child_allocate() both in realize
and in add as we wanted to create and position the child windows
for the widgets. However, this call also actually called
gtk_widget_size_allocate() on the child, which it shouldn't. In some
cases the overlay is realized before being allocated, and thus it
will allocate the child at 0x0 which is an invalid size for it to be in.
In particular, if the child has margins set this will result in negative
allocations and warnings.
This fix splits out the allocation computation so that
gtk_overlay_create_child_window can use it without callers
having to call gtk_overlay_child_allocate() to move the windows.
https://bugzilla.gnome.org/show_bug.cgi?id=696623
Instead of maintaining the init refcount in regular event handlers that can
fire in case of hotplug or mode changes, use a dedicated sync callback
to wait for roundtrips.
If a window is overlapped by a layered (i.e. partially transparent)
window then that region will not disappear from the native window clip
region. This lets us handle compositing multiple layers of windows.
For native subwindows this doesn't really work. For them we apply the
clip region as a shape to the native window which lets us have client
side windows overlapping the native window. However, with the addition
of the layered stuff the "overlapped-by-alpha-csw" part got broken, as
this area is not removed from the clip region of the native window.
We fix this by also removing the layered area when applying the shape.
This means alpha and alpha backgrounds don't work over native windows,
but there is not much to do about that.
https://bugzilla.gnome.org/show_bug.cgi?id=696370
The global_removal argument is the _name_ of the object.
We were comparing it to the _object id_ of the object.
To fix this, store the name at the time the object is bound.
We need to be a bit more careful when updating the screen
size - the code that was there would not do the right thing
if e.g. the width of one monitor was reduced.
We use a ref-count mechanism to track whether parts of the init sequence
still needs round trips to receive remaining initial state. Typically
we need a couple of roundtrips total to get the global list, then the
input and output configurations, but with the ref-count we avoid making
global assumptions like that.
https://bugzilla.gnome.org/show_bug.cgi?id=696340
In commit 4e41577b, we are using g_content_type_is_a() to determine how
to display the demo resources in the right pane of the gtk3-demo program.
Use g_content_type_get_mime_type(), so that we can obtain the mime
type of the demo resources on all platforms, as g_content_type_guess()
returns a platform-specific string, as
https://developer.gnome.org/gio/2.35/gio-GContentType.html states.
As .ui files and .css files are normally registered with a different mime
type string on Windows, check for those strings as well.
This will ensure the demo resources can be properly displayed on Windows
as well.
In avahi_request_printer_list() a new connection to the DBus system bus
is started asynchronously, but it's not cancellable and it's not taking
any reference of the GtkPrintBackendCups. This means that when the
callback is called, the object might have been destroyed already. We can
just pass the cancellable created and check for the cancelled error in
the callback before trying to use the GtkPrintBackendCups. The code to
cancel avahi operations and to unsibscribe from the DBus signals has
been moved from finalize to dispose to make sure it happens as soon as
possible.
https://bugzilla.gnome.org/show_bug.cgi?id=696553
If GtkPrintBackendCups is finalized and cups_get_printer_list hasn't
been called, g_object_unref is called for the GDBusConnection pointer
that is NULL. Use g_clear_object() instead.
https://bugzilla.gnome.org/show_bug.cgi?id=696546
Allow to set a GdkWindow to use a custom surface instead of a
wl_shell_surface. It allows to register the surface as a custom type
with some Wayland interface.
https://bugzilla.gnome.org/show_bug.cgi?id=695861
When no GDK backend can be initialized (either because
GDK_BACKEND has been set to the wrong value, or the backends
are simply not included), the expectation is that gtk_init_check
should return FALSE, not error out.
This commit makes it so, by using gdk_display_manager_peek
instead of gdk_display_manager_get in code paths that are used
during initialization.
The GDK model for keymaps expects the keymap object to stay
around and emit a ::keys-changed signal. So, do that. This
should make layout changes work, but it remains untested since
weston does not support layout changes at runtime.
At the same time, plug a memory leak where GdkWaylandKeymap
forgot to free its xkb objects in finalize.
https://bugzilla.gnome.org/show_bug.cgi?id=696339
For introspection scanning which ends up calling class_init() which in
turn calls into the keybindings code, we can just use the fallback
keyval conversion code.
https://bugzilla.gnome.org/show_bug.cgi?id=696457
This is an (unintentional) side effect of my changes to GtkTreeView's
get_preferred_size() implementation. It seems odd to me that
GtkTreeView directly determines its own size when inside a
GtkScrolledWindow, but since it does, it should be using its natural
size, not its minimum size.
With this commit, we pick up xft settings from GSettings
as well. Among other things, this makes the Large Text
setting work. Still to do: pick up fontconfig changes without
having all clients use up inotify watches for all font
directories.
Add GInitable interface with a default implementation that always
succeeds. This allows backends to override the GInitable implementation
and add their own checks to determine if the backend can be loaded. If
a backend cannot be loaded, GDK can attempt to load the next available
backend.
Since backends may need to read any relevant options (such as the
display flag) to determine if they can be created successfully, this
patch also removes calls that attempt to create the display manager
before the options have been parsed.
https://bugzilla.gnome.org/show_bug.cgi?id=694465
The check for GDK_CURSOR_IS_PIXMAP was ineffective, since _all_
cursors have this type, from the looks of it. Instead, store
buffer ownership information separately.
These might be candidates for a future settings interface; until
then, we use GSettings directly. Note again that we are careful
to avoid a dependency on GNOME schemas.
Key repeat under X is not affected by modifiers. And on some systems
(e.g my Thinkpad), NumLock is permanently on, rendering key repeat
nonfunctional. This commit changes the Wayland backend to do
key repeat regardless of modifiers.
http://bugzilla.gnome.org/show_bug.cgi?id=695497
This make the nice 'snap off' feature of gnome-shell work
with client-side decorations. weston moves the maximized window
around, which is less ideal...
We already set it in init, so this is just redundant.
The additional window-content style class here is needed so that we can
distinguish between the full X window background and the background for
the actual window contents.
Commit 0d9d808217 fixed the hotspot issue,
but commit f2cc52fddd then optimized away
cursor changes a little too aggressively. We always need to set the
cursor on enter. Make sure we clear the current cursor on leave so we
don't think it's already set on the next enter.
https://bugzilla.gnome.org/show_bug.cgi?id=695512
Until we figure out where we want to go with settings under
Wayland, this makes GTK+ applications a lot easier to deal
with under Wayland.
Note that we are careful to deal with the absence of schemas,
so this does not introduce a dependency on GNOME settings.
wl_pointer.set_cursor is rejected if the serial number doesn't match
the enter serial number for the wl_pointer. We passed the right serial
number when setting the cursor surface in response to the enter event.
Later set_cursor requests fail, but we can still attach new buffers to
our cursor surface, which is why the cursor changed, but the hotspot
didn't update. Clicking in the decoration results in a leave/enter pair
which triggers wl_pointer.set_cursor with the right serial. That's why
clicking the decoration sets the right cursor.
https://bugzilla.gnome.org/show_bug.cgi?id=695512
Prevent the new window dragging code from interfering with
selection of colors on button release, by handling button
presses we care about instead of letting them bubble up to
the window.
Partial fix for
https://bugzilla.gnome.org/show_bug.cgi?id=695493
We need to pass the delta between the old and new hotspot
when attaching the new cursor surface, to keep the hotspot
at the same position. We can't deal with this in the compositor,
since the set_cursor call already overwrites the old hotspot,
so the information is lost by the time the attach happens.
Unfortunately, we can't query the initial hotspot from
the compositor, so the first cursor change will make the
hotspot jump.
https://bugzilla.gnome.org/show_bug.cgi?id=695512
We were not translating event coordinates to the toplevel
window, thus the regions we determined were not right.
We were also not respecting the maximized state, and we
were unnecessarily refusing to handle events when not decorated.
https://bugzilla.gnome.org/show_bug.cgi?id=696197
If the style changes before we're realized we will delay the
style-updated signal until realize. However, we then lose
the changes bitmap. This means that gtk_widget_real_style_updated()
must treat a NULL change as "everything changed" and queue a resize.
Apparently time_t is used in gtkrecentmanager.h, which is a special type
that could not be recognized when Gtk-3.0.gir is built. Judging from the
ast.py from the gobject-introspection package, we can define time_t as
long, and this will allow pygobject to load the Gtk module from
gi.repository.
The code was always adding a label widget as a child, but
then skipping over it in forall if a custom_title was present.
This confuses internal logic of GTK+ which assumes that it
can iterate over the entire widget hierarchy with forall,
to maintain state. Fix this by destroying the label when
a custom_title is set, and recreating it as needed.
Use separate fields for saving the window dimensions prior to fullscreening
and maximisation. Then use those fields to restore the window dimensions from.
The function update_window_buttons shows or hides the title header after it
has finished updating the visibility of the various buttons. Unfortunately
this
conflicted with the hiding of the title done when going fullscreen.
This solves the problem and fixes the rendering of fullscreen applications by
using update_window_buttons to control the visibility of the box in the
fullscreen case.
Requests are not limited in size by BroadwayRequest, as
BroadwayRequestTranslation can be of variable size. No need
to copy the request anymore though, because requests are aligned
now.
This reverts commit 30a1a79322.
This turns out to be unnecessary when you can set the titlebar
on the window and let GtkWindow handle the events. As a benefit,
we get the window menu on custom titlebars for free.
A new function that sets a custom titlebar on a GtkWindow.
With client-side decorations, the custom titlebar simply
replaces the one that GtkWindow would otherwise create itself.
With traditional decorations, we tell the window manager
to just decorate the window with a border. This works ok
at least with metacity and mutter.
With recent changes in attach semantics, we always need to attach before
committing. Without this changes to the window contents to not get reflected
in the content of the surface.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
We currently use this information to display the title
string in the window list of the desktop shell.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
For csd, we were subtracting the border width one too many
times from the child height, causing clipped off content e.g.
in the 'Properties' window in testgtk.
To clear the tooltip one is to set the tooltip to NULL. Though
the GtkEntryAccessible expect this tooltip to not be NULL in
gtk_entry_accessible_notify_gtk (already handling this case
in its _init).
Fixes:
** (epiphany:23914): CRITICAL **: atk_object_set_description: assertion
`description != NULL' failed
when epiphany g_object_set the entry icon tooltip to NULL (clear the
tooltip) in its find bar.
https://bugzilla.gnome.org/show_bug.cgi?id=695375
To extract the mnemonic key value, the string must contain the
underscore. But when the "gtk-auto-mnemonics" setting is true and when
the Alt key is not pressed, the underscore must not be displayed. The
problem was that the 'new_str' variable was used for both purposes:
extract the text to display, and extract the accelerator character.
When the underscore must not be visible, the underscores were removed
from the 'new_str' variable before extracting the accelerator character.
Now there are two strings, one for each purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=674759
For now, nothing changes, we're using the sum of inner and
outer border everywhere.
In the future, we will make the inner border the visible
window frame, and the outer border the shadow/resize border.
Add a style property to control the presence and order of
window buttons. We allow buttons at the left and right side,
they can be specified like this: icon,close:minimize,maximize.
Also, change the default button layout back to have just a close
button on the right, use icons in buttons, and set style classes
on the buttons, to allow better theming.
Add window-minimize, window-maximize, window-restore and window-delete
icons to the builtin icon theme. These will be used for icons in
the window buttons, and the expectation is that the icon theme
will provide icons matching the desired decoration style.
window-delete is used instead of window-close, since window-close
is also used for GTK_STOCK_CLOSE, and the two may require different
styles when used inside the application vs in the window frame.
Hide the close button if the window is not deletable, hide the
maximize button if the window is not resizable, and hide all
buttons if the window is a dialog.
Update buttons when the window state changes.
Client side decorations can be enabled on non-Wayland platforms by
setting the GTK_CSD="1" environment variable.
We must ensure we have a GdkVisual that has an alpha channel since
the decorations rely on transparency. If we cannot get a visual with
an alpha channel then we do not enable client side decorations.
Otherwise we'll potentially get some background sticking through our rounded
corners in our decorations. The actual background will get drawn as part of
the decoration drawing.
This change comprises four main parts:
* the creation of the widgets that form the decorations,
* implementation of get_preferred_height/width, and the for_width/for_height
variants,
* taking the decorations into account when allocating,
* and drawing the decorations themselves.
Kristian did the bulk of the original work on this but any bugs are almost
certainly mine through the many refactorings and rebasings.
Update the documentation and users of this function to handle
the future case that that we have some internal decorations to the window and
useable allocation is thus smaller.
By having a separate out parameter there is no need to have an in/out function
and allows for greater robustness.
The current implementation simply returns the allocation provided.
For gtk_text_iter_get_char(), due to the "Returns" at the beginning of
the description, the description was not visible. So the first sentence
has been reworded.
If there are rows that contain only spanning children,
our algorithm was unnecessarily distributing extra space
to the other rows, even if they contain only non-expanding
children.
We improve the behaviour by treating rows containing only
spanning children as expanding.
... instead of taking the last one we find. This is necessary as
attached widgets (mostly menus) can be attached to an invisible widget,
but we still want to invalidate styles for them.
https://bugzilla.gnome.org/show_bug.cgi?id=695772
When setting new text on the label, the text-changed::delete signal
needs to be emitted before deleting the text (so that atk-bridge can
query the old text) while the text-changed::insert event needs to happen
afterwards (for the same reason). The old code using the notify signal
was only emitted after changing the text.
Converts usage of Avahi API to DBus calls. This change allows
us to remove dependency on avahi-gobject and avoids of possible
circular dependency.
Lists printers if Gtk+ is compiled with CUPS 1.6 or newer.
The cursor theme and size settting code was ifdefed to only
be compiled with the X11 backend, but it didn't check for
running under X at runtime. Fix that.
http://bugzilla.gnome.org/695495
Both of them started to make use of round(), a C99 function. So, include
fallback-c89.c to provide a fallback implementation for round() for
compilers that don't have round()
https://bugzilla.gnome.org/show_bug.cgi?id=694339
Change of plans to match the tests from the previous commit.
The state of the underlying dialog is never reflected by GtkFileChooserButton's API,
as the dialog is a transient thing. The file chooser button only updates its state from the dialog,
and reflects the dialog's state, when the dialog has been confirmed and dismissed by the user.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We used to have numeric names, which are a pain to maintain when new tests are added.
Now we have a real nomenclature (see the comment at the beginning of the open-dialog-cancel-* tests),
which lets us see easily if we have tested all the combinations.
Also, added all the combinations that were missing and removed redundant tests.
Not all the tests pass currently.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The idea is that the button will only update its state of the selection and current folder
when changes to those are done either by the calling program (with the filechooser's API)
or when the user actually confirms and dismisses the underlying GtkFileChooserDialog.
If the user makes changes to the dialog but has not dismissed it yet, those changes
will not be reflected in the button (as one would expect).
This commit also makes sure the current-folder-changed and selection-changed signals
are emitted at the right times.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We only emitted that signal when the selection changed through the underlying GtkFileChooserDialog.
To do this when the dialog is not active and the selection is changed by the calling program
(instead of by the user), we need to wait until the GtkFileChooserButton's UI has been updated
via an async callback from GIO. So, we keep track of whether an entry point into the
button's API caused a programmatic change in the selection.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This should let tests complete faster. Also, this will let us test
that the correct signals are actually being emitted.
The tests now fail, as the signals are not being emitted when they
should.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We only FORCE_INVALIDATE when something weird changes that the CSS
machinery can't detect. But now that our style_updated functions skip
recomputations when some properties don't change we want to make sure
these recomputations are still run. So we just claim all properties
changed.
http://bugzilla.gnome.org/show_bug.cgi?id=695482
And also explicitly remove pointer/keyboard grabs from the display.
Whenever the grab is reported lost, we should popdown the combobox, so that the
GDK_WINDOW_TEMP window is hidden and removed from the toplevel, as done with
the menu for example.
Leaving the GDK_WINDOW_TEMP window open when re-activating the application
triggers several issues in the win32 backend, due to restacking windows of the
non-toplevel group into the toplevel group:
https://bugzilla.gnome.org/show_bug.cgi?id=695200
Something is causing the GtkFileChooserDialog to be resized really small on the second time it is run
during each test for GtkFileChooserButton. So as a temporary hack we set it to 500x500 pixels on
the second run, so the size allocation code doesn't bomb on us.
The currently-selected file *is* the selection even in SELECT_FOLDER mode. Do not confuse this
with the current folder.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
gtk_tree_view_column_unset_tree_view() resets column->priv->tree_view to
NULL.
The function is called when a column is removed, but later from the same
function we would call _gtk_tree_view_column_unrealize_button(), which
expects column->priv->tree_view to be != NULL, causing these critical
warnings
Gtk-CRITICAL **: gtk_widget_unregister_window: assertion
`GTK_IS_WIDGET (widget)' failed
This commit moves the call to unset the tree view after the button is
unrealized.
https://bugzilla.gnome.org/show_bug.cgi?id=695473
We assumed that we didn't have to update the combo box if the dialog got cancelled,
as it should simply retain its previous contents. But this assumption doesn't work
as the dialog is brought up with the 'Other...' item - we don't want the
combo box to keep showing 'Other...' if the dialog is cancelled.
The test from the previous commit now passes.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
There is this bug:
1. Start with a file chooser button in SELECT_FOLDER mode, and select a folder from the combo box.
2. Click on the button's combo box, select 'Other...'
3. You get the file chooser dialog. Cancel the dialog.
4. The file chooser button's combo box still shows 'Other...' instead of
showing the selection from (1).
This is a test to ensure that the original selection is restored.
The test fails right now.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This is surprisingly tricky, since the (None) item *has* to be a visible item while
the combo box is *not* popped up, so that it can show its contents. But the item
has to be *not* visible when the combo box is popped up.
Also, update the whole button's selection, not just the underlying dialog's, when
the combo box changes its selection - based on a patch by Paul Davis in
https://bugzilla.gnome.org/show_bug.cgi?id=691040#c20
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This way the internal labels will show the correct selection even if nothing
has been selected programmatically.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We didn't change it when the file chooser button's dialog was inactive, and so
the actual file chooser button would not visually reflect the current selection.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We do some gymnastics to pull the string out of the GtkButton or the GtkComboBox that is
being used in GtkFileChooserButton to show the current selection when the dialog
is inactive - namely, we look for the subwidget with the correct ATK role, and pull its
accessible name.
Currently the test fails; this is https://bugzilla.gnome.org/show_bug.cgi?id=691040#c18
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Integrate the utility projects to build the introspection files into the
main solution files, so that one can build the introspection files from the
IDE. This is not built by default, so one can build the introspection
files if he/she chooses to do so.
Add Windows .bat and Python script to call g-ir-scanner to build
introspection files for Visual Studio builds. This will read from the
autotools files using Python REGEX functionality to determine the headers
and sources for g-ir-scanner to process, so the autotools files will not
need to be updated except to distribute the necessary files. Thils will
also enable one to build introspection files on Windows without using a
BASH-style shell such as MSYS.
Also add an utility Visual Studio project to call the Windows .bat to
build the introspection files for GTK+/GDK, for convenience.
In the case of checking for local_only, g_file_is_native() is not useful, since it
will return FALSE for something in a FUSE mount.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Since FUSE locations can be handled safely by applications show these mounted locations regardless of whether gtk_file_chooser_set_local_only()
is set to TRUE
https://bugzilla.gnome.org/show_bug.cgi?id=586367
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.
Now, even if the handles being rendered are small, the handle touch
input shape will be as wide as the visible part of the rendered asset, and
high enough to cover both the handle and the height of the line where
the selection bound is.
Also, make handles have the same virtual distance to the line top/bottom
when a drag starts, so the handle doesn't jump to another line after a
too short threshold.
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 block signal handlers areound GtkEntry signal emission and if those
signals get used to call functions on the completion that cause a
reconnection of the signals, then the reconnected signals will not be
blocked anymore (so they might get emitted?) and unblocking the old
signal id will later cause warnings.
Fixes spurious warnings in gtk/tests/filechooser tests.
When setting contents of the clipboard and ownership or user data changes, we
end up calling clipboard_unset() to fully cleanup the previous clipboard state.
This call will itself call clear_func() for the previous user_data, and always
reset both 'get_func' and 'clear_func' to NULL.
So it's actually not possible to have 'get_func' being non-NULL once we have
called clipboard_unset(), so just remove that condition check and the code
inside.
https://bugzilla.gnome.org/show_bug.cgi?id=694924
icon_info_dup() is now called also for GtkIconInfos that already have
a pixbuf, so we must make sure that we correctly carry that from
the original icon_info to the copy.
This is checked by GIO for us now.
Also, it's generally just a bad idea spawning error dialogs from inside
a library on top of other dialogs: lesson learned.
https://bugzilla.gnome.org/show_bug.cgi?id=675333
If you tried to lookup an icon that was not emblemed, and then looked up
an emblemed icon with the same base, we would override the iconinfo adding
the emblems inline. Later, when the icon finished rendering, inside
gtk_icon_info_load_icon_finish, we would copy the result from the duplicate
(which did not include the emblem infos), but the icon would still fail the
assertion, because emblems infos are present but emblem_applied is false
(they were not requested in the first place!).
Solve this by avoiding the overwrite on a cached iconinfo, and instead duplicate
the iconinfo before adding the emblems. It is expected that another layer
of caching (such as StTextureCache in gnome-shell) will take care of avoiding
multiple rendering of the same icon+emblem combination.
https://bugzilla.gnome.org/show_bug.cgi?id=694968
Show printers advertised by avahi on local network. CUPS
backend now looks for _ipps._tcp and _ipp._tcp services
offered by avahi. If it finds such a service (printer)
it requests its attributes through IPP_GET_PRINTER_ATTRIBUTES
ipp request and adds it to the list of printers. Such printer
behaves like a remote printer then.
If an avahi printer is a default printer then it is considered
default by the backend only if there is no local or remote
default printer.
This functionality is enabled when building Gtk+ with CUPS 1.6
or later because it replaces browsing protocol removed in CUPS 1.6.
https://bugzilla.gnome.org/show_bug.cgi?id=688956
Instead of using the secondary slot for both clear and search. This
Makes it possible to use the search icon for actions regardless of
whether text has been entered, makes it possible to use the primary
icon to indicate search status, allows us to indicate the purpose
of the entry even if text has been already entered.
https://bugzilla.gnome.org/show_bug.cgi?id=694990
The last change fixed the windowed widget case but broke
opacity group handling for windowed child widgets. This fixes
up the code by making sure we norender_children in when there
is an opacity group.
This also cleans up the comments about how this works to something
that is hopefully more understandable.
We always need to render the background, as the window
background is not always set (i.e. during gtk_widget_draw()) or
when its partially visible.
https://bugzilla.gnome.org/show_bug.cgi?id=694925
Mutter magically ignores override-redirect windows with geometry
-100-100+1+1, and this breaks the frame synchronization between
gtk+ and mutter. For now, we avoid the issue by simply giving
the window a different geometry.
https://bugzilla.gnome.org/show_bug.cgi?id=694217
When the range of the GtkRange is zero (i.e. the upper and lower bounds
of the adjustment have the same value), don't use an origin to draw the
trough, as the slider will also be hidden, and the juncture between the
two sections of the trough will be visible.
It's not friendly to bindings, and we didn't need an inout parameter anyway.
We use a simple return value from the signal handler now.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The default CSS didn't have anything for GtkTreeView's 'dnd' style class. So,
the call to gtk_render_frame() to draw the highlight frame for the drag-dest-row
was getting a border-width of 0, and nothing was drawn as a result.
Now we just copy the default from Adwaita, but make the border-radius 0, to make it
square like the rest of the Raleigh theme...
Unmounted volumes don't have a URI yet, so we can use that to distinguish them
from within the DnD code.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Since we are linking in the resource items by the source, we need to
disable WholeProgramOptimization so that the resource stuff does get linked
into the demo binaries, so that they can be loaded properly.
Also make sure that gtk3-demo-application is also built with the multibyte
character set, like the rest.
This should fix bug 694342, at least for Visual Studio builds.
If no updates, redraws, or repaints have been scheduled for this frame,
we will skip immediately to RESUME_EVENTS, and no GdkFrameTimings will
be created.
https://bugzilla.gnome.org/show_bug.cgi?id=694732
This is so we can prepare these buffers without them being set on the
widgets yet and only gtk_text_view_set_buffer() them afterwards. And
this in turn gets rid of all the a11y events we were needlessly
emitting.
https://bugzilla.gnome.org/show_bug.cgi?id=694406
-Use ApiVersion instead of GtkApiVersion for consistency's sake across
the board
-Add placeholder directives in the property sheets for building
introspection files using .bat files directly from the Visual Studio IDE.
This is used by the "Application Class" demo... so this should be built
as well especially as we are getting gspawn-win{32|64}-helper.exe fixed
on Visual Studio 2005 (and later) builds.
The file chooser button only supports single-selection modes, so
switch the code to a simpler gtk_file_chooser_get_file() to avoid
dealing with GSLists of a single file.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
When events are paused, we should not return TRUE from prepare() or check().
GTK+ handles this for events that are already in the GTK+ queue, but
we also need suppress checks for events that are in the system queue - if we
return TRUE indicating that there are events in the system queue, then we'll
call dispatch(), and do nothing. The event source will spin, and will never
run the other phases of the paint clock.
(Broadway doesn't have a window system queue separate from the GDK event queue,
but we write the function the same way for consistency.)
https://bugzilla.gnome.org/show_bug.cgi?id=694274
When events are paused, we should not return TRUE from prepare() or check().
GTK+ handles this for events that are already in the GTK+ queue, but
we also need suppress checks for events that are in the system queue - if we
return TRUE indicating that there are events in the system queue, then we'll
call dispatch(), and do nothing. The event source will spin, and will never
run the other phases of the paint clock.
https://bugzilla.gnome.org/show_bug.cgi?id=694274
Update the Visual Studio projects for gtka11y and the completion of the
projects that go along with it. This have been distcheck'ed on my Ubuntu
12.04 system.
Link to winmm.lib as well, as we are now using timeEndPeriod() and
timeBeginPeriod() since commit 5dbf814f (win32: Request higher
precision timers during animations).
This may ensure that the dialog is actually done initializing. We need to kill this
sleeping business and really use signals, sigh...
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We only emit that signal when the user confirms the button's internal GtkFileChooserDialog,
or when he drags-and-drops stuff into the button.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This ensures that data maintained by the button while the dialog opens/closes remains consistent.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Previously we could end up in a situation where browse_list_model==NULL, and yet load_state==LOAD_FINISHED.
This is not a valid state. So, when we get rid of the list model, really ensure that we end up
in LOAD_EMPTY so nothing assumes that there is a valid list model around.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We don't want to emit state changes for all the cells in a row, just for
the cell in the expander column. It's the only one that reports EXPANDED
or EXPANDABLE states, after all.
Also, contains refactoring of the affected functions for all the special
cases.
https://bugzilla.gnome.org/show_bug.cgi?id=694059
We weren't checking the removed flag but the added flag for removal
emissions, so what would happen for every state change notification was:
- on state-added, both an "added" and a "removed" event were emitted
- on state-removed, nothing
https://bugzilla.gnome.org/show_bug.cgi?id=694059
Commit 1db87c897f accidentally removed
a check for !in_paint_idle in maybe_start_idle which causes us
to create a paint loop whenever something requests a phase
inside the paint_idle.
The callback function gtk_window_on_theme_variant_changed is only used on the
X11 backend (where GtkSettings is used for the settings information.)
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=674207
We can't safely examine allocations synchronously using
gtk_main_iteration(), as there might be not enough time for a new paint
clock tick to have expired and the allocation set on the widget.
Work this around adding g_usleep() calls before processing pending
mainloop events.
With the following code:
#define INVALID_CHAR GDK_KEY_VoidSymbol - 1
gtk_accelerator_get_label (INVALID_CHAR, GDK_SHIFT_MASK | GDK_CONTROL_MASK);
we would get this label:
Shift+Ctrl+
instead of this label:
Shift+Ctrl
https://bugzilla.gnome.org/show_bug.cgi?id=694075
The default windows timer resolution is 16msec, which is too little
for fluent animations (say at 60Hz). So, while a paint clock is
active we temporarily raise the timer resolution to 1 msec.
Add an API to start or stop continually updating the frame clock.
This is a slight convenience for applcations and avoids the problem
of getting one more frame run after an animation stops, but the
primary motivation for this is because it looks like we might have
to use timeBeginPeriod()/timeEndPeriod() on Windows to get reasonably
accurate timing, and for that we'll need to know if there is an
animation running.
https://bugzilla.gnome.org/show_bug.cgi?id=693934
gdkwindown-win32.c included windows.h directly rather than via gdkwin32.h
which broke the build for me at least. Instead rely on it being included in
gdkwin32.h and things work right.
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 was causing warnings on widget unparent like:
Gdk-CRITICAL **: gdk_window_has_native: assertion `GDK_IS_WINDOW (window)' failed
Becasue the window was not properly removed from the lists on unrealize.
The macros we had for checking for toplevel windows were passing
through the root window, which was not intentional and meant that
for the root window WINDOW_IS_TOPLEVEL() returned TRUE but
window->impl->toplevel was NULL, causing gdk_window_create_cairo_surface()
to crash.
We clear GtkTickCallbackInfo on creation to ensure all fields start
as 0. Before we sometimes ended up with destroyed being 1
so the tick was never called.
gtk_icon_info_copy and gtk_icon_info_free are deprecated for
the corresponding GObject methods.
We set correct transfer markup for the GtkIconInfo returning methods
to fix the introspection of them.
gtk_icon_info_load_symbolic_for_context_async had the wrong method
name in its documentation block.
We need to disconnect the frame clock when we unrealize (at which
point the old clock is still alive) not in destroy(). Since there
is no common unrealize for containers, trigger this from GtkWidget.
A switch of device may be significant for an application, so don't
compress motion events if they are for different devices. This simple
handling isn't sufficient if we have competing event streams from
two different pointer events, but we don't expect this case to be
common.
* remove gdk_frame_clock_get_frame_time_val(); a convenience
function that would rarely be used.
* remove gdk_frame_clock_get_requested() and
::frame-requested signal; while we might want to eventually
be able to track the requested phases for a clock, we don't
have a current use case.
* Make gdk_frame_clock_freeze/thaw() private: they are only
used within GTK+ and have complex semantics.
* Remove gdk_frame_clock_get_last_complete(). Another convenience
function that I don't have a current use case for.
* Rename:
gdk_frame_clock_get_start() => gdk_frame_clock_get_history_start()
gdk_frame_clocK_get_current_frame_timings() => gdk_frame_clock_get_timings()
Since we're not exporting the ability to create your own frame
clock for now, remove the setters for GdkFrameTimings fields.
Also remove all setters and getters for fields that are more
about implementation than about quantities that are meaningful
to the applcation and just access the fields directly within
GDK.
Now that GdkFrameClock is a class, not interface, there's no real advantage
to splitting the frame history into an aggregate object, so directly
merge it into GdkFrameClock.
It's unlikely that anyone will want to have, say, a GtkWidget that
also acts as a GdkFrameClock, so an abstract base class is as
flexible as making GdkFrameClock an interface, but has advantages:
- If we decide to never make implementing your own frame clock
possible, we can remove the virtualization.
- We can put functionality like history into the base class.
- Avoids the oddity of a interface without a public interface
VTable, which may cause problems for language bindings.
Instead of making the frame clock a settable property of a window, make
toplevel windows inherently have a frame clock when created (getting
rid of the default frame clock.) We need to create or destroy frame
clocks when reparenting a window to be a toplevel, or to not be a
toplevel, but otherwise the frame clock for a window is immutable.
Add a very simple GtkWidget function for an "tick" callback, which
is connected to the ::update signal of GdkFrameClock.
Remove:
- GtkTimeline. The consensus is that it is too complex.
- GdkPaintClockTarget. In the rare cases where tick callbacks
aren't sufficient, it's possible to track the
paint clock with ::realize/::unrealize/::hierarchy-changed.
GtkTimeline is kept using ::update directly to allow using a GtkTimeline
with a paint clock but no widget.
If we get a focus event for a X window we don't recognize, just
ignore it and avoid a g-critical when
_gdk_device_manager_core_handle_focus() is called with a NULL window.
Deprecate gdk_window_enable_synchronized_configure() and
gdk_window_configure_done() and make them no-ops. Implement the
handling of _NET_WM_SYNC_REQUEST in terms of the frame cycle -
we know that all processing will be finished in the next frame
cycle after the ConfigureNotify is received.
The first version of the video-timer simply played back the video
according to the wall clock, and showed each frame at the neareste
presentatin time. But an alternative strategy for playing back
video is that if the frame-rate is an integer-divisor of the
display refresh rate, or very close to that, is to change the playback
speed to complete avoid frame drops and changes in latency.
(This would require resampling audio if present.)
Demonstrate this technique by adding a --pll option to the
video-timer demo.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Add a test case that simulates the timing operaton that goes on
when showing a constant frame rate stream like a video - each
frame is shown at the VBlank interval that is closest to when it
would ideally be timed.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
For an operation like synchronizing audio to video playback, we need to
be able to predict the time that a frame will be presented. The details
of this depend on the windowing system, so make the backend predict
a presentation time for ::begin-frame and set it on the GdkFrameTimings.
The timing algorithm of GdkFrameClockIdle is adjusted to give predictable
presentation times for frames that are not throttled by the windowing
system.
Helper functions:
gdk_frame_clock_get_current_frame_timings()
gdk_frame_clock_get_refresh_info()
are added for operations that would otherwise be needed multiple times
in different locations.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Show the average and standard deviation of the latency in addition to
the frame rate. Add options to print the output in machine-readable form,
and to control the frequency and total number of statistics that will be
output.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
We want the compositor to do different things for frames where
"slept before" is TRUE. Communicate to the compositor that
frame is a no-delay frame (slept_before=FALSE) by ending the frame
by increasing the counter value by 1, and that the frame is a
normal frame (slept_before=TRUE) by increasing the counter value
by 3.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Add functions that tell us whether the main loop slept before we drew
a frame. Blocking with the frame clock frozen doesn't count as sleeping.
We'll use this to advertise to the compositor whether we
are drawing as fast as possible (and it should do the same) or timing
frames carefully (and it should do the same.)
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Don't start the idle if we're in the middle of painting a frame -
this will prevent us from getting the timing right when starting
the idle after the frame.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
In order to be able to track statistics about how well we are drawing,
and in order to be able to do sophisticated things with frame timing
like predicting per-frame latencies and synchronizing audio with video,
we need to be able to track exactly when previous frames were drawn
to the screen.
Information about each frame is stored in a new GdkFrameTimings object.
A new GdkFrameHistory object is added which keeps a queue of recent
GdkFrameTimings (this is added to avoid further complicating the
implementation of GdkFrameClock.)
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Instead of communicating the start of a frame to the window manager
as soon as we begin a frame, start a frame only when we know we've
actually created damage to the contents of a window.
(This uses cairo_set_mime_data() as a notification mechanism - a
clever suggestion from Uli Schlachter.)
The advantage of this is that we aren't forcing the compositor to
do a frame cycle and send _NET_WM_FRAME_DRAWN - depending on how the
compositor is structured that might either cause it to do extra
work or it might send _NET_WM_FRAME_DRAWN early and upset frame
timing.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Since events can be paused independently for each window during processing,
make _gdk_display_pause_events() count how many times it is called
and only unpause when unpause_events() is called the same number of
times.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Unqueuing events from the windowing system when paused could result
in weird reordering if event filters resulted in application-visible
behavior. Since we now resume events when the frame clock is frozen,
we now no longer count on low-level event handling running while
event handling is paused.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Keeping events paused after the end of a frame put us in a
weird state where we had to process and queue events - so that
we would get the message from the compositor - but not deliver
them. Instead resume events before ending the frame.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
When we have pending motion events, instead of delivering them
directly, request the new FLUSH_EVENTS phase of the frame clock.
This allows us to compress repeated motion events sent to the
same window.
In the FLUSH_EVENTS phase, which occur at priority GDK_PRIORITY_EVENTS + 1,
we deliver any pending motion events then turn off event delivery
until the end of the next frame. Turning off event delivery means
that we'll reliably paint the compressed motion events even if more
have arrived.
Add a motion-compression test case which demonstrates behavior when
an application takes too long handle motion events. It is unusable
without this patch but behaves fine with the patch.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Add a test of a window with an animated size and contents. The
test accepts load factor command line argument to see how things
work as the drawing of the content requires more GPU resources.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
When we have a looping animation for something like an angle,
we need to make sure that the distance we go past 1.0 becomes
the starting distance for the next frame. This prevents a
stutter at the loop position.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Use GdkFrameClock for the timing of GtkTimeline. This require the
user to provide either a GtkWidget or a GdkFrameClock when creating
the timeline. The default constructor now takes a GtkWidget. If you
want to create a GdkFrameClock without a widget, you need to use
g_object_new() and pass in a GdkFrameClock and GdkScreen.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
The frames-per-second for an animation should be controlled by how
fast we can process frames and the the frame-rate of the display; it's not
a meaningful app-settable property.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Add back the GtkTimeline code that previously made private and
then removed. It will be hooked up to GdkFrameClock. This commit
purely adds the old code back.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Switch GtkStyleContext to using GdkFrameClock. To do this, add a new
UPDATE phase to GdkFrameClock.
Add a GdkFrameClockTarget interface with a single set_clock() method,
and use this to deal with the fact that GtkWidget only has a frame
clock when realized.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
If the backend is throttling paints, then the frame clock will be
frozen at the end of the frame. If not, then we need to add throttling,
so wait until 16ms after the start of the frame before beginning the
next frame.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
By starting with an odd frame counter value, we make the mapping
and initial paint of the window an atomic operation, avoiding
any visual artifacts from an unpainted window.
Possible improvement: start the frame when doing gdk_window_show(),
so that the same improvement occurs for windows that were previously
shown and are being mapped again.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
When a window is unmapped, freeze its frame clock. This avoids doing
unnecessary work, but also means that we won't block waiting for
_NET_WM_FRAME_DRAWN messages that will never be received since the
frame ended while the window was withdrawn.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
As part of the extended _NET_WM_SYNC_REQUEST_COUNTER protocol,
we get a _NET_WM_FRAME_DRAWN message for each frame we draw. Use this
to synchronize the updates we are doing with the compositing manager's
drawing, and ultimately with with display refresh.
We now set the sync request counters on all windows, including
override-redirect windows, since it is also useful to do synchronized,
atomic updates for such windows.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
By exporting two XSync counters on a toplevel window, we subscribe
to an extended form of the _NET_WM_SYNC_REQUEST_COUNTER protocol,
where the window manager can initiate an atomic frame, as previously,
but the application can also do so by incrementing the new counter to
an odd value, and then to an even value to finish the frame.
See:
https://mail.gnome.org/archives/wm-spec-list/2011-October/msg00006.html
The support for 64-bit integers that GLib requires is used to
simplify the logic.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Add the ability to freeze a frame clock, which pauses its operation,
then thaw it again later to resume.
Initially this is used to implement freezing updates when we are
waiting for ConfigureNotify in response to changing the size of
a toplevel.
We need a per-window clock for this to work properly, so add that
for the X11 backend.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Instead of having gdk_frame_clock_request_frame() have
gdk_frame_clock_request_phase() where we can say what phase we need.
This allows us to know if we get a frame-request during layout whether
it's just a request for drawing from the layout, or whether another
layout phase is needed.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
We may receive events because SubstructureNotifyMask has been selected
for the root window. (Most likely, this would occur because GTK+
is being used inside a window manager like Metacity or Mutter.)
This can confuse various types of internal accounting, so detect
such events and comprehensively ignore them for GDK's internal
purposes. We still need to generate GDK events for these cases
because you can select for substructure events with
GDK_SUBSTRUCTURE_MASK.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
This is necessary in order to have async operations on it.
All the old copy/free functions keeps working, and g_boxed_copy on a GObject
also works, so this should be mostly compatible, but techncally its a minor
ABI break since the GType changes fundamental type. Changes like this has
happened before though, like with GVariant becomming its own fundamental
type.
https://bugzilla.gnome.org/show_bug.cgi?id=693802
These are generic tests that can test the button in all of its modes,
instead of hand-written tests for each combination.
Some tests fail currently.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
If the user didn't explicitly select anything, BUT the file chooser button has
a current_folder set, do the same as what GtkFileChooserDefault would do:
return the current folder as the selection.
This makes the tests in tests/filechooser pass!
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
If no file was originally selected in the GtkFileChooserButton, then its
internal dialog is brought up and cancelled, then we need to restore the
selection back to none. GtkFileChooser, though, doesn't like to
select a NULL file, so call _unselect_all() in that condition.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The button's underlying file chooser dialog should not be used to store the file selection
while the dialog is unmapped. Instead, the file chooser button now stores the
selection itself.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
It used to fetch a possibly multiple selection from the GtkFileChooserDialog, and then
pick just the first item from the selection list. But since GtkFileChooserButton
operates in single-selection mode only, it can simply use gtk_file_chooser_get_file()
instead.
Also, the right way to reset the selection for GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER
is with gtk_file_chooser_select_file(), not with _set_current_folder_file().
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This code came from a home-grown testing mechanism, which didn't aggregate tests
into a test suite; it just ran them one by one. Here we move some of that machinery
to GTestDataFunc for more flexibility in running tests.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This adds a way to get the gtk_widget_set_opacity liike behaviour
of retargeting GdkWindows and exposing every child in ::draw, without
actually having an alpha. This is needed if you're doing more complex things
such as cross fading of widgets.
We do this as a hack by using opacity values that round to 255 yet not
really 1.0 in order to avoid having some magical API call for this
mainly internal call.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
Some backends do not have slave devices, which means last_slave may be
NULL. Use the current device as the source device if last_slave is NULL
when synthesizing a crossing event.
https://bugzilla.gnome.org/show_bug.cgi?id=692411
Sink the GtkEntry assigned to the private structure of GtkCellRendererText
before signals containing it as an argument are sent out. This keeps
language bindings from sinking the reference and then destroying the entry
when the signal closure is finished.
https://bugzilla.gnome.org/show_bug.cgi?id=693400
When calling gtk_widget_draw() on the entry gtk_cairo_should_draw_window()
will return TRUE for all windows. This is used when rendering a widget to
somewhere other than the screen, and its now used for transparent widgets.
This caused the texthandle to always draw itself and terminate the draw
handler for the entry.
Instead we now only draw the markers when really visible, plus we return
FALSE to avoid stopping the entry drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
This adds gtk_widget_get/set_opacity, as well as a GtkWidget.opacity
property. Additionally it deprectates gtk_window_get/set_opacity and
removes the GtkWindow.opacity property (in preference for the new
identical inherited property from GtkWidget, which should be ABI/API
compat).
The implementation is using the new gdk_window_set_opacity child
window support for windowed widgets, and cairo_push/pop_group()
bracketing in gtk_widget_draw() for non-window widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
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
We now store the current opacity for all windows. For native windows
we just call into the native implementation whenever the opacity changes.
However, for non-native windows we implement opacity by pushing a
second implicit paint that "stacks" on the existing one, acting as
an opacity group while rendering the window and its children.
This works well in general, although any native child windows will of
course not be opaque. However, there is no way to implement
implicit paint flushing (i.e. draw the currently drawn double buffer
to the window in order to allow direct drawing to the window).
We can't flush in the stacked implicit paint case because there
is no way to get the right drawing behaviour when drawing directly
to the window. We *must* draw to the opacity group to get the right
behaviour.
We currently flush if:
* A widget disables double buffering
* You call move/resize/scroll a window and it has non-native children
during the expose handler
In case this happens we warn and flush the outermost group, so there may
be drawing errors.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
_gdk_display_device_grab_update does not support passing in NULL for the
source device. If we don't have a slave device (saved in the pointer info)
then do not try and use that NULL pointer for the source_device.
This bug appeared in the Wayland backend where we (currently) only have master
devices exposed and as such no slave device is ever saved.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=692411
The following patch added a dependency on a new API first available in that
release:
commit 92f0c5c384
Author: Mike Gorse <mgorse@suse.com>
Date: Mon Dec 3 16:07:23 2012 -0600
Add accessibility for GtkLevelBar and value test
The "activate" action here did not do anything.
It is possible we actually want to have some actions here,
like "step-up", "step-down", "page-up", "page-down", etc.
For now, just remove the AtkAction implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=553334
This reverts commit cd98eb15cb.
It turns out that we just started using AX_PROG_CC_FOR_BUILD, which
for some reason requires AC_CANONICAL_TARGET. That seems wrong to
me, but for now, lets just keep using it.
This autoconf macro should only be used for building compilers
(or compiler tools) for a specific target. The current effect of
it in GTK3 is that it causes various executables like gtk3-demo
to be prefixed with $target- when the --target configure flag
is set or when cross-compiling. When cross-compiling GTK3 on
Linux for the Win32 target this causes the gtk3-demo binary
to be named i686-w64-mingw32-gtk3-demo.exe instead of just
gtk3-demo.exe (like it was before commit 53083ea7b4)
https://bugzilla.gnome.org/show_bug.cgi?id=692638
There's really no reason why we shouldn't automatically create a
GtkViewport when the widget added to GtkScrolledWindow is not a
GtkScrollable, instead of just printing a g_warning.
Copy the viewport special case into the scrolled window implementation
of gtk_container_add().
https://bugzilla.gnome.org/show_bug.cgi?id=693015
Saves ~6MB of memory per application in the Adwaita I am using - at
least until the app starts using all the images in the theme, because
the code doesn't discard images yet once they were loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=692934
This is essentially a GtkCssImage for a cairo_surface_t and is a pretty
much straight up copy of GtkCssImageUrl. But we want to implement lazy
loading and animations, so GtkCssImageUrl is going to gain new
features...
https://bugzilla.gnome.org/show_bug.cgi?id=692934
I'd like to use it when printing the value, but I haven't found a way to
do that sanely yet, as I'd need to be able to print relative paths for
make check to work (otherwise the srcdir would blow things up). And we
use a GString to output to, so there's no way to attach a base dir to
that.
If anyone has an idea how to achieve that, poke me. Having the real
filename in debug prints sounds like a very good idea to me.
https://bugzilla.gnome.org/show_bug.cgi?id=692934
This way, people know what stuff we are loading.
And instead of listing all the files in the top (and forgetting things),
we just take them from the resources list.
Commit ddceddaa84 removed the call to
gtk_style_context_set_background() in favour of always rendering it with
gtk_render_background() during the draw vfunc.
This has the side effect of making the backing window always
transparent, which blocks GTK from applying some optimizations during
the paint cycle. The result is that, especially in clutter-gtk
applications, scrolling performance gets really bad.
This commit partially reverts ddceddaa84
and changes the code so that both gtk_style_context_set_background() and
gtk_render_background() are called
Commit da09447914 removed the call to
gtk_style_context_set_background() in favour of always rendering it with
gtk_render_background() during the draw vfunc.
This has the side effect of making the backing window always
transparent, which blocks GTK from applying some optimizations during
the paint cycle. The result is that, especially in clutter-gtk
applications, scrolling performance gets really bad.
This commit partially reverts da09447914
and changes the code so that both gtk_style_context_set_background() and
gtk_render_background() are called.
gtk_tree_drag_source_drag_data_get's GtkSelectionData argument should not be
marked as (out) because:
a) GtkSelectionData is semi-private (it's declared in gtkselectionprivate.h),
and thus gobject-introspection has no knowledge of its fields or its size.
There is thus no way for language bindings to allocate GtkSelectionData.
b) Even if it was possible for language bindings to allocate GtkSelectionData,
a zeroed-out instance thus created would not be usable with
gtk_tree_drag_source_drag_data_get. As far as I can tell, you need to
initialize its "target" member to the GdkAtom of "GTK_TREE_MODEL_ROW".
Language bindings have no way of knowing this, of course.
https://bugzilla.gnome.org/show_bug.cgi?id=692844
Instead of having an accept_uri_drops flag, we'll always advertise as accepting URI drops.
However, we'll see if the caller actually handles the drag-action-requested signal. If it
does, we'll indeed allow performing file operations when URIs are dropped. Otherwise,
we'll only allow creating bookmarks from dragged URIs.
Dragging URIs directly into a places item will cause the sidebar to check if the caller
allows file operations. Dragging URIs between places items will cause the sidebar
to create bookmarks for those URIs instead.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Since XIQueryVersion, the bad API that it is, enforces the version from
the first client that requests it, for clients to be able to use the new
features in XI2.3, we need to ensure that we pass XIQueryVersion 2.3 as
the version that we support. We know that GTK+ won't be confused by the
new features.
https://bugzilla.gnome.org/show_bug.cgi?id=692467
The X server should fill in the minor version that it supports in the
case where it only supports the older version, so we can safely always
pass a higher version number than is potentially supported by the
server.
libXi was designed to be stable in the case where it doesn't recognize
requests or events/replies, so this should still work in a case where
we have new versions of the X server, and GTK+, but an old version of
libXi, at least for however well that setup should work.
https://bugzilla.gnome.org/show_bug.cgi?id=692467
This keeps the drop indicator line from 'sticking' if you drag a bookmark above
the Bookmarks heading.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
and gdk_window_get_fullscreen_mode() API to allow
applications to specify if a fullscreen window should
span across all monitors in a multi-monitor setup or
remain on the current monitor where the window is
placed.
Fullscreen mode can be either GDK_FULLSCREEN_ON_ALL_MONITORS
or GDK_FULLSCREEN_ON_CURRENT_MONITOR.
https://bugzilla.gnome.org/show_bug.cgi?id=691856
This is akin to commit cfb09e5654 in the gtk-2-24 branch;
the last_folder_uri is no longer being used for anything meaningful, so we
remove it altogether.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This is a quickfix to keep things working.
It turns out GtkWindow assumes it can do sizing operations while not
being visible, or while in the process of show()ing/hide()ing itself.
And commit b495ce54 broke these operations.
Figuring this properly requires some more thinking and restructuring on
my part, so for now we relax the requirement of visiblility enough for
these things to start working again.
Allows to access Wayland specific window information like wl_surface and
wl_shell_surface.
Add gdk_wayland_window_get_wl_surface for getting the Wayland wl_surface
and gdk_wayland_window_get_wl_shell_surface for getting the Wayland
wl_shell_surface.
The code is always instantiating this schema at a fixed location, so why
is it relocatable?
Add a path so that it shows up properly in dconf-editor, and from the
gsettings commandline tool.
The code is always instantiating this schema at a fixed location, so why
is it relocatable?
Add a path so that it shows up properly in dconf-editor, and from the
gsettings commandline tool.
https://bugzilla.gnome.org/show_bug.cgi?id=692163
This adds a PlatformToolset tag in the project configs so that we can
provide support for Visual Studio 2012 with relative ease as the format
of the VS 2012 projects are only slightly different from their VS 2010
counterparts.
We can then use a script like the one used in GLib[1] to copy the VS2010
projects and replace the necessary tags to create the VS2012 projects.
This also cleans up the projects and property sheets, as there were some
unwanted/unneeded entries in them.
[1]: http://git.gnome.org/browse/glib/commit/?id=76cecf061b377d30e5422cdddb1fb9d19c52421d
-Rename the "libgail" projects to gtka11y, for consistency with the
autotools builds
-Update the projects completion in gtk/a11y/Makefile.am, as the sources are
now listed under $(libgtka11y_la_SOURCES) instead of $(libgail_la_SOURCES)
In the Wayland backend implementation for gdk_display_get_keymap we enumerate
the known devices and look for an core keyboard device. These device objects
are created when we receive the capabilities for the seat. The seat
capabilities may be received after a request for the keymap so we handle this
by creating a temporary keymap which we then free later when we have the real
one.
The rest of the public API works in terms of GFile, so remove this last remnant
of passing URIs around.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
An instance of GtkAdjustment may be used by another instance after
the spin button widget is destroyed. In that case, the function
gtk_spin_button_accessible_value_changed() will be called with an
invalid argument. This situation is often caused when one use
GtkCellRendererSpin widget. To avoid invalid call of the function,
the signal handler for the "value-changed" signal should be disconnected
when the spin-button widget is destroyed.
Using g_signal_connect_object achieves just that.
https://bugzilla.gnome.org/show_bug.cgi?id=691592
width-chars and max-width chars should (and do) only change the
requested sizes, not the allocated size of the label.
This came out of an IRC discussion, so no bug.
The underlying code uses API that is no longer available with 1.0. This
optional, off by default build mode hasn't worked since the release of
Wayland 1.0.
There are cases where crossing events aren't generated by input devices themselves
but rather through programmatical means (windows being moved/hidden/destroyed while
the pointer is on top).
Those events come from X as sourceid=deviceid, and GDK does its deal at lessening
this by setting a meaningful source device on such events, although this caused
some confusion on the mechanism to block/synthesize touch crossing events that
could possibly cause bogus enter events on the new window below the pointer.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=691572
Since 16195ad the “expand” property is always set to FALSE when a
column is resized. This commit takes a different approach and enables
“expand” whenever the column is wide enough. An appropriate
“fixed-width” (so that the desired width is achieved after expanding) is
calculated using equations that are explained in the code.
https://bugzilla.gnome.org/show_bug.cgi?id=691751
Rewrites gtk_tree_view_column_request_width() and
gtk_tree_view_size_allocate_columns() to respect the minimum and natural
sizes that are already being returned by
gtk_cell_area_context_get_preferred_width().
The convoluted logic explained (not!) by this comment has been removed:
“Only update the expand value if the width of the widget has changed, or
the number of expand columns has changed, or if there are no expand
columns, or if we didn't have an size-allocation yet after the last
validated node.” This logic seems to have been a workaround for the
“jumping” behavior fixed in 16195ad and is no longer necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=691751
Removes the hidden “resized-width” and “use-resized-width” properties
from GtkTreeViewColumn and instead uses the “fixed-width” property to
serve the same purpose. “fixed-width”, if set, will now override the
auto-sized width (-1 is now a legal value meaning “not set”).
Additional “cleanups” in this commit:
1. When the user resizes the column the “expand” property is now also
set to FALSE, in order to prevent the column from suddenly jumping to a
different width when the window is resized.
2. The code that translated mouse movement to column sizes has been
simplified:
the change in column width is now calculated directly from the distance
the mouse cursor has traveled. Weird behavior that might have happened
previously if the position of the column changed during resizing, is now
prevented.
3. There was some lengthy logic handling the keyboard shortcuts used to
resize treeview columns, which would call gtk_widget_error_bell() once
the minimum or maximum width was reached. Instead of rewriting these
checks I simply set the “fixed-width” property to what was requested,
relying on the fact that it is already clamped between the minimum and
maximum width during size allocation.
I will greatly surprised if anyone notices the missing error bell.
https://bugzilla.gnome.org/show_bug.cgi?id=691751
Splits up size_request() so that the height calculations are only done
when get_preferred_height() is called and the width calculations are
only done when get_preferred_width() is called. Since
get_preferred_width() does not change the treeview->priv->width value,
treeview->priv->prev_width will always be equal to it and can therefore
be removed. The only place where prev_width was used is a block in
gtk_tree_view_size_allocate(). This block seems to be adjusting the
horizontal scrollbar to account for treeview->priv->width having been
changed in size_request() and should no longer be necessary. A similar
block immediately above it seems to already account for the width change
in size_allocate().
https://bugzilla.gnome.org/show_bug.cgi?id=691751
After “validation” (i.e., background size calculations) of some cells,
size_request() was called here to update the internally cached size of
the treeview. Apparently not updating the sizes leads to some kind of
“inconsistency” that messes with top_row_to_dy(). In the GTK3 model for
size allocation, things are more complicated. The treeview can’t just
go ahead and calculate its own size any more; instead it reports both a
“minimum” and a “natural” size, and it doesn’t know what size it will
actually get until size_allocate(). It may be necessary to update
top_row_to_dy() to deal with not knowing the exact size.
https://bugzilla.gnome.org/show_bug.cgi?id=691751
We want to reserve space for the size of the scrollbars even when they
are not visible. And because toggling visibile to off now returns 0 for
size requests, this won't work anymore.
The window size can be queried on widget->window directly, no need to
store it in widget->allocation.
This change is necessary because gtk_widget_set_allcation() is now
checking invariants that assume it's called from insize
gtk_widget_size_allocate() and that wasn;t the case here.
Commit e32da246a8 made GtkRange's trough
respect the CSS margin property, but it also trimmed the box in which
the trough reacts to click events by the margin.
We still want to catch events in that area instead, and just make sure
the margin is applied when drawing (which was already implemented by
that commit).
This commit reverts the parts of
e32da246a8 that didn't involve drawing,
fixing the bug.
https://bugzilla.gnome.org/show_bug.cgi?id=691677
Before acting on any hint that is set by the window manager we must
first check that the hint is supported by the current window manager.
Checking that a property has a value is insufficient as it may have
been set by a previous window manager which did support the hint.
https://bugzilla.gnome.org/show_bug.cgi?id=691515
We used to have set_current_location() and get_selected_location(), with confusing
semantics. Now they are symmetric, with the exception that if set_location() is
called with a location that is not shown in the sidebar, then it will both clear
the selection in the list and make get_selection() return NULL.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This lets us handle the 'Open in new tab' and 'Open in new window' menu items
on our own, and allows callers to have less code to deal with each mode.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This lets us remove two entry points, gtk_places_sidebar_set_show_trash(),
and gtk_places_sidebar_set_trash_is_full().
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This is analogous to NautilusTrashMonitor in that it just monitors trash:///
and is able to return the appropriate icon for the trash's current state.
Later we may want to move this utility object into GIO or something.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
When cross-compiling, instead of depending on a natively built GTK+ (which means
building Glib, ATK, Pango, gdk-pixbuf, libX11...) for gtk-update-icon-cache,
find the host compiler and gdk-pixbuf, and build another gtk-update-icon-cache
with that.
This uses AX_PROG_CC_FOR_BUILD from autostars to find the host compiler, and
assumes that you'd set PKG_CONFIG_FOR_BUILD to a host pkg-config binary.
https://bugzilla.gnome.org/show_bug.cgi?id=691301
With this we always roundtrip position change to the webbrowser.
This avoids conflicts when things change from both directions (app and user).
Also, we fake configure evens when there is no web client to ensure
apps get the events.
GtkWidget::visible is required for the widget to:
- have a preferred size other than 0/0
- have a size allocated
- return other values than { -1, -1, 1, 1 } from get_allocation()
This is an experimental patch aiming to make concepts and behaviors
inside GTK more concreate. GtkWidget::visible is now essentially what
CSS does for "display: none".
Note that if you want the effect of CSS's "visibility: hidden", you'll
have to use a GtkNotebook with an empty page as the concept of reserving
space but not drawing anything isn't supported natively in GTK.
It's a lot uglier now, but it shouldn't crash anymore.
We must update the font description for animations, but we can't free it
on query, because some paths call gtk_style_context_get_font() twice in
a row without stopping the use of the first call. So us just creating a
new font description all the time and unreffing the old one is not a
good idea. So we just mere the new one into the old one.
https://bugzilla.gnome.org/show_bug.cgi?id=691186
Previously, with STATE_FLAGS_REPLACE we would unset _all_ the state
flags on children, not just the ones that do propagate. This caused the
RTL/LTR flags to get lost.
This is a trivial example. Just check that we can derive
from GtkButtonAccessible, and have a GtkButton subclass
use the derived accessible implementation.
We add a separate gtk-a11y.h single-include header for
them. This header will work much the same as gtkx.h. It
will be installed in /usr/include/gtk-3.0/gtk, but you
have to include it separately.
Since we are going to install these headers soon, we need
to make their mutual includes work in the installed location
as well. Also, avoid including individual gtk headers, to
avoid trouble with single-include guards.
This commit exposes the get_type() functions and standard
headers for accessible implementations. This makes it possible
to derive from the GTK accessible implementations without
GType magic tricks. This is necessary, because we require the
a11y type hierarchy to be parallel to the widget type hierarchy.
So, if you derive a widget and need to adjust its a11y implementation,
you have to be able to derive its accessible implementation.
This commit probably exposes more than is absolutely necessary,
it also exposes accessibles of widgets that are unlikely candidates
for deriving from.
Since not every theme renders a background for a GtkViewport (and
Adwaita master doesn't), ensure the grid+viewport we use to emulate a
text view here uses the "view" style class.
It already paints the css border, so let's make it also honor css
background. This is needed to have a box of a different color around
some widgets (e.g. latest gnome-clocks design)
This (shouldn't) change any behaviour, but it moves the
webserver parts to a separate file, making the broadway display file
smaller and preparing for later separating out the server to its own
process.
If you want to get rounded corners on an hbox, instead of
:first-child {
border-top-left-radius: 5px;
border-bottom-left-radius: 5px;
}
:last-child {
border-top-right-radius: 5px;
border-bottom-right-radius: 5px;
}
you now need to write:
:first-child, :last-child:dir(rtl) {
border-top-left-radius: 5px;
border-bottom-left-radius: 5px;
}
:last-child, :first-child:dir(rtl)
{
border-top-right-radius: 5px;
border-bottom-right-radius: 5px;
}
If you want to get rounded corners on an hbox, instead of
:first-child {
border-top-left-radius: 5px;
border-bottom-left-radius: 5px;
}
:last-child {
border-top-right-radius: 5px;
border-bottom-right-radius: 5px;
}
you now need to write:
:first-child, :last-child:dir(rtl) {
border-top-left-radius: 5px;
border-bottom-left-radius: 5px;
}
:last-child, :first-child:dir(rtl)
{
border-top-right-radius: 5px;
border-bottom-right-radius: 5px;
}
If you want to get rounded corners on an hbox, instead of
:first-child {
border-top-left-radius: 5px;
border-bottom-left-radius: 5px;
}
:last-child {
border-top-right-radius: 5px;
border-bottom-right-radius: 5px;
}
you now need to write:
:first-child, :last-child:dir(rtl) {
border-top-left-radius: 5px;
border-bottom-left-radius: 5px;
}
:last-child, :first-child:dir(rtl) {
border-top-right-radius: 5px;
border-bottom-right-radius: 5px;
}
This function is just a sophisitcated optimization.
If we know the GDK window's background will be opaque, we mark it as
opaque. This is so GDK can do all the optimizations it does for opaque
windows and be fast.
This is mainly used when scrolling.
The previous code didn't get this right, in particular it didn't enforce
a transparent background when it knew the background was not opaque.
Instead of conditionally creating contextual menu items like 'Show file properties',
we'll instead let the caller populate the popup menu, as is done for GtkEntry.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The code path where we update the tooltip text property doesn't set
the state and value variables, and so doesn't need to call
notify_state_change().
Return early, and move the if block at the beginning of the function for
clarity.
There are some registred stock ids like gtk-discards that have no icons,
and you could also pass a non-registred stock id. Both of these means
gtk_style_context_lookup_icon_set returns NULL, which causes
a critical in gtk_icon_set_render_icon_pixbuf.
We avoid this by just making these render as EMPTY.
In gtkimcontextime.c, use gdk_win32_window_get_impl_hwnd() to get to
the impl's existing native window instead of GDK_WINDOW_HWND() which
implicitly ensures a native window for the widget itself. This seems
to work around whatever GDK problem with native subwindows and fixes
the bug.
This is based on Michael Natterer's fix for gtk-2-24.
We used to use GTK_RESIZE_QUEUE, but that is problematic for e.g
a GtkScrolledWindow with NEVER scroll policies, as size changes
in ancestors will never get propagated to the scrolled window, causing
it to not have the correct size.
This is a slight performance hit, but in practice its not bound to be
problematic. In typical UIs there is only a single "large" GtkScrolledWindow
visible at a time, so a size requeust propagating out of such a window
will only hit the smaller amount of widgetry outside the scrolled window,
and additionally all such widgets will have their size request caches
still valid.
https://bugzilla.gnome.org/show_bug.cgi?id=690099
We don't get an automatic queue resize on realize anymore, which
was papering over this bug where we did not set the child window
size/position at realize time.
We still lack a button to activate Search, like in Nautilus, but that will come later.
And with this, the last REMOVE_FOR_PLACES_SIDEBAR is gone!
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Reading recent:/// as-is is probably fine for OPEN mode. But for SAVE mode, we want to present
a list of recent directories. So, we go back to our old machinery for now; in the future
we'll probably just use recent:/// and extract the list of recent directories from there.
This also fixes showing the Recent item as highlighted when the file chooser starts up.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We use the new g_type_get_type_registration_serial() so that we can
cache and properly invalidate the result of g_type_from_name().
This bumps the glib requirement to 2.35.3 to get the new function.
https://bugzilla.gnome.org/show_bug.cgi?id=689847
Rather than first collecting matches and then getting the change
for them we do the change collection directly on the tree. This
is about twice as fast.
At the moment, gtk+ doesn't depend on intltool, which is the program
that knows how to translate schemas. Attempting to translate them
causes a build failure, so for now, let's leave them in en_US.
https://bugzilla.gnome.org/show_bug.cgi?id=689584
We must not release the GtkClipboardOwner in pasteboardChangedOwner
becaue we don't own a reference to ourselves (NSPasteboard does).
Instead, release the owner right after setting it, transferring
ownership to NSPasteboard
Also, fix repeated setting of the same owner by keeping the
owner around in GtkCLipboard, and re-use it if "user_data"
doesn't change. To avoid clipboard_unset()ting our own contents
in the process, add an ugly "setting_same_owner" boolean to
GtkClipboardOwner, set it during re-setting the same owner,
and avoid calling clipboard_unset() from pasteboardChangedOwner
if it's TRUE.
(cherry picked from commit 4a8df7a33c)
We currently invalidate the whole tree every time the style state
changes in the tree view. The primary reason for this is to catch
default font changes as that may affect text cell renderers. But
cell renderers could *potentially* also read other style properties
(although that seems weird and unlikely).
We handle this by invalidating only when some state that affects sizes
is changed. This includes all the font properties.
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.
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
Pango 1.32.4 has a feature where any PangoLayout automatically handles
the case where a PangoContext is changed. We want to rely on this to
avoid having to clear layouts too often, so we make this a hard dep.
This is for a very simple reason: The getter is returning a const value
and the font isn't const anymore. So we need to store the font
description somewhere but we can't reuse it as it's changing all the
time (yay animations, yay inherited values). Sucks.
So keep the hack in here but deprecate the function.
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.
This is necessary because values in a GtkCssComputedValues can change
now. So if the font-size is inherited or animated, the cached value will
be outdated.
Fixes the fontchooser preview not updating.
Oh, the giant void.
I stare into it
and it makes me afraid
that I've screwed up.
But I know I haven't.
Because any remaining bugs
will be yours to fix.
Not mine.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This means reffing the root in the set property implementation,
rather than in the constructor. We don't need to unref the root
on set, as it's a CONSTRUCT_ONLY property.
https://bugzilla.gnome.org/show_bug.cgi?id=680065
GtkWindow always queues a resize on style updates if there is
a grip, because it may have been the grip size style properties
that changed. However, even if it *were*, and it likely wasn't
that would not affect the windows size request, so no need
to queue a resize.
queue_resize basically tells the parent widget that it may need
to pick a different size/layout. However, for a hidden child widget
that should never be needed. It may be that the widget is in a
sizegroup that has ignore_hidden == FALSE though, so it may
affect the size group calculations.
However, if a widget is not visible and not in a size group then
its safe to avoid the resize, as the widget will be resized on
becoming visible anyway.
This avoids a lot of size allocation for hidden things like menus
and tooltips.
Almost all array computations lead to no changes (99% in nautilus)
so we avoid the upfront allocation and delay it until we know its
needed. This drops the allocate/free from the profile.
These are internal apis, and any external issues should have been
caught by checks at public API points. We use the internal checks
here because these checks show up in a non-neglible way on profiles.
The file chooser will not accept dropping URIs in a shortcut item. However, Nautilus will,
to perform normal DnD for files.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
pasteboardChangedOwner is not called as reliably as we'd want to get it,
so keep track of [pasteboard changeCount] and drop clipboard ownership
when a change happened. Also better unset the clipboard content redundantly
in a few places rather than missing one, and reorder the code in
gtk_clipboard_set_contents() so that the new aggressive unsetting
won't unset the clipboard under our feet when we call
[pasteboard declareTypes].
(cherry picked from commit f2b74db5dc)
We'll use this signal to ask the caller about what drag action to indicate
when something is being hovered on an item in the places sidebar.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We now support the keywords (like xx-small, medium, larger, smaller...)
and I've changed the default value to be "medium".
This required some shuffling of the "get default font size" code. But
all is well now.
The default font is no longer handled like a custom style sheet that
overrides everything, but as the initial value. This is the same
behavior as in web browsers.
And it allows the theme to actually use the 'font-family' and
'font-size' properties. Of course, a well behaved theme will respect the
setting as much as possible and for example use relative font sizes
(which aren't yet supported, but will be soon).
This gives a GtkSettings object for resolving system-dependant things -
like the default font family and font size.
No code does this yet, but we have an API.
Only GtkSettings implements this.
Per the gtk-devel meeting on 2012/11/29, we'll not have a UI in the file chooser dialog
to select between those modes. Instead, we'll show that key in gtweaktool.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The new css tree may change the order of selectors (keeping the
same semantics). This affects how the selectors are printed later,
which causes some css parsing tests to not match the references.
Fortunately the order is consistent between runs given the same
css, so we just have to switch around the order in some of the
.ref.css files.
Now we use the selector tree everywhere, so there is no need to
keep around the linear selectors unless we're using them to
verify the tree correctness, so free them.
We add some "artificial" ordering to the otherwise unordered
tree nodes. This means the tree will be the same every time for the
same input. This is good because e.g. tree order affects the
reordering of the simple selectors, which may affect how
css providers are printed, which need to be consistent for
the css tests to work.
When building the tree we generally reorder the selectors inside
the same simple selector in order to pick a good first selector
to balance the tree better. However, some kinds of selectors
can't really be reordered, even thought they are simple.
This is since the matching code for some types handle
the existance of a directly preceeding selector differently:
REGION and ANY selectors look for a DESCENDANT previous
POSITION selector look for a REGION previous
From a set of GtkCssSelectors and the rulesets they match to
we create a large decision tree that lets us efficitently match
against all the rules and return the set of matched rulesets.
The tree is created such that at each level we pick the initial rule[1]
in all the considered selectors for that level and use put the
one that is in most selectors in the node. All selectors matching that
are put in the previous part of the tree.
This returns true if the matcher matches *anything*. We need
to check this later, because such matchers are dangerous in loops
that iterate over all parents/siblings since such loops would not
terminate.
With the previous commit all loads of the same icon will share a single
GtkIconInfo, which typicallty means the pixbuf is shared via Info->pixbuf.
However, atm we don't share symbolic icons, which causes these to be re-read
and re-parsed every time. This is especially bad if the icon is used many times
in some form of list. So, we cache the pixbufs and reuse them.
https://bugzilla.gnome.org/show_bug.cgi?id=689081
In order to avoid loading and keeping around the same icon multiple times
we keep a cache of all outstanding GtkIconInfo objects for a given theme.
Additionally we return to the app not the normal pixbuf from the info,
but rather a proxy copy of it sharing the same data, but no extra
reference. This allows us to track when the app is no longer using
the pixbuf, and we can thus ensure that the GtkIconInfo in the cache
stays around for at least as long as the pixbuf is alive.
When the app unrefs the pixbuf we put the Info on a short LRU list
to keep it alive a bit longer, in case the app needs it in a short
while.
https://bugzilla.gnome.org/show_bug.cgi?id=689081
This was broken since commit b2aaa94 in 2008. Its commit message
clearly states that the intention was to check for GTK_GRAB,
GTK_UNGRAB and STATE_CHANGED. Lets do that, then.
This was found by Coverity.
Both flashing a window and setting the window opacity were using
incorrect declarations for function pointers. They were missing the
WINAPI annotation as defined in windows.h. As a result, the stack
could be corrupted when these functions were invoked.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=689235
(cherry picked from commit 5637ef1f97)
gtk+ was trying to display already freed strings, leaking memory,
...I noticed this because I was getting weird blinking characters
as the status of my cups printers, and valgrind confirmed something
was wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=683072
... so we don't bump a refcount whenever we get the initial singleton.
We want to use this function instead of
_gtk_css_style_property_get_initial_value() everywhere where we compute
values, because some initial values may depend on settings soon.
Resizes are queued via
gtk_widget_propagate_state()
=> gtk_style_context_set_state()
=> gtk_style_context_queue_invalidate()
=> gtk_style_context_validate()
=> _gtk_widget_style_context_invalidated()
so there's no need to queue an extra one.
Symbolic colors are an implementation detail of the CSS engine and have
been superceded by GtkCssColorValue. We don't want them clobbering the
public API. In particular because the only use I could find in the
public API is people using it to shade colors.
Make _gtk_style_provider_private_get_color() return a GtkCssValue (a
GtkCssColorValue to be exact) instead of GtkSymbolicColor.
With this, the symbolic color usage inside GTK is minimized.
The documentation for gtk_file_chooser_get_filenames() states that the
returned filenames are absolute paths, and uses g_file_get_path() to
construct the filename. The same function is used to construct the
filename in gtk_file_chooser_get_filename(), so it should also return
absolute paths.
https://bugzilla.gnome.org/show_bug.cgi?id=371034
This is so that the sidebar will already know the URI of the location it is showing. When
the caller asks the sidebar to change back to the same location, the call will be idempotent.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
To be consistent with the ::location-selected signal, which emits a GFile, we now also use a GFile
instead of a string URI in the inbound API.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
That URI is not a native file, and so it would not show up if local_only=TRUE.
Add a special case for it so that recent:/// can always be visited.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
It has two possible values, 'recent' and 'cwd'. We will use these to determine
whether to set the default starting mode, if a folder has not been pre-set,
to showing the Recent Files list or the current working directory.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Instead of having a nested-callback scheme (to preserve internal API compatibility),
we use a direct callback from g_volume_mount().
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We add a method to say whether the trash is full/empty (to use the appropriate icon),
and a signal that the sidebar can use to request that the trash be emptied when
the user selects 'Empty trash' from the context menu.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Currently they default to false. This also fixes warnings with uninitialized widgets
in bookmarks_check_popup_sensitivity().
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We query the file info for display name and icon synchronously. If it becomes a problem,
we'll make it async, more in line with NautilusBookmark.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This syncs the code up to commit 4b6abf644b from Nautilus.
This only refers to nautilus-places-sidebar.[ch].
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We use the normal gtk_style_context_set_state() machinery to set a
prelighted state. Hopefully even symbolic icons will be rendered
prelighted properly.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We need to ask the caller to pop up error messages for us, so it can do
it with its own conventions: pick the right transient window, use a status
bar rather than a dialog, etc.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
It sucks to have this as an app-settable option. Maybe we should
make this a standard GSetting thing and be done with it.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The file chooser will leave these off by default; file managers
like Nautilus will turn them on.
These control whether the places sidebar shows 'open in new tab' and similar
items in its context menu.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Don't try to decide if the URIs are acceptable / not duplicates; the
idea is to let the user bookmark whatever he pleases.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This signal just carries a boolean initiated_unmount argument, which
is meant to say True when the unmount/eject starts, and False when
the operation finishes.
We may want to rename all of this to unmount_started / stopped, etc.
I don't know if the caller needs to know about the mount_op in question,
or if it can be inferred from what the caller knows to be the current
shown location on the GtkPlacesSidebar.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Now we just need to see if we need to replace calls to
nautilus_window_set_initiated_unmount() with a signal.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
There are still some missing pieces to get the bookmark's icon,
and *maybe* to cull the list of bookmarks based on some criteria.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
It's unfortunate that now we have two instances of the bookmarks manager
for each GtkFileChooserButton; one for the button itself and one for the
underlying GtkFileChooserDefault. We may refactor that in the future.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We had the bookmarks machinery in GtkFileSystem for historical reasons.
Now, we'll keep this separately. This will allow us to make the
bookmarks machinery public if needed in the future.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Conflicts:
gtk/Makefile.am
Instead of directly calling the Nautilus machinery to open locations
in tabs or windows, we emit a signal which the caller must handle.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Nautilus lets you open things in the same tab, in a new tab, or in
a new window. We will expose these semantics through an enum, as
part of an 'open' signal.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
cat $(top_srcdir)/build/win32/vs10/$(MSVC_SLN).sln | sed 's/11\.00/$(MSVC_FORMAT_VER)\.00/g' | sed 's/2010/$(MSVC_VER_LONG)/g' > $(top_builddir)/build/win32/vs$(MSVC_VER)/$(MSVC_SLN).sln
cat $(top_srcdir)/build/win32/vs10/README.txt | sed 's/vs10/vs$(MSVC_VER)/g' | sed 's/VS10/VS$(MSVC_VER)/g' > $(top_builddir)/build/win32/vs$(MSVC_VER)/README.txt
create_vcxproj:
for F in `(cd $(top_builddir)/build/win32/vs10 && ls *.vcxproj)`; do \
case $$F in \
*) cat $(top_builddir)/build/win32/vs10/$$F | sed 's/v100/v$(MSVC_VER)0/g' > $(top_builddir)/build/win32/vs$(MSVC_VER)/$$F \
;; \
esac; \
done
create_props:
for F in `(cd $(top_builddir)/build/win32/vs10 && ls *.props)`; do \
case $$F in \
*) cat $(top_builddir)/build/win32/vs10/$$F | sed 's/<VSVer>10<\/VSVer>/<VSVer>$(MSVC_VER)<\/VSVer>/g' > $(top_builddir)/build/win32/vs$(MSVC_VER)/$$F \
if exist ..\..\..\MSVC_$(Configuration) goto DONE_GDKCONFIG_H
if exist ..\..\..\gdk\gdkconfig.h del ..\..\..\gdk\gdkconfig.h
if exist ..\..\..\GDK_BROADWAY_BUILD del ..\..\..\GDK_BROADWAY_BUILD
if exist ..\..\..\MSVC_$(Configuration)_Broadway del ..\..\..\MSVC_$(Configuration)_Broadway
if exist $(Configuration)\$(Platform)\bin\$(GtkDllPrefix)gdk$(GtkDllSuffix).dll del $(Configuration)\$(Platform)\bin\$(GtkDllPrefix)gdk$(GtkDllSuffix).dll
if exist $(Configuration)\$(Platform)\bin\gdk-$(ApiVersion).lib del $(Configuration)\$(Platform)\bin\gdk-$(ApiVersion).lib
if "$(Configuration)" == "Release" del ..\..\..\MSVC_Debug
if "$(Configuration)" == "Debug" del ..\..\..\MSVC_Release
if exist ..\..\..\MSVC_$(ConfigurationName) goto DONE_GDKCONFIG_H

if exist ..\..\..\gdk\gdkconfig.h del ..\..\..\gdk\gdkconfig.h

if exist ..\..\..\GDK_BROADWAY_BUILD del ..\..\..\GDK_BROADWAY_BUILD

if exist ..\..\..\MSVC_$(ConfigurationName)_Broadway del ..\..\..\MSVC_$(ConfigurationName)_Broadway

if exist $(ConfigurationName)\$(PlatformName)\bin\$(GtkDllPrefix)gdk$(GtkDllSuffix).dll del $(ConfigurationName)\$(PlatformName)\bin\$(GtkDllPrefix)gdk$(GtkDllSuffix).dll

if exist $(ConfigurationName)\$(PlatformName)\bin\gdk-$(ApiVersion).lib del $(ConfigurationName)\$(PlatformName)\bin\gdk-$(ApiVersion).lib

if "$(ConfigurationName)" == "Release" del ..\..\..\MSVC_Debug

if "$(ConfigurationName)" == "Debug" del ..\..\..\MSVC_Release

Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
