1. 31 Mar, 2019 1 commit
  2. 26 Mar, 2019 2 commits
    • Will Thompson's avatar
      pcap-monitor: clear G_MESSAGES_DEBUG from environment · f2f34a4e
      Will Thompson authored
      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.
      f2f34a4e
    • Will Thompson's avatar
      Show load errors in infobar · 8c19e97f
      Will Thompson authored
      8c19e97f
  3. 22 Mar, 2019 2 commits
    • Will Thompson's avatar
      Add new Flatpak manifest, build it in CI · 5e888709
      Will Thompson authored
      5e888709
    • Will Thompson's avatar
      Don't share owned_names values across copy() · f7db90ee
      Will Thompson authored
      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.
      f7db90ee
  4. 21 Mar, 2019 6 commits
    • Will Thompson's avatar
      Draw signals properly · 0b9532bd
      Will Thompson authored
      0b9532bd
    • Will Thompson's avatar
      Track adjacent NameModels explicitly · 31407d2a
      Will Thompson authored
      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.
      31407d2a
    • Will Thompson's avatar
      Intern search index terms · 23aee920
      Will Thompson authored
      This is largely an excuse to use GRefString
      23aee920
    • Will Thompson's avatar
      Rename main executable to 'bustle' · e78de937
      Will Thompson authored
      e78de937
    • Will Thompson's avatar
      Find libpcap using pkg-config · 4d1f3f24
      Will Thompson authored
      At some point in the past 10 years, it's grown a .pc file.
      4d1f3f24
    • Will Thompson's avatar
      Reimplement core functionality in C · ace79097
      Will Thompson authored
      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
      ace79097
  5. 13 Mar, 2019 1 commit
    • Will Thompson's avatar
      Add DOAP file · 4c371ddb
      Will Thompson authored
      This is used by tools like GNOME Builder to show some project metadata.
      4c371ddb
  6. 08 Mar, 2019 3 commits
  7. 07 Mar, 2019 9 commits
  8. 01 Mar, 2019 1 commit
  9. 07 Dec, 2018 13 commits
  10. 29 Nov, 2018 2 commits