Hi, this mail got a bit longer then I expected. I added some ideas how the UI could react to orientation changes. Those are only ideas and I know that it´s too late to implement/change all this. Also I´m aware that there might be different opinions ;) I just had to get this of my chest. Maybe it will at least evolve into a fruitful discussion :)
Alberto Garcia wrote: > HildonAppMenu has automatic relayout. The number of columns changes > from 2 to 1, and filters remain the same. If really necessary, you can > also have a different menu for portrait mode, hide some of its items > or change some of their labels. > I think most people who use filters and the portrait mode will have to create a different version of the menu for portrait mode. In my opinion there is just not enough space to put them in one row. From the hildon HIG HIG[1]: "Filters should be presented in groups. For example, if the menu should allow the user to sort a list of messages alphabetically, the filters present should be at least a "sort alphabetically" filter and a "sort by date"." Well, first it´s not possible to present filters without a group, so the first sentence doesn't really make sense ;) and (more important) second: The example filter should have _at least_ "sort alphabetically" and "sort by date". I cannot check right now, but I doubt that those two strings fit into the filter group in portrait mode. And even if they do, how does it look with non-english strings like "Alphabetisch sortieren" and "Nach Datum sortieren"?! Maybe you should check again if the filter UI really makes sense at the moment. I know it looks cool, but that doesn't help much if later no one can use it. > Standard (Gtk) toolbars don't change, because I don't think there's > a reliable and generic way to change their layout. If a particular > toolbar doesn't look good in portrait mode because it has too many > items, it's IMHO the app -not the toolkit- that should take care of > this. The same applies to many other widgets and the whole program > UI in general (if it's going to support portrait mode it should be > designed with that in mind). > Hmm... Well, I think the toolkit should do as much as possible for the developer. If the developer wants to override all this magical stuff, then there surely should be a way to do so. I have a couple of ideas how to do this. I have no idea how the relation between Hildon and Maemo-Gtk is, so I don´t know how feasible my suggestion are. Basically I was thinking that Hildon and Maemo-Gtk is one project and the word "hildon" is more or less just used to introduce API which does not exist in pure Gtk... But anyways, here are some ideas how to embrace the portrait mode a bit more and make the life for application developers easier. 1a) Introduce some kind of "important" property for widgets. Using this, I could mark some of my buttons as important and thus the UI would make sure that they are shown even in portrait mode. Buttons or widgets without that flag could be omitted or put into a sub menu if there is not enough space. Using this mechanism I also could mark one of my table view column as important. The other column could be omitted. 1b) If a property like "important" is too generic/vague then how about a "portrait" and "landscape" property. This way I still would have the complete control over which widget are shown when and I would have to thing about portrait and landscape mode, but at least I wouldn´t clutter my code with lots of if (portrait_mode) statements... 1c) Or how about that: Landscape mode is always "edit mode" and portrait mode is always "view mode". In this way the application developer would get a big hint on which buttons/widget should be shown. I surely don´t need a "change font style" button if I´m in the "view mode". Using this distinction it would also be possible to change the behavior of other widgets in a meaning full way. For example the text view could change from being editable/selectable with the fingers in "edit mode" to being pannable in "view mode". 2a) Menus: Why not leaving the GtkMenu API like it is, but draw it like the AppMenu? It could still be hierarchically. If I press a button which opens a new sub menu, this sub menu just slided over the current menu and. That way all applications could use a finger friendly menu which using new API. If there are too many (more then 10) menu item, then just show scroll buttons like in the Diablo start menu. If there are GtkRadioMenuItems in that menu they could automatically be shown as Filters and so on... Of course very long menus or menus with deep hierarchies would still be annoying for the end users, but they can be changed over time to make it a pleasant experience. IMO it still would be a much better experience then giving the user a device where every second application still has those ugly stylus menus. 2b) Toolbars: Automatically distribute all buttons on the toolbar evenly over the available space. In this way if an application has only 5 buttons on the toolbar it will look good and consistent in landscape and in portrait mode. 2b) Toolbars: If there are too many items on the toolbar then displace some kind of ">" sign on the right side of the toolbar. This arrow symbol should have the same size like every other tool button. Then when the user clicks this button, the current toolbar just slides to the left out of the view and from the right side a new toolbar (or new tool items) slide in. Now this toolbar has a "<" sign on the left and maybe a ">" sign on the right. In this way even large toolbars stay finger friendly and don´t use more space then before. With the sliding animation the users gets enough feed back to know what´s going on. Here again, the application developer should be encouraged to reduce the number of tool items or to drop the toolbar completely, still it would be possible to have a large toolbar if really needed and applications which are not completely ported would look nice too. All in all I think that the Gtk-API should be used more, but that the rendering on the screen should just different from the rendering on the desktop. If I remember correctly there was quite some effort for Maemo 4.0 to remove own/specific API and replace them with existing API, now it looks like we´re going into the other direction again. If you argue that traditional Gtk application should still work as expected, I totally agree. Therefore I would suggest something like that: If a developer initializes his application with gtk_init() he gets traditional behavior and sizing, but if he uses hildon_gtk_init() all widgets represent them selfs als finger friendly as possible. This could of course also be decided on per widget basis if needed. Fine tuning of the Maemo UI can then be done by using properties (like finger size or thumb size) that are just ignored by normal Gtk. In my opinion this would make writing or porting UIs much easier. Almost every developer hates coding UIs, so I think it should be made as pleasant as possible. I did not prove read, so please excuse minor mistakes... Now I hopefully can get back to work :) Thanks for reading! Conny [1] http://maemo.org/api_refs/5.0/beta/hig/html/ch04s02.html _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
