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.
