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

Reply via email to