Dispaly the new row entry !!!

July 29, 2018

Dispaly the new row entry !!!

During GUADEC, my mentors told me that I needed to complete the project before ui freeze. It took only two weeks to calculate the time. So I dare not stay too much. I immediately set off to return to China and continue my project.

After I returned to China, I started my daily work. We discussed during GUADEC. Starting from 7.13, there will be a shorter meeting at 9:00 pm Beijing time. I need to report to them about my work for the day and the plan for tomorrow.

I am very grateful to my two mentors, taking some time each day to review the code for me and solve some of my problems.

Ok, let’s talk about the progress of these two weeks.

The biggest improvement achieved was the successful display of the obtained log messages to the interface.
Specifically how to achieve it, this part of the function is mainly implemented in gl-journal-model.c.
I think it can be divided into the following sections to explain:

1. Receive data

This previous blog has been mentioned roughly in the past, so let me introduce it in detail here.

G_signal_connect (model->journal, "entry-added",
                      G_CALLBACK (on_new_entry_added), model);

Receive the entry-added signal in gl-journal-model.c, then call

/* Add the new log entries into the model */
Static void
On_new_entry_added (GlJournal *journal,
                    GlJournalEntry *new_entry,
                    Gpointer user_data)

The callback function performs the processing of the next part.

2. Show entry

I think this part is a more complicated part of the entire feature implementation process.
The first received log entry is organized into a row_entry, and the row_entry structure is

Struct _GlRowEntry
{
    GObject parent_instance;

    GlJournalEntry *journal_entry;
    GlRowEntryType row_type;

    /* Number of compressed entries represented by
     * a header
     */
    Guint compressed_entries;
};

row_type is a special variable.

Typedef enum
{
    GL_ROW_ENTRY_TYPE_UNCOMPRESSED,
    GL_ROW_ENTRY_TYPE_COMPRESSED,
    GL_ROW_ENTRY_TYPE_HEADER
} GlRowEntryType;

So I have to focus on the type of row_type in the process of adding.
Adding a new new_row_entry will face three situations (according to the existing add policy)

• An entry that is not similar to previous_row_entry.

  Add it directly

• Similar to revious_row_entry, but prev is a header

  Change the type of previous_row_entry to
  GL_ROW_ENTRY_TYPE_COMPRESSED and update its journal_entry to new_journal_entry. Update the new one to header.

• Similar to revious_row_entry, but prev is a COMPRESSED

  Extract the previous one and this one to create a new header. When the next similar message arrives, the program will process it according to the second case.
  (This is handled differently than gl_journal_model_fetch_idle. It wasn’t until a different message was added that the header was set. This different processing is consistent with the display logic)

3. Storage of entries

Since the model and the view list are bound together in this program, when the logs are started, the loading message is added from the end of the journal, so it is reversed in the entries, so when adding, I take The strategy is to have the new entry inserted in position 0. This guarantees the order of the data.

BTW, because the logic of the item processing is roughly similar to the gl_journal_model_fetch_idle of the master branch, so the code structure is re-combed, and the common part is extracted and written into a new function.

Static void
Gl_journal_model_handle_add_entry (GlJournalModel *model,
                                   GlRowEntry *row_entry,
                                   Gboolean adding_new)

With adding_new for various control of the case, the code is a lot simpler, g_list_model_items_changed(), and g_ptr_array_insert(), where the parameters take a more concise ternary expression to simplify the code.
i.e.
g_list_model_items_changed (G_LIST_MODEL (model), adding_new ? last - 1 : 0, 1, 1);

As for

 static void
Gl_journal_model_add_header (GlJournalModel *model, gboolean adding_new)

Modifications have been made to add variable control to the process of adding headers to achieve reuse of existing code.

A small issue.

Due to a lot of modifications to the gl_journal_model_fetch_idle() function, the Logs entry has more than 50 row_entry loaded by default. This is because I did not consider this situation in the new code China, which caused the problem, thank you. My mentor, jkang, discovered this problem in time, allowing me to solve this hidden little problem.

This gif is my work on logs.

Feel so happy!