Re: Scrolling a GtkTreeview cell

[Kian Karas <kian karas dev gmail com>]

On Thu, Jan 25, 2018 at 10:13 AM, Yuri Khan <yuri v khan gmail com> wrote:

> On Thu, Jan 25, 2018 at 3:18 PM, Kian Karas <kian karas dev gmail com>
> wrote:
>
> > It's an industrial device with a 4.5" screen. The only input method is a
> > keypad. The keypad has up/down/left/right/enter/back buttons (and some
> other
> > domain specific keys). The before mentioned keys are used to navigate a
> menu
> > system.
> >
> > The menu system is a tree structure with multiple levels. It is used to
> > access new views (different from the menu view; domain specific
> functions),
> > status information (e.g. serial no., SW version, etc.) and change
> settings.
>
> The menu system is a tree structure, but each screen is a flat list.
> So yes, you’d need a list, not a tree.
The tree view was selected because it required the least code. No one on
the team had any prior experience with GTK. It was really easy to get
going. But i realize now, that it is too simple for what we would like.


> > Here's a screenshot of status information, including the string that does
> > not fit (last row):
> > https://imgur.com/a/4XlTK
>
> This way of organizing information is sometimes called a property
> list. Initially a two-column table seems to be an obvious
> implementation, but it suffers from this particular problem when
> horizontal space is limited.
>
> How long is that NATID? I see 13 digits and an indication there are
> more.

 It is 19 characters, but you could imagine we run into the same problem in
the future with another text.


> Is there any convention to split that into groups, like you see
> 1234 5678 9012 3456 on bank cards?

That would help readability. At the
> same time, it introduces natural points to wrap lines.
>
>     Part Number         71-000000
>     Version                47.11D
>     Build Number          kk-5910
>     NATID          8988 1697 0000
>                         0000 0013
If a row is to span multiple lines, it might improve readability but how to
indicate to the user that the multi-line row is only in partial view? If
"Part Number" is in view, the second line of the "NATID" would not be.
I think I would still prefer scrolling the left column some how (without a
visible scrollbar). I haven't yet looked into how I could do that so any
suggestions would be appreciated ;) I think I would like a solution where
the ellipses would be shown in either (or both!?) sides of the string to
indicate it's possible to scroll to that side.


> Also it looks like the left column is too wide. The longest visible
> label is Build Number but the NATID value starts way to the right. If
> wrapping is not an option, I’d try to make the labels shorter. In a
> pinch, “Number” can be shortened to “#”.
My problem is all about compromising, and making the left column less
readable, would be one compromise. However, I don't think it's a good
compromise and it is not a general solution (there might be cases where
there is no reasonable mnemonic).


> Lastly, for this screen, you could skip the list box altogether and
> organize the property list as a single column GtkBox, where each child
> is a single row GtkBox, with the label in the left cell and value in
> the right cell. This approach takes you off the listbox grid; you can
> have one row with a long label and a short value, and another row with
> a short label and a long value.
>
>     Part Number           71-000000
>     Version                  47.11D
>     Build Number            kk-5910
>     NATID  8988 1697 0000 0000 0013
 I have thought about this possibility of loosing the fixed column width.
It's a good compromise. It will introduces a lot code complexity in my menu
object, but that's just the way it must be.

Sorry for turning it into a “what you want is wrong” discussion :)
>
No, I appreciate it! I realize now that the easy fix to the tree view
implementation I hoped for does not exist.

I'll need to decide between the list view and your suggested box-in-box
solution.