On Tue, Jun 02, 2009 at 08:09:36PM +0200, Cornelius Hald wrote: > this mail got a bit longer then I expected.
And the reply took longer than I expected too :) Please accept my apologies. > 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. Yes, that's probably true, but I think it'll happen to other parts of the UI as well. It's not easy to design an application that looks fine both in portrait and landscape with the UI unchanged (but I admit I'm not a UI designer) :) Wrt filters, you're right that it's harder to use them in portrait mode. The problem is that Fremantle was designed to be used mostly in landscape, with portrait being used in a few exceptional cases. > > Standard (Gtk) toolbars don't change, because I don't think > > there's a reliable and generic way to change their layout. [...] > > 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. Well, I know what you mean but please understand that we have to focus on some very important bugs and having the basic stuff working right before adding those extra niceties :) > 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. This can be done very easily if you hide the "unimportant" options when the screen rotates. Connect to the "size-changed" signal and then call gtk_widget_hide() All other menu items will rearrange when you hide/show any of them. > 2a) Menus: Why not leaving the GtkMenu API like it is, but draw it > like the AppMenu? That was our initial plan, but due to several technical reasons we saw that it was not feasible and decided to create a different widget. > 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. We try to do that where possible. Sometimes it's just a matter of theming the widget correctly, but other times it requires significant changes to Gtk, and the maemo-Gtk maintainers try to keep it as close to upstream as possible, because maintaining a big fork is a hard task, but they can tell you better than me :) Another thing is that legacy (i.e. pre-Fremantle) apps should look more or less the same (i.e., consistent within themselves). If we change the internals of many Gtk widgets to make them match the Fremantle UI style, old apps could look very weird. > 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. My personal opinion from what I can see is that Maemo 4 (and previous versions) had a UI style much closer to desktop apps, and Maemo 5 is VERY different in that sense. Implementing all the requires changes in Gtk while maintaining compatibility with previous versions is very very difficult. Or, in other words, making a desktop app that also looks like a Fremantle app with no changes in the code is basically impossible. Of course I admit that we could have made some mistakes, but believe me, we try to avoid creating new widgets unless it's necessary. > Thanks for reading! Thanks for writing :) and sorry again for the delay. Berto _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
