Re: maemo-release
On Thu, Nov 12, 2009 at 06:11, Quim Gil quim@nokia.com wrote: [...] If the utilities are really useful [...] That still seems to be an outstanding question in my mind; what does maemo-release do that maemo-version doesn't? If it is something useful, is it going to be changed to return the right version numbers? Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Follow up from QA meeting on IRC
Hi, Edward Page wrote: To help remind people that there is a checklist and whats on it, should the rating page link to or include the criteria? I see there were no notes on the algorithm. A threshold of 10 was annoying as a developer. As a tester, a threshold of 10 made me feel more comfortable not doing a full blown /opt check or power management check because of 10 people I could hope someone else would do it and I could worry about other issues like application stability. With a smaller threshold I would feel more of a burden to do all of the steps which would discourage me. So I guess I'll share my idea. To me, it seems that one tester would probably be enough for /opt, power management, etc. If the categories were broken out, these could just require a net of +1 karma with a required comment to describe steps and results regardless of whether they gave an up or down. Net +1 is in case others disagree, they can vote it down. Required comments either way are to make people feel comfortable that it was tested properly and not just someone saying it works for me and voting it up. Ed's point definitely resonates with me. The great thing about QA is that you can crowd-source it effectively if you don't require much of the user/tester. It seems like the Maemo QA process is more developer-focussed than user-focussed at the moment, and is as such pushing a lot of the responsibility for the QA process to the user. This seems like an ideal opportunity to lower the barrier to participation to tiny levels, but only if it is 1. easy to give a +1/-1 2. We don't require intimate knowledge of the Maemo community for feedback (I'm thinking of the checklist, what optification means, etc) 3. We require enough feedback that most of the code paths in the application will be tested before we OK an application Lowering the threshold to 5 is implicitly saying we're not getting feedback quickly enough, which in turn is saying the feedback process is overly cumbersome for a casual user. It seems to me that that's the problem, rather than the contents of the checklist or the threshold in place. If giving feedback was trivially easy (as it is, for example, in Android Market) you would be getting hundreds of votes when new versions of applications are released, as people installed used them. So - how can we make giving the feedback and voting on applications easier? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-release
Hi, Quim Gil wrote: We are asking the renaming of pure end user apps called Maemo Something in order to avoid confusion of what is official and what is not. Just to be clear, when you say what is official, what do you mean? Is this applications shipped with the device by default? Or applications created by Nokia? Or applications in the Nokia applications repository? I'd like to think that eventually, applications written by anyone in the community can become official and be installed by default in future Maemo devices, if they prove themselves capable. Cheers, Dave. (For the rest, I agree - if we're not talking about user-targetted apps, the impact is small - I just want to clarify the meaning of the often-used word official) -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-release
Andrew Flegg wrote: That still seems to be an outstanding question in my mind; what does maemo-release do that maemo-version doesn't? If it is something useful, is it going to be changed to return the right version numbers? I also wonder what is the result. Gabriel, can you let us know what are your plans? IMO maemo-version should stay, old SDK versions should stay too to prevent confusion (i.e. gregale being 2.2 etc.) and the http://wiki.maemo.org/Maemo-releases or other documentation should stay too but use maemo-version instead. Someone helped me to discover maemo-version only recently and until now I planned only to read /etc/maemo_version in my debian/rules. The idea about using it in Build-Depends was new to me, thanks for that. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-release
ext Dave Neary wrote: Hi, Quim Gil wrote: We are asking the renaming of pure end user apps called Maemo Something in order to avoid confusion of what is official and what is not. Just to be clear, when you say what is official, what do you mean? A piece of software that Nokia is responsible of, and therefore customers can complain to Nokia about. Is this applications shipped with the device by default? Or applications created by Nokia? Or applications in the Nokia applications repository? I'd like to think that eventually, applications written by anyone in the community can become official and be installed by default in future Maemo devices, if they prove themselves capable. Cheers, Dave. (For the rest, I agree - if we're not talking about user-targetted apps, the impact is small - I just want to clarify the meaning of the often-used word official) -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
JSON libs @ Maemo
Hi, I will know if someone is using the JSON format in Maemo. I was checking the packages repositories and only libjson-glib-1.0-0 python-simplejson is ported. I was porting/using the last weekend json-c in N900 ( I didn't upload to extras repositories yet ). But my question is if somebody is using QJson ( http://qjson.sourceforge.net/ ) in Maemo. Also it will be nice know if somebody is using other JSON libraries in Maemo differents of the last mentioned. Cheers, Adrian. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
maemo stars inconsistent between popular list and single application view.
Hay, the subject tells the problem: e.g. maemo5 popular list for OMWeather (the first) it has three stars on the popular list, but a little less than four stars if one views the application directly: http://maemo.org/downloads/product/Maemo5/omweather/ It seems you round the stars down to the next integer?! Detlef ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: change profile state
http://www.gossamer-threads.com/lists/maemo/developers/54784 On Thu, Nov 12, 2009 at 03:16:03PM +0200, mohamed ismael wrote: dear all, how can i change the profile state (silent, general) in maemo 5 i am using hildon thanks. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- import sig ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: popularity-contest (was Re: Follow up from QA meeting on IRC)
On Nov 12, 2009, at 6:15, Quim Gil wrote: Hi, ext Edward Page wrote: Which reminds me, any reason Maemo doesn't use Debian's popularity contest? At least at a community level there is https://garage.maemo.org/projects/popcon/ Bas (the founder of that project) and I have been discussing how to implement this. debian's popularity contest is definitely going to be used at the very least as inspiration, but hopefully its code as well. Right now it spends a lot of time trying to determine the last time a tool was used and that may be more relevant to a server environment than a mobile device. What I had hoped to do was to 1. Create a md5 or sha1 hash of the device's MAC addres and IMEI as unique identifier which cannot be tracked back 2. Check which repos the device is using, to see where the software comes from 3. Ask dpkg what is installed 4. Aggregate the dpkg output and rank that, roughly like popcon but perhaps doing some other cool things I want to preserve as much privacy as possible on the device so anyone who participates is not identified. I know that I can only obfuscate data, not hide it completely, so I strongly feel this project should come with the advice that you may not want to use it. It also should not be a Nokia project because it is bad if Nokia is gathering information surreptitiously on its users. So let me be clear: this is a community project that is completely voluntary! Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
libprofile
how can i find the library libprofile ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: libprofile
Hi, you have to install the dev-package of libprofile in the SDK: apt-get install libprofile-dev and then you will find the header-files in: /usr/include/profiled/ Cheers Daniel ext mohamed ismael wrote: how can i find the library libprofile ___ 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: Follow up from QA meeting on IRC
On Nov 12, 2009, at 9:17, Dave Neary wrote: Hi, Edward Page wrote: To help remind people that there is a checklist and whats on it, should the rating page link to or include the criteria? Yes - that makes sense. I see there were no notes on the algorithm. A threshold of 10 was annoying as a developer. As a tester, a threshold of 10 made me feel more comfortable not doing a full blown /opt check or power management check because of 10 people I could hope someone else would do it and I could worry about other issues like application stability. With a smaller threshold I would feel more of a burden to do all of the steps which would discourage me. Ed's point definitely resonates with me. The great thing about QA is that you can crowd-source it effectively if you don't require much of the user/tester. It seems like the Maemo QA process is more developer-focussed than user-focussed at the moment, and is as such pushing a lot of the responsibility for the QA process to the user. QA is logically the next step after development and is often done by an engineer, at least in the corporate world. Even in maemo, those who do QA so far have also been developers; either they have done QA on their own package or they have done it informally for other's and use the extras-testing interface. In short - the expectation is that you are pretty deep into maemo. This seems like an ideal opportunity to lower the barrier to participation to tiny levels, but only if it is 1. easy to give a +1/-1 Well, we need to keep this distinct from merely rating the package. We are not rating here, we are promoting quality packages. You may be asked to promote a package you think frivolous, but if it meets the technical criteria you are asked to promote it. 2. We don't require intimate knowledge of the Maemo community for feedback (I'm thinking of the checklist, what optification means, etc) Feedback is welcome through a variety of means - rating the package with stars on the download page is one for example. Feedback is welcome in QA too, but let's not pretend that this isn't a serious technical process requiring at least some knowledge of the underlying operating system and perhaps the package system and even how the development process works (on a high level). We need to insure that those who are doing QA, can handle the technical demands so that the software does not damage the device and maemo's reputation. This really does require a clear specification, i.e. checklist, and knowing what optification means in the maemo context. 3. We require enough feedback that most of the code paths in the application will be tested before we OK an application Lowering the threshold to 5 is implicitly saying we're not getting feedback quickly enough, I think it is really saying that the bar is currently set to high. which in turn is saying the feedback process is overly cumbersome for a casual user. Yes and it should be. This is critically important and has serious implications and technical challenges. Anyone at all is welcome, but you may need to learn some stuff about the QA process. The QA process is hard because developing is hard, writing code is hard, integrating into an OS is hard - we need to make sure those things work. It seems to me that that's the problem, rather than the contents of the checklist or the threshold in place. If giving feedback was trivially easy (as it is, for example, in Android Market) you would be getting hundreds of votes when new versions of applications are released, as people installed used them. We need a separate mechanism for this then, perhaps this is similar to the app rating system we already have on downloads? So - how can we make giving the feedback and voting on applications easier? I don't think the idea of Quality Software fits with the idea of Easy to do. Exhibit A: Windows. Many developers are familiar with this saying said to management only half in jest: Quality, Time, Cost - pick two. Seriously, we don't want people surfing by and clicking pejoratively. We need a set of serious technical criteria to assure quality software, not a warm and fuzzy interface where the hoi polloi randomly click shiny buttons. Jereamiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
On Nov 12, 2009, at 4:50, Graham Cobb wrote: On Wed, Nov 11, 2009 at 04:29:55PM +0200, Marius Vollmer wrote: ext Thomas Perl th.p...@gmail.com writes: The following is a rant about XB-Maemo-Upgrade-Description with some suggestions for improvement... Yeah, as soon as I 'invented' it, I could see how it is not going to work very well. I actually think it is best to ignore this field. Actually, I disagree. I don't see this field as being anything like a changelog. It is an alternative description to display to someone who already has the program installed and hence, probably, already knows what it does any why they should install it but does not know whether they should bother to install this particular release. So, for a security update it would contain text something like: This is an important security update that should be installed as soon as possible. This is what the changelog was designed for. The control file should not be for messages but rather more like a compiled file that just happens to be text, users should not be reading it. According to debian policy source package control files only have five _mandatory_ fields. This means it is very unlikely that any X-* random header we invent will be used upstream or even downstream, and we are encouraging non-standard control files which may make Mer do non-standard stuff etc. We want compatibility across projects, therefor compatibility of control files across projects. I.e. a package built on Mempis should 'just work' on Maemo, Ubuntu, etc. Bunches of header files in the control file pollutes that namespace and makes compatibility harder, let's use the changelog. For beta-testing releases (releases that will never be promoted beyond extras-testing) I do use it to describe the user-visible changes since the last full release, including bug numbers fo fixed bugs. However, for real releases (which will get promoted into Extras) I use it to give a general view of the release. For example, for a (fictional) 2.7.4 release, the text might read: This update contains many bug fixes since version 2.7, particularly in import and export capabilities. The only change since 2.7.3 is a fix to Edit menu handling in portrait mode. My suggestion is to either use the Debian changelog, or if this sounds too technical for the end user, agree on some way to mark user-relevant changes in the Debian changelog (by using USER: as a prefix for a one-line summary or by having a convention of having the first entry in the Debian changelog be a user-friendly summary of all changes) and then parse the changelog and display all user-relevant changes in the AppMgr. Yes, we pretty much have to have a full list of changes and the Application manager then can display the relevant ones. The apt-listchanges program does this for Debian. But the audiences are completely different. changelog's are not documentation. They are documentation. Documentation for the builders of the software. Just as the header file is not suitable user documentation, changelogs are not suitable upgrade documentation. I don't agree actually. The user description has to answer the question why should I install this, the changelog has to answer the question what has changed -- the answers are related but are not the same and cannot be generated form the same source. Particularly as the descriptions have to be read in a specific layout in the AppMgr, which is much better suited to a paragraph of natural language text than a detailed list. And don't forget the requirements of translation as well. Well if HAM has a little slug saying Changed frobulation on foo: fixes security hole. that can come from the changelog just as well as the control file, perhaps more easily. Keep the upgrade description. If some people want to generate it automatically from their changelogs that is fine -- I can imagine an mh-generateupdatedescfromchangelog program which can be called from debian/rules. But don't do it automatically. I actually think this method has some potential. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
Hello! The following is a rant about XB-Maemo-Upgrade-Description with some suggestions for improvement... Change Log handling (at that time for the downlaod page however ) was discussed before! See: http://www.mail-archive.com/maemo-developers@maemo.org/msg16160.html -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optification (was Re: PyMaemo (Python for Maemo) final release for Maemo 5 (Fremantle))
On Thu, Nov 12, 2009 at 11:30 AM, Eero Tamminen eero.tammi...@nokia.com wrote: ext Anderson Lizardo wrote: Do you think it can be made a generic dh_* like tool that handles this automatically? This way it could be called from debian/rules as e.g.: maemo-python-optify /usr/lib/python2.5 and the init scripts be generated automatically. What do you think? Are you suggesting that each python package would themselves do the bind mount? And hide anything that was before in that directory? Saner solution is that the bind mount is done by something from which the package depends from (be it python package itself or something else). No no, I'm just suggesting make it a generic, more automatic tool (like maemo-optifier itself) that can be used by other bigger packages that maemo-optify cannot handle generically (although I'm not aware of any other cases). This is optional though, and for Python we will handle it now instead of waiting for this tool to be written. For Python, we will bind mount just the core python2.5 package. This way, all packages that depend on python2.5 and install modules/extensions to /usr/lib/python2.5 will benefit from it transparently. I should also remember that we have to handle packages that use python-central/python-support too, as they move the extensions to other places (directories under /usr/share/... and /var/lib/... IIRC). They will be handled similarly as well. We will also make sure all possible installation paths (fresh install, upgrade from optified package, downgrade to non-optified package, removal) are properly handled so that we can cleanly move in/out from the bind mount solution and avoid upgrade breakages. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to get a transparent GtkWindow (fremantle)
Thanks a lot Kimmo! At least, now I know what's happening! Now, what to do to solve the problem? If HildonAppMenu behaves like this by design (and if the bug regards only the fact that it is first mapped and then unmapped while it shouldn't be mapped at all), is there a way to create a floating top level widget on top of a HildonWindow or it is somewhat forbidden by the actual implementation? I don't want to continue the development in the wrong direction, maybe it's better if I stop here and redisign my app to not include the offending widget and find another way to present the same informations to the user - but let me say that I grew somewhat fond of my transparent-overlayed-unobtrusive-image-details-window! What do you think? -- Luca Donaggio 2009/11/11 Kimmo Hämäläinen kimmo.hamalai...@nokia.com On Wed, 2009-11-11 at 08:28 +0100, Hamalainen Kimmo (Nokia-D/Helsinki) wrote: On Tue, 2009-11-10 at 16:15 +0100, ext Luca Donaggio wrote: I thought it was somewhat related to transparency because doing this: gdk_window_reparent(win-window,gtk_widget_get_window(GTK_WIDGET (mainwin)),300,200); makes the HildonAppMenu work again at the price of loosing the transparency effect (modified code attached). Reparenting 'win-window' makes it a child of 'mainwin'. That is completely different ballgame than the original code, which keeps 'win- window' a top-level window (child of the root). When the window is not top-level, it's not managed by the window manager anymore, but it could also cause something in Gtk/Hildon (at least I have checked all places deleting windows in hildon-desktop to no avail). Finally I found the reason for hiding the menu! It's in libhildon function hildon_app_menu_find_intruder. It thinks that the window with the This is an RGBA window label is an intruder (such as dialog etc.) and closes the menu as soon as it is mapped. This seems like a bug since the menu should not be mapped in the first place if this intruder is already there at mapping time. To summarize: this is libhildon bug and hildon-desktop is completely innocent (at last...)! ;) -Kimmo -Kimmo -- Luca Donaggio 2009/11/10 Kimmo Hämäläinen kimmo.hamalai...@nokia.com On Tue, 2009-11-10 at 14:12 +0100, ext Luca Donaggio wrote: Hi Kimmo, I'm sorry to bother you again, but the problem I'm facing is not how to get a transparent window, but that if I create such a window the HildonAppMenu of its parent HildonWindow doesn't show anymore. I (slightly) modified your code to exemplify my situation. Ah, yes, I can see it. Looks like the menu is unmapped immediately when it is shown. It's weird, I'm not yet sure what unmaps it... Now it looks like hildon-desktop is not unmapping it, so it could be widget side problem also. I'll try to find out. BTW. this problem is not related to the transparency: opaque window does the same. -Kimmo Thanks for your time, Luca Donaggio 2009/11/10 Kimmo Hämäläinen kimmo.hamalai...@nokia.com Hi, Sorry, took some time, I was busy with some bug fixing... I started with the Home applet example and managed to whip up a small example (attached) that shows a transparent pop-up window. -Kimmo ___ 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: Problems Panning/Clicking with GtkIconView
Hi, I am having a hell of a time trying to get an GtkIconView working correctly with the pannable area widget. Using hildon.GtkIconView I am able to pan by using the scrollwheel on my mouse, but if i click anywhere to start panning, it immediately activates whatever was clicked on. gtk.IconView does pretty much exactly the same thing. Removing the connect function obviously allows you to pan freely. I've tested on a N900 ande it's exactly the same behavior. Does anybody know how this could be achieved? Thanks ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optification (was Re: PyMaemo (Python for Maemo) final release for Maemo 5 (Fremantle))
On mar., 2009-11-10 at 12:33 -0400, Anderson Lizardo wrote: Nice to hear that! We decided to leave out the optification for the final release, just not to delay it even more. But now I believe we can work on it as an update through extras-devel (I just hope that that QA process will take any possible regressions with the new packages we upload). Hmhm so everything will install on OneNAND ? Or everything will install on eMMC ? -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Package does not end up in DIABLO extras-devel
Hello! Packages are starting to show up in diablo's repos now. I will try a look into this and make sure things are working as they should be. I don't want to restart any services or have any unplanned downtime so I am not going to be intrusive, just poke around and see if I can find any obvious issues. While I got success mails for uploads of a new (lib)illumination version, it still does not appear in the extras-devel repository (http://repository.maemo.org/extras-devel/pool/diablo/free/i/illumination/). For fremantle everything works as expected. It seems that at least for me something is still broken in the diablo autobuilder process. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
