[MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
Hi all, MeeGo is dead ... long live Tizen !! - Haven't we heard that before? - Maemo, Moblin? We need a community that transcends the mere branding of MeeGo, Maemo, Moblin - and now Tizen. A lot of proposals have been put forward: * Move to Tizen and trust that They'll get it right this time * Merge or join some existing projects (like the Qt Project, Debian, openSUSE, etc) * Keep MeeGo alive by approaching the Linux Foundation The goal is to find a truly sustainable way for MeeGo and other interested communities to work with Tizen. Our solution is the Mer Project: How does the concept of a truly open and inclusive integration community for devices sound? After all if upstream is king - then contributions will end up the same place, no matter if it's Tizen, Maemo, MeeGo or openSUSE. Some history - many of us in MeeGo originated from a project called Mer, short for Maemo Reconstructed - where we approached doing a open mobile platform through reconstruction of the Maemo platform into a open platform. We were big on open governance, open development and open source. For a few months a group of us have been working on various scenarios of change in MeeGo [1] and now that the Tizen news is out in the open, it's time to talk about what we as a community can make happen next. To make it clear: this is not in any way an anti-Tizen or anti-Intel project, but a direction we can and will go in - we strongly want to collaborate with Tizen and Intel. We will continue to welcome contribution and participation from the hacker community - in fact we aim to make it so easy to port to a new vendor device that a single hacker could do it for their device. We decided to approach the problems and potential scenarios of change in MeeGo in the light of the reallocation of resources caused by what is now known as the Tizen work. There have not been any Trunk/1.3 releases since August and Tablet UX has totally stalled. What really works (and works quite well) is the Core. It's time to take the pieces and use them for reconstruction. We have some clear goals: * To be openly developed and openly governed as a meritocracy * That primary customers of the platform are device vendors - not end-users. * To provide a device manufacturer oriented structure, processes and tools: make life easy for them * To have a device oriented architecture * To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5) * To innovate in the mobile OS space Now we'd like to talk a bit about what specific initiatives we propose to take: 0) Becoming MeeGo 2.0 Our work has the intended goal of being MeeGo 2.0 - and we hope that the Linux Foundation will see our work as a worthy succesor within the MeeGo spirit. We'd like to provide ability to be Tizen compliant, i.e. supporting HTML5/WAC and the application story there and feed back to that ecosystem. 1) Modularity. A set of architectural components for making devices. Rather than dictate the architecture we will support collaboration and the flexibility to easily access off-the-shelf components for device projects. Component independence permits focused feature and delivery management too. Initially the project will be developing a Core for basing products on and will split UX and hardware adaptations out into seperate projects within the community surrounding the Core. 2) Working towards an ultra-portable Linux + HTML5/QML/JS Core for building products with. We have already taken MeeGo and cut it into a set of 302 source packages that can boot into a Qt UI along with standard MeeGo stack pieces. This work can be seen already at [2] and we've made our first release and have had it booting on devices already[6]. To ease maintenance, we would like to encourage people to participate in the Core work of the Tizen project, utilizing their work where we can in Mer: why do the same work twice? Even if Tizen turns out to be dramatically different, the maintenance load of 302 source packages - much of it typical Linux software, is significantly lower than that of the 1400 packages found in MeeGo today. Using another lesson learned from MeeGo, we also want to port this work to everywhere, ARMv6/7 - hardfp, softfp, i486, Atom, MIPS, etc - allowing much more freedom for porting to new devices. 3) Change governance towards a more technically oriented one, similar to the Yocto Project We'd like to propose a revamp of governance based upon the Yocto Project governance - which is much more geared towards open technical work - encouraging collaboration and discussion. You can look at a description of this at [3]. 4) Work towards better vendor relations and software to support these as well as easier contribution methods. As part of our customer oriented goal we're improving delivery methods from Mer. We are designing simpler and more resilient update mechanisms to support smaller and more distributed organisations (think outsourcing too!). We want to encourage easy upstream contribution and
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
2011/10/3 Carsten Munk cars...@maemo.org Hi all, Our solution is the Mer Project: Excellent! count me in. A few questions about the project's communication channels? Do we use these MeeGo mailing list, the meego-* IRC channels or are we moving somewhere? (IMO moving to mer-specific channels would make sense) -Timo ___ 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 Reconstructed - a plan of action and direction for MeeGo
2011/10/3 Timo Härkönen timop.harko...@gmail.com: 2011/10/3 Carsten Munk cars...@maemo.org Hi all, Our solution is the Mer Project: Excellent! count me in. A few questions about the project's communication channels? Do we use these MeeGo mailing list, the meego-* IRC channels or are we moving somewhere? (IMO moving to mer-specific channels would make sense) I think for now, we use mer specific channels. Ideally we'd like to stay within MeeGo community, but for reasons such as trademark usage and uncertain future, we'd like to earn ability to use MeeGo as a name through actual effort and merit. Also, I seem to have learnt that cross posting is bad, seems like I posted to meego-commits@ as well instead of meego-community. BR Carsten Munk ___ 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 Reconstructed - a plan of action and direction for MeeGo
Carsten Hi, Your aims are why I was draw to MeeGo in the first place and its good to see you aiming even higher. 'We will continue to welcome contribution and participation from the hacker community - in fact we aim to make it so easy to port to a new vendor device that a single hacker could do it for their device.' That's me so count me in. vgrade PS thanks for adding the Pi video link On Mon, Oct 3, 2011 at 7:01 AM, Carsten Munk cars...@maemo.org wrote: Hi all, MeeGo is dead ... long live Tizen !! - Haven't we heard that before? - Maemo, Moblin? We need a community that transcends the mere branding of MeeGo, Maemo, Moblin - and now Tizen. A lot of proposals have been put forward: * Move to Tizen and trust that They'll get it right this time * Merge or join some existing projects (like the Qt Project, Debian, openSUSE, etc) * Keep MeeGo alive by approaching the Linux Foundation The goal is to find a truly sustainable way for MeeGo and other interested communities to work with Tizen. Our solution is the Mer Project: How does the concept of a truly open and inclusive integration community for devices sound? After all if upstream is king - then contributions will end up the same place, no matter if it's Tizen, Maemo, MeeGo or openSUSE. Some history - many of us in MeeGo originated from a project called Mer, short for Maemo Reconstructed - where we approached doing a open mobile platform through reconstruction of the Maemo platform into a open platform. We were big on open governance, open development and open source. For a few months a group of us have been working on various scenarios of change in MeeGo [1] and now that the Tizen news is out in the open, it's time to talk about what we as a community can make happen next. To make it clear: this is not in any way an anti-Tizen or anti-Intel project, but a direction we can and will go in - we strongly want to collaborate with Tizen and Intel. We will continue to welcome contribution and participation from the hacker community - in fact we aim to make it so easy to port to a new vendor device that a single hacker could do it for their device. We decided to approach the problems and potential scenarios of change in MeeGo in the light of the reallocation of resources caused by what is now known as the Tizen work. There have not been any Trunk/1.3 releases since August and Tablet UX has totally stalled. What really works (and works quite well) is the Core. It's time to take the pieces and use them for reconstruction. We have some clear goals: * To be openly developed and openly governed as a meritocracy * That primary customers of the platform are device vendors - not end-users. * To provide a device manufacturer oriented structure, processes and tools: make life easy for them * To have a device oriented architecture * To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5) * To innovate in the mobile OS space Now we'd like to talk a bit about what specific initiatives we propose to take: 0) Becoming MeeGo 2.0 Our work has the intended goal of being MeeGo 2.0 - and we hope that the Linux Foundation will see our work as a worthy succesor within the MeeGo spirit. We'd like to provide ability to be Tizen compliant, i.e. supporting HTML5/WAC and the application story there and feed back to that ecosystem. 1) Modularity. A set of architectural components for making devices. Rather than dictate the architecture we will support collaboration and the flexibility to easily access off-the-shelf components for device projects. Component independence permits focused feature and delivery management too. Initially the project will be developing a Core for basing products on and will split UX and hardware adaptations out into seperate projects within the community surrounding the Core. 2) Working towards an ultra-portable Linux + HTML5/QML/JS Core for building products with. We have already taken MeeGo and cut it into a set of 302 source packages that can boot into a Qt UI along with standard MeeGo stack pieces. This work can be seen already at [2] and we've made our first release and have had it booting on devices already[6]. To ease maintenance, we would like to encourage people to participate in the Core work of the Tizen project, utilizing their work where we can in Mer: why do the same work twice? Even if Tizen turns out to be dramatically different, the maintenance load of 302 source packages - much of it typical Linux software, is significantly lower than that of the 1400 packages found in MeeGo today. Using another lesson learned from MeeGo, we also want to port this work to everywhere, ARMv6/7 - hardfp, softfp, i486, Atom, MIPS, etc - allowing much more freedom for porting to new devices. 3) Change governance towards a more technically oriented one, similar to the Yocto Project We'd like to propose a revamp of governance based upon the Yocto
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
From: Carsten Munk cars...@maemo.org To: meego-dev meego-dev@meego.com; meego-comm...@meego.com Sent: Monday, October 3, 2011 1:01 AM Subject: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo Hi all, MeeGo is dead ... long live Tizen !! - Haven't we heard that before? - Maemo, Moblin? We need a community that transcends the mere branding of MeeGo, Maemo, Moblin - and now Tizen. ... Our solution is the Mer Project: Count me in, Carsten, David and Robin, even if I get involved with other projects. Randall (Randy) Arnold http://texrat.net ___ 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 Reconstructed - a plan of action and direction for MeeGo
Hi, -Original Message- From: Randall Arnold From: Carsten Munk cars...@maemo.org To: meego-dev meego-dev@meego.com; meego-comm...@meego.com Sent: Monday, October 3, 2011 1:01 AM Subject: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo Hi all, MeeGo is dead ... long live Tizen !! - Haven't we heard that before? - Maemo, Moblin? We need a community that transcends the mere branding of MeeGo, Maemo, Moblin - and now Tizen. ... Our solution is the Mer Project: Count me in, Carsten, David and Robin, even if I get involved with other projects. +1 from me I didn't manage for openMind, but I promise to look into Mer on Archos gen6/7/8/9, BeagleBoard, PandaBoard and SnowBall as soon as I recover from this head cold and find some spare time. (help welcome!) Cheers Thomas ___ 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 Reconstructed - a plan of action and direction for MeeGo
Hi, Sounds great! Count me in. -- Iekku -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev- boun...@meego.com] On Behalf Of ext Carsten Munk Sent: 03 October, 2011 09:01 To: meego-dev; meego-comm...@meego.com Subject: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo Hi all, MeeGo is dead ... long live Tizen !! - Haven't we heard that before? - Maemo, Moblin? We need a community that transcends the mere branding of MeeGo, Maemo, Moblin - and now Tizen. A lot of proposals have been put forward: * Move to Tizen and trust that They'll get it right this time * Merge or join some existing projects (like the Qt Project, Debian, openSUSE, etc) * Keep MeeGo alive by approaching the Linux Foundation The goal is to find a truly sustainable way for MeeGo and other interested communities to work with Tizen. Our solution is the Mer Project: How does the concept of a truly open and inclusive integration community for devices sound? After all if upstream is king - then contributions will end up the same place, no matter if it's Tizen, Maemo, MeeGo or openSUSE. Some history - many of us in MeeGo originated from a project called Mer, short for Maemo Reconstructed - where we approached doing a open mobile platform through reconstruction of the Maemo platform into a open platform. We were big on open governance, open development and open source. For a few months a group of us have been working on various scenarios of change in MeeGo [1] and now that the Tizen news is out in the open, it's time to talk about what we as a community can make happen next. To make it clear: this is not in any way an anti-Tizen or anti-Intel project, but a direction we can and will go in - we strongly want to collaborate with Tizen and Intel. We will continue to welcome contribution and participation from the hacker community - in fact we aim to make it so easy to port to a new vendor device that a single hacker could do it for their device. We decided to approach the problems and potential scenarios of change in MeeGo in the light of the reallocation of resources caused by what is now known as the Tizen work. There have not been any Trunk/1.3 releases since August and Tablet UX has totally stalled. What really works (and works quite well) is the Core. It's time to take the pieces and use them for reconstruction. We have some clear goals: * To be openly developed and openly governed as a meritocracy * That primary customers of the platform are device vendors - not end-users. * To provide a device manufacturer oriented structure, processes and tools: make life easy for them * To have a device oriented architecture * To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5) * To innovate in the mobile OS space Now we'd like to talk a bit about what specific initiatives we propose to take: 0) Becoming MeeGo 2.0 Our work has the intended goal of being MeeGo 2.0 - and we hope that the Linux Foundation will see our work as a worthy succesor within the MeeGo spirit. We'd like to provide ability to be Tizen compliant, i.e. supporting HTML5/WAC and the application story there and feed back to that ecosystem. 1) Modularity. A set of architectural components for making devices. Rather than dictate the architecture we will support collaboration and the flexibility to easily access off-the-shelf components for device projects. Component independence permits focused feature and delivery management too. Initially the project will be developing a Core for basing products on and will split UX and hardware adaptations out into seperate projects within the community surrounding the Core. 2) Working towards an ultra-portable Linux + HTML5/QML/JS Core for building products with. We have already taken MeeGo and cut it into a set of 302 source packages that can boot into a Qt UI along with standard MeeGo stack pieces. This work can be seen already at [2] and we've made our first release and have had it booting on devices already[6]. To ease maintenance, we would like to encourage people to participate in the Core work of the Tizen project, utilizing their work where we can in Mer: why do the same work twice? Even if Tizen turns out to be dramatically different, the maintenance load of 302 source packages - much of it typical Linux software, is significantly lower than that of the 1400 packages found in MeeGo today. Using another lesson learned from MeeGo, we also want to port this work to everywhere, ARMv6/7 - hardfp, softfp, i486, Atom, MIPS, etc - allowing much more freedom for porting to new devices. 3) Change governance towards a more technically oriented one, similar to the Yocto Project We'd like to propose a revamp of governance based upon the Yocto Project governance - which is much more geared towards open technical work - encouraging collaboration and discussion. You can look at a description of this at [3]. 4) Work towards better vendor relations and software to
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
Il 10/03/2011 09:01 AM, Carsten Munk ha scritto: The goal is to find a truly sustainable way for MeeGo and other interested communities to work with Tizen. Our solution is the Mer Project: [...] That's fantastic! I can't make any promises, as free time is an obsolete concept for me, but I'll support the project as much as I can. Thanks guys for driving this! Ciao, Alberto ___ 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] Audio policy -- Adding one's own resource class
So does libresource expose a DBUS interface ? I'm asking this because say I'm
running Ubuntu , Chrooted on Meego then I would need these DBUS API's to
interact with the policy framework.
-Original Message-
From: Sami Sirkiä [mailto:sami.sir...@cybercom.com]
Sent: Friday, September 23, 2011 5:50 PM
To: meego-dev@meego.com
Cc: Chanchani, Nimesh
Subject: Re: [MeeGo-dev] Audio policy -- Adding one's own resource class
Yes, that is how it behaves.
Policy rules can be changed per product, but there is no way an
application could bring in a new rule.
BR,
SSirkia
On 09/23/2011 01:55 PM, nimesh.chanch...@accenture.com wrote:
Thx! Sami .
So as I understand, policy unaware apps don't have to request for resources.
They just have to start using it? And ohmd will cork or uncork the resources
as and when it desires?
-Original Message-
From: Sami Sirkiä [mailto:sami.sir...@cybercom.com]
Sent: Friday, September 23, 2011 4:13 PM
To: meego-dev@meego.com
Cc: Chanchani, Nimesh
Subject: Re: [MeeGo-dev] Audio policy -- Adding one's own resource class
Hi,
Resource policy daemon (ohmd) has an enforcement module in pulseaudio.
A policy-unaware application may play sounds, but the streams are corked
if there are higher priority streams playing.
This means the audio from anroid app is not audible during phone calls,
and the application does not even know this.
The musix player in handset images is policy-unavare. It keeps playing
happily during phone calls and ringtone, although music does not come
out. When ringing or call ends, music is again routed out.
If I recall correctly, recording is not enforced. Application can
record, but nothing guarantees that some sounds are played
simultaneously. player priority is just a name, recording is also
possible.
I don't know of any way to prioritize policy-unaware apps/streams.
Instead their audio streams are mixed together. (I think...)
But then, I may remember things wrong.
--
SSirkia
On 09/23/2011 01:04 PM, nimesh.chanch...@accenture.com wrote:
Thanks Tukka . I have aa few questions about policy unaware apps:
If the apps don't ask for the permission (policy unaware apps), they are
all going to be treated as media players. In this case, how can they
know if they are granted the permission to use a particular resource
set? For instance let's assume a policy-unaware Android app wants to
play audio through the speakers while the speakers are already in use by
a higher priority app. In this case the policy framework denies the
permission; how does the policy unaware app get notified?
Is there a way to give different priorities to policy-unaware apps? For
example, an phone call should have higher priority over the audio player.
What happens if a policy-unaware app wants to record audio? I guess that
is not going to be possible, since all policy unaware apps are treated
as media players by the policy framework.
*From:*meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com]
*On Behalf Of *Tuukka Mäkinen
*Sent:* Thursday, September 22, 2011 6:40 PM
*To:* meego-dev@meego.com
*Subject:* Re: [MeeGo-dev] Audio policy -- Adding one's own resource class
On 09/22/11 15:44, nimesh.chanch...@accenture.com
mailto:nimesh.chanch...@accenture.com wrote:
Hi guys,
I want to add my own resource class and alter the priorities of the
existing ones. Can anyone suggest a starting point or a pointer?
Regards,
Nimesh
Policy settings are in the package policy-settings-basic-{platform}
package. That package contains policy rules (in prolog) and some
settings files. Looking into settings package for N900 resource classes
appear to be defined in resource_classes.pl.
It would be interesting to see what could be done with policy framework
but unfortunately I haven't quite grasped prolog.
Tuukka Mäkinen
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete
the original. Any other use of the email by you is prohibited.
This message is for the designated recipient only and may contain privileged,
proprietary, or otherwise private information. If you have received it in
error, please notify the sender immediately and delete the original. Any
other use of the email by you is prohibited.
___
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] Where's the evidence that Tizen will contain *any* MeeGo code?
On Fri, Sep 30, 2011 at 6:45 PM, Robin Burchell robin+me...@viroteck.netwrote: LiFo owns MeeGo and won't let us the name, to be sure, I'm not so sure about that, and nothing stops us from asking. The worst that can happen is that we're told no, and have to come up with a new name. Why would you want it? It is a name synonymous with failure now. But seriously, if the worst case occurs and Tizen bears nearly no resemblance to MeeGo, why shouldn't we consider working on Qt development with Ubuntu Core, which is focused on ARM? Different silicon for different situations. From previous experiments that I've seen with Ubuntu, performance-wise, I don't think this would be an option. Okay, now you're starting to wander off into the woods here. You're going to have to be very specific with what you claim are performance problems, don't just throw out unsupported claims because you've got some random anecdotal evidence. Linaro has made Android run 11% faster and I'm certain other Linux optimizations have come along with that as well that affect the GNU userland. If anything, deb based systems running Linaro perform much better than rpm systems which traditionally are not multi-platform and are aimed at the server. MeeGo Core is deliciously bare, which is one of the reasons it is a good choice for mobile (and also one of the reasons that makes me think we'll see parts of it live on in Tizen). Abandoning that legacy and jumping on board another distro is certainly an option, but not, I believe, the best available. Linaro has done huge amounts of work on the Linux kernel on ARM silicon. ARM chips have extraordinary price to performance ratio and can scale down as well as up to multicore. If you're serious about Mobile Computing, you have to look seriously at the ARM processor. Debian and Ubuntu are the two distributions that have; - Commercial support - A decade long history of supporting ARM (and other platforms) - A large highly-competent ecosystem It makes a great deal of sense to just port some of the MeeGo stuff over to deb-based systems, at least some of it, other parts of it already exist. [ of course, you're free to make your own decision ] Intel's possible complete departure, MeeGo development on Atom may completely stop, while Ubuntu Core is completely focused on ARM. Wrong. Ubuntu works very hard to stress that they are not just an ARM distro - they have a great x86 distro too. And that complete focus is a bad thing, Again, wrong. Your making assumptions. it just minimalises your portability, Now you just don't know what you're talking about. Debian is much, much more portable than MeeGo is or Tizen will ever be. Regards, Jeremiah ___ 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] Who will keep pushing MeeGo?
On Fri, Sep 30, 2011 at 7:40 PM, quim@nokia.com wrote: Dave wrote: and at best an improvement (HTML5 vs QML). Fwiw QML doesn't stop any HTML5 improvement. In fact it plays perfectly well with HTML Javascript next to its neighbor QtWebKit, and bridges web development with native development (if you need it) down to core C/C++. If you need additional features not covered that web engine/framework X provides, you can add such engine/framework or you can improve/add to the Qt web engine/framework. This is what is important to remember; that Qt and its ecosystem will likely just work on Tizen. But, and this is a big but, will Nokia try and kill Qt now that it is under Microsoft's boot? The strategic reasoning behind HTML5 is understandable: it is a general trend. The WAC part makes sense if you have a customer requiring it. Looking forward to the announcement of a native SDK and the reasoning behind it. And of course looking forward to see the work of the new Tizen stakeholders working on the Qt integration. The Qt Project will provide tools for them to make Tizen a first class Qt platform if they wish. If we look at LiMo we can see it supports Qt and GTK+. I think that Tizen will likely do so as well, if not, it will be trivially to port and I'm sure Quim is right about tools being available for the work, as well as developers and documentation. A toolkit is always needed, even if its just to build browser windows. :-) Regards, Jeremiah ___ 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] Who will keep pushing MeeGo?
On Monday, 3 de October de 2011 12:08:44 Jeremiah Foster wrote: This is what is important to remember; that Qt and its ecosystem will likely just work on Tizen. But, and this is a big but, will Nokia try and kill Qt now that it is under Microsoft's boot? Not if I have anything to say about it. Nor the hundreds of experienced engineers inside Nokia and outside that have been developing it for years. You simply can't stop an Open Source project if people are willing to continue it. If we look at LiMo we can see it supports Qt and GTK+. I think that Tizen will likely do so as well, if not, it will be trivially to port and I'm sure Quim is right about tools being available for the work, as well as developers and documentation. A toolkit is always needed, even if its just to build browser windows. :-) Without a shipped system library, the cost of using a library as large as Qt is very high. That's exactly the problem that the Qt on Android developers are facing right now, and also the same that the early Qt for Symbian had: a one- time download of 10 to 20 MB. And that's hoping for a decent package management system, not what Symbian had. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center 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] MeeGo Reconstructed - a plan of action and direction for MeeGo
Hi, +1 Nicola Da: meego-dev-boun...@meego.com A: meego-dev meego-dev@meego.com, meego-comm...@meego.com Cc: Data: Mon, 3 Oct 2011 08:01:17 +0200 Oggetto: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo Hi all, MeeGo is dead ... long live Tizen !! - Haven't we heard that before? - Maemo, Moblin? We need a community that transcends the mere branding of MeeGo, Maemo, Moblin - and now Tizen. A lot of proposals have been put forward: * Move to Tizen and trust that They'll get it right this time * Merge or join some existing projects (like the Qt Project, Debian, openSUSE, etc) * Keep MeeGo alive by approaching the Linux Foundation The goal is to find a truly sustainable way for MeeGo and other interested communities to work with Tizen. Our solution is the Mer Project: How does the concept of a truly open and inclusive integration community for devices sound? After all if upstream is king - then contributions will end up the same place, no matter if it's Tizen, Maemo, MeeGo or openSUSE. Some history - many of us in MeeGo originated from a project called Mer, short for Maemo Reconstructed - where we approached doing a open mobile platform through reconstruction of the Maemo platform into a open platform. We were big on open governance, open development and open source. For a few months a group of us have been working on various scenarios of change in MeeGo [1] and now that the Tizen news is out in the open, it's time to talk about what we as a community can make happen next. To make it clear: this is not in any way an anti-Tizen or anti-Intel project, but a direction we can and will go in - we strongly want to collaborate with Tizen and Intel. We will continue to welcome contribution and participation from the hacker community - in fact we aim to make it so easy to port to a new vendor device that a single hacker could do it for their device. We decided to approach the problems and potential scenarios of change in MeeGo in the light of the reallocation of resources caused by what is now known as the Tizen work. There have not been any Trunk/1.3 releases since August and Tablet UX has totally stalled. What really works (and works quite well) is the Core. It's time to take the pieces and use them for reconstruction. We have some clear goals: * To be openly developed and openly governed as a meritocracy * That primary customers of the platform are device vendors - not end-users. * To provide a device manufacturer oriented structure, processes and tools: make life easy for them * To have a device oriented architecture * To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5) * To innovate in the mobile OS space Now we'd like to talk a bit about what specific initiatives we propose to take: 0) Becoming MeeGo 2.0 Our work has the intended goal of being MeeGo 2.0 - and we hope that the Linux Foundation will see our work as a worthy succesor within the MeeGo spirit. We'd like to provide ability to be Tizen compliant, i.e. supporting HTML5/WAC and the application story there and feed back to that ecosystem. 1) Modularity. A set of architectural components for making devices. Rather than dictate the architecture we will support collaboration and the flexibility to easily access off-the-shelf components for device projects. Component independence permits focused feature and delivery management too. Initially the project will be developing a Core for basing products on and will split UX and hardware adaptations out into seperate projects within the community surrounding the Core. 2) Working towards an ultra-portable Linux + HTML5/QML/JS Core for building products with. We have already taken MeeGo and cut it into a set of 302 source packages that can boot into a Qt UI along with standard MeeGo stack pieces. This work can be seen already at [2] and we've made our first release and have had it booting on devices already[6]. To ease maintenance, we would like to encourage people to participate in the Core work of the Tizen project, utilizing their work where we can in Mer: why do the same work twice? Even if Tizen turns out to be dramatically different, the maintenance load of 302 source packages - much of it typical Linux software, is significantly lower than that of the 1400 packages found in MeeGo today. Using another lesson learned from MeeGo, we also want to port this work to everywhere, ARMv6/7 - hardfp, softfp, i486, Atom, MIPS, etc - allowing much more freedom for porting to new devices. 3) Change governance towards a more technically oriented one, similar to the Yocto Project We'd like to propose a revamp of governance based upon the Yocto Project governance - which is much more geared towards open technical work - encouraging collaboration and discussion. You can look at a description of this at [3]. 4) Work towards better vendor
Re: [MeeGo-dev] Who will keep pushing MeeGo?
On Oct 3, 2011, at 1:08 PM, ext Jeremiah Foster wrote: This is what is important to remember; that Qt and its ecosystem will likely just work on Tizen. But, and this is a big but, will Nokia try and kill Qt now that it is under Microsoft's boot? Nokia has clearly announced that Qt plays key role in next billion project and Nokia continues active Qt development. Nokia has two separate units, Smart devices that makes N9 and what is moving to MS stuff and then Mobile phones that currently makes S40 phones and will do this next billion project. Next billion project will make Qt handsets as mass products to mass markets. Just some numbers, devices called as smart phones were sold 300M in 2010 but all handset market were 1.3 Billion. This 1 billion is not market that Nokia can just ignore. Qt itself is FOSS, Nokia can't kill it and it does not have reason to do it. From application developers point of view, Qt will be there event what ever happens and what ever will be platform running it called, Maemo, MeeGo, Symbian, Android, Next billion or Tizen. Kate ___ 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] Who will keep pushing MeeGo?
On Mon, Oct 3, 2011 at 1:41 PM, kate.alh...@nokia.com wrote: On Oct 3, 2011, at 1:08 PM, ext Jeremiah Foster wrote: This is what is important to remember; that Qt and its ecosystem will likely just work on Tizen. But, and this is a big but, will Nokia try and kill Qt now that it is under Microsoft's boot? Nokia has clearly announced that Qt plays key role in next billion project and Nokia continues active Qt development. Nokia has two separate units, Smart devices that makes N9 and what is moving to MS stuff and then Mobile phones that currently makes S40 phones and will do this next billion project. Next billion project will make Qt handsets as mass products to mass markets. Hmm, that is quite a different story from what I hear from Nokia's marketing material. Somewhere there is a disconnect, either Nokia _is_ porting Qt to WP*, Nokia will continue with Linux for the next billion, or Nokia will use Symbian. Nokia publicly keeps saying the direct opposite of all these options. I realize you don't speak for Nokia's business plans per se but you can understand that developers will be skeptical about certain technologies if they aren't commercially viable. Free Software developers have to eat too. Just some numbers, devices called as smart phones were sold 300M in 2010 but all handset market were 1.3 Billion. This 1 billion is not market that Nokia can just ignore. Then why abandon what is likely the best smartphone platform out there right now? I.e. N9? Regards, Jeremiah ___ 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-community] invitation... and a second one
(cc:ing to meego-dev as well since Jos originally wanted to post there, too) to, 2011-09-29 kello 21:40 +0200, Jos Poortvliet kirjoitti: Dear MeeGo friends! Many people in your community wonder where to go since the Tizen announcement. At a MeeGo meet in Tampere, many expressed concerns: can we contribute to Tizen? How long will it last *this time*? How will Samsung behave? I know many of you are concerned about loosing the great community you've build. Thanks Jos for the invitation! I have now written another invitation from Debian perspective and an overview of the situation from my point of view at: http://losca.blogspot.com/2011/10/from-meego-to-tizen-debian.html In brief: do not fall in agony, there is a wide range of communities out there. Just answer the Aaron Seigo's question about thinking about evaluating own motives in contributing to for example MeeGo. Then choose the communities (plural) you want to work in! Obviously it could be the future Tizen community as well. But it could be openSUSE, Debian, Qt project, KDE project, Mer, or any number of other possibilities. All of them have some similarities with what MeeGo was. -Timo ___ 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] Who will keep pushing MeeGo?
On Oct 3, 2011, at 2:57 PM, ext Jeremiah Foster wrote: On Mon, Oct 3, 2011 at 1:41 PM, kate.alh...@nokia.commailto:kate.alh...@nokia.com wrote: On Oct 3, 2011, at 1:08 PM, ext Jeremiah Foster wrote: This is what is important to remember; that Qt and its ecosystem will likely just work on Tizen. But, and this is a big but, will Nokia try and kill Qt now that it is under Microsoft's boot? Nokia has clearly announced that Qt plays key role in next billion project and Nokia continues active Qt development. Nokia has two separate units, Smart devices that makes N9 and what is moving to MS stuff and then Mobile phones that currently makes S40 phones and will do this next billion project. Next billion project will make Qt handsets as mass products to mass markets. Hmm, that is quite a different story from what I hear from Nokia's marketing material. Somewhere there is a disconnect, either Nokia _is_ porting Qt to WP*, Nokia will continue with Linux for the next billion, or Nokia will use Symbian. Nokia publicly keeps saying the direct opposite of all these options. About Next billion, only that is said is that it uses Qt. I can't say anything more about it and I don't know what is opposite for this ? Symbian and WP are Smart devices unit products and they are moving to WP I realize you don't speak for Nokia's business plans per se but you can understand that developers will be skeptical about certain technologies if they aren't commercially viable. Free Software developers have to eat too. I can only refer what Nokia has announced publicly, i can't add anything. I work with developer community unit and i can say that Qt HAS a future. I understand clearly that FOSS developers have to eat too. I can say that Qt is commercially viable technology. Today you can make money with mobile Qt apps for Nokia N9 and Symbian, in future there will be Next billion project for even larger markets. Qt is open, it lives it's own live, you can make mobile Qt apps also for Android. I personally put some of my MeeGo Harmattan Qt Quick components applications running on my Archos 10.1 Android tablet. Kate ___ 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] Who will keep pushing MeeGo?
The only commercially viable mobile platform currently is iOs, and even that is a stretch, if you look at the amount of companies actually making a living on app revenue. On 10/3/11 2:57 PM Jeremiah Foster wrote: On Mon, Oct 3, 2011 at 1:41 PM, kate.alh...@nokia.com wrote: On Oct 3, 2011, at 1:08 PM, ext Jeremiah Foster wrote: This is what is important to remember; that Qt and its ecosystem will likely just work on Tizen. But, and this is a big but, will Nokia try and kill Qt now that it is under Microsoft's boot? Nokia has clearly announced that Qt plays key role in next billion project and Nokia continues active Qt development. Nokia has two separate units, Smart devices that makes N9 and what is moving to MS stuff and then Mobile phones that currently makes S40 phones and will do this next billion project. Next billion project will make Qt handsets as mass products to mass markets. Hmm, that is quite a different story from what I hear from Nokia's marketing material. Somewhere there is a disconnect, either Nokia _is_ porting Qt to WP*, Nokia will continue with Linux for the next billion, or Nokia will use Symbian. Nokia publicly keeps saying the direct opposite of all these options. I realize you don't speak for Nokia's business plans per se but you can understand that developers will be skeptical about certain technologies if they aren't commercially viable. Free Software developers have to eat too. Just some numbers, devices called as smart phones were sold 300M in 2010 but all handset market were 1.3 Billion. This 1 billion is not market that Nokia can just ignore. Then why abandon what is likely the best smartphone platform out there right now? I.e. N9? Regards, Jeremiah ___ 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] Who will keep pushing MeeGo?
On Monday, 3 de October de 2011 13:57:58 Jeremiah Foster wrote: Hmm, that is quite a different story from what I hear from Nokia's marketing material. Somewhere there is a disconnect, either Nokia _is_ porting Qt to WP*, Nokia will continue with Linux for the next billion, or Nokia will use Symbian. Nokia publicly keeps saying the direct opposite of all these options. I can tell you which ports are active for Qt 5. These are the reference platforms: - Linux with X11 - Linux with Wayland - Windows - Mac (Cocoa) There are some other active platforms which are not the reference ones (Android, X11 on other Unix, DirectFB and LinuxFB on Linux, etc.). There are also some people working on iOS port, but it's much behind. And finally, the Symbian port is dead. It's not a target at all for Qt 5. All of the above is public information that anyone can find. There is nothing about a WP port. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center 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] Who will keep pushing MeeGo?
On Mon, Oct 3, 2011 at 3:53 PM, Thiago Macieira thi...@kde.org wrote: And finally, the Symbian port is dead. It's not a target at all for Qt 5. ... until someone decides to do the port, that is. ___ 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] Who will keep pushing MeeGo?
On Monday, 3 de October de 2011 16:03:05 Ville M. Vainio wrote: On Mon, Oct 3, 2011 at 3:53 PM, Thiago Macieira thi...@kde.org wrote: And finally, the Symbian port is dead. It's not a target at all for Qt 5. ... until someone decides to do the port, that is. Right, someone could do that. But that port might not be accepted into the mainline anymore, just like a port to DOS or to use the Borland C++ compiler might not be. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center 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
[MeeGo-dev] Community infra resources funds (was RE: MeeGo...)
Discussing resources funds is not as much fun as discussing brands or toolkits, but let me bring your attention to this point since it is probably important or plain critical for any plans forward discussed here. My assumption is that the current community doesn't have enough muscle to afford the whole cost of infrastructure of a project with the size and complexity of MeeGo. The options are either reuse free-as-in-beer infra from other projects or assure corporate sponsorship from different sources (I would trust less this one, but it is also a possibility). Imad Sousou wrote: I will be working even harder to make sure that developers of MeeGo can also transition to Tizen. 1. Can we get any details about the availability of the current meego.com infrastructure under Intel's funding? End of this year? July 2012? End of 2012? Later? The answer to this question helps figuring out the urgency for a move. 2. What is the scope we can expect for tizen.org in terms of community infrastructure? Will a fortizen.org like site be needed as well or the core tizen.org (plus AppUp?) will be inclusive enough to satisfy community initiative with a link to the Tizen project, even if it's indirect? The answer to this question helps figuring out the need to find/fund own infra for all the non-official development infra. Thank you. -- Quim ___ 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-community] MeeGo as a vehicle for Qt-based products?
On Oct 1, 2011, at 11:28 AM, Kok, Auke-jan H wrote: Snip I've been asking the same questions as everyone else. If I get answers back that I can share, I most certainly will. For now, I'd like to ask everyone to submit questions to Dawn Foster, and keep asking. Answers will come - be patient. Please no :) I really do read all of the mailing list posts here, so continue to use this is as the place for questions and discussion. Sending it to me individually makes it less likely that you will get an answer, not more likely. Right now, there are still many unanswered questions because we just don't have answers to many of the technical questions yet. People are very focused on getting the code out into the repos so that we can start having productive discussions about the project based on the code. Right now, we'd be guessing along with everyone else on many of the questions. 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 Reconstructed - a plan of action and direction for MeeGo
I'm for that! Wasn't the Mer project part of the Maemo 5.0 porting to the Nokia N8X0 platform? On 03/10/2011 07:01, Carsten Munk wrote: Hi all, MeeGo is dead ... long live Tizen !! - Haven't we heard that before? - Maemo, Moblin? We need a community that transcends the mere branding of MeeGo, Maemo, Moblin - and now Tizen. A lot of proposals have been put forward: * Move to Tizen and trust that They'll get it right this time * Merge or join some existing projects (like the Qt Project, Debian, openSUSE, etc) * Keep MeeGo alive by approaching the Linux Foundation The goal is to find a truly sustainable way for MeeGo and other interested communities to work with Tizen. Our solution is the Mer Project: How does the concept of a truly open and inclusive integration community for devices sound? After all if upstream is king - then contributions will end up the same place, no matter if it's Tizen, Maemo, MeeGo or openSUSE. Some history - many of us in MeeGo originated from a project called Mer, short for Maemo Reconstructed - where we approached doing a open mobile platform through reconstruction of the Maemo platform into a open platform. We were big on open governance, open development and open source. For a few months a group of us have been working on various scenarios of change in MeeGo [1] and now that the Tizen news is out in the open, it's time to talk about what we as a community can make happen next. To make it clear: this is not in any way an anti-Tizen or anti-Intel project, but a direction we can and will go in - we strongly want to collaborate with Tizen and Intel. We will continue to welcome contribution and participation from the hacker community - in fact we aim to make it so easy to port to a new vendor device that a single hacker could do it for their device. We decided to approach the problems and potential scenarios of change in MeeGo in the light of the reallocation of resources caused by what is now known as the Tizen work. There have not been any Trunk/1.3 releases since August and Tablet UX has totally stalled. What really works (and works quite well) is the Core. It's time to take the pieces and use them for reconstruction. We have some clear goals: * To be openly developed and openly governed as a meritocracy * That primary customers of the platform are device vendors - not end-users. * To provide a device manufacturer oriented structure, processes and tools: make life easy for them * To have a device oriented architecture * To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5) * To innovate in the mobile OS space Now we'd like to talk a bit about what specific initiatives we propose to take: 0) Becoming MeeGo 2.0 Our work has the intended goal of being MeeGo 2.0 - and we hope that the Linux Foundation will see our work as a worthy succesor within the MeeGo spirit. We'd like to provide ability to be Tizen compliant, i.e. supporting HTML5/WAC and the application story there and feed back to that ecosystem. 1) Modularity. A set of architectural components for making devices. Rather than dictate the architecture we will support collaboration and the flexibility to easily access off-the-shelf components for device projects. Component independence permits focused feature and delivery management too. Initially the project will be developing a Core for basing products on and will split UX and hardware adaptations out into seperate projects within the community surrounding the Core. 2) Working towards an ultra-portable Linux + HTML5/QML/JS Core for building products with. We have already taken MeeGo and cut it into a set of 302 source packages that can boot into a Qt UI along with standard MeeGo stack pieces. This work can be seen already at [2] and we've made our first release and have had it booting on devices already[6]. To ease maintenance, we would like to encourage people to participate in the Core work of the Tizen project, utilizing their work where we can in Mer: why do the same work twice? Even if Tizen turns out to be dramatically different, the maintenance load of 302 source packages - much of it typical Linux software, is significantly lower than that of the 1400 packages found in MeeGo today. Using another lesson learned from MeeGo, we also want to port this work to everywhere, ARMv6/7 - hardfp, softfp, i486, Atom, MIPS, etc - allowing much more freedom for porting to new devices. 3) Change governance towards a more technically oriented one, similar to the Yocto Project We'd like to propose a revamp of governance based upon the Yocto Project governance - which is much more geared towards open technical work - encouraging collaboration and discussion. You can look at a description of this at [3]. 4) Work towards better vendor relations and software to support these as well as easier contribution methods. As part of our customer oriented goal we're improving delivery methods from Mer. We are designing simpler and more resilient update
Re: [MeeGo-dev] Regarding Qt with HTML5 layer from MeeGo Smart TV WG Meeting Minutes for 9/20/2011
Neils, Here is the whitepaper: http://qt.nokia.com/files/pdf/whitepaper-qt-hybrid-server-driven-ui/at_download/file The critical, and missing, context here is that Qt WebKit hybrid is a way to build native apps, not apps that run in a browser. Another way to think about it: Qt WebKit hybrid lets you build an app-specific web browser that is designed to run that particular app. And another relevant datapoint: the Qt WebKit hybrid design pattern has been used by several companies for building connected TV apps for streaming premium content. e.g. Netflix in North America, and CNTV in China, to name a couple. Hope that answers yours concerns, and thanks for the links to your projects. Best, Dilip On Oct 2, 2011, at 3:50 PM, ext Niels Mayer wrote: In MeeGo Smart TV WG Meeting Minutes for 9/20/2011 I noticed: o Dilip Kenchammana: Qt with HTML5 layer Dilip has provided a white paper via e-mail. Discussion postponed to next meeting. Is it possible to get a copy of this whitepaper? I have serious concerns all-around over the approach being taken, and am curious how a number of issues are being resolved. Especially w/r/t/ security, and also because silly breakage needs to be done to very hairy browser code in order to poke holes for video acceleration and/or DRM-protection. And once that breakage has been perpetrated, a tidal-wave of bugreports will ensue because the HTML5 standard permits canvas like operations on top of the video; also dynamically altering the video frame. An extreme example: http://www.craftymind.com/factory/html5video/CanvasVideo.html Especially troubling for the Tizen approach, are statements like: http://lists.meego.com/pipermail/meego-tv/2011-September/000103.html Q: Narm, is there privacy controls to prevent rogue JavaScript from accessing private data. A: Doninique, not that he's seen. Designed for closed system. Access to scripts and code inside the box is limited by physical security. . FYI, my own qt and html5 project: http://code.google.com/p/qtzibit/ http://nielsmayer.com/meego/qml/qtzibit.xhtml qtzibit: tiny programs make amazing web mashups using Simile-Widgets Exhibit, QtWebKit and QML ( http://nielsmayer.com/meego/qml/qtzibit_0_1_0.i586.rpm http://nielsmayer.com/meego/qml/qtzibit_0.1.0_armel.deb ) Also, MeeGo/Qt and TV related: http://nielsmayer.com/meego/qml/qmltube.xhtml (qmltube: Port/fork of cutetube-qml for Linux, MeeGo Netbook, Tablet and Harmattan.) ( http://nielsmayer.com/meego/qml/qmltube_1_11_2.i586.rpm http://nielsmayer.com/meego/qml/qmltube_1.11.1_armel.deb ) PS: Coming soon to a Nokia N9 (validation-willing) near you, my new app 'voicetogoog': http://nielsmayer.com/voicetogoog/voicetogoog-map-view.png http://nielsmayer.com/voicetogoog/voicetogoog-details-view.png http://nielsmayer.com/voicetogoog/voicetogoog-menu-view.png http://nielsmayer.com/voicetogoog/voicetogoog-recording-voice.png 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
[MeeGo-dev] will Mer support application developers?
Carsten, you wrote: ... [snip] ... to find a truly sustainable way for MeeGo and other interested communities to work with Tizen. Our solution is the Mer Project: ...[snip]... On Mer's website http://merproject.org/ I found that one of its goals is: That the primary customers of the platform are device vendors - not end-users. What do you see as Mer's goals relative to application developers who may be looking, for instance, for access to a device's sensors? Are application developers considered end-users? Vim ___ 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] will Mer support application developers?
Hi, Yesterday we had already MeeGo Community Edition running on top of Mer, maybe CE is the answer you are looking for? -- Iekku From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of ext Vim Toutenhoofd Sent: 04 October, 2011 05:18 To: meego-dev@meego.com Subject: [MeeGo-dev] will Mer support application developers? Carsten, you wrote: ... [snip] ... to find a truly sustainable way for MeeGo and other interested communities to work with Tizen. Our solution is the Mer Project: ...[snip]... On Mer's websitehttp://merproject.org/ I found that one of its goals is: That the primary customers of the platform are device vendors - not end-users. What do you see as Mer's goals relative to application developers who may be looking, for instance, for access to a device's sensors? Are application developers considered end-users? Vim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
