An inert gridview is a gridview that does not use the factory. This
allows faster updates because no calls into user code need to happen.
A gridview is inert when either:
- It is not rooted.
- It is not visible.
- No factory is set (that one is obvious)
The gridview does not need to be inert without a model, as that case is
handled by the item manager.
This should allow Nautilus to keep both the gridview and the columnview
around, and just gtk_widget_hide() the unused widget.
The code for now does not disable the item manager, as some
functionality of the item manager is required to allow setting scroll
positions and such.
But that is a place where more gains could be found if profiling showed
that was useful to do.
An inert listview is a listview that does not use the factory. This
allows faster updates because no calls into user code need to happen.
A listview is inert when either:
- It is not rooted.
- It is not visible.
- No factory is set (that one is obvious)
The listview does not need to be inert without a model, as that case is
handled by the item manager.
This should allow Nautilus to keep both the gridview and the columnview
around, and just gtk_widget_hide() the unused widget.
The code for now does not disable the item manager, as some
functionality of the item manager is required to allow setting scroll
positions and such.
But that is a place where more gains could be found if profiling showed
that was useful to do.
The widget would teardown the factory on unroot to avoid unnecessary
work when it isn't shown.
However, recycling may reposition widgets, and repositioning widgets
does a unroot/root.
We don't want to recycle widgets then.
The implementation lives (as always) in GtkListBase.
This is a feature request from the Nautilus developers, who currently do
some hacks to emulate that behavior and it apparently only breaks
sometimes.
We connect gtk_scrolled_window_update_use_indicators
as signal handler in realize(), but we were disconnecting
gtk_scrolled_window_sync_use_indicators in unrealize.
Spotted by Milan Crha.
Fixes: #5684
The cursor-theme-size setting is documented as
'0 means the default size'. Make it so by using
size 24 if we see a 0. Its better than crashing.
Fixes: #5700
The function is going away, and the computation
here was wrong anyway. Instead, add a helper that
properly computes the pointing-to rect in surface
coordinates and use it everywhere.
The widget paintable uses the widgets bounds
as intrinsic size, so we need to offset from
that to the allocation, which is what the
coordinates are relative to.
Text handles had the same problem as popovers.
They were interpreting their pointing-to rectangle
relative to the widgets bounds, when it is meant
to be relative to the widgtets allocation.
While we touch this code, rewrite it to use
gtk_widget_compute_point.
When we don't have a pointing-to rectangle, we want to place
the popover wrt to the parents bounds. But if we have a
pointing-to rectangle, it is relative to the widgets allocation,
which is different from the bounds.
We were not handling the second case correctly, leading to context
menus in the text view being mispositioned by the widgets CSS padding.
While we are touching this code, rewrite it to handle transforms.
Fixes: #5695
Since we are making GdkGLContext call the core wgl*() functions directly
instead of via libepoxy, drop the workarounds that we needed for notifying
libepoxy that wglMakeCurrent() outside of GDK/GTK was called.
This way, we clean up the code, and as a result, we can use the GstGL
APIs like the other platforms to query what GL api that is to be used.
For ensuring that things work between different threads, we now call
gdk_gl_context_clear_current() in place of calling wglMakeCurrent(xxx,
NULL), so that we make sure that there is no current GL context on a
thread outside of GstGL's thread, which Windows does not like.
