| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
g_log_default_handler() is documented to write INFO and DEBUG messages
to stdout. flatpak-spawn emits such messages if run with
G_MESSAGES_DEBUG=all, and its stdout is by necessity shared with its
child.
In this case, the child is dbus-monitor. Running Bustle with
G_MESSAGES_DEBUG=all in a Flatpak sandbox, then trying to record a log,
would cause the pcap-format message stream to be interleaved with output
like:
** (flatpak-spawn:116): DEBUG: 21:54:39.917: child_pid: 25091
and libpcap complains that 2a 2a 20 28 is not a known format header.
|
|
|
|
|
|
Previously, owned_names itself was copied, but the GHashTables which are
its values were not. This means that name ownership changes would affect
previous instances in the chain.
As explained in the TODO, we could do this more lazily for a
potentially-large memory saving. (In fact, I thought I had done so
already, but no.) Let's do it the memory-hungry and slow but safe way
for now.
|
|
|
|
The previous scheme worked fine for the unfiltered log but will not work
when filtering is introduced, because the row where the state is
BUSTLE_NAME_MODEL_LANE_STATE_NEW or BUSTLE_NAME_MODEL_LANE_STATE_CLOSING
may be filtered out.
|
|
This is largely an excuse to use GRefString
|
|
|
|
At some point in the past 10 years, it's grown a .pc file.
|
|
Obviously I did not write this all in one go, but I didn't preserve my
incremental work. bustle-window.ui is almost unmodified from
data/bustle.ui, and the build system builds the existing C code, but
otherwise it's all new.
The key part is that the log is represented as a GtkTreeModel
(specifically a GtkListStore) with references between method calls and
the corresponding reply¹ are represented with a GtkTreeRowReference. The
chart is drawn using a GtkTreeView and a custom renderer that renders
one horizontal stripe of the chart at a time. The approach (and the
colour scheme for the lanes) is inspired by gitg. The current
name-ownership state is tracked explicitly for each row of the diagram
(using an externally-immutable data structure, naturally).
By using the GtkTreeView machinery, we get many things essentially for
free that I've failed to implement in the old codebase for over a
decade, including type-ahead search (30 minutes) and selection tracking
(surely less buggy than my implementation).
There are many missing features:
- None of the UI is wired up outside the diagram itself and the details
pane. This is just a matter of typing.
- The rendering of each message is incomplete: undirected signals are
simply not drawn, for example.
- Support for showing system and session bus logs side-by-side. I think
this will be relatively straightforward: it's just™ a matter of a few
extra model columns and another TreeViewColumn.
I have not worked out how to fit some aspects of the old diagram into
the new world order:
- Arcs between method calls and the reply are really hard to do when you
fundamentally don't know where the other side will be. I was always
very unsatisfied with how this looked for very busy diagrams in the
old codebase so maybe I can find another way to display this
anyway.
- Headers for each "lane" in the diagram, showing which name(s) it owns.
Again, I was never satisfied with how it looked before (taking only
the last component of each name worked fine for Telepathy but is
useless in many other cases) so I think this will just stay
unimplemented. I'll either add a colour-coded legend, or something to
the details pane, or both.
¹ or replies: the edge case where more than one reply is seen for a
given message is handled
|
|
This is used by tools like GNOME Builder to show some project metadata.
|
|
|
|
|
|
It's traditional not to do this because of the likelihood that it will
drift out of date. This does make life a little harder for translators,
but we've never seen one in half a decade...
|
|
This is expected, not an error. We can also just track the next
available fake name, rather than scanning the map each time.
|
|
We don't need any of these maps to be lazy; they will all be
fully-evaluated.
|
|
|
|
|
|
A step towards updating the diagram immediately, too.
|
|
Previously, the filtering mechanism was “hide all messages which involve
one of these names”, although the dialog presented them in the opposite
sense. I often want to say something a bit different: “show only
messages which involve one of these names”.
Implement this with three states for each name: Default, Only, and
Never. The logic for each message is:
* If it involves at least one Never name, hide it
* If there are no Only names, show it
* Otherwise, show it if it involves at least one Only name
|
|
Unfortunately, setting border-width=0 on the GtkDialog's internal vbox
child is deleted by a round-trip though Glade, so one needs to be
careful with that!
|
|
This is the maximum size for scalable images according to
/usr/share/icons/hicolor/index.theme; at some point, Flatpak got more
militant about enforcing this.
|
|
When opening these icons, Inkscape reports:
$FILENAME was created in an older version of Inkscape (90 DPI) and
we need to make it compatible with newer versions (96 DPI).
with a link to https://inkscape.org/en/learn/faq#dpi_change for more
details.
These are intended for screen display, so I picked the option to not
rescale at all; in practice this did cause the XML to be rewritten in
mostly-harmless ways.
|
|
|
|
Placate hlint
See merge request bustle/bustle!13
|
|
This isn't the change hlint proposed, but it eliminates binding and
immediately deconstructing 's_'.
|
|
hlint complained about some of this, and while I was looking into it I
noticed an existing TODO. This way is neater.
|
|
|
|
I made the 0.7.4 release from a diverged local branch. :(
|
|
|
|
|
|
Previously, we sent SIGKILL directly to the child process. If we're
monitoring the system bus, the child process is owned by root, so the
parent process can't send it signals. In this case, we relied on the
child process dying with "Broken pipe" when it next tries to write to
stdout (which we close).
If you run `pkexec dbus-monitor --system` in a terminal, you are able to
press Ctrl-C to send SIGINT to that privileged child process. This is
because the signal is not sent directly. Instead, the terminal emulator
writes ^C to the child's controlling terminal; the kernel turns this
into SIGINT and send that to the child.
We can do the same thing here. Here are the steps:
* Create a pseudo-terminal (PTY) master/slave (not my terminology) pair
* Make this PTY the controlling terminal for the child process:
* Make the slave FD the stdin for the child
* In a GSubprocessLauncher child_setup function, which runs between
fork() and exec():
* Move the process to a new session with setsid(), removing any
existing controlling terminal
* Call ioctl(STDIN_FILENO, TIOCSCTTY, 0) to set the stdin FD as the
controlling terminal
* When it comes time to kill the child, write ^C into the master side of
the PTY
We continue to send SIGINT (rather than SIGKILL; it seems kinder) the
old-fashioned way (in case something goes wrong setting the controlling
terminal) and closing the pipe so that the child eventually dies with
EPIPE (in case the old-fashioned way fails too).
A potential fly in the works is that, in the Flatpak case, the immediate
child is a flatpak-spawn process; `pkexec dbus-monitor --system` is
actually launched from the session helper. Happily, the session helper
already calls setsid() + TIOCSCTTY if any of stdin/stdout/stderr on the
spawned process are TTYs
<https://github.com/flatpak/flatpak/blob/1.0.1/session-helper/flatpak-session-helper.c#L182-L202>
so we just skip the child_setup function in that case.
See https://blog.nelhage.com/2011/02/changing-ctty/ for some useful
background reading on controlling terminals.
|
|
|
|
|
|
That page just points to https://gitlab.freedesktop.org/bustle/bustle
now!
|
|
(Valid) error replies always have exactly one string argument; it's much
more legible if we show it without the @s annotation and
backslash-escapes inside the string.
|
|
For some reason I've never noticed this was missing before!
|
|
Add nix compatibility
See merge request bustle/bustle!12
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
