maemo.org Bugzilla – Bug 4618
GtkMessageDialog text gets cripplet in portrait mode
Last modified: 2009-08-04 14:08:32 UTC
You need to log in before you can comment on or make changes to this bug.
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
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)
Confirming.
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!
I have filed bug 4648 about the portrait mode documentation not being verbose and explicit enough. This bug here is unfortunately WONTFIX, as mentioned.
(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.