The window's role is 'GtkFileChooserDialog', so that window managers can match it
for positioning.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Instead of setting it on the child scrolled window. This is needed
because the whole window's allocation must be equal to the one of the
entry (in case the popup-set-width property is TRUE); if we set the size
request on a children of the window, there might be other children with
borders/paddings in between the toplevel and the child we set the size
request too, which will break alignment.
https://bugzilla.gnome.org/show_bug.cgi?id=672947
This call was forcing needless work since gtk_window_map() already
does a gdk_window_show() which initially sets GDK_WINDOW_STATE_FOCUSED
that we then handle regularly on the widget's window state event
handler.
https://bugzilla.gnome.org/show_bug.cgi?id=673237
Code was using different places to compute the icon size when layouting
and when doing size requests. This resulted in non-matching behavior in
obscure cases. And that lead to iconviews that were too small.
This ensures that items stay left-aligned instead of slowly expanding into
empty space when widening the iconview. It's also what the iconview did
pre-refactoring.
Note that for cases where natural width != minimum width, the cells
might still expand and shrink back.
Always assume max-columns and min-rows. The old approach was kinda
insane.
As an example, try to write an algorithm that optimizes the minimum size
for infinite (take a reasonably large number like 2520) word-wrapped
Monospace text cells containing the text "XXXXX XXX XXX XXXXX" (keep in
mind that this is the easy problem, because it's assuming equal cell
renderers). There's 4 ways to reasonably lay out this text:
19 glyphs (19x1):
XXXXX XXX XXX XXXXX
18 glyphs (9x2):
XXXXX XXX
XXX XXXXX
21 glyphs (7x3):
XXXXX
XXX XXX
XXXXX
20 glyphs (5x4):
XXXXX
XXX
XXX
XXXXX
The best thing to do usually is using the 9x2 approach, but that's
neither the one using the natural nor the one using the minimum size.
As a side note, this does not include spacing and padding, which might
also influence the decision. Nor does it include height-for-width
considerations. Look at this table (numbers given in glyphs, not pixels,
as for pixel-sizes it gets even more interesting):
given best solution
width columns sizing glyphs per cell
6 1 6x4 20
7 1 7x3 21
8 1 7x3 24
9 1 9x2 18
10 1/2 9x2/5x4 20
11 1/2 9x2/5x4 22
12 1/2 9x2/5x4 24
13 1/2 9x2/5x4 26
14 2 7x3 21
15 3 5x4 20
16 3 5x4 21.3
17 3 5x4 22.7
18 2 9x2 18
19 1/2 19x1/8x2 19
20 1/2/4 19x1/8x2/5x4 20
21 1-4 any 21
22 1-4 any 22
23 1-4 any 23
24 1-4 any 24
25 5 5x4 20
26 5 5x4 20.8
27 3 9x2 18
28 3 9x2 18.7
29 3 9x2 19.3
30 3/6 9x2/5x4 20
Now of course, nobody wants the number of columns to randomly change in
inexplicable ways while they enlarge or shrink an iconview, so we not
only have to optimize for smallest or other size measurements, but we
also have to optimize for "most pleasing to the eye".
And last but not least, I'd like to once again remind you - if you kept
up until now - that this discussion was for identically-sized cells
only.
Instead of just returning the last allocated numbers, we now compute the
proper sizes from scratch. This is a bit less trivial, but it results in
proper height-for-width handling.
This is a huge quest to remove all caching from GtkIconview to simplify
the code. As it turns out, iconview performance is a joke, so the caches
are kinda unnecessary.
If we need caching, we can add it in a useful way later.
If we use
&item->cell_area
instead of
(GdkRectangle *) item
there is no need anymore to keep the cell_area as the first member of
the the item. And we cget compile-time checks for changes to the item
struct.
Add a fallback-c89.c for the gdk/ subdirectory as there is code that uses
functions that are introduced by C99. This currently adds fallback
implementations for MSVC for isnan() and isinf()
Dist this "new" source file as well
nearbyint(), isinf() and isnan() are C99 functions, so check for them.
Also clean up configure.ac a little bit as the checks for rint() and
round() can be a bit simpler, according to Matthias' suggestions.
On Windows, gtkwin32themeprivate.h is needed as
_gtk_win32_theme_get_default() is called on that platform to avoid C4013
warnings/errors (aka implicit declaration of ... for GCC folks).
Symbolic icons use a "-symbolic" suffix to distinguish themselves from
highcolor variants. Note that the dash character here has a different
meaning than the specificity level defined in the icon-naming-spec [1],
as it identifies a property of the icon itself.
Since they might be provided by a parent theme (e.g. the HighContrast theme
relies on the gnome icon theme for them), when we are looking up one we
should first escape the generic icon inheritance mechanism defined in the
icon-naming-spec [1], and privilege a symbolic icon, if it exists in a
parent theme, before applying the inheritance evaluation.
This fixes symbolic icons not working properly when used in the
HighContrast theme with the GTK_ICON_LOOKUP_GENERIC_FALLBACK flag set.
[1]
http://standards.freedesktop.org/icon-naming-spec/latest/ar01s03.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=674806
This was broken since before GTK+ 3.0, when we replaced
a use of requisition by allocation. Fix this by using the
requisition height, that is already cached by the menu code.
The math is not quite right here; if you page all the way
down a long menu, you end up on the second-to-last menuitem.
But at least, page up/down let you move up and down the menu
again.
https://bugzilla.gnome.org/show_bug.cgi?id=668931
Due to the way the tests are structured, a missing libXext will give a
warning about a missing libX11 (even if libX11 is installed). This is
confusing to people who are trying to build Gtk.
https://bugzilla.gnome.org/show_bug.cgi?id=674200
This moves the freeing of the icon_helper from the destory to the finalize
function to avoid segfaults when trying to access a destroyed object before it
is disposed. This often happens in signal handlers which get called
asynchronously after destroy.
https://bugzilla.gnome.org/show_bug.cgi?id=674050
Deal with the possibility of a NULL application ID by updating our
copied logic from GLib: use a path of /org/gtk/Application/anonymous in
this case.
https://bugzilla.gnome.org/show_bug.cgi?id=671249
We currently have a couple of cases where GtkApplication assumes that
the session bus will be non-NULL causing critical error output or (in
the case of trying to publish menus) an infinite loop.
Three fixes:
- if the session bus is NULL due to not having registered the
GtkApplication yet then give a g_critical on the entry point to the
menu setters instead of going into an infinite loop. Document this.
- check for NULL session bus even when calling the menu setters at the
right time in order to prevent the infinite loop for
non-programer-error cases (ie: because we had trouble connecting to
the session bus)
- check for NULL session bus when publishing the X11 properties on the
GtkApplicationWindow and skip publishing them if we're not on the bus
https://bugzilla.gnome.org/show_bug.cgi?id=671249
