We can just include the files directly, and avoid the static
linking and potential problems that come with that when porting
the build system to other platforms.
This also moves stackstash.[ch] into a location that can be
embedded by both the libsysprof and libsysprof-ui code. We
pass native pointers to the structure as a gpointer in the
public API to allow for this. The performance of that code is
incredibly sensitive to the interactivity of Sysprof.
This moves everything into other places and simple includes the
files in the cases that it is necessary. In the future, we can
rewrite sysprofd to use GDBus and add GetProcFile() to allow
for client-side processing of kallsyms.
This doesn't make profiling useful in any way, but it does get things
to the point where I can actually open a capture file. And it would
be nice if we could progress to the point of loading capture files
(with correct data in-tact) and this helps us move down that path.
To really do that correctly, we should make some of the widgetry
disabled when it isn't useful. We also need to ensure that we add extra
decoding information to capture files during shutdown so that any
platform can read it back. This would also help the situation of
running and reading on separate architectures.
Of course, this all needs improvements to be realistically useful, but
it allows us to get things at least opening. We can adjust how we
store that data to make it available on other OS's later.
The big thing going on here is that we are going to split up the libraries
a bit better, and remove GObject from the capture library. The libsysprof
library will bring in the capture library statically, so we can export the
symbols we want.
Eventually, we will bump the version to sysprof-3, but not yet.
Historically, Sysprof never supported translations. When revamping the
Sysprof implementation we didn't fix that, even though we were able to
start accepting translations.
This ensures we setup the translation tooling at startup.
Fixes#3
clang errors out when using -Werror=format-nonliteral
since the definition of g_strdup_vprintf() from glib-2.0
is using va_list and clangs still warns where as
gcc doesn't do that for va_list arguments
Fixes
src/sp-window.c:96:27: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
| str = g_strdup_vprintf (format, args);
| ^~~~~~
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
I think this was masked by the .destructive-action class being defined
later in the Adwaita CSS than the .suggested-action class, so its values
for each property win.
The goal here is to avoid having to hard code what visualizers are shown
from the .ui files. We just should add things that we find are supported.
Long term, I think we'll add a concept of an "instrument" which is the
combination of a data source (SpSource) and a visualizer (SpVisualizerRow).
The other goal here is to enable the future support for discovering marks
and adding rows for each of those threads.
The lib/ directory was getting a bit out of hand, so this tries
to organize things a bit so it is easier going forward to locate
the code people want to patch.
Now that we are post-3.26, we are removing the legacy autotools
build system in favor of meson.
Please report any errors you have so that we can ensure this is
ready for GNOME 3.28.
We want this in sysprof.h (without UI components) so that we
can use it to filter things in profilers. Therefore, we don't
need to make it namespaced to "visualizers" since a time range
selection is a fairly straightforward, and non-UI confined
implementation.
We want to set some custom backgrounds for the visualizers, and
those need to track with the current theme. SpThemeManager will
watch the systems theme changes (including dark theme) and
update the loaded CSS resources as necessary.
This allows us to have the SpVisualizerView grow and shrink
along with the visualizer content up until the user has manually
moved the paned handle. At which point it clamps to that
position as allowed by the size request phases.
