RE: Left high-and-dry by Nokia/Ovi store :(
actually Quim already had asnwered chapeu Cheers, Igor From: maemo-developers-boun...@maemo.org [maemo-developers-boun...@maemo.org] On Behalf Of Stoppa Igor (Nokia-D/Helsinki) Sent: 18 November 2009 09:48 To: code...@gmail.com; maemo-developers@maemo.org; Gil Quim (Nokia-D/Helsinki) Subject: RE: Left high-and-dry by Nokia/Ovi store :( hi, maybe Quim can help you, although this is probably not his turf. Cheers, Igor From: maemo-developers-boun...@maemo.org [maemo-developers-boun...@maemo.org] On Behalf Of ext Jonathan Blake [code...@gmail.com] Sent: 17 November 2009 23:00 To: maemo-developers@maemo.org Subject: Left high-and-dry by Nokia/Ovi store :( I'm cross posting this from the TMO forums after suggestion, apologies to anyone who has already read what I have to say. -- Having faithfully paid the 50 euros to register with Ovi Publishers several days ago, I have been happily working on my upcoming application, preparing for the release of the new N900 store which I was assured is in the last stages of finalization. I have spent many years in Canada operating doing very legitimate and legal development as a sole proprietor, as long as one pays taxes, there is no necessity to incorporate as a company, as this is recognized as an important element of trade (not everyone who does business can or will incorporate). Today my Nokia Store / Ovi Publisher account was disabled and locked out, because I am not a corporation. Nokia does not recognize individuals or sole proprietorship as valid business entities, and as such only corporations may publish through the Ovi store. Needless to say, as a legitimate businessman, I feel incredibly let down by Nokia, and the Ovi policies. These policies are going to prevent 95% of application developers from publishing through nokia, leaving only the choice of giving our work away for free (which is fine if you're into that), or trying to establish an independent distribution channel which is going to be incredibly difficult. Nokia should ensure that they either recognise sole proprietorships as legitimate business entities, or make it very clear - and i mean 72px font clear, that they do not allow individuals to publish through the store. I moved over from Apple because of their policies and increasingly corporation-centric publishing rules. I'm really sad to say that it looks like I made a mistake, and without a distribution channel, Nokia has left me, and many other future application developers high and dry. I know I'm feeling emotional, but right now I just feel like forgetting I ever heard about the N900. This sucks [http://talk.maemo.org/images/smilies/frown.gif] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mails about ratings from Downloads
On Wed, 2009-11-18 at 00:12 +, Valerio Valerio wrote: seems that is still possible to vote trough Maemo-select without login, I'm still getting a lot of rating from anonymous, most of the times a bunch of them as described by Conny. It's also possible to vote anonymously via maemo.org Downloads. I was looking into why the votes come in batches of 5-10 votes at a time and it probably has to do with the (super) slow response times of the web interface + that the backend does not check whether or not someone already voted. This check seems to be only implemented on the frontend level. So what happens it this: 1) User clicks on Vote 2) Browser sends data to server inserts it into the database sends out email etc... 3) Server needs several minutes to prepare and send back updated html (or js) to the client. Between 2) and 3) the user clicks the Vote button again because nothing happened for 10 seconds or so. Again the vote data is sent to the server, inserted in the DB etc... Then still nothing happens and the user clicks Vote again and again and again. You get lots and lots of votes, all with the same rating from the same person :) I actually tried that and gave my app 3 anonymous votes in a row without problems. The result is, that, for example, Conboy for Fremantle now has 74 votes with 284 downloads. Wow that's user participation ;) In reality I think Conboy got around 7 unique votes. Cheers! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to create a desktop applet
On Wed, 2009-11-18 at 09:19 +0100, ext ibrahim wrote: Kimmo Hämäläinen wrote: On Tue, 2009-11-17 at 18:31 +0100, ext ibrahim wrote: daniel wilms wrote: Hi I can't seem to find the APIs needed to do such thing. where should a look to find something like that? there is a good tutorial how to do that in the developer guide: http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Application_Development/Writing_Desktop_Widgets Hope that helps, cheers Daniel I tried the example, created a debian package out of the output, and installed it on the emulator and the n900 phone. BUT noting happened! th eapplication is installed but i can't see the applicatin name in the Add Widget menu from the Desktop menu. What am I missing ?? is there anything else i can do to make the home widget visible to the Add widget and the Desktop?? I haven't tried that, but libhildondesktop1-examples package has an example Home applet that worked for me. The package should be part of the SDK. The latest source is in the gitorious: http://maemo.gitorious.org/fremantle-hildon-desktop/libhildondesktop -Kimmo Didn't work either. Maybe there is something wrong with the way i create packages: the steps i take to create the package are : 1. compile the source and header using gcc inside scratchbox * gcc -shared 'pkg-config hildon-1 libhildondesktop-1 --libs --cflags' example.c example.h -o output.so 2. create the folder structure : data/usr/lib/ and put the output.so file inside it 3. create the folder : data/usr/share/applications/hildon-home and put the .desktop file inside it 4. create the DEBIAN/control file and supply the package information in it 5. rename the parent folder to : appname-version|| 6. |run the command : dpkg-deb --build app-folder| 7. then setup the package to the emulator using dpkg -i packagename.deb 8. in the emulator; press on the upper area of the desktop, and enter the desktop menu 9. click on the Desktop menu --- add widget --- didn't find my application name in the widgets menu !!! what's wrong with what i've done ?? can anybody help? Easier way: 1) git clone git://gitorious.org/fremantle-hildon- desktop/libhildondesktop.git (you can do this also outside Scratchbox), or: 1) apt-get source libhildondesktop1 2) cd libhildondesktop 3) dpkg-buildpackage -rfakeroot -b (this builds the Debian package) 4) copy libhildondesktop1-examples_version_armel.deb to your N900 5) install it as root: dpkg -i libhildondesktop1- examples_version_armel.deb (hildon-home should notice the new .desktop file and list it in the dialog that you use to add applets on the Home view) -Kimmo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bug#6203, rotation and OHMD
Hi, ext Aniello Del Sorbo wrote: Is the purpose of OHMD ONLY to pause not whitelisted applications when rotating? As if it is so, I'd put a stop ohmd every time I run Xournal to make sure it rotates smoothly. It handles also audio policies and tries to make sure that you get your phone calls when the device is heavily loaded and some other minor things. Not something you may want to stop then. I'll wait for a fix. The policy configuration is in: /usr/share/policy/etc/current/syspart.conf As a temporary hack for your own device, you might try to modify that file as root and then do killall ohmd to restart it with the new policy. This way you get to decide what has the priority instead of it being dictated by Nokia. :-) In future there may be some way to install extra policies. NOTE: if this conf file has errors, ohmd isn't started and your device will most likely behave strangely as result (cannot play music etc). DISCLAIMER: if it breaks, you get to keep all the pieces. I.e. have an up to date backup of your data and be ready to reflash in the case that things really break. Modified policy is an untested configuration. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: The issue of version strings / improving Application manager view
Hi, Kallioinen Juha (Nokia-D/Helsinki) wrote: The problem is imho the Application manager, not the version numbers. What's the point of even displaying the version number in the Application manager's default view? I personally don't care about the version at all and I certainly won't remember if an application's version has been updated by looking at the list view. Am I alone with this opinion? Why do you need to see the version there? The update manager will gladly tell me if I have an older version installed and if I don't, won't I just install whatever the Application manager offers me? The alpha/beta/stable status would be interesting. I.e. is this a bugfix release or one with new buggy features? The package version can anyways be found from the package details page, where there's more space available for it too. A link to package page that opens Browser would be best I think. A much more interesting bit of data instead of the package version to be shown by default might be the date when the package was uploaded. Also the Application manager could use a 'show new packages' view. But these of course require changes to the Application manager and maybe even to apt/dpkg database to be able to show the package's date and are more difficult to implement than just making nicer version numbers. Maybe a nice version number could really just be the date the package was created. That would fulfill my first wish, but we'd lose the upstream version trackability :) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bug#6203, rotation and OHMD
Message: 13 Date: Tue, 17 Nov 2009 19:28:49 +0200 From: Eero Tamminen eero.tammi...@nokia.com Subject: Re: Bug#6203, rotation and OHMD To: ext Aniello Del Sorbo ani...@gmail.com Cc: maemo-developers@maemo.org maemo-developers@maemo.org Message-ID: 4b02dd51.3070...@nokia.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed It handles also audio policies and tries to make sure that you get your phone calls when the device is heavily loaded and some other minor things. - Eero Just to know. I see now this `ohmd` process in my 41-10. I did not get it, was this daemon improved or made worse in new firmware released lately? -- Sincerely, Eugene ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mails about ratings from Downloads
Just a quick note that there's a bug report at https://bugs.maemo.org/show_bug.cgi?id=6192 about the same issue for Maemo Select on maemo.nokia.com. Sharing proposals/workarounds/etc is probably welcome. :-) andre -- Andre Klapper (maemo.org bugmaster) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bug#6203, rotation and OHMD
2009/11/18 Eero Tamminen eero.tammi...@nokia.com: Hi, ext Aniello Del Sorbo wrote: Is the purpose of OHMD ONLY to pause not whitelisted applications when rotating? As if it is so, I'd put a stop ohmd every time I run Xournal to make sure it rotates smoothly. It handles also audio policies and tries to make sure that you get your phone calls when the device is heavily loaded and some other minor things. Not something you may want to stop then. I'll wait for a fix. The policy configuration is in: /usr/share/policy/etc/current/syspart.conf As a temporary hack for your own device, you might try to modify that file as root and then do killall ohmd to restart it with the new policy. This way you get to decide what has the priority instead of it being dictated by Nokia. :-) In future there may be some way to install extra policies. NOTE: if this conf file has errors, ohmd isn't started and your device will most likely behave strangely as result (cannot play music etc). DISCLAIMER: if it breaks, you get to keep all the pieces. I.e. have an up to date backup of your data and be ready to reflash in the case that things really break. Modified policy is an untested configuration. As commented on the Bug I won't touch anything, I may play with it, but I will have to just wait for a fix coming from you guys. You do realize that the ones that will get thumbs down for this will be us, third party developers as people will think it's Xournal and Conboy not properly developed. Indeed, Nokia Phone app rotates nicely. :) -- anidel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to create a desktop applet
On Nov 18, 2009, at 9:19, ibrahim wrote: Didn't work either. Maybe there is something wrong with the way i create packages: There isn't really a wrong or right way, just a way that works for you and allows the package to be installed according to policy. That said, there are some 'best practices' that will make your life easier. the steps i take to create the package are : 1. compile the source and header using gcc inside scratchbox * gcc -shared 'pkg-config hildon-1 libhildondesktop-1 --libs --cflags' example.c example.h -o output.so 2. create the folder structure : data/usr/lib/ and put the output.so file inside it 3. create the folder : data/usr/share/applications/hildon-home and put the .desktop file inside it 4. create the DEBIAN/control file and supply the package information in it You may want to look at dh-make. This program creates a whole bunch of skeleton files and directories which can provide a template for your package. You just have to edit the files you want and make them relevant to your package. The debian New Maintainers Guide describes this process in detail. You get the added benefit that your eventual package is installable on a number of OSes, like Ubuntu, Mepis, debian, etc. 5. rename the parent folder to : appname-version|| 6. |run the command : dpkg-deb --build app-folder| Like Kimmo mentioned, using dpkg-buildpackage is probably a best practice. I think this is the command used most often both in Maemo and in debian which means you will have lots of help if you run into some weird behavior. 7. then setup the package to the emulator using dpkg -i packagename.deb 8. in the emulator; press on the upper area of the desktop, and enter the desktop menu 9. click on the Desktop menu --- add widget --- didn't find my application name in the widgets menu !!! what's wrong with what i've done ?? can anybody help? I think following Kimmo's advice would be an excellent way to go. :-) Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to create a desktop applet
Hi. On Wed, 18 Nov 2009 10:19:09 +0200 ibrahim ibrahim@asgatech.com wrote: Didn't work either. Maybe there is something wrong with the way i create packages: the steps i take to create the package are : 1. compile the source and header using gcc inside scratchbox * gcc -shared 'pkg-config hildon-1 libhildondesktop-1 --libs --cflags' example.c example.h -o output.so 2. create the folder structure : data/usr/lib/ and put the output.so file inside it 3. create the folder : data/usr/share/applications/hildon-home and put the .desktop file inside it 4. create the DEBIAN/control file and supply the package information in it 5. rename the parent folder to : appname-version|| 6. |run the command : dpkg-deb --build app-folder| 7. then setup the package to the emulator using dpkg -i packagename.deb 8. in the emulator; press on the upper area of the desktop, and enter the desktop menu 9. click on the Desktop menu --- add widget --- didn't find my application name in the widgets menu !!! what's wrong with what i've done ?? can anybody help? If those instructions are complete you're storing the .so file in a wrong location (/usr/lib/). The .so files for a Home applet are stored in /usr/lib/hildon-desktop/ -- Daniel Martin Yerga http://yerga.net ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
how to change the language of the program during run time?
hello , i am trying to change the language during run time. i road the documentation of the localization http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Application_Development/Maemo_Localization i generated the *.po file using the command xgettext -f po/POTFILES.in -C -a -o po/template.po and then made a en_GB.po copy of the template then made the ar_Ar.po file which contain my localization the i generated the *.mo file using the following command msgfmt po/fi_FI.po -o debian/myapp/usr/share/locale/fi_FI/LC_MESSAGES/myapp.mo i made the path by hand and run the command so i get myapp.mo file i added the following line on the main before gtk_init() setlocale(LC_ALL, ar_AR); bindtextdomain(GETTEXT_PACKAGE, localedir); bind_textdomain_codeset(GETTEXT_PACKAGE, UTF-8); textdomain(GETTEXT_PACKAGE); i added the following line to configure.ac file ALL_LINGUAS=en_GB ar_AR i built a package and deployed it on N900 device when i setup the package i get the following error but i run the program with the following command LANGUAGE=ar_Ar myapp the application run and display my language but when i click on a button which contain the following code setlocale(LC_ALL, en_GB); it does not make any thing . i have two questions: 1- how to make my program launch with the desired language without the line LANGUAGE=ar_Ar myapp? 2- how to change the language during run time? thanks ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to change the language of the program during run time?
On Wed, Nov 18, 2009 at 03:48:11PM +0200, mohamed ismael wrote: hello , i am trying to change the language during run time. i road the documentation of the localization http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Application_Development/Maemo_Localization i generated the *.po file using the command xgettext -f po/POTFILES.in -C -a -o po/template.po and then made a en_GB.po copy of the template then made the ar_Ar.po file which contain my localization the i generated the *.mo file using the following command Just a quick note, the Arabic locale is 'ar' only not 'ar_AR', AFAIK there is no such glibc locale. -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bug#6203, rotation and OHMD
Hi, ext Eugene Antimirov wrote: It handles also audio policies and tries to make sure that you get your phone calls when the device is heavily loaded and some other minor things. Just to know. I see now this `ohmd` process in my 41-10. I did not get it, was this daemon improved or made worse in new firmware released lately? Better for known (pre-installed) applications, worse for unknown applications. The reason for this is that unknown applications have unknown resource usage so system policy treats them with more care. It's a bit of a chicken and egg problem. Changing the policy is slow iterative work requiring lots of testing that the policy change doesn't significantly worsen other use-cases in some situations (e.g. for things for which there are certain certification legal requirements). Developers can now experiment and report/discuss things which they would like policy to handle better (for certain classes of 3rd applications and their use-cases). I.e. in regards to 3rd party applications, the policies could be considered work-in-progress. Things that could potentially be done for 3rd party applications policy handling: - Default policy is improved in regards to unknown processes. It's yet unknown whether this can be done well enough without sacrificing the known functionality, that's why feedback is needed on the behavior of 3rd party application use-cases. - Applications themselves specify the required policy on install. This is extra work for apps, and requires extensive testing to guarantee that the policy they choose is good match for the application in all cases. (application doesn't leak or otherwise hog resources) - Some way for user to specify per-application policy. I'm sure power-users would like that... :-) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Upgrade Description and Package Interface fun
No, this is not an option IMHO, because the Upgrade Description would tell about things not present in the current version in extras. This only generates confusion. As long as this critical bug exists, Upgrade Description must not be considered mandatory for package updates in the extras-testing QA. Hopefully this bug gets fixed, soon. Martin 2009/11/18, Graham Cobb g+...@cobb.uk.net: On Tue, Nov 17, 2009 at 08:11:35AM +0100, Martin Grimme wrote: https://bugs.maemo.org/show_bug.cgi?id=6187 ? As long as this bug exists, I won't use the upgrade description field anymore. It is a serious bug (nothing that happens in extras-testing should ever affect the Downloads view which needs to be built from Extras only). But it seems like a mistake not to use the upgrade description. Packages which have a released version in Extras need to have an Upgrade Description. I would tend to assume the bug will be fixed and create the Upgrade Description to avod a tester making me down for not having an Upgrade Description. While the bug exists you could always make sure the Upgrade Description also contains enough information to tell someone who does not have it installed what it does. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bug#6203, rotation and OHMD
How about another XAtom (since we already have so many on Maemo ;) ) on the application window, saying I rotate well and quickly. ? The ohmd could take care of this atom and refrain from freezing the app during rotation, iff it is the currently visible one. Of course applications could lie about their rotation capabilities, but that's what we have the extras-testing QA for. Martin 2009/11/18, Eero Tamminen eero.tammi...@nokia.com: Hi, ext Eugene Antimirov wrote: It handles also audio policies and tries to make sure that you get your phone calls when the device is heavily loaded and some other minor things. Just to know. I see now this `ohmd` process in my 41-10. I did not get it, was this daemon improved or made worse in new firmware released lately? Better for known (pre-installed) applications, worse for unknown applications. The reason for this is that unknown applications have unknown resource usage so system policy treats them with more care. It's a bit of a chicken and egg problem. Changing the policy is slow iterative work requiring lots of testing that the policy change doesn't significantly worsen other use-cases in some situations (e.g. for things for which there are certain certification legal requirements). Developers can now experiment and report/discuss things which they would like policy to handle better (for certain classes of 3rd applications and their use-cases). I.e. in regards to 3rd party applications, the policies could be considered work-in-progress. Things that could potentially be done for 3rd party applications policy handling: - Default policy is improved in regards to unknown processes. It's yet unknown whether this can be done well enough without sacrificing the known functionality, that's why feedback is needed on the behavior of 3rd party application use-cases. - Applications themselves specify the required policy on install. This is extra work for apps, and requires extensive testing to guarantee that the policy they choose is good match for the application in all cases. (application doesn't leak or otherwise hog resources) - Some way for user to specify per-application policy. I'm sure power-users would like that... :-) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bug#6203, rotation and OHMD
Out of ignorance, why don't you guys simply allow only the foremost (i.e. the currently visible one) application to rotate and send the rotation event to the other apps AFTER the animation has completed. After all to switch from one app to the other we've got to go via the task switcher and that rotates to landscape mode anyway (at least until you put in support for rotation there as well, but still..) Aniello 2009/11/18 Martin Grimme martin.gri...@gmail.com: How about another XAtom (since we already have so many on Maemo ;) ) on the application window, saying I rotate well and quickly. ? The ohmd could take care of this atom and refrain from freezing the app during rotation, iff it is the currently visible one. Of course applications could lie about their rotation capabilities, but that's what we have the extras-testing QA for. Martin 2009/11/18, Eero Tamminen eero.tammi...@nokia.com: Hi, ext Eugene Antimirov wrote: It handles also audio policies and tries to make sure that you get your phone calls when the device is heavily loaded and some other minor things. Just to know. I see now this `ohmd` process in my 41-10. I did not get it, was this daemon improved or made worse in new firmware released lately? Better for known (pre-installed) applications, worse for unknown applications. The reason for this is that unknown applications have unknown resource usage so system policy treats them with more care. It's a bit of a chicken and egg problem. Changing the policy is slow iterative work requiring lots of testing that the policy change doesn't significantly worsen other use-cases in some situations (e.g. for things for which there are certain certification legal requirements). Developers can now experiment and report/discuss things which they would like policy to handle better (for certain classes of 3rd applications and their use-cases). I.e. in regards to 3rd party applications, the policies could be considered work-in-progress. Things that could potentially be done for 3rd party applications policy handling: - Default policy is improved in regards to unknown processes. It's yet unknown whether this can be done well enough without sacrificing the known functionality, that's why feedback is needed on the behavior of 3rd party application use-cases. - Applications themselves specify the required policy on install. This is extra work for apps, and requires extensive testing to guarantee that the policy they choose is good match for the application in all cases. (application doesn't leak or otherwise hog resources) - Some way for user to specify per-application policy. I'm sure power-users would like that... :-) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- anidel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bug#6203, rotation and OHMD
I see many use cases for those policies like an incoming phone call should work properly even while some app is doing heavy number crunching. However rotation is a different thing. I mean what's the objective? The rotation animation should be smooth even if something uses a lot of processing time? Fair enough. But pausing the _foreground_ application is hardly the solution. How about pausing all _background_ applications? The foreground application is the only application interested in the rotation. Therefore it already specifies explicitly that it can rotate. If I now write an application it's my duty to give the CPU some time while rotating. If I don't do this, _my_ application looks shitty and everyone will tell me. It's not the platform that gets a bad reputation, it's my app. So, if anything should get paused, it's all applications which are not white listed and which are not in the foreground. If I somehow missed the point, please tell me :) Cheers! Conny On Wed, 2009-11-18 at 18:07 +0200, Eero Tamminen wrote: Hi, ext Eugene Antimirov wrote: It handles also audio policies and tries to make sure that you get your phone calls when the device is heavily loaded and some other minor things. Just to know. I see now this `ohmd` process in my 41-10. I did not get it, was this daemon improved or made worse in new firmware released lately? Better for known (pre-installed) applications, worse for unknown applications. The reason for this is that unknown applications have unknown resource usage so system policy treats them with more care. It's a bit of a chicken and egg problem. Changing the policy is slow iterative work requiring lots of testing that the policy change doesn't significantly worsen other use-cases in some situations (e.g. for things for which there are certain certification legal requirements). Developers can now experiment and report/discuss things which they would like policy to handle better (for certain classes of 3rd applications and their use-cases). I.e. in regards to 3rd party applications, the policies could be considered work-in-progress. Things that could potentially be done for 3rd party applications policy handling: - Default policy is improved in regards to unknown processes. It's yet unknown whether this can be done well enough without sacrificing the known functionality, that's why feedback is needed on the behavior of 3rd party application use-cases. - Applications themselves specify the required policy on install. This is extra work for apps, and requires extensive testing to guarantee that the policy they choose is good match for the application in all cases. (application doesn't leak or otherwise hog resources) - Some way for user to specify per-application policy. I'm sure power-users would like that... :-) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bug#6203, rotation and OHMD
Hi, ext Aniello Del Sorbo wrote: why don't you guys simply allow only the foremost (i.e. the currently visible one) application to rotate and send the rotation event to the other apps AFTER the animation has completed. Background applications don't get the rotation / redraw messages at all. You can check this with xresponse and/or xev. (Fixing that in X and composite/window manager required a lot of work, but AFAIK applicable parts of this work are now in upstream.) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bug#6203, rotation and OHMD
Hi, ext Martin Grimme wrote: How about another XAtom (since we already have so many on Maemo ;) ) on the application window, saying I rotate well and quickly. ? The ohmd could take care of this atom and refrain from freezing the app during rotation, iff it is the currently visible one. Of course applications could lie about their rotation capabilities, but that's what we have the extras-testing QA for. The rotation case is a minor issue and I think it can be handled OK for unknown applications without this kind of kludges. Let's just hope we can get a fix for that included to the next release. The main issue with policy is handling of unknown processes in general and for that more feedback is needed. (A hint: MAFW is a known system service, so it's good to use that for music playback... Tracker use is a bit more problematic because it's resource usage can fluctuate pretty much according to content it processes and what kind of requests it gets. And policy daemon doesn't currently know whether foreground application needs tracker or not.) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bug#6203, rotation and OHMD
2009/11/18 Cornelius Hald h...@icandy.de: I see many use cases for those policies like an incoming phone call should work properly even while some app is doing heavy number crunching. However rotation is a different thing. I mean what's the objective? The rotation animation should be smooth even if something uses a lot of processing time? Fair enough. But pausing the _foreground_ application is hardly the solution. How about pausing all _background_ applications? The foreground application is the only application interested in the rotation. Therefore it already specifies explicitly that it can rotate. If I now write an application it's my duty to give the CPU some time while rotating. If I don't do this, _my_ application looks shitty and everyone will tell me. It's not the platform that gets a bad reputation, it's my app. So, if anything should get paused, it's all applications which are not white listed and which are not in the foreground. If I somehow missed the point, please tell me :) Cheers! Conny How dare you steal my words out of my hands before I even write them! No, I miss the point as well.. Aniello On Wed, 2009-11-18 at 18:07 +0200, Eero Tamminen wrote: Hi, ext Eugene Antimirov wrote: It handles also audio policies and tries to make sure that you get your phone calls when the device is heavily loaded and some other minor things. Just to know. I see now this `ohmd` process in my 41-10. I did not get it, was this daemon improved or made worse in new firmware released lately? Better for known (pre-installed) applications, worse for unknown applications. The reason for this is that unknown applications have unknown resource usage so system policy treats them with more care. It's a bit of a chicken and egg problem. Changing the policy is slow iterative work requiring lots of testing that the policy change doesn't significantly worsen other use-cases in some situations (e.g. for things for which there are certain certification legal requirements). Developers can now experiment and report/discuss things which they would like policy to handle better (for certain classes of 3rd applications and their use-cases). I.e. in regards to 3rd party applications, the policies could be considered work-in-progress. Things that could potentially be done for 3rd party applications policy handling: - Default policy is improved in regards to unknown processes. It's yet unknown whether this can be done well enough without sacrificing the known functionality, that's why feedback is needed on the behavior of 3rd party application use-cases. - Applications themselves specify the required policy on install. This is extra work for apps, and requires extensive testing to guarantee that the policy they choose is good match for the application in all cases. (application doesn't leak or otherwise hog resources) - Some way for user to specify per-application policy. I'm sure power-users would like that... :-) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- anidel Sent from London, Eng, United Kingdom ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
how can i change the language of my program during run time?
how can i change the language of my program during run time? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
