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
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.
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.
(cherry picked from commit 76e466197a)
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.
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.
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
... 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.
https://bugzilla.gnome.org/show_bug.cgi?id=695715
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.
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
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
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.
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
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.
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 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.
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.
pasteboardChangedOwner is not called as reliably as we'd want to get it,
so keep track of [pasteboard changeCount] and drop clipboard ownership
when a change happened. Also better unset the clipboard content redundantly
in a few places rather than missing one, and reorder the code in
gtk_clipboard_set_contents() so that the new aggressive unsetting
won't unset the clipboard under our feet when we call
[pasteboard declareTypes].
(cherry picked from commit f2b74db5dc)
We now support the keywords (like xx-small, medium, larger, smaller...)
and I've changed the default value to be "medium".
This required some shuffling of the "get default font size" code. But
all is well now.
The default font is no longer handled like a custom style sheet that
overrides everything, but as the initial value. This is the same
behavior as in web browsers.
And it allows the theme to actually use the 'font-family' and
'font-size' properties. Of course, a well behaved theme will respect the
setting as much as possible and for example use relative font sizes
(which aren't yet supported, but will be soon).
This gives a GtkSettings object for resolving system-dependant things -
like the default font family and font size.
No code does this yet, but we have an API.
Only GtkSettings implements this.
The new css tree may change the order of selectors (keeping the
same semantics). This affects how the selectors are printed later,
which causes some css parsing tests to not match the references.
Fortunately the order is consistent between runs given the same
css, so we just have to switch around the order in some of the
.ref.css files.
Now we use the selector tree everywhere, so there is no need to
keep around the linear selectors unless we're using them to
verify the tree correctness, so free them.
We add some "artificial" ordering to the otherwise unordered
tree nodes. This means the tree will be the same every time for the
same input. This is good because e.g. tree order affects the
reordering of the simple selectors, which may affect how
css providers are printed, which need to be consistent for
the css tests to work.
When building the tree we generally reorder the selectors inside
the same simple selector in order to pick a good first selector
to balance the tree better. However, some kinds of selectors
can't really be reordered, even thought they are simple.
This is since the matching code for some types handle
the existance of a directly preceeding selector differently:
REGION and ANY selectors look for a DESCENDANT previous
POSITION selector look for a REGION previous
From a set of GtkCssSelectors and the rulesets they match to
we create a large decision tree that lets us efficitently match
against all the rules and return the set of matched rulesets.
The tree is created such that at each level we pick the initial rule[1]
in all the considered selectors for that level and use put the
one that is in most selectors in the node. All selectors matching that
are put in the previous part of the tree.
This returns true if the matcher matches *anything*. We need
to check this later, because such matchers are dangerous in loops
that iterate over all parents/siblings since such loops would not
terminate.
With the previous commit all loads of the same icon will share a single
GtkIconInfo, which typicallty means the pixbuf is shared via Info->pixbuf.
However, atm we don't share symbolic icons, which causes these to be re-read
and re-parsed every time. This is especially bad if the icon is used many times
in some form of list. So, we cache the pixbufs and reuse them.
https://bugzilla.gnome.org/show_bug.cgi?id=689081
In order to avoid loading and keeping around the same icon multiple times
we keep a cache of all outstanding GtkIconInfo objects for a given theme.
Additionally we return to the app not the normal pixbuf from the info,
but rather a proxy copy of it sharing the same data, but no extra
reference. This allows us to track when the app is no longer using
the pixbuf, and we can thus ensure that the GtkIconInfo in the cache
stays around for at least as long as the pixbuf is alive.
When the app unrefs the pixbuf we put the Info on a short LRU list
to keep it alive a bit longer, in case the app needs it in a short
while.
https://bugzilla.gnome.org/show_bug.cgi?id=689081
This was broken since commit b2aaa94 in 2008. Its commit message
clearly states that the intention was to check for GTK_GRAB,
GTK_UNGRAB and STATE_CHANGED. Lets do that, then.
This was found by Coverity.
Both flashing a window and setting the window opacity were using
incorrect declarations for function pointers. They were missing the
WINAPI annotation as defined in windows.h. As a result, the stack
could be corrupted when these functions were invoked.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=689235
(cherry picked from commit 5637ef1f97)
gtk+ was trying to display already freed strings, leaking memory,
...I noticed this because I was getting weird blinking characters
as the status of my cups printers, and valgrind confirmed something
was wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=683072
... so we don't bump a refcount whenever we get the initial singleton.
We want to use this function instead of
_gtk_css_style_property_get_initial_value() everywhere where we compute
values, because some initial values may depend on settings soon.
Resizes are queued via
gtk_widget_propagate_state()
=> gtk_style_context_set_state()
=> gtk_style_context_queue_invalidate()
=> gtk_style_context_validate()
=> _gtk_widget_style_context_invalidated()
so there's no need to queue an extra one.
Symbolic colors are an implementation detail of the CSS engine and have
been superceded by GtkCssColorValue. We don't want them clobbering the
public API. In particular because the only use I could find in the
public API is people using it to shade colors.
Make _gtk_style_provider_private_get_color() return a GtkCssValue (a
GtkCssColorValue to be exact) instead of GtkSymbolicColor.
With this, the symbolic color usage inside GTK is minimized.
The documentation for gtk_file_chooser_get_filenames() states that the
returned filenames are absolute paths, and uses g_file_get_path() to
construct the filename. The same function is used to construct the
filename in gtk_file_chooser_get_filename(), so it should also return
absolute paths.
https://bugzilla.gnome.org/show_bug.cgi?id=371034
When event capturing is enabled, stop propagating scroll events
at insensitive widgets, but don't handle them (don't return TRUE),
so they can bubble up again and reach their handling widgets.
Activate the "hides on deactivate" behavior for splashscreens,
torn-off menus, utility windows, tooltips and notifications: when
another application is brought to the front, these windows are hidden
so as not to obscure it. This is the expected behavior for
application-specific floating windows on OS X.
(cherry picked from commit 0596f5591f)
Render a background with gtk_render_background() in draw() instead.
Note that we still use gtk_style_context_set_background() for the header
window.
https://bugzilla.gnome.org/show_bug.cgi?id=688744
Make it so that the repeating vs normal test only uses sharp color
cutoffs instead of real gradients. That removes rounding errors and
makes the test pass.
so GtkMenu works properly. This is not right, but not more
wrong than always sending GDK_NOTIFY_ANCESTOR either.
(cherry picked from commit 35a9322e45)
Based on a patch from Paul Davis, inject synthetic enter events directly
into the Quartz event stream, instead of trying to synthesize them in GDK.
This seems to magically fix most combo box popup weirdness, I guess
some code is relying on a specfic order of events, or any other state
imposed by the "proper" code path of events coming in the usual way.
The patch also removes _gdk_quartz_events_send_enter_notify_event()
which is now obsolete.
(sortof cherry-pixked from 979e5061a0
but needed manual editing because GdkQuartzWindow.c was renamed
and apparently earlier patches not picked correctly/completely)
so they can appear on top of popup menus. Also, reorder the switch()
statement in window_type_hint_to_level() so it resembles the stacking
order, to avoid confision like this in the future. Fixes bug 688512.
(cherry picked from commit 1a2509a6ab)
Don't try to handle button press events on the window frame, they
have out-of-window coordinates. Also, break grabs on such events
so popup menus go away.
Patch from Kristian Rietveld, fixes bug 684419.
(cherry picked from commit 43e1354b71)
This reverts the size_allocate removal from commit
8449e05865. That code was using
_gtk_window_set_allocation() instead of gtk_widget_set_allocation(). And
that broke glade.
We can set for_size to -1 earlier than we did. Doing so makes sure we
only cache one value (as we should in the first place). In GTK 3.6, this
worked properly, but with Previously, this check was moved further up to
avoid interacting with size groups. But after recent refactorings, size
groups are handled way earlier anyway.
... instead of GtkSizeGroupMode. Orientation is what we're interested in
after all. When we need a GtkSizeGroupMode, we can do the translation
where we need it.
which does not really have a different effect than the previously
used NSPopUpMenuWindowLevel, but is what all code examples I found
are using, and it does make more sense.
(cherry picked from commit 47f0e3f1e1)
Application code can set shortcut folders that are already bookmarks.
This code causes the bookmarks to be refreshed after the shortcut is
added removing any possible bookmark duplicates
https://bugzilla.gnome.org/show_bug.cgi?id=577806
Expose GtkEntry icons as child accessibles of a GtkEntry, and provide
actions to simulate clicking them. Also, refactor the a11y children test
slightly to add a test.
https://bugzilla.gnome.org/show_bug.cgi?id=686347
The bitmasks with the 31st, 32nd and 63rd bit set are added. The make up
the largest bitmasks on 32bit/64bit that can be represented without
allocating and the smallest bitmask on 32bit that must be allocated.
With the fix in 77912a65e2, another bug
got visible: booleans are 32 bits, so if the intersection between the 2
bitmasks happened in higher bits, the return value would be truncated to
FALSE.
This actually made slider handles disappear, so it was pretty visible.
BIG NOTE: We fail on some of these to give the colors defined in the CSS
specs. This is not good, but I'm not sure how to best fix it.
For those cases, I've kept the correct color in the CSS file but added
the correct one next to it.
If lookup->missing is empty we don't need to continue looking.
We short circuit in several places as this can happen
after iteratively makeign lookup->missing smaller.
We need to use the allocated codepath if *any* argument is
allocated, not if one arg is not allocated.
This bug caused unnecessary calls to _gtk_bitmask_is_allocated,
as well as return completely wrong result if both bitmask are
allocated.
What is this bin doing with all these crazy deltas? Company does:
<Company> that can safely be removed
<Company> in general, code that isn't obvious can either be understood
<Company> with a bit of thinking or it can be removed
<Company> if in doubt, go for the 2nd of those :)
Most GtkBin subclasses override this strange garbage anyway, so it's
not like this code is ever *run*, per se. Just make it proxy directly
to the child, and hope nothing goes wrong.
Implement get_preferred_width, get_preferred_height, and size_allocate.
This allows GtkBin subclasses to be quick and easy, without the
author doing the subclassing to have to do much work.
If the "wider" label is the smaller one, use the wider size for both
cases. This can happen when ellipsizing a single character, which is
often smaller than the ellipsizing glpyph(s).
Functions should not have a space before the opening parenthesis. So
change output like
alpha (@color, 0.5)
to
alpha(@color, 0.5)
and do the same for "shade" and "mix".
Tests have been updated accordingly.
This is so newer versions of those libraries don't cause more warnings
with a stable GTK version.
We don't ever want to turn off deprecation warnings for master however,
because that's where we get rid of deprecated API we use.
Note that only glib allows use to easily do this, so nothing is done for
Pango, gdk-pixbuf or Cairo here.
With ellipsizing, the ellipsized text can have a smaller height than the
non-ellipsized text. So the wider text is also higher. Example:
.<big>TEXT</big>
will ellipsize to the small text.
Reported-By: Rico Tzschichholz <ricotz@t-online.de>
We must make sure to remove the weak pointer when disposing the widget
or when resetting the align widget otherwise glib will try to nullify
invalid memory.
This way we don't need a marker on GtkWidgetParivate that needs to be
unset later, so we have all our data in the same place and can avoid
problems with reentrancy and shenanigans like that.
But the main reason I wrote that is cleaner code.
With this function now available, we can do size computation in 2
ways:
(1) Compute size with size groups
(2) Compute size without size groups
And have (1) use (2) instead of setting flags on widgets. This patch
does exactly that.
With size groups now doing hfw, doing the optimization for CONSTANT_SIZE
was done too early. Size groups need to know that it's a hfw request, so
the other widgets in the size group get the correct behavior.
The label code assumed that Pango treats this as "wrap to as much space
as possible and then ellipsize all the lines", but for Pango, ellipsize
takes precedence over wrap. So do the same thing in GtkLabel.
Also updated is the reftest that checked this behavior.
Get rid of all the event boxes in this test. Event boxes need GDK
windows which cost a lot of performance when running the test and they
clip the label output.
Getting rid of the clipping also shows 2 bugs in this test that weren't
visible before. Those will be fixed in a followup patch.
We compute on-demand for size groups anyway, so we can (in theory, this
patch doesn't do that yet) get around costly cache blowing when
invalidating single widgets of a size group this way.
The current approach of using gtk_widget_get_mapped() is broken:
The usual steps taken when showing a window are:
(1) request the sizes
(2) allocate the sizes
(3) show the window in the allocated size
Showing the window with a random size between steps (1) and (2) would of
course
result in extra work and potential flickering when the widgets get
resized to
their proper sizes.
However, as GtkSizeGroup::ignore-hidden uses gtk_widget_get_mapped() to
determine visibility for a widget, the following will happen:
(1) the widget will request a 0 size
(2) the widget will be allocated a 0 size
(3) the widget will be too small when it is shown
gtk_widget_get_visible() however is set in advance. Note that toggling
visibility also causes a gtk-widget_queue_resize() call already so we
take care of changes in here automatically.
Instead of only checking the ignore_hidden flag when getting the
preferred sizes, respect it already when constructing the list of
widgets. This way, widgets don't queue resizes for groups they're
ignored in anyway.
For loops to loop over lists look nicer and actually do the right thing
with "break" and "continue" statements. So they are vastly preferred to
while loops.
This simplifies code and because sizes are cached by the widgets
themselves, it's not a large performance problem (unless people use huge
amounts of widgets in a single size group, but who does that?
The main problem is that we were emitting the row-deleted signal for the model in the middle
of the process that actually deletes the row from the model (remove the row from the array,
update the model->file_lookup hash table, etc.). In the model's caller, one of the row-deleted
callbacks was requesting an iter, which caused the model to revalidate itself - but it did
this while it was in an inconsistent state. This led to an assertion failure later when the
model resorted itself.
The fix in remove_file() is like this:
* The filteredness/visibility of the deleted node is not updated. The
node will simply be gone; we don't need to update those values at
all.
* We invalidate just the node that is being deleted.
* The model->file_lookup hash table is not completely nuked; instead,
we carefully adjust its indices.
* The row-deleted signal is only emitted at the very end, when
deletion is complete and the model is consistent.
Many thanks to William Hua for doing the detective work on this bug!
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
They were in the semi-public API of GtkFileSystemModel, but never actually used outside of it.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This is a function internal to the file system model; let's not pollute the gtk_tree_path namespace.
Also, make the 'i' variable into 'r' as it refers to a row index, not a file-array index (for
consistency with the docs and the rest of the code).
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Right now we support loading and recoloring symbolic GFileIcons, but
only if the underlying GFile has a local path. This breaks when the
GFileIcon is loaded from a GResource, which is a reasonable option for an
application that wants to ship a custom symbolic icon.
This patch changes GtkIconInfo to store a GFile together with the file
path, and changes the symbolic icon lookup code to use the GFile URI,
which transparently makes the code work also for GResources.
https://bugzilla.gnome.org/show_bug.cgi?id=687059
Move variable initialization outside the first code with side effects.
This allows adding some more early returns, including one for code that
used to trigger g_return_if_fail() in certain corner cases.
Old code tried to use the "background-image" proeprty for setting the
default image background. While this used to work in the early days of
GTK3, today it is grossly misleading as the backgronud image may be
resized, repositioned and semi-translucent which causes very weird
artifacts when rendering.
So we use the background-color only instead.
This way we create one provider per settings object instead of stuffing
it into a global unchanging never-deleting hash table.
Also, we now reload the theme when instructed instead of keeping the old
loaded (and possibly stale) data forever.
https://bugzilla.gnome.org/show_bug.cgi?id=683896
This makes sure the full theme loading logic resides in one function and
isn't scattered around.
As a side-effect, the hash table kept by gtk_css_provider_get_named()
will now be populated with fallback themes. This will not be a problem
after the next commit though.
Split maintaining the global themes hash table and the theme loading
code into two functions.
This also fixes leaking the provider when loading a theme from a builtin
resource.
libxkbcommon has had some changes to its API. However, it now has a
stable release (0.2.0), so this makes the necessary changes, and
replaces all uses of the deprecated API.
Signed-off-by: Ran Benita <ran234@gmail.com>
Themes may want to render handles differently depending on whether
the widget is in selection mode (2 handles enclosing a selection) or
cursor mode (one handle pointing out the insertion cursor).
This improves both interaction and theming, as it allows
arbitrary handle shapes while just being draggable from
the visible areas.
This way themes can set up handles with the hotspot visually
displaced from the horizontal center, as long as the hotspot
lies centered in the image/svg asset.
The check on the handle to be drawn on the mask was based on the yet to
be set priv->windows pointers, pass explicitly the handle position to
have the shape correctly initialized on non-composited environments
The GtkNotebook drag-motion event handler may install a timeout when
hovering over a tab, in order to switch to it.
On the other hand it's desirable for applications to use the empty tab
area as a drop target, so the drag-motion handler returns FALSE
(also in case it installs the switch tab timeout), as explained in
https://bugzilla.gnome.org/show_bug.cgi?id=350665.
Unfortunately, applications can use the tab label widget (or a child
of it) as a different drop target area, and install their own
drag-motion handler there.
In this scenario, the timeout will still be installed by GtkNotebook's
handler, but since it returns FALSE, it will never get the matching
drag-leave event, causing it to trigger also when the mouse pointer
moved elsewhere before it expired.
Fix this by returning TRUE from drag-motion when the event is over a
tab. Note that this makes automatic tab switching not work anymore when
drag and drop is handled in the tab label widget; applications are
expected to also handle tab switching if desired in such a case.
https://bugzilla.gnome.org/show_bug.cgi?id=684415
GtkScrollbar used to rely on style-updated being emitted every time
after the widget was created in order to set the right values from its
style properties on GtkRange.
Nowadays we try to be smarter and avoid emitting style-updated at
creation time, so we need to manually initialize the GtkRange values.
This fixes a regression from 35e36b9fe5.
https://bugzilla.gnome.org/show_bug.cgi?id=686280
Currently we use gtk_style_context_set_background() when the state flags
change in order to propagate the background color to the overshoot
window, but this is actually only needed because the window doesn't get
expose events, since we always draw a full background in draw().
This also fixes some problems when the GdkWindow of the scrolled
window's child is composited, as seen in oxygen-gtk3.
https://bugzilla.gnome.org/show_bug.cgi?id=686265
The implementation of transition for GtkCssShadowValue can return NULL
at least when the two values have a different inset; all other parts of
the GTK/CSS machinery (e.g. GtkCssArrayValue) handle this by returning
NULL too. Instead, GtkCssShadowsValue was returning an invalid value,
where "len" was set, but some values in the array were NULL, which would
lead to a segfault when this value is later evaluated by the compute
function.
Fix this by making GtkCssShadowsValue return NULL if a shadow transition
fails, like GtkCssArrayValue does.
https://bugzilla.gnome.org/show_bug.cgi?id=686013
Don't use a repeating linear gradient, since it can't be easily
reftested against a non-repeating one for the reasons described in the
test header.
Instead, add a separate test for repeating gradients (against another
repeating gradient).
This makes the test pass, so it can be added to the Makefile now.
Parsing a shorthand background property was running into unexpected
errors when trying position values where there were none. To fix this,
introduce a try_parse variant of the position parse function that
silently returns NULL.
Move instance fields to a private struct, in preparation
for installing a11y headers.
This also required removing access to GtkWidgetAccessible innards
from several accessible implementations.
Move instance fields to a private struct, in preparation
for installing a11y headers.
This also required removing access to GtkToplevelAccessible innards
from the GtkWindowAccessible implementation.
Move instance fields to a private struct, in preparation
for installing a11y headers.
This also required removing access to GtkRendererCellAccessible innards
from various cell accessible implementations.
Move instance fields to a private struct, in preparation
for installing a11y headers.
This also required removing access to GtkContainerCellAccessible
innards from the GtkCellAccessible implementation.
Move instance fields to a private struct, in preparation
for installing a11y headers.
This also required removing access to GtkContainerAccessible innards
from the GtkMenuItemAccessible implementation.
Before we used a window's background color, which resulted in corrupted
display in some cases, presumably because we didn't reset the active
pattern. This patch seems to eliminate the observed corruption.
(cherry picked from commit 0e42cf81f1)
This avoids a case where the display has been opened, but calling
gdk_display_get_default() in the callback doesn't work.
Reviewed-by: Benjamin Otte <otte@redhat.com>
... instead of from the intrinsic value. This way, we respect running
animations.
Note that the concept of "reversing" transitions is not implemented yet.
Otherwise, that value will never get reset and remain frozen in time.
This is problematic for example when the value is inherited and the
parent changes the value.
When positioning the scrollbar we were doing several miscalculations
when accounting for CSS paddings and borders. This also fixes a number
of problems with RTL and when scrollbars-within-bevel is FALSE.
https://bugzilla.gnome.org/show_bug.cgi?id=685449
I'm adding a bunch of fixes for gcc complaining about
-Wmissing-declarations after finding a bunch of cases today where I
had forgotten to make functions static in the CSS code.
This patch fixes the tests in gtk/tests.
After this last patch, the gtk/ subdir should now compile without
warnings when this flag is enabled.
This is part of a bunch of fixes for gcc complaining about
-Wmissing-declarations.
It puts functions into headers and includes those headers both where the
functions are defined and where they function are used.
Also remove the starting underscore from function names where
appropriate, as those functions are static now and not exported anymore.
This is part of a bunch of fixes for gcc complaining about
-Wmissing-declarations.
I'm adding a bunch of fixes for gcc complaining about
-Wmissing-declarations.
This set of patches makes private classes in gtk/*.c that use
G_DEFINE_TYPE() safe by adding definitions for the get_type() function
that can't be made static.
I'll add a bunch of fixes for gcc complaining about
-Wmissing-declarations after finding a bunch of cases today where I had
forgotten to make functions static in the CSS code.
A thorn in those patches is G_DEFINE_TYPE() which doesn't allow making
the get_type() function static, so I added definitions for that function
above the G_DEFINE_TYPE().
After those patches, GTK should compile without warnings when this flag
is enabled.
It seems we missed updating this since GTK+3, widgets cannot be
allocated less than the size they requested in thier request
phase, and explicit sizes are used only to grow the size request.
This is intended mainly to speed up the current situation with spinners
on debug kernels. Because we now don't use a cross-fade to draw the
transition but instead have a real gradient that we draw, we don't need
to use the slow cross-fade code.
https://bugzilla.gnome.org/show_bug.cgi?id=684639
We need to store the border widths independant of them being set to 0 by
border styles, because otherwise we'd need to track that dependency and
recompute on changes, and I don't want to add more entries to
GtkCssDependencies just for this special case.
By moving the code that does the setting to 0 from the compute stage to
the query stage, we can achieve this.
Now we need to just be aware that the actual value stored is not set to
0 when we use gtk_css_computed_values_get_value().
By calling XSync in _gdk_x11_display_after_process_all_updates we
effectively make gdk rendering sync, which avoids problems with the
client animations running faster than the Xserver rendering, thus
filling up the X rendering pipes and essentially "locking up" the
Xserver (i.e. you can't even close the offending window because the
WM is starved too).
I verified this worked by making GtkSpinner paint multiple times on my
intel driver (which has some issue making this rendering slow atm),
and without this patch i get severe lag where even window dragging
stops for 5 seconds when i drag the mouse around. However, with the
patch everything is smooth.
https://bugzilla.gnome.org/show_bug.cgi?id=684639
GDK_WINDOW_XID() has the side-effect of turning a window native;
this in turn can have unexpected effects such as black backgrounds.
Avoid this by using the XID of the toplevel.
https://bugzilla.gnome.org/show_bug.cgi?id=682395
Otherwise the evil widgets that don't chain up their map and unmap
vfuncs will not get updated style contexts. This is in particular true
for GtkWindow and the CSS Theming / animated backgrounds demo in
gtk-demo.
Here's the shortest description of the bug I can come up with:
When computing values, we have 3 kinds of dependencies:
(1) other properties ("currentColor" or em values)
(2) inherited properties ("inherit")
(3) generic things from the theme (@keyframes or @define-color)
Previously, we passed the GtkStyleContext as an argument, because it
provided these 3 things using:
(1) _gtk_style_context_peek_property()
(2) _gtk_style_context_peek_property(gtk_style_context_get_parent())
(3) context->priv->cascade
However, this makes it impossible to lookup values other than the ones
accessible via _gtk_style_context_peek_property(). And this is exactly
what we are doing in gtk_style_context_update_cache(). So when the cache
updates encountered case (1), they were looking up the values from the
wrong style data.
So this large patch essentially does nothing but replace the
context argument in all compute functions with new arguments for the 3
cases above:
(1) values
(2) parent_values
(3) provider
We apparently have a lot of computing code.
The garbage would be visible if any widget enabled the toplevel
NSView's CALayer in order to do custom native rendering.
(cherry picked from commit 92ea94af5f)
This is needed for the SELECTION_NONE mode where nothing is ever
selected, but its also needed for CTRL-<key> keynav that moves the
focus without changing the selection.
https://bugzilla.gnome.org/show_bug.cgi?id=684984
Currently the GdkWindow used for dragging is created once when
the first drag starts, and the reused identical each time.
Instead, just recreate it for each drag, with the correct size.
This reverts commit f2cb8f1270.
The patch actually didn't work for at least text. I currently have no
clue why, but I suspect it requires investigating Cairo code and
recording surfaces, and I'll not do that right now.
Split out the blurred shadow rendering in three steps:
- creation of a surface of the appropriate size - we use the clip
rectangle as a good measurement for the size, since we won't render
out of it anyway
- painting the unblurred shape on the surface - this is responsibility
of the single shadow implementations
- blur the surface and compose the result back on the original cairo_t
This means we can share code between the implementations for the first
and third steps; it also makes the code independent of the rendered
size, so we can avoid passing down a cairo_rectangle_t with e.g. the
icon coordinates.
The code accesses pixels in a chunks of 4 bytes, so we must only support
formats where the size of a single pixel is 4 bytes.
Fix RGB24 to be 4 bytes (the alpha channel is ignored) and disallow A8.
We were adding one child too much to the style context path when
generating it for the internal buttons, which in turn caused sibling
selectors from the theme such as :first-child to apply to both buttons
under certain circumstances. Spotted by Lapo Calamandrei.
As long as we don't have an API for explicitly inverting the bar, it
makes more sense for the progress in vertical orientation to fill from
the bottom.
In the event that a GtkAccelKey was present for the closure but it
contained a keyval of 0 the previous code would show "". After the
recent adjustments, "-/-" would be shown in this case.
It turns out to be a pretty common case, so fix the logic to stop using
'0' as a magic value to mean "don't have an accel" and add a separate
boolean for that purpose.
This reverts commit 1f5dea9eba,
since it was causeing noticable behaviour changes.
Previously, GTK_DATA_PREFIX=/ ./gtk3-demo would start
gtk3-demo with the Raleigh theme. With that change, it
was starting with no theme at all (i.e. all black).
While regular animations should always be created, transitions should
not. This patch allows to express this by passing NULL as the values to
transition from.
It also adds a gtk_style_context_should_create_transitions() function
that returns TRUE when transitions should be created.
... that actually was both wrong, a performance failure and has been
there since the original checkin.
Updating the cached style data absolutely does not mean clearing all
cached style data first. There's nothing to update then.
This will be useful to not trigger updates all the time when nothing is
happening (ie due to animations being paused or due to them having
reached their final value).
This adds the GtkCssAnimation class and the code needed to hook it into
GtkStyleContext. It takes the values out of the CSS "animation"
properties and does animations. See
http://dev.w3.org/csswg/css3-animations/
for details.
Note that the code for starting and stopping animations with widget
visibility doesn't work yet.
This change is necessary because the old code did not accound for corner
cases (like translucent child windows), which could stop
gtk_widget_queue_resize() to not trigger redraws.
Make the main (and only) entry-point to gtkmodelmenu.c the now-public
gtk_menu_shell_bind_model().
Move the convenience constructors (gtk_menu_new_from_model() and
gtk_menu_bar_new_from_model()) to their proper files.
Remove the private header file.
Simplify the code a bit by making the initial populate part of the
bind() call.
https://bugzilla.gnome.org/show_bug.cgi?id=682831
Add an API to GtkAccelLabel for hardcoding the accel key to be displayed
(ie: allowing us to bypass the GtkAccelGroup lookup).
Use that from the GMenuModel-based GtkMenu construction code instead of
passing around the accel group.
This makes accel labels work in bloatpad again.
This patch effectively removes any hope of automatic runtime accel
changes in GMenuModel-based menus without additional application
support but it leaves the door open for this to be supported again in
the future (if we decide that it's important).
https://bugzilla.gnome.org/show_bug.cgi?id=683738
Add support for a stateful action associated with a submenu. The action
state is set to TRUE when the menu is shown and FALSE when it is
unshown.
This is useful to avoid unnecessary processing for menus that have
frequently-changing content.
A possible future feature is to add support for asynchronously filling
the initial state of the menu by waiting until the action actually emits
its state-change signal to TRUE before showing the menu.
A silly example has been added to Bloatpad to demonstrate the new
feature.
https://bugzilla.gnome.org/show_bug.cgi?id=682630
In gtk_menu_bar_draw, the check for shadow type != none
disables rendering of the background instead of the frame.
The check should be moved down to gtk_render_frame.
Patch by Peter de Ridder,
http://bugzilla.gnome.org/show_bug.cgi?id=670390
A button is highlighted if the private variable in_button is TRUE.
This variable is set when the pointer is over the button and cleared when
it left the button. When a button is hidden while there is the pointer over
it, GTK generates a leave notification event, in_button is set to FALSE.
But when a button is removed from a container but not destroyed, it is
unrealized and loose its window. It cannot receive the leave notification
event and in_button stay TRUE. So when the button get a new parent it is still
highlighted.
https://bugzilla.gnome.org/show_bug.cgi?id=676890
Scroll to the selection when setting it so the selected font is
visible on screen. This is especially useful if an initial font is
set for the user to see it.
https://bugzilla.gnome.org/show_bug.cgi?id=684156
Previously, we would avoid setting the prelight state flag when
button_down was TRUE and draw_indicator = FALSE, which is the normal
case of a GtkToggleButton during a mouse press.
It looks like this behavior was introduced a long time ago with commit
b94e6c0a80. I believe the reason was that
a widget in GTK2 couldn't have more than a single state (e.g.
hover+active) at a given moment.
https://bugzilla.gnome.org/show_bug.cgi?id=684038
Apply patch from Kristian Rietveld which addresses two issues
in gdkeventloop-quartz.c:
This patch moves the autorelease pool drain and introduces protection against
the invalidated ufds. Basically, when we suspect ufds has been invalidated by a
recursive main loop instance, we refrain from calling the collect function.
(cherry picked from commit 79b3326eaa)
After my recent fix for this, nautilus was still having problems
telling keeping F10 and Shift-F10 apart. With this change, we are
treating levels with the same symbol like inactive levels, ignoring
them entirely.
The widget-factory was pretty much overflowing, so I've
made it page, and started to fill the second page with
vertical spin buttons. New examples and widgets should
be added to page 2 now.
Be a bit more careful in get_pango_attr_list() and
get_utf8_preedit_string() to ensure that the client_window is properly
created before proceeding, to avoid access violation/segfault crashes on
Windows with IME installed, especially when running the pickers demo.
https://bugzilla.gnome.org/show_bug.cgi?id=682919
Don't hook on the widget style context and set up instead
a widget path for itself. Also use a common style class
for both handles, with an extra top/bottom class for each
handle.
This is to allow animating arrays properly. I'm not really thrilled
about this solution (we leak propertys into the values again...), but
it's the best I can come up with - I prefer it to having N different
array types...
I want to get away from the ability to have 0-length arrays, all css
arrays are single element.
Even if the element is "none", it is still a "none" element.
GtkTextHandle is used to indicate both the cursor position
and the selection bound, dragging the handles will modify
the selection and scroll if necessary.
Backwards text selection is also blocked for touch devices,
so the handles don't get inverted positions and possibly
obscure portions of the selected text.
GtkTextHandle is used to indicate both the cursor position
and the selection bound, dragging the handles will modify
the selection and scroll if necessary.
Backwards text selection is also blocked for touch devices,
so the handles don't get inverted positions (This is more
important though on GtkTextView, as inverted handles may
obscure portions of the selected text, good for consistence
though)
This is a helper object to allow text widgets to implement
text selection on touch devices. It allows for both cursor
placement and text selection, displaying draggable handles
on/around the cursor and selection bound positions.
Currently, this is private to GTK+, and only available to
GtkEntry and GtkTextView.
GtkTextHandle creates temporary override redirect windows, but still
hook to the text widget for events, so those are effectively captured
by GtkScrolledWindow if a text widget is within it
A change in xkeyboard-config 2.4.1 made it so that function keys
now have a shift level which has the same symbol, but 'eats' the
shift modifier. This would ordinarily make it impossible for us
to discriminate between these key combinations.
This commit tries harder to discriminate in 2 ways:
- XKB has a mechanism to tell us when a modifier should not be
consumed even though it was used in determining the level.
We now respect such 'preserved' modifiers. This does not fix
the Shift-F10 vs F10 problem yet, since xkeyboard-config does
not currently mark Shift as preserved for function keys.
- Don't consume modifiers that do not change the symbol. For
the function keys, the symbol on the shift level is the same
as the base level, so we don't consider Shift consumed.
For more background on the xkeyboard-config change, see
https://bugs.freedesktop.org/show_bug.cgi?id=45008https://bugzilla.gnome.org/show_bug.cgi?id=661973
Showing mnemonics immediately on modifier press can be annoying and
distracting when the user is just trying to Alt+Tab into another
application/window since the mnemonic will show up and quickly vanish
again when we receive the focus out event.
https://bugzilla.gnome.org/show_bug.cgi?id=672431
The file type radio group has a mnemonic on its label, but
activating it did not work, since GtkPrinterOptionWidget did
not know to forward the activation to one of the buttons.
* This patch gets rid of the separated
fields for selecting a print to file
target by removing the folder selection
button and the entry. It is replaced by
a browse button, which opens a file
selection dialog, that can select both
the path AND the filename.
* If the filename is relativ to the home
folder it will substitute ~/ instead of
the home folder. Additionally if the
resulting filename is longer than 30
characters, it cut of the first part
and replace it by '...' so that
the button text never gets too long.
https://bugzilla.gnome.org/show_bug.cgi?id=682129
The file chooser is asynchronous, so doing 'select_file (old_file)' and subsequently querying
the file for updating the labels is not going to work. However, the underlying file chooser
will emit 'selection-changed' as appropriate when it finishes restoring the old file. So,
we only need to update the labels when the file chooser dialog is confirmed, not cancelled.
This commit moves all the entry completion implementation
into gtkentrycompletion.c. It also gets rid of an unnecessary
completion_device member in GtkEntryPrivate.
When compiling gtk on Win32 then the file gtkdbusgenerated.c also needs to be
compiled and linked into the gtk library as it's needed for GtkMountOperation
https://bugzilla.gnome.org/show_bug.cgi?id=682825
- don't poke at the children's background pattern at draw time, but just
call gtk_render_background()
- we should propagate rendering of the background to the overshoot
window when the state flags or the style changes, or it won't respond
to e.g. focused/backdrop changes correctly
https://bugzilla.gnome.org/show_bug.cgi?id=682854
GTK_CSS_DEPENDS_ON_EVERYTHING was used as a placeholder when
implementing dependencies. Now that dependencies are completely
implemented, it's no longer necessary.
... in the case where no change of the DOM tree actually happened.
We don't do anything yet with that information, this patch just
correctly computes it.
When values are computed, they might depend on various other values and
we need to track this so we can update the values when those other
values change. This is the first step in making that happen.
This patch does not do any dependency tracking at all, instead it uses
GTK_CSS_DEPENDS_ON_EVERYTHING as a sort of FIXME.
Both _gtk_css_style_property_print_value() and
_gtk_css_style_property_compute_value() aren't necessary anymore and are
replaced by _gtk_css_value_print() and _gtk_css_value_comptue()
respectively.
This gets rid of the public function
_gtk_css_rgba_value_compute_from_symbolic().
The fallback is now handled using a switch statement instead of letting
the caller pass the function.
This is a reorganization of how value computing should be done.
Previously the GtkCssStyleProperty.compute vfunc was supposed to take
care of special cases when it needed those for computation. However,
this proved to be very complicated in cases where values were nested and
only the last value (of a common type) needed to be special cased.
A common example for this was the fallback handling for unresolvable
colors.
Now, we pass the property's ID along with all compute functions so we
can do the special casing where it's necessary.
Note that no actual changes happen in this commit. This will happen in
follow-ups.
This commit is essentially a large reorganization. Instead of all value
subtypes having their own compute function, there is the general
_gtk_css_value_compute() function that then calls a vfunc on the
subtype.
This hint may be used in text widgets to inhibit their
input methods. The most compelling usecase is calculator
applications, which already have a builtin and better
suited onscreen keyboard.
https://bugzilla.gnome.org/show_bug.cgi?id=651244
This improves the layout of the mount operations dialog to:
* Make primary labels bold in all cases
* Lay out the widgets in a grid
* Put space between the two radio groups to distinguish them
https://bugzilla.gnome.org/show_bug.cgi?id=682552
2012-08-24 18:10:39 -04:00
1213 changed files with 332277 additions and 124867 deletions
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.
