In this blog post, I am going to elaborate upon the event compression feature in GNOME Logs as implemented by me during last three weeks. It’s been exciting three weeks for me to hack on Logs code base and bring this crucial usability feature to life. First, let me speak in pictures about how this implemented feature looks like.
A GNOME Logs window showing compressed events looks like below:
The rows which indicate numbers along side the event messages represent a group of compressed events which have been hidden in the events list. I would like to call such rows “header rows”.
Clicking on a header row, toggles the visibility of the compressed event rows represented by it in the events list:
Here, a header row representing seven compressed events is expanded. The header row stores the details of one of these compressed events to be shown in the events list while it hides them. This compressed event, whose details are to be shown in in the header row, is selected such that it maintains the timestamp sorting order specified by “sort-order” GSettings key.
To keep things simple initially, only adjacent events w.r.t timestamp are checked for the compression/similarity criteria. The compression/similarity criteria for grouping these adjacent events under a header row is as follows:
- Events containing messages whose first word is same (includes exact duplicates)
- Events which have been generated by the same process.
This can be extended in future to compress non-adjacent events in specific batch sizes and accordingly group them under a common header row.
When we click on any row (including the expanded compressed events) except the header row, the detailed information regarding the event is shown in a fixed size popover:
Longer detail fields like “Message” are wrapped over multiple lines so that they do not exceed the width of the popover. All the detail fields which were available in the previous detailed event view are available in the new popover as well.
Well , what about event rows containing super long messages like coredumps or stacktraces ? Such event details are handled gracefully in the popover using a GtkScrolledWindow.
I will now try to explain in simple words about what exactly is going on behind the scenes. While fetching the events from the journal using sd-journal API in the model array (backend), we count the number of adjacent events satisfying the earlier mentioned compression/similarity criteria. If the detected number of compressed entries in a group is 2 or exceeds 2, then a dummy event representing these compressed entries is added to the model array. This dummy event is nothing but our “header row”. This information is then parsed in the frontend and accordingly the events marked as compressed in the model array are hidden in the events list. You can follow progress on merging of this enhancement here.
Moreover, I have now started working on my next task which is writing a shell search provider for GNOME Logs. During previous year, I came out with patches containing a very basic implementation of shell search provider. I will now be improving on those patches according to review given by David. Currently, I am researching on various possible approaches to fetch the events from the model in the shell search provider. Further progress regarding this can be tracked here.
I am very happy to tell you that I will be attending GUADEC 2017 in Manchester. Many thanks to the GNOME Foundation for sponsoring travel as well as accommodation for me. I look forward to meeting all of you at GUADEC 2017 🙂