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.
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>
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>
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>
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>
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.
