...instead of waiting 1 second before first showing it. It's a
placebo which doesn't affect the actual opening time, but
makes it seem more responsive to users by avoiding the
initial 1 second blocking delay before any feedback is
given.
Don't advise for rows added when a model reset is in progress.
Otherwise the rows are tested for sort order, etc triggering
a bunch of useless calculations, given that the model is in
the process of being reset anyway.
Tested using a 150k point shapefile, decreased attribute table
load times from 50+ seconds to 4 seconds.
Refs #16577, #16239
(forward port from b97a980b99a32f7cbbb8cc32ac6a781246df1171)
Instead delay the search until either a tiny timeout (100ms) or
the first new results come in, whichever happens first.
This avoids the list view clearing too frequently and giving
a distracting "flashing" appearance when users type quickly
into to locator bar.
This unifies the way the include directories are handled in the
CMakeLists.txt files.
Paths are now normally relative to the root of the source- or build dir.
They may still be relative for paths withing a plugin subdirectory but
should no longer be relative to paths outside of the current source- or
build-directory.
The previous approach had resultet in many different styles which are
hard to wrap ones head around if new to the build system.
It sometimes defined includes twice
By using relative paths, it was not possible to copy paste the paths
between different files.
The file qgsexpressions.h has grown to one monolithic piece over the
years. This makes it hard to maintain and slows down compilation because
even small changes at one end will result in recompiling big parts of
the source tree. It also requires the compiler to keep track of all
these implementation details for said big parts of the source tree.
This splits this implementation into smaller pieces. There are soe API
changes connected to this, but since these can be considered
implementation details, on which not many plugins rely, this shouldn't
have a big impact on the ecosystem outside the source tree.
Implementations of virtual methods will never be inlined, there's no
reason to keep them in headers. It just makes code less readable and
potentially slows down compilation.
