GSoC 2017 : GNOME Logs

Hello GNOME’ers,

Hope all of you are doing well 🙂

In this blog post, I want to introduce you to my GSoC project on GNOME Logs for this year. Last year, GNOME Logs saw the addition of a search popover and many improvements to it’s backend in terms of searching functionality. Moreover, some initial work regarding a Shell search provider for GNOME Logs was also done. I would also like to tell you that I was the GSoC 2016 intern on GNOME Logs and I must say, it was one of my summers spent well ! I got acquainted with the vibrant and diverse GNOME community and and on the other hand improved my skills in open source software development too , due to the valuable guidance given by my mentor, David King. This year, I will be mentored by David King and Jonathan Kang, two awesome people who are also the maintainers of GNOME Logs.

Regarding this year improvements to GNOME Logs, I will be working on the following tasks:

  1. Move sorting by timestamp functionality from the frontend to backend.
  2. Compress similar logs shown in the event list.
  3. Write a shell search provider for GNOME Logs so that search results can be exposed to GNOME Shell.
  4. Write unit tests for testing the user interface and search functionalities.

Here, I will be briefly explaining you about the first two tasks and the progress done on them. The first task is mostly about transferring the computational overhead to the model which is the actual backend in GNOME Logs. Currently, the list of events shown in the user interface are sorted w.r.t timestamp by GtkListBox using GtkListBoxSortFunc. The main motive of moving the sorting functionality to model is to reduce the complexity from the Logs frontend and make it simple. A challenging task here was to get the GListModel interface (which is implemented by GNOME Logs model class) to return the entries filled in the model array in a reverse order. It took me almost six months to figure out a correct approach for doing so. It would not have been possible without the guidance from my mentors and Lars Karlitski. Progress regarding the enhancement can be tracked on this bugzilla bug.

The second task is related to improvements in user interface and crucial for GNOME Logs from usability point of view. Currently, many adjacent events shown in the events list are either exact copy of each other or they are from the same process which logs some unnecessary events. This clutters the event list which makes it hard for a user to see the events which are of prime importance to him. So, the aim of this task is to compress these similar adjacent events. Allan Day of GNOME Design team has developed an excellent mockup to present the compressed events in an intuitive way. I would like to post his mockup here:logs-message-compression

To keep things simple initially, adjacent events will be compressed if the first word in their respective messages is same which takes care of exact adjacent duplicates too. This similarity criteria will of course be extended in the future to include other types of similar messages.

As of now, I have implemented some part of the mockup except the popover. A video of the working prototype can be seen here. I will be ready with the patches in the coming weeks and further progress regarding the event compression enhancement can be tracked on this bugzilla bug.

That’s all for now. Let me know in the comments what you think of this year’s GSoC improvements to GNOME Logs. We will meet again soon.

Regards.

GNOME Logs Search Provider

Hello everyone,

In this post I will be telling you about the search provider for the GNOME Logs as implemented by me in the last two weeks.

When we type a search term in the GNOME Shell overview search bar, the top 3 journal entries relevant to the search term are shown as results:

overview-search-bar

As you can see in the picture above, we show the journal entry message and also the process name which sent the message to the journal in the description of each of the result.

When we click on a search result, the details of the result are shown in a newly opened window:

search-result-detailed-window

If we click on the application icon on left side of the results in the overview, a new window is opened which shows all of the results related to the entered search term in the overview:

application-icon-click

You can see a working video of the search provider here.

So, as you can see above, GNOME Logs is the new GNOME Application joining the league of other GNOME Apps search providers for GNOME Shell. 🙂

By default the search term is searched in all the available journal parameters in GNOME Logs. This was all about the GNOME Logs search provider in it’s current state of implementation. You can track the further progress on search provider in my github branch.

Along with the search provider, I also worked to get the patches related to the search popover merged in the GNOME Logs repository. Progress on this can be tracked on this bugzilla bug.

Apart from this, a sad announcement. I will not be able to attend GUADEC this year due to my university project evaluations clashing with the schedule of GUADEC. I will be missing GUADEC and the amazing GNOME Community very much 😦

Feel free to comment about what you think of the GNOME Logs search provider.

Stay tuned for my upcoming final GSoC project report.

See ya !

