Bug 4618 - (int-120360) GtkMessageDialog text gets cripplet in portrait mode
(int-120360)
: GtkMessageDialog text gets cripplet in portrait mode
Status: RESOLVED WONTFIX
Product: Desktop platform
gtk
: 5.0-beta
: All Maemo
: Medium normal with 3 votes (vote)
: ---
Assigned To: unassigned
: gtk-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2009-06-02 18:52 UTC by Cornelius Hald
Modified: 2009-08-04 14:08 UTC (History)
5 users (show)

See Also:


Attachments
Crippled GtkMessageDialog (23.90 KB, image/png)
2009-06-02 18:54 UTC, Cornelius Hald
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Cornelius Hald (reporter) 2009-06-02 18:52:52 UTC
STEPS TO REPRODUCE THE PROBLEM:
Create a GtkMessageDialog with some text and show in portrait mode.

EXPECTED OUTCOME:
All text is shown, at least until the complete screen size is filled.

ACTUAL OUTCOME:
Not all text is shown, most of it is hidden behind the "yes" and "no" buttons.
But only the lowest 3rd of the screen is used, so there would be plenty of
space to show the complete message. (See screenshot)

REPRODUCIBILITY:
always
Comment 1 Cornelius Hald (reporter) 2009-06-02 18:54:58 UTC
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>
Comment 2 Alberto Garcia Gonzalez 2009-06-02 19:46:22 UTC
This is GTK, not Hildon. (I'll try to take a look at it anyway)
Comment 3 Andre Klapper maemo.org 2009-06-02 21:28:25 UTC
Confirming.
Comment 4 Andre Klapper maemo.org 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.
Comment 5 Cornelius Hald (reporter) 2009-06-05 19:03:59 UTC
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!
Comment 6 Alberto Garcia Gonzalez 2009-06-08 21:28:58 UTC
> 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? :)
Comment 7 Cornelius Hald (reporter) 2009-06-09 13:33:29 UTC
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 maemo.org 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 nokia 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?
Comment 10 Alberto Garcia Gonzalez 2009-06-09 15:04:33 UTC
(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?
Comment 11 Cornelius Hald (reporter) 2009-06-09 15:08:48 UTC
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?!
Comment 12 Alberto Garcia Gonzalez 2009-08-04 14:08:32 UTC
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.