GStreamer pipeline with live and non-live sources
Hi, We have a strange problem with our dear JamMo application. It uses GStreamer to provide karaoke-like singing game for children. The following (simplified) pipeline used to work before PR1.1.1 update: gst-launch-0.10 filesrc location=/home/user/MyDocs/test.mp3 ! decodebin! pulsesink pulsesrc ! wavenc ! filesink location=/home/user/MyDocs/recording.wav Since PR1.1.1 there are audible scratches or even worse: the sound disappears totally. It is because the sink has to slave its clock to the pipeline clock, which is the one provided by the live source [1], and there is probably not enough processing power available. However, it used to work! The difference is at least the GStreamer version, which was upgraded to 10.0.25 in PR1.1.1. It was 10.0.23 in PR1.1. (In addition, there were synchronisation issues with PR1.0, so the only working version was PR1.1. with GStreamer 0.10.23). Actually, the same happens in desktop environment too when comparing different GStreamer versions. It is extremely important to be able to have playback and recording in sync. Thus, I have tried different buffering and latency parameters, but have not found a solution. Does anyone know, how the pipeline above could be optimized to work decently in N900? Thank you in advance! BR, Henrik [1] http://sourceforge.net/mailarchive/message.php?msg_name=128447.2407.9.camel%40metal -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to keep hildon-plugin-manager from loading plugins before the package is installed completely?
On 28/06/10 22:38, pHilipp Zabel wrote: My assessment of the situation is that hildon-status-menu loads the plugin as soon as status-area-applet-tor.desktop is unpacked. It then races against the unpacking process and wins. It tries to load the icon before the maemo-optified link /usr/share/icons/hicolor/48x48/hildon/statusarea_tor_disabled.png is created. Is this what happens? What should I do about it - I guess I can't stop h-s-m from prematurely loading the plugin? Could you unpack the desktop file to some other place or name first, and then use postinst script to move it into right place and name? By that way, hildon-status-menu sees the new file only after the whole package is unpacked. BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Package import into Extras-devel from the builder stucked
Alert! It seems that packages are not imported into Extras-devel after the builder has succeeded with them. Here is an example: http://maemo.org/packages/view/jammo/ Version 0.4.4 or 0.4.5 is not yet in the Extras-devel repository after several hours: http://repository.maemo.org/extras-devel/pool/fremantle/free/j/jammo/ I hope the problem can be fixed quick. Thanks! BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Is mauku open source, i.e free or is in non-free?
Jeremiah Foster wrote: Bug #7505 asks if mauku is open or closed. According to the bug report, it looks pretty closed. ... What should we do here? Move this to non-free? Mauku 2.0 is not free as open source software (Mauku 0.x was under GPL). It is mainly based on Microfeed library written by me and licensed under LGPL, but the application itself is not licensed under any OSI compliant license. I am very aware of the meaning free here. Mauku was uploaded into the free section because there was (is) no non-free repository in Extras. However, the community insisted to close all external repositories and use Extras instead (done that). In addition, Ovi Store was not (is not, it is still beta) available for distribution channel. Last time I saw someone mentioning something about the non-free section in Extras, there were opinions that (some?) members of the community do not want to spend their time doing QA for non-free software. As far as I know, that was the end of the discussion. There have not been any discussion, announcements or instructions how to really handle QA in the non-free section. My opinion is that QA in the non-free section should work as it is working in the free section currently. In most cases, testers are doing their work without really reviewing the source code. The same criteria could be applied for non-free software. If there are community members wanting to support and use non-free software in their devices, they should be given a change to do that. My humble intention was to provide my software for Maemo users (and maemo.org members) through the channel they are aware and in a way that should cause least problems. Feel free to remove it (completely, please, in that case) or move to non-free section in Extras (not in extras-devel or extras-testing) and provide a guidance how to upgrade it later. Naturally, the latter is better. BR, Henrik (author of Mauku) P.S. I have been very busy lately, and I have had to make decisions how to spend my time. Unfortunately, the confusion and unreadiness of Maemo (and maemo.org) software distribution channels was one reason why I have dropped the priority of Mauku project. Those essential building blocks should be in good shape in order to attract developers (both open source and commercial), but unfortunately that is not the case here now. I really hope things will be get better... -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Is mauku open source, i.e free or is in non-free?
Ryan Abel wrote: On Jan 26, 2010, at 4:07 PM, Henrik Hedberg wrote: Jeremiah Foster wrote: Bug #7505 asks if mauku is open or closed. According to the bug report, it looks pretty closed. ... What should we do here? Move this to non-free? I am very aware of the meaning free here. Mauku was uploaded into the free section because there was (is) no non-free repository in Extras. However, the community insisted to close all external repositories and use Extras instead (done that). In addition, Ovi Store was not (is not, it is still beta) available for distribution channel. http://repository.maemo.org/extras/pool/fremantle/non-free/ Thanks, I know. But as I said, [t]here have not been any discussion, announcements or instructions how to really handle QA in the non-free section. Thus, the non-free section in Extras does not officially exists. There is only procedures how to upload it into extras-devel. BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Is mauku open source, i.e free or is in non-free?
Eduardo Lima (Etrunko) wrote: To upload to extras non-free, you must use dput and edit /etc/dput.cf accordingly, as described in http://wiki.maemo.org/Uploading_to_Extras#.22non-free.22_packages. Don't know the current status of the non-free queue for Fremantle. It used to work back in the days of Gregale/Bora/Chinook/Diablo. The problem is in the non-free queue actually. As I said, [t]here have not been any discussion, announcements or instructions how to really handle QA in the non-free section. Thus, the non-free section in Extras does not officially exists. There is only procedures how to upload software into extras-devel. (Am I repeating myself?) * * * To bring something new also: I think maemo-developers is not right place to discuss about individual applications. As the interest in Maemo increases, there will be more and more subscribers and traffic in this list. But as this is actually about the non-free section in Extras and QA, the discussion is valuable. BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Profiling applications (oprofile, others?)
Alberto Mardegan wrote: since fremantle's maemo-mapper is so horribly slow, I went and tried to run oprofile. Unfortunately it seems to me that static functions never appear in the final report. Is this how it is supposed to work? Your binary may lack frame pointers. See [1]. BR, Henrik [1] http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Kernel_and_Debugging_Guide/Maemo_Debugging_Guide#Debugging_Issues_on_ARM_Architecture -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel - extras-testing auto-promotion not working?)
Anderson Lizardo wrote: Some user suggested once creating meta user/* packages for libraries, python modules etc. that need updates, but I think this just too hackish, and even if we proceed and do this, how do we convince the end user to install it? I still suggest meta user/* packages. Nokia is actually using meta user/* packages (for example, Maemo 5 package is a meta package pulling the platform non user/* packages when upgraded). However, there might still be a question about how to convince an end user to upgrade a package that he has not actually installed. In Maemo 5 case that is easy, but in other cases it might require some additional communication. One solution could be that the Application Manager showed other user/* packages that depends on meta user/* packages. That way an user might understand that if he upgraded Python package (or Microfeed package), gPodder (Mauku), for example, would benefit from that. Maybe those meta packages should be in a separate section (user/backend, user/platform, user/libraries, or similar). BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: JSON libs @ Maemo
Adrián Yanes wrote: I was checking the packages repositories and only libjson-glib-1.0-0 python-simplejson is ported. For Fremantle, yes. I was porting/using the last weekend json-c in N900 ( I didn't upload to extras repositories yet ). I was maintaining json-c for Diablo and older OS versions, because Mauku was using the library. However, the new Microfeed backend has its own implementation of json parser [1], so I am not interested in json-c anymore. BR, Henrik [1] http://gitorious.org/microfeed/libmicrofeed/blobs/master/microfeed-provider/microfeedjson.h -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DBus service name
Aniello Del Sorbo wrote: there's no two without a three... so.. third question of the day. I am using com.nokia.xournal as DBus service name. I wanted to change it. Thus I went to xournal.service and xournal.desktop files and changed it to something less nokian and more maemian like org.maemo.xournal. Guess what.. Xournal gets killed after a few minutes. Reverted back to com.nokia.xournal and it works again. See: http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Application_Development/LibOSSO_library#Maemo_initialization The name in OSSO initialization, .desktop file, and .service file must be the same. BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
On Nov 3, 2009, at 12:16, Andrew Flegg wrote: Agreed. -maemo0 to -maemo1 is supposed to be a Maemo-specific change or a packaging change (AIUI). Native packages (such as Hermes, Attitude etc.) don't have that suffix and use a traditional x.y.z numbering scheme. Not necessarily. There is no official version numbering sceme for native Maemo packages. For example, some packages are using date, like 20091019. Jeremiah Foster wrote: This is what I had in mind but skipped on elaborating in an effort to keep things as clear as possible. I think this solution is excellent and perhaps we can implement it if there is consensus? It is nice to see that there is a strong push to make changes into the way karma is handled in QA. However, I suggest that you do not try to guess anything from a version number - unless you want to make a new requirement for a package as a side effect. Forcing developers to use a specific version numbering scheme would make Maemo even more different than other Linux distributions (see, for example [1]). Packages are promoted with the web interface. Simple checkbox there is enough to implement this feature. BR, Henrik [1] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Testing nonsense
Till Harbaum wrote: there's another problem with the testing i am facing with gpxview: Nonsense ratings. GPXView got a thumbs down for needing lots of porting to match the maemo6 gui. Yes, harmattan! Why the heck should a fremantle program not be forwarded to extras due to the fact that it will be hard to port it to qt (which is what that guy is imho trying to say)? I am considering to entirely ignore the test process until this testing/promotion thing has actually proven to be useful. Dealing with people that just rate nonsense issues is a) a waste of time and b) frustrating. In addition, testers - whether they rate nonsense issues or not - even get positive karma! It feels little unfair. I really would like to see a discussion about the responsibilities and ethics of a tester, and possible procedures to make sure that a tester is behaving as expected. BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
Anderson Lizardo wrote: But the PyMaemo team is still responsible for providing upgrades and fixes for these packages through the extras-devel/extras-testing repositories, and the user applications that use packages like python-dbus, when promoted, will automatically promote the dependencies. It *seems* to be the correct way of handling the promotion for packages not under user/* sections, like all PyMaemo components. Why is that? You do not feel scary that you cannot push, for example, a security fix for your components? Let's say that I am using one application (user/* package) that depends on python. For some reason it is not maintained anymore, and thus not updated. How do I get new versions of python libraries? Another thing to consider is that should _every_ application (user/* package) that depends on python be updated to just have a new version number in their dependencies when a new version of python libraries is released? (May be not, if they are working with the earlier version too, but what about those security fixes, for example.) There will be a lot of unnecessary megabytes to download just for that. For Microfeed backend (libraries and applications that are not visible to user directly) I decided to create one user/* package that depends on the latest library packages. Applications using the backend are encouraged to depend on that package. When a library, for example, is updated, there will be a new version of the user/* package that pulls the library package. How do you see that option? BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Testing nonsense
2009/11/3 Till Harbaum li...@harbaum.org: there's another problem with the testing i am facing with gpxview: Nonsense ratings. GPXView got a thumbs down for needing lots of porting to match the maemo6 gui. Yes, harmattan! Why the heck should a fremantle program not be forwarded to extras due to the fact that it will be hard to port it to qt (which is what that guy is imho trying to say)? Aniello Del Sorbo wrote: Well he didn't say he thunbed it down because of what he said in the comment. Maybe he thumbed it down for a reason and ALSO commented that it'll be hard to adapt it to Maemo 6 later on. The instructions for testers [1] says: Whenever you decide to vote an application down, please leave a comment describing what issues you found. The best feedback is a bug number, since this allow to track and discuss better the problems. Voting thumbs down without any explanation doesn't help the developer getting better software for you and the end users. There is a long list of blockers (must) for packages that developers provide. Why are the instructions for testers just advices (please, not even should). I think it should read: Whenever you decide to vote an application down, you MUST leave a comment describing what issues you found. The best feedback is a bug number, since this allow to track and discuss better the problems. or even better (the commenting feature in packages interface is overlapping thing with bugs.maemo.org): Whenever you decide to vote an application down, you MUST provide a link to a bug report with severity major or higher. Actually, I read some early postings about the subject (since April). There were many good ideas (like linking into Bugzilla), but for some reason we got this separate playground. BR, Henrik [1] http://wiki.maemo.org/Extras-testing#Thumbs_Down -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
Tim Teulings wrote: Except how do you try to prevent abuse (whether intentional or accidental)? At least with the version number you've got some safety check (although it is in no way comprehensive). It also requires more changes at more levels (I bet), so harder to implement. I think it is time to decide (again?) if we trust developers in their atempt to get their software/package into extras or not. Currently, we trust ten random testers rather than one well-known developer. Why could not we trust well-known developers who have track record of producing high-enough quality software? They may have their own methods for testing, like couple of active and skilful dedicated testers for the application domain. I see that more trustful than those random testers who vote subjectively based on their opinions of an user interface. We could have a group of accredited developers who have access to the Extras. They are committed to release only validated and verified packages. When a new developer wants to upload a package of his own, an accredited developer could sponsor him, i.e. act like a gatekeeper. Sounds familiar? See Debian New Maintainers Process [1]. Another possibility is to have the team of accredited testers, who can make the final decision of their own. To become an accredited tester required commiting to write sane bug reports and to make decisions on generally agreed checks, among others. Then there would not be a need for ten random strangers and ten day delays. BR, Henrik [1] http://www.debian.org/devel/join/newmaint.en.html -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: optify liqbase
Gary Birkett wrote: this should with 1 symlink or hardlink and will cure all liqbase /opt situations: /usr/share/liqbase/* Why do you need that symlink at all? If you put all your application data into /opt/liqbase (and subdirectories) and you have the control, then all paths can point directly to /opt/liqbase/something. As someone said earlier, maemo-optify is not the only solution. Installing directly into /opt/package and accessing that directly is even better. Only .desktop files, binaries (/usr/bin, probably symlinked) and such need to be somewhere else. So, use /opt/liqbase in your code, not /usr/share/liqbase. BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
igor.sto...@nokia.com wrote: I think the problem here is that some braindead system has been introduced, which doesn't account for the actual work being done. And what is the biggest mistake here is that the new system has been put into production before testing it at all. Someone just came up with an idea of crowd sourcing the QA and used random generator to set the parameters. Soon it was in real use before any experiences of its functionaly had got. I would have understood if the parameters had been really low (say, 1 day and 1 thumbs up) at the beginning, or there would have been a separate repository (say, extras-selection) to test this new functionality. The parameters could have been changed according to success of the system and in parallel with the amount of testers (and devices available). The sad contradiction here is that developers are expected to produce high quality outcomes and their results are put under QA, put the maemo.org processes and tools are not! Those should have been tested, for example, with a smaller group of developers before putting into production system. The maemo-extras testing marathon did amazing job. Thanks to everybody who participated! However, it cannot be a permanent way to overcome one of the biggest problems with the new system. I am not totally against the new system, and I do recognize the importance of quality assurance. I just hope that we can learn from the past and react rapidly. Please, do not refer to the better future and the possibility to have more users and testers later. Things should work now! Here are my suggestions now: 1) Fine tune the parameters: say, 5 days and 5 votes. These can be changed later when the system is working (has enough testers). 2) Change the system so that user packages that are depended by another user package are promoted automatically when the actual user package is promoted (like non-user packages are promoted currently). For example, when an user is testing Mauku, she is implicitely testing also the microfeed package [1]). 3) Find a way to overcome the limitations when an upgraded package is an important security fix. And here are my older suggestions [2], which, I think, are still valid: * Negative karma can be given _only_ if it based on the agreed QA requirements. (Testers are still giving karma based on their subjective thinking instead of QA requirements.) * The package page should have a link to a bug tracker and the link must be used! (Comments are stored into a wrong place currently. It is double effort for a developer to track the packages interface in addition to bugs.maemo.org.) * Negative karma can be given _only_ with a link to a bug tracker having a bug report about the show stopper. It may be either a new bug report written by the tester or an old open bug report just referred in the comment. * Negative karma is automatically removed when the related bug report is closed (fixed or other way resolved). (Currently, there is no way to remove the negative karma (thumbs down) if the bug is fixed. Please, note that the bug may be in the library code, and the bug in the package is thus actually fixed when the library is fixed. So, there would not be any need to update the application package every time.) BR, Henrik P.S. I do not necessarily see that more testers will make things easier and more workable. The more testers there are, the more subjective evaluations we will get. If one tester just do not like the graphics of an application he may give thumbs down, and even four other testers giving thumbs up are needed to fix that misjudgement. I really would like to see a discussion about the responsibilities of testers. Should there be a mechanism to give negative karma to testers who are not following the QA rules, or even way to ban them? [1] http://talk.maemo.org/showthread.php?p=362575#post362575 [2] http://lists.maemo.org/pipermail/maemo-developers/2009-September/020921.html -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
Martin Grimme wrote: resetting Karma on a new version leads to one very bad issue, IMHO: Developers of packages with some Karma will hold back bugfix-updates until the unfixed version has reached extras. Guilty as charged. I have actually postponed the release of Mauku 2.0 beta 5, because I have been waiting for beta 4 to go through the QA process. The sad thing is that I am not happy with the beta 4, but I think there should be at least one version in extras available for ordinary users. So, I just promoted it into extras. The beta 5 has been ready over two weeks and I have used it myself. However, although the beta 4 just hit extras, I am not going to put beta 5 in testing just yet. I will develop it further, and not start the testing process until I have more features implemented (actually, I would have introduced those features in beta 6 or beta 7, but now those features will appear in delayed beta 5). On the other hand, the current QA process makes sure that you have to think twice and test internally before you put your package into testing. This may be a good thing. However, it makes incremental development very hard or even impossible. From my viewpoint, the biggest problem is not even the required amount of karma but the quarantine period, which is way too long. If I liked to release a new version once a week, the package would never hit extras. BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Screenshot as loading screen on Maemo 5
Aniello Del Sorbo wrote: But taking a snapshot slows down the startup... it should be then done in a small thread? The hildon_gtk_window_take_screenshot function just sends a client message to the root window [1] , and the screenshot is taken by the window manager / hildon desktop (I guess). So, it does not take too long from the application itself, and a thread would make it only slower. BR, Henrik [1] http://maemo.gitorious.org/hildon/hildon/blobs/master/hildon/hildon-gtk.c#line463 -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle fullscreen mode [was Re: Call for testers with N900 for vncviewer]
Cornelius Hald wrote:
I don´t think there is already a widely used keyboard shortcut.
The full screen toggling should be done with the touch screen, yes.
However, there are some shortcuts in the keyboard (of which I found
by accident):
CTRL-Backspace = Open the task switcher (can be used to somehow replace
the full screen button)
CTRL-Shift-X = Open a new terminal (which is very handy if the
hildon-desktop has jammed ;)
CTRL-Shift-P = Take a screenshot (which is saved in
${HOME}/MyDocs/.images/Screenshots)
BR,
Henrik
--
Henrik Hedberg - +358 (0)40 574 5087 - http://www.henrikhedberg.net/
Innologies - Innovative Technologies - http://www.innologies.fi/
Oulu, Finland - FI19934487, VAT reg. - http://www.innologies.com/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Auto builder broken?
Aniello Del Sorbo wrote: how did you upload your .changes to extras assistant? I use scp. btw, I think there were issues with the autobuilder as it should be stopped for now as they were solving some issues that arose with the final sdk release. It was Tuesday, but I have heard rumors that the builder was working yesterday... BR, Henrik ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Name for community widgets project
Cornelius Hald wrote: it looks like some people are interested in the Fremantle community widgets project. What we need now (amongst other things) is a name. The following names have already been mentioned: - hildon-extras - HildonExtrasColorChooser - hexy - HexyColorChooser Others ideas? If you are targeting to Hildon, why not to use just Hildon. At the same time you could make sure that there are no name collisions. The transition from your library to the future extended Hildon library would just need to change compilation options, not all names in a source code. I know that this is not a common way to do things and not generally suggested, but I think this a special situation. At least there should be no negative issues with that (if you are careful with the names, as you should if you are going to integrate it finally) and it would make the forthcoming transition easier. BR, Henrik ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to use extras-testing correctly?
Niels Breet wrote: On Thu, September 24, 2009 11:19, Aniello Del Sorbo wrote: Here's my proposal: We leave Extras-Testing as it is, with votes, comments, bug reports an so on (or improve it, as you wish). But then it's only the developer that decides, based on that feedback, if or not to promote the application to Extras. This is what happens now. Even if your app gets enough votes for promotion to Extras, you still need to push the button. There is no automatic promotion. The developer/maintainer is always the one who decides on when to publish the app. So no quarantine, no need to gather karma points? Please, update the wiki [1], if that will be the case. Aniello was saying that developer should have an option to promote his application directly into extras regardless of the extras-testing QA. I second to that. In addition, Aniello had nice ideas about the processes and tools how to find applications (and developers) who had probably misused their power to promote application directly into extras. There is no hurry to implement those, although they could make sense in the long run. BR, Henrik [1] http://wiki.maemo.org/Extras-testing#Promotion_.2F_Demotion -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to use extras-testing correctly?
Extras-testing QA is not working as it is implemented now! There are two main issues: * Comments are stored into a wrong place. Those belong to Bugzilla! It is double effort for a developer to track two different places or to transfer reports into bug tracking system manually. * Developers are giving karma based on their subjective thinking instead of agreed (?) QA requirements. Let's analyse karma and comments that Mauku has got: * Two testers of five either add a new bug report or search the existing bug reports before entering a comment. Good for those two, bad for the rest. * Negative karma given at 2009-09-24 04:52 UTC and related comment written at 2009-09-24 04:55 UTC. Is there any real reason to give negative karma based on the comment? Tester either wants some new features (definitely not based on QA requirements) or some minor user interface modifications (not a show stopper). * All testers report at least one issue that is not actually related to the application itself but the underlying library. I understand that it is hard for end-user to see the difference, but what happens when the library is updated? These issues are fixed, and so is the application also, but the negative karma stays there. My suggestion here is that: * Negative karma can be given _only_ if it based on the agreed QA requirements. * The package page should have a link to a bug tracker. * Negative karma can be given _only_ with a link to a bug tracker having a bug report about the show stopper. It may be either a new bug report written by the tester or an old open bug report just referred in the comment. * Negative karma is automatically removed when the related bug report is closed (fixed or other way resolved). Graham Cobb wrote: Testers should be testing against the agreed requirements only. The subjective element should be eliminated as much as possible - we are using human testers because it is impossible to do this testing manually, not because we expect different opinions. We are using more than one tester just so that a problem doesn't slip through because one tester missed it, not because we expect voting. I strongly agree! By all means add a comment if you are unhappy with the UI but it should get a +1 as long as it doesn't conflict with the requirements. Ideally every -1 should require a comment saying which of the QA requirements is violated. I strongly agree. Actually, I would remove the word ideally. It is a must! And with the relationship to bug tracker I described above. BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to use extras-testing correctly?
tero.k...@nokia.com wrote: Once there is hardware available, I think that the limit is the quaranteen time that the app has to stay in extras-testing. Knowing the community, my guess is that there will be enough testers for the apps. (some people code well, others like to test) Is it possible to predict or set the actual moment when a package goes into extras? For example, if I liked to make a grand announcement of my new software, how could I time my announcement when the control of the release date and time is not in my own hands? BR, Henrik -- Henrik Hedberg - +358 (0)40 574 5087 - http://www.henrikhedberg.net/ Innologies - Innovative Technologies - http://www.innologies.fi/ Oulu, Finland - FI19934487, VAT reg. - http://www.innologies.com/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
Kimmo Hämäläinen wrote: Does UnionFS support block rotation (like ubifs) for the internal flash? UnionFS works on top of other file system(s) in directory level. In this case, UBIFS would be still there for the underlying root filesystem. It seems that the overhead of using UnionFS is about 10% [1], which should be noted when making decisions. This performance lost will affect all files, not should optified files as in the original plan. BR, Henrik [1] http://www.linuxjournal.com/article/7714 -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
Marius Vollmer wrote: It will be hardcoded, but I think it is still negotiable. The partition itself is actually 2 GB, but it is also used for the Meta Tracker database and other things. What about making it 4 GB? Would that feel big enough? 2 GB, 4 GB... I think there is always an issue when it is hard coded. Why is the ancient VFAT and fixed partitioning still used? Would it be possible to partition eMMC into one big ext3 partition and just use some kind of loopdevice or similar when exposing a part of it as an USB storage in VFAT format? That way also the annoying not mounted right now issue would be fixed, since an USB host and the device could use the same files at the same time. I do not see technical limits, but maybe someone should just code a relevant kernel module (the virtual VFAT loopdevice ;) if that does not exist. BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
On ons, 2009-09-09 at 15:20 +0200, ext Henrik Hedberg wrote: Why is the ancient VFAT and fixed partitioning still used? Would it be possible to partition eMMC into one big ext3 partition and just use some kind of loopdevice or similar when exposing a part of it as an USB storage in VFAT format? That way also the annoying not mounted right now issue would be fixed, since an USB host and the device could use the same files at the same time. I do not see technical limits, but maybe someone should just code a relevant kernel module (the virtual VFAT loopdevice ;) if that does not exist. Patches happily accepted! Kees Jongenburger wrote: Perhaps samba or webdav or sshfs , mpd are possible without unmounting the block device ? Also a virtual virtual fat implemented as fuse really sounds like a crazy project. Virtual virtual fat (or wfat now on ;) is what I had in my mind. However, I do not see FUSE as an solution here, because the problem is that the USB mass storage devices transfer pure sectors. Thus, data is not going through the Linux VFS. We need a block device that acts like a VFAT partition but reads and writes the actual data into a given directory (in any file system, actually). Yes, it really sounds crazy! ;) BR, Henrik P.S. The original root cause is the USB mass storage specification, which does not say anything about the file system. Thus, FAT has become de-facto standard for portable media, which is sad. -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Code cookbook for Maemo?
tero.k...@nokia.com wrote: A few guys from our product management got an idea of a 'code cookbook'. A sort of wiki-like place where you could copy-paste snippets of code, tag and comment on them. Then by searching on the tags or text you could find pieces of code that do a specific thing. The idea would be to make life simpler for developers, by providing them with a cookbook from where to find usefull algorithms for things that most people run into or need to be coded in some particular way. Excellent idea! Could you, however, explain how is this different from the existing Code Snippets page in Garage: https://garage.maemo.org/snippet/ ;) BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Problems running Maemo 5 on Ubuntu 9.04 i386
daniel wilms wrote: have you installed the nokia-binaries? For more information have a look at the last point of the installation instructions [1]. And for the _both_ targets: FREMANTLE_X86 and FREMANTLE_ARMEL? It seems that you may have omitted the X86 target when installing nokia-binaries. ext Fabio Rotondo wrote: Hi everyone, sorry for posting this too newbie question on this list. I googled for a while before doing so and also browsed the bugzilla at maemo.org, with no success. I have installed maemo as described here: http://maemo.org/development/sdks/maemo_5_beta_2_sdk_installation/ everything worked out fine, without any install error, but when I try the following line: [sbox-FREMANTLE_X86: ~] af-sb-init.sh start I get: bash: af-sb-init.sh: command not found I have browsed my scratchbox system and found the script only in: ./targets/FREMANTLE_ARMEL/usr/bin/af-sb-init.sh So what am I missing? Before you ask, I have also installed the nokia binaries packages. Henrik ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder: building svn tags from garage
Ed Bartosh wrote: If everybody thinks that support of multiple package builds is more important I'll do that. Excellent! True. But if we manage to define a group of packages as one build I can solve this problem by creating local repo, adding packages to it as soon as they're built and using it for the build. Of course better solutions would be to make adding to extras-devel work faster, but i tend to think it's near to impossible :) Sounds good. I was looking for a simple solution that can be implemented rapidly and without major modifications. However, it seems that you have already an implementable solution. I think adding packages to extras-devel faster is not the key point, and it can be even harmless if done when the chain of multiple inter-dependable packages are being built. Thus, it would be nice, if the group of packages is added to extras-devel only if all packages have been built successively. Yet again, big thanks for fixing this. BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optimal battery life considerations in apps
Andrew Flegg wrote 09.07.2009 00:29: 2) Stop updating the screen when your app isn't in the foreground. (1) is trivial to implement. (2) is trickier (there's hildon_program_is_topmost() and hildon_window_is_topmost(), but polling to discover when you're topmost again is hideous). You are raising a very important question. Actually, hildon_program_is_topmost() and hildon_window_is_topmost() are not enough, because a desktop widget (HDHomePluginItem) is not a Hildon Window, but inherited from GtkWindow. Thus, there is also need for hildon_gtk_window_is_topmost(GtkWindow*); 2) In Fremantle, there's a compositing window manager. On a desktop this means you never receive an expose event since your window is always exposed on an off-screen buffer. What is the best way of implementing (2) in Maemo 5? There is a standard X event for that: XVisibilityEvent. The X server (and a window manager) can keep window contents cached (backing store) and decide not to send exposure events, but my interpretation is that if it is not sending visibility events it is broken (and it is currently as I showed in my earlier post). There is no need to reinvent the wheel. We could just hope that Nokia fixes the issue - in a standard way. The main advantage of using Linux also in mobile devices is that developers can use their earlier knowledge and code from desktop world (UI is a different thing, naturally). Maemo is going to dangerous direction if more and more things are done differently. I really do not hope that. BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Submenues in Fremantle
Till Harbaum / Lists wrote 05.07.2009 18:44: i already tried this and it looks much better than the extra windows. Why are there different tutorials/style guides for this? ... - Can i add a title? I'd like if the submenues are somehow titled like the main menu entries they were reached from. Could you explain what have you tried? As far as I understand there are no such things as submenus. There is only AppMenu and of course Sub Views (of which Tim speaks) that are actually stacked windows (which I would understand as extra windows). Am Sonntag 05 Juli 2009 schrieb Tim: Till, Have you tried to create new Sub Views for each of the submenu items? BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Microfeed: Backend for accessing micro-blogging sites
I have announced today a new project called Microfeed. Microfeed is a specification and a reference implementation of D-Bus-based client-server architecture providing access to various micro-blogging sites, such as Twitter, Facebook, Jaiku, Qaiku, and Laconi.ca. Also other services that have feed-type interface can be intergrated into the framework. By utilizing the Microfeed architecture, a client application can focus on user interface, while actual feed fetching is done in the background independently. The client application simply subscribes the feeds it is interested, and a provider publishes new information when it is received. The Microfeed has unified format for various messages, and supports also updating of status information in micro-blogging sites. Mauku will be the first application that utilizes the Microfeed backend. There is already Mauku Widget available for Fremantle in the extras-devel. The idea of the Microfeed architecture is that multiple applications can utilize the same information at the same time. Microfeed is an open source software project. You are invited to participate! You can contribute in many ways, such as: * Spread the word: tell other developer that they could use Microfeed. * Utilize the specification and/or the reference implemenation in your own client application. * Write and fix documentation. Make it easier to understand. * Provide example applications and tutorials. * Review and test the implementation and write bug reports. * Write bindings to other languages, such as Python. You can also rewrite the reference implementation (especially the subscriber side of the library) in other language on top of the D-Bus. * Implement new providers. Especially Facebook provider would be nice! * Enhance the specification and/or the reference implementation. For more information, visit microfeed.org. BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Visibility events for widgets in Fremantle
Hi,
I am trying to track visibility changes for a widget
(HDHomePluginItem) in Fremantle. For some reason this is not working:
HD_DEFINE_PLUGIN_MODULE(MaukuWidget, mauku_widget,
HD_TYPE_HOME_PLUGIN_ITEM);
static gboolean on_visibility_notify_event(GtkWidget* widget,
GdkEventVisibility* event, gpointer user_data) {
return FALSE;
}
static void mauku_widget_init(MaukuWidget* mauku_widget) {
g_signal_connect(mauku_widget, visibility-notify-event,
G_CALLBACK(on_visibility_notify_event), NULL);
gtk_widget_add_events(GTK_WIDGET(mauku_widget),
GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK |
GDK_BUTTON_MOTION_MASK | GDK_VISIBILITY_NOTIFY_MASK);
}
The callback function is never called.
Is this a bug in the window manager or in the X, expected behaviour,
or am I just missing something?
BR,
Henrik
--
Henrik Hedberg - http://www.henrikhedberg.net/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder and build-dependencies from extras-devel
gary liquid wrote: if you add NEW calls or references or headers into the library since you last updated, it will FAIL because your app will be trying to load in the older versions. I believe many of us have had the same problems. it was something I encountered and pondered whether we could make the autobuilder cheat and look in the queued for updating to extras-devel list so that it found the others. +1 but at the end of the day, I just uploaded and got the library through, waited an hour, then sent the app. That makes unnecessary delay between the moment your application is ready to be released and the final moment when it can be actually announced to the world. What to do in between? Drink a lot of coffee? In the middle of the night perhaps? 1. Upload your library into the extras assistant 2. Wait unspecified time (usually at least ten minutes) 3. See if the build succeeded. If not, go to 1. 4. Wait unspecified time (one hour perhaps) until the library is actually in the extras-devel. 5. Upload your application into the extras assistant. 6. Wait unspecified time (usually at least ten minutes) 7. See if the build succeeded. If not, go to 5. 8. Wait unspecified time (one hour perhaps) until the application is actually in the extras-devel. 9. Promote the library and the application to the extras. 10. Wait unspecified time (one hour perhaps) until the library and the application is actually in the extras. 11. Announce the new version of your application to users. How many hours is 1 - 10? Is there any possibility to make this time shorter? BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Default nice value setting
Frantisek Dufka wrote: Sadly I think that you cannot raise the priority from 0 to -1 unless being root, you can just lower it so that setpriority call may not help you. If it is really crucial for the application to have higher priority, maybe it could be installed as setuid root. In that way, it could first set priority from 0 to -1, and then drop the privileges. BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Questions about HildonPannableArea
Claudio Saavedra wrote 09.06.2009 19:23: You are wrong. The HildonPannableArea is an important actor in Fremantle. Look at modest, for example, where it's heavily used. Of course, you can continue using a scrolled window, but that's completely up to you and I wouldn't recommend it, since it will look really oldish. This may sound nitpicking, but I do not think that oldish or newish is a value in itself. I see too often that someone has designed a modern and attractive user interface that is really awful to use. However, I would say that it would be inconsistent to use the old scrolled window when every other application is using the new pannable area. That kind of inconsistency makes an user confused. It might be useful to notice that usually a pannable area is used to scroll a container vertically. Thus, it could be possible to select text horizontally in a text entry at the same time. Could this be the solution to the original issue? What kind of improvements that requires to be implemented for applicable Hildon widgets? BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
Kimmo Hämäläinen wrote: Yes, we have _HILDON_PORTRAIT_MODE_REQUEST and _HILDON_PORTRAIT_MODE_SUPPORT window properties (I think libhildon has convenience functions for setting them). The request property makes hildon-desktop to rotate the screen using XRandR, _IF_ all other visible windows are ok with that. If you don't have the support property or request property, it means that your window only supports the landscape mode. And if there is no convenience function in HildonWindow, then there is naturally the source code of hildon-desktop. :) It contains a test application called tests/test-portrait-win.c. Worth looking... http://repository.maemo.org/pool/maemo5.0alpha/free/h/hildon-desktop/hildon-desktop_2.2.20-1.tar.gz BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ... and QA of closed source applications?
Quim Gil wrote: In the QA from extras-devel to extras-testing thread we are discussing a community quality process that relies heavily on the fact that the source code of an application and its dependencies is available. But happens with the closed source applications? This is a very important question, and even if some members of the maemo.org community may be hard core open source software enthusiastic using only free software in their devices, the reality is that there are even more opportunities to get very good software for the devices if we allow also non-free software to be a part of our community supported extras repository. There have been very popular and even community friendly apps that were not open source, like Mauku or Canola. Just to clarify: Mauku was a closed source software at the very beginning, but the source code has been available and licensed under APLv2 since November 8, 2007. See http://garage.maemo.org/projects/mauku - Keep the same QA process where availability of source code is not determinant, I think the QA process of free and also non-free packages will be based mainly on usage of the software. The source code is not so important in either situation. Earlier, there were some thoughts about packages that are maintained by a maintainer who do not know the programming language of the software they are packaging. Respectively, I claim that the most of future extras testers will not be able to track the functionality of the software they are testing into source code level (they do not know the language, the source code is too complicated, there are too many lines to read, they have not enough time etc.). For example, how many of Mauku users have really checked what kind of dirty tricks I am doing with their Jaiku and Twitter accounts even if the source code has been available for a long time? Let's see, your criteria for extras applications were: - Install and deinstall flawlessly. - Don't bring conflicts in dependencies. - Their info in the app manager is complete (icon, summary, URL to project, updates info). - Have decent page in maemo.org/downloads. - Have a place to report issues to the developers. - Don't crash or freeze systems. - Don't drain batteries. - Are feature complete: everything inside works. - Have been tested by someone trusted before. None of these criteria requires the source code to be available. Thus, the QA for non-free packages in extras should be the same than for free packages. BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Clutter in Fremantle (Alpha SDK)
Hi, How is Clutter supposed to work in applications in Fremantle? Will the Clutter-GTK library be included in the final SDK? I have tried to run a Clutter application that works in desktop environment. It compiles fine, but nothing happens when starting it in the Alpha SDK. Also, even the simplest example application from Programming with Clutter tutorial does not work [1]. Is this somehow related to this statement: It is assumed that we will have only one OpenGL drawing context, and thus a single process running in the system will be using Clutter at a time. This process will be the window manager and the implementor of all challenging graphical UI effects on the screen. [2] What is the trick to get a working Clutter stage in Fremantle application? BR, Henrik [1] http://www.openismus.com/documents/clutter_tutorial/0.8/docs/tutorial/html/sec-stage.html#sec-stage-basics [2] http://maemo.org/development/sdks/maemo5_alpha_overview/ -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Clutter in Fremantle (Alpha SDK)
Till Harbaum wrote 17.03.2009 13:38: Am Dienstag 17 März 2009 schrieb Henrik Hedberg: How is Clutter supposed to work in applications in Fremantle? Will the Clutter-GTK library be included in the final SDK? I have tried to check the clutter-gtk libs into the fremantle extras-devel but this failed due to some problems in the sdk, see: https://bugs.maemo.org/show_bug.cgi?id=4197 I have been able to compile it locally and to run the demo application that comes with clutter-gtk. I compiled the Clutter-GTK, and it really worked! So, the trick is documented somewhere in the gtk-clutter-embed.c source file. :) Thank you for the hint. However, I think that the Clutter-GTK should be included in the official SDK. Could someone from Maemo Software comment on this? Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Clutter in Fremantle (Alpha SDK)
Quim Gil wrote 17.03.2009 14:29: A reason for the delay has been that we are aiming to have Clutter 1.0 in the final release. Before integrating that version it was not critical to have the clutter-gtk bindings in the SDK. Thank you for this very important information. It should be noted that Clutter 1.0 is not API compatible with Clutter 0.8. All developers interested in Clutter should look at the Clutter 0.9, which is the development branch leading towards the Clutter 1.0. http://www.clutter-project.org/blog/?p=66 http://www.clutter-project.org/docs/clutter/0.9/ Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Clutter in Fremantle (Alpha SDK)
Kimmo Hämäläinen wrote: On Tue, 2009-03-17 at 08:37 +0100, ext Henrik Hedberg wrote: Is this somehow related to this statement: It is assumed that we will have only one OpenGL drawing context, and thus a single process running in the system will be using Clutter at a time. This process will be the window manager and the implementor of all challenging graphical UI effects on the screen. [2] This we have assumed in the design, but it does not mean that multi- context does not work. As Kate has already proven, multi-context works. But as long as you have hildon-desktop running in the background, you will not render directly to the screen even if you use Clutter/QtGraphicsView/EGL+OpenGLES2.0/whatnot in your application. When hildon-desktop is running, it is the only one drawing on the screen (with the exception of XVideo). So, killing hildon-desktop is the only way to get direct rendering to the screen at the moment. (We might have something more elegant for this in the future...) Could you clarify what does this mean in practice? Is the performance of 3D rendering significantly slower in applications, for example? I suppose that even if off-screen rendering is used it is still hardware accelerated. Thus, compositing in window manager level should not be a big issue, and we can live with that (for now) if everything just work fast enough. Who needs direct rendering anyway. :) BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
