Let's look how standard GtkFileChooserDialog looks on QVGA portrait device (240x320):
Note that "Places" pane on left cannot be shrinked beyond the size shown, which doesn't leave room for any useful display of filenames, so the dialog is clearly unusable.
So, I've took time to patch GTK+ 2.10.14 (this is the version used by Angstrom 2007.12, and my primary focus is to improve its usability on the supported devices) to make the widget be more PDA-friendly. I started with "data-driven" changes (meaning changing numbers and strings, but note code constructs):
- Reduced Gnome Human Interface Guidelines mandated spacing and borders of 6 and 12 pixels to 2. It's nice to have standards (even though Gnome doesn't offer us opportunity to choose from ;-) ), but on small screens, there's simply not enough space to spend pixel-wealth on gaps.
- Removed labels from Places pane's buttons, leaving only icons.
- Made Places pane shrinkable.
So, adaptive relayout was required, based on "PDA" mode being active. I first started with defining PDA mode as being portrait screen orientation, but thinking further, the problem, at least for GtkFileChooser, can be defined as follows: there's just too little of horizontal space available, and there should be efforts applied to use it to show as much of user's filenames' length as possible. Based on this note, PDA mode was defined as having a screen width below some threshold. This threshold was set as absolute value, but is not really arbitrary, and tied to real-world available screen sizes. I found that standard dialog looks pretty well in VGA landscape orientation, but still leaves too little space for filenames
in portrait orientation. So, threshold was set to 490 (to account for fudge factor ;-) ).
Now, with the above note on horizontal space scarcity, and keeping in mind that screen area at all is scarce, for vertical space should be saved too, following dynamic layout changes are done to dialog when being in PDA mode (i.e. run on the screen <490 pixels width):
- Vertical split pane is used for Places vs Filelist
- Buttons are packed to the left instead of bottom of Places
- Actually, only "Add" button was left, as "Remove" action can be easily accessed from Places list context menu, and most importantly, intuitively can be expected there. ("Add to shortcuts" choice is available for context menu on Filelist items, but who'd look for it there, without knowing it is?). This allows for more visually pleasing layout when Places pane is minimized.
- Dialog itself is sized to take all available width (originally, GTK+ sizes it to take no more than 3/4 of screen width, if possible, or packed requested size otherwise).
A refreshing change, with pretty long filenames being easily visible.
I've tested the patch pretty well, plus code changes are pretty small, so I intend to commit it to OE soon, and RFC its addition to Angstrom stable branch after it gets more review and testing.
There're still few things to consider and do to make it even more usable on small, PDA-like screens:
- Catch and process screen geometry change events - I'm pretty sure this is not done by GTK+ currently, and on dynamic screen device like PDA could make parts of dialog go offscreen when switching from landscape to portrait and vice-versa.
- Possibly, adjust screen width threshold based on more testing (original value was based on review of big-gaps dialogs, maybe smaller gaps affect that).
- Alternatively, gaps can be calculated on the fly, so original Gnome HIG-mandated values would be used on big screens, and small values only in PDA mode.
- Default "File system" choice in Places is superflous, it can be accessed with the icon from the path buttons at the top of dialogs. Unfortunately, screenshots above have it scrolled away. And having "File system" is Places causes exactly same problem: it takes space and calls for scrolling, so we'd better skip it there altogether, letting user to access own choices easier.
- Think about dialog height. Currently, as seen from above screenshot, it leaves bunch of screen area unused, and (apparently) due to Matchbox window management constraints, it cannot be resized by user. We could fit 1-2 more filenames if sized the dialog near-fullscreen. But that would look OK for QVGA, but already artificial for VGA.
Finally, it would be fun to have a look at GTK+ 2.12. As they say, it has stuff contributed by Nokia based on N770/N800 work, so I keep my fingers crossed that I didn't do monkey's job! ;-) Nonetheless, the focus is current Angstrom release, as I wrote above.
Great work! :M:
ReplyDeletePoky has had patches to GTK+ to reduce the size of the file selector since February, with quite a different look.
ReplyDelete2 Ross:
ReplyDeleteYes, Koen already pointed me to them. I still going to RFC adding my version to OE on the basis of its noticeably smaller size. It would be nice if you or other OH people could comment if it makes more sense to import your version (for example, if you're going to upstream it).
Annoyingly, upstream has rejected some of the interesting changes (such as basic removable media detection based on /media mounts), but with luck GTK+ 2.14 and GIO will let these changes be more localised.
ReplyDeleteWe'd love to get our changes upstreamed in some form, because it is so large resyncing it for a new GTK+ version is quite a chore!
Code: The code is no upstreamable. It applies look change without chance to configure it. Look switch is hardcoded using on pixel screen width. It is bad, because it does not take in account DPI and proposed font size (i. e. small screens with high DPI) and even can cause look change when using screen rotation. New enough gtk+ provides a way to provide completely custom file chooser. You may use it (even unconditionally) without need to patch gtk+.
ReplyDeleteLook and feel: Maybe I would prefer "one list" layout - Click to any item in "Places", it will disappear and in the same area the list will appear. Return to places would require a button. Also context menu is a bit uncomfortable with a stylus. I prefer menu or button.
HIG: Please criticize HIG in the GNOME list or bugzilla to get it changed.
2 Stanislav:
ReplyDeleteWhat made you think I intend to upstream that code or have an idea that it might be upstreamable? ;-)
What made you think that I criticize Gnome HIG, or want to have it changed? Or, if I would like to do so, I wouldn't know where to do it?
This is merely my personal blog, not a mailing list or bugtracker, please bear with it ;-).
As for your preferences on dialog look and feel, thanks for sharing them, eagerly awaiting your implementation, that would be very interesting!
Your blog says, that GNOME HIG does not take in account PDA devices. Reading it, I strogly agree with you. So I opened a discussion: http://mail.gnome.org/archives/usability/2008-January/msg00014.html
ReplyDeleteUpstreaming such useful patches is a generally useful idea. Otherwise half of them may be lost over the time.
I do not plan to rewrite your patch. But you could change one line to prevent swapping PDA/normal mode after xrandr call (not tested, would need to pass impl from the caller):
return (gdk_screen_width() + gdk_screen_height() - MAGIC_CONSTANT_VASTED_PIXELS_AROUND_84) / pango_font_description_get_size (GTK_WIDGET (impl)->style->font_desc) > MAGIC_CONSTANT_NUM_OF_CHARS_AROUND_70
Stanislav, thanks for your supporting this cause. If only I had some magic solution in my pocket to come to GTK+/Gnome people and say "hey, that's how it should be done". Unfortunately, that's not the case ;-). So, I'm trying to make changes with a limited, but useful scope (make current promising distro work well now).
ReplyDeleteI'll try to post to the thread you open just to share my thoughts on that.
As for screen orientation changes, I didn't test how original dialog behaves, and my patch doesn't take or give much to that. I'll try to look into this, and ping you for ideas how to handle it then.
Your magic constant is 490 pixels of screen width.
ReplyDeleteSo in 480x640 it will open reduced file chooser but in 640x480 it will use standard file chooser.
Upstream gtk+ will require a lot of work to become really PDA friendly. File chooser is only one small step.