gimp_container_tree_view_clear_items(): GTK+ 3.x always keeps the row
with the cursor selected, so we get a gazillion selection changed
during gtk_tree_store_clear(), block our selection changed handler
during the clear.
Also, make sure we freeze() and thaw() the font container correctly,
so that all places keep their fonts across a refresh.
The only thing to make this actually work seems to be a bug in the
list views, grid views work perfectly.
Make sure gimp_async_set_wait() and gimp_async_set_cancel() work
correctly, even if the set changes in nontrivial ways as a result
of waiting-on/canceling individual operations. This is purely
theoretic right now, but why not.
Virtualize a lot of functions and move their code into the default
implementation. Also connect to changes of the "path" property and
reload data automatically when the path changes. Add "wait" method
which is by default empty but is to be implemented by fonts.
Increase the percision of the "position" property of
guides-new-percent.scm to two decimal places. Currently, it only
accepts integers, which limits its accuracy to 100px.
Add support for exponentiation (using the ^ operator) to eevl.
This is occasionally useful, e.g., in geometrically-derived
quantities involving square roots.
Let's go with a simpler manifest since soon it will be built on a better
machine (our CI server) and to make scripts simpler.
Note that I also removed the old webkitgtk dependency, but actually I
realize the GNOME runtime does not have the new dependency as well,
since the runtime actually has a webkit2gtk-4.0 instead. We'll have to
look into this.
With GTK+3, high or low density is taken care by the screen scale
factor. Having a separate preferences for this is redundant, and likely
even wrong.
It may be interesting though to have a new preference later, which would
allow smaller scale icon sizing since some people like their icon
slightly smaller or bigger, and also when you are using screens whose
density is at a limit scale factor. Right now, this can be done through
themes, but a GUI settings may be interesting. If I add such feature,
let's just do it from scratch later.
gtk_window_set_default_icon_name() apparently isn't able to properly
fallback to symbolic or non-symbolic variant. So let's test both.
There is also gtk_window_set_icon_list() but it takes a list of pixbuf,
so I really doubt it is the best solution either. The proposed solution
is working ok for now, even though I feel it is again a bit hackish.
Use a cairo surface with scale factor in the list cell, instead of
pixbuf property, so that the example icon keeps sharpness even on high
density (when possible, i.e with vector icons, or available high res
version).
Also if an example icon was not set, search for the symbolic variant
first, then fallback to non-symbolic.
Commit b2df13749c disabled building
devel-docs and pygimp in the makefiles, but their makefiles are
still generated by configure, which breaks distcheck, because the
necessary Makefile.in files are missing from the tarball.
Comment out the skipped files in configure.ac too.
When font loading is finished, restore the font list in the
corresponding async completion callback, and not in the
"notify::empty" signal handler of the fonts async set
This solves a problem arising when gimp_fonts_wait() is called
*inside* a "notify::empty" signal handler, emitted when reloading
fonts (causing the "empty" property of the fonts async set to
switch from TRUE to FALSE): When the wait is over, "empty" will
switch back from FALSE to TRUE, however, since the "notify" signal
is non-recursive, the corresponding handler will not be called,
gimp_fonts_wait() will return *before* the font list is restored,
and the caller will see an empty font list. This can happen under
certain circumstances when reloading fonts while the text tool is
active.
This commit makes 2 improvements to this renderer. First it will allow
it to find symbolic variants of icons. Second it properly renders icons
when the display is scaled, by producing pixbuf size double to logical
drawing size and making cairo rendering it at the expected logical size.
... Windows.
Reviewer note (Jehan): I have not built on Windows because I need to
refresh my crossbuild environment, but it looks sane enough, and Gil
previously did good patches. I push as-is, hoping it still builds fine
on Windows. :-)
