maemo.org Bugzilla – Full Text Bug Listing
|Summary:||Clarify which widgets support portrait mode in the Documentation|
|Product:||[Documentation] Developer Guide||Reporter:||Andre Klapper <andre_klapper>|
|Component:||maemo.org wiki||Assignee:||Jarmo Tikka <jarmo.tikka>|
|Status:||RESOLVED INVALID||QA Contact:||documentation <documentation>|
|Priority:||Medium||CC:||agarcia, andre_klapper, csaavedra, dneary, hald, murrayc, quim.gil|
Split from bug 4618. To me this has a high priority, otherwise 3rd party developers will get quite disappointed. CURRENT SITUATION: http://maemo.org/api_refs/5.0/beta/hig/html/ch02.html says: "Although both orientations are supported, framework level functionalities such as the status bar, back/close, are not available on the portrait mode." Internal comment in int-120360 is "Portrait mode is not fully supported. Applications are expected to use landscape only UI, or if they insist on portrait, then fix all the problems by themselves on the app side (e.g by creating plain GtkDialogs with empty action area)." EXPECTED SITUATION: Document exactly which widgets can be and which cannot be used in portrait mode. Also write more visible that portrait mode is not a goal for Fremantle.
I think the HIG should not deal with the specific details of which widget implements what. This should be documented probably in the API reference, stating explicitly which widgets will react automatically to orientation changes. Probably the tutorial could also indicate some implementation guidelines regarding this, like how to enable orientation support and request and when to use it. And yes, the HIG could link to these documents to the people interested in the details.
I can see the issue, though - if you have a GTK+ widget that doesn't support portrait mode, but is otherwise completely standard GTK+, then you need to document in GTK+ "this widget does not support portrait mode when used with the Maemo platform" - but that is then a patch that you have to maintain downstream, since a patch like that to the widget's docs will never get accepted upstream. So are you suggesting that every widget that doesn't support portrait mode has a comment attached like this, resulting in a delta with official GTK+ for all those widgets, for a comment?
No, you can't expect people to use maemo's GTK+ API reference when using Maemo. They will assume that the regular GTK+ reference is appropriate apart from when using obviously maemo-specific additions. So, this needs to be in a separate place. The HIG probably isn't the best place for it, though it would be better than nothing, as a <note>.
First of all, sorry for this long comment ;) I hope it can be used as a reference for future questions about this portrait/landscape issue. Summary: -------- In principle, all GTK+ widgets support portrait and landscape mode. In fact they're independent of the screen resolution. However, some widgets *might* not behave correctly if the resolution is too small. I don't have a list of them. GtkMessageDialog (bug 4618) might be one example. GTK+ is known to have problems when the resolution is too small (read: when widgets are not allocated the space they request). See here: http://bugzilla.gnome.org/show_bug.cgi?id=557596 That is not a trivial problem to solve, and given that complete support for portrait mode (when that bug is more likely to be triggered) is not a goal in Fremantle, fixing it is out of the scope of this project. However, if someone finds a particular widget that behaves really badly when there's not enough screen size (be it in portrait or landscape mode) at least *I* would like to know about it (but unfortunately I cannot guarantee that we can fix it for Fremantle). And now, the details: --------------------- GTK+ widgets themselves are independent of the resolution and don't have the notion of screen ratio or device orientation. They request the space they need to draw their contents, and that's it. If for some reason a widget is allocated more or less space than it requested, it's up to the widget to solve the problem and display its contents the best possible way. They generally do it correctly, unless the allocated space is really too small for their needs. As GTK+ widgets work on any resolution, from a general point of view there's no such thing as support for different orientations. What you get when you change to portrait mode is a different screen resolution, nothing more, nothing less. Simple widgets (e.g a button) don't usually need much space and so they can be drawn correctly in either orientation. But if you combine widgets, e.g., a box with four buttons in a row and you change to portrait mode then it probably isn't going to look good, not because it's a design limitation of the widgets, but because you're creating an interface not suited to the width you're trying to use it in. And I don't think GTK+ can do anything about it unless you expect, say, GtkHBox to split its contents into two rows if there's no space for just one. So: in general, GTK+ widgets support any resolution and orientation, but a particular combination of widgets might not look good if the screen resolution is less than X. A random application designed for landscape mode is not guaranteed to look good in portrait mode, and the toolkit can't do much about it. All that said, some widgets written specifically for Maemo *might* react to size changes to adapt themselves. The only widget doing that is HildonAppMenu, which isn't as generic as most other widgets, has very specific requirements and is designed with the resolution of the Nokia device in mind. If there's a particular widget that doesn't look good when its width is reduced from 800 to 480, chances are that you're trying to draw too many things inside it and the widget has no way of displaying them correctly in so little space. Of course it might be a bug in the widget. bug 4618 could be an example (I cannot confirm it because I haven't debugged it). It might be something like "GtkMessageDialog doesn't wrap its text correctly if it doesn't have enough width", which would be an upstream (rather than Maemo) bug, as it's a general bug applicable to all kinds of displays. And yeah, that doesn't mean it cannot be fixed in Maemo-GTK before it's fixed upstream, but, as it was already explained, that particular bug wasn't considered a priority by Nokia and wasn't given resources to debug it and fix it.
What is the situation of this report? I'm asking honestly since I don't follow the Hildon development and I couldn't follow the long discussions about portrait mode either. (In reply to comment #4) > That is not a trivial problem to solve, and given that complete > support for portrait mode (when that bug is more likely to be > triggered) is not a goal in Fremantle, fixing it is out of the scope > of this project. Then, is this an enhancement request? Or do you feel that the current documentation is enough, and specific widgets behaving really bad in portrait mode should be reported as specific bugs?
So... re-reading Claudio and Alberto's answer I wonder whether it would be better to close this (you choose the resolution) and then file bugs for specific widgets that developers are interested in but fail to perform well in portrait mode. In any case this doesn't feel like High-major, really. Applications supporting portrait mode are available in Extras already.
Let's close this as INVALID and ask people to file specific bug reports against epecific widgets.
[Rearrangement of Documentation bug reports.] Mass-moving old closed Developer Platform > Documentation tickets. You can filter bugmail by searching for this comment.