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.

Comment 2 Dave Neary 2009-06-17 19:47:12 UTC

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.

Comment 5 Quim Gil 2009-09-21 08:36:20 UTC

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?

Comment 6 Quim Gil 2009-10-14 07:56:40 UTC

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.

Comment 7 Andre Klapper (reporter) 2009-10-15 03:23:11 UTC

Let's close this as INVALID and ask people to file specific bug reports against
epecific widgets.

Comment 8 Andre Klapper (reporter) 2010-05-17 16:28:52 UTC

[Rearrangement of Documentation bug reports.]
Mass-moving old closed Developer Platform > Documentation tickets.
You can filter bugmail by searching for this comment.