On Thu, Jan 25, 2018 at 10:13 AM, Yuri Khan <yuri.v.k...@gmail.com> wrote:
> On Thu, Jan 25, 2018 at 3:18 PM, Kian Karas <kian.karas....@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. _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