GNOME Logs GSoC Progress Report

Hello everyone,

I will be mentioning all the progress done in the GNOME Logs GSoC project in the previous weeks. The search popover is completed, but the patches related to it are yet to be merged, which I hope, will get merged in the coming week. In this post, I will be telling you about features implemented by me in search popover. If you want a brief recap about the search popover, please see my earlier blog post about it.

The implemented search popover looks like this when the drop down button besides the search bar is clicked :

popover-main

Clicking on the button related to what label, it opens up this treeview which allows us to select the journal parameters to search the user entered text from:

popover-select-parameter       popover-select-parameter-2

If we select any particular field from the treeview, it shows an option to select the search type:

popover-search-type

The search type option is hidden when “All Available Fields” is selected as exact search type doesn’t make sense in that case. So, only substring search type is available by default in that case.

Clicking on the button related to when label shows this treeview from where we select the journal range filters:

popover-rage-filters

If we select the “Set Custom Range” option, we go to another submenu:

custom-range-submenu

It allows us to set a custom range for the journal, including the starting date time and ending date time. Clicking on the either of the select date button shows this calendar from which we can select the date:

custom-range-calendar

Clicking on either of the select time button shows these time selection spinboxes:

custom-range-time
12-hour format
custom-range-time-24
24-hour format

The time spinboxes change depending upon the time format used in the current timezone.

This was all about the search popover as it is currently implemented by me. From next week, I will be working on writing a search provider for GNOME Logs which can be used to query journal entries according to the user entered text in the GNOME Shell search bar. Also, I will be working on getting the patches for search popover merge into the master branch of GNOME Logs. After all the patches related to search popover get merged, I will be making a video on how the search popover works. I would like to thank my mentor David King for guiding me in the right direction and helping me get my patches reviewed and merged.

My next post will be about the search provider for GNOME Logs coming next week.

So, stay tuned and Happy Coding 🙂

GNOME Logs search popover

Hello Everyone,

It’s been almost two weeks since my last post. In this post, I will be mentioning all the progress done in these two weeks. First of all, the searching part is now moved from the front end part to the actual back end of GNOME Logs which is the sd-journal API. So, now when the user types text into the search bar, the results are actually fetched from the journal itself. Progress on the project can be checked out on my Github repository. I would like to thank my mentor David King a.k.a amigadave for reviewing my commits and guiding me in the right direction.

GNOME Logs got a new search popover. I have implemented the GUI bits of the search popover for GNOME Logs.We decided to use a complete popover design as it feels modern and didn’t want the user to open any dialog. So, all the actions that the user can do will be contained within the popover itself. The popover design is inspired by the Nautilus search popover with much of design and code reused from it. It is coded by Georges Stavracas a.k.a feaneron and designed by Allan Day a.k.a aday. I would like to thank both of them because due to their work, I was able to implement the search popover much faster and also I learnt a lot about dealing with popovers by reading Nautilus search popover code.

I will give here a short image walk through on the search popover:

This is how the entire popover looks when clicked on the drop down button besides the search bar:

broad-pic

Clicking on the button related to “What” label  opens up a listbox from which we can select the search parameter for querying the entries from journal:

select-parameter-listbox

Clicking on the button related to “When” label opens up a listbox from which we can select the range of journal entries which will be displayed:

select-range-listbox

Furthermore, if we click on “Set Custom Range” , we go to another submenu in which we can select the date range of the journal between which the entries will be displayed. This is similar to the –since and –until options of journalctl command line tool. Currently, here we don’t allow entering the time as GTK+ does not have a specialized time widget but it can be done in future once GTK+ gets a time widget.

custom-range-submenu

If we click any of the buttons, a text entry and a calendar is displayed from which the user can select the date or type the date into the text entry.

custom-range-calendar

Clicking on “Back” button goes back to main menu.

search-type

The last option “Search Type” consists of two radio buttons which specify whether the user wants a substring match or an exact match for his query.

You can watch the video of search popover in action here.

In the coming weeks, I will be implementing all the back end functionality of the search popover (so that selecting the options in it actually affect the displayed results).

Let me know in the comments about what you think of the search popover design and if some options are missing from the current design or it needs some different options.

In the next post, most probably, I will be posting a link to a video where I will demonstrate a fully implemented search popover.

Till then,

Happy Coding 🙂

GSoC 2016 Introduction

Hi everyone,

My name is Pranav Ganorkar and I am a third year student at V.E.S. Institute of Technology, Mumbai pursuing Bachelor’s degree in Computer Engineering.

My very first introduction to Linux was in eighth grade when I booted the Live CD (Yes, CD’s used to be much popular at that time due to low penetration of Internet) of Fedora 13 on my Desktop. I was very much impressed by it’s user interface and started hacking on it. It was my first introduction to GNOME Desktop. At that time , in high school, I was mostly interested in installing various distros and trying out new desktop environments. What a wonderful life back then , wasn’t it ? 🙂

I started following GNOME Development when I was in my first year of Engineering. It was when I learnt about the GTK+ Toolkit and tried to make some simple applications using it.  It’s been almost three years now since I have been using GNOME as my primary desktop environment on Arch Linux. I started following GNOME Logs development from January 2016, got acquainted with it’s source code, started hacking on it and was able to make my first contribution in March 2016 with a lot of help from David, my mentor.

Now, some details regarding my GSoC project. I will be working on improving the search feature in GNOME Logs under the mentorship of David King. Currently, searching in GNOME Logs is only restricted to the front end part. Meaning, the actual search results are not fetched from sd-journal API (the API which GNOME Logs uses to fetch the entries from the journal) but using the filter function for GtkListBox in the already fetched results. So, my first task is to move the searching to the back-end part. That is, when the user types text in the search bar, the results will actually be fetched from the sd-journal API.

I will also be improving the GUI for the search interface. Currently, GNOME Logs does not have any option to graphically restrict the journal fields by which user entered text will be filtered. So, I will be adding a drop down menu besides the search bar to let the user select the various journal fields by which to restrict the search results from. Currently I have done a GUI mockup for it which looks like this:

gnome-logs-gsoc

Also, the advanced options menu button will provide the user with a dialog box which will provide with advanced journalctl filtering options like “since” and “until”. Also, user can specify the type of search : exact or substring which he wants to perform. Currently, the GUI mockup for advanced search dialog box looks like this:

advanced-search-dialog-box

Along with the above tasks, I will also be writing a search provider for GNOME Logs. So, GNOME Shell will be getting a new search provider. Yay 🙂

Finally, testing will be done to test all the above implemented functionalities. I hope that after the completion of my project, GNOME Logs will be able to match up with journalctl tool in terms of searching and filtering functionality.This is a short summary of my GSoC project.

Looking forward to an exciting summer and learning a lot in process about GNOME Development and it’s vibrant community 🙂

Also, feel free to comment about what you think of the current GUI mockups.

See you in next post. Until then,

Happy Coding !

Constant Pointers in C

Recently, I was working on a bug of Gnome-Logs. It involved some operations on pointers. More specifically, the pointer variables were used to determine the index of the newline character (\n) in a string and determine the substring between two newline characters (\n). I successfully submitted my patch solving the bug. But the reviewer mentioned that the following char pointers should be kept const.

gchar   *newline_index;
gchar   *prevpos;

I asked him why should they be const because we are modifying them on the following lines in the loop:

prevpos = newline_index + 1;
newline_index = strchr (prevpos, ‘\n’);

The reviewer then explained to me that the const modifier acts differently on pointers. Specifically, const modifier on a pointer allows us to change the memory location it is pointing to but does not allow us to change the value at that memory location. So, The above modifying code is perfectly valid even in the case of const pointer. I thank to the reviewer, David King, for clearing this misconception for me.

Here,  In this post I will explain about the different types of const pointers used in C:

There are basically three types of const pointers:

  1. Constant Pointers
  2. Pointer to Constant
  3. Constant Pointer to a Constant

Let us understand each of these one by one. We will first start with the Constant Pointers.


 

Constant Pointer

A constant pointer is a pointer that cannot change the address it is holding. We can also say that once a constant pointer starts pointing to a variable then it cannot point to any other variable. The syntax for const pointer is as follows:

<type of pointer>  * const <name of pointer>

An example declaration is:

char * const ptr;

Let us take a small program to illustrate these type of pointers:

#include<stdio.h>

int main(void)
{
int var1 = 0, var2 = 0;
int *const ptr = &var1;
ptr = &var2;
printf("%d\n", *ptr);

return 0;
}

Here , we have two int variables var1 and var2 and and a constant pointer ptr.
we first initialize the constant pointer ptr variable to point to var1 and then to var2.

So, we assigned an address to a constant pointer and then we tried to change the address by assigning the address of some other variable to the same constant pointer.

If we compile the above program, we will get the following error:

$ gcc -Wall constptr.c -o constptr
constptr.c: In function ‘main’:
constptr.c:7: error: assignment of read-only variable ‘ptr’

We see that while compiling the compiler complains about ptr being a
read only variable. This means we cannot change the value ptr holds. Hence, a constant variable which points to some variable cannot be made to point to another variable.

Now, we discuss about the next type of const pointers: Pointer to Constant.


Pointer to Constant

A pointer through which one cannot change the value of variable it points to is known as a pointer to a constant. These type of pointers can change the address they point to but cannot change the value kept at those address. It was this type of constant pointer that I had misconception about while working on my patch.

The syntax for a pointer to a constant is given as:

const <type of pointer>* <name of pointer>

An example definition could be:

const char* ptr;

Let us understand the working of pointer to constant through a small program:

#include<stdio.h>

int main(void)
{
int var1 = 0;
const int* ptr = &var1;
*ptr = 1;
printf("%d\n", *ptr);

return 0;
}

In the above code, we defined a variable named var1 and initialized it to 0. Then we defined a pointer to constant ptr and intialize it to point to the address of var1. Next we change the value of var1 to 1 through the use of *ptr. Finally , we print the new value using printf.

When we compile the above code, we get the following error:

$ gcc -Wall constptr.c -o constptr
constptr.c: In function ‘main’:
constptr.c:7: error: assignment of read-only location ‘*ptr’

We see that the compiler complains about ‘*ptr’ being read only. It means that we cannot change the value using the ‘ptr’ variable as it is defined to be a pointer to a constant.

Next we will discuss the last type: Constant Pointer to a Constant


 

Constant Pointer to a Constant

This type is a mixture of the above two types. A constant pointer to a constant is a pointer that can neither change the address it is pointing to nor it can change the value present at that address.

The syntax for defining a constant pointer to a constant is:

const <type of pointer>* const <name of pointer>

An example definition can be given like:

const char* const ptr;

Let us understand the working of constant pointer to a constant through a small program:

#include<stdio.h>

int main(void)
{
int var1 = 0,var2 = 0;
const int* const ptr = &var1;
*ptr = 1;
ptr = &var2;
printf("%d\n", *ptr);

return 0;
}

In the above program, we declared two integer variables var1 and var2 and initialize
them to 0. Next, we declared a constant pointer to a const ptr and intialized it to point to
var1. We then change the value and address of the pointer ptr in the next two lines. Finally, we print the value at the address pointed by ptr.

When we compile the above program, we get the following error:

$ gcc -Wall constptr.c -o constptr
constptr.c: In function ‘main’:
constptr.c:7: error: assignment of read-only location ‘*ptr’
constptr.c:8: error: assignment of read-only variable ‘ptr’

 

So we see that the compiler complains about both the value and address being changed.Hence, we infer that a constant pointer to a constant cannot change the address and value pointed by it.

I hope you have understood the concept of constant pointers in C and your misconceptions about it just like me must have been cleared through this post.

Looking forward to see you all, until then,

Happy Programming !!!!

 

 

 

 

Detect a loop in a Linked List

Suppose you are given a linked list like this:

linked-list-loop

And you want to remove the loop in it.

A very trivial way can be storing a boolean “visited” variable which stores true or false depending on whether a node is visited or not. But we need to store this info in each and every node. This will cost us some space.

A very clever way is to use two pointer for traversing the linked list. one pointer will travel one node at a time and other node will travel two nodes at a time. we can also call the pointers as slowpointer and fastpointer. Now, if there is a loop in a linked list , these two pointers will meet at a certain node.

The above mentioned algorithm was proposed by Robert Floyd and is also called Floyd’s loop detection algorithm.

so, this is how we detect a loop in a Linked List.