Prevent the new window dragging code from interfering with
selection of colors on button release, by handling button
presses we care about instead of letting them bubble up to
the window.
Partial fix for
https://bugzilla.gnome.org/show_bug.cgi?id=695493
We were not translating event coordinates to the toplevel
window, thus the regions we determined were not right.
We were also not respecting the maximized state, and we
were unnecessarily refusing to handle events when not decorated.
https://bugzilla.gnome.org/show_bug.cgi?id=696197
If the style changes before we're realized we will delay the
style-updated signal until realize. However, we then lose
the changes bitmap. This means that gtk_widget_real_style_updated()
must treat a NULL change as "everything changed" and queue a resize.
The code was always adding a label widget as a child, but
then skipping over it in forall if a custom_title was present.
This confuses internal logic of GTK+ which assumes that it
can iterate over the entire widget hierarchy with forall,
to maintain state. Fix this by destroying the label when
a custom_title is set, and recreating it as needed.
The function update_window_buttons shows or hides the title header after it
has finished updating the visibility of the various buttons. Unfortunately
this
conflicted with the hiding of the title done when going fullscreen.
This solves the problem and fixes the rendering of fullscreen applications by
using update_window_buttons to control the visibility of the box in the
fullscreen case.
This reverts commit 30a1a79322.
This turns out to be unnecessary when you can set the titlebar
on the window and let GtkWindow handle the events. As a benefit,
we get the window menu on custom titlebars for free.
A new function that sets a custom titlebar on a GtkWindow.
With client-side decorations, the custom titlebar simply
replaces the one that GtkWindow would otherwise create itself.
With traditional decorations, we tell the window manager
to just decorate the window with a border. This works ok
at least with metacity and mutter.
For csd, we were subtracting the border width one too many
times from the child height, causing clipped off content e.g.
in the 'Properties' window in testgtk.
To clear the tooltip one is to set the tooltip to NULL. Though
the GtkEntryAccessible expect this tooltip to not be NULL in
gtk_entry_accessible_notify_gtk (already handling this case
in its _init).
Fixes:
** (epiphany:23914): CRITICAL **: atk_object_set_description: assertion
`description != NULL' failed
when epiphany g_object_set the entry icon tooltip to NULL (clear the
tooltip) in its find bar.
https://bugzilla.gnome.org/show_bug.cgi?id=695375
To extract the mnemonic key value, the string must contain the
underscore. But when the "gtk-auto-mnemonics" setting is true and when
the Alt key is not pressed, the underscore must not be displayed. The
problem was that the 'new_str' variable was used for both purposes:
extract the text to display, and extract the accelerator character.
When the underscore must not be visible, the underscores were removed
from the 'new_str' variable before extracting the accelerator character.
Now there are two strings, one for each purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=674759
For now, nothing changes, we're using the sum of inner and
outer border everywhere.
In the future, we will make the inner border the visible
window frame, and the outer border the shadow/resize border.
Add a style property to control the presence and order of
window buttons. We allow buttons at the left and right side,
they can be specified like this: icon,close:minimize,maximize.
Also, change the default button layout back to have just a close
button on the right, use icons in buttons, and set style classes
on the buttons, to allow better theming.
Add window-minimize, window-maximize, window-restore and window-delete
icons to the builtin icon theme. These will be used for icons in
the window buttons, and the expectation is that the icon theme
will provide icons matching the desired decoration style.
window-delete is used instead of window-close, since window-close
is also used for GTK_STOCK_CLOSE, and the two may require different
styles when used inside the application vs in the window frame.
Hide the close button if the window is not deletable, hide the
maximize button if the window is not resizable, and hide all
buttons if the window is a dialog.
Update buttons when the window state changes.
Client side decorations can be enabled on non-Wayland platforms by
setting the GTK_CSD="1" environment variable.
We must ensure we have a GdkVisual that has an alpha channel since
the decorations rely on transparency. If we cannot get a visual with
an alpha channel then we do not enable client side decorations.
Otherwise we'll potentially get some background sticking through our rounded
corners in our decorations. The actual background will get drawn as part of
the decoration drawing.
This change comprises four main parts:
* the creation of the widgets that form the decorations,
* implementation of get_preferred_height/width, and the for_width/for_height
variants,
* taking the decorations into account when allocating,
* and drawing the decorations themselves.
Kristian did the bulk of the original work on this but any bugs are almost
certainly mine through the many refactorings and rebasings.
Update the documentation and users of this function to handle
the future case that that we have some internal decorations to the window and
useable allocation is thus smaller.
By having a separate out parameter there is no need to have an in/out function
and allows for greater robustness.
The current implementation simply returns the allocation provided.
For gtk_text_iter_get_char(), due to the "Returns" at the beginning of
the description, the description was not visible. So the first sentence
has been reworded.
If there are rows that contain only spanning children,
our algorithm was unnecessarily distributing extra space
to the other rows, even if they contain only non-expanding
children.
We improve the behaviour by treating rows containing only
spanning children as expanding.
... instead of taking the last one we find. This is necessary as
attached widgets (mostly menus) can be attached to an invisible widget,
but we still want to invalidate styles for them.
https://bugzilla.gnome.org/show_bug.cgi?id=695772
When setting new text on the label, the text-changed::delete signal
needs to be emitted before deleting the text (so that atk-bridge can
query the old text) while the text-changed::insert event needs to happen
afterwards (for the same reason). The old code using the notify signal
was only emitted after changing the text.
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>
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
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.
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>
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.
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>
