ColumnView - the missing bits

[shartrec (Trevor Campbell)]

I’m not sure if this is the appropriate place to raise these points and I would be happy to raise bugs / improvement requests in the appropriate places if members of this group think it best.

Also I don’t mean these to be critical of the ongoing GTK4 development direction, but just hopefully useful feedback.

I have just recently finished converting my little application to GTK4 and updating it to get rid of all the deprecated usages. This mainly consisted of converting the use of TreeView and ListStore to using ColumnView and an implementation of ListModel.

While this has generally been reasonably straight forward and I have a couple of outstanding features that I’m not able to complete. This, in my humble opinion, is because of some missing and/or incorrect behaviour in the new features.

1. TreePath funtionality.
   In one area of the application I have a simple two level tree. If the user selects a lower leaf of the tree, there is no straight forward way to know at what position in the tree the parent branch is.

-B1
  |___L1
  |___L2
  |___L3
-B2
  |___L4
  |___L5

In the above example, L4 is selected there is no way of knowing its parent is in position 2. Similarly if B2 is selected, there is no way of knowing it is in position 2 as the index returned from the selection depends on the expansion state of the tree. It is easily possible to get the row from the TreeListModel and the underlying object, but without storing redundant (and therefore error prone) data in the underlying objects or by manually walking the tree and counting parent and child rows, the structure of a selection is hidden.

This is important to my application as I have an ordered model and a need to allow the user to reorder the items in both the parent and child models, e.g. move branch B2 before B1.

2. Selection behaviour
   In a ColumnView, a mouse click with button 2 or 3 does not cause the clicked on row to be selected. So when using a GestureClick it is not possible to know what row was a subject of the click and so showing a popup (context) menu and performing an action on the selected rows breaks from the accustomed conventions including the behaviour of TreeView. There is a potential workaround by setting SingleClickActivate but that introduces a whole range of other undesireable behaviours when combined with a popup menu. The main problem here is that the seleced item in the underlying list will change if the user accidentally allows the mouse pointer to wander outside the popup menu. This can bee seen here Wrong folder trashed when using right click->"Move to trash" (#157) · Issues · GNOME / baobab · GitLab.

3. TreeListModel invalidation
   In my particular case, the UI is not well aware of how the underlying model may have changed. Imagine the model is backed by an external database and the user presses “Refresh”. In my case each time I need to display an updated view of the model I completely rebuild the TreeListModel, SelectionModel, etc and reconnect them to the view. While this is easily done a simple invalidate() method on the model would be a convienience.

4. Access to Row widget and children.
   There is no apparent way to get the x,y coordinates of a selected row in the ColumnView. This is a usability issue when navigating with a keyboard and showing a popup (context) menu, as there is no way to locate the menu near to the selected row.
   Studying the code for Gnome Files, they use a workaround of storing a pointer to one of the widgets in the model object within the bind method of the ListItemFactory. This seems really unacceptable as, afaik, these widgets are reused and there are no gaurantees in the API that suggests this is safe.

[shartrec (Trevor Campbell)]

It turns out building a TreePath like structure is quite simple, once you get the issue clear in your mind.
In Rust

// Get a tree path vector from a TreeListModel
pub fn get_tree_path(row: u32, trm: &TreeListModel) -> Vec<u32> {
    let mut path: Vec<u32> = Vec::new();
    // Walk the tree filling in the path vector according to the depth we are at
    for i in 0..=row {
        if let Some(r) = trm.row(i) {
            let path_index = r.depth();
            if path_index as usize >= path.len() {
                path.push(0);
            } else {
                let old_val = path.remove(path_index as usize);
                path.insert(path_index as usize, old_val + 1);
            }
            // clear lower level paths
            path.truncate((path_index + 1) as usize);
        }
    }
    path
}

I have only tested this for my use case which has a depth on only 2.