Re: Ideal screen rotation
2009/11/23 Neil Jerram neiljer...@googlemail.com: FWIW, as well as the discussed rotation support, I'd also like to - add a GPRS/PDP toggle to the GSM gadget - add a fast charge menu to the battery gadget - fix the battery gadget so that it it goes up to 100%. Just in case anyone is waiting for these, I should say that I have changed tack now and am no longer working on these points. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
2009/11/23 Neil Jerram neiljer...@googlemail.com: 2009/11/23 Neil Jerram neiljer...@googlemail.com: For now, just to get the code out, I've created a project at gitorious: http://gitorious.org/enlightenment-for-openmoko-freerunner. For anyone who may take a look, I should say that there are still 2 big pieces missing: - Being notified somehow when the currently focussed app changes, and what that app's properties are, and checking those props against some config somewhere, to find out the app's rotation preference. Is there a place in the Illume code where I can catch every time that the current foreground thing changes? My best guess so far is the BORDER_FOCUS_IN event, but this misses at least two cases: 1. Switching back to the Illume launcher - which it appears doesn't count as an E_Border. 2. An app (like Mokomaze) that starts up in full screen. Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Mon, 23 Nov 2009 21:06:30 + Rui Miguel Silva Seabra r...@1407.org said: On Mon, Nov 23, 2009 at 07:26:57PM +, Neil Jerram wrote: 2009/11/7 Neil Jerram neiljer...@googlemail.com: Thanks. I think I'll look at adding this into the e17 WM. I have some code ready to share now. What would be the best way to do that - bearing in mind that the aim is to facilitate contributions and new packages for the Freerunner? If the E project is still interested in illume changes, I guess I could send changes there. But if illume isn't of ongoing interest now, maybe some Debian or SHR repository would be better, or maybe I should set up a new repository somewhere? FWIW, as well as the discussed rotation support, I'd also like to - add a GPRS/PDP toggle to the GSM gadget - add a fast charge menu to the battery gadget - fix the battery gadget so that it it goes up to 100%. So I think there's a strong case for an ongoing FR-focussed e17/illume codebase. There's an illume2 project at enlightenment, perhaps a good spot for it? It has seen some action recently, perhaps thanks to Samsung's sponsoring? who knows... but... contributions are welcome. like always - they may be accepted ax-is or punted back to the contributor with fixme's or just patched and fixed anyway... it depends on the content. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
2009/11/7 Neil Jerram neiljer...@googlemail.com: Thanks. I think I'll look at adding this into the e17 WM. I have some code ready to share now. What would be the best way to do that - bearing in mind that the aim is to facilitate contributions and new packages for the Freerunner? If the E project is still interested in illume changes, I guess I could send changes there. But if illume isn't of ongoing interest now, maybe some Debian or SHR repository would be better, or maybe I should set up a new repository somewhere? FWIW, as well as the discussed rotation support, I'd also like to - add a GPRS/PDP toggle to the GSM gadget - add a fast charge menu to the battery gadget - fix the battery gadget so that it it goes up to 100%. So I think there's a strong case for an ongoing FR-focussed e17/illume codebase. Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Mon, Nov 23, 2009 at 07:26:57PM +, Neil Jerram wrote: 2009/11/7 Neil Jerram neiljer...@googlemail.com: Thanks. I think I'll look at adding this into the e17 WM. I have some code ready to share now. What would be the best way to do that - bearing in mind that the aim is to facilitate contributions and new packages for the Freerunner? If the E project is still interested in illume changes, I guess I could send changes there. But if illume isn't of ongoing interest now, maybe some Debian or SHR repository would be better, or maybe I should set up a new repository somewhere? FWIW, as well as the discussed rotation support, I'd also like to - add a GPRS/PDP toggle to the GSM gadget - add a fast charge menu to the battery gadget - fix the battery gadget so that it it goes up to 100%. So I think there's a strong case for an ongoing FR-focussed e17/illume codebase. There's an illume2 project at enlightenment, perhaps a good spot for it? It has seen some action recently, perhaps thanks to Samsung's sponsoring? Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
2009/11/23 Rui Miguel Silva Seabra r...@1407.org: There's an illume2 project at enlightenment, perhaps a good spot for it? It has seen some action recently, perhaps thanks to Samsung's sponsoring? Yes, but I imagine that could be pretty unstable in the short term. For now, just to get the code out, I've created a project at gitorious: http://gitorious.org/enlightenment-for-openmoko-freerunner. Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
2009/11/23 Neil Jerram neiljer...@googlemail.com: For now, just to get the code out, I've created a project at gitorious: http://gitorious.org/enlightenment-for-openmoko-freerunner. For anyone who may take a look, I should say that there are still 2 big pieces missing: - Being notified somehow when the currently focussed app changes, and what that app's properties are, and checking those props against some config somewhere, to find out the app's rotation preference. - Updating that config when App must be portrait or ... landscape is selected for the current app. One other idea... I thought that implementing FLIP_X and/or FLIP_Y might be useful, because - in a car - it would allow using the FR in a head up display fashion. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
FWIW, as well as the discussed rotation support, I'd also like to - add a GPRS/PDP toggle to the GSM gadget - add a fast charge menu to the battery gadget - fix the battery gadget so that it it goes up to 100%. This sounds great and needed. Communication with SHR devs might be useful to get it to SHR soon. So I think there's a strong case for an ongoing FR-focussed e17/illume codebase. There's an illume2 project at enlightenment, perhaps a good spot for it? At this point, i would not focus on it, plus, i would expect that the gadgets should still work correctly in Illume2? just my 2c Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Tue, Nov 10, 2009 at 12:00:31AM +, Dave Ball wrote: Carsten Haitzler (The Rasterman) wrote: wm needs to track both and determine which one takes precedence based on policy and th en implement that rotation, if needed. policy is what a wm implements - that's the nature of the beast. that policy may be hard-coded in the wm or configuration for it. I've been looking at existing window properties [1] to try and understand the best way to do this. option1: New atoms in the _NET_WM_STATE property. - _NET_WM_STATE_LANDSCAPE - _NET_WM_STATE_PORTRAIT If neither is present for a given window, WM can choose (based on the accelerometers). Both present is an error - or could be defined as leave the window in it's current orientation. option2: New property. _NET_WM_ORIENTATION 0 = Either / WM decides 1 = Landscape 2 = Portrait There are two landscape positions and 2 portrait positions :) Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Rui Miguel Silva Seabra wrote: On Tue, Nov 10, 2009 at 12:00:31AM +, Dave Ball wrote: option1: New atoms in the _NET_WM_STATE property. - _NET_WM_STATE_LANDSCAPE - _NET_WM_STATE_PORTRAIT If neither is present for a given window, WM can choose (based on the accelerometers). Both present is an error - or could be defined as leave the window in it's current orientation. option2: New property. _NET_WM_ORIENTATION 0 = Either / WM decides 1 = Landscape 2 = Portrait There are two landscape positions and 2 portrait positions :) Doh - of course! Which would lead to: _NET_WM_STATE_ORIENTATION_LANDSCAPE _NET_WM_STATE_ORIENTATION_PORTRAIT _NET_WM_STATE_ORIENTATION_INVERTED or _NET_WM_ORIENTATION 0 = Either / WM decides 1 = Landscape 2 = Portrait 3 = Landscape inverted 4 = Portrait inverted However, what's the use-case for an application requesting either of the inverted states? I can't see when those would be useful - in terms of hints the app would supply. Obviously, if the WM was deciding orientation based on the device position, you would correctly rotate to the inverted states, but if an application is built for portrait or landscape is there any reason a developer would not want the normal portrait/landscape orientation for the device? Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
perhaps the landscape / portrait flag should just contrain the rotation? So if you flip the phone 180 degrees, you get the 'expected' behaviour, but if you just flip it 90 degrees nothing changes? Warren On Tue, Nov 10, 2009 at 7:08 AM, Dave Ball openm...@underhand.org wrote: Rui Miguel Silva Seabra wrote: On Tue, Nov 10, 2009 at 12:00:31AM +, Dave Ball wrote: option1: New atoms in the _NET_WM_STATE property. - _NET_WM_STATE_LANDSCAPE - _NET_WM_STATE_PORTRAIT If neither is present for a given window, WM can choose (based on the accelerometers). Both present is an error - or could be defined as leave the window in it's current orientation. option2: New property. _NET_WM_ORIENTATION 0 = Either / WM decides 1 = Landscape 2 = Portrait There are two landscape positions and 2 portrait positions :) Doh - of course! Which would lead to: _NET_WM_STATE_ORIENTATION_LANDSCAPE _NET_WM_STATE_ORIENTATION_PORTRAIT _NET_WM_STATE_ORIENTATION_INVERTED or _NET_WM_ORIENTATION 0 = Either / WM decides 1 = Landscape 2 = Portrait 3 = Landscape inverted 4 = Portrait inverted However, what's the use-case for an application requesting either of the inverted states? I can't see when those would be useful - in terms of hints the app would supply. Obviously, if the WM was deciding orientation based on the device position, you would correctly rotate to the inverted states, but if an application is built for portrait or landscape is there any reason a developer would not want the normal portrait/landscape orientation for the device? Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Warren Baird wrote: perhaps the landscape / portrait flag should just contrain the rotation? So if you flip the phone 180 degrees, you get the 'expected' behaviour, but if you just flip it 90 degrees nothing changes? Given that these properties are for the orientation an application requests (to the WM) should ideally be used, I'm not sure how the actual rotation would help? Working from rotation would also complicate the behaviour on devices that are normally landscape - such as the Nokia N900. What I'm suggesting is that the application just says landscape or portrait, and then the WM would decide the most appropriate way to orient the screen for that device. If an application doesn't request either landscape or portrait, then the WM would rotate the screen according to the device orientation, through each of the positions the device could be held (including inverted). So the WM definitely needs to know the actual orientation of the device (such as from the FSO api), but I think the application itself only needs to request Landscape, Portrait or neither. Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Tue, Nov 10, 2009 at 12:08:06PM +, Dave Ball wrote: Rui Miguel Silva Seabra wrote: On Tue, Nov 10, 2009 at 12:00:31AM +, Dave Ball wrote: option1: New atoms in the _NET_WM_STATE property. - _NET_WM_STATE_LANDSCAPE - _NET_WM_STATE_PORTRAIT If neither is present for a given window, WM can choose (based on the accelerometers). Both present is an error - or could be defined as leave the window in it's current orientation. option2: New property. _NET_WM_ORIENTATION 0 = Either / WM decides 1 = Landscape 2 = Portrait There are two landscape positions and 2 portrait positions :) Doh - of course! Which would lead to: _NET_WM_STATE_ORIENTATION_LANDSCAPE _NET_WM_STATE_ORIENTATION_PORTRAIT _NET_WM_STATE_ORIENTATION_INVERTED or _NET_WM_ORIENTATION 0 = Either / WM decides 1 = Landscape 2 = Portrait 3 = Landscape inverted 4 = Portrait inverted However, what's the use-case for an application requesting either of the inverted states? I can't see when those would be useful - in terms of hints the app would supply. Obviously, if the WM was deciding orientation based on the device position, you would correctly rotate to the inverted states, but if an application is built for portrait or landscape is there any reason a developer would not want the normal portrait/landscape orientation for the device? Yes, certain devices may be better prepared (in terms of connectivity for power, usb, etc...) for one kind of landscape rather than the other. Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Rui Miguel Silva Seabra wrote: On Tue, Nov 10, 2009 at 12:08:06PM +, Dave Ball wrote: However, what's the use-case for an application requesting either of the inverted states? I can't see when those would be useful - in terms of hints the app would supply. Obviously, if the WM was deciding orientation based on the device position, you would correctly rotate to the inverted states, but if an application is built for portrait or landscape is there any reason a developer would not want the normal portrait/landscape orientation for the device? Yes, certain devices may be better prepared (in terms of connectivity for power, usb, etc...) for one kind of landscape rather than the other. Yup - although that would be at the device level rather than the application level. If the WM knows what the device's policy is, I can't see a situation where one app wants to be in landscape, and a different app wants to be in landscape inverted on the same device? Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
I meant that it should *constrain* the behaviour of rotation - more or less like omnewrotate behaves now, but skipping over the two 'incorrect' orientations. so if the app says 'landscape', it's still flip between xrandr -o 1 and xrandr -o 3 as you rotate the phone, but won't flip to xrandr -o 0 or xrandr -o 2. I don't think it will normally makes sense for an application to specficially request 'xrandr -o 3' - they will usually just want to be sure that they are displayed in portrait or landscape mode. I've been using epdfview a lot lately, and I'd love to be able to constrain it to only show up in landscape mode... Warren On Tue, Nov 10, 2009 at 11:11 AM, Dave Ball openm...@underhand.org wrote: Warren Baird wrote: perhaps the landscape / portrait flag should just contrain the rotation? So if you flip the phone 180 degrees, you get the 'expected' behaviour, but if you just flip it 90 degrees nothing changes? Given that these properties are for the orientation an application requests (to the WM) should ideally be used, I'm not sure how the actual rotation would help? Working from rotation would also complicate the behaviour on devices that are normally landscape - such as the Nokia N900. What I'm suggesting is that the application just says landscape or portrait, and then the WM would decide the most appropriate way to orient the screen for that device. If an application doesn't request either landscape or portrait, then the WM would rotate the screen according to the device orientation, through each of the positions the device could be held (including inverted). So the WM definitely needs to know the actual orientation of the device (such as from the FSO api), but I think the application itself only needs to request Landscape, Portrait or neither. Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Tue, Nov 10, 2009 at 05:15:54PM +, Dave Ball wrote: Rui Miguel Silva Seabra wrote: On Tue, Nov 10, 2009 at 12:08:06PM +, Dave Ball wrote: However, what's the use-case for an application requesting either of the inverted states? I can't see when those would be useful - in terms of hints the app would supply. Obviously, if the WM was deciding orientation based on the device position, you would correctly rotate to the inverted states, but if an application is built for portrait or landscape is there any reason a developer would not want the normal portrait/landscape orientation for the device? Yes, certain devices may be better prepared (in terms of connectivity for power, usb, etc...) for one kind of landscape rather than the other. Yup - although that would be at the device level rather than the application level. If the WM knows what the device's policy is, I can't see a situation where one app wants to be in landscape, and a different app wants to be in landscape inverted on the same device? If you want to standardize something, better be prepared for uses such as a device. For some reason xrandr allows different options rathen than just 3. 0 == normal 1 == turned left 2 == normal inverted 3 == turned right Now... on my laptop, landscape == 0 or 2, but on the Free Runner landscape = 1 or 3 Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Warren Baird wrote: I meant that it should *constrain* the behaviour of rotation - more or less like omnewrotate behaves now, but skipping over the two 'incorrect' orientations. so if the app says 'landscape', it's still flip between xrandr -o 1 and xrandr -o 3 as you rotate the phone, but won't flip to xrandr -o 0 or xrandr -o 2. I don't think it will normally makes sense for an application to specficially request 'xrandr -o 3' - they will usually just want to be sure that they are displayed in portrait or landscape mode. ok, we can make that a policy decision in the WM, but the app only needs to specify portrait or landscape. Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
If you want to standardize something, better be prepared for uses such as a device. For some reason xrandr allows different options rathen than just 3. 0 == normal 1 == turned left 2 == normal inverted 3 == turned right Now... on my laptop, landscape == 0 or 2, but on the Free Runner landscape = 1 or 3 in my oppinion this is quite simple and contrary to carsten, i say: landscape := more broad than high portrait := more high than broad ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
2009/11/10 Warren Baird wjba...@alumni.uwaterloo.ca: I meant that it should *constrain* the behaviour of rotation - more or less like omnewrotate behaves now, but skipping over the two 'incorrect' orientations. so if the app says 'landscape', it's still flip between xrandr -o 1 and xrandr -o 3 as you rotate the phone, but won't flip to xrandr -o 0 or xrandr -o 2. I don't think it will normally makes sense for an application to specficially request 'xrandr -o 3' - they will usually just want to be sure that they are displayed in portrait or landscape mode. This subtlety hadn't occurred to me before, but I actually have a use case for it! I have an in-car phone holder that happens to work better with the phone upside down, so that the USB connection can be on the left. So yes, it would be better if a prefers-portrait app (like tangogps) could be shown in either -o 0 or -o 2, depending on actual phone position. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Tue, 10 Nov 2009 16:11:40 + Dave Ball openm...@underhand.org said: Warren Baird wrote: perhaps the landscape / portrait flag should just contrain the rotation? So if you flip the phone 180 degrees, you get the 'expected' behaviour, but if you just flip it 90 degrees nothing changes? Given that these properties are for the orientation an application requests (to the WM) should ideally be used, I'm not sure how the actual rotation would help? Working from rotation would also complicate the behaviour on devices that are normally landscape - such as the Nokia N900. What I'm suggesting is that the application just says landscape or portrait, and then the WM would decide the most appropriate way to orient the screen for that device. If an application doesn't request either landscape or portrait, then the WM would rotate the screen according to the device orientation, through each of the positions the device could be held (including inverted). So the WM definitely needs to know the actual orientation of the device (such as from the FSO api), but I think the application itself only needs to request Landscape, Portrait or neither. you want a bitmask for 4 rotations as well as flips. why? because this is what xrandr supports. you want to give a mask for which rotations the app wants why do u need both 90 and 270 degrees for example? look at a g1. u slide kbd open to one side of the screen. now imaging if u slid the screen the other way you have a different button set along the other side. eg a set of psp-style game-pad controllers for games. so games would request 270 and aps rthat are built for text input with hw kbd are 90. etc. etc. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Rui Miguel Silva Seabra wrote: On Fri, Nov 06, 2009 at 04:40:04PM +0100, Helge Hafting wrote: But there is a problem. The user may switch between several apps with different rotation needs. (xmahjongg needs landscape, tetris needs portrait, ...) How will omnewrotate be notified about this? The proper way is to define a set of DBUS signals. Of course conflicting signals need to be ignored. What conflicting signals? A proper implementation won't have conflicts? The normal freerunner usage is to maximize the foreground app, so there is only one app that need its rotation preference obeyed at any time. The user may run both some portrait apps, some landscape apps, and some don't care at all apps and some use the accelerometer orientation apps all at the same time. All of them can state their preferences, only one need to be obeyed at any time. So, when the user uses the arrows to flip form app to app, the orientation stays the same if a don't care app is selected, or some app that wants the current orientation. If an app with a different orientation is selected, the display should change _before_ the new app gets painted. It is a huge waste of time if the app first shows in the wrong orientation, and then quickly changes. (Or if the previous app is repainted in the new orientation before the new app is brought to the surface.) There are no conflicts, but whatever software you have managing the display must be able to change orientation at exactly the right moment. Merely setting the orientation when an app is launched (like we do for backlight) is no good - the user can switch apps at any time. Good orientation management must therefore be a part of the app switching mechanism. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Mon, Nov 09, 2009 at 01:28:48PM +0100, Helge Hafting wrote: But there is a problem. The user may switch between several apps with different rotation needs. (xmahjongg needs landscape, tetris needs portrait, ...) How will omnewrotate be notified about this? The proper way is to define a set of DBUS signals. Of course conflicting signals need to be ignored. What conflicting signals? A proper implementation won't have conflicts? app1 prefers landscape1 app2 prefers landscape2 app3 prefers portrait1 In such a system, while app1 will have to prevail and the others will have to wait. (...) There are no conflicts, but whatever software you have managing the display must be able to change orientation at exactly the right moment. Of course you see, then, that rotation is a job best served by the Window Manager, yes? :) Daemons that rotate the screen (like my omnewrotate) are simpler hacks... Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Mon, 9 Nov 2009 15:49:24 + Rui Miguel Silva Seabra r...@1407.org said: On Mon, Nov 09, 2009 at 01:28:48PM +0100, Helge Hafting wrote: But there is a problem. The user may switch between several apps with different rotation needs. (xmahjongg needs landscape, tetris needs portrait, ...) How will omnewrotate be notified about this? The proper way is to define a set of DBUS signals. Of course conflicting signals need to be ignored. What conflicting signals? A proper implementation won't have conflicts? app1 prefers landscape1 app2 prefers landscape2 app3 prefers portrait1 thats why i said 1. put it as properties on a window (you now know precisely which windows want what - or dont care - 1 app can create more than 1 window remember) 2. the wm knows which windows are around doign what and their properties. it can decide what to do. :) In such a system, while app1 will have to prevail and the others will have to wait. (...) There are no conflicts, but whatever software you have managing the display must be able to change orientation at exactly the right moment. Of course you see, then, that rotation is a job best served by the Window Manager, yes? :) Daemons that rotate the screen (like my omnewrotate) are simpler hacks... Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Carsten Haitzler (The Rasterman) wrote: wm needs to track both and determine which one takes precedence based on policy and th en implement that rotation, if needed. policy is what a wm implements - that's the nature of the beast. that policy may be hard-coded in the wm or configuration for it. I've been looking at existing window properties [1] to try and understand the best way to do this. option1: New atoms in the _NET_WM_STATE property. - _NET_WM_STATE_LANDSCAPE - _NET_WM_STATE_PORTRAIT If neither is present for a given window, WM can choose (based on the accelerometers). Both present is an error - or could be defined as leave the window in it's current orientation. option2: New property. _NET_WM_ORIENTATION 0 = Either / WM decides 1 = Landscape 2 = Portrait Thoughts? http://www.youtube.com/watch?v=abNsVyYTSkU OT - but I'm struggling with e's xnest.sh script: xhost + su newuser Xnest -ac :1 env DISPLAY=:1 enlightenment_start works, but: xhost + su newuser /data/programming/e17/e17_src/e/xnest.sh doesn't. Initially it ran through e's firstrun wizard in an xnest, then crashed - now it dies on start. I've attached the xnest.sh output - any ideas? Dave [1] http://standards.freedesktop.org/wm-spec/1.4/ar01s05.html newu...@dougal:/data/programming/e17/logo-0.0.1$ /data/programming/e17/e17_src/e/xnest.sh [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! (EE) config/hal: NewInputDeviceRequest failed (2) (EE) config/hal: NewInputDeviceRequest failed (2) (EE) config/hal: NewInputDeviceRequest failed (2) (EE) config/hal: NewInputDeviceRequest failed (2) (EE) config/hal: NewInputDeviceRequest failed (2) (EE) config/hal: NewInputDeviceRequest failed (2) GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu... [Thread debugging using libthread_db enabled] ESTART: 0.0 [0.0] - begin ESTART: 0.00010 [0.00010] - signals done ESTART: 0.00014 [0.4] - determine prefix DYNAMIC DETERMINED PREFIX: /opt/e17 ESTART: 0.00034 [0.00020] - prefix done ESTART: 0.00037 [0.3] - eina init [New Thread 0x7f440ce2c710 (LWP 25665)] ESTART: 0.01835 [0.01798] - intl init ESTART: 0.01840 [0.5] - parse args ESTART: 0.01841 [0.1] - arg parse done ESTART: 0.01845 [0.3] - ecore init ESTART: 0.02113 [0.00268] - ecore_file init ESTART: 0.02128 [0.00015] - more ecore ESTART: 0.02129 [0.1] - x connect Xlib: extension DPMS missing on display :1.0. Xlib: extension RANDR missing on display :1.0. ESTART: 0.02402 [0.00273] - ecore_con ESTART: 0.02432 [0.00030] - xinerama E17 INIT: XINERAMA CHOSEN: [0], 1080x675+0+0 ESTART: 0.02665 [0.00233] - x hints ESTART: 0.02702 [0.00037] - x hints done ESTART: 0.02703 [0.1] - ecore_evas init ESTART: 0.02715 [0.00012] - test done ESTART: 0.02716 [0.1] - efreet ESTART: 0.02731 [0.00015] - efreet done ESTART: 0.02732 [0.1] - configure ESTART: 0.02738 [0.6] - dirs ESTART: 0.02746 [0.8] - filereg ESTART: 0.02747 [0.1] - config ESTART: 0.02906 [0.00159] - scale ESTART: 0.02915 [0.8] - pointer ESTART: 0.02916 [0.2] - path ESTART: 0.02922 [0.6] - ipc INFO: E_IPC_SOCKET=/tmp/enlightenment-system/disp-:1.0-25665 ESTART: 0.02954 [0.00031] - font ESTART: 0.02957 [0.4] - theme ESTART: 0.03629 [0.00672] - intl post ESTART: 0.04364 [0.00735] - move/resize info ESTART: 0.04374 [0.9] - splash RUN INIT: /opt/e17/lib/enlightenment/utils/enlightenment_init '/opt/e17/share/enlightenment/data/themes/default.edj' '1' '0' 'Enlightenment' '0.16.999.062' Xlib: extension DPMS missing on display :1.0. Xlib: extension RANDR missing on display :1.0. E17 INIT: XINERAMA CHOSEN: [0], 1080x675+0+0 Program received signal SIGUSR2, User defined signal 2. [Switching to Thread 0x7f440ce2c710 (LWP 25665)] 0x7f4407b0e8b0 in __pause_nocancel () from /lib/libpthread.so.0 #0 0x7f4407b0e8b0 in __pause_nocancel () from /lib/libpthread.so.0 #1 0x0042e626 in main () The program is running. Exit anyway? (y or n) [answered Y; input not from terminal] newu...@dougal:/data/programming/e17/logo-0.0.1$ [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! (EE) XKB: No components provided for device Virtual core keyboard ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
in my oppinion, it is not necessary, because one has all needed information already in -- man XSizeHints if a window says, for exampe 800x600, and says maybe in the aspect ratios 4:3, the rotation preference is quite clear, i think. 800x600 doesn;'t even fit. its a minimum size. it's not sane to use such a property as this doesn't tell you the original rotation - just a size. you are overloading a property here that isn't meant for this information. ther's also a window aspect ratio property - again, this isn't rotation. a wm may interpret this by scrolling the window around, not rotating. or just make the window smaller if it likes it or not (eg what e and matchbox do for example). can you give us a hint where this (rotation) property can be found ? perhaps hint on manual page ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Am Sonntag, den 08.11.2009, 14:39 +1100 schrieb Carsten Haitzler: so to me - it makes perfect sense for such a desired state to be put into the x domain entirely as the property is related directly to the display/screen. gsm makes no sense being properties/events of x11. neither does wifi, or bt but brightness of screen, current abient lighting sensor data, etc. makes sense. as such x also covers input devices (kbd, mouse), thus anything you can deem to be an input device (touchscreen, buttons on the device, accelerometrs etc.) makes sense to put via x11, not dbus. its within the logical domain for its functionality. In the light of more versatile use I prefer this to be via dbus, but I'd absolutely welcome an fsodeviced plugin that sets an atom on the root window. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Carsten Haitzler (The Rasterman) wrote: On Sun, 08 Nov 2009 04:37:07 + Dave Ball openm...@underhand.org said: Is there a quick-start guide for writing an e module, maybe some simple code / example? http://www.rasterman.com/files/logo-0.0.1.tar.gz http://www.youtube.com/watch?v=abNsVyYTSkU Heh - Thanks! That's pretty comprehensive and cool - now if only youtube would let me step frame-by-frame! :-) Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sun, 08 Nov 2009 09:48:23 +0100 Matthias Huber matthias.hu...@wollishausen.de said: in my oppinion, it is not necessary, because one has all needed information already in -- man XSizeHints if a window says, for exampe 800x600, and says maybe in the aspect ratios 4:3, the rotation preference is quite clear, i think. 800x600 doesn;'t even fit. its a minimum size. it's not sane to use such a property as this doesn't tell you the original rotation - just a size. you are overloading a property here that isn't meant for this information. ther's also a window aspect ratio property - again, this isn't rotation. a wm may interpret this by scrolling the window around, not rotating. or just make the window smaller if it likes it or not (eg what e and matchbox do for example). can you give us a hint where this (rotation) property can be found ? perhaps hint on manual page ? see my other mails. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On 11/8/09, Carsten Haitzler ras...@rasterman.com wrote: 1. omnewroatte ONLY listens to accelerometers and talks to the wm (via any mechanism you like) telling it what position the phone is in. that is all it does. nothing else. all other decisions are made by the wm base on as you said above, the properties of the window - which app is currently active (change apps between one that wants to be portrait wants to be landscape, the wm has to flip orientation when you flip apps. etc. for example - e already has a config dialog for changing screen resoltion and rotation. it already handles this stuff - it's missing the logic of reading some as-yet-uninvented property from a window and 2. handling that property with respect to rotation. any wm can do this. this is definitely a job that belongs in properties of a window and the wm to read them, follow their changes, and do the right thing) Then there is no need for omnewrotate, as fsodeviced is already doing exactly that via dbus. -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
2009/11/7 Carsten Haitzler ras...@rasterman.com: no. the proper way is to set properties on your window. How exactly does that (setting a property) happen though? Is it something that the app would normally do in its own startup code? (I presume yes.) For apps that don't already do this - and which we'd ideally like to support without having to modify them all - is there a way that a proxy could do it for them? Also do you know if there's already a well-known window property for preferred rotation, or would we be inventing a new one? Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, Nov 07, 2009 at 11:49:18AM +1100, Carsten Haitzler wrote: On Fri, 6 Nov 2009 20:24:13 + Neil Jerram neiljer...@googlemail.com said: 2009/11/6 Rui Miguel Silva Seabra r...@1407.org: On Fri, Nov 06, 2009 at 04:40:04PM +0100, Helge Hafting wrote: Well, you cannot expect every app to have such preferences, this device runs generic linux apps that aren't made specially for the freerunner. Now, of course the app loader can do this, similiar to how we already request the cpu/backlight when launching some apps. But there is a problem. The user may switch between several apps with different rotation needs. (xmahjongg needs landscape, tetris needs portrait, ...) How will omnewrotate be notified about this? The proper way is to define a set of DBUS signals. Thanks to everyone for your replies on this topic. I agree with Helge, in that I don't think DBUS is a good solution, because I really want a solution that works for existing apps. I suppose for existing apps there could be a DBUS proxy that somehow works out the best orientation and then sends a DBUS signal on the app's behalf. But that seems complicated. Also I'm not sure why DBUS helps at all. Once a program somewhere has worked out the best orientation, why not just call xrandr directly? Another thought that occurred to me is that if this was a window manager responsibility, perhaps the window manager could infer preferred orientation simply from the requested window size? (i.e. requesting width height implies a preference for landscape). That should often work for apps that were designed for the desktop. I would guess that apps written for the FR might not request specific sizes, because they'd know that they will always be fullscreen anyway - so for those apps some explicit configuration would be needed somewhere (prefer-portrait, prefer-landscape, or auto-rotate). repeating... property on window. the rotation preferences are a property of a window - like min and max size are, its title, etc. etc. - stick it on the window. ignore dbus. this is not something you do by dbus. if something is related to the display - especially something is related to your window, your domain for advertising state, information, making requests and getting replies is the x11 domain as long as you are using x11. :) I'm definitely not following you... I envision the following scenario according to what you say, could you please elaborate on why it wouldn't happen this way? 1. App wants to be landscape, sets property on window 2. rotator determines the phone is in portrait, rotates. Now what happens? 3. App is landscape, but screen is portrait: fail or 3. Window manager overrides rotation 3.1 but rotator determines portrait, rotates again 3.2 go to 3: fail Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Fri, Nov 06, 2009 at 08:24:13PM +, Neil Jerram wrote: 2009/11/6 Rui Miguel Silva Seabra r...@1407.org: On Fri, Nov 06, 2009 at 04:40:04PM +0100, Helge Hafting wrote: Well, you cannot expect every app to have such preferences, this device runs generic linux apps that aren't made specially for the freerunner. Now, of course the app loader can do this, similiar to how we already request the cpu/backlight when launching some apps. But there is a problem. The user may switch between several apps with different rotation needs. (xmahjongg needs landscape, tetris needs portrait, ...) How will omnewrotate be notified about this? The proper way is to define a set of DBUS signals. Thanks to everyone for your replies on this topic. I agree with Helge, in that I don't think DBUS is a good solution, because I really want a solution that works for existing apps. You have no solution for existing apps other than causing a full stop on rotation once you get the desired rotation (which is what I do for apps that work better on landscape). I suppose for existing apps there could be a DBUS proxy that somehow works out the best orientation and then sends a DBUS signal on the app's behalf. But that seems complicated. Not smart either, because you'd have a buttload of work for little gain, and there will always be one more app which isn't supported yet, etc... Also I'm not sure why DBUS helps at all. Once a program somewhere has worked out the best orientation, why not just call xrandr directly? DBUS helps a lot because you can define a standard set of signals: 1. screen rotation apps could listen for specific screen rotation signals 2. apps which have specific needs can broadcast said needs to DBUS This means minimal aditional work for everyone. Another thought that occurred to me is that if this was a window manager responsibility, perhaps the window manager could infer preferred orientation simply from the requested window size? (i.e. requesting width height implies a preference for landscape). The only way this could be the window manager's job, was if the window manager had auto-rotation routings. AFAICT, E doesn't yet. Of course rotator apps only come up because people feel the need and writing a simple daemon is simpler than patching a quite evolved window manager. That should often work for apps that were designed for the desktop. I would guess that apps written for the FR might not request specific sizes, because they'd know that they will always be fullscreen anyway - so for those apps some explicit configuration would be needed somewhere (prefer-portrait, prefer-landscape, or auto-rotate). So rotators would need to parse all the configurations? I still think DBUS is the way to do it well, but I'm open for proof otherwise. Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 10:20:37 + Rui Miguel Silva Seabra r...@1407.org said: On Fri, Nov 06, 2009 at 08:24:13PM +, Neil Jerram wrote: 2009/11/6 Rui Miguel Silva Seabra r...@1407.org: On Fri, Nov 06, 2009 at 04:40:04PM +0100, Helge Hafting wrote: Well, you cannot expect every app to have such preferences, this device runs generic linux apps that aren't made specially for the freerunner. Now, of course the app loader can do this, similiar to how we already request the cpu/backlight when launching some apps. But there is a problem. The user may switch between several apps with different rotation needs. (xmahjongg needs landscape, tetris needs portrait, ...) How will omnewrotate be notified about this? The proper way is to define a set of DBUS signals. Thanks to everyone for your replies on this topic. I agree with Helge, in that I don't think DBUS is a good solution, because I really want a solution that works for existing apps. You have no solution for existing apps other than causing a full stop on rotation once you get the desired rotation (which is what I do for apps that work better on landscape). I suppose for existing apps there could be a DBUS proxy that somehow works out the best orientation and then sends a DBUS signal on the app's behalf. But that seems complicated. Not smart either, because you'd have a buttload of work for little gain, and there will always be one more app which isn't supported yet, etc... Also I'm not sure why DBUS helps at all. Once a program somewhere has worked out the best orientation, why not just call xrandr directly? DBUS helps a lot because you can define a standard set of signals: 1. screen rotation apps could listen for specific screen rotation signals 2. apps which have specific needs can broadcast said needs to DBUS This means minimal aditional work for everyone. Another thought that occurred to me is that if this was a window manager responsibility, perhaps the window manager could infer preferred orientation simply from the requested window size? (i.e. requesting width height implies a preference for landscape). The only way this could be the window manager's job, was if the window manager had auto-rotation routings. AFAICT, E doesn't yet. the wm is who knows the properties of all windows - and knows which one(s) are active. it is by far ion the best position to make a decision. a stand-alone rotator is asking for trouble. it will be hell as any app can just ask for whatever rotation they want irrespective if they are active or not. it's everyone fighting over a single resource. the right place for this is as properties of a window and part of the windowing system setup - thus a matter between apps and the wm. Of course rotator apps only come up because people feel the need and writing a simple daemon is simpler than patching a quite evolved window manager. actually it's much more work doing a stand-alone rotator. That should often work for apps that were designed for the desktop. I would guess that apps written for the FR might not request specific sizes, because they'd know that they will always be fullscreen anyway - so for those apps some explicit configuration would be needed somewhere (prefer-portrait, prefer-landscape, or auto-rotate). So rotators would need to parse all the configurations? I still think DBUS is the way to do it well, but I'm open for proof otherwise. dbus is by far and wide NOT the way to do it. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 08:33:35 + Neil Jerram neiljer...@googlemail.com said: 2009/11/7 Carsten Haitzler ras...@rasterman.com: no. the proper way is to set properties on your window. How exactly does that (setting a property) happen though? Is it how does setting the title? or the min/max size of the window happen? the name and class, window role, if its a dialog, transient for which window, if the app would like it to be borderless... all of these are properties. try xprop and clikc on a window. any window (freerunner or desktop - doesn't matter). THOSE are properties. you can add/create/define any properties you like. they hang onto the window until they are modified or deleted or the window is deleted. something that the app would normally do in its own startup code? (I yes. see above. apps are doing it all the time. it's about the most standard way to provide information about your window, from title to minimum and maximum size to aspect ratios and more. rotation preferences are just yet more properties like this. if its a property of the window - put it as a property of the window. use the mechanism created for precisely this kind of thing. dbus is not that mechanism. presume yes.) For apps that don't already do this - and which we'd ideally like to support without having to modify them all - is there a way that a proxy could do it for them? if an app has rotation preferences, it should set them. if it has none - it gets whatever the screen has right now - or whatever the wm chooses to implement as policy. yes - you modify apps to have them indicate their preferences. otherwise they are deemed to not care which is the case now, for example. you modify the apps - thats the right way to do it. you don't post-mortem find a way to hack things in. :) Also do you know if there's already a well-known window property for preferred rotation, or would we be inventing a new one? you'd be inventing it. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 10:14:34 + Rui Miguel Silva Seabra r...@1407.org said: On Sat, Nov 07, 2009 at 11:49:18AM +1100, Carsten Haitzler wrote: On Fri, 6 Nov 2009 20:24:13 + Neil Jerram neiljer...@googlemail.com said: 2009/11/6 Rui Miguel Silva Seabra r...@1407.org: On Fri, Nov 06, 2009 at 04:40:04PM +0100, Helge Hafting wrote: Well, you cannot expect every app to have such preferences, this device runs generic linux apps that aren't made specially for the freerunner. Now, of course the app loader can do this, similiar to how we already request the cpu/backlight when launching some apps. But there is a problem. The user may switch between several apps with different rotation needs. (xmahjongg needs landscape, tetris needs portrait, ...) How will omnewrotate be notified about this? The proper way is to define a set of DBUS signals. Thanks to everyone for your replies on this topic. I agree with Helge, in that I don't think DBUS is a good solution, because I really want a solution that works for existing apps. I suppose for existing apps there could be a DBUS proxy that somehow works out the best orientation and then sends a DBUS signal on the app's behalf. But that seems complicated. Also I'm not sure why DBUS helps at all. Once a program somewhere has worked out the best orientation, why not just call xrandr directly? Another thought that occurred to me is that if this was a window manager responsibility, perhaps the window manager could infer preferred orientation simply from the requested window size? (i.e. requesting width height implies a preference for landscape). That should often work for apps that were designed for the desktop. I would guess that apps written for the FR might not request specific sizes, because they'd know that they will always be fullscreen anyway - so for those apps some explicit configuration would be needed somewhere (prefer-portrait, prefer-landscape, or auto-rotate). repeating... property on window. the rotation preferences are a property of a window - like min and max size are, its title, etc. etc. - stick it on the window. ignore dbus. this is not something you do by dbus. if something is related to the display - especially something is related to your window, your domain for advertising state, information, making requests and getting replies is the x11 domain as long as you are using x11. :) I'm definitely not following you... I envision the following scenario according to what you say, could you please elaborate on why it wouldn't happen this way? 1. App wants to be landscape, sets property on window 2. rotator determines the phone is in portrait, rotates. Now what happens? 3. App is landscape, but screen is portrait: fail or 3. Window manager overrides rotation 3.1 but rotator determines portrait, rotates again 3.2 go to 3: fail rotate and wm should work closely together or be the same. the wm reads ande knows all the properties of all windows. the rotator can do this independantly - but its a fair bit of work. the wm makes decisions which rotation to use based on app properties and rotation preference (preference maybe being set by the user explicitly or automatically by accelerometers - how, doesn't much matter). rotator doesnt go off and do whatever it likes irrespective of app hints. it needs to take them into account - put hints on window as properties. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, Nov 7, 2009 at 1:55 PM, Carsten Haitzler ras...@rasterman.com wrote: [...] yes. see above. apps are doing it all the time. it's about the most standard way to provide information about your window, from title to minimum and maximum size to aspect ratios and more. rotation preferences are just yet more properties like this. if its a property of the window - put it as a property of the window. use the mechanism created for precisely this kind of thing. dbus is not that mechanism. [...] if an app has rotation preferences, it should set them. if it has none - it gets whatever the screen has right now - or whatever the wm chooses to implement as policy. yes - you modify apps to have them indicate their preferences. otherwise they are deemed to not care which is the case now, for example. you modify the apps - thats the right way to do it. you don't post-mortem find a way to hack things in. :) Also do you know if there's already a well-known window property for preferred rotation, or would we be inventing a new one? you'd be inventing it. I agree that window properties is the right way to implement that, but we need a way to get rotation preferences now, while that may be proposed and discussed as a standard for the future. So a couple of questions: * is it possible/safe/correct to set a window properties of a window/xclient by an external app (e.g. a launcher)? * supposing the above is possible, we may add a custom configuration entry in .desktop files and delegate the launcher to set window properties * if that is not possible the wm or an ewmh app helper (the launcher itself?) may get the active current window and perform the screen rotation as needed In every case and going a bit ot, is anyway possibile having a generic Window ID to retrieve the .desktop file originating the owning app? I'm just guessing to retrieve the pid from window properties, retrieve the executable (like /proc/pid/exe) and back search in the .desktop file definitions. But this seems weight as the Exec in .desktop files may be a relative path, a link etc, for sure there is a better way, may you explain them? Thanks and Regards Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
2009/11/7 Rui Miguel Silva Seabra r...@1407.org: I'm definitely not following you... I envision the following scenario according to what you say, could you please elaborate on why it wouldn't happen this way? My thinking is evolving with this discussion, but my current idea of the solution is that the WM controls whether omnewrotate is running (or equivalent, but for simplicity let's just say omnewrotate). So for the current foreground app, the WM determines (from properties, or width:height, or configuration, or some customization hook, or from user direction via a shelf gadget) which of the following applies. 1. App works best in landscape. 2. App works best in portrait. 3. App can adapt to either landscape or portrait, and user should choose by turning the phone round. Then, for (1) and (2), the WM itself calls xrandr to set the correct orientation, and kills omnewrotate if it was running. For (3) the WM starts omnewrotate if it isn't already running, and omnewrotate then handles autorotation. Given that... 1. App wants to be landscape, sets property on window WM would call xrandr itself. 2. rotator determines the phone is in portrait, rotates. omnewrotate wouldn't be running, so this wouldn't happen. Now what happens? 3. App is landscape, but screen is portrait: fail WM calls xrandr to go to landscape. or 3. Window manager overrides rotation 3.1 but rotator determines portrait, rotates again As above, omnewrotate wouldn't actually be running, so wouldn't do this. I hope that helps to clarify what I have in mind! Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
2009/11/7 Nicola Mfb nicola@gmail.com: I agree that window properties is the right way to implement that, but we need a way to get rotation preferences now, while that may be proposed and discussed as a standard for the future. Yes, exactly. So a couple of questions: * is it possible/safe/correct to set a window properties of a window/xclient by an external app (e.g. a launcher)? I don't know (yet). * supposing the above is possible, we may add a custom configuration entry in .desktop files and delegate the launcher to set window properties Yes, that seems like a good option. * if that is not possible the wm or an ewmh app helper (the launcher itself?) may get the active current window and perform the screen rotation as needed I don't think the launcher itself can do it, because it doesn't know when the app gets mapped to the foreground. Some apps take so long to appear that you can switch to several other screens and write a short program while waiting for them :-) I wouldn't want the launcher to spuriously change the orientation of those existing screens. What is an ewmh helper? In every case and going a bit ot, is anyway possibile having a generic Window ID to retrieve the .desktop file originating the owning app? I'm just guessing to retrieve the pid from window properties, retrieve the executable (like /proc/pid/exe) and back search in the .desktop file definitions. Well the .desktop file can have StartupWMClass, and I think the idea is that that is sufficient to identify the resulting window. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, Nov 7, 2009 at 3:33 PM, Neil Jerram neiljer...@googlemail.com wrote: [...] I don't think the launcher itself can do it, because it doesn't know when the app gets mapped to the foreground. Some apps take so long to appear that you can switch to several other screens and write a short program while waiting for them :-) I wouldn't want the launcher to spuriously change the orientation of those existing screens. What is an ewmh helper? I mean an helper app that listen via EWMH for client stacking list changes and/or current active win id changes, so when a Window is showed it takes the ID and query for properties, if rotation preferences is found rotate the screen or set autorotation. If not it has to determine the .destkop file that originated the Window, search for the rotation properties, than if possible it may set those for the window or cache them internally for the next interaction. [...] Well the .desktop file can have StartupWMClass, and I think the idea is that that is sufficient to identify the resulting window. Oh! I noted that property, just curious if it is safe, software set that properties widely and in a good way, no duplication or weird default values? I may use that to show the icon of the .desktop file instead of the window property icon in my app switcher too ;) Thanks Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
2009/11/7 Rui Miguel Silva Seabra r...@1407.org: You have no solution for existing apps other than causing a full stop on rotation once you get the desired rotation (which is what I do for apps that work better on landscape). I imagine WM configuration for this, and a shelf gadget to make it easy to add to the configuration for an app that doesn't yet have it. DBUS helps a lot because you can define a standard set of signals: 1. screen rotation apps could listen for specific screen rotation signals Agree there. The frequency of the new DBUS orientation interface seems high enough for omnewrotate to use it instead of reading accelerometer data directly. 2. apps which have specific needs can broadcast said needs to DBUS Interesting idea, but different apps can have different specific needs, and only the WM knows which app is in the foreground. Another thought that occurred to me is that if this was a window manager responsibility, perhaps the window manager could infer preferred orientation simply from the requested window size? (i.e. requesting width height implies a preference for landscape). The only way this could be the window manager's job, was if the window manager had auto-rotation routings. AFAICT, E doesn't yet. I think my other response has covered this. Of course rotator apps only come up because people feel the need and writing a simple daemon is simpler than patching a quite evolved window manager. Yes, good point. And I also admit that the work needed for my so-called ideal solution is non-trivial, and that the result might only be a little better than the existing solution - i.e. to run omnewrotate nearly all the time, and only stop it when using an app with which it interferes in a bad way. But I think I might have a go anyway at patching the e17 WM. With Debian, and 'apt-get source', and gcc on the phone, it shouldn't be as hard as it might sound. That should often work for apps that were designed for the desktop. I would guess that apps written for the FR might not request specific sizes, because they'd know that they will always be fullscreen anyway - so for those apps some explicit configuration would be needed somewhere (prefer-portrait, prefer-landscape, or auto-rotate). So rotators would need to parse all the configurations? No, the WM (or whatever hook the WM calls out to). Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
2009/11/7 Carsten Haitzler ras...@rasterman.com: On Sat, 7 Nov 2009 08:33:35 + Neil Jerram neiljer...@googlemail.com said: 2009/11/7 Carsten Haitzler ras...@rasterman.com: no. the proper way is to set properties on your window. How exactly does that (setting a property) happen though? Is it how does setting the title? or the min/max size of the window happen? the name and class, window role, if its a dialog, transient for which window, if the app would like it to be borderless... all of these are properties. try xprop and clikc on a window. any window (freerunner or desktop - doesn't matter). THOSE are properties. you can add/create/define any properties you like. they hang onto the window until they are modified or deleted or the window is deleted. something that the app would normally do in its own startup code? (I yes. see above. apps are doing it all the time. it's about the most standard way to provide information about your window, from title to minimum and maximum size to aspect ratios and more. rotation preferences are just yet more properties like this. if its a property of the window - put it as a property of the window. use the mechanism created for precisely this kind of thing. dbus is not that mechanism. Thanks. I think I'll look at adding this into the e17 WM. If you can recommend a good place in the code to starting working on this (i.e. checking for a rotation property, and invoking xrandr or omnewrotate accordingly), that would be great. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
07.11.2009 14:44, Nicola Mfb : On Sat, Nov 7, 2009 at 1:55 PM, Carsten Haitzler ras...@rasterman.com wrote: [...] yes. see above. apps are doing it all the time. it's about the most standard way to provide information about your window, from title to minimum and maximum size to aspect ratios and more. rotation preferences are just yet more properties like this. if its a property of the window - put it as a property of the window. use the mechanism created for precisely this kind of thing. dbus is not that mechanism. [...] if an app has rotation preferences, it should set them. if it has none - it gets whatever the screen has right now - or whatever the wm chooses to implement as policy. yes - you modify apps to have them indicate their preferences. otherwise they are deemed to not care which is the case now, for example. you modify the apps - thats the right way to do it. you don't post-mortem find a way to hack things in. :) Also do you know if there's already a well-known window property for preferred rotation, or would we be inventing a new one? you'd be inventing it. i don't think so, see below I agree that window properties is the right way to implement that, but we need a way to get rotation preferences now, while that may be proposed and discussed as a standard for the future. So a couple of questions: * is it possible/safe/correct to set a window properties of a window/xclient by an external app (e.g. a launcher)? in my oppinion, it is not necessary, because one has all needed information already in -- man XSizeHints if a window says, for exampe 800x600, and says maybe in the aspect ratios 4:3, the rotation preference is quite clear, i think. the only thing, i think, we need, is a little patch in the window-manager. i don't say it is easy, but this is the only right place. In every case and going a bit ot, is anyway possibile having a generic Window ID to retrieve the .desktop file originating the owning app? I'm just guessing to retrieve the pid from window properties, retrieve the executable (like /proc/pid/exe) and back search in the .desktop file definitions. But this seems weight as the Exec in .desktop files may be a relative path, a link etc, for sure there is a better way, may you explain them? these things are workarrounds for not having to patch the window manager, i think. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, Nov 7, 2009 at 4:56 PM, Matthias Huber matthias.hu...@wollishausen.de wrote: [...] * is it possible/safe/correct to set a window properties of a window/xclient by an external app (e.g. a launcher)? in my oppinion, it is not necessary, because one has all needed information already in -- man XSizeHints if a window says, for exampe 800x600, and says maybe in the aspect ratios 4:3, the rotation preference is quite clear, i think. Good point! it may be if preferred widthprefferred height then use landscape else use portrait. How may we handle the case for apps that are able to auto relayout according to screen orientation? An idea may be if ratio is in a 1 +/- x than use autorotate else use the previous pseudo snippet. We should gather if generic apps uses xsizehints at all in the proper way, I guess yes. the only thing, i think, we need, is a little patch in the window-manager. i don't say it is easy, but this is the only right place. Agree, and this should be more feasible than other heavy implementation. In every case and going a bit ot, is anyway possibile having a generic Window ID to retrieve the .desktop file originating the owning app? I'm just guessing to retrieve the pid from window properties, retrieve the executable (like /proc/pid/exe) and back search in the .desktop file definitions. But this seems weight as the Exec in .desktop files may be a relative path, a link etc, for sure there is a better way, may you explain them? these things are workarrounds for not having to patch the window manager, i think. Exactly! I'm writing a small apps that interact with the window manager via ewmh and it works well (tested on matchbox), i'm able to raise, activate, close windows, manage the stacking list and so on, so the idea is to add randr code to rotate them, in that way should work with every wm ewmh compliant. I'm searching for a way to retrieve the .desktop entry of a Window ID to have a nice app switcher with localized names, nice graphics and so on, and it seems that the wm class may help me in that, finally we may use XSizeHint + .destkop custom overrides when necessary? Oh last time I checked Illume about that I found it's not ewmh compliant, just curious if it is now implemented? Regards Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, Nov 07, 2009 at 11:46:28PM +1100, Carsten Haitzler wrote: if something is related to the display - especially something is related to your window, your domain for advertising state, information, making requests and getting replies is the x11 domain as long as you are using x11. :) I'm definitely not following you... I envision the following scenario according to what you say, could you please elaborate on why it wouldn't happen this way? 1. App wants to be landscape, sets property on window 2. rotator determines the phone is in portrait, rotates. Now what happens? 3. App is landscape, but screen is portrait: fail or 3. Window manager overrides rotation 3.1 but rotator determines portrait, rotates again 3.2 go to 3: fail rotate and wm should work closely together or be the same. the wm reads ande knows all the properties of all windows. the rotator can do this independantly - but its a fair bit of work. the wm makes decisions which rotation to use based on app properties and rotation preference (preference maybe being set by the user explicitly or automatically by accelerometers - how, doesn't much matter). It can do *your*way* with more work than the WM, but then, if the WM *doesn't* do rotation according to accelerometers, this is a moot point :) rotator doesnt go off and do whatever it likes irrespective of app hints. it needs to take them into account - put hints on window as properties. Of course, but there has to be a standard way to take their needs in account :) Being X properties or DBUS, it's the same for me. DBUS seems more natural as there's probably less pooling, but then I know only a bit more of DBUS than of X11 (which AFAIR was a bunch of huge books) :) Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, Nov 07, 2009 at 02:23:01PM +, Neil Jerram wrote: 2009/11/7 Rui Miguel Silva Seabra r...@1407.org: I'm definitely not following you... I envision the following scenario according to what you say, could you please elaborate on why it wouldn't happen this way? My thinking is evolving with this discussion, but my current idea of the solution is that the WM controls whether omnewrotate is running (or equivalent, but for simplicity let's just say omnewrotate). Actually, screen rotation *should* be the job of the WM. For me, as a relative begginer, it was easier to startup with the first rotate.c written by Chris Ball and step by step improving (for instance, drop fork and link to libxrandr for better performance, control speed of reading from device, give tolerance, etc. But if it was the WM, the WM could even do nifty special effects (in graphics card that would allow it), etc... OMNewRotate is a hack satisfying one need. To keep it going it needs a smart way to do it (like DBUS). X properties is probably not so good for this kind of programs. (...) As above, omnewrotate wouldn't actually be running, so wouldn't do this. If you have two applications handling screen rotation at the same time, then you're just bound to a disaster fuse. Either the WM does it (hint for more experienced E developers), or it should keep it's hands off of it :) I hope that helps to clarify what I have in mind! Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, Nov 07, 2009 at 02:53:18PM +, Neil Jerram wrote: But I think I might have a go anyway at patching the e17 WM. With Debian, and 'apt-get source', and gcc on the phone, it shouldn't be as hard as it might sound. Please do, and hopefully make it so much better and niftier than omnewrotate :) Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Fri, Nov 06, 2009 at 08:24:13PM +, Neil Jerram wrote: 2009/11/6 Rui Miguel Silva Seabra r...@1407.org: On Fri, Nov 06, 2009 at 04:40:04PM +0100, Helge Hafting wrote: Well, you cannot expect every app to have such preferences, this device runs generic linux apps that aren't made specially for the freerunner. Now, of course the app loader can do this, similiar to how we already request the cpu/backlight when launching some apps. But there is a problem. The user may switch between several apps with different rotation needs. (xmahjongg needs landscape, tetris needs portrait, ...) How will omnewrotate be notified about this? The proper way is to define a set of DBUS signals. Thanks to everyone for your replies on this topic. I agree with Helge, in that I don't think DBUS is a good solution, because I really want a solution that works for existing apps. I suppose for existing apps there could be a DBUS proxy that somehow works out the best orientation and then sends a DBUS signal on the app's behalf. But that seems complicated. Also I'm not sure why DBUS helps at all. Once a program somewhere has worked out the best orientation, why not just call xrandr directly? The program needs to know which orientation it works best, but outsource the work to another program in a lighteight form (X props or dbus) is better. Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 19:46:28 + Rui Miguel Silva Seabra r...@1407.org said: On Sat, Nov 07, 2009 at 11:46:28PM +1100, Carsten Haitzler wrote: if something is related to the display - especially something is related to your window, your domain for advertising state, information, making requests and getting replies is the x11 domain as long as you are using x11. :) I'm definitely not following you... I envision the following scenario according to what you say, could you please elaborate on why it wouldn't happen this way? 1. App wants to be landscape, sets property on window 2. rotator determines the phone is in portrait, rotates. Now what happens? 3. App is landscape, but screen is portrait: fail or 3. Window manager overrides rotation 3.1 but rotator determines portrait, rotates again 3.2 go to 3: fail rotate and wm should work closely together or be the same. the wm reads ande knows all the properties of all windows. the rotator can do this independantly - but its a fair bit of work. the wm makes decisions which rotation to use based on app properties and rotation preference (preference maybe being set by the user explicitly or automatically by accelerometers - how, doesn't much matter). It can do *your*way* with more work than the WM, but then, if the WM *doesn't* do rotation according to accelerometers, this is a moot point :) then do it with dbus if you insist. it's the wrong way. it's like putting drivers in your wm, or putting your email client as a module in the kernel. it's wrong. rotator doesnt go off and do whatever it likes irrespective of app hints. it needs to take them into account - put hints on window as properties. Of course, but there has to be a standard way to take their needs in account :) Being X properties or DBUS, it's the same for me. DBUS seems more natural as there's probably less pooling, but then I know only a bit more of DBUS than of X11 (which AFAIR was a bunch of huge books) :) no. dbus is far from natural or correct. that's what i keep saying. this is not something for dbus. it's something for properties on a window. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 14:53:18 + Neil Jerram neiljer...@googlemail.com said: 2009/11/7 Rui Miguel Silva Seabra r...@1407.org: You have no solution for existing apps other than causing a full stop on rotation once you get the desired rotation (which is what I do for apps that work better on landscape). I imagine WM configuration for this, and a shelf gadget to make it easy to add to the configuration for an app that doesn't yet have it. DBUS helps a lot because you can define a standard set of signals: 1. screen rotation apps could listen for specific screen rotation signals Agree there. The frequency of the new DBUS orientation interface seems high enough for omnewrotate to use it instead of reading accelerometer data directly. 2. apps which have specific needs can broadcast said needs to DBUS Interesting idea, but different apps can have different specific needs, and only the WM knows which app is in the foreground. Another thought that occurred to me is that if this was a window manager responsibility, perhaps the window manager could infer preferred orientation simply from the requested window size? (i.e. requesting width height implies a preference for landscape). The only way this could be the window manager's job, was if the window manager had auto-rotation routings. AFAICT, E doesn't yet. I think my other response has covered this. Of course rotator apps only come up because people feel the need and writing a simple daemon is simpler than patching a quite evolved window manager. Yes, good point. And I also admit that the work needed for my so-called ideal solution is non-trivial, and that the result might only be a little better than the existing solution - i.e. to run omnewrotate nearly all the time, and only stop it when using an app with which it interferes in a bad way. But I think I might have a go anyway at patching the e17 WM. With Debian, and 'apt-get source', and gcc on the phone, it shouldn't be as hard as it might sound. e has a whole subsystem for this... modules. you don't need to patch anything. modules are runtime patches for the wm. :) That should often work for apps that were designed for the desktop. I would guess that apps written for the FR might not request specific sizes, because they'd know that they will always be fullscreen anyway - so for those apps some explicit configuration would be needed somewhere (prefer-portrait, prefer-landscape, or auto-rotate). So rotators would need to parse all the configurations? No, the WM (or whatever hook the WM calls out to). Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 19:57:25 + Rui Miguel Silva Seabra r...@1407.org said: On Sat, Nov 07, 2009 at 02:23:01PM +, Neil Jerram wrote: 2009/11/7 Rui Miguel Silva Seabra r...@1407.org: I'm definitely not following you... I envision the following scenario according to what you say, could you please elaborate on why it wouldn't happen this way? My thinking is evolving with this discussion, but my current idea of the solution is that the WM controls whether omnewrotate is running (or equivalent, but for simplicity let's just say omnewrotate). Actually, screen rotation *should* be the job of the WM. For me, as a relative yup! that's what i was saying :) just helping people who have spent far less time than me, for example, dealing with desktop standards, properties, x11, wm's, multiple separare clients etc. etc. :) begginer, it was easier to startup with the first rotate.c written by Chris Ball and step by step improving (for instance, drop fork and link to libxrandr for better performance, control speed of reading from device, give tolerance, etc. But if it was the WM, the WM could even do nifty special effects (in graphics card that would allow it), etc... if the wm was a compositor too - which some are, yes. correct. it could animate the transitions etc. etc. OMNewRotate is a hack satisfying one need. To keep it going it needs a smart way to do it (like DBUS). X properties is probably not so good for this kind of programs. (...) As above, omnewrotate wouldn't actually be running, so wouldn't do this. If you have two applications handling screen rotation at the same time, then you're just bound to a disaster fuse. Either the WM does it (hint for more experienced E developers), or it should keep it's hands off of it :) I hope that helps to clarify what I have in mind! Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 07 Nov 2009 16:56:13 +0100 Matthias Huber matthias.hu...@wollishausen.de said: 07.11.2009 14:44, Nicola Mfb : On Sat, Nov 7, 2009 at 1:55 PM, Carsten Haitzler ras...@rasterman.com wrote: [...] yes. see above. apps are doing it all the time. it's about the most standard way to provide information about your window, from title to minimum and maximum size to aspect ratios and more. rotation preferences are just yet more properties like this. if its a property of the window - put it as a property of the window. use the mechanism created for precisely this kind of thing. dbus is not that mechanism. [...] if an app has rotation preferences, it should set them. if it has none - it gets whatever the screen has right now - or whatever the wm chooses to implement as policy. yes - you modify apps to have them indicate their preferences. otherwise they are deemed to not care which is the case now, for example. you modify the apps - thats the right way to do it. you don't post-mortem find a way to hack things in. :) Also do you know if there's already a well-known window property for preferred rotation, or would we be inventing a new one? you'd be inventing it. i don't think so, see below I agree that window properties is the right way to implement that, but we need a way to get rotation preferences now, while that may be proposed and discussed as a standard for the future. So a couple of questions: * is it possible/safe/correct to set a window properties of a window/xclient by an external app (e.g. a launcher)? in my oppinion, it is not necessary, because one has all needed information already in -- man XSizeHints if a window says, for exampe 800x600, and says maybe in the aspect ratios 4:3, the rotation preference is quite clear, i think. 800x600 doesn;'t even fit. its a minimum size. it's not sane to use such a property as this doesn't tell you the original rotation - just a size. you are overloading a property here that isn't meant for this information. ther's also a window aspect ratio property - again, this isn't rotation. a wm may interpret this by scrolling the window around, not rotating. or just make the window smaller if it likes it or not (eg what e and matchbox do for example). the only thing, i think, we need, is a little patch in the window-manager. i don't say it is easy, but this is the only right place. In every case and going a bit ot, is anyway possibile having a generic Window ID to retrieve the .desktop file originating the owning app? I'm just guessing to retrieve the pid from window properties, retrieve the executable (like /proc/pid/exe) and back search in the .desktop file definitions. But this seems weight as the Exec in .desktop files may be a relative path, a link etc, for sure there is a better way, may you explain them? these things are workarrounds for not having to patch the window manager, i think. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 14:33:25 + Neil Jerram neiljer...@googlemail.com said: 2009/11/7 Nicola Mfb nicola@gmail.com: I agree that window properties is the right way to implement that, but we need a way to get rotation preferences now, while that may be proposed and discussed as a standard for the future. Yes, exactly. So a couple of questions: * is it possible/safe/correct to set a window properties of a window/xclient by an external app (e.g. a launcher)? I don't know (yet). * supposing the above is possible, we may add a custom configuration entry in .desktop files and delegate the launcher to set window properties Yes, that seems like a good option. * if that is not possible the wm or an ewmh app helper (the launcher itself?) may get the active current window and perform the screen rotation as needed I don't think the launcher itself can do it, because it doesn't know when the app gets mapped to the foreground. Some apps take so long to appear that you can switch to several other screens and write a short program while waiting for them :-) I wouldn't want the launcher to spuriously change the orientation of those existing screens. What is an ewmh helper? In every case and going a bit ot, is anyway possibile having a generic Window ID to retrieve the .desktop file originating the owning app? I'm just guessing to retrieve the pid from window properties, retrieve the executable (like /proc/pid/exe) and back search in the .desktop file definitions. Well the .desktop file can have StartupWMClass, and I think the idea is that that is sufficient to identify the resulting window. it isn't actually - it can help, but it's not sufficient. it can be ambiguous. in fact often is. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 17:31:58 +0100 Nicola Mfb nicola@gmail.com said: On Sat, Nov 7, 2009 at 4:56 PM, Matthias Huber matthias.hu...@wollishausen.de wrote: [...] * is it possible/safe/correct to set a window properties of a window/xclient by an external app (e.g. a launcher)? in my oppinion, it is not necessary, because one has all needed information already in -- man XSizeHints if a window says, for exampe 800x600, and says maybe in the aspect ratios 4:3, the rotation preference is quite clear, i think. Good point! it may be if preferred widthprefferred height then use landscape else use portrait. How may we handle the case for apps that are able to auto relayout according to screen orientation? An idea may be if ratio is in a 1 +/- x than use autorotate else use the previous pseudo snippet. correct. these apps will have minimu8m window sizes too - often set by the toolkit. the information here is now bogus and unintended and doesn't want to tell you to keep an orientation specifically. this hint is not intended for this. creasting a new atom for a hint and setting it is very easy. you are not materially saving work by overloading existing properties which as you already can see - will cause problems. We should gather if generic apps uses xsizehints at all in the proper way, I guess yes. the only thing, i think, we need, is a little patch in the window-manager. i don't say it is easy, but this is the only right place. Agree, and this should be more feasible than other heavy implementation. In every case and going a bit ot, is anyway possibile having a generic Window ID to retrieve the .desktop file originating the owning app? I'm just guessing to retrieve the pid from window properties, retrieve the executable (like /proc/pid/exe) and back search in the .desktop file definitions. But this seems weight as the Exec in .desktop files may be a relative path, a link etc, for sure there is a better way, may you explain them? these things are workarrounds for not having to patch the window manager, i think. Exactly! I'm writing a small apps that interact with the window manager via ewmh and it works well (tested on matchbox), i'm able to raise, activate, close windows, manage the stacking list and so on, so the idea is to add randr code to rotate them, in that way should work with every wm ewmh compliant. I'm searching for a way to retrieve the .desktop entry of a Window ID to have a nice app switcher with localized names, nice graphics and so on, and it seems that the wm class may help me in that, finally we may use XSizeHint + .destkop custom overrides when necessary? Oh last time I checked Illume about that I found it's not ewmh compliant, just curious if it is now implemented? Regards Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 14:44:53 +0100 Nicola Mfb nicola@gmail.com said: On Sat, Nov 7, 2009 at 1:55 PM, Carsten Haitzler ras...@rasterman.com wrote: [...] yes. see above. apps are doing it all the time. it's about the most standard way to provide information about your window, from title to minimum and maximum size to aspect ratios and more. rotation preferences are just yet more properties like this. if its a property of the window - put it as a property of the window. use the mechanism created for precisely this kind of thing. dbus is not that mechanism. [...] if an app has rotation preferences, it should set them. if it has none - it gets whatever the screen has right now - or whatever the wm chooses to implement as policy. yes - you modify apps to have them indicate their preferences. otherwise they are deemed to not care which is the case now, for example. you modify the apps - thats the right way to do it. you don't post-mortem find a way to hack things in. :) Also do you know if there's already a well-known window property for preferred rotation, or would we be inventing a new one? you'd be inventing it. I agree that window properties is the right way to implement that, but we need a way to get rotation preferences now, while that may be proposed and discussed as a standard for the future. thats the job of the wm to implement the rotation and a policy (preferences) *IF* an app desires something specific - it is up to the app to say so. until it does it can be assumed to have no preference. So a couple of questions: * is it possible/safe/correct to set a window properties of a window/xclient by an external app (e.g. a launcher)? it is. but it's wrong. it's silly. it's a horrible hack. you do not need it. that app HAS no preferences. it was never written to be just landscape or just portrait. it HAD to have been written to work in either mode. it had no choice. your assumption here is wrong :) * supposing the above is possible, we may add a custom configuration entry in .desktop files and delegate the launcher to set window properties this is just silly. you are modifying the app - you are modifying the .desktop file. the code here is several times bigger than modifying the app. it's a horrible hack. don't do it. * if that is not possible the wm or an ewmh app helper (the launcher itself?) may get the active current window and perform the screen rotation as needed as such - until an app window hints otherwise - rotate as desired. if it hints that it would like to be a specific rotation, then enforce that rotation if it is not in effect yet. :) In every case and going a bit ot, is anyway possibile having a generic Window ID to retrieve the .desktop file originating the owning app? this is a complicated mess. a window id is like a pointer. knowing who allocated it is tricky. as such its not guaranteed to be able to know UNLESS the app alrady does a chunk of work and sets a bunch of properties etc. etc. and the wm tracks pid's launch id's matches these up with window properties etc. etc. - e does this. .desk to files are NOT the place for things like this. absolutely not the place. you will be abusing a mechanism not designed for this. i can tell you that i'd never accept a patch that does this - and most wm authors i know would not. you'd never get this through as a standard on freedesktop.org. because it's wrong. I'm just guessing to retrieve the pid from window properties, retrieve the executable (like /proc/pid/exe) and back search in the .desktop file definitions. not always possible. setting pid is optional for an app. even then - if the pid of the app is not the pid of what you launched (you launched a shell script that runs 1 or more child procs - thus have different pid's) you are screwed. it's an inexact breakable mechanism. i repeat. don't use it. not going to send more mails about not using it. i've said it often enough. :) But this seems weight as the Exec in .desktop files may be a relative path, a link etc, for sure there is a better way, may you explain them? the app sets the property if it cares. it it's code. otherwise - too bad. thats the better way. Thanks and Regards Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 15:04:46 + Neil Jerram neiljer...@googlemail.com said: 2009/11/7 Carsten Haitzler ras...@rasterman.com: On Sat, 7 Nov 2009 08:33:35 + Neil Jerram neiljer...@googlemail.com said: 2009/11/7 Carsten Haitzler ras...@rasterman.com: no. the proper way is to set properties on your window. How exactly does that (setting a property) happen though? Is it how does setting the title? or the min/max size of the window happen? the name and class, window role, if its a dialog, transient for which window, if the app would like it to be borderless... all of these are properties. try xprop and clikc on a window. any window (freerunner or desktop - doesn't matter). THOSE are properties. you can add/create/define any properties you like. they hang onto the window until they are modified or deleted or the window is deleted. something that the app would normally do in its own startup code? (I yes. see above. apps are doing it all the time. it's about the most standard way to provide information about your window, from title to minimum and maximum size to aspect ratios and more. rotation preferences are just yet more properties like this. if its a property of the window - put it as a property of the window. use the mechanism created for precisely this kind of thing. dbus is not that mechanism. Thanks. I think I'll look at adding this into the e17 WM. If you can recommend a good place in the code to starting working on this (i.e. checking for a rotation property, and invoking xrandr or omnewrotate accordingly), that would be great. 1. dont invoke any commands. a fork+exec is expensive when you can just issue a protocol request to x. the most you will do is exec omnewrotte and give omnewrotate the ability to report rotation via dbus or vis stdout. hell maybe just put it in a thread and write current rotation, if it changes, down a pipe () to the main loop. 2. look at modules in general. this is how you patch the wm. :) 3. look at conf_display module - it does resolution changes and rotation preferences already 4. look at pager module for tracking new windows (or window deletes, the currently active window etc. 5. look at e_hints.c for getting hints. some of this is wrappers around existing well known icccm and netwm properties, some is getting custom properties not wrapped. 6. look at e_border.c for more info on tracking property changes (set up a handler for the event) etc. etc. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 14:23:01 + Neil Jerram neiljer...@googlemail.com said: 2009/11/7 Rui Miguel Silva Seabra r...@1407.org: I'm definitely not following you... I envision the following scenario according to what you say, could you please elaborate on why it wouldn't happen this way? My thinking is evolving with this discussion, but my current idea of the solution is that the WM controls whether omnewrotate is running (or equivalent, but for simplicity let's just say omnewrotate). So for the current foreground app, the WM determines (from properties, or width:height, or configuration, or some customization hook, or from user direction via a shelf gadget) which of the following applies. 1. App works best in landscape. 2. App works best in portrait. 3. App can adapt to either landscape or portrait, and user should choose by turning the phone round. Then, for (1) and (2), the WM itself calls xrandr to set the correct orientation, and kills omnewrotate if it was running. For (3) the WM starts omnewrotate if it isn't already running, and omnewrotate then handles autorotation. no. this is way too ugly. 1. omnewroatte ONLY listens to accelerometers and talks to the wm (via any mechanism you like) telling it what position the phone is in. that is all it does. nothing else. all other decisions are made by the wm base on as you said above, the properties of the window - which app is currently active (change apps between one that wants to be portrait wants to be landscape, the wm has to flip orientation when you flip apps. etc. for example - e already has a config dialog for changing screen resoltion and rotation. it already handles this stuff - it's missing the logic of reading some as-yet-uninvented property from a window and 2. handling that property with respect to rotation. any wm can do this. this is definitely a job that belongs in properties of a window and the wm to read them, follow their changes, and do the right thing) Given that... 1. App wants to be landscape, sets property on window WM would call xrandr itself. 2. rotator determines the phone is in portrait, rotates. omnewrotate wouldn't be running, so this wouldn't happen. Now what happens? 3. App is landscape, but screen is portrait: fail WM calls xrandr to go to landscape. or 3. Window manager overrides rotation 3.1 but rotator determines portrait, rotates again As above, omnewrotate wouldn't actually be running, so wouldn't do this. I hope that helps to clarify what I have in mind! Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Carsten Haitzler (The Rasterman) wrote: On Sat, 7 Nov 2009 19:46:28 + Rui Miguel Silva Seabra r...@1407.org said: Being X properties or DBUS, it's the same for me. DBUS seems more natural as there's probably less pooling, but then I know only a bit more of DBUS than of X11 (which AFAIR was a bunch of huge books) :) no. dbus is far from natural or correct. that's what i keep saying. this is not something for dbus. it's something for properties on a window. Sounds like we should be using window properties for passing hints to the WM, and dbus for getting orientation information from the accelerometers. Maybe it's time for omnewrotate to retire, with the WM talking to FSO's orientation API [1] directly? app - window properties - wm - dbus - fso WM making the decision on what direction to orient the display, based on window properties and device actual orientation etc. Dave [1] http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Device.Orientation.html;hb=HEAD ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sun, 08 Nov 2009 02:03:47 + Dave Ball openm...@underhand.org said: Carsten Haitzler (The Rasterman) wrote: On Sat, 7 Nov 2009 19:46:28 + Rui Miguel Silva Seabra r...@1407.org said: Being X properties or DBUS, it's the same for me. DBUS seems more natural as there's probably less pooling, but then I know only a bit more of DBUS than of X11 (which AFAIR was a bunch of huge books) :) no. dbus is far from natural or correct. that's what i keep saying. this is not something for dbus. it's something for properties on a window. Sounds like we should be using window properties for passing hints to the WM, and dbus for getting orientation information from the accelerometers. that is sane. :) Maybe it's time for omnewrotate to retire, with the WM talking to FSO's orientation API [1] directly? perhaps. whatever the mechanism 1. the wm is the right place to make the decision. 2. the wm is in the best position to easily gather information about an application's window and know what window is active 3. the wm is already talking to the xserver as part of its job - and it's always hanging around 4. all the wm needs to know is some external input has decded that the screne should be rotated. be this an accelerometer, or like the g1, opening up the screen, so be it. as long as 4.1 the current status of this rotation state can be queried at any time (you can ask what position the device is in or the screen is opened up or not etc. etc.) 4.2 you can get an event when this state changes really quickly (not have to wait a while). if it were me... i'd even have the current desired rotation state be a property on the root window too... but at this point its moot - dbus or property. it's the same. from my view - the property is simpler to do. it takes significantly less code in most languages/toolkits. trust me on this one. it does. but.. as i said - at this point it's moot. individal apps preferences for rotation should be properties on their own windows. app - window properties - wm - dbus - fso WM making the decision on what direction to orient the display, based on window properties and device actual orientation etc. yes. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Carsten Haitzler (The Rasterman) wrote: On Sun, 08 Nov 2009 02:03:47 + Dave Ball openm...@underhand.org said: Sounds like we should be using window properties for passing hints to the WM, and dbus for getting orientation information from the accelerometers. that is sane. :) Maybe it's time for omnewrotate to retire, with the WM talking to FSO's orientation API [1] directly? perhaps. whatever the mechanism 1. the wm is the right place to make the decision. 2. the wm is in the best position to easily gather information about an application's window and know what window is active 3. the wm is already talking to the xserver as part of its job - and it's always hanging around 4. all the wm needs to know is some external input has decded that the screne should be rotated. I think what you meant here is the WM decides whether the screen should be rotated or not - all the 'external input' provides to the WM is some hint that e.g. the _device_ has been rotated? WM could decide to NOT rotate the screen, if the current app only works in one orientation. be this an accelerometer, or like the g1, opening up the screen, so be it. as long as 4.1 the current status of this rotation state can be queried at any time (you can ask what position the device is in or the screen is opened up or not etc. etc.) 4.2 you can get an event when this state changes really quickly (not have to wait a while). Indeed. I've not played with the fso orientation API, but it looks like that is exactly what it's designed to provide. It seems sensible for this to be over dbus - given that it's an abstraction of hardware. if it were me... i'd even have the current desired rotation state be a property on the root window too... but at this point its moot - dbus or property. If the root window will only work in one orientation, specifying that orientation through a window property would be consistent - but ideally wouldn't we want the root window to be able to cope with being rotated to work in either orientation? Or have i missed something special about the root window? Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sun, Nov 8, 2009 at 2:13 AM, Carsten Haitzler ras...@rasterman.com wrote: [...] Raster, I understand perfectly that the best way is having apps setting an XAtom and the wm managing it. But if all those people are asking for a weird or wrong solution is becouse the good way is not standardized, is not implemented in the WMs and is unknown to existing apps, so we are just doing a bit of brainstorming to find a feasable solution *now*. Patching E/Illume and a dozen of apps is easy but I think peoples want use existing linux apps with their preferred WM too. Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sun, 08 Nov 2009 03:14:54 + Dave Ball openm...@underhand.org said: Carsten Haitzler (The Rasterman) wrote: On Sun, 08 Nov 2009 02:03:47 + Dave Ball openm...@underhand.org said: Sounds like we should be using window properties for passing hints to the WM, and dbus for getting orientation information from the accelerometers. that is sane. :) Maybe it's time for omnewrotate to retire, with the WM talking to FSO's orientation API [1] directly? perhaps. whatever the mechanism 1. the wm is the right place to make the decision. 2. the wm is in the best position to easily gather information about an application's window and know what window is active 3. the wm is already talking to the xserver as part of its job - and it's always hanging around 4. all the wm needs to know is some external input has decded that the screne should be rotated. I think what you meant here is the WM decides whether the screen should be rotated or not - all the 'external input' provides to the WM is some hint that e.g. the _device_ has been rotated? WM could decide to NOT rotate the screen, if the current app only works in one orientation. be this an accelerometer, or like the g1, opening up the screen, so be it. as long as 4.1 the current status of this rotation state can be queried at any time (you can ask what position the device is in or the screen is opened up or not etc. etc.) 4.2 you can get an event when this state changes really quickly (not have to wait a while). Indeed. I've not played with the fso orientation API, but it looks like that is exactly what it's designed to provide. It seems sensible for this to be over dbus - given that it's an abstraction of hardware. if it were me... i'd even have the current desired rotation state be a property on the root window too... but at this point its moot - dbus or property. If the root window will only work in one orientation, specifying that orientation through a window property would be consistent - but ideally wouldn't we want the root window to be able to cope with being rotated to work in either orientation? Or have i missed something special about the root window? root window i special. it's generally got properties for the display/screen(s) as a whole. as such the desired rotation of the device is implicitly a property of the screen (device accelerometres and screen are tied in this case). thus it makes sense to set desired device rotation on the root window and desired app window rotation on the individual app windows. wm needs to track both and determine which one takes precedence based on policy and th en implement that rotation, if needed. policy is what a wm implements - that's the nature of the beast. that policy may be hard-coded in the wm or configuration for it. so to me - it makes perfect sense for such a desired state to be put into the x domain entirely as the property is related directly to the display/screen. gsm makes no sense being properties/events of x11. neither does wifi, or bt but brightness of screen, current abient lighting sensor data, etc. makes sense. as such x also covers input devices (kbd, mouse), thus anything you can deem to be an input device (touchscreen, buttons on the device, accelerometrs etc.) makes sense to put via x11, not dbus. its within the logical domain for its functionality. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sun, 8 Nov 2009 04:15:52 +0100 Nicola Mfb nicola@gmail.com said: On Sun, Nov 8, 2009 at 2:13 AM, Carsten Haitzler ras...@rasterman.com wrote: [...] Raster, I understand perfectly that the best way is having apps setting an XAtom and the wm managing it. But if all those people are asking for a weird or wrong solution is becouse the good way is not but the apps are asking for nothing right now. there is no standard. there is no info. thus.. it's moot. they get the behavior they get now. screen rotates if they like it or not -0 the window resizes and it is the job of an application to handle a window resize. if they like the size or not, under x11, it is the task of the app to adjust to a resize as it sees fit. it gets no explicit control over the window size. it only gets hints and to ask nicely. the answer to those hints may be no. it can and does happen. standardized, is not implemented in the WMs and is unknown to existing apps, so we are just doing a bit of brainstorming to find a feasable solution *now*. apps that don't ask - have their windows rotated if they like it or not. they NEVER have had the choice before. they NEVER knew about rotation before. they don't know or care. they never had the ability TO care before. Patching E/Illume and a dozen of apps is easy but I think peoples want use existing linux apps with their preferred WM too. 1. come up with a workable standard - 2. make sure it's clean and well thought through, 3. propose it to fdo as a new standard, 4. wait and over time it will actually be supported in apps and... the problem will go away permanently. anything else is a hack. well it doesnt need to go to fdo - but as long as it exists as a documented standard that anyone can choose to support or not, it doesn't matter. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Carsten Haitzler (The Rasterman) wrote: wm needs to track both and determine which one takes precedence based on policy and th en implement that rotation, if needed. policy is what a wm implements - that's the nature of the beast. that policy may be hard-coded in the wm or configuration for it. Is there a quick-start guide for writing an e module, maybe some simple code / example? Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sun, 08 Nov 2009 04:37:07 + Dave Ball openm...@underhand.org said: Carsten Haitzler (The Rasterman) wrote: wm needs to track both and determine which one takes precedence based on policy and th en implement that rotation, if needed. policy is what a wm implements - that's the nature of the beast. that policy may be hard-coded in the wm or configuration for it. Is there a quick-start guide for writing an e module, maybe some simple code / example? Dave http://www.rasterman.com/files/logo-0.0.1.tar.gz http://www.youtube.com/watch?v=abNsVyYTSkU umm... and otherwise look at the modules already in e (src) and the files i pointed to :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Tue, Nov 03, 2009 at 07:40:58PM +, Neil Jerram wrote: - for many apps there is a preferred orientation (e.g. zhone and hex-a-hop), and the best thing is to rotate the screen to what is best for each app, regardless of how the phone is being held When this is the case, I stop omnewrotate. - for some apps you definitely don't want the screen to be rotated underneath them, e.g. mokomaze Idem. - for the apps where autorotation makes sense, you want the control to be easily accessible - certainly a lot easier than switching back to the launcher or an xterm and doing something there :-) Have others already thought about this and devised solutions? I think a good solution might involve the window manager - since the window manager knows which app is at the front of the screen and so could rotate the screen correctly for it (including enabling autorotation for the apps where that makes sense). Alternatively - at least for e17 - an easily accessible gadget in the top shelf could make it very simple to choose a specific orientation and to enable and disable autorotation. The icon in the launcher being a toggler for omnewrotate is a hack as I haven't learned how to make a shelf gadget yet. Patches to make a shelf gadget for omnewrotate are, of course, welcome :) Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
[cut] autorotation for the apps where that makes sense). Alternatively - at least for e17 - an easily accessible gadget in the top shelf could What about full screen appications? Maybe using AUX button is a solution? -- Patryk LeadMan Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Email secured by Check Point ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Neil Jerram wrote: Having just written an automatic screen rotation program (like omnewrotate), I'm now wondering about the best way of using it, so that everything Just Works the way that it should. In particular, I've realized now that - for many apps there is a preferred orientation (e.g. zhone and hex-a-hop), and the best thing is to rotate the screen to what is best for each app, regardless of how the phone is being held - for some apps you definitely don't want the screen to be rotated underneath them, e.g. mokomaze - for the apps where autorotation makes sense, you want the control to be easily accessible - certainly a lot easier than switching back to the launcher or an xterm and doing something there :-) Have others already thought about this and devised solutions? I think a good solution might involve the window manager - since the window manager knows which app is at the front of the screen and so could rotate the screen correctly for it (including enabling autorotation for the apps where that makes sense). Alternatively - at least for e17 - an easily accessible gadget in the top shelf could make it very simple to choose a specific orientation and to enable and disable autorotation. The software that control rotation need to know if the foreground app should run in landscape, portrait or auto mode. (And perhaps the upside-down variants as well.) There are many ways to do this. For example: 1. Add this to enlightenment. Advantages: e already knows at all times which app is in the foreground. The .desktop files in /usr/share/applications/ can specify rotation preferences. You can also have rotation gadgets on the top shelf, for overriding when necessary. Disadvantage: Works only with e - obviously. 2. Give omnewrotate (or similiar rotation app) a list of apps and their preferred rotation. Advantage: works for all window managers disadvantage: overriding the rotation could be trickier, and omnewrotate will need a way to get notified about focus/foreground changes. Fast polling will slow down the phone, slow polling will be too slow. So notification is necessary. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Wed, Nov 04, 2009 at 01:55:29PM +0100, Helge Hafting wrote: Have others already thought about this and devised solutions? I think a good solution might involve the window manager - since the window manager knows which app is at the front of the screen and so could rotate the screen correctly for it (including enabling autorotation for the apps where that makes sense). Alternatively - at least for e17 - an easily accessible gadget in the top shelf could make it very simple to choose a specific orientation and to enable and disable autorotation. The software that control rotation need to know if the foreground app should run in landscape, portrait or auto mode. (And perhaps the upside-down variants as well.) Or, what I think would be the proper way to do it, the application should broadcast to dbus that it prefers no rotation, or one of the 4 possible rotation states and omnewrotate could listen to such requests and not rotate while there is such a message in the bus. Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
The software that control rotation need to know if the foreground app should run in landscape, portrait or auto mode. (And perhaps the upside-down variants as well.) Or, what I think would be the proper way to do it, the application should broadcast to dbus that it prefers no rotation, or one of the 4 possible rotation states and omnewrotate could listen to such requests and not rotate while there is such a message in the bus. so how does framework fit to this with it's orientation interface? Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Wed, Nov 04, 2009 at 02:22:33PM +0100, Petr Vanek wrote: The software that control rotation need to know if the foreground app should run in landscape, portrait or auto mode. (And perhaps the upside-down variants as well.) Or, what I think would be the proper way to do it, the application should broadcast to dbus that it prefers no rotation, or one of the 4 possible rotation states and omnewrotate could listen to such requests and not rotate while there is such a message in the bus. so how does framework fit to this with it's orientation interface? As far as I know, FSO will only emit some signals from time to time saying what position it thinks it's on. Other programs can plug into it and decide what to do (but of course that isn't at a rate useful for gestures). Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
so how does framework fit to this with it's orientation interface? As far as I know, FSO will only emit some signals from time to time saying what position it thinks it's on. Other programs can plug into it and decide what to do (but of course that isn't at a rate useful for gestures). i am testing that interface now and it reports position in less then 2 seconds (which i consider very optimal for regular usage). what kind of gestures do you mean or what do you mean by gestures? Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Wed, Nov 04, 2009 at 02:47:02PM +0100, Petr Vanek wrote: so how does framework fit to this with it's orientation interface? As far as I know, FSO will only emit some signals from time to time saying what position it thinks it's on. Other programs can plug into it and decide what to do (but of course that isn't at a rate useful for gestures). i am testing that interface now and it reports position in less then 2 seconds (which i consider very optimal for regular usage). what kind of gestures do you mean or what do you mean by gestures? Look for accelges (for an example). You need a lot more finegrained readings (several per second) in order to understand adequately a gesture (example, shaking the freerunner, doing an L in the air, etc...) Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Look for accelges (for an example). You need a lot more finegrained readings (several per second) in order to understand adequately a gesture (example, shaking the freerunner, doing an L in the air, etc...) oh yes, agree, but this is complicated and has nothing to do with simple screen rotation per application/user needs which i thought this thread was about? Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Wed, Nov 04, 2009 at 03:50:55PM +0100, Petr Vanek wrote: Look for accelges (for an example). You need a lot more finegrained readings (several per second) in order to understand adequately a gesture (example, shaking the freerunner, doing an L in the air, etc...) oh yes, agree, but this is complicated and has nothing to do with simple screen rotation per application/user needs which i thought this thread was about? Nothing much, really, which is why it was a mere comment between parenthesis, you asked, I replied :) Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
oh yes, agree, but this is complicated and has nothing to do with simple screen rotation per application/user needs which i thought this thread was about? Nothing much, really, which is why it was a mere comment between parenthesis, you asked, I replied :) :) Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
