Bug 4618 (int-120360)

Created an attachment (id=1212) [details]
Crippled GtkMessageDialog

The complete text on this dialog would be:
<dialog>
Really delete this note?

If you delete a note it is permanently lost.
</dialog>

This is GTK, not Hildon. (I'll try to take a look at it anyway)

Comment 3 Andre Klapper 2009-06-02 21:28:25 UTC

Confirming.

Comment 4 Andre Klapper 2009-06-05 18:31:43 UTC

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."

This has been closed internally as WONTFIX and the internal comment 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)."

If that is really Nokia's position then this should be much clearer noted in
the HIG.

Then maybe I should file a new bug: "Portrait mode not supported!"
I can see how only some closed source Nokia telephone application is using the
portrait mode and everyone else is left alone. Why even mention the portrait
mode in the API?

This is really weak!

> Then maybe I should file a new bug: "Portrait mode not supported!"

Well, the thing is that Fremantle is meant to be used mostly in
landscape mode. There's support for portrait mode as well, but it was
introduced for a few specific use cases rather than meant for all
programs (in fact, apps have to explicitly indicate that they support
portrait mode).

It's true that not all apps are going to look nice when changed to
portrait mode without changes, and I don't think it can (or should) be
done in a generic way. Some widgets (e.g. HildonAppMenu) are aware of
portrait mode, but most of them are not (and as I've just said, I
don't think there's a good generic solution for most widgets).

I admit that some widgets might have some extra support. However,
having full-fledged support for portrait mode as a goal for Fremantle
doesn't only involve changes in the code, but also a lot of effort on
design, testing, etc. As our resources are limited, we try to focus
first on other important parts of the platform that also need our
work.

Of course we could have made the portrait API secret just to solve our
internal needs, but do you really think it would have been better? :)

It´s clear that it´s not a 100% automatic process. We already talked about
that. But here we´re actually talking about a _dialog_. I mean how difficult
can it be to relayout a dialog to fit on the screen without hiding the text?
Those are two buttons, text and an icon and you have the _complete_ screen to
display them.

You cannot seriously think that this should be the responsibility of the
developer!

Here are some ideas how widgets could react to screen orientation change:
http://lists.maemo.org/pipermail/maemo-developers/2009-June/019424.html


However, I know you´re having people above you too ;)
Still, how about documenting exactly which widgets can be and which cannot be
used in portrait mode? And maybe also writing somewhere more visible that
portrait mode is not a goal for Fremantle!

Comment 8 Andre Klapper 2009-06-09 14:27:06 UTC

I have filed bug 4648 about the portrait mode documentation not being verbose
and explicit enough.

This bug here is unfortunately WONTFIX, as mentioned.

Comment 9 Eero Tamminen 2009-06-09 14:41:25 UTC

(In reply to comment #6)
> It's true that not all apps are going to look nice when changed to
> portrait mode without changes, and I don't think it can (or should) be
> done in a generic way. Some widgets (e.g. HildonAppMenu) are aware of
> portrait mode, but most of them are not (and as I've just said, I
> don't think there's a good generic solution for most widgets).

At least in the dialog case I don't think it's so much of an issue of
"rotation" or "portrait mode", but reaction on resizes.  Doesn't Gtk have
options for label used in the dialog that would handle this automatically?

(In reply to comment #9)
> At least in the dialog case I don't think it's so much of an issue
> of "rotation" or "portrait mode", but reaction on resizes.  Doesn't
> Gtk have options for label used in the dialog that would handle this
> automatically?

Yes, that's true. This upstream bug looks related too:

http://bugzilla.gnome.org/show_bug.cgi?id=345349

Chris, are you there? :-) What do you think about this?

I´m not so sure that it´s related. The Gtk bug is talking about filenames which
do not have whitespaces. Therefor they are normally not wrapped. In my example
are plenty of whitespaces so I think that shouldn´t be the problem?!

I think that the fix for internal bug #124303 could fix this one too.

I'll try to check it very quickly after that one is fixed.