The Second Milestone

credits : UNIX and Linux System Administration Handbook (Nemeth, Snyder, Hein, Whaley)

This is the second post, about my GSoC progress. I know this is a late post but hope that the content coming your way suffices for the delay. So, cheers readers! Lets dive into it!

Getting the permissions right

Last post was about porting the Basic Tab of Properties window to use GtkBuilder where we got the basic process of porting right. This time we come with a similar goal for permissions-tab but with a tad-bit more content than the basics.

Like before the task started with porting the outer containers of the the permissions-page ie. defining them in XML and packing its inner contents inside a GtkBox on code. Commit: 1c978477 achieves the same.

Structue of permissions page

The outermost container of the permissions page packs a grid which delivers the basic usecase of the permissions-page, in addition to this the box also contains two labels at the top and bottom which respectively show up when the dialog is launched under exceptional ownership and file type circumstances.

Naturally the next step in our course of actions is to port these labels along with their prompt separators to the template definition. And make sure they appear only when needed using gtk_widget_show () in code. Commit 5953986c achieves the same. This has pretty much been a monotonic story, moving on to the interesting parts.

The Permissions Grid

Interestingly the permissions grid is not as simple as it sounds (looks!) I packs a total of 9 GtkLabel:GtkComboBox pairs which hide/show etc. based on the selection for which the properties-window has been launched morphing the appearance of the permissions grid.

The first image corresponds to permissions for a directory, and the second one is permissions for a composite selection of files and directories. Porting each row of the grid involves adding a GtkLabel:GtkComboBox pair to the .ui file and than glue together their data flow mechanisms to the existing logic in code.

Wait we missed something ? Where are the options in the ComboBoxes like we know them to be ?

GtkComboBoxes have Menu items too

Clearly we owe you an explanation! For the reason behind adding empty combo-boxes in Glade and populating them with code instead of doing so in Glade, there is one in the next section of this post. Commit bd8f590a ports all the GtkLabel:GtkComboBox rows to the .ui template.

The remaining rows of the grid like the execute-label, security-context, and the change-permissions button are ported to the .ui template in the commit 13cff098

GEEKY TEXT WARNING: The next section gets technical! Proceed Accordingly!

GtkComboBox: The Explanation as Promised

If you expected it to be simple, well it’s not! When you see many boxes sliding out a single one ‘you know it’s not simple!’ So, let’s put our nerd-glasses on and start dismantling the GtkComboBox.

According to the documentation :

> A GtkComboBox is a widget that allows the user to choose from a list of valid choices. The GtkComboBox displays the selected choice. When activated, the GtkComboBox displays a popup which allows the user to make a new choice.

> The GtkComboBox uses the model-view pattern the list of valid choices is specified in the form of a tree model, and the display of the choices can be adapted to the data in the model by using cell renderers, as you would in a tree view. This is possible since GtkComboBox implements the GtkCellLayout interface. The tree model holding the valid choices is not restricted to a flat list, it can be a real tree, and the popup will reflect the tree structure.

All in all this is what it says is :

Clearly, Glade supports the creation of empty GtkComboBoxes! Question arises does it also support Tree Model and Cell Renderer Widgets. The answer is Yes, It does! Glade supports the creation of Data Holding Widgets like GtkTreeStore and GtkListStore. The Options could be found neatly tucked away in the overflow menu.

So GtkListStore can be initialzed in Glade in the form of a table where Column types can be defined and than Data rows can be populated. Now,

  • Create GtkListStore –done
  • Connect GtkListStore with a GtkComboBox (Option found in General Tab)
  • Assign Cell Renderer of the ComboBox a Column from the Tree Model (Open the Combo Editor by right-clicking on ComboBox and selecting Edit) And this is how a complete ComboBox along with all it’s data members can be Constructed in Glade.
Why did we not populate permission-comboBoxes using Glade ?
  1. Permissions list stores have a column for permissions enum. While we can use the enum value symbol in C, we would have to use a numeric value in Glade, which is going to be quite obscure and hard to document
  2. Porting the models to GtkBuilder UI definition isn’t really improving hackability / design-ability much because of how Glade handles it
  3. The comboBox itself is already defined in the .ui file, so it’s possible to tweak the design even if the comboBoxes look empty
  4. If it would make things more complicated, then it’s more reasonable to let the code handle it.

Credits: @antoniof As a result @antoniof opened an issue about in Glade about the same : Combo-Editor Discoverability

Hhuh ! That was tedious ! Next blog-post will be talking about revisiting the Basic and Permissions page and completing them once-and for all.

4 thoughts on “The Second Milestone

  1. Pingback: Links 20/7/2020: Linux 5.8 RC6, KStars 3.4.3, Skrooge 2.23.0 | Techrights

  2. Pingback: GSoC final project report – cocoon

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s