Re: Fremantle UI Portrait Mode
On Fri, 2009-06-12 at 12:17 +0200, Alberto Garcia wrote: However the modifications you're talking about (changing the implementation of Gtk widgets so they look/behave differently while maintaining the same API) can't, by definition, be moved upstream :) I don't see why not. That happens for the Windows and Mac ports. OK, so this might need a slightly different structure in the source code, but it's perfectly #ifdef-able. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, 2009-06-12 at 00:23 +0200, Alberto Garcia wrote: All in all I think that the Gtk-API should be used more, but that the rendering on the screen should just different from the rendering on the desktop. We try to do that where possible. Sometimes it's just a matter of theming the widget correctly, but other times it requires significant changes to Gtk, and the maemo-Gtk maintainers try to keep it as close to upstream as possible, because maintaining a big fork is a hard task, but they can tell you better than me :) It's easier now that GTK+ (and hildon) uses git. And the changes could go upstream within a year, reducing the differences in your fork. This happened for previous Maemo GTK+ additions: http://live.gnome.org/Maemo/GtkContributions (I know it's too late.) -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, Jun 12, 2009 at 10:31:44AM +0200, Murray Cumming wrote: All in all I think that the Gtk-API should be used more, but that the rendering on the screen should just different from the rendering on the desktop. We try to do that where possible. Sometimes it's just a matter of theming the widget correctly, but other times it requires significant changes to Gtk, and the maemo-Gtk maintainers try to keep it as close to upstream as possible, because maintaining a big fork is a hard task, but they can tell you better than me :) It's easier now that GTK+ (and hildon) uses git. And the changes could go upstream within a year, reducing the differences in your fork. This happened for previous Maemo GTK+ additions: http://live.gnome.org/Maemo/GtkContributions Moving these changes upstream is something that the maemo-gtk maintainers are already doing AFAIK. We all try to add to maemo-gtk all things that can go upstream. However the modifications you're talking about (changing the implementation of Gtk widgets so they look/behave differently while maintaining the same API) can't, by definition, be moved upstream :) Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Tue, Jun 02, 2009 at 08:09:36PM +0200, Cornelius Hald wrote: this mail got a bit longer then I expected. And the reply took longer than I expected too :) Please accept my apologies. I think most people who use filters and the portrait mode will have to create a different version of the menu for portrait mode. In my opinion there is just not enough space to put them in one row. Yes, that's probably true, but I think it'll happen to other parts of the UI as well. It's not easy to design an application that looks fine both in portrait and landscape with the UI unchanged (but I admit I'm not a UI designer) :) Wrt filters, you're right that it's harder to use them in portrait mode. The problem is that Fremantle was designed to be used mostly in landscape, with portrait being used in a few exceptional cases. Standard (Gtk) toolbars don't change, because I don't think there's a reliable and generic way to change their layout. [...] The same applies to many other widgets and the whole program UI in general (if it's going to support portrait mode it should be designed with that in mind). Hmm... Well, I think the toolkit should do as much as possible for the developer. If the developer wants to override all this magical stuff, then there surely should be a way to do so. Well, I know what you mean but please understand that we have to focus on some very important bugs and having the basic stuff working right before adding those extra niceties :) 1a) Introduce some kind of important property for widgets. Using this, I could mark some of my buttons as important and thus the UI would make sure that they are shown even in portrait mode. Buttons or widgets without that flag could be omitted or put into a sub menu if there is not enough space. This can be done very easily if you hide the unimportant options when the screen rotates. Connect to the size-changed signal and then call gtk_widget_hide() All other menu items will rearrange when you hide/show any of them. 2a) Menus: Why not leaving the GtkMenu API like it is, but draw it like the AppMenu? That was our initial plan, but due to several technical reasons we saw that it was not feasible and decided to create a different widget. All in all I think that the Gtk-API should be used more, but that the rendering on the screen should just different from the rendering on the desktop. We try to do that where possible. Sometimes it's just a matter of theming the widget correctly, but other times it requires significant changes to Gtk, and the maemo-Gtk maintainers try to keep it as close to upstream as possible, because maintaining a big fork is a hard task, but they can tell you better than me :) Another thing is that legacy (i.e. pre-Fremantle) apps should look more or less the same (i.e., consistent within themselves). If we change the internals of many Gtk widgets to make them match the Fremantle UI style, old apps could look very weird. If I remember correctly there was quite some effort for Maemo 4.0 to remove own/specific API and replace them with existing API, now it looks like we´re going into the other direction again. My personal opinion from what I can see is that Maemo 4 (and previous versions) had a UI style much closer to desktop apps, and Maemo 5 is VERY different in that sense. Implementing all the requires changes in Gtk while maintaining compatibility with previous versions is very very difficult. Or, in other words, making a desktop app that also looks like a Fremantle app with no changes in the code is basically impossible. Of course I admit that we could have made some mistakes, but believe me, we try to avoid creating new widgets unless it's necessary. Thanks for reading! Thanks for writing :) and sorry again for the delay. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
Hi fellow developers! If you´re planning to use the portrait mode in Fremantle, please first have a look at this (WONTFIX) bug: https://bugs.maemo.org/show_bug.cgi?id=4618 Cheers! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
Murray Cumming wrote: On Fri, 2009-05-29 at 23:07 +0300, Henrik Hedberg wrote: However, usually developer should not need to know mode but Hildon widgets should adjust themselves as much as possible during the relayout. Unfortunately that seems not to be the case, as Conny demonstrated earlier with some screenshots. Yes, someone should file bugs about those standard dialogs. I just did. Here: https://bugs.maemo.org/show_bug.cgi?id=4618 Also I entered a bug for the toolbars: https://bugs.maemo.org/show_bug.cgi?id=4617 I hope it´s ok, I´m not very familiar with the bugzilla monster ;) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
Am Dienstag, den 02.06.2009, 18:06 +0200 schrieb Cornelius Hald: https://bugs.maemo.org/show_bug.cgi?id=4618 https://bugs.maemo.org/show_bug.cgi?id=4617 I hope it´s ok, I´m not very familiar with the bugzilla monster ;) Seems like you successfully tamed Bugzilla, though I always love to see exact steps to reproduce (e.g. in order to reproduce the issue I wonder how to start Fremantle SDK beta in Portrait mode). ;-) andre -- Andre Klapper (maemo.org bugmaster) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
Andre Klapper wrote: Am Dienstag, den 02.06.2009, 18:06 +0200 schrieb Cornelius Hald: https://bugs.maemo.org/show_bug.cgi?id=4618 https://bugs.maemo.org/show_bug.cgi?id=4617 I hope it´s ok, I´m not very familiar with the bugzilla monster ;) Seems like you successfully tamed Bugzilla, though I always love to see exact steps to reproduce (e.g. in order to reproduce the issue I wonder how to start Fremantle SDK beta in Portrait mode). ;-) Ah well, that would be another bug report :P Easiest way is to just create the Xephyr window with -screen 480x800x16 instead of -screen 800x480x16 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
Hi, this mail got a bit longer then I expected. I added some ideas how the UI could react to orientation changes. Those are only ideas and I know that it´s too late to implement/change all this. Also I´m aware that there might be different opinions ;) I just had to get this of my chest. Maybe it will at least evolve into a fruitful discussion :) Alberto Garcia wrote: HildonAppMenu has automatic relayout. The number of columns changes from 2 to 1, and filters remain the same. If really necessary, you can also have a different menu for portrait mode, hide some of its items or change some of their labels. I think most people who use filters and the portrait mode will have to create a different version of the menu for portrait mode. In my opinion there is just not enough space to put them in one row. From the hildon HIG HIG[1]: Filters should be presented in groups. For example, if the menu should allow the user to sort a list of messages alphabetically, the filters present should be at least a sort alphabetically filter and a sort by date. Well, first it´s not possible to present filters without a group, so the first sentence doesn't really make sense ;) and (more important) second: The example filter should have _at least_ sort alphabetically and sort by date. I cannot check right now, but I doubt that those two strings fit into the filter group in portrait mode. And even if they do, how does it look with non-english strings like Alphabetisch sortieren and Nach Datum sortieren?! Maybe you should check again if the filter UI really makes sense at the moment. I know it looks cool, but that doesn't help much if later no one can use it. Standard (Gtk) toolbars don't change, because I don't think there's a reliable and generic way to change their layout. If a particular toolbar doesn't look good in portrait mode because it has too many items, it's IMHO the app -not the toolkit- that should take care of this. The same applies to many other widgets and the whole program UI in general (if it's going to support portrait mode it should be designed with that in mind). Hmm... Well, I think the toolkit should do as much as possible for the developer. If the developer wants to override all this magical stuff, then there surely should be a way to do so. I have a couple of ideas how to do this. I have no idea how the relation between Hildon and Maemo-Gtk is, so I don´t know how feasible my suggestion are. Basically I was thinking that Hildon and Maemo-Gtk is one project and the word hildon is more or less just used to introduce API which does not exist in pure Gtk... But anyways, here are some ideas how to embrace the portrait mode a bit more and make the life for application developers easier. 1a) Introduce some kind of important property for widgets. Using this, I could mark some of my buttons as important and thus the UI would make sure that they are shown even in portrait mode. Buttons or widgets without that flag could be omitted or put into a sub menu if there is not enough space. Using this mechanism I also could mark one of my table view column as important. The other column could be omitted. 1b) If a property like important is too generic/vague then how about a portrait and landscape property. This way I still would have the complete control over which widget are shown when and I would have to thing about portrait and landscape mode, but at least I wouldn´t clutter my code with lots of if (portrait_mode) statements... 1c) Or how about that: Landscape mode is always edit mode and portrait mode is always view mode. In this way the application developer would get a big hint on which buttons/widget should be shown. I surely don´t need a change font style button if I´m in the view mode. Using this distinction it would also be possible to change the behavior of other widgets in a meaning full way. For example the text view could change from being editable/selectable with the fingers in edit mode to being pannable in view mode. 2a) Menus: Why not leaving the GtkMenu API like it is, but draw it like the AppMenu? It could still be hierarchically. If I press a button which opens a new sub menu, this sub menu just slided over the current menu and. That way all applications could use a finger friendly menu which using new API. If there are too many (more then 10) menu item, then just show scroll buttons like in the Diablo start menu. If there are GtkRadioMenuItems in that menu they could automatically be shown as Filters and so on... Of course very long menus or menus with deep hierarchies would still be annoying for the end users, but they can be changed over time to make it a pleasant experience. IMO it still would be a much better experience then giving the user a device where every second application still has those ugly stylus menus. 2b) Toolbars: Automatically distribute all buttons on the toolbar evenly over the available space. In this
Re: Fremantle UI Portrait Mode
Henrik Hedberg wrote:
Murray Cumming wrote:
On Fri, 2009-05-29 at 13:20 +0200, Alberto Garcia wrote:
To detect screen orientation changes you can e.g. use the
size-changed signal of GdkScreen.
This seems like a rather long-winded way to detect landscape or portrait
mode, requiring the hard coding of the dimensions.
if (width height) {
/* landscape */
} else if (width height) {
/* portrait */
} else {
/* square :) */
}
However, usually developer should not need to know mode but Hildon
widgets should adjust themselves as much as possible during the
relayout. Unfortunately that seems not to be the case, as Conny
demonstrated earlier with some screenshots.
Mmm... what could possibly go wrong ... eg when we look at maemo on a slightly
squarer device with a different windowmanager layout.
Surely
XRRScreenChangeNotifyEvent
should be supported since this actually provides 'orientation' which is what IU
the UI guidelines suggest working to.
Maybe even abstracted to a high level 'RandRChanged' signal?
David
--
Don't worry, you'll be fine; I saw it work in a cartoon once...
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, May 29, 2009 at 11:07:32PM +0300, Henrik Hedberg wrote: However, usually developer should not need to know mode but Hildon widgets should adjust themselves as much as possible during the relayout. Unfortunately that seems not to be the case, as Conny demonstrated earlier with some screenshots. As Murray says, that's not always possible/feasible with all standard Gtk widgets. There is one (1) Hildon widget in Conny's screenshots and that one is already fixed. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, 2009-05-29 at 23:07 +0300, Henrik Hedberg wrote: However, usually developer should not need to know mode but Hildon widgets should adjust themselves as much as possible during the relayout. Unfortunately that seems not to be the case, as Conny demonstrated earlier with some screenshots. Yes, someone should file bugs about those standard dialogs. And most custom application layouts would need a different layout for portrait mode. The GTK+ box model can't know that you suddenly want the buttons in a hbox on the bottom instead of in a vbox on the right. I'm currently reading about Android. They have a whole API for reacting to the orientation change for this reason. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Sat, 2009-05-30 at 12:47 +0200, Murray Cumming wrote: And most custom application layouts would need a different layout for portrait mode. The GTK+ box model can't know that you suddenly want the buttons in a hbox on the bottom instead of in a vbox on the right. Some time ago I wrote a magic paned container which laid its children out like a GtkHPaned or GtkVPaned depending on the allocation it has been given. It worked surprisingly well for the classic use case of a paned where you have a list of objects in one side and details of the selected object in the other. http://svn.o-hand.com/repos/misc/trunk/libowl/libowl/owlpaned.c A better solution would be for GtkPaned to be a concrete class and have an orientation property, then a convenience function could monitor the allocation and switch it on the fly (and work for other containers such as GtkBox). Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
Kimmo Hämäläinen wrote: Yes, we have _HILDON_PORTRAIT_MODE_REQUEST and _HILDON_PORTRAIT_MODE_SUPPORT window properties (I think libhildon has convenience functions for setting them). The request property makes hildon-desktop to rotate the screen using XRandR, _IF_ all other visible windows are ok with that. If you don't have the support property or request property, it means that your window only supports the landscape mode. And if there is no convenience function in HildonWindow, then there is naturally the source code of hildon-desktop. :) It contains a test application called tests/test-portrait-win.c. Worth looking... http://repository.maemo.org/pool/maemo5.0alpha/free/h/hildon-desktop/hildon-desktop_2.2.20-1.tar.gz BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, 2009-05-29 at 13:48 +0300, Kimmo Hämäläinen wrote:
On Thu, 2009-05-28 at 17:19 +0200, ext Cornelius Hald wrote:
* What happens to toolbars when in portrait mode? Is there some
automatic behavior like showing the toolbar as two rows instead of a
single row? Is it scaled? Is the space between the buttons reduced?
Or do we have to care about this by ourself, for example listen to some
signal and then hiding some buttons or rearranging them?
AFAIK, there is automatic relayout only for confirmation dialogs (and
maybe application menu as you said), but not much more. So toolbars you
have to handle yourself. The toolkit people can give better answers
(I'm handling the hildon-desktop side).
Toolkit people here :)
Offhand, application menus and confirmation notes will relayout; banners
and picker dialogs will resize to new screen dimensions. That's pretty
much it (unless I'm forgetting something).
* What happens to any other widget when in portrait mode?
It looks crap. That's why the rotation is not unconditional, see below.
* Is there a signal which signals that the screen orientation changed?
Yes, XRandr signals, which are handled by GTK, methinks.
You can connect to GdkScreen::size-changed or GdkScreen::monitors-
changed to get notified and do your magic.
* Is there a function to change the screen orientation and can we
somehow use this with the beta SDK?
Yes, we have _HILDON_PORTRAIT_MODE_REQUEST and
_HILDON_PORTRAIT_MODE_SUPPORT window properties (I think libhildon has
convenience functions for setting them).
typedef enum {
HILDON_PORTRAIT_MODE_REQUEST = 1 0,
HILDON_PORTRAIT_MODE_SUPPORT = 1 1
} HildonPortraitFlags;
hildon_gtk_window_set_portrait_flags (GtkWindow *window,
HildonPortraitFlags portrait_flags);
The HIG[1][2] is very vague on that matter so it would really be nice if
someone from the hildon team or the UI specs team could comment on that.
I think it would be a shame if the new device is finally available and
every time someone holds the device in portrait mode, everything* looks
like crap.
If you don't want to support portrait mode, just don't set any portrait
flags and the UI will look as crappy as you originally planned :)
Claudio
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, May 29, 2009 at 01:48:54PM +0300, Kimmo Hämäläinen wrote: AFAIK, there is automatic relayout only for confirmation dialogs (and maybe application menu as you said), but not much more. So toolbars you have to handle yourself. The toolkit people can give better answers (I'm handling the hildon-desktop side). HildonAppMenu has automatic relayout. The number of columns changes from 2 to 1, and filters remain the same. If really necessary, you can also have a different menu for portrait mode, hide some of its items or change some of their labels. Standard (Gtk) toolbars don't change, because I don't think there's a reliable and generic way to change their layout. If a particular toolbar doesn't look good in portrait mode because it has too many items, it's IMHO the app -not the toolkit- that should take care of this. The same applies to many other widgets and the whole program UI in general (if it's going to support portrait mode it should be designed with that in mind). Edit-mode toolbars (HildonEditToolbar) look fine in portrait mode. Again, if the label is too long for portrait the app can change it. To detect screen orientation changes you can e.g. use the size-changed signal of GdkScreen. * Is there a function to change the screen orientation and can we somehow use this with the beta SDK? hildon_gtk_window_set_portrait_flags (window, HILDON_PORTRAIT_MODE_REQUEST | HILDON_PORTRAIT_MODE_SUPPORT); Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Thu, 2009-05-28 at 19:03 +0300, Eero Tamminen wrote:
* Is there a signal which signals that the screen orientation changed?
Application needs to specifically request portrait mode with a window
property (I guess there's some API for that), otherwise window manager
uses landscape mode for the application window.
In the beta SDK there seems to be no API, but when looking into the git
version of hildon I can find some stuff. The last time I was checking I
somehow missed that. But a grep for portrait revealed some places. The
function seems to be hildon_gtk_window_set_portrait_flags() in
hildon-gtk.c.
App can listen to standard XRandr messages for this transition if
it wants to, but it's not necessary.
Ok. Originally I was thinking that XRandr will not be used. I thought
that this would happen on toolkit level - but don't ask me why ;)
* Is there a function to change the screen orientation and can we
somehow use this with the beta SDK?
It's just a question whether your distro's Xephyr version has XRandR
enabled. It should.
Then just use xrandr -o left/right/normal for Xephyr's display.
I did that, and yes, it rotates the screen :) Here again I was aware of
XRandr but thought that it will be implemented on top of something like
clutter to have nice transition effects and stuff... So I was not
thinking about the obvious.
After rotating everything looks ok, but when clicking around I realized
that only the visual content is rotated. Mouse clicks are still handled
like the screen is not rotated at all. For example to close a window I
still have to click the top right corner of my Xephyr window instead of
the top left corner where the close button is drawn.
I figured that I have to set those window properties somehow, so I
checked the newer hildon code and came up with the following code:
static void
set_flag(GtkWindow *window, const gchar *atomname, Atom xatom, gboolean
flag) {
GdkWindow *gdkwin = GTK_WIDGET(window)-window;
GdkAtom atom = gdk_atom_intern(atomname, FALSE);
if (flag) {
guint32 set = 1;
gdk_property_change(gdkwin, atom, gdk_x11_xatom_to_atom(xatom), 32,
GDK_PROP_MODE_REPLACE, (const guchar *) set, 1);
} else {
gdk_property_delete(gdkwin, atom);
}
}
static void
set_portrait_mode(GtkWindow *window, gboolean portrait)
{
set_flag(window, _HILDON_PORTRAIT_MODE_SUPPORT, XA_CARDINAL,
portrait);
set_flag(window, _HILDON_PORTRAIT_MODE_REQUEST, XA_CARDINAL,
portrait);
}
But calling that didn't make a difference. So either the code is wrong
or the window manger in the beta SDK doesn't know about those
properties.
So next, just tried to create a Xepyr window with portrait dimensions,
but without rotation by calling:
Xephyr :2 -host-cursor -screen 480x800x16 -dpi 96 -ac
The result was much better working, unfortunately the UI didn't adopt
much to the new dimensions. The only widget that I use which really
adopted it self, was the AppMenu. The AppMenu shows the buttons in one
column instead of in two. But the Filters are still in one row, leaving
them almost no space at all.
Here are some screenshots:
The main window (toolbar cannot show all items - small arrow is added)
http://zwong.de/wp-content/uploads/2009/05/conboy_note_window.png
A click on the arrow brings up a not finger friendly menu:
http://zwong.de/wp-content/uploads/2009/05/conboy_toolbar_portrait.png
A click on the delete button brings up a crippled dialog:
http://zwong.de/wp-content/uploads/2009/05/conboy_delete_dialog_portrait.png
The AppMenu looks nice, only the Filters get crippled:
http://zwong.de/wp-content/uploads/2009/05/conboy_style_menu_portrait.png
The search window looks as expected:
http://zwong.de/wp-content/uploads/2009/05/conboy_search_window_portrait.png
I think I did my homework ;) Could now please someone how made the specs
comment on whether this is the expected behavior or not?
Thanks!
Conny
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
Grrr I should have just waited for another couple of hours :D
Thanks Kimmo, Berto, Claudio and Hendrik for answering my questions.
They rendered this mail quite useless. Well, maybe at least the
screenshots help someone to get a feeling of the problems he/she will
have to face when implementing portrait mode.
So long!
Conny
On Fri, 2009-05-29 at 13:22 +0200, Cornelius Hald wrote:
On Thu, 2009-05-28 at 19:03 +0300, Eero Tamminen wrote:
* Is there a signal which signals that the screen orientation changed?
Application needs to specifically request portrait mode with a window
property (I guess there's some API for that), otherwise window manager
uses landscape mode for the application window.
In the beta SDK there seems to be no API, but when looking into the git
version of hildon I can find some stuff. The last time I was checking I
somehow missed that. But a grep for portrait revealed some places. The
function seems to be hildon_gtk_window_set_portrait_flags() in
hildon-gtk.c.
App can listen to standard XRandr messages for this transition if
it wants to, but it's not necessary.
Ok. Originally I was thinking that XRandr will not be used. I thought
that this would happen on toolkit level - but don't ask me why ;)
* Is there a function to change the screen orientation and can we
somehow use this with the beta SDK?
It's just a question whether your distro's Xephyr version has XRandR
enabled. It should.
Then just use xrandr -o left/right/normal for Xephyr's display.
I did that, and yes, it rotates the screen :) Here again I was aware of
XRandr but thought that it will be implemented on top of something like
clutter to have nice transition effects and stuff... So I was not
thinking about the obvious.
After rotating everything looks ok, but when clicking around I realized
that only the visual content is rotated. Mouse clicks are still handled
like the screen is not rotated at all. For example to close a window I
still have to click the top right corner of my Xephyr window instead of
the top left corner where the close button is drawn.
I figured that I have to set those window properties somehow, so I
checked the newer hildon code and came up with the following code:
static void
set_flag(GtkWindow *window, const gchar *atomname, Atom xatom, gboolean
flag) {
GdkWindow *gdkwin = GTK_WIDGET(window)-window;
GdkAtom atom = gdk_atom_intern(atomname, FALSE);
if (flag) {
guint32 set = 1;
gdk_property_change(gdkwin, atom, gdk_x11_xatom_to_atom(xatom), 32,
GDK_PROP_MODE_REPLACE, (const guchar *) set, 1);
} else {
gdk_property_delete(gdkwin, atom);
}
}
static void
set_portrait_mode(GtkWindow *window, gboolean portrait)
{
set_flag(window, _HILDON_PORTRAIT_MODE_SUPPORT, XA_CARDINAL,
portrait);
set_flag(window, _HILDON_PORTRAIT_MODE_REQUEST, XA_CARDINAL,
portrait);
}
But calling that didn't make a difference. So either the code is wrong
or the window manger in the beta SDK doesn't know about those
properties.
So next, just tried to create a Xepyr window with portrait dimensions,
but without rotation by calling:
Xephyr :2 -host-cursor -screen 480x800x16 -dpi 96 -ac
The result was much better working, unfortunately the UI didn't adopt
much to the new dimensions. The only widget that I use which really
adopted it self, was the AppMenu. The AppMenu shows the buttons in one
column instead of in two. But the Filters are still in one row, leaving
them almost no space at all.
Here are some screenshots:
The main window (toolbar cannot show all items - small arrow is added)
http://zwong.de/wp-content/uploads/2009/05/conboy_note_window.png
A click on the arrow brings up a not finger friendly menu:
http://zwong.de/wp-content/uploads/2009/05/conboy_toolbar_portrait.png
A click on the delete button brings up a crippled dialog:
http://zwong.de/wp-content/uploads/2009/05/conboy_delete_dialog_portrait.png
The AppMenu looks nice, only the Filters get crippled:
http://zwong.de/wp-content/uploads/2009/05/conboy_style_menu_portrait.png
The search window looks as expected:
http://zwong.de/wp-content/uploads/2009/05/conboy_search_window_portrait.png
I think I did my homework ;) Could now please someone how made the specs
comment on whether this is the expected behavior or not?
Thanks!
Conny
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, May 29, 2009 at 01:22:57PM +0200, Cornelius Hald wrote: The AppMenu looks nice, only the Filters get crippled: http://zwong.de/wp-content/uploads/2009/05/conboy_style_menu_portrait.png This is a bug (already fixed): in portrait, the menu will use the full width of the screen, so in your case I think that these buttons will look fine. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, 2009-05-29 at 13:34 +0200, Alberto Garcia wrote: On Fri, May 29, 2009 at 01:22:57PM +0200, Cornelius Hald wrote: The AppMenu looks nice, only the Filters get crippled: http://zwong.de/wp-content/uploads/2009/05/conboy_style_menu_portrait.png This is a bug (already fixed): in portrait, the menu will use the full width of the screen, so in your case I think that these buttons will look fine. That's good to hear! Thanks :) Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, 2009-05-29 at 13:22 +0200, ext Cornelius Hald wrote: ... After rotating everything looks ok, but when clicking around I realized that only the visual content is rotated. Mouse clicks are still handled like the screen is not rotated at all. For example to close a window I still have to click the top right corner of my Xephyr window instead of the top left corner where the close button is drawn. That would be Xephyr/Xorg bug. The whole point of using XrandR is to get this input event and screen geometry delivery right. BR; Kimmo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, 2009-05-29 at 14:50 +0300, Kimmo Hämäläinen wrote: That would be Xephyr/Xorg bug. The whole point of using XrandR is to get this input event and screen geometry delivery right. I using xserver-xephyr-2:1.6.0-0ubuntu14 which is the ubuntu intrepid version running on ubuntu jaunty. Maybe that's the reason?! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, 2009-05-29 at 13:20 +0200, Alberto Garcia wrote: To detect screen orientation changes you can e.g. use the size-changed signal of GdkScreen. This seems like a rather long-winded way to detect landscape or portrait mode, requiring the hard coding of the dimensions. Surely some simple hildon API would make life easier? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, May 29, 2009 at 09:37:10PM +0200, Murray Cumming wrote: To detect screen orientation changes you can e.g. use the size-changed signal of GdkScreen. This seems like a rather long-winded way to detect landscape or portrait mode, requiring the hard coding of the dimensions. Why do you need the hard coding of the dimensions to know what's the page orientation? Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
Hi, ext Cornelius Hald wrote: as I was asked to write a bit about the fremantle-ization of the Conboy UI, I first would like to ask some more UI specific questions. Then I can complete this process and write about it. * What happens with the AppMenu-Filters when in portrait mode? The HIG tells me that the 2x5 button layout of the AppMenu will change into a 1x10 button layout. But what happens with the single row of Filters? Will it still be a single row? This is important to know, because it would mean that we have to reduce the length of our labels by around 50%. * What happens to toolbars when in portrait mode? Is there some automatic behavior like showing the toolbar as two rows instead of a single row? Is it scaled? Is the space between the buttons reduced? Or do we have to care about this by ourself, for example listen to some signal and then hiding some buttons or rearranging them? * What happens to any other widget when in portrait mode? * Is there a signal which signals that the screen orientation changed? Application needs to specifically request portrait mode with a window property (I guess there's some API for that), otherwise window manager uses landscape mode for the application window. App can listen to standard XRandr messages for this transition if it wants to, but it's not necessary. * Is there a function to change the screen orientation and can we somehow use this with the beta SDK? It's just a question whether your distro's Xephyr version has XRandR enabled. It should. Then just use xrandr -o left/right/normal for Xephyr's display. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
