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>
