osso-statusbar-cpu Re: Beware Personal launcher
Santtu Lakkala wrote: Frantisek Dufka wrote: osso-statusbar-cpu does exactly this. With memory reporting turned off it is nice statusbar clock with black background. Once the background turns solid blue you know there is a problem :-) Actually it should have graphs of cpu and/or memory usage, not black background; there's just a bug I haven't fixed that causes it to be black by default. If you change the settings, it should start to work. Sorry for the confusion, it does have graph of CPU usage. I don't see any bug. I meant that in normal case CPU usage is pretty low so it is mostly black. BTW long time ago I got chinook version from http://people.debian.org/~tschmidt/maemo/chinook/osso-statusbar-cpu/ Yesterday I noticed there is also 0.7.x (since June 2008) with 'official' chinook support in maemo-hackers.org repository http://maemo-hackers.org/apt/pool/main/o/osso-statusbar-cpu/ Both of them work fine, they just look different. With default OS2008 theme I like a bit more the old 0.6.1 look with thin border :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How can I change the background color of a GtkButton when it is activated
Hi Yao, Yao Wang wrote: The default color when I pressed down the button is blue. I want to change the background color of button when it is pressed and recover its origin background color when it is released. The default colour for when the button is pressed is set by the GTK+ theme. I'd suggest changing the theme so that all buttons, when pressed, will be red. It's in general not a good idea to hack applications with hard-coded widget colours, and it's generally encouraged to write applications which are consistent with the rest of the environment. Hope this helps! Dave. -- maemo.org docsmaster Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Planet Maemo news from 01/01/1970
Hello, I have seen recently many news from 01/01/1970 in the planet maemo RSS feed. Is that a problem with my reader (akregator) or do others see this as well? Thanks, Rainer -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07157-734133 email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Planet Maemo news from 01/01/1970
On Tue, November 25, 2008 16:38, Rainer Dorsch wrote: Hello, Hi, I have seen recently many news from 01/01/1970 in the planet maemo RSS feed. Is that a problem with my reader (akregator) or do others see this as well? Thanks for reporting this issue. A fix has been applied, so it should look a lot better now. Thanks, Rainer -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Planet Maemo news from 01/01/1970
Hi, Rainer Dorsch wrote: I have seen recently many news from 01/01/1970 in the planet maemo RSS feed. Is that a problem with my reader (akregator) or do others see this as well? In recent days I have also seen items on Planet Maemo get syndicated many times into the feed. Is that the same issue, or a different one? Cheers, Dave. -- maemo.org docsmaster Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: RSS-reader issue
Hi, Am Montag 24 November 2008 schrieb Eero Tamminen: Did you have automatic RSS updates enabled? which release you were using? This happened a few days ago with the latest diablo on n810 with all updates installed. I think one of the RSS feeds had something that put RSS feed reader into a loop and it would be good to identify what that was. Do you have the rss feed colder contents backed up somewhere? I am a bad tester ... i did not save anything. But i barely used the reader and might be able to reproduce it. I'll give it a try. I think Youtube and some other Flash stuff can occasionally cause more than few minutes of 100% CPU usage normally. That's right. This may be circumvented if such applications explicitely register for this. Also mplayer may cause that. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Application Manager and Extras-devel: Dealing with unstable software
Let's say you've got a user, and this user wants to get to something shiny, but the only place this something shiny is available is from an unstable testing repository. Normally this unstable testing repository would not be the sort of place this user would venture into, but the application is only there because a few minor packaging issues have to be wrapped up (maybe the l10n is split up into a bunch of separate packages); or there's just a few more bugs they want to stomp out; or they want to give it a week or two of testing before they push it to the unstable repository--whatever, so the user decides (perhaps with the encouragement of some of their peers) to dive in, add the unstable repository and install the application. So the application installs and runs fine. Perhaps they encounter a few of those small bugs that are still being worked on, but nothing serious. A few weeks pass without issue, and they see a notification for some new updates to a few of their favorite applications, go to install them and BAM! one wont install due to a messed up postinst, the next now crashes on start and the last now randomly loses data. What happened? Developers using that unstable testing repository as an unstable testing repository uploaded some new unstable versions of their applications for some testing, and our poor user ended up as collateral damage. So the question is, what can we do to protect users from the full fury of Extras-devel while still giving them reasonable access to some of the stabler applications in the repository? Clearly there are a few issues at play here: developers moving software to Extras-devel before it's ready (critical crasher or data- lose bugs, etc), developers leaving applications in Extras-devel for too long (no real bugs, just sitting there unpromoted), and Extras lacking a finer granularity of stability levels. The first two can be dealt with (up to a point) through developer education, but the last can't really be addressed (although I'd be interested if there's any history or particular inertia behind the 2-tier setup we have now). Simple user education will also have a large effect (yes, you can install this, but disable this repository when you're done). Those issues aside, what can we do at an application level to improve the user experience here? An opt-in system for Extras-devel updates and installs might be useful (rather than offering the Extras-devel version, the user has to request it specifically), visual cues to a packages origin (color coding, a small icon) and notices might also help (this package is unstable software, and may contain many significant bugs, are you sure you want to install it?), or even some sort of apt pinning system to ignore certain updates. What are your ideas? -- Ryan Abel Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
the unstable repository--whatever, so the user decides (perhaps with the encouragement of some of their peers) to dive in, add the unstable repository and install the application. Use an install file to install the application in question? Assuming the application needs libraries which are contained in the extras-devel repo, you'd need to temporarily enable that repo. My feeling is that the repos enabled/added as part of install files should be disabled immediately after the app in question has been added in any case, so I suggest this change is made to the way Application Manager handles the install files. Would that achieve the desired goal? It would require that a list of application install files are available (perhaps auto-generated from the contents of the repo, or perhaps by the author in question?) packages origin (color coding, a small icon) and notices might also help (this package is unstable software, and may contain many significant bugs, are you sure you want to install it?), or even some sort of apt pinning system to ignore certain updates. I also like the idea of flagging applications that come from somewhere other than Extras, and I suppose it would be possible to have an Updates section with Stable and Unstable candidates in it (or perhaps allow updates to be sorted by their origin repo - and have Extras as the default origin). But these are still more for power users, simply disabling the repo immediately after use is imo a better bet for unskilled users. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
Hi. There's no way to avoid developers setting up their own repositories if they want to do it for whatever reason they might have. Having a temporary repository flag or keyword in the install file, would help as these developers could use a .install file that adds the temporary repositories, install the application, then removes the repository. Also external repositories or application that comes from external ones, could be colored in yellow (warning), not installable ones (AM knows that) in red and installable ones (from known repositories) in green. An External repository can be anything that is not from Nokia and not from Maemo. I have my Xournal diablo alpha version in the Extras-devel since a long time now and I had many users that installed it as they found the update when another application required the extras-devel repository, added it and left it there. AM could also implement filters. Show All applications, Applications from known repositories, Applications from external repositories. Sorry for not exposing the ideas in a better way, too late and tired. :) Aniello On Tue, Nov 25, 2008 at 10:16 PM, Simon Pickering [EMAIL PROTECTED]wrote: the unstable repository--whatever, so the user decides (perhaps with the encouragement of some of their peers) to dive in, add the unstable repository and install the application. Use an install file to install the application in question? Assuming the application needs libraries which are contained in the extras-devel repo, you'd need to temporarily enable that repo. My feeling is that the repos enabled/added as part of install files should be disabled immediately after the app in question has been added in any case, so I suggest this change is made to the way Application Manager handles the install files. Would that achieve the desired goal? It would require that a list of application install files are available (perhaps auto-generated from the contents of the repo, or perhaps by the author in question?) packages origin (color coding, a small icon) and notices might also help (this package is unstable software, and may contain many significant bugs, are you sure you want to install it?), or even some sort of apt pinning system to ignore certain updates. I also like the idea of flagging applications that come from somewhere other than Extras, and I suppose it would be possible to have an Updates section with Stable and Unstable candidates in it (or perhaps allow updates to be sorted by their origin repo - and have Extras as the default origin). But these are still more for power users, simply disabling the repo immediately after use is imo a better bet for unskilled users. Cheers, Simon ___ 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: Application Manager and Extras-devel: Dealing with unstable software
There should be a whitelist of applications to use from -devel with a method to add or select packages from within it. If I *choose* to get involved in the xournal beta testing and want to obtain it from -devel this should not effect the testing status of other applications which I am not focusing upon nor testing. This way only xournal will be listed as coming from -devel and nothing else. If at a later date I also wish to test out another cool application I could simply add that as well, but at no time would I get unexpected dangerous updates. gary (lcuk on #maemo) On Tue, Nov 25, 2008 at 11:04 PM, Aniello Del Sorbo [EMAIL PROTECTED]wrote: Hi. There's no way to avoid developers setting up their own repositories if they want to do it for whatever reason they might have. Having a temporary repository flag or keyword in the install file, would help as these developers could use a .install file that adds the temporary repositories, install the application, then removes the repository. Also external repositories or application that comes from external ones, could be colored in yellow (warning), not installable ones (AM knows that) in red and installable ones (from known repositories) in green. An External repository can be anything that is not from Nokia and not from Maemo. I have my Xournal diablo alpha version in the Extras-devel since a long time now and I had many users that installed it as they found the update when another application required the extras-devel repository, added it and left it there. AM could also implement filters. Show All applications, Applications from known repositories, Applications from external repositories. Sorry for not exposing the ideas in a better way, too late and tired. :) Aniello On Tue, Nov 25, 2008 at 10:16 PM, Simon Pickering [EMAIL PROTECTED] wrote: the unstable repository--whatever, so the user decides (perhaps with the encouragement of some of their peers) to dive in, add the unstable repository and install the application. Use an install file to install the application in question? Assuming the application needs libraries which are contained in the extras-devel repo, you'd need to temporarily enable that repo. My feeling is that the repos enabled/added as part of install files should be disabled immediately after the app in question has been added in any case, so I suggest this change is made to the way Application Manager handles the install files. Would that achieve the desired goal? It would require that a list of application install files are available (perhaps auto-generated from the contents of the repo, or perhaps by the author in question?) packages origin (color coding, a small icon) and notices might also help (this package is unstable software, and may contain many significant bugs, are you sure you want to install it?), or even some sort of apt pinning system to ignore certain updates. I also like the idea of flagging applications that come from somewhere other than Extras, and I suppose it would be possible to have an Updates section with Stable and Unstable candidates in it (or perhaps allow updates to be sorted by their origin repo - and have Extras as the default origin). But these are still more for power users, simply disabling the repo immediately after use is imo a better bet for unskilled users. Cheers, Simon ___ 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 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
investiganting a hildonization bug (open loadopt file: permission denied)
Hello there, I'm writing my very first Python application using the PyQt4 packages which another brazilian, Luciano Wolf, announced last september (IIRC). I know the code linked below is pretty crappy but I've found a weird problem while Hildonizing my app. Astmontray is a systray applet with a very simple menu layout that I wrote following both Python and Qt4 documentation and seems to work fine on my Macbook running Leopard, my Mandriva 2009.0 box and Maemo Diablo. Despite its source everything seems to be running alright. However, on Diablo the context menu is not Hildonized (by that I mean it does not look like the rest of the environment, it has a raw Qt4 appearance). That happens every time I run the app after a sudo gainroot, but if I run the app as a regular user I get the following message in terminal: Open loadopt file: Permission denied Even though I get this message every time I run it, it misteriously works AND get properly Hildonized. How come? Any ideas? Is it known or am I missing something obvious here? I wouldn't doubt that, btw. The current code is freely available at: http://caio.ueberalles.net/svn/voip/asterisk/astmontray/ []s Caio Begotti ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
i do not think there is ever a perfect way for anything. there are many points which intersect and by discussion we will find that common ground :) using the .install file to opt-in to a testing program is great, opting back out is trickier, it would have to be something on the update information screen itself. there is also the problem with dependencies, but they could be handled in a similar manner. gary On Tue, Nov 25, 2008 at 11:40 PM, Aniello Del Sorbo [EMAIL PROTECTED]wrote: This could be a way. One could also think about using a new keyword for the .install file, i.e. for ex. stability_level = level, that can be set to: 0 alpha (marked red) 1 beta (marked yellow) 2 stable (marked green) And AM can be configured to show only levels from 0, from 1 or from 2 (default). There are plenty of ways... Perhaps a mix of them hides the perfect solution. Aniello On Tue, Nov 25, 2008 at 11:22 PM, gary liquid [EMAIL PROTECTED] wrote: There should be a whitelist of applications to use from -devel with a method to add or select packages from within it. If I *choose* to get involved in the xournal beta testing and want to obtain it from -devel this should not effect the testing status of other applications which I am not focusing upon nor testing. This way only xournal will be listed as coming from -devel and nothing else. If at a later date I also wish to test out another cool application I could simply add that as well, but at no time would I get unexpected dangerous updates. gary (lcuk on #maemo) On Tue, Nov 25, 2008 at 11:04 PM, Aniello Del Sorbo [EMAIL PROTECTED]wrote: Hi. There's no way to avoid developers setting up their own repositories if they want to do it for whatever reason they might have. Having a temporary repository flag or keyword in the install file, would help as these developers could use a .install file that adds the temporary repositories, install the application, then removes the repository. Also external repositories or application that comes from external ones, could be colored in yellow (warning), not installable ones (AM knows that) in red and installable ones (from known repositories) in green. An External repository can be anything that is not from Nokia and not from Maemo. I have my Xournal diablo alpha version in the Extras-devel since a long time now and I had many users that installed it as they found the update when another application required the extras-devel repository, added it and left it there. AM could also implement filters. Show All applications, Applications from known repositories, Applications from external repositories. Sorry for not exposing the ideas in a better way, too late and tired. :) Aniello On Tue, Nov 25, 2008 at 10:16 PM, Simon Pickering [EMAIL PROTECTED] wrote: the unstable repository--whatever, so the user decides (perhaps with the encouragement of some of their peers) to dive in, add the unstable repository and install the application. Use an install file to install the application in question? Assuming the application needs libraries which are contained in the extras-devel repo, you'd need to temporarily enable that repo. My feeling is that the repos enabled/added as part of install files should be disabled immediately after the app in question has been added in any case, so I suggest this change is made to the way Application Manager handles the install files. Would that achieve the desired goal? It would require that a list of application install files are available (perhaps auto-generated from the contents of the repo, or perhaps by the author in question?) packages origin (color coding, a small icon) and notices might also help (this package is unstable software, and may contain many significant bugs, are you sure you want to install it?), or even some sort of apt pinning system to ignore certain updates. I also like the idea of flagging applications that come from somewhere other than Extras, and I suppose it would be possible to have an Updates section with Stable and Unstable candidates in it (or perhaps allow updates to be sorted by their origin repo - and have Extras as the default origin). But these are still more for power users, simply disabling the repo immediately after use is imo a better bet for unskilled users. Cheers, Simon ___ 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 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- anidel ___
Re: Application Manager and Extras-devel: Dealing with unstable software
On Tue, Nov 25, 2008 at 11:46 PM, gary liquid [EMAIL PROTECTED] wrote: i do not think there is ever a perfect way for anything. there are many points which intersect and by discussion we will find that common ground :) Another ugly trick (hey, it's what I'm good at, coming up with dirty ideas) would be to have dynamic repositories. Now I know, it sounds crazy, just bear with me. This would only require server side scripting (mostly), and would allow for content updates directly to the end user, without having to manually check for the .install files. The way I see it, user lambda wants to see what's flying in the latest version of xournal, he adds the -devel repository for xournal. He gets the updates, no problems with dependencies (provided they are available from his current list of repositories). In case he wants to go back to the stable version, he simply removes the -devel repository, and after a refresh, his tablet is stable again. Obviously, most users would only use the standard Maemo repository, the dynamic repositories only need to be updated when a package goes through one of the builders, and can be part of the compilation process. This does impose as constraint that each and every package will have its own repository, unless we make the builders project aware, so that a specific project can tag multiple packages to be part of one single repository. Hey, I warned you, I'm dirty. My 2p, S. -- question = ( to ) ? be : ! be; -- Wm. Shakespeare ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How can I change the background color of a GtkButton when it is activated
Hi, Dave, Thanks for your advice. However, my objective is to set two different colors for two different buttons. That is to say, for button A, when it is pressed, the color should be red; while for button B, in this case, the color should be green. Thus I do not think the GTK+ theme can solve this problem. Is there any other possible solutions? Thanks in advance. On Tue, Nov 25, 2008 at 10:23 AM, Dave Neary [EMAIL PROTECTED] wrote: Hi Yao, Yao Wang wrote: The default color when I pressed down the button is blue. I want to change the background color of button when it is pressed and recover its origin background color when it is released. The default colour for when the button is pressed is set by the GTK+ theme. I'd suggest changing the theme so that all buttons, when pressed, will be red. It's in general not a good idea to hack applications with hard-coded widget colours, and it's generally encouraged to write applications which are consistent with the rest of the environment. Hope this helps! Dave. -- maemo.org docsmaster Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] -- Sincerely yours, Yao Wang Mobile Life Lab Beijing University of Posts Telecommunications ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How can I change the background color of a GtkButton when it is activated
What about connecting two signals to your button widget: pressed and released In the function for pressed change the background colour to blue. In the function for released change the background colour back to normal. http://library.gnome.org/devel/gtk/stable/GtkButton.html#GtkButton.signals I think this should do what you want, though I don't know if it is the optimal way. Andrew 2008/11/25 Yao Wang [EMAIL PROTECTED] Hi, Dave, Thanks for your advice. However, my objective is to set two different colors for two different buttons. That is to say, for button A, when it is pressed, the color should be red; while for button B, in this case, the color should be green. Thus I do not think the GTK+ theme can solve this problem. Is there any other possible solutions? Thanks in advance. On Tue, Nov 25, 2008 at 10:23 AM, Dave Neary [EMAIL PROTECTED] wrote: Hi Yao, Yao Wang wrote: The default color when I pressed down the button is blue. I want to change the background color of button when it is pressed and recover its origin background color when it is released. The default colour for when the button is pressed is set by the GTK+ theme. I'd suggest changing the theme so that all buttons, when pressed, will be red. It's in general not a good idea to hack applications with hard-coded widget colours, and it's generally encouraged to write applications which are consistent with the rest of the environment. Hope this helps! Dave. -- maemo.org docsmaster Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] -- Sincerely yours, Yao Wang Mobile Life Lab Beijing University of Posts Telecommunications ___ 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
Now Hiring: Maemo Community debmaster
(Cross-spam intentional.) For more details about this exciting new opportunity, please visit the Council blog post: http://maemo.org/community/council/now_hiring-maemo_community_debmaster/[1] If you have any questions, email [EMAIL PROTECTED] Tim --- http://tim.samoff.com Links: -- [1] http://maemo.org/community/council/now_hiring-maemo_community_debmaster/ [2] mailto:[EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: investiganting a hildonization bug (open loadopt file: permission denied)
Hi, If you want to run a graphical program as root, I find prefixing the command with run-standalone.sh works for me. Regards On Tue, Nov 25, 2008 at 11:46 PM, Caio Begotti [EMAIL PROTECTED] wrote: Hello there, I'm writing my very first Python application using the PyQt4 packages which another brazilian, Luciano Wolf, announced last september (IIRC). I know the code linked below is pretty crappy but I've found a weird problem while Hildonizing my app. Astmontray is a systray applet with a very simple menu layout that I wrote following both Python and Qt4 documentation and seems to work fine on my Macbook running Leopard, my Mandriva 2009.0 box and Maemo Diablo. Despite its source everything seems to be running alright. However, on Diablo the context menu is not Hildonized (by that I mean it does not look like the rest of the environment, it has a raw Qt4 appearance). That happens every time I run the app after a sudo gainroot, but if I run the app as a regular user I get the following message in terminal: Open loadopt file: Permission denied Even though I get this message every time I run it, it misteriously works AND get properly Hildonized. How come? Any ideas? Is it known or am I missing something obvious here? I wouldn't doubt that, btw. The current code is freely available at: http://caio.ueberalles.net/svn/voip/asterisk/astmontray/ []s Caio Begotti ___ 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
