[MeeGo-dev] Using meego-dev for the Accounts SSO project
Hi all, I'd like to hear your comments about the possibility of moving the development team discussions from an internal (and not public) Nokia mailing list to meego-dev. I would estimate the traffic to be from 1 to 5 messages per day (with some occasional spikes, of course) and being mostly consisting of patches and review comments. Reasons for moving away from the internal mailing list should be quite obvious. :-) Accounts SSO is part of MeeGo Core, yet almost nobody knows about it, and very little contributions are coming from outside of Nokia. I initially though that a project specific ML would be more appropriate (and filed BMC#14801 about that), but if people here don't mind a little extra traffic then having the development happening in this ML would be all fine to me, and could be even more beneficial to the project. You opinion about this proposal is appreciated and, in fact, needed. :-) Ciao, Alberto -- http://blog.mardy.it -- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Using meego-dev for the Accounts SSO project
2011/3/25 Alberto Mardegan ma...@users.sourceforge.net: Hi all, I'd like to hear your comments about the possibility of moving the development team discussions from an internal (and not public) Nokia mailing list to meego-dev. I would estimate the traffic to be from 1 to 5 messages per day (with some occasional spikes, of course) and being mostly consisting of patches and review comments. Reasons for moving away from the internal mailing list should be quite obvious. :-) Accounts SSO is part of MeeGo Core, yet almost nobody knows about it, and very little contributions are coming from outside of Nokia. I initially though that a project specific ML would be more appropriate (and filed BMC#14801 about that), but if people here don't mind a little extra traffic then having the development happening in this ML would be all fine to me, and could be even more beneficial to the project. You opinion about this proposal is appreciated and, in fact, needed. :-) Hi, One suggestion could be to use a prefix, like we in N900 try to use N900: as prefix on subject lines and then when there's sufficient traffic, move to seperate. BR Carsten Munk Ciao, Alberto -- http://blog.mardy.it -- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Using meego-dev for the Accounts SSO project
On Fri, 2011-03-25 at 09:10 +0200, Alberto Mardegan wrote: Hi all, I'd like to hear your comments about the possibility of moving the development team discussions from an internal (and not public) Nokia mailing list to meego-dev. I would estimate the traffic to be from 1 to 5 messages per day (with some occasional spikes, of course) and being mostly consisting of patches and review comments. I would encourage you to do patch review in bugzilla primarily, and tie in the mailing list only if there's need to. Yes, I'm aware that the contribution guidelines say that a patch needs to go onto the ML first. - Rob ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] [N900] Have uboot default to maemo?
Hi, is it possible to convince uboot to boot into maemo per default? I tried to setenv / saveenv the bootcmd but the device gets rebooted during saveenv (watchdog?). Thanks, Rolf ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Thu, Mar 24, 2011 at 10:16 PM, Richard Dale richard.d...@telefonica.net wrote: I personally think that the Nepomuk non-application specific integrated data approach could be a killer feature of MeeGo. In comparison iOS is completely Agreed. Luckily tracker will still be there on the platform (as Marius stated earlier in this thread), so it can be used by willing applications. It's just that contact information is not *primarily* stored there anymore - but we can arrange for an (unofficial) way where it gets moved there from EDS anyway. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Candidate specification for a generic video player from the TV list
Hi, On 24.03.2011 23:57, Dominig Ar Foll wrote: Apologies for responding in dual posting. I would like as much as possible to concentrate that type of chat on the TV mailing list but I would not enjoy to leave a question open. Regarding the already existing projects. Are you aware of MAFW on Maemo5 http://www.grancanariadesktopsummit.org/node/219 The implementation might not be perfect, but the concept behind is sane. No I did not know it and I think you for the link. I have so far only written a requirement specification and any idea to move toward a goo implementation specifications are welcomed. I will dig in their documentation. MAFW on Fremantle was mostly done by Igalia. Some of the people now work on Grillo open source project where you might be able to talk to them (on irc). The picture in 6 Position in MeeGo looks quite arbitrary to me. Do the colors have a special semantics (meybe add a small leged below). No the colour are just imported from a slide and where just there to help to identify the blocks. The main idea of that graph is to make very clear that the proposed concept does not pan to create a universal audio/video pipeline but has the goal to be able to integrate multiple video pipeline under a unified umbrella. In particular it aims at enabling to get non open source pipeline to coexist with public pipelines. In 7 Transparency you need to highlight what your proposal adds to the existing features. The chapter 7) Transparency regroup the need to provide certain type of services in a transparent manner to the the application. My goal is to enable applications to play multimedia content which knowing much about that content. e.g. if you write an application which need to access a live TV service but you live in US, you will have different pipeline once that same application is run in Europe.The requirement of transparency is applied to the typeof source and target. In a very similar manner as when you print on Linux today. Your application knowns very little about the printer but still can print. Which part of the pipeline your are thinking is not well handled right now. I you have concrete examples for illustration, I would encourage you to add them. I believe architecturally we don't miss anything major here. * Transport protocol: handled e.g. by gstreamer already, standarts like DLNA specify subsets for interoperability already I am afraid that GStreamer cannot do today everything that I would love it to do. It does pretty well on most of internet format but Playbin2 has a very limited set of supported services when it come to Broadcast or IPTV. Furthermore by default it does not support any smoth streaming feature or protection. The gstreamer people already have smooth streaming implementation. There are two things: 1) missing architecture to implement a feature 2) missing implementation for a certain feature I believe the gstreamer architecture is pretty solid for adding extra streaming protocols, container, codecs etc. Regarding content protection, I believe it should be done outside of gstreamer. As I said it is not media specific. One idea would be to implement a virtual file system with the related access rights and process isolation. This would allow to run an unmodified media pipeline. But I agree that GStreamer is a great tool and I would certainly see it as one of the strong candidate to implement the first open source audio video pipe line under a UMMS framework. Just to be clear - I am not saying that gstreamer is the tool for everything. But integrating two many thing in parallel might not be beneficial either. Thus your document needs to improve pointing out the missing parts (explicitly). Then people can help you to identify existing implementations (or where they believe the feature should be added). Then we can also identify things that are completely missing. We also have to keep in mind that people need to be able to understand our multimedia stack. Right now I think it makes sense: QtMulitmediaKit * high level qt/c++ api that focuses on particular use cases * might apply constraints to keep the api simple QtGStreamer * the full feature set of gstreamer bound to a qt style api GStreamer * high level api (playbin2, camerabin(2), decodebin2, gnonlin, rtpbin, ...) * open and closed multimedia components Kernel * audio/video i/o, network, accelerated codecs, ... * Transparent Encapsulation and Multiplexing: could you please elaborate why one would need the non-automatic mode. I think it does not make sense to let the application specify what format the stream is in, if the media-framework can figure it (in almost all of the cases). In some corner cases one can e.g. use custom pipelines and specify the format (e.g. a ringtone playback service might do that if it knows the format already). Multimedia
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
This is actually quite good in my view, we have a proven working in the wild implementation in official , while all other components are still there to experiment with or showcase when they become mature enough. -Sivan On Fri, Mar 25, 2011 at 11:11 AM, Ville M. Vainio vivai...@gmail.com wrote: On Thu, Mar 24, 2011 at 10:16 PM, Richard Dale richard.d...@telefonica.net wrote: I personally think that the Nepomuk non-application specific integrated data approach could be a killer feature of MeeGo. In comparison iOS is completely Agreed. Luckily tracker will still be there on the platform (as Marius stated earlier in this thread), so it can be used by willing applications. It's just that contact information is not *primarily* stored there anymore - but we can arrange for an (unofficial) way where it gets moved there from EDS anyway. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Fri, 2011-03-25 at 12:19 +0200, Sivan Greenberg wrote: This is actually quite good in my view, we have a proven working in the wild implementation in official , while all other components are still there to experiment with or showcase when they become mature enough. This is certainly a good compromise. But then we just develop a Tracker miner for E-D-S (which is somthing we planned to do anyway in upstream, at least at some point). Some pointers and info on how to make a E-D-S miner for Tracker: http://lists.meego.com/pipermail/meego-dev/2011-March/482147.html Cheers, Philip -- Philip Van Hoof freelance software developer Codeminded BVBA - http://codeminded.be ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Candidate specification for a generic video player from the TV list
Hi again, On 25.03.2011 12:07, Stefan Kost wrote: Hi, On 24.03.2011 23:57, Dominig Ar Foll wrote: snip There is no architectural issue regarding blueray in the our stack. It is more a legal mess. I belive given you have the time and money, you could write blueray support to gstreamer in a similar fashion as we have the dvd support now. The idea presented here is that the UMMS can decide which pipe line to call on depending of URL or the detected stream type without requiring a prior knowledge from the application about the pipeline configuration/selection. That means you would like to have a bunch of different multimedia frameworks on a device and then use an appropriate one depending on the URI. E.g. use gstreamer for some formats and use mplayer for some others. While that might sound like a good idea, I don't think it is one for several reasons: - you will needs to abstract the the different apis (well thats actually your proposal) - you increase size and complexity of the multimedia stack - more difficult to debug (e.g. differnet tools needed) - testing is a lot more difficult - users might get annoyed by small incompatibilities (seeking works differently depending on the media) - you need to do base adaptation several times (integrate codecs, rendering etc. in several frameworks) There might be more reasons that speak against such an approach, but already the last one would be major enough for me. Can't resist, while speaking with a colleague he came up with a good metaphor for the above. Is there an idea car? No, there isn't. Thus instead of fixing the car to be what we want, we have a simpler solution - we take 3 cars, string the together, put an extra seat on the roof and proxy the controls. Then we can drive using the Fiat in the city, using the Porsche on the motorway and using the van when we need more space for transportation. Of course finding a parking space gets tricky ... Stefan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Using meego-dev for the Accounts SSO project
On 03/25/2011 09:52 AM, Rob Staudinger wrote: On Fri, 2011-03-25 at 09:10 +0200, Alberto Mardegan wrote: I would estimate the traffic to be from 1 to 5 messages per day (with some occasional spikes, of course) and being mostly consisting of patches and review comments. I would encourage you to do patch review in bugzilla primarily, and tie in the mailing list only if there's need to. Yes, I'm aware that the contribution guidelines say that a patch needs to go onto the ML first. Since our code is in gitorious.org, we generally do code reviews in gitorious.org, and we just post a URL to a short comment to the mailing list. Trivial/short patches are usually sent to the mailing list. I think it will be challenging enough to convince all the stakeholder to migrate to a different ML; I wouldn't like to also change the review process. But that said, if someone submits patches as bugzilla attachments, it's also fine to review them there. But to ensure that all team members have a chance to view the submissions, I'd rather encourage using the ML. Ciao, Alberto -- http://blog.mardy.it -- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Using meego-dev for the Accounts SSO project
Hi, On 25/03/11 07:10, Alberto Mardegan wrote: Hi all, I'd like to hear your comments about the possibility of moving the development team discussions from an internal (and not public) Nokia mailing list to meego-dev. Looking forward to seeing you all on here. :) I would estimate the traffic to be from 1 to 5 messages per day (with some occasional spikes, of course) and being mostly consisting of patches and review comments. I don't think that will be a problem. If it proves to become a problem, it can always be spun off onto a different list. Ciao, Alberto Best regards, -- Robin Burchell http://rburchell.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Howto get hardware backbutton support on meego UI
Hi, all Do all meego Apps support backbutton as Android platform? when press hardware back button as phone,tablet, can close current app page and go back to previous page. If support, How could send the back button key value from EC to meego app for handling? -- Best Regards Lin ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Friday, March 25, 2011 09:11:48 AM Ville M. Vainio wrote: On Thu, Mar 24, 2011 at 10:16 PM, Richard Dale richard.d...@telefonica.net wrote: I personally think that the Nepomuk non-application specific integrated data approach could be a killer feature of MeeGo. In comparison iOS is completely Agreed. Luckily tracker will still be there on the platform (as Marius stated earlier in this thread), so it can be used by willing applications. It's just that contact information is not *primarily* stored there anymore - but we can arrange for an (unofficial) way where it gets moved there from EDS anyway. Well Tracker is in MeeGo sure, but I was talking about RAD environments on top of Tracker, and in one of the mails on this architecture thread I saw this: On Monday, March 07, 2011 10:06:08 PM Arjan van de Ven wrote: Are you planning to support or implement a QSparql backend for EDS? I suspect we'll never see QSparql in MeeGo the way things are going Disclaimer: I am a QSparql developer QSparql is the standard way of accessing Tracker from Maemo in Qt code, and as far as I know it has been packaged for MeeGo too. In order to build the Qt based RAD environment, that I personally dream of, QSparql will be needed. Maybe it shouldn't be used directly by application programmers, but it will be needed as a base for building visual development tools that might use QML with QtCreator plugins support. -- Richard ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Candidate specification for a generic video player from the TV list
El vie, 25-03-2011 a las 12:07 +0200, Stefan Kost escribió: Hi, On 24.03.2011 23:57, Dominig Ar Foll wrote: Apologies for responding in dual posting. I would like as much as possible to concentrate that type of chat on the TV mailing list but I would not enjoy to leave a question open. Regarding the already existing projects. Are you aware of MAFW on Maemo5 http://www.grancanariadesktopsummit.org/node/219 The implementation might not be perfect, but the concept behind is sane. No I did not know it and I think you for the link. I have so far only written a requirement specification and any idea to move toward a goo implementation specifications are welcomed. I will dig in their documentation. MAFW on Fremantle was mostly done by Igalia. Some of the people now work on Grillo open source project where you might be able to talk to them (on irc). Grilo actually expands on the ideas introduced by MAFW, and we think it fixes many of its shortcomings while keeping the good ideas behind it. I elaborated on the reasons we had to create Grilo and what it provides to multimedia solution developers in a post when we first announced the project [1], it is an old post and some things are outdated (like the link to the repository), but the main ideas are there. I also wrote an article explaining the purpose of Grilo [2] that you might be interested in reading. BTW, I sent a paper to the MeeGo Conference in Dublin with the idea of introducing Grilo to the MeeGo community there. Unfortunately I did not get it accepted, although I did have a lightning talk on the topic. I've sent the proposal again for the San Francisco event [3], hopefully I am more lucky this time around :) I would love to see Grilo included in the multimedia stack of MeeGo, I think it would be a great tool for multimedia solution developers and we (Igalia) would be glad to work on making that possible if the MeeGo community welcomes the addition. Iago [1]http://blogs.igalia.com/itoral/2010/02/10/grilo/ [2]http://www.gnomejournal.org/article/103/grilo-integrating-multimedia-content-in-your-application [3]http://sf2011.meego.com/program/sessions/grilo-enhancing-multimedia-experience-meego ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Friday, March 25, 2011 09:11:48 AM Ville M. Vainio wrote: On Thu, Mar 24, 2011 at 10:16 PM, Richard Dale richard.d...@telefonica.net wrote: I personally think that the Nepomuk non-application specific integrated data approach could be a killer feature of MeeGo. In comparison iOS is completely Agreed. Luckily tracker will still be there on the platform (as Marius stated earlier in this thread), so it can be used by willing applications. It's just that contact information is not *primarily* stored there anymore - but we can arrange for an (unofficial) way where it gets moved there from EDS anyway. Yes Tracker is still part of MeeGo, but I was talking specifically about RAD environments built on top of Tracker. My concern is that I saw this statement in one of the mails in this thread: On Monday, March 07, 2011 10:06:08 PM Arjan van de Ven wrote: Are you planning to support or implement a QSparql backend for EDS? I suspect we'll never see QSparql in MeeGo the way things are going Disclaimer: I am a QSparql developer QSparql is the official way of using Tracker in Maemo Qt based code. As far as I know it has been packaged for MeeGo too, and I am not sure if the above statement from Arjan van de Ven is correct. In order to build the RAD environment, that I personally dream of, QSparql will be needed even if application programmers won't all use it directly. Maybe we can do a visual QtCreator environment via QSparql QML integration and QtCreator plugins, to allow app developers to rapidly create mashups with the application independent data in Tracker. That data might by combined with data from SPARQL endpoints out on the web that is also retrieved via QSparql. -- Richard ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Candidate specification for a generic video player from the TV list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/17/2011 06:57 AM, Stefan Kost wrote: snip In 7 Transparency you need to highlight what your proposal adds to the existing features. * Transport protocol: handled e.g. by gstreamer already, standarts like DLNA specify subsets for interoperability already * Transparent Encapsulation and Multiplexing: could you please elaborate why one would need the non-automatic mode. I think it does not make sense to let the application specify what format the stream is in, if the media-framework can figure it (in almost all of the cases). In some corner cases one can e.g. use custom pipelines and specify the format (e.g. a ringtone playback service might do that if it knows the format already). As a possible example (pulled from recent experience), automagic determination of stream parameters takes time (and CPU cycles). A non-automatic mode would be (was) helpful in instances where the application knows exactly what type of stream to expect, and there is a requirement for an absolute minimum of start-up time between the user pressing the Play button and video appearing on the screen. * Transparent Target: Whats the role of the UMMS here? How does the URI make sense here. Are you suggesting to use something like opengl://localdisplay/0/0/854/480? MAFW was introducing renderers, where a local renderer would render well locally and one could e.g. have a UPnP DLNA renderer or a media recorder. * Transparent Resource Management: That makes a lot of sense and so far was planned to be done on QT MultimediaKit * Attended and Non Attended execution: This sounds like having a media recording service in the platform. 8 Audio Video Control This is a media player interface. Most of the things make sense. Below those that might need more thinking * Codec Selection: please don't. This is something that we need to solve below and not push to the application or even to the user. Agreed, in part. As a general rule, the underlying detection and codec selection should be transparent to an application, however there are corner cases where this may not be desirable, and specific selection of a codec may be necessary. Consider a system which has an external (to the main CPU) PowerDrain-5000(tm) video processor capable of both MPEG-2 and MPEG-4 decode. If the system is in a commanded low-power state, it may be more prudent to decode standard-definition MPEG-2 content in software on the main CPU and leave the external video processor powered-down. However, when decode of MPEG-4 content is desired, soft-decode may not be feasible and the external video hardware needs to be used. In instances, as above, where the system has multiple codecs (hardware and software) capable of decoding given content, is there envisioned some method of specifying codec priority so that a given method of decode is used preferentially? * Buffer Strategy: same as before. Buffering strategy depends on the use-case and media. The application needs to express whether its a media-player/media-editor/.. and from that we need to derive this. But not all use-cases may have the same requirements. Again, from recent experience, my system's requirements for low-latency may or may not match yours. That's not to say that providing some sane defaults that cover a majority of expected use cases isn't a good idea, just don't restrict the application to those and those alone. snip 15 GStreamer It is GStreamer (with a upper case 'S') :) In general please spell check the section. Regarding the three weak points: * smooth fast forward is a seek_event with a rate1.0. There might be elements not properly implementing that, but I fail to understand how you can fix that on higher layers instead of in the elements. It might make sense to define extended compliance criteria for base adaptation vendors to ensure consistent behavior and features. +1. - -Cory - -- Cory T. Tusar Senior Software Engineer Videon Central, Inc. 2171 Sandy Drive State College, PA 16803 (814) 235- x316 (814) 235-1118 fax There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. --Sir Charles Anthony Richard Hoare -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk2MraoACgkQHT1tsfGwHJ+W0wCghQdfIej8YDiGQ/o1bmDVGohs rf4AoI26XSbPONI24mzCDJo5hAOM+PEN =kGk+ -END PGP SIGNATURE- ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Fri, Mar 25, 2011 at 4:53 PM, Richard Dale richard.d...@telefonica.net wrote: On Monday, March 07, 2011 10:06:08 PM Arjan van de Ven wrote: Are you planning to support or implement a QSparql backend for EDS? I suspect we'll never see QSparql in MeeGo the way things are going Disclaimer: I am a QSparql developer QSparql is the standard way of accessing Tracker from Maemo in Qt code, and as far as I know it has been packaged for MeeGo too. In order to build the Qt based RAD environment, that I personally dream of, QSparql will be needed. Is there a particular reason not to have QSparql, when you already have Tracker? (Someone should really summarize these threads in a wiki) Maybe it shouldn't be used directly by application programmers, but it will be needed as a base for building visual development tools that might use QML with QtCreator plugins support. Perhaps you can elaborate on this RAD tools elsewhere, say, meego-community mailing list? I have hard time thinking how a RAD tool for sparql would look like, but the thought is intriguing... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Candidate specification for a generic video player from the TV list
On Fri, 2011-03-25 at 10:58 -0400, Cory T. Tusar wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/17/2011 06:57 AM, Stefan Kost wrote: snip In 7 Transparency you need to highlight what your proposal adds to the existing features. * Transport protocol: handled e.g. by gstreamer already, standarts like DLNA specify subsets for interoperability already * Transparent Encapsulation and Multiplexing: could you please elaborate why one would need the non-automatic mode. I think it does not make sense to let the application specify what format the stream is in, if the media-framework can figure it (in almost all of the cases). In some corner cases one can e.g. use custom pipelines and specify the format (e.g. a ringtone playback service might do that if it knows the format already). As a possible example (pulled from recent experience), automagic determination of stream parameters takes time (and CPU cycles). A non-automatic mode would be (was) helpful in instances where the application knows exactly what type of stream to expect, and there is a requirement for an absolute minimum of start-up time between the user pressing the Play button and video appearing on the screen. A lot of improvement has gone into GStreamer over the past year to speed up the pre-roll/typefinding/setup of playback pipelines. This was mainly to get gst-discoverer to be faster than exiftool to get information about media files, which it now is ... considering it also decodes the first audio/video frame(s). The only case I can think of where you would gain time would be for live mpeg-ts streams where you could provide the PAT/PMT information which you would have cached previously (in order not to have to wait for the next occurence). But that would still require you to wait for the next keyframe to appear unless you already have a few seconds live back-buffer on the machine (in which case you would also have cached PAT/PMT). Did you have another use-case in mind ? * Transparent Target: Whats the role of the UMMS here? How does the URI make sense here. Are you suggesting to use something like opengl://localdisplay/0/0/854/480? MAFW was introducing renderers, where a local renderer would render well locally and one could e.g. have a UPnP DLNA renderer or a media recorder. * Transparent Resource Management: That makes a lot of sense and so far was planned to be done on QT MultimediaKit * Attended and Non Attended execution: This sounds like having a media recording service in the platform. 8 Audio Video Control This is a media player interface. Most of the things make sense. Below those that might need more thinking * Codec Selection: please don't. This is something that we need to solve below and not push to the application or even to the user. Agreed, in part. As a general rule, the underlying detection and codec selection should be transparent to an application, however there are corner cases where this may not be desirable, and specific selection of a codec may be necessary. Consider a system which has an external (to the main CPU) PowerDrain-5000(tm) video processor capable of both MPEG-2 and MPEG-4 decode. If the system is in a commanded low-power state, it may be more prudent to decode standard-definition MPEG-2 content in software on the main CPU and leave the external video processor powered-down. However, when decode of MPEG-4 content is desired, soft-decode may not be feasible and the external video hardware needs to be used. In instances, as above, where the system has multiple codecs (hardware and software) capable of decoding given content, is there envisioned some method of specifying codec priority so that a given method of decode is used preferentially? Yes, with playbin2/decodebin2 you can change the order of codecs/plugins being used. By default it will use the one with the highest rank matching the stream to decode, but you can connect to the 'autoplug-factories' signal and reorder those plugins to have it use the software one or the hardware one. Another way to go around that problem would be to have the software plugin only accept SD streams in input (via its pad template caps) and have a higher rank than the hardware one, which would make the system automatically pick up the SW plugin for SD content, but use the HW one for HD content. * Buffer Strategy: same as before. Buffering strategy depends on the use-case and media. The application needs to express whether its a media-player/media-editor/.. and from that we need to derive this. But not all use-cases may have the same requirements. Again, from recent experience, my system's requirements for low-latency may or may not match yours. That's not to say that providing some sane defaults that cover a majority of expected use cases isn't a good idea, just don't restrict the application to those and those alone. Latency/buffering are
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Friday, March 25, 2011 03:01:43 PM Ville M. Vainio wrote: On Fri, Mar 25, 2011 at 4:53 PM, Richard Dale richard.d...@telefonica.net wrote: On Monday, March 07, 2011 10:06:08 PM Arjan van de Ven wrote: Are you planning to support or implement a QSparql backend for EDS? I suspect we'll never see QSparql in MeeGo the way things are going Disclaimer: I am a QSparql developer QSparql is the standard way of accessing Tracker from Maemo in Qt code, and as far as I know it has been packaged for MeeGo too. In order to build the Qt based RAD environment, that I personally dream of, QSparql will be needed. Is there a particular reason not to have QSparql, when you already have Tracker? I wouldn't have thought there was, but obviously the statement above from Arjan van de Ven concerned me. (Someone should really summarize these threads in a wiki) Maybe it shouldn't be used directly by application programmers, but it will be needed as a base for building visual development tools that might use QML with QtCreator plugins support. Perhaps you can elaborate on this RAD tools elsewhere, say, meego-community mailing list? I have hard time thinking how a RAD tool for sparql would look like, but the thought is intriguing... Well, RDF stores are just databases that happen to be more general and based on graphs, rather than being based on tables like relational databases. Often you can view RDF data as a table and that works fine. But I don't see any reason why visual development tools for RDF/SPARQL stores should look much different to what people are familiar with from tools like Visual Basic. Or ORM's like NeXT/Apple's Enterprise Object Framework, or the Core Data modern equivalent, that are combined with Interface Builder for visually composing UIs. -- Richard ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On 3/25/2011 8:24 AM, Richard Dale wrote: On Friday, March 25, 2011 03:01:43 PM Ville M. Vainio wrote: On Fri, Mar 25, 2011 at 4:53 PM, Richard Dale richard.d...@telefonica.net wrote: On Monday, March 07, 2011 10:06:08 PM Arjan van de Ven wrote: Are you planning to support or implement a QSparql backend for EDS? I suspect we'll never see QSparql in MeeGo the way things are going Disclaimer: I am a QSparql developer QSparql is the standard way of accessing Tracker from Maemo in Qt code, and as far as I know it has been packaged for MeeGo too. In order to build the Qt based RAD environment, that I personally dream of, QSparql will be needed. Is there a particular reason not to have QSparql, when you already have Tracker? I wouldn't have thought there was, but obviously the statement above from Arjan van de Ven concerned me. my concern is based on the (lack of) progress around QSparql in MeeGo. I'm sure it's all great in Harmattan, but a solid story for MeeGo has so far been lacking. Ideally QSparql becomes a real, full and open source member of the Qt family of APIs. (a solid story also includes proper moving away from older APIs) Until that's there color me a bit skeptical... it's been promised for a long time and hasn't really materialized very well yet. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
Hi Arjen, On Fri, Mar 25, 2011 at 17:30, Arjan van de Ven ar...@linux.intel.com wrote: I wouldn't have thought there was, but obviously the statement above from Arjan van de Ven concerned me. my concern is based on the (lack of) progress around QSparql in MeeGo. I'm sure it's all great in Harmattan, but a solid story for MeeGo has so far been lacking. Ideally QSparql becomes a real, full and open source member of the Qt family of APIs. (a solid story also includes proper moving away from older APIs) Where exactly your concerns are coming from? http://maemo.gitorious.org/maemo-af/qsparql and http://maemo.gitorious.org/maemo-af/libqtsparql-tracker are alive and available. Development there hapens daily. Developers are available at upstream tracker IRC channel. The code there exactly what is used in Harmattan, packages get built straight out of gitorious.org. Are you concerned that nobody has submitted libqtsparql-tracker for about three months to OBS? QSparql build itself as over a month old. I guess an architecture decision story hasn't really added any assurance at all. Until that's there color me a bit skeptical... it's been promised for a long time and hasn't really materialized very well yet. Code is there open, development is happening openly, and for what it worth, it gets very extensive testing as part of Harmattan application development. Don't tell me that at this level (Tracker - QSparql) testing in MeeGo would be totally different from any other recent GNU/Linux environment. Regarding proper moving away from older APIs, meego-handset-photos hasn't seen any development in gitorious.org since October2010. Where can I find a recent version? -- / Alexander Bokovoy ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo qemu minimal console image howto
On Fri, Mar 25, 2011 at 2:51 PM, Ameya Palande ameya.pala...@nokia.com wrote: On 03/24/2011 04:16 PM, ext Jeremiah Foster wrote: On Wed, Mar 23, 2011 at 6:07 PM, Ameya Palandeameya.pala...@nokia.com I have created a small howto for creating a minimal MeeGo Qemu console image. http://wiki.meego.com/Minimal_image Comments/Suggestions/Contributions are welcome! Thanks for doing this! A couple questions the link on the wiki goes to the repository of MeeGo package patterns on Gitorious but I don't seem meego-minimal-console there. My intention is to create such a pattern! The meego-minimal that is there has X, is that the one you're using? I used core-ia32-base-nodocs as my base kickstart file. Secondly, what is the goal? Is it to create the smallest set of packages and dependencies that will boot? How does this interact with MeeGo Core? This image can be used for debugging meego startup scripts, reducing meego footprint etc. Sounds very useful. I look forward to trying it out! Jeremiah ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Idle hands are the devil's tools, aka the MeeGo SDK installer
Warning. Agitated rant ahead. In a moment of Friday afternoon boredom following a tweet about a certain competition I decided to check out the state of the 'official' offering and got the Linux install from http://appdeveloper.intel.com/en-us/meego-sdk-suite. Smallish thing, an installer I think to myself, okay... Are you sure ? Of course I'm sure. It says it wants sudo and stuff... well, okay, I would have preferred to do the apt-getting myself if that's what it does anyway... I know, what kind of idiot sudos some random installer from the Internet... Well, I did happen to have a previous install on my otherwise bog-standard Lucid hack-machine and the installer happily offers to remove 6-7 packages from that. Says continue with existing not recommended, well, okay, then proceed with remove... And yes, I know, that's a double fail, I asked for it (cue laugh). As it turns out, the eager beaver installer apt-get bloody *force* removed pretty much all of my Kubuntu install, all the way down to kdm. WTF ? But you said just 6-7 packages... (haha, sucker !). But a fail is a fail only if you don't learn from it, so let's see what we can learn from this incident (apart from saying 'no thanks' to stupid sudo-requiring installers even if they come from official sources). Checking out the installer script you can see what caused the meltdown: echo MeeGo SDK components found. echo $PKGS setFontColor red echo -e The following packages are installed and will be uninstalled\n \ prior to installing the MeeGo SDK: echo$PKGS setFontColor blue echo -e Would you like to uninstall all previously \ installed MeeGo SDK components now?\n \ \t(u)ninstall now\n \ \t(s)kip uninstall and proceed (not recommended)\n \ \t(e)xit installation read -p Select option (u/s/e): setFontColor default if [ $REPLY == u ] [ $REPLY != U ]; then if [ $OS == Ubuntu ]; then apt-get autoremove -y $PKGS \(is this safe / necessary ?) I don't know who asked that there, but let me answer. I don't know if it's necessary, but it's VERY not safe (I'll refrain from using derogatory terms this time). You display the packages YOU want to uninstall and then tell apt to remove whatever IT thinks is right (along with, you know, dependencies). What the frack happened to apt-get --just-print (dry-run) and then proceeding ? And I thought the QtSDK is sometimes a bit rough around the edges and people are sometimes too heavy criticizing error-prone SDK setups... but that's peanuts compared to this monster-fail, seeing apt kill your install was not a pleasant sight (now I know how people accidentlaly typing rm -rf / feel). Not. Frackin'. Funny. At. All. Sorry about the agitated mail, now I have the weekend fun of a devel machine to setup, instead of doing something productive like the initial idea from an hour ago of publishing something to AppUp developer challenge by using the official tools in the process. I guess you can call that learning the hard way. End of rant. And have a nice day. Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Idle hands are the devil's tools, aka the MeeGo SDK installer
On Mar 25, 2011, at 11:31 AM, Attila Csipa wrote: Warning. Agitated rant ahead. In a moment of Friday afternoon boredom following a tweet about a certain competition I decided to check out the state of the 'official' offering and got the Linux install from http://appdeveloper.intel.com/en-us/meego-sdk-suite. Smallish thing, an installer I think to myself, okay... Are you sure ? Of course I'm sure. It says it wants sudo and stuff... well, okay, I would have preferred to do the apt-getting myself if that's what it does anyway... I know, what kind of idiot sudos some random installer from the Internet... Well, I did happen to have a previous install on my otherwise bog-standard Lucid hack-machine and the installer happily offers to remove 6-7 packages from that. Says continue with existing not recommended, well, okay, then proceed with remove... And yes, I know, that's a double fail, I asked for it (cue laugh). As it turns out, the eager beaver installer apt-get bloody *force* removed pretty much all of my Kubuntu install, all the way down to kdm. WTF ? B ut you said just 6-7 packages... (haha, sucker !). But a fail is a fail only if you don't learn from it, so let's see what we can learn from this incident (apart from saying 'no thanks' to stupid sudo-requiring installers even if they come from official sources). Checking out the installer script you can see what caused the meltdown: echo MeeGo SDK components found. echo $PKGS setFontColor red echo -e The following packages are installed and will be uninstalled\n \ prior to installing the MeeGo SDK: echo$PKGS setFontColor blue echo -e Would you like to uninstall all previously \ installed MeeGo SDK components now?\n \ \t(u)ninstall now\n \ \t(s)kip uninstall and proceed (not recommended)\n \ \t(e)xit installation read -p Select option (u/s/e): setFontColor default if [ $REPLY == u ] [ $REPLY != U ]; then if [ $OS == Ubuntu ]; then apt-get autoremove -y $PKGS \(is this safe / necessary ?) I don't know who asked that there, but let me answer. I don't know if it's necessary, but it's VERY not safe (I'll refrain from using derogatory terms this time). You display the packages YOU want to uninstall and then tell apt to remove whatever IT thinks is right (along with, you know, dependencies). What the frack happened to apt-get --just-print (dry-run) and then proceeding ? And I thought the QtSDK is sometimes a bit rough around the edges and people are sometimes too heavy criticizing error-prone SDK setups... but that's peanuts compared to this monster-fail, seeing apt kill your install was not a pleasant sight (now I know how people accidentlaly typing rm -rf / feel). Not. Frackin'. Funny. At. All. Sorry about the agitated mail, now I have the weekend fun of a devel machine to setup, instead of doing something productive like the initial idea from an hour ago of publishing something to AppUp developer challenge by using the official tools in the process. I guess yo u can call that learning the hard way. End of rant. And have a nice day. I'm looking into this now to get that installer pulled off of the website and fixed. Dawn ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Idle hands are the devil's tools, aka the MeeGo SDK installer
On Mar 25, 2011, at 12:31 PM, Attila Csipa wrote: Please do. I would also recommend a *thorough* review for the whole script. Absolutely. The Linux SDK has been removed from the website, and we're doing a thorough review of the code now. The team was already in the process of re-writing that code anyway (unaware of this particular bug) to make other improvements. We hope to have a new version out next week (assuming QA goes well on this new code), and you can be sure we're testing some additional use cases to make sure we don't have a repeat of your issues. Thanks for all of your detailed descriptions about the problems. They were very helpful in narrowing down the issue! Dawn ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Systray
On Wed, Mar 23, 2011 at 3:45 PM, Leonardo Luiz Padovani da Mata leonar...@syst.com.br wrote: Hello, Is there plans to change matchbox-panel to a different systray? Do the netbook image support standrt behavior of system tray like icons on botton left on kde or windows. I'm wondering how to deal with a java application that runs a system tray icon and pop-up messages to users. What are the plans for the Future of System Tray on MeeGo? I remember that MeeGo netbook UX included an option to view the system tray icons, a new floating bar appeared showing the tray icons, it did not look well integrated. - Fernando ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Idle hands are the devil's tools, aka the MeeGo SDK installer
On 03/25/11 13:03, Foster, Dawn M wrote: On Mar 25, 2011, at 12:31 PM, Attila Csipa wrote: Please do. I would also recommend a *thorough* review for the whole script. Absolutely. The Linux SDK has been removed from the website, and we're doing a thorough review of the code now. The team was already in the process of re-writing that code anyway (unaware of this particular bug) to make other improvements. We hope to have a new version out next week (assuming QA goes well on this new code), and you can be sure we're testing some additional use cases to make sure we don't have a repeat of your issues. Thanks for all of your detailed descriptions about the problems. They were very helpful in narrowing down the issue! Absolutely, thanks for letting us know and taking the time to dig a bit deeper into the issue. I do encourage you to file a bugzilla so this can be tracked, so that this e-mail isn't the last one you will ever hear about that Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Session/BoF Proposals for MeeGo Conference due in 9 hours
This is your final reminder that session proposals and Birds of a Feather (BoF) proposals are due today at 23:59 PST (in just 9.5 hours). http://sf2011.meego.com/program/call-session-proposals Regards, Dawn ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Session/BoF Proposals for MeeGo Conference due in 9 hours
Mine is there. I hope to get more information about hotel reservation and sponsorship. Since i (and other participants) need to get a visa to go to USA, please, consider to have the final version of sessions as soon as possible! On Fri, Mar 25, 2011 at 6:34 PM, Foster, Dawn M dawn.m.fos...@intel.com wrote: This is your final reminder that session proposals and Birds of a Feather (BoF) proposals are due today at 23:59 PST (in just 9.5 hours). http://sf2011.meego.com/program/call-session-proposals Regards, Dawn ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines -- Leonardo Luiz Padovani da Mata International Syst S/A Metasys Tecnologia Software Engineer Metasys MeeGo Team leonar...@metasys.com.br +55-31-3503-9040 May the force be with you, always Nerd Pride... eu tenho. Voce tem? ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Session/BoF Proposals for MeeGo Conference due in 9 hours
On Fri, Mar 25, 2011 at 6:46 PM, Leonardo Luiz Padovani da Mata leonar...@syst.com.br wrote: Mine is there. I hope to get more information about hotel reservation and sponsorship. Since i (and other participants) need to get a visa to go to USA, please, consider to have the final version of sessions as soon as ***consider to have the final version of ACCEPTED sessions as soon as possible! possible! On Fri, Mar 25, 2011 at 6:34 PM, Foster, Dawn M dawn.m.fos...@intel.com wrote: This is your final reminder that session proposals and Birds of a Feather (BoF) proposals are due today at 23:59 PST (in just 9.5 hours). http://sf2011.meego.com/program/call-session-proposals Regards, Dawn ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines -- Leonardo Luiz Padovani da Mata International Syst S/A Metasys Tecnologia Software Engineer Metasys MeeGo Team leonar...@metasys.com.br +55-31-3503-9040 May the force be with you, always Nerd Pride... eu tenho. Voce tem? -- Leonardo Luiz Padovani da Mata International Syst S/A Metasys Tecnologia Software Engineer Metasys MeeGo Team leonar...@metasys.com.br +55-31-3503-9040 May the force be with you, always Nerd Pride... eu tenho. Voce tem? ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Session/BoF Proposals for MeeGo Conference due in 9 hours
On Friday, 25 de March de 2011 18:47:23 Leonardo Luiz Padovani da Mata wrote: On Fri, Mar 25, 2011 at 6:46 PM, Leonardo Luiz Padovani da Mata leonar...@syst.com.br wrote: Mine is there. I hope to get more information about hotel reservation and sponsorship. Since i (and other participants) need to get a visa to go to USA, please, consider to have the final version of sessions as soon as ***consider to have the final version of ACCEPTED sessions as soon as possible! Hello Leonardo We'll try to get the initial list of approved sessions in two weeks. It will be a tight schedule for the program team, but we'll do our best. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On 25/03/11 09:11, Ville M. Vainio wrote: On Thu, Mar 24, 2011 at 10:16 PM, Richard Dale richard.d...@telefonica.net wrote: I personally think that the Nepomuk non-application specific integrated data approach could be a killer feature of MeeGo. In comparison iOS is completely Agreed. Luckily tracker will still be there on the platform (as Marius stated earlier in this thread), so it can be used by willing applications. It's just that contact information is not *primarily* stored there anymore - but we can arrange for an (unofficial) way where it gets moved there from EDS anyway. Would it be helpful to have a branch project area on the community OBS? Conceptually this is similar to the Project:DE which is tracking trunk and maintaining an overlay. It may help to show me the code and to maintain patchsets over time as MeeGo:Trunk moves. David/lbt -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Candidate specification for a generic video player from the TV list
FYI, I just proposed a BOF that will partially be on this topic from an app-developers pt-of-view: http://sf2011.meego.com/program/sessions/bof-developing-qml-youtube-api-and-internet-video BOF: Developing in QML for YouTube API and Internet video ... [...] demonstrate powerful techniques for working with YouTube feeds and for displaying YouTube videos in QML-based apps. Discussion on ideas, implementation strategies and applications of Internet video in MeeGo; focus will be on QML implementation, providing touch-interfaces for streaming media browsing, hybrid implementations involving Flash embedded in WebKit implementations, issues with using QtMultimediaKit Player, and discussion of alternatives. [...] e. Open discussion on media players including issues with using QtMultimediaKit Player in QML, and discussion of alternatives such as Grilo ( http://sf2011.meego.com/program/sessions/grilo-enhancing-multimedia-experience-meego ), MAFW ( http://www.grancanariadesktopsummit.org/node/219 ), gst123 ( http://space.twc.de/~stefan/gst123.php ) and the Media Lovin' Toolkit ( http://www.mltframework.org/ ) which is the basis of the amazing http://wiki.meego.com/MeeGo-Lem#The_OpenShot_Video_Editor . ... Any suggestions or changes? Let me know... it's not midnight yet! :-), especially from pt-of-view of using aforementioned playback/loop/clip tools from QML. Niels http://nielsmayer.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
