Re: This might be illegal!
Il giorno sab, 07/11/2009 alle 09.29 +0530, Aditya Gandhi ha scritto: Hi people, Those who really wish to go by the book, don't like to break simple laws please stop here. I don't mean to be rude, but don't want people who usually don't break the law to get lured.. Is there anyway in which we can use their emulator, probably hack the g1 emulator and reverse engineer the android market so we can have it on freerunner, I know it wouldn,t be easy but I think it would be worth it. Cause I think its not the processor which is different, but the api which google uses for these apps to run. The main point here is I don't know how to do it, but wan't to and I'm asking for help of the people who can do it. Please confirm if you wish to Get it installed, google account sync, gmail working and calendar sync is quite easy, but once installed it doesn't start ti download anything. It can be a simple issue (like handling protocol market://, dns, routing or something similar) but i don't want to spend time trying to fix it. Maybe someone who want can try to make it. Syncing and intalling those apps could be illegal so you're warned. Pietro ___ 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: community Digest, Vol 156, Issue 27, Ideal screen rotation
On Fri, 6 Nov 2009 17:22:27 + Rui Miguel Silva Seabra r...@1407.org said: On Fri, Nov 06, 2009 at 04:40:04PM +0100, Helge Hafting wrote: Rui Miguel Silva Seabra wrote: On Wed, Nov 04, 2009 at 01:55:29PM +0100, Helge Hafting 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. 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. Of course conflicting signals need to be ignored. no. the proper way is to set properties on your window. this is a display system thing. dbus is orthogonal to it. you set properties. you let the wm figure out what to do with the active window(s) based on their properties. Which window property, a 'no resize' flag? Is the property stored by X, the window manager, or something else? Is the code that does the rotations in the window manager? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Some questions about android on Freerunner
In The Name Of God The compassionate merciful Good day everyone ; Thanks for your attentions ; 3 - Problem is that : our religion Eslam says you can use a person code while he/she allows you , now There are codes and wiki and .. on Google host .Even google is not owner of codes , Host pertains to google . So using that address and host is not possible for moslems now . See Now with this condition i will not use code.google.com with proxy , So please guide regarding to this fact . How about questions 4 and 5 and 6? 4 - You said codes (stable) are also on repository so just we lack wiki and issue tracking Yes ? Is there any other wiki/ manual /help for beginners ? What does issue tracking mean and is there any other site for issue tracking ? *ultimately what problems will a android user be faced without using code.google.com* ? 5- Why wiki and issue tracking are on google , can not be on other host? what is wiki license ? maybe it can be copy on other host ? Or is not it possible to replace Host ? 6-What is this address http://source.android.com/download for ? Does it host codes also ? and why android.com is not forbidden for Iranians ? Regards dehqan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [WikiReader] unable to run emulator
On Sat, Nov 7, 2009 at 2:01 AM, Suco sucotro...@gmail.com wrote: Trying to run it again, I've noted that when I execute sh 00run.sh this line is showed: make: *** There is no rule to build the target `farm0'. Stop. Yes you will need to write your own file. If you look at what is being executed in 00run.sh then it should be fairly obvious. Let us know if you get stuff. -Sean ___ 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: Some questions about android on Freerunner
On Sat, 7 Nov 2009 13:39:15 +0330 a dehqan dehqa...@gmail.com wrote: In The Name Of God The compassionate merciful Good day everyone ; Thanks for your attentions ; 3 - Problem is that : our religion Eslam says you can use a person code while he/she allows you , now There are codes and wiki and .. on Google host .Even google is not owner of codes , Host pertains to google . So using that address and host is not possible for moslems now . See Now with this condition i will not use code.google.com with proxy , So please guide regarding to this fact . Are you able to download a different openmoko distribution, like SHR? http://build.shr-project.org/shr-unstable/images/om-gta02/ -- Michael Smith Network Applications www.netapps.com.au | +61 (0) 416 062 898 Web Hosting | Internet Services signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Some questions about android on Freerunner
a dehqan dehqa...@gmail.com writes: 3 - Problem is that : our religion Eslam says you can use a person code while he/she allows you , now There are codes and wiki and .. on Google host .Even google is not owner of codes , Host pertains to google . So using that address and host is not possible for moslems now . See Now with this condition i will not use code.google.com with proxy , So please guide regarding to this fact . Have you seen my reply suggesting that google does not intend to actually probibit the access for you? Taking that into account i can't see why you keep asking useless questions without clarifying your position. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: This might be illegal!
On Sat, Nov 7, 2009 at 04:59, Aditya Gandhi aditya...@gmail.com wrote: Hi people, Those who really wish to go by the book, don't like to break simple laws please stop here. I don't mean to be rude, but don't want people who usually don't break the law to get lured.. Is there anyway in which we can use their emulator, probably hack the g1 emulator and reverse engineer the android market so we can have it on freerunner, I know it wouldn,t be easy but I think it would be worth it. Cause I think its not the processor which is different, but the api which google uses for these apps to run. The main point here is I don't know how to do it, but wan't to and I'm asking for help of the people who can do it. Please confirm if you wish to For apps written in their native API (not Dalvik) processor can be a problem - on gta01/02 we have armv4t, and on G1 there is armv5. -- Sebastian Krzyszkowiak dos ___ 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: community Digest, Vol 156, Issue 27, Ideal screen rotation
On Sat, 7 Nov 2009 03:41:28 -0600 Jared Maddox absinthdr...@gmail.com said: On Fri, 6 Nov 2009 17:22:27 + Rui Miguel Silva Seabra r...@1407.org said: On Fri, Nov 06, 2009 at 04:40:04PM +0100, Helge Hafting wrote: Rui Miguel Silva Seabra wrote: On Wed, Nov 04, 2009 at 01:55:29PM +0100, Helge Hafting 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. 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. Of course conflicting signals need to be ignored. no. the proper way is to set properties on your window. this is a display system thing. dbus is orthogonal to it. you set properties. you let the wm figure out what to do with the active window(s) based on their properties. Which window property, a 'no resize' flag? Is the property stored by X, the window manager, or something else? Is the code that does the rotations in the window manager? properties are stored in x - attached to the window in question. wm's listen for property changes and fetch these properties on window show and property changes. the wm may do whatever it wants then. the title of your window is a property. use xprop and click on a window. find out. -- - 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: This might be illegal!
On Sat, 2009-11-07 at 09:29 +0530, Aditya Gandhi wrote: Hi people, Those who really wish to go by the book, don't like to break simple laws please stop here. I don't mean to be rude, but don't want people who usually don't break the law to get lured.. Is there anyway in which we can use their emulator, probably hack the g1 emulator and reverse engineer the android market Slideme that is a market,has an old apache 2.0 licensed version I tried to compile it but needed the 1.1 SDK and my CPU had better things to do than compile the 1.1 SDK Denis. ___ 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
Latest Date Code
Hi, What is the latest date code behind the A7 phone .. Mine have 20090313 Thanks ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Latest Date Code
Hi, for the A7 units we sell, we have seen date codes between 200902xx and 200904xx. And as far as I know April was the time frame of the last production runs. It is also in coincidence with the OM announcement to close the development department and focus all company efforts on the Plan B = Wikireader. There are also enough units in stock. So if you plan a larger project based on the A7 hardware, you don't have to worry that there is suddenly no supply. And even if someone just buys a single unit (produced in Spring 2009) it will support the development of future open hardware. Best regards, Nikolaus Am 07.11.2009 um 19:08 schrieb shamsul hassan: Hi, What is the latest date code behind the A7 phone .. Mine have 20090313 Thanks ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Mobile Office Solutions by Golden Delicious Computers GmbHCo. KG Buchenstr. 3 D-82041 Oberhaching +49-89-54290367 http://www.handheld-linux.com AG München, HRA 89571 VAT DE253626266 Komplementär: Golden Delicious Computers Verwaltungs GmbH Oberhaching, AG München, HRB 16602 Geschäftsführer: Dr. Nikolaus Schaller Digital Tools for Independent People ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Free runner opened up
So anyone had success in separating the LCD panel from the touch screen and the back lit? Sriranjan On Wed, Aug 26, 2009 at 4:25 AM, Thomas HOCEDEZ thomas.hoce...@free.frwrote: Michal Brzozowski a écrit : 2009/8/26 David Garabana Barro da...@garabana.com mailto:da...@garabana.com On Wednesday 26 August 2009 13:07:55 Helge Hafting wrote: Ben Wilson wrote: I dunno about the freerunner but with gta01 it shipped with a guitar pick to be used to pry the case open without damaging the plastic :) The freerunner is easy enough to open with a fingernail. Or with a Credit Card if you eat your fingernails ;) Don't you have to remove those little screws first? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Yes, of course ! First unscrew the 2 little Torx screws... If no you will injure you credit cards and doing so, eating your nails ! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Free runner disassembly guide
Hi, Is there a free runner disassemble guide?Also was any one able the open the LCD and separate it into Touch panel,Backlit and the color screen?Please let me know. Thanks and Regards Sriranjan ___ 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: Free runner disassembly guide
RANJAN infi...@gmail.com writes: Is there a free runner disassemble guide? If you search the wiki for Neo1973 (aka gta01) disassembly guide, you'll find what you need. The instructions are the same for both gta01 and gta02. Also was any one able the open the LCD and separate it into Touch panel,Backlit and the color screen?Please let me know. I don't think anyone ever tried. If you do, please share the results. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Free runner disassembly guide
I don't think anyone ever tried. If you do, please share the results. Hi, Was able to remove the LCD from the metal sandwich kind casing.But there are two cords (highly delicate and flexible) which run from the LCD to the mother board.One is shielded with some sort or metal tape which I did remove and the other is glued. Please advice. Sriranjan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Free runner disassembly guide
Hi, you can remove the LDC module (LCD + Touch) by removing the silver tape and opening the Hirose FPCB plug. But I have no idea how to open the combined LCD+Touch-Module. Most likely you will destroy it. Maybe this helps: http://wiki.openmoko.org/wiki/TPO_TD028TTEC1 Nikolazs Am 07.11.2009 um 21:36 schrieb RANJAN: I don't think anyone ever tried. If you do, please share the results. Hi, Was able to remove the LCD from the metal sandwich kind casing.But there are two cords (highly delicate and flexible) which run from the LCD to the mother board.One is shielded with some sort or metal tape which I did remove and the other is glued. Please advice. Sriranjan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Free runner disassembly guide
Hi, Please keep the list Cc'd on useful discussions! Adding Cc back in assumption you dropped it by mistake. Also please follow a well-established tradition to use the ``'' symbol for quotations instead of indenting text. On Sat, Nov 07, 2009 at 12:30:59PM -0800, RANJAN wrote: On Sat, Nov 7, 2009 at 12:10 PM, Paul Fertser [1]fercer...@gmail.com wrote: RANJAN [2]infi...@gmail.com writes: Is there a free runner disassemble guide? If you search the wiki for Neo1973 (aka gta01) disassembly guide, you'll find what you need. The instructions are the same for both gta01 and gta02. Also was any one able the open the LCD and separate it into Touch panel,Backlit and the color screen?Please let me know. I don't think anyone ever tried. If you do, please share the results. Was able to remove the LCD from the metal sandwich kind casing.But there are two cords (highly delicate and flexible) which run from the LCD to the mother board.One is shielded with some sort or metal tape which I did remove and the other is glued. The flat cable with a small flexible shield glued on top of it is the one connecting the LCD Module (LCM) to the board. If you unlock the connector you'll be able to easily disconnect it. As to the links inside the LCM, that's an unknown territory, any reports (preferrably with photos) are appreciated. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Free runner disassembly guide
But I have no idea how to open the combined LCD+Touch-Module. Most likely you will destroy it. Maybe this helps: The touch resistive layer is on the top metal case and the color LCD is kind of sandwiched between the Resistive later which is pasted to the metal frame and the back lit is hooked to the frame.(I may be successful in releasing the hooks). But my query is :how is the LCD layer connected? And how do you remove the Hirose connector? Sriranjan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Free runner disassembly guide
The flat cable with a small flexible shield glued on top of it is the one connecting the LCD Module (LCM) to the board. If you unlock the connector you'll be able to easily disconnect it. As to the links inside the LCM, that's an unknown territory, any reports (preferrably with photos) are appreciated. Hirose Unlocked. Sriranjan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[ALL] will the owner of the stopwatch application please report to the front desk
list, ive just seen on opkg.org that someone added a stopwatch/countdown application. http://www.opkg.org/package_300.html they say they did not write the program, just added it. only they are nameless. i am looking for the actual writer of the application. anyone know? mike, are you the creator? http://www.mikecrash.com/index.php?name=Newsfile=articleid=103 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Free runner disassembly guide
On Sat, Nov 07, 2009 at 01:39:33PM -0800, RANJAN wrote: I don't think anyone ever tried. If you do, please share the results. Attached are the pics of LCD opened (still the touch layer is to be separated from the backlit). Good pics you've got there but i'm afraid that being attached to the mails they won't reach the mailing list. So if you want to share them you need to put them on some server. Also i'm unsure if cross-posting to both devel and community makes sense, probably we should continue on devel only. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] will the owner of the stopwatch application please report to the front desk
Hi, I know who wrote it and he will propably reply soon - otherwise I will tell him on monday personally ;-). In the meanwhile you can find the source here [1] and bb recipe here [2] if that helps. Btw I have it running on SHR-U currently... [1] http://git.senfdax.de/?p=stopwatch;a=summary [2] http://git.senfdax.de/?p=oe_recipes;a=tree;f=stopwatch list, ive just seen on opkg.org that someone added a stopwatch/countdown application. http://www.opkg.org/package_300.html they say they did not write the program, just added it. only they are nameless. i am looking for the actual writer of the application. anyone know? mike, are you the creator? http://www.mikecrash.com/index.php?name=Newsfile=articleid=103 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] will the owner of the stopwatch application please report to the front desk
On Sat, Nov 7, 2009 at 2:02 PM, Christian Rüb christian.r...@gmx.net wrote: Hi, I know who wrote it and he will propably reply soon - otherwise I will tell him on monday personally ;-). In the meanwhile you can find the source here [1] and bb recipe here [2] if that helps. Btw I have it running on SHR-U currently... yep, works good. will wait for there [possible] reply ___ 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: Some questions about android on Freerunner
Are you able to download a different openmoko distribution, like SHR? http://build.shr-project.org/shr-unstable/images/om-gta02/ Yes , please guide on those questions nothing esle , no SHR no using proxy and other things : 4 - You said codes (stable) are also on repository so just we lack wiki and issue tracking Yes ? Is there any other wiki/any thing else that has wiki efficient for beginners at all is it necessary ? What does issue tracking mean and is there any other site for issue tracking ? *ultimately what problems will a android user be faced without using code.google.com* and d.android.com ? 5- Why wiki and issue tracking are on google , can not be on other host? what is wiki license ? maybe it can be copy on other host ? Or is not it possible to replace Host ? 6-What is this address http://source.android.com/download for ? Does it host codes also ? and why android.com is not forbidden for Iranians ? Paul Fertser , Your comment has been read but answers for above questions is required . Regards dehqan ___ 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: Looking for a convenient tool
2009/11/7 ri...@happyleptic.org: I'm looking for a program that, given a set of shell commands, display a gtk window with a button that runs each command. I have looked at zenity but it apparently lacks the button widgets. Do you know of something similar, or should I write it myself ? have a look at gtkdialog - it's similar to zenity, but far more flexible and powerful ___ 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: Some questions about android on Freerunner
On Sun, 8 Nov 2009 07:41:53 +0330 a dehqan dehqa...@gmail.com wrote: Are you able to download a different openmoko distribution, like SHR? http://build.shr-project.org/shr-unstable/images/om-gta02/ Yes , please guide on those questions nothing esle , no SHR no using proxy and other things : 4 - You said codes (stable) are also on repository so just we lack wiki and issue tracking Yes ? Is there any other wiki/any thing else that has wiki efficient for beginners at all is it necessary ? What does issue tracking mean Keeping track of software development. For example when you find a problem with some software you create an issue in the issue tracker. When the issue is fixed you close the issue. and is there any other site for issue tracking ? Lots. sourceforge.net is one such site. *ultimately what problems will a android user be faced without using code.google.com* and d.android.com ? Android users don't need the issue tracker. They should just need to install an image and use the phone. The issue tracker and wiki would only be important as a reference if they needed to solve a problem with the phone. 5- Why wiki and issue tracking are on google , can not be on other host? what is wiki license ? maybe it can be copy on other host ? Or is not it possible to replace Host ? You can put a wiki on any system. There are many free wiki applications. For example mediawiki.org 6-What is this address http://source.android.com/download for ? Does it host codes also ? and why android.com is not forbidden for Iranians ? If you mean why android.com is not forbidden for Iranians the my answer is I don't see why it should be. Please tell us what you are trying to accomplish. You will get better advice that way. Regards, -- Michael Smith Network Applications www.netapps.com.au | +61 (0) 416 062 898 Web Hosting | Internet Services signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Some questions about android on Freerunner
In The Name Of God The compassionate merciful Good day everyone ; Thanks for your attentions ; See it's required to know whether fater buying freerunner can android be used or not . Android users don't need the issue tracker. They should just need to install an image and use the phone. The issue tracker and wiki would only be important as a reference if they needed to solve a problem with the phone. So an end-user need that wiki and issue tracking , if not , how does he/she solve his/her android problems on freerunner ? can he/she use here/other communities instead of code.google.com issue tracking ? 5- Why wiki and issue tracking are on google , can not be on other host? what is wiki license ? maybe it can be copy on other host ? Or is not it possible to replace Host ? You can put a wiki on any system. There are many free wiki applications. For example mediawiki.org Will Google admin of code.google.com make a mirror for free runner codes who is he/she ? If you mean why android.com is not forbidden for Iranians the my answer is I don't see why it should be. why ? cause of a.android.com is forbidden . and Does sorce.android.com contain whatever d.android.com contains ? Regards dehqan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] will the owner of the stopwatch application please report to the front desk
Hi Jeremy, I wrote this application. How can I help you? Kind regards, Christof On Sat, Nov 07, 2009 at 01:10:25PM -0800, jeremy jozwik wrote: list, ive just seen on opkg.org that someone added a stopwatch/countdown application. http://www.opkg.org/package_300.html they say they did not write the program, just added it. only they are nameless. i am looking for the actual writer of the application. anyone know? mike, are you the creator? http://www.mikecrash.com/index.php?name=Newsfile=articleid=103 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community pgpI8bnA1lZtS.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
