Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
I just think it would have been better if we (The Nokia linux organization and the fans) did not have to go through the MeeGo hurdle, and as you say in detail, look at harmattan and how slick and beautiful is as a product. (I use it in N950 as my everyday phone and no *other* OS/ device even comes close to the experience I get. However, I understand from Carsten that all of our code is already in RPM and hence this is why Mer is going to use it, I am wondering what would it take to just use Harmattan as the basis for Mer now and keep the tradition and the rocking dev tools (Scratchbox is indeed, a cross compilation environment OOTB that as an embedded OS maker, I've yet come to see in its simplicity and support to the developer from any other platform / distro and/or vendor). If you ask me, Harmattan is the way to go , asking to yet open closed parts or replace them with open parts , put a UX on top following the Swipe style if we have a UX team (because Mer is supposed to be a thin base layer nothing more). And just do it. Then Nokia (In my deepest hopes) could re-use it when perhaps Linux will find its way back there as a smartphone platform. On Tue, Oct 4, 2011 at 10:53 AM, karoliina.t.salmi...@gmail.com karoliina.t.salmi...@gmail.com wrote: would be better or equal. Before scratchbox we were compiling with ext hard drive connected to Nokia 770 proto (and ran the gcc on the arm). After scratchbox came, there was a great convenience improvement. Killing scratchbox without a replacement (OBS is not a replacement!) is not very good choice. +1 . on your machine, not needing some OBS build service to build your package when you can compile on your computer. So forget RPM, is number 1 key to the success. And even if the intended hardware would be something else than ARM, it does not matter. This is my recommendation. Do whatever you want, but I think this would be the right thing to do at this point. +1 - Number 2 key to the success is a blazingly superb UI. And this is not even very hard one but takes some work. Community MeeGo has not had a meaningful UI, has always had poor graphics (or missing graphics on Nokia's code drops, are different from app to app because the apps are color coded - this kind of attention does matter). But QML is really awesome for creating things fast and the QML based swipe tutorial on Harmattan (when you boot your N9 first time) shows that it can be done with QML (as the swipe tutorial simulates the Harmattan UI framework). I think QML is a key to developing any UI concept fast whatever the Mer wants to be. ++1 - Number 3: Thou shalt not restrict it to one single technology. I think restricting to HTML5 only or QML only would be a bad idea. Instead a support of choices which work for different purposes is a key to success. Things which do not need to be replaced should not be replaced, they can be substituted, but not replaced. +++1 . Problem is that how do you make all of the technologies appear integrative to the platform, as Rich Green once noted about apps and WP7 that an app there does not feel different to the core OS UX. I could argue that we should support GTK , Vala, Mono stuff and the list goes on...but how to make it look organic? - Many of the lower layers have been already open sourced by companies and it is just about utilizing them and doing the top of the cake right. There are some missing pieces, but filling the gaps should not be impossible. It is some work to do, but it may not be overwhelmingly big work. I have no idea about this - can anybody really estimate the amount of work needed? -Sivan ___ 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
On Tue, Oct 4, 2011 at 11:14 AM, Robin Burchell robin+me...@viroteck.net wrote: OBS is a very useful tool, just not for the purposes you were apparently forced to use it for. I've used it for the commit, push package, wait for build failure type development cycle as well, and I agree, it's far from optimal - but for easily making heavily customised distributions, OBS is great. Robin, why is OBS different and better than the original buildd's we used for Maemo and/or nowdays open sourced Launchpad ? I was one of those who felt the whole lot of changes we've been going through to adopt to Moblin were time consuming and just presented yet another hurdle to the community that was already experienced in Debian packaging and the debian build servers. I think, if we're reconstructing we should perhaps re think the decisions that were laid upon us by the corporate governance before we repeat them. Important note: this is not trolling, I'm sincerely trying to understand where and how we are going to from now on. -Sivan ___ 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
On Tue, Oct 4, 2011 at 11:20 AM, Robin Burchell robin+me...@viroteck.net wrote: it can be looked at. We've chosen the approach of minimal change because it means we have a working system with less effort. I realize this, does this mean that once we find someone to sponsor the servers we just deploy OBS on it and we are done? (trying ot understand where this saves effort) Again - I hope that's okay I'm asking all of this, and this does not look like being ungrateful for the proposal :-) (With how MeeGo mailing lists looked the last couple of months, one be better sure than sorry ;)) -Sivan ___ 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
On Tue, Oct 4, 2011 at 11:28 AM, Carsten Munk cars...@maemo.org wrote: Long story short: buildd and launchpad is very useful but only when you're doing Debian and Debian only. OBS is different in many different ways and allows a proper productization environment as well as growing an organisation organically. I see, thanks for enlightening me. We should then look to add the missing features like Feature Planning (blueprint) and others from Launchpad, although we could just use the wiki for everything not build / commit stuff. The choice has been made to go for OBS and RPM in Mer - we'll be in a even longer cycle if we were to revert to Debian based things and it's not obvious there'll be any benefit - I personally got bitten badly by basing on Debian/Ubuntu in the first iteration of Mer. We're here now and we have something that works and expertise in these areas. That's the direction we're going in. (I swear, if we are going to have the RPM vs DEB talk, I'll propose we switch to rot13 encrypted zip files and actually go ahead with it!) I've stopped it, I hope Qt Creator will learn to create RPM packages by when Mer is reading for playing with :-D -Sivan ___ 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
On Tue, Oct 4, 2011 at 1:58 PM, Jeremiah Foster jeremiah.fos...@pelagicore.com wrote: On Tue, Oct 4, 2011 at 11:35 AM, Sivan Greenberg si...@omniqueue.com wrote: On Tue, Oct 4, 2011 at 11:28 AM, Carsten Munk cars...@maemo.org wrote: Long story short: buildd and launchpad is very useful but only when you're doing Debian and Debian only. Except it was built by Canonical for Ubuntu and is used by Linaro. But perhaps those two things are Debian too? OBS is different in many different ways and allows a proper productization environment as well as growing an organisation organically. What does that even mean? I would also like to understand that, perhaps through the use of that layer on top of OBS which I had forgotten its name? Is there somewhere documentation to read about this? I see, thanks for enlightening me. You're not enlightened, you've just gotten a perspective from one developer on why they like what they like. To be frank, I just did not want to make Carsten angry and go with rot13 encrypted zip files so we actually have to use it ;-) We should then look to add the missing features like Feature Planning (blueprint) and others from Launchpad, although we could just use the wiki for everything not build / commit stuff. NB - Not all of Launchpad is open source. I stand corrected. The choice has been made to go for OBS and RPM in Mer - we'll be in a even longer cycle if we were to revert to Debian based things and it's not obvious there'll be any benefit - I personally got bitten badly by basing on Debian/Ubuntu in the first iteration of Mer. We're here now and we have something that works and expertise in these areas. That's the direction we're going in. (I swear, if we are going to have the RPM vs DEB talk, I'll propose we switch to rot13 encrypted zip files and actually go ahead with it!) Ignorance is bliss. Well, deb lovers could always try and have their own deb'd meego as Robin noted. But if Qt Creator does take care of all the packaging for RPM and the upload to OBS, then I should not care about the underlying packaging system. -Sivan ___ 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
On Tue, Oct 4, 2011 at 2:19 PM, Jeremiah Foster jeremiah.fos...@pelagicore.com wrote: I think what Carsten means by growing an organisation organically is that OBS allows multiple users to create their own repositories, it allows us to separate different projects into different repositories for staging or logical separation and it's easy and intuitive to do all of this from the web interface and to tools provided. This is likely what he's referring to. But as someone who is concerned with integration, this is bordering on a misfeature. What is happening is that each repository is a separate Linux distro. This makes integration a complete nightmare and unlikely to occur. Look a the ABI break that occurred in MeeGo for ARM. That effectively killed any release of that distro. Just because you can build your own Linux distro doesn't mean you should. Also, does not Launchpad support PPA at this point, as well as on the fly test builds out of version control? I know Linaro people are using it and are quite happy about it or perhaps I'm misinformed ? It might be ahead of time to be concerned by this, but the concern Quim Gill expressed about the ability of the community to fund the infrastructure might be realized if Mer is to be adopted on a large scale... My personal experience with Launchpad is that the sysadmin personnel is *VERY* responsive and cater for rapid and fruitful distro work. Again, those concerns are only for when Mer is in massive adoption which is where we want to reach anyway? How do we pitch prospective sponsors when they ask us about Harmattan and speak about Debian in the mobile field, I think it has some success compared to others. Linaro seems to be doing well and they so far manage to gather vendors interested. Again, no trolling, just asking questions :) -Sivan ___ 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 Sat, Oct 1, 2011 at 2:28 PM, Gabriel Beddingfield gabrb...@gmail.com wrote:
On 09/29/2011 10:20 AM, Nasa wrote:
1) Concentrate on the handset and *ONLY* on it from now onward. Do
one thing and do it best (tm).
Why would you exclude 4/5 of the people involved in the meego project?
Handsets weren't even the largest part of the project...
Fine... pick IVI. Pick *something*.
MeeGo's complexity ({Netbook,Handset,IVI,Tablet} x {i586,armv7} x
{MeeGoCompliance,PlatformCompliance,DeviceCompliance}) was apparently too
much to bear even with corporate sponsorship. If you continue as a
community project, it's important to narrow this down in order to succeed.
++1 That is why I said so the first place. Trying to do everything and
in the same time proved us very wrong.
-Sivan
___
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 Thu, Sep 29, 2011 at 5:03 PM, Robin Burchell robin+me...@viroteck.net wrote: Obviously, we'd probably need to rethink some things like project governance, infrastructure, etc - but provided these can be solved, what do you all think? Can it be business as usual? I believe so. In fact I think this could actually enable us to create a true open base truly governed by community perhaps similar to the Qt Open Governance project. I think we should align with Qt releases as much as we can as our *core* app dev technology. Through concentrating on rocking Qt support, we earn a lot of great technologies (including HTML5 if I read right the Qt5 direction) not to mention great SDK and documentation to engage and attract veteran and new developers. (I get people asking me all the time how to use Qt on Android, as the native tools for them more often then not do not provide the experience they know or heard of about Qt) So I'll shed some light on how I see this and how we should proceed: 1) Concentrate on the handset and *ONLY* on it from now onward. Do one thing and do it best (tm). 2) Invite contacts from any handset mfct. interested to tell us their requirements and what would make it attractive for them to use as a base and try to respond to these. Nokia seems the first natural company I would like to talk to. (Admittedly as a passionate Nokia fan, I would love to try and do something that would help Nokia to produce the next Linux phone if they ever want to do this again. People who are fans of other vendors could do the same) 3) Vendor involvement is only through having contacts but they do not steer the project, unless getting into steering based by merit and proving skills. Community steers it. They can make suggestion and help in implementation but through the normal community channels, as a community contributor. No precedence or short-lanes to vendors and participation rights are based *only* on merit. Related to (2) I talked with Qualcomm people back then before SF2011 (we were supposed to meet in SF) about MeeGo but there was some concerns back then due to the heavy vendor steering, perhaps now we could invite them aboard, presenting a pure community project. These are some steps I think we could take, I would propose to see how we can align as best with Qt Open Gov now and follow their governance structure. -Sivan ___ 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 Thu, Sep 29, 2011 at 6:37 PM, Robin Burchell robin+me...@viroteck.net wrote: Hi, On Thu, Sep 29, 2011 at 5:20 PM, Nasa nas...@comcast.net wrote: So I'll shed some light on how I see this and how we should proceed: 1) Concentrate on the handset and *ONLY* on it from now onward. Do one thing and do it best (tm). Why would you exclude 4/5 of the people involved in the meego project? Handsets weren't even the largest part of the project... Personal area of interest, perhaps. Anyway, we don't need to exclude anyone here - anyone can come and play ball. In my view of the ideal MeeGo universe, UX is entirely seperate projects from MeeGo itself - MeeGo Core is just the basics needed to boot and get to a display, hardware adaptations and user interfaces are outside of scope there. Personal area of interest, nobody should be excluded but I think we should consider managing the verticals team in a way that would enable each of them to progress without being delayed for parts they don't really need to use on the core, so for instance, tablet should not be delayed for GSM modem code and vice versa for handset if they do not need it for operation. -- -Sivan ___ 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] WebOS and MeeGo: Opportunities or indifference?
Although this is rather an interesting discussion, I think this should be continued over meego-community as this is not a development question but more related to developer outreach ? -Sivan On Sat, Aug 20, 2011 at 6:27 AM, Si Howard howa...@gmx.co.uk wrote: That would be helpful to both parties as Ari Jakassi was head of Nokia Maemo then left for WebOS at HP. Bring him back to Nokia for Maemo/MeeGo? Plus it would bring more developers into the MeeGo ecosystem which would help the cause as well. On 20/08/2011 00:42, Fernando Cassia wrote: 1. Do the companies behind MeeGo -or the MeeGo community- plan to extend an olive branch, so to speak, to the WebOS developers' community?. In other words, there might be plenty of third party WebOS developers who might be interested in learning about whatMeeGo has to offer and how they could reconvert their apps to the MeeGo platform. It would also help them know MeeGo is a truly open platform, that won't go under just because one company dumps it (Hello, Mr. Elop). 2. Any contact between MeeGo devs, pundits, and fans, with HP? 3 Intel might be interested in WebOS, no? couldn't WebOS become a HTML5 apps layer on top of MeeGo? Just thinking aloud and shooting in the dark here, trying to imagine ways to turn bad news about WebOS into good news (or opportunities for growth) for MeeGo... FC ___ 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 -- -Sivan ___ 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 to post bug reports for MeeGo 1.2 Harmattan?
In Nokia developer, there's a special section for that. This also holds for S60 which is Nokia adaptation of Symbian.org together with their cut of UX. Mind you, I never got a response from the bugs I submitted as this is a non public issue tracking system. I would say we should try to speak to Nokia people to at least have some sort of public issue tracking so we'd be able to know if the issue is being taken care of, rejected, or ignored altogether. -Sivan On Wed, Jun 22, 2011 at 7:40 AM, Carsten Munk cars...@maemo.org wrote: Submit them to your vendor, ie, Nokia (you'd have to ask them for where, because I don't know). Then they will submit it further to any upstream projects they use. The reasoning forro this (even when ignoring the complete Harmattan mess) is these steps: 1) A vendor might have modifications to the upstream packages/software or own packages/software he uses. Then he should handle it 2) If no modifications/directly from upstream, submit to the upstream project - it's a bug in that software then. 3) Upstream may handle the issue and fix may trickle down to the consumer through the vendor's path of upgrades If you can replicate an error in MeeGo.com images/components directly, you're of course welcome to submit to those bugtrackers. Example could be a Qt or Qt Mobility issue that happens on MeeGo.com images too. /Carsten 2011/6/22 Andrey Ponomarenko aponomare...@ispras.ru: Hi, Could anybody explain me where to post bug reports for MeeGo 1.2 Harmattan [1]? To maemo.org Bugzilla [2] or to MeeGo Bugzilla [3]? Thanks! [1] MeeGo 1.2 Harmattan [2] maemo.org Bugzilla [3] MeeGo Bugzilla -- Andrey Ponomarenko Department for Operating Systems at ISPRAS web: http://www.LinuxTesting.org mail: aponomare...@ispras.ru ___ 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 ___ 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 to post bug reports for MeeGo 1.2 Harmattan?
Interesting. I did not know people already have the device and want to submit kernel or userland patches for the firmware ! :) -Sivan On Wed, Jun 22, 2011 at 10:07 AM, Andrew Flegg and...@bleb.org wrote: On Wed, Jun 22, 2011 at 05:29, Andrey Ponomarenko aponomare...@ispras.ru wrote: Could anybody explain me where to post bug reports for MeeGo 1.2 Harmattan [1]? To maemo.org Bugzilla [2] or to MeeGo Bugzilla [3]? Neither. See Quim's post: http://forum.meego.com/showpost.php?p=22953postcount=77 HTH, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-develop...@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ 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 app model in 2012: Rethinking the MeeGo app model to be more platform agnostic
So, we've actually discussed this sort of stuff during my Quality and the Compliance spec BOF[0], I also think that HTML5 and PySide would be the way to go about this, but we need to get PySide to be an official part of MeeGO core. Maybe we can start pitching this to the TSG? I think given it is supported in the intel app store and they sort'a did something similar to a one click rpm download install, we could perhaps build on the app up packaging model for the samepurpose on pub.meego? Also, we've discussed an interesting way to make this happen using sub-category compliances, When I get home I will put both the recording and all of the meeting minutes on the wiki so we can gather more feedback and continue the brainstorming. On Wed, Jun 1, 2011 at 6:40 AM, Akkana Peck akk...@shallowsky.com wrote: Wichmann, Mats D writes: switch to html5 :) I know you used a smiley, but: Is there a way to package an html+javascript app on meego so that it has a desktop icon and shows up in the apps menu without needing an architecture-specific C++ Qt wrapper? Also without requiring packages like qml-viewer or python-webkit, which may or may not be installed. ...Akkana ___ 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] MeeGo app model in 2012: Rethinking the MeeGo app model to be more platform agnostic
[0]: http://sf2011.meego.com/program/sessions/bof-quality-and-compliance-specification On Wed, Jun 1, 2011 at 7:03 AM, Sivan Greenberg si...@omniqueue.com wrote: So, we've actually discussed this sort of stuff during my Quality and the Compliance spec BOF[0], I also think that HTML5 and PySide would be the way to go about this, but we need to get PySide to be an official part of MeeGO core. Maybe we can start pitching this to the TSG? I think given it is supported in the intel app store and they sort'a did something similar to a one click rpm download install, we could perhaps build on the app up packaging model for the samepurpose on pub.meego? Also, we've discussed an interesting way to make this happen using sub-category compliances, When I get home I will put both the recording and all of the meeting minutes on the wiki so we can gather more feedback and continue the brainstorming. On Wed, Jun 1, 2011 at 6:40 AM, Akkana Peck akk...@shallowsky.com wrote: Wichmann, Mats D writes: switch to html5 :) I know you used a smiley, but: Is there a way to package an html+javascript app on meego so that it has a desktop icon and shows up in the apps menu without needing an architecture-specific C++ Qt wrapper? Also without requiring packages like qml-viewer or python-webkit, which may or may not be installed. ...Akkana ___ 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] PDF reader for tablets running MeeGo
Is this based on the QML book reading example that circulated here some 4 months ago? -Sivan 2011/5/13 Bogdan Cristea crist...@gmail.com: On Friday, May 13, 2011 12:25:57 PM you wrote: Here you can find ShowMee, our fullscreen PDF reader for MeeGo, which has a touch interface and is targeted mainly at presentations: https://build.pub.meego.com/package/show?package=showmeeproject=home%3Axto r https://build.pub.meego.com/package/show?package=es.warp.showmeeproject=h ome%3Axtor (packaged using Intel AppUp conventions) It uses QML and a pdf provider relying on Poppler. If you can wait one or two days, we plan to set up a public repo at GitHub. Hi Interesting application you have there. I was able to run your app on my desktop computer, but not yet on MeeGo tablet, but I'll give it a try ASAP. There is still room for improvements, but it is a starting point. regards -- Bogdan Cristea Software Engineer web: http://sites.google.com/site/cristeab/ ___ 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] [MeeGo-community] MeeGo Application Developer Engagement
Has anything progressed on this? -Sivan On Fri, Jun 18, 2010 at 7:42 PM, Robin Burchell virot...@viroteck.net wrote: *** [cross-posting since this is a big topic, please direct feedback to meego-community list to keep traffic in one place] *** I've a bit of a plan I'd like to outline, and call for comments on. (And volunteers, hopefully, otherwise I shall be rather busy!) This is mostly targetted at existing application developer-type people, especially those with Qt knowledge, although all are welcome to participate in some way or another. Some background: We have a lot of highly productive developers that are not sure how their skills will remain relevant in a MeeGo context. We can't afford to lose them through neglect. There are also even more developers not familiar with MeeGo. When they find us, we have to grab them and keep them. Basically, we can't afford to lose our developers, and we need to gain more. I need help. I've written tutorials and helped a lot of people in the past, but frankly, it is not enough. We need to do more. The hands of many lighten that load. What? = The success of a platform is usually directly linked to its support and nurturing of developer talent. Great platforms have often withered without developer attention, and bad platforms have survived technical flaws thanks to high developer engagement and retention. I think we need this around MeeGo, and our related platform - Qt. Specifically, we need to provide education, support (moral and technical), and a feedback cycle - for application developers. Or, in a word: Mentoring. - Helping new developers find their feet - Teaching developers new tricks - Exchanging knowledge throughout the community to ensure equal footing A simple summary would be that *no* application developer should feel alone, or be confused. ;) As an added benefit, rough edges and other nasties become more obvious, and can (hopefully) be addressed instead of falling to the wayside, and losing valuable developers as a consequence. How? Tutorials - Wiki based - Forum threads for feedback and questions Classes - On IRC - Covering tutorial material and topics which don't quite fit into a tutorial, e.g. how to write responsive UI - Possibly split out into a tutorial *after* each class, if the topic is self-contained enough Mentoring - A 'buddy' type system. Skilled developers offer to take on an eager trainee or two (or three or four) and 'show them the ropes'. It might be as simple as asking them how their project is going, and where they're getting stuck - from time to time - or as difficult as actually pitching in and helping them hack. Not really a role I want to define in terms beyond something like a 'big geeky brother'. :) Where do I sign up? I've set up a wiki page containing a copy of this material at: http://wiki.meego.com/DeveloperEngagement If you're interested in helping out as a mentor, or with classes or tutorials, please add yourself to the list. A sidenote: please let's not discuss the material now, because it's practically infinite :). I'm specifically after feedback on this proposal, and volunteers to step up to help get the ball rolling. Finally: I realise this sounds very Qt-centric, and well, it is - for two reasons. Firstly, that's my prime area of expertise, and secondly.. MeeGo is focusing on Qt as the toolset to use for application developers. If your skills aren't in the Qt arena, you can still be of help - providing other facets of developer knowledge (best practices, how to use version control, etc), or perhaps by being the guinea-pigs to run through early versions of tutorials. -- Robin Burchell http://rburchell.com ___ MeeGo-community mailing list meego-commun...@meego.com http://lists.meego.com/listinfo/meego-community ___ 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 Application Developer Engagement
So to be more specific, if I want to help the Tablet UX now to fix browsing gmail and Facebook and to perhaps use one of the ideapad's display buttons as the home button rather then the windows key, whom do I talk to, how do I start? Where can I get a mentor? -Sivan On Thu, May 12, 2011 at 2:42 PM, Sivan Greenberg si...@omniqueue.com wrote: Has anything progressed on this? -Sivan On Fri, Jun 18, 2010 at 7:42 PM, Robin Burchell virot...@viroteck.net wrote: *** [cross-posting since this is a big topic, please direct feedback to meego-community list to keep traffic in one place] *** I've a bit of a plan I'd like to outline, and call for comments on. (And volunteers, hopefully, otherwise I shall be rather busy!) This is mostly targetted at existing application developer-type people, especially those with Qt knowledge, although all are welcome to participate in some way or another. Some background: We have a lot of highly productive developers that are not sure how their skills will remain relevant in a MeeGo context. We can't afford to lose them through neglect. There are also even more developers not familiar with MeeGo. When they find us, we have to grab them and keep them. Basically, we can't afford to lose our developers, and we need to gain more. I need help. I've written tutorials and helped a lot of people in the past, but frankly, it is not enough. We need to do more. The hands of many lighten that load. What? = The success of a platform is usually directly linked to its support and nurturing of developer talent. Great platforms have often withered without developer attention, and bad platforms have survived technical flaws thanks to high developer engagement and retention. I think we need this around MeeGo, and our related platform - Qt. Specifically, we need to provide education, support (moral and technical), and a feedback cycle - for application developers. Or, in a word: Mentoring. - Helping new developers find their feet - Teaching developers new tricks - Exchanging knowledge throughout the community to ensure equal footing A simple summary would be that *no* application developer should feel alone, or be confused. ;) As an added benefit, rough edges and other nasties become more obvious, and can (hopefully) be addressed instead of falling to the wayside, and losing valuable developers as a consequence. How? Tutorials - Wiki based - Forum threads for feedback and questions Classes - On IRC - Covering tutorial material and topics which don't quite fit into a tutorial, e.g. how to write responsive UI - Possibly split out into a tutorial *after* each class, if the topic is self-contained enough Mentoring - A 'buddy' type system. Skilled developers offer to take on an eager trainee or two (or three or four) and 'show them the ropes'. It might be as simple as asking them how their project is going, and where they're getting stuck - from time to time - or as difficult as actually pitching in and helping them hack. Not really a role I want to define in terms beyond something like a 'big geeky brother'. :) Where do I sign up? I've set up a wiki page containing a copy of this material at: http://wiki.meego.com/DeveloperEngagement If you're interested in helping out as a mentor, or with classes or tutorials, please add yourself to the list. A sidenote: please let's not discuss the material now, because it's practically infinite :). I'm specifically after feedback on this proposal, and volunteers to step up to help get the ball rolling. Finally: I realise this sounds very Qt-centric, and well, it is - for two reasons. Firstly, that's my prime area of expertise, and secondly.. MeeGo is focusing on Qt as the toolset to use for application developers. If your skills aren't in the Qt arena, you can still be of help - providing other facets of developer knowledge (best practices, how to use version control, etc), or perhaps by being the guinea-pigs to run through early versions of tutorials. -- Robin Burchell http://rburchell.com ___ MeeGo-community mailing list meego-commun...@meego.com http://lists.meego.com/listinfo/meego-community ___ 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-architecture] Another architecture direction mail
As Andrew says, it is a pleasure to finally read this sort of communication. Thank you Arjan. On Sat, Apr 2, 2011 at 12:27 PM, Andrew Flegg and...@bleb.org wrote: On Fri, Apr 1, 2011 at 17:07, Arjan van de Ven ar...@linux.intel.com wrote: Thanks for circulating this - communication of such decisions is an important part of open development, IMHO. It starts to feel we are stabilizing on the golden path. As Carsten asks, it'd be useful for the maintainers - and interesting for everyone else - to see the criteria and problems identified. Indeed, so we can create those wiki pages to engage community contributors. However, could you clarify who the we is with we have been evaluating (given the comments from Sakari last time[1])? Also, are the meeting minutes going to be published where it was decided? I can understand not circulating for discussion beforehand; afterall, our architect group at work[0] doesn't go for consensus with every developer. But we do advertise each meeting before we have it, publish minutes and (technically ;-)) people can attend the meeting if they feel they have something to contribute. I would love to see us hold the meetings in the public, accepting one feedback per subject from randomly selected developer , and then allow community to watch meetings and see the decisions being made. So I for instance, could follow those meetings and blog or publish a writeup of all the technologies discussed, their issues preventing from making it to core, and engage community in helping. (as an example) I think the same level of process is (at a minimum) required in MeeGo to allow participation of others in future; and people won't contribute if they don't see a way in. ++1 -Sivan ___ 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 Bugs Access Denied
Can we please add mandatory fields to such bug reports: - Why is it inaccessible. - ETA for opening bug report. Such that filing those bugs will be impossible without ? -Sivan On Thu, Mar 31, 2011 at 9:27 AM, eric.le-r...@nokia.com wrote: Hi Marius, On 3/31/11 10:07 AM, Marius Vollmer marius.voll...@nokia.com wrote: ext eric.le-r...@nokia.com eric.le-r...@nokia.com writes: Indeed, file a request so we make the warning more user friendly, thanks. Can't you just do it without having a request filed? Nope. As we have a distributed team to handle bugzilla it's way easier if we actually have a formal request... So it doesn't go into limbo if I or someone else don't do it immediately. Sorry for being _that_ demanding :P Cheers, Eric ___ 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] Meego Bugs Access Denied
As me and timeless discussed in our talk, if you state a project is open , follow the statement. If the core base as not intended to be an end user platform, and is defined as an LFS project, why does it contain CSI stuff in a linux foundation bugzilla ? I propose each client customer vendor whatever has his own bugzilla or issue tracking pertinent to his derivative to not taint the open source meego.com. Customer sensitive information has one place and only one place - in customer's internal issue tracking system. If they want something fixed (with) upstream, they should have the person (the developer, PM whatever ) affected by the bug, report it on the open source bugzilla and work there with meego.com - the upstream until it is resolved. As someone following the open source meego distro, I couldn't care less about specific customer's issues that have no relevance or origination in the open source code base in its original form, unless I'm a consultancy doing custom development services on MeeGo, for which the mentioned down applies the same. bugs.meego.com should have no permission denied bugs. The process for re-reporting the issue from a customer (onto an open source bugzilla without CSI residual) should be prompt enough and perhaps we should anchor it in a Working with upstream MeeGo guidelines ? I've done this with projects like RSysLog, CouchDB , CouchDBKit, Ubuntu, GNOME and many more. I think that could be a solution to this issue? Or could this create a different problem of issues not reported even thought they originate and/or affect the core pristine code base? -Sivan On Thu, Oct 28, 2010 at 6:12 PM, Dave Neary dne...@maemo.org wrote: Hi, eric.le-r...@nokia.com wrote: Usually that reason is security issue or customer sensitive information. This seems to fall under the csi category probably. The unfortunate thing for me is this will increase in the near future before it gets better. Is there a possibility of putting in place some kind of process whereby the bugs can be public sanitised (without any CSI) and any super-zoomed surveillance photos, ballistic reports, DNA profiles, fingerprint searches and other CSI stuff can be somewhere else? (excuse my attempt at levity - hope it doesn't get lost in cultural translation!) Having closed bugs is one thing - planning to have more is another. But like you said, there should be a way to request access for people who need to know. As far as I can tell, this situation is exceptional and we should return to normal very soon. I completely understand the frustration and actually share it... a suggestion would be to have a Reason field which would be required when closing a bug to public - at least that way people would know why the bug was closed off. Reasons could be confidential information, Security issue or Oops, I checked the checkbox by mistake :) Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ 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)
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 Thu, Mar 24, 2011 at 9:07 AM, Carsten Munk cars...@maemo.org wrote: 2011/3/23 zoltan@nokia.com: Since lot of time was anyway lost on the subject, and it's an important subject, perhaps it would make sense to consecrate a wiki page to it, including the main use cases to be solved, the solutions proposed, the test data sets involved, test cases used for measuring the solutions (in production type of environment and background load), and then measurements for each solution (eventually on separate pages). This work anyway needs to be done, actually a lot has already been done, so it is not waste of time. It does not need to happen entirely (including all test cases) before Imad's decision, just a few. If you don't like this, just use email or whatever way you want. But let's set a deadline for this preparation until Monday, so that Imad makes a decision on Monday. Meanwhile the work doesn't have to stop. Please also remember that if there is supposed to be a technology selection, your dispute document also has to list people/companies publically committed to the task of implementation/maintenance. Actual contribution/commitment weighs harder than numbers sometimes. +1 Let me draw a parallel. When a feature comes in, there is a query around for who can and wants to invest in implementing and maintaining the feature (at least one release cycle up to a year after the release, in case of very important central feature probably several cycles) as well as QA responsibility. When a assignee/QA is found, the feature is accepted on the roadmap. A feature may cover several modifications in multiple components. At that time when a FEA# is proposed a component developer can pitch investments/commitment from companies to support it through numbers and facts, or take on the sole responsibility himself/herself. It's pretty obvious Intel has knowledge assets and people doing SyncEvolution/EDS already so they would probably not be interested in investing in the alternative. Which means someone else has to do the lifting. We can't ask for Intel's investment into technologies or strong arm them, nor should we. ++1 If I was a product manager or TSG looking at the technology choice/selection I would look, even before looking at the numbers, check if there's actual resources listed that will actually do the hard lifting for technology direction and discard the technologies that doesn't have sufficient. And then evaluate based on the facts. +1 BR, -Sivan ___ 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 Wed, Mar 23, 2011 at 6:09 PM, Carsten Munk cars...@maemo.org wrote: Guys, I think this discussion and (passive?) agressiveness has gone on for too long. I would propose that if you have a problem with decisions made, present a dispute to the TSG stating your exact objections, potential solutions to the issue and let it be evaluated and let the answer to the dispute from TSG be the final word. It is a role of the TSG to solve these kind of disputes. +1 We can't be bogged down with flamewars forever and we do need to make sure that when a decision is made by people nominated in roles where they should make the hard decisions, it is followed. Or we'll go nowhere with MeeGo. Not trying to troll, but you sent this email just when I was about to email my thoughts and ask about my concerns for where MeeGo is heading. Before any of you point out that Imad from Intel is the only person in TSG at the moment, that TSG meetings are public and that decisions made are public record. I personally trust that Imad will be objective and resolve the dispute properly. ++1 I'd also like to add that regardless of way the new architectural decisions were made, he's communication of the decision was excellent IMHO. I'm not sure this was not like this before, but his announcement was first of kind for me at least following the project Sometimes you need to use 'older' wheels and improve them until exhaustion before recreating them... and I think his approach could not be more healthier for the project not to mention improve release schedule and feature completeness per release. Also another note that I am trying to make through for a while about using wiki specs like Ubuntu does. I know that there's bugzilla. I don't think there could be worser tool to track specifications, not allowing you insert inline photos and images like in a proper wiki. I would like again, to propose using specs to plan ourselves ahead. it caters for easy to reach documentation (bugzilla couldn't be worse in that regard as well) for wide participation (everybody uses wiki's this days, bugzillas coward even me at times). I feel there is great objection to use proven tools and methodologies from other projects that evolved over the conservative ways of work of the open source projects of the 70s, like Ubuntu , Debian, Linaro and others similar. I can't understand why. I will try to serve as an example with my projects, but it would be great to have this for the core arch of meego. I fantasize of reading through the spec like Linaro has, understanding why decisions were made, how, what did they affect and how they are implemented. Architectural overview like we have is nice, maybe for a vendor decision maker, but not for someone interested and the bolts and bulbs of some inner subsystem like the watchdog, or DSME (we keep getting question about it , as Jeremiah asked not long ago) or policy kit etc. If those have specs upstream, then we should link them for easy access. I ask you, is it feasible to have a spec like I linked from the email I sent some time ago (a spec with drawing and charts together with text ). Or better, hover to linaro's wiki and wander through the other specs. I think if we work that way, this would be a leap forward and how we architect meego. Also, in conferences we should have bofs per spec to discuss with the people involved of its design and attack plan for implementation. -Sivan ___ 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 Wed, Mar 23, 2011 at 7:40 PM, Robin Burchell virot...@viroteck.net wrote: On Wed, Mar 23, 2011 at 4:48 PM, Sivan Greenberg si...@omniqueue.com wrote: I'd also like to add that regardless of way the new architectural decisions were made, he's communication of the decision was excellent I think the existence (and breadth) of this thread is clear evidence that it wasn't. Or did you skip over the bits about people with expertise in the areas involved and Nokia architects noting that they hadn't been consulted about this at all, and their requests for information on what specific performance problems there were etc repeatedly being ignored? I admit I found it difficult to follow the thread, I stand corrected! Let me just say that from my *personal* (I apologize if this sounded as if I speak for broader group...) point of view as someone following the development, I knew exactly what was going to happen, which components supposedly did not deliver the promise, and which components are going to be committed to onwards. For a simpleton like me trying to understand which technologies to target or work on, how open they are and what is the level of support in *open source* available, this was rather a breeze. (having known parts of SyncEvo, surrounding projects and the less then hour support replies I got from Patrick just by stating I am interested in helping, without tedious bug reports and endless red tape, also for me SyncEvo feels more of an tangible upstream to meego than tracker, but that is surely a hunch based, uninformed feeling). If the input was indeed disregarded, than this is terribly unfortunate and shows we have serious issues running the project which should be resolved *before* any engineering work goes on. Maybe we need to adopt Ubuntu's code of conduct? Let's hope an official governing body of MeeGo would address that ASAP as I know the Nokia side a bit, where blood sweat and tears were put into their responsibility areas in MeeGo. However, my personal reservation is that it is not possible that those wrong decisions were made at a whim and without considering the alternatives or the current state of affairs, or were light headed at. I just can't buy it, maybe I'm stupid. Even if that is how it seems from the communications exchanged on this thread so far. (Which gets me back on needing an open architecture process! with specs and bof per spec, after we get past the stabilization phase which feels to be delaying...). Superior technology is worth nothing without proper execution... Sometimes you need to use 'older' wheels and improve them until exhaustion before recreating them... Yes. Key point being that you should try improve something *first* rather than throw it out on what seems to be a whim without consulting the people involved and without backing up your reasons for *why*. I recall that Imad explained in his email why, again for me as a simpleton in the MeeGo world, that seemed enough. Regardless if EDS is much inferior to Tracker if I was an meego architect, I'd settle first for 10 contacts working flawlessly with the technology I can use without hurdles today (I have expectations from vendors, community, users? Yes yes, I know MeeGo is NOT for end users... Someone wants to see a final first usable version of the software already), than state of the art that cowards at locating or taking long to load or taking ages to load the first contact... or even if is flawless on the end user side, takes ages for my developers to learn.. or kills my battery..(this is just an example!) [I'd like to note that I am certainly not the world's biggest fan of some of the mentioned technologies, but I don't really support how this decision was made, either] I can understand that, and I admit I prefer open architecture decisions and discussions a'la Ubuntu BOF - Spec style. Linaro seems as if they are doing it at least in a very open and transparent way. -Sivan ___ 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 Conferece: non-commercial proposals are also welcome!
I wonder what we can do to avoid this kind of mis conceptions in the future - I guess this also worth discussion at the conf :-) Thanks for the note! -Sivan On Thu, Mar 17, 2011 at 6:43 PM, Quim Gil quim@nokia.com wrote: CROSSPOSTING ON PURPOSE - please reply only to meego-events. Loud and clear: 100% community - non-profit - hobbyist submissions are also welcome at the MeeGo Conference http://sf2011.meego.com/program/call-session-proposals Just like in Dublin. Hurry up! I'm sending this because I just realized at #meego IRC channel that many people thought the San Francisco conference was *exclusively* for commercial parties and topics like e.g. apps.meego.com or the community OBS were not wanted. Good that I asked and we found the problem. I'm not part of the content committee but I believe everybody in the conference organization assumes that any relevant community activity related to the MeeGo project is worth a submission proposal. -- Quim ___ MeeGo-community mailing list meego-commun...@meego.com http://lists.meego.com/listinfo/meego-community 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] Some architecture changes (MSSF / Buteo / PIM storage)
On Tue, Mar 15, 2011 at 9:10 AM, Ville M. Vainio vivai...@gmail.com wrote: On Mon, Mar 14, 2011 at 9:20 PM, Patrick Ohly patrick.o...@intel.com wrote: I've said before and I say it again here, I consider performance comparisons pointless at this time. Considering that e-d-s has a much more modest feature set than tracker (tracker in general being a much more ambitious project), I would have expected it to to trounce tracker in performance, which doesn't seem to be the case. I am wondering if EDS was tested using flat file storage ? (sorry for my ignorance in reading the test code and setup) This evidence might prompt to re-evaluate this part of the architectural plans. Or at least leave the door open to transitioning back to tracker when it's feasible. Isn't this the situation already? I remember Arjan saying this round. I at least hope that what we are aiming for is to first release something out the door already, usable to some degree, and then refactor/ improve when technologies get more baked and their interfaces. -Sivan ___ 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] Announcing MeeGo 1.2 Developer Edition for N900
Let us hope that this will be the natural successor to Harmattan on the N9(50?) and we could use the fruits of this development on that what I'm reading is a 1GHz OMAP6 device? -Sivan On Thu, Mar 3, 2011 at 5:02 PM, Arjan van de Ven ar...@linux.intel.com wrote: On 3/3/2011 5:36 AM, jukka.ekl...@nokia.com wrote: Hi there, I am thrilled to announce a little thing we started at Nokia. Basically we want to have MeeGo running in N900 device, so that it's really usable as your daily development device. Basic Handset UX should work, phone calls, SMS, web browsing. So we are concentrating on a few selected features and polish those to be perfect. It might mean that we leave out some things in MeeGo 1.2 trunk for this edition, but that is not the default intention. We are doing this fully on the open, and I hope this is an interesting project where we all in the community work towards the same goal: have a great MeeGo edition in the N900. This work is naturally based on the great work done already by N900 adaptation team lead by Harri and Carsten. The wiki is up here: http://wiki.meego.com/ARM/N900/DeveloperEdition. It will populated with more information as we go, thanks for the patience. does this include Nokia open sourcing the pieces they previously committed to open source (including policy etc) and the pieces that are essential for running the N900 ? but also seriously; after using a N900 for well over a year, last December I gave up on it; it was just too slow and the apps on it were too painful (browser, maps, etc) and the reception was too bad, I could just not keep using it. Believe me I tried, and it was pain in my heart to give up on something that could run MeeGo maybe some day... but it just wasn't a viable phone. So I won't be helping you on this project at this point... maybe when the next MeeGo phone ships from Nokia (it'll run MeeGo and not Maemo I take it from the press releases)... ___ 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] Dconf
On Wed, Jan 26, 2011 at 8:22 AM, Marius Vollmer marius.voll...@nokia.com wrote: What about moving Qt Mob PS into QtCore? QSettings is using it btw? Or has plumbing to allow usage thereof? (I now recalled I talked to you about this a long while back) -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Perf tweak: using asynchronous I/O with sqlite (e.g. for tracker...)
In my experience, and from extensively working with couchdb[0] , to way to improve performance of software that relies on sqlite is to make the writes as short as possible and more granular. Since reads IIRC by default return immediately if there's no writing thread blocking, this has quite nice results and is already utilized by projects like Axiom[1]. -Sivan [0]: (which could be interesting to test instead of sqlite if we're going to the proper async direction, being erlang it should not heave issues to run on mobile targets and is already running on iOS and Android, also it is highly performent if writes are un-conflicting and the current version of a document is represented by a view collecting revisions ) [1]: http://pypi.python.org/pypi/Axiom/0.6.0 On Wed, Jan 19, 2011 at 8:56 PM, Bernd Stramm bernd.str...@gmail.com wrote: On Wed, 19 Jan 2011 20:31:35 +0200 Ville M. Vainio vivai...@gmail.com wrote: On Wed, Jan 19, 2011 at 7:58 PM, Bernd Stramm bernd.str...@gmail.com wrote: Doing the writes asynchronously can improve response time for the parts of a system that don't wait for these particular write operations. Can you elaborate on that? Why would a process wait for a particular write operation, instead of just wanting to get access to the current state of the database? The process that issues the write may well assume that the data it just wrote are part of the current state of the database. If it doesn't wait for the write, this assumption is not necessarily correct. In particular, a read for the data changed by the write issued (but not completed) will reflect the old state. The writes do not go any faster. The difference is just that normally sqlite blocks the entire writing thread from doing anything else. Not just any other sqlite operations, but anything. No Qt event loop, for example. It doesn't actually gain performance in the sense that write operations don't complete any faster. It unblocks the process that is flushing the transaction, allowing it to process new requests. If you flush the data for a second and you get a new request, you lose that second (instead of being able to serve the request immediately). What you lose is Durability aspect of ACID. -- Bernd Stramm bernd.str...@gmail.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Cross development talk URL , Notification API Beta for MeeGo and Symbian
Hi All, I just wanted to update, that thanks to the wonderful Alexandra Leisse, MeeGo CO task page here[0] got a bit better with a link to Michael Samarin's talk about cross development. Michael talks about some basic guidelines to get started, and presents some interesting study cases that go as far to work on Windows Mobile, using Qt. And on a related note, I also want to bring to people's attention of the recent beta release from Forum Nokia of the new push Notification API. Not related per se to cross development but it does present common API across Symbian and MeeGo. This takes the task of supporting live data updates together with maintaining appropriate power consumption experience much easier than before. Read all about it here[1][2]. I had quite a privilege to participate in the live web cast with the developers and project drivers that took place before the beta release, I thank Forum Nokia and the Champion's program for this. Last but not least, I know that this page calls for cleaning up and re-org with repositioning of goals according to the dependent projects. This should come the following weeks. Cheers, -Sivan [0]: http://wiki.meego.com/Qt_across_(Maemo-)MeeGo_%26_Symbian#Resources [1]: http://blogs.forum.nokia.com/blog/nokia-developer-news/2010/12/08/push-notifications-and-long-battery-life-with-notifications-api-beta [2]: https://projects.forum.nokia.com/notificationsapi ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Dconf
I also recall a couple of emails about it from the beginning of the project. What has Ubuntu made already that could be served to a transitioning or testing phase ? -Sivan On Wed, Jan 19, 2011 at 12:28 AM, Arjan van de Ven ar...@linux.intel.com wrote: On 1/19/2011 6:11 AM, Ville M. Vainio wrote: Now that the internet is telling me Ubuntu is warming up to Qt and making Qt wrappers for dconf... Perhaps this is a bandwagon meego should jump to? It's not like we have anything better lined up in that area. -- this has come up several times ;-) we'll switch to dconf when we can obsolete gconf; hopefully that is soon, but for me it'd be a worst-case situation if we end up with both gconf and dconf at the same time. Yes dconf is better, but unless we can use it to replace the old bad boy we're not winning anything by going to it. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] progressing on compliance spec
Hi , So given we are now introducing a rather open PM process, maybe we can start planning to meet online about this as well (my hunch that they are quite related) ? I would imagine we'd need a representative from each group of stakeholders. Each representative can communicate his requirements, we pick up the most important or critical ones through consensus or voting and set to define them in the spec. As noted before, my interested is with embodying quality principles into it. Thanks in advance, -Sivan On Tue, Jan 11, 2011 at 3:16 AM, Sivan Greenberg si...@omniqueue.com wrote: Hi, Not that I know of and as of this thread. I actually spoke with Mats and expressed my care for quality aspects we should incorporate into the spec. We've set to speak again in a month's time or so. I have even proposed that a sprint could be dedicated to that, but then again this should include representatives from ideally most of the stakeholders in MeeGo. Best, -Sivan On Fri, Jan 7, 2011 at 11:29 AM, jukka.ekl...@nokia.com wrote: Hi, Did this proceed, is there a meeting(s) scheduled on IRC? Jukka -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of ext Sivan Greenberg Sent: 7. joulukuuta 2010 18:16 To: Ylinen Mikko.K (Nokia-MS/Tampere) Cc: meego-dev@meego.com Subject: Re: [MeeGo-dev] progressing on compliance spec I'm at UTC+2 currently, so late evening would be best unless it is friday. -Sivan On Tue, Dec 7, 2010 at 2:24 PM, mikko.k.yli...@nokia.com wrote: Hi, -Original Message- From: Wichmann, Mats D Sent: 03 December, 2010 18:50 since there still seem to be a number of open questions, I'd like to set up a #meego-meeting on a regular basis until we've come to more agreement. For those who are interested, are there particular times that would be bad (obviously already taken times are out since the meeting channel is single-threaded) Would you have any proposals? In general, afternoon/early evening EEST times are bad for me. http://wiki.meego.com/MeeGo-Meeting_IRC_Schedule -- Mikko ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Precision of what it means to 'be responsible for' / committing to maintaining a feature/package/whatever in MeeGo?
On Wed, Jan 12, 2011 at 10:28 AM, Dave Neary dne...@maemo.org wrote: re. Core should not be exempt: if we look at Debian, you can't become a maintainer of a package unless the maintainer(s) invite you to be, or the package is abandoned. I don't think any core packages will be abandoned any time soon, so the short answer there is to start packaging newer versions of core packages, and submitting them to the maintainer. What if I want to change something or add functionality to an existing package? For instance, what if I want to provide fixes or apply somebody else's fixes to improve the core UX in meego to be more suitable for the idea pad[0], and I do have the time for that. Perhaps we could at least assign a mentor or a sponsor that would review packages and upload them on my behalf? I even touched sysvinit in Ubuntu through this process[1]. Martin only physically uploaded it. For other packages, I hope that David or Arjan have a good answer - I'd love to see something like a package wishlist + list of orphaned packages, where new packagers can cut their teeth. Yes, that is highly desirable. Do we have an ITP request queue like Debian has? If not, can we please start it? We still need some people to be able to review packages or help people get their first package the #debian-mentors style , although I've seen that already happening in #meego. Do we keep this that way? In any case, your question clarifies that we're talking about package maintainer not project maintainer, which is, as I pointed out, a different role. Well, in Ubuntu when you wanted to add a feature you ultimately became the package's maintainer. When writing a spec you would even detail which packages you would have to depend on, possible workflows for upgrades, interaction with packaging system etc. So development or working on a new feature at least for the first runs meant you'd be maintaining the package. Where do we stand with regard to that? I hope mentioning packages need be abandoned to be cared for by the community does not imply that's core is mostly for Intel / Nokia or other funded stakeholders in the project? And yes, I know this is not Ubuntu :) So this is only suggestions from past experiences and questions, not criticism in any way. Cheers, -Sivan [0]: http://bugs.meego.com/show_bug.cgi?id=10739 [1]: https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/28447/comments/14 ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] How extreme should we follow upstream? (was: Precision of what it means to 'be responsible for' / committing to maintaining a feature/package/whatever in MeeGo?)
On Wed, Jan 12, 2011 at 1:14 PM, Dave Neary dne...@maemo.org wrote: You will need to presumably open some smaller-granularity bugs (Increase corner and edge target sizes on windows for touch events, for example), against the appropriate module. Now, I don't know exactly what is involved, but I can guess that changes would be needed in Mutter, I guess, and it probably needs some work in XInput Xorg to differentiate between touch mouse events, and related work in Clutter and Mx. It's possible that the maintainers of one or all of these modules will reject your work as not aligned with their goals - you can try to propose that the patch be carried as a distro-specific diff, but that would be quite a big one, and there's a good chance that the request would be rejected by the package maintainers MeeGo architects. So you should work with the Mutter/Mx/Clutter maintainers first to see if they agree with your way of doing things before you start doing the work, to give the best possible chance of your patch being accepted. Once you have a good idea that patches would be accepted, you can start working on the code for the problem. So first you'd make a patch proposal for XInput in Xorg, and a related patch request in Mx or Mutter, whichever is relevant (Thomas Wood, Thomas Friedrich or Emmanuele Bassi can tell you, I guess). They will review your patch, suggest changes, but (if you've done the work of getting everyone on the same page beforehand) these changes should only be minor. If, on the other hand, you propose patches for features the maintainers don't want, or you're doing things in a way they fundamentally disagree with, no amount of massaging the patch will help. So, once the XInput patch is accepted, and the Mx/Mutter patch is accepted, the changes will automatically propagate to the Netbook UX for the next version. Now, knowing that the next version of XInput will be releasing sometime in 2011, and Clutter (synced with GNOME I think) probably won't include your patch until September '11, MeeGo won't have it until the Winter '11 release, or perhaps Spring '12. Concretely, this is what working upstream actually means. So given this alleged time frame (I'm thinking out loud, and I thank you greatly for this discussion, albeit a bit off topic now to Carsten's original topic) , how extreme do we follow upstream? In my perception popular distros are doing something in between. I don't think we'd have usable out of the box distro like Ubuntu (which is for me almost a dream come true in terms of what I can offer to peopel coming from other platforms) if Ubuntu was just 'following' upstream. I know for fact that great measure had been taken to include distro specific patches until an upstream piece of software is actually usable or usable for general consumption. But if we target MeeGo to be just a 'reference' platform, then strictly following upstream is in place. And we can leave the local distro patching for the vendors, something that is happening anyways I guess. I don't believe personally we can give MeeGo to our non techie friends and tell them how great it is if it will always only follow upstream. As an example, gnome cups manager lacked support for controlling IPP printer detection in gnome for a long time. After realizing upstream is not going to deliver this, I did the GUI part and a core dev did the backend part and we released this feature to the great satisfaction of, in this case, corporate users[0]. Is this something we can hope to see in MeeGo in your opinion? Anybody else reading this thread? :) Again, I couldn't resist and I'm brainstorming out loud. Feel free to correct me or fill in with anything not accurate. -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Working upstream (was: Precision of what it means to 'be responsible for' / committing to maintaining a feature/package/whatever in MeeGo?)
On Wed, Jan 12, 2011 at 2:25 PM, Dave Neary dne...@maemo.org wrote: It seems your pointer [0] is uninitialised... [0]: https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/8975 It is indeed quite small change, but not just a configuration and theme change but proper glade file and C code change. Still this change meant a lot for people working inside secure LAN where IPP printers reside and announcing. Last time I checked, this change was dropped, as g-c-m is probably dealing with this itself upstream (I tried to check but couldn't find proof but my investigation was rather brief). But I this type of changes would have process in place I hope. As this kind of small details to my discontent are sometimes those who determine what will user X say about the usability of platform Y. -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Precision of what it means to 'be responsible for' / committing to maintaining a feature/package/whatever in MeeGo?
Hi Dave! I really liked the use of the median to conclude Prof. Knuth has not done much of maintainer-ship over Tex the last couple of years, but your account felt a bit too philosophical to me. But then again it is late for me, and this is probably my own subjective experience :-) On Mon, Jan 10, 2011 at 6:27 PM, Dave Neary dne...@maemo.org wrote: The glib short answer to the question how much time does it take to be a maintainer? is as much time as the maintainer wants to spend. So - I am who I am. I now have a lot of free time. I am interested in maintaining packages. I have experience in maintaining Ubuntu packages (gnome-cups-manager, gnome-system-tools, my own hubackup, notification-daemon and more). Not so much with RPM based packages. Bottom line, what do I do to start maintaining a MeeGo (core should not be exempt!) package? What is my course of action? Cheers, -Sivan -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] progressing on compliance spec
Hi, Not that I know of and as of this thread. I actually spoke with Mats and expressed my care for quality aspects we should incorporate into the spec. We've set to speak again in a month's time or so. I have even proposed that a sprint could be dedicated to that, but then again this should include representatives from ideally most of the stakeholders in MeeGo. Best, -Sivan On Fri, Jan 7, 2011 at 11:29 AM, jukka.ekl...@nokia.com wrote: Hi, Did this proceed, is there a meeting(s) scheduled on IRC? Jukka -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of ext Sivan Greenberg Sent: 7. joulukuuta 2010 18:16 To: Ylinen Mikko.K (Nokia-MS/Tampere) Cc: meego-dev@meego.com Subject: Re: [MeeGo-dev] progressing on compliance spec I'm at UTC+2 currently, so late evening would be best unless it is friday. -Sivan On Tue, Dec 7, 2010 at 2:24 PM, mikko.k.yli...@nokia.com wrote: Hi, -Original Message- From: Wichmann, Mats D Sent: 03 December, 2010 18:50 since there still seem to be a number of open questions, I'd like to set up a #meego-meeting on a regular basis until we've come to more agreement. For those who are interested, are there particular times that would be bad (obviously already taken times are out since the meeting channel is single-threaded) Would you have any proposals? In general, afternoon/early evening EEST times are bad for me. http://wiki.meego.com/MeeGo-Meeting_IRC_Schedule -- Mikko ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Forum Nokia UX Library
Hi All, The FN's UX design library is public and available at[0]. Recommended reading for people designing UXs looking for guidelines and direction. Cheers, -Sivan [0]: http://library.forum.nokia.com/index.jsp?topic=/Design_and_User_Experience_Library/GUID-A8DF3EB8-E97C-4DA0-95F6-F464ECC995BC_cover.html ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] What are the advantages of developing QT apps without libmeegotouch over MTF enabled application?
A related question for me as I'm going to implement a couple of UXs soon, what sort of already ready made regular application components are available from Qt Quick Components right now? Button, Windows, Dialogs? Can I use everything I would have used using Qt Designer default mainwindow app skeleton? -Sivan On Tue, Dec 28, 2010 at 4:20 PM, Andrew Flegg and...@bleb.org wrote: On Tue, 28 Dec 2010, 13:50:35 GMT, kate.alh...@nokia.com wrote: With Qt Quick you have all enablers for full MeeGo UX and in Qt Quick Components you have all UX components ready made. Well, not yet. And it's not yet clear what that means in terms of good cross-platform support (e.g. Symbian, Maemo or MeeGo). What *is* the timescale and roadmap for Qt Quick Components? Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Fwd: Qtest Mobile App Port Contest for Qt and KDE applications
Well, still it might be a good opportunity to do test driven development with qt's testing framework. -Sivan On Mon, Dec 27, 2010 at 4:26 PM, Dan Leinir Turthra Jensen ad...@leinir.dk wrote: On Monday 27 Dec 2010 13:42:43 Thiago Macieira wrote: On Monday, 27 de December de 2010 14:37:00 Sivan Greenberg wrote: On Mon, Dec 27, 2010 at 3:04 AM, Thiago Macieira thi...@kde.org wrote: I don't know if this was the intention, but the name indicates that one is supposed to write a unit test application (QTest is the namespace containing some functions, from module QtTest). Thanks for the clarification, I had assumed this is around this. I was interested to see how QTest stuff matches with PyUnit. I might give it a try :) Just to be clear: I don't know if you're supposed to write a unit test. But the name of the contest sure does give that impression. It is not - just read it out loud and it makes some semblance of silly sense, but yeah, oops ;) -- ..Dan // Leinir.. http://leinir.dk/ Co- existence or no existence - Piet Hein ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] SyncEvolution in bug jar but not part of meego ?
Hi All, In Dublin I was told that SyncEvo was replaced by Buteo since it was not extensible enough. Is it this still part of MeeGo? I keep seeing it in the bug jar reports, hence why I'm asking. Thanks -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] progressing on compliance spec
I'm at UTC+2 currently, so late evening would be best unless it is friday. -Sivan On Tue, Dec 7, 2010 at 2:24 PM, mikko.k.yli...@nokia.com wrote: Hi, -Original Message- From: Wichmann, Mats D Sent: 03 December, 2010 18:50 since there still seem to be a number of open questions, I'd like to set up a #meego-meeting on a regular basis until we've come to more agreement. For those who are interested, are there particular times that would be bad (obviously already taken times are out since the meeting channel is single-threaded) Would you have any proposals? In general, afternoon/early evening EEST times are bad for me. http://wiki.meego.com/MeeGo-Meeting_IRC_Schedule -- Mikko ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Learning from Mistakes and Beyond, slides available in PDF.
Hi All, For those of you who have been asking for the slides, thanks to timeless they are online in .PDF here[0]. For those who found it lacking a general point, you're not wrong. There is no general point made here, other than learn and try to not repeat and these solutions might help along the way. This is about details, indeed. There are some minor text positioning issues in some of the slides, but they should be good to go. Mats, as per your suggestion to discuss compliance quality items on -dev, both general and specific ideas are addressed in the slides (and talk). I hope you find this at least interesting as an entry point. I'm keen on discussing this further and iron this out into mandatory quality requirements into the spec/ sub profiles. On a related note, can we please fill this page up[1] with at least a link to [2] , a request for feedback and a contact person? Let's make it easier for those who arrived at www.meego.com and just searched for compliance[3]. Thanks! -Sivan [0]: http://conference2010.meego.com/sites/all/files/sessions/meego_learning_from_mistakes.pdf [1]: http://meego.com/about/compliance-program [2]: http://wiki.meego.com/Quality/Compliance [3]: http://meego.com/search/node/compliance ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Setting up sources to be able upgrade from daily snapshots.
Hi List, I'd like to set up my netbook to upgrade from whatever is used to create the daily netbook snapshots. For testing. What is the way to go about this? I'm thinking along the lines of setting it to use unstable distribution in Debian terms, so I can then zypper refresh and upgrade. I apologize if this has been asked already, but google seems to be indecisive regarding the answer. Thanks, -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] QWidget::showEvent might be helpful for apps wanting to know if they should keep drawing.
Hi List, Me and Javier talked about this a day ago, and I went on to find if there's something in Qt already to help app developers to do the right thing when their applications are out of focus, minimized or are brought back and visible again. I did some questioning around #qt-labs and found out about this aforementioned[0] event (for me it is just a callback I reiplement to act on this event). This may be a start but reading the reference (which could be a bit clearer) we're still missing the hide thing. To my understanding, this callback can help to know that an app that wishes to deliver running in background UX needs to maintain drawing until it is fired the hide[1] event. Now if I get this right the window manager or ux-launch or whatever is responsible for what the compositor did in Mamo, needs to call this event on the top level widget of an app (QMainWindow perhaps as an examle?) when it hides it away, so then the app itself knows it is safe to stop drawing and will continue upon receiving a showEvent. However, an ambiguity arises as the Qt reference states the hide events are also dispatched when a widget is minimized, so this also depends on what is the state of an app when it is shown in MeeGo/Maemo dashboard. (e.g. small windows instead of completely minimized as on the desktop) or what's the definition of minimized in the maemo/meego sense. Is any of this making sense, is it already implemented as so? Thanks, -Sivan [0]: http://doc.qt.nokia.com/4.6/qwidget.html#showEvent [1]: http://doc.qt.nokia.com/4.6/qwidget.html#hideEvent ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] QWidget::showEvent might be helpful for apps wanting to know if they should keep drawing.
Sorry about the noise, but apparently I confused those with this that are actually the thing to use: QEvent::WindowActivate QEvent::ApplicationActivated (google was unkind letting me find the references for those events so you'd have to google them yourself) Now the question is, if the meego window manager (MTF?) uses those with apps it manages. Thanks, -Sivan On Fri, Nov 12, 2010 at 8:20 PM, Sivan Greenberg si...@omniqueue.com wrote: Hi List, Me and Javier talked about this a day ago, and I went on to find if there's something in Qt already to help app developers to do the right thing when their applications are out of focus, minimized or are brought back and visible again. I did some questioning around #qt-labs and found out about this aforementioned[0] event (for me it is just a callback I reiplement to act on this event). This may be a start but reading the reference (which could be a bit clearer) we're still missing the hide thing. To my understanding, this callback can help to know that an app that wishes to deliver running in background UX needs to maintain drawing until it is fired the hide[1] event. Now if I get this right the window manager or ux-launch or whatever is responsible for what the compositor did in Mamo, needs to call this event on the top level widget of an app (QMainWindow perhaps as an examle?) when it hides it away, so then the app itself knows it is safe to stop drawing and will continue upon receiving a showEvent. However, an ambiguity arises as the Qt reference states the hide events are also dispatched when a widget is minimized, so this also depends on what is the state of an app when it is shown in MeeGo/Maemo dashboard. (e.g. small windows instead of completely minimized as on the desktop) or what's the definition of minimized in the maemo/meego sense. Is any of this making sense, is it already implemented as so? Thanks, -Sivan [0]: http://doc.qt.nokia.com/4.6/qwidget.html#showEvent [1]: http://doc.qt.nokia.com/4.6/qwidget.html#hideEvent ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] QWidget::showEvent might be helpful for apps wanting to know if they should keep drawing.
On Fri, Nov 12, 2010 at 8:41 PM, Bernd Stramm bernd.str...@gmail.com wrote: Does this address whether a widget is obscured by something else? In some windowing systems large numbers of windows are visible, or partially visible. In other windowing systems only a small number (like say, one) are visible. The windows don't know this in Qt. True, so it would be useful to know how far I was minimized, and do a ratio of this and the size of the display, then you could know if it is still worth redrawing, this could be a nice optimization direction and still maintain highly responsive UX. More generally it would be really nice if my application would know what kind of device it is running on, *at run time*. And what kind of display is used. How large are things on the display. If those things are unknown (as I think they are at present), it is not practical to write applications once and have them work on different types of devices. True, I think I saw this is being worked on , but otherwise there are nice and friendly people in #qt-labs you talk to, possibly file a feature request, patch etc etc :) And no, tons of #ifdefs don't count as write once :) Known, and is already somewhat described here: http://wiki.meego.com/Qt_across_(Maemo-)MeeGo_%26_Symbian#Collecting_Porting_Experience -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] QWidget::showEvent might be helpful for apps wanting to know if they should keep drawing.
Thanks Robin for that, On Fri, Nov 12, 2010 at 9:32 PM, Robin Burchell virot...@viroteck.net wrote: meegotouch at least is one step ahead on this, it seems: http://apidocs.meego.com/git-tip/mtf/class_m_widget.html#a0190cf09ccca7fc23769082b31b54538 For people involved in MTF, what does the following states that are possible through the event mean: http://apidocs.meego.com/git-tip/mtf/class_m_on_display_change_event.html#a7763c99cb5844f5999a0b437fd8bfaab MustBeResolved Widget must use viewRect to verify its presence on the display, as well as of all its children. How this state is detected by MTF before dispatched? PartiallyOnDisplay Widget is partially present on the display, according to its bounding rectangle. Widget may still use viewRect to get a more precise (and therefore more computationally expensive) assertion by comparing it against its shape, for instance. Could there be a percentage of how much of the window is on display? For example, I think it be still nice to have an app drawing until it gets more than 20% out of view (I now realize this is due to the fact windows can be moved sideways in MeeGo) Thanks! -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] QWidget::showEvent might be helpful for apps wanting to know if they should keep drawing.
On Fri, Nov 12, 2010 at 9:09 PM, Arjan van de Ven ar...@linux.intel.com wrote: can we get some urgency on solving this? adding events for you're visible and you're not visible ? It's a huge deal for power / thermal savings. To really make to easier and a no brainer for at least the bulk of use cases, this should really be just a I am visible , I am not visible, without daunting the developer doing all sorts of heavy computation to know if he/she need to draw or not. -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] NQS vs MeeGo SDK [Re: MeeGo 1.1 SDK beta released]
On Thu, Nov 11, 2010 at 11:43 AM, Attila Csipa me...@csipa.in.rs wrote: IIUC The biggest problem with that is support - the version of QtCreator means little in terms of what targets you are actually using in there (the distro supported one is usually limited to the desktop Qt version the distro ships with). However, if you decide you want to use THAT QtCreator with Maemo5/6/MeeGo1.1/1.2/SymbianS60/S3/YouNameIt targets, it suddenly gets very very murky (esp since there is no Qt version/feature equivalency across these targets). That said, I would really like to see a properly packaged NQS not just a blob installer. Target support should come in the form of plugins, if not already so (the fact you can choose to install a subset of targets and components in the NSQ installer suggests that). Such that distro packagers could package them separately and you could then have your distro installer get you the version of creator and offer you to also install its set of compatible target plugin package. Most of the FOSS stuff does this already on Debian/Ubuntu. I'd be great to have this with the NSQ. -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Buteo SyncML: OVI.com fix
Hi Folks, Part of the discussion in Munich OVI sprint we in the PIM team concluded that we'd like to achieve the following for better integration with either the KDE desktop/ MeeGo: 1) OVI to officially support SyncEvolution, e.g. be fully compatible with SyncEvolution through its usage of SyncML. 2) Create a reference pure qt UI for either the desktop and mobile platforms. Now according to this group of threads on the ML, it seems that there's already collaboration going on between SyncEvolution team and Nokia / Intel. We'd like to know what's the status of this, in order to not duplicate efforts, or preferably re-use mobile version of qt ui for SyncEvolution for KDE, if a such already exists. Many thanks in advance, -Sivan On Fri, Nov 5, 2010 at 7:57 AM, Santosh Puranik santosh.pura...@nokia.com wrote: Hello Patrick, ext Patrick Ohly wrote, On Thursday 04 November 2010 06:41 PM, UTC +0530: According to the patch, a new config option omit-data-update-status is added to /etc/sync/meego-syncml-conf.xml which, if set, enables some new additional logic. Question: is it necessary to use a meego-syncml-conf.xml which has omit-data-update-status == 1 to avoid the problem? The default value is still 0. Yes, that's correct. The ovi.com server expects that the SyncML client omits the Data Update Status to Server package if there are no status to send (when the server has no changes to send to the client). This omit-data-update-status package controls this behavior of the Buteo SyncML stack. So, clients can enable this configuration in their stack configuration files if needed. Best Regards, Santosh ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Buteo SyncML: OVI.com fix
On Mon, Nov 8, 2010 at 2:57 PM, Patrick Ohly patrick.o...@intel.com wrote: The question of Ovi.com-MeeGo interoperability is something completely separate from that. It is done inside Nokia and I don't know much about it. Sateesh should be able to tell you more. My interest is more from an Sateesh, could you please kindly elaborate on the state of things then? Also, what efforts, if at all, are carried to create a QT/MeeGo UI ? architectural point of view: if tweaks to a shared file in /etc/sync are necessary, how can we get those into MeeGo Core? My experience with Debian tells me that you need a package in core for sync configuration, or delivering the sync framework package (be it Buteo or else) with the required configuration file modifications represented in the binary package, possibly through a patch phase in the package build process. If the question is around approval of such packages, then we need to consult whoever approves core packages, which I think now happens through feature request onto futurzilla. -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Buteo SyncML: OVI.com fix
On Mon, Nov 8, 2010 at 5:35 PM, Patrick Ohly patrick.o...@intel.com wrote: On Mo, 2010-11-08 at 15:20 +, Sateesh Kavuri wrote: On Monday 08 November 2010 03:42 PM, ext Sivan Greenberg wrote: On Mon, Nov 8, 2010 at 2:57 PM, Patrick Ohlypatrick.o...@intel.com wrote: The question of Ovi.com-MeeGo interoperability is something completely separate from that. It is done inside Nokia and I don't know much about it. Sateesh should be able to tell you more. My interest is more from an Sateesh, could you please kindly elaborate on the state of things then? Also, what efforts, if at all, are carried to create a QT/MeeGo Currently Ovi.com Contacts synchronization is not part of the MeeGo Sync feature list. About the Qt/MeeGo UI for Sync, there is already effort to create such an UI. Ossama (in CC) is working on this and he can provide more info about the current status. This will be a MTF based UI, integrated into the Handset UX. Sivan, is that the kind of Qt UI you were looking for? Since the handset is dear to me, that is very much interesting to me as well. We thought regarding KDE, that if some sort of skeleton exists for a UI client, we could also re-use it for KDE. I will continue this in the respective KDE mailing list for a desktop UI. Thanks! -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Buteo SyncML: OVI.com fix
On Mon, Nov 8, 2010 at 5:20 PM, Sateesh Kavuri sateesh.kav...@nokia.com wrote: Currently Ovi.com Contacts synchronization is not part of the MeeGo Sync feature list. About the Qt/MeeGo UI for Sync, there is already effort to What's needed to achieve this btw? If that's okay to discuss in public channels... Maybe it is addition of PIM items or fields to the Buteo stack? create such an UI. Ossama (in CC) is working on this and he can provide more info about the current status. If you would like to contribute the UI, I think the best way is to get in touch with Ossama and work together for the wireframes and the implementation. Yes, I'm keen on that and will wait for Ossama's reply. -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [Meego-architecture] MeeGo Architecture BOF - request for topics
Hi, - dconf vs. gconf vs. flat files using QSettings - Why Buteo over SyncEvolution - boot loader changes, how and where? - Architecture features: what's the process? These are off the to of my head, I might have more if we sit for the actual discussion. -Sivan On Mon, Nov 8, 2010 at 5:55 PM, sakari.pou...@nokia.com wrote: Hi, We have a BOF session on MeeGo conference about open architecture process: http://conference2010.meego.com/session/open-architecture-process-meego Time is limited so we would like to know what type of topics people want to be discussed on that BOF. Can you send your proposal so we can compile a list of topics beforehand. Regards, MeeGo Architecture Team (Sakari, Arjan, Mikko, Sunil) Sorry for cross-posting - replies on meego-architecture list, please. ___ MeeGo-architecture mailing list meego-architect...@lists.meego.com http://lists.meego.com/listinfo/meego-architecture ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] 1.1 core release notes.
Hi List, It seems we are missing the release notes for the meego core , as they are available for the handset: http://meego.com/downloads/releases/1.1/meego-v1.1-handset They should be added to: http://meego.com/downloads/releases/1.1/meego-v1.1-core-software-platform . As for example, this one bug[0] as kindly referred to me by Stskeep should be mentioned for the sake of testers. Actually, now that I check this- it seems that this is not even mentioned on the handset release notes. Could someone with access to the part of the site add the required release notes there? Many thanks! -Sivan [0]: http://bugs.meego.com/show_bug.cgi?id=2260 ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] 1.1 core release notes.
On a related note, I think we should have a few more people dealing with important stuff like release notes. To cater for quick edits and important emergency release related announcements, especially pertaining to making sure users don't shoot themselves in the leg. -Sivan On Thu, Nov 4, 2010 at 10:55 AM, Sivan Greenberg si...@omniqueue.com wrote: Hi List, It seems we are missing the release notes for the meego core , as they are available for the handset: http://meego.com/downloads/releases/1.1/meego-v1.1-handset They should be added to: http://meego.com/downloads/releases/1.1/meego-v1.1-core-software-platform . As for example, this one bug[0] as kindly referred to me by Stskeep should be mentioned for the sake of testers. Actually, now that I check this- it seems that this is not even mentioned on the handset release notes. Could someone with access to the part of the site add the required release notes there? Many thanks! -Sivan [0]: http://bugs.meego.com/show_bug.cgi?id=2260 ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Virtual Keyboard
Hi, Without actually looking at the UI, but isn't this a bit awkward ? e.g. Enter is common enough to be more apparent that that? Hopefully it'll change for 1.2 ? -Sivan On Tue, Nov 2, 2010 at 7:01 PM, Mohammad Anwari md...@di.blankon.in wrote: 2010/11/2 praveen pandey praveen.pan...@gmail.com: Hi All, I dont see an 'Enter key' in Virtual Keyboard in meego 1.1 image. I tried SMS application and wifi application but both keypads are not having 'Enter' key. Is there a need to install some other keyboard layout. Hi, In 1.1 the Enter key is under Space, so you need to press Shift-Space to get Enter. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Virtual Keyboard
On Tue, Nov 2, 2010 at 8:41 PM, Mohammad Anwari md...@di.blankon.in wrote: 2010/11/2 Sivan Greenberg si...@omniqueue.com: Hi, Without actually looking at the UI, but isn't this a bit awkward ? e.g. Enter is common enough to be more apparent that that? Hopefully it'll change for 1.2 ? Yes, it will change, you consider that as a journey of the UI of MeeGo virtual keyboard :-) Great, as per my latest involvement with Maemo and MeeGo, it is important we do not repeat previous UI mistakes or leave stuff like that unchanged, were there plans to fix that without a user noticing it and commenting on it here? :) Thanks! -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] MeeGo Backup Framework
Hi List, I was wondering where one can read about the backup framework as mentioned in [0] ? As the developer of several backup solution both closed and open source, I'm interested in having a complete dummy poof backup system for MeeGo; that is, other that storing your contacts and personal preferences, also the storage you've used on your device to keep your photos, music, files etc. Also I wonder if ownCloud[1] was taken in consideration when creating the framework? I reckon it could be a viable solution as a storage sync back end, and is inline with other PIM services. Thanks, -Sivan [0]: http://conference2010.meego.com/session/backuprestore-meego [1]: http://owncloud.org/index.php/Main_Page ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Backup Framework
On Fri, Oct 29, 2010 at 12:38 PM, Dave Neary dne...@maemo.org wrote: By the way, like the new URL? Thanks to Ferenc for doing the config changes from http://bugs.maemo.org/7107 - the same config change has been proposed for MeeGo in http://bugs.meego.com/1128 - Oops! Doesn't work yet :) Yeah! It is much better to be able to reference bugs like this. Regarding docs btw, I think we should mandate to work the TTD way as in turning the Requirements -- Docs -- Tests -- Code. That will enable the new MeeGo framework to be properly documented rather than docs being an after thought. -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Backup Framework
On Fri, Oct 29, 2010 at 12:28 PM, Sateesh Babu sateesh.kav...@gmail.com wrote: Right now there is no working backup solution for MeeGo. There are initial set of requirement created [2] for the backup framework (some still unclear ATM). The idea is to share and exchange more information about the backup framework in the upcoming MeeGo conference. Would be quite happy to get inputs from someone quite experience in this area. Very well. As I'm quite experienced with backup systems (one open source example is hubackup[0]) I will go over the requirements list and start working to solve unclarity. My end goal would be dummy proof system to allow maximized testing of new releases and upgrades by the community. Support of online backup services is an open question (see [3]). It would be nice to have a reference service for MeeGo and maybe OwnCloud could be considered. Feel free to comment further in the feature requests for backup/restore. Will do, a quick note, out of my experience it is much more viable to have users backup to either online storage, or their own private clone of the online storage service. My backup solution tried to enable optical medium backups and that proved to be erronous and require tremendous effort in planning workflow that would instruct a user To do the right thing (tm). Cheers! -Sivan [0]: http://www.ubuntugeek.com/hubackup-backup-application-for-ubuntu-home-users.html ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Geoclue and Qt Mobility on MeeGo
Re reading about MeeGo's architecture, is Geoclue the engine or the backend for Qt's Mobility location and positioning APIs? If not, what is the relationship ? Thanks -Sivan (Since these subjects appear to be part of the core stack, I felt comfortable to discuss this here and not on meego-sdk) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] lack of QA mailing list; or what do we have in place to prevent UX regressions?
Hi List, I was delighted to be informed by the good Maemo bug master that that this bug [0] has been resolved with the last PR1.3 update, released today. My question to QA people and teams (it has been a while since I was involved with QA in meego so please bare with me) - What sort of infrastructure do we have in place to make absolutely sure this will not regress in further versions of MeeGo, if hypothetically this bug had been originated in MeeGo ? If not I think we should start spec'ing and designing it ASAP, or is the BOSS wrapper around OBS for continues integration solves that as well? And on a related note, besides the dear bug master's talk, are there any other people interested in discussing quality that might be good to pre-announce so people can plan ahead and decide to which talks BOFs they want to attend? [0]: https://bugs.maemo.org/show_bug.cgi?id=8747 Cheers, -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] lack of QA mailing list; or what do we have in place to prevent UX regressions?
Yes, thanks Andre, it just missed me from the main meego.com subscription page at the user page. On Mon, Oct 25, 2010 at 10:57 PM, Andre Klapper aklap...@openismus.com wrote: Am Montag, den 25.10.2010, 22:43 +0200 schrieb Sivan Greenberg: What sort of infrastructure do we have in place to make absolutely sure this will not regress in further versions of MeeGo, if hypothetically this bug had been originated in MeeGo ? Probably something better to discuss on http://lists.meego.com/listinfo/meego-qa though that place is sometimes a bit too quiet. andre -- Andre Klapper (maemo.org bugmaster) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Python packaging policy for MeeGo?
On Mon, Oct 18, 2010 at 12:53 PM, Matti Airas matti.p.ai...@nokia.com wrote: [1] http://wiki.meego.com/Packaging/Guidelines [2] http://en.opensuse.org/openSUSE:Packaging_Python [3] http://fedoraproject.org/wiki/Packaging/Python Which ones should we follow? I wonder should we also have explicit guidance about the matter in our packaging guidelines? Explicit guidelines for Python packaging should be available under the packaging manual, IMHO. Lack of them I guess is just the artifact of our project still being relatively young. +1 for adding official python packaging guidelines by who ever is the authority on this. -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Notification Manager in Meego
You can try and use dbus-monitor (running through sudo or root might unveil more info) since to my understanding most if not all of the system events are passed through this message bus. For instance, running this program on Maemo on the terminal and doing all sorts of stuff with it shows a wealth of information of what's happening on the system right now, so you can detect calls, messages, handset tilts etc... -Sivan On Mon, Oct 18, 2010 at 1:28 PM, dhaval bc dhava...@gmail.com wrote: Hi, Is there any notification manager implemented in meego, to which i can register to get system events notification. Regards, Dhaval ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] GConf as the settings database
On Mon, Sep 27, 2010 at 8:15 AM, Marius Vollmer marius.voll...@nokia.com wrote: The Right Thing would have been (IMO) to get behind dconf, and write the Qt-equivalent of GSettings for Harmattan. This didn't happen and libgq just doesn't die. There is a copy of it somewhere in Qt Mobility as well. So, to create a QSettings API compatible class that would be the GSettings for Harmattan? Or given QSettings doesn't allow for change subscription and listening, the MGConfItem is preferable? I propose that we find a owner for libgq, and he/she then kills off its copies in libmeegotouch and Qt Mobility and takes patches, etc. He/she might also want to follow the 'vision' of libgq and provide more wrappers, such as for GIO. I might be actually interested in that, but first would carefully investigate what this would require and to make sure I could pick up the missing bits on the go. -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] GConf as the settings database
On Mon, Sep 27, 2010 at 8:15 AM, Marius Vollmer marius.voll...@nokia.com wrote: copies in libmeegotouch and Qt Mobility and takes patches, etc. He/she might also want to follow the 'vision' of libgq and provide more wrappers, such as for GIO. Marius, apart for the gconf -2lib that it required for building, would I require anything else to experiment with it and attempt at replacing gconf with dconf for some experiments? The vision, is hence to provide as many more back ends such as GIO ? Thanks, -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] GConf as the settings database
On Sun, Sep 26, 2010 at 8:38 AM, Ville M. Vainio vivai...@gmail.com wrote: On Sat, Sep 25, 2010 at 4:56 PM, Sivan Greenberg si...@omniqueue.com wrote: Thanks for this reply, seems that betting on MGConfItem is reasonable. Just use QSettings if you don't need to listen to subscribe to changes in settings (most apps don't). GConf is too heavy and platform-specific for most needs. Given that, I wonder if it was re-chosen for either backward compatibility with GNOMEish legacy from Maemo, the lack of any other system that is close in feature set or both? If you need to subscribe to changes, consider Qt Mobility Publish Subscribe API instead. It can use gconf as back-end on Linux. I'll also check if it can be set other back ends as well on Linux, although judging by the MeeGo architecture document GConf remains as the standard config database. I wonder why we have to suspect things btw, isn't the fact it is at apidoc.meego.com makes it an official way to work with the settings? Being there is not really a sign of something being official, at least yet. Note and accounted for, Thanks. -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] GConf as the settings database
Hi List, According to http://meego.com/developers/meego-architecture , GConf is the settings database for MeeGo. Give MeeGo SDK is heavily based and utilizes Qt, is this for backward compatibility or indeed the main settings database that should be used from within Qt through something like [0] ? If so, then [0] is probably now part of the Application Framework in MeeGo ? Thanks, -Sivan [0]: http://maemo.gitorious.org/~vivainio/maemo-af/libgq-fremantle/blobs/master/gconf/gconfitem.h ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] GConf as the settings database
On Sat, Sep 25, 2010 at 5:45 PM, Robin Burchell virot...@viroteck.net wrote: No, at least, I very much doubt it. libgq seems to be unmaintained - or at least, nobody seems interested in taking my patches to it, despite repeated attempts to get somebody to have a look (see http://lists.maemo.org/pipermail/maemo-developers/2010-August/027366.html for details on that). I also don't think it is packaged for MeeGo. I suspect that MGConfItem (http://apidocs.meego.com/mtf/class_m_g_conf_item.html) is the thing to use, though personally I think this would be better placed at the Qt level either relating to QSettings (as mentioned in a reply to this mail) or something, so as for application developers to maintain maximum portability (to e.g. Symbian) Interestingly enough, the apidoc for MGConfItem looks suspiciously the same like the \brief in [0]. Seems likes only the name was changed into t MeeGo SDK naming. (MGConfItem instead o GConfItem as available from libgq). Anyway, this is probably the way to go and yes, your note that it should sit part of Qt instead of being duplicated in MeeGo makes sense, although sometimes it makes it easier to release a consistent API that wraps everything to unify access, so you always use MG* instead of Using Q* for settings, and MG* for touch stuff etc. Thanks for this reply, seems that betting on MGConfItem is reasonable. I wonder why we have to suspect things btw, isn't the fact it is at apidoc.meego.com makes it an official way to work with the settings? -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] GConf as the settings database
On Sat, Sep 25, 2010 at 7:05 PM, Thiago Macieira thi...@kde.org wrote: On Saturday 25. September 2010 16.46.14 Martin Grimme wrote: Hi, I suppose QSettings would be the portable class of choice for accessing GConf on MeeGo, ini-Files on Linux and Mac, Registry on Windows. The documentation [1] doesn't mention a gconf backend at the moment, though. There isn't one. As an app developer I don't see this much as a problem, as KDE for example is said to be using .ini files happily? If this lacks the ability to notify subscribing entities of conf changes, that is something else. -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Version of Qt the Nokia Qt SDK has.
Hi List, Trying to download the newly released Nokia Qt SDK using the online Linux 32 bit installer suggests that the version of Qt that is delivered with it is 4.6.3 (if to judge by the sources download option). Also, without claiming for accuracy I couldn't find the release notes to check the details of this bundle at[0]. How can I use the latest Nokia SDK (released Sep. 14th) with the latest version of Qt for both desktop and MeeGo (-maemo stack in the installer options) development ? Many thanks, -Sivan [0]: http://qt.nokia.com/products/qt-for-mobile-platforms#qtfornokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Creating a Python project for MeeGo
On Mon, Sep 20, 2010 at 9:18 PM, Attila Csipa me...@csipa.in.rs wrote: On Mon, Sep 20, 2010 at 8:26 PM, Matti Airas matti.p.ai...@nokia.com wrote: In my opinion, Core OS, absolutely. There's already a world of pain in Maemo 5, with Python being just in Extras and thus effectively prohibited from Ovi Store. Yet, 20% of maemo.org apps are written in Python, so there's a significant developer base there. We're working on Harmattan to have the Ovi Store situation changed, and having to revert the stance once more in MeeGo proper would be, well, quite strange. Additionally, Per's point of having PyGTK present in Core is a good reference: I think it would be a rather suboptimal situation if you could develop MeeGo-compliant Python applications for the Handset UX only with GTK but not with Qt. +1 +1 for Core OS. In pushing to promote PySide as the rapid prototyping and development approach you get people saying it is not even official in either of the platforms. There has been already much investment and efforts going into PySide that I think this is really just a natural proceeding. This is a great technology, being developed in the open, enabling those who still are not C++ experts to develop for Harmattan right now. Something that can enable us to target wider developer audience for the upcoming platform and widen even greater the developer offering for Nokia. Not to mention it makes it easier for people that want to migrate from other platforms and programming languages that are far enough from C++ to do so in a true rapid way. -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Creating a Python project for MeeGo (was: pyside in repo.meego.com?)
On Mon, Sep 20, 2010 at 5:59 PM, Matti Airas matti.p.ai...@nokia.com wrote: On 20.09.2010 17:41, ext Per Åstrand wrote: Hi! I've been checking the repositories for python support. AFAICT the compliance doc at http://www.pyside.org/2010/09/meegotouch-bindings-alpha-available/ requires an application to only use packages in the officail repos to be meego compliant IMHO it makes sense to also include python bindings for QT (pyside) to be able to write meego compliant applications in python. pyside project seems to be tracking QT and meego well (http://www.pyside.org/2010/09/meegotouch-bindings-alpha-available/). Also kind of strange that bindings for gtk is in the repo, but not for QT... Hi Per, We (as in the PySide team) are definitely planning on providing the PySide packages on MeeGo in the near future. However, since we're just ramping up our MeeGo activities (still waiting for the OBS accounts to be created, etc), I have to say I've been rather ignorant about the details of the contribution process. In particular, I'm interested about the proper channels for contributing to the existing Python distribution. What is the formal project the current Python packages live in? Should we contribute there or should we make a proposal to the TSG to create a proper MeeGo Python project which could act as an umbrella for all Python-related activities in MeeGo? Matti, maybe we can ask Dawn to add this item for tomorrow's TSG meeting so it can be discussed and agreed upon already? -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Creating a Python project for MeeGo (was: pyside in repo.meego.com?)
Sorry, tomorrow is just the community office meeting. But I think we should prepare a project proposal on the wiki and ask to add it to next TSG meeting for approval. -Sivan On Mon, Sep 20, 2010 at 11:03 PM, Sivan Greenberg si...@omniqueue.com wrote: On Mon, Sep 20, 2010 at 5:59 PM, Matti Airas matti.p.ai...@nokia.com wrote: On 20.09.2010 17:41, ext Per Åstrand wrote: Hi! I've been checking the repositories for python support. AFAICT the compliance doc at http://www.pyside.org/2010/09/meegotouch-bindings-alpha-available/ requires an application to only use packages in the officail repos to be meego compliant IMHO it makes sense to also include python bindings for QT (pyside) to be able to write meego compliant applications in python. pyside project seems to be tracking QT and meego well (http://www.pyside.org/2010/09/meegotouch-bindings-alpha-available/). Also kind of strange that bindings for gtk is in the repo, but not for QT... Hi Per, We (as in the PySide team) are definitely planning on providing the PySide packages on MeeGo in the near future. However, since we're just ramping up our MeeGo activities (still waiting for the OBS accounts to be created, etc), I have to say I've been rather ignorant about the details of the contribution process. In particular, I'm interested about the proper channels for contributing to the existing Python distribution. What is the formal project the current Python packages live in? Should we contribute there or should we make a proposal to the TSG to create a proper MeeGo Python project which could act as an umbrella for all Python-related activities in MeeGo? Matti, maybe we can ask Dawn to add this item for tomorrow's TSG meeting so it can be discussed and agreed upon already? -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Upstart in MeeGo?
Sorry for the ignorance but what is MeeGo using at the moment? I've had a lot of issues with upstart on Ubuntu so if there an alternative which is even what's now in MeeGo locally developed, it could probably stick. -Sivan On Sat, Sep 18, 2010 at 6:47 PM, Arjan van de Ven ar...@linux.intel.com wrote: On 9/18/2010 8:46 AM, Felipe Contreras wrote: Huh? I think nowadays upstart can be considered deprecated: http://0pointer.de/blog/projects/systemd.html just because someone is doing an experiment doesn't mean other things are deprecated Ok, I thought that was obvious, but I guess time will tell. it's far from obvious... really. systemd has design issues which have to be hashed out obviously (Fedora is punting on it for F14 for a reason) upstart has license/contribution issues which are not pretty Fedora is putting it on F14 because F13 was practically out when systemd was announced. Fedora is NOT using systemd in 14 ..only in 15 maybe MeeGo currently has a highly customized boot process, optimized for speed. At this point, if we were to switch, upstart matches that closer than systemd does so upstart would be a more logical change if we were to change. If you want speed, you need a customized boot process in traditional yes I know a thing or two about boot speed so far MeeGo is one of the fastest booting Linux OSes in the market init systems (sysvinit, upstart), because everything gets started, so then you need to pick and choose what really gets started, and when. that's regurgitating systemd propaganda... but that does not make it true ;) But systemd turns the problem around; nothing gets started, unless it's really used, so there's less need to customize (if any). systemd turns it into a worst case problem unfortunately, because now you hit the start latency ALL THE TIME. this is what I meant with design issues; systemd's design isn't going to give you a super fast boot. Now maybe they'll fix it sometime in the future but today it makes systemd entirely uninteresting for booting fast. yes it'll boot faster than the really really slow existing Fedora, but that's not an interesting benchmark point. the benchmark point should be the state of the art, not the worst of the industry. It's ok to have multiple competing technologies; that's one of the ways innovation happens in open source.. competition. Sure, but we are not using any, so I don't see why we should assume that upstart will be used. I think both approaches need to be carefully and equally considered. oh trust me we are looking at all options, very very carefully. That's why I said that upstart currently is more likely than systemd, but frankly, for 1.2 we might also just stick with what we have now.. it works and is fast. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Looking for a right way to create daemons on MeeGo
On Fri, Sep 3, 2010 at 10:22 PM, Auke Kok auke-jan.h@intel.com wrote: On 09/03/10 09:42, Epshteyn, Eugene wrote: Are there instructions for MeeGo similar to what exists for Debian (http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html) about setting up daemons? I have some software that needs to run as a daemon, and I would like to learn what's the right way to do that on MeeGo (e.g., creating separate user/group, adding to init.d, what's a good place for the daemon to dump log files, etc.) MeeGo currently assumes no new system-wide daemons will be added, we prefer that services are started on-demand where possible, and/or run from the user's session instead of running system-wide. D-bus activation is a popular and well-proven method for doing this. What's the proper canonical way to use dbus in such way to trigger local service startup ? -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Multitouch support vs. New Ubuntu Multitouch API
Hey Claudio, I found some interesting points here: http://blogs.forum.nokia.com/blog/ville-vainios-forum-nokia-blog/2010/08/13/mtf_docs_on_web The interesting point being this can be tested on N900, as Ville explains. -Sivan 2010/8/18 Cláudio Sampaio pat...@gmail.com: Hi. I've search through meego's site for multitouch and couldn't find anything relating to its multitouch support. How multitouch support in Meego relates to that new Multitouch stack to be released by Canonical? http://lwn.net/Articles/400455/rss Is it done differently? Can Meego actually use Canonical's framework? If this is not the right list for this kind of question, I apologize. If anyone can point me to the right place, if not this one, I'd be glad. Thanks! -- Cláudio Patola Sampaio IRC: ptl - Yahoo: patolaaa Campinas, SP - Brazil. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Multitouch support vs. New Ubuntu Multitouch API
On Wed, Aug 18, 2010 at 7:18 PM, Thiago Macieira thi...@kde.org wrote: On Wednesday 18 August 2010 13:10:23 Cláudio Sampaio wrote: Hi. I've search through meego's site for multitouch and couldn't find anything relating to its multitouch support. How multitouch support in Meego relates to that new Multitouch stack to be released by Canonical? http://lwn.net/Articles/400455/rss Is it done differently? Can Meego actually use Canonical's framework? It's done completely differently. It uses the Qt multitouch and gesture support only. It's built-in. So MTF is wrappers around Qt's multi touch and gesture api? What does built-in here means? -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [QA] Looking for input on implementing automated image installation
I think as proposed in the bug report, there should be a way to trigger dd (and bunzip2) with a command or script under busybox to received bytes of the netcat chosen port. I may be wrong here, but setting NFS on the busybox system could introduce dependency overhead and adds filesystem abstraction over the wire. The image is really over 1G ? -Sivan 2010/8/18 Wang, Jing J jing.j.w...@intel.com: Take netbook for example, by PXE, it is easy to boot the customized initrd and run netcat to listen command. But before write image, we need make clear how to get this image, which is an over 1G stuff. What I can think about is NFS, any other poi nt? -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Timo H?rk?nen Sent: Wednesday, August 18, 2010 9:10 PM To: meego-dev@meego.com Subject: [MeeGo-dev] [QA] Looking for input on implementing automated image installation Hi The QA Test tools team is thinking of ways to implement automated way of installing images into different targets. We're thinking currently to implement it as proposed by Carsten in bugzilla [1]. We would like to hear if you have any comments or alternative ideas on how it could be implemented. [1] http://bugs.meego.com/show_bug.cgi?id=4887#c9 -Timo -- Timo Härkönen MeeGo QA Tools ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] web-enabled
I think that it refers to the fact that it is very easy to write apps in Qt that use the internet, or allow web browsing and web serving consumption. But that's my guess. Sivan On Tue, Aug 10, 2010 at 1:46 PM, Nicola De Filippo nic...@nicoladefilippo.it wrote: Him here http://meego.com/developers/meego-api i read Using Qt, you can write web-enabled applications, what do you mean? Nicola ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] missing an instruction bit
Hi list, I am just trying to follow the MeeGo QEMU image instructions, but when trying to start the image: si...@sivan-desktop:~/n$ ./qemugl_cmd.sh meego-handset-ia32-1.0.80.9.20100706.1-sdk-pre0729/meego-handset-ia32-1.0.80.9.20100706.1-sdk-pre0729.raw Could not access KVM kernel module: No such file or directory So, if KVM is necessary, maybe we should add this instruction bit to the wiki? I followed it as a simple user, not checking if installing qemu from my vendor would solve this dependency, I think it is reasonable to assume that new users trying to test this will do the same. Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] missing an instruction bit
So , now I tried installing qemu from the lucid repos, and some kvm in name packages were installed: Get:1 http://de.archive.ubuntu.com/ubuntu/ lucid/main libaio1 0.3.107-3ubuntu2 [9,512B] Get:2 http://de.archive.ubuntu.com/ubuntu/ lucid/main seabios 0.5.1-0ubuntu2 [48.2kB] Get:3 http://de.archive.ubuntu.com/ubuntu/ lucid/main vgabios 0.6c-2ubuntu1 [78.5kB] Get:4 http://de.archive.ubuntu.com/ubuntu/ lucid-updates/main qemu-common 0.12.3+noroms-0ubuntu9.2 [30.1kB] Get:5 http://de.archive.ubuntu.com/ubuntu/ lucid-updates/main qemu-kvm 0.12.3+noroms-0ubuntu9.2 [2,556kB] Get:6 http://de.archive.ubuntu.com/ubuntu/ lucid-updates/universe qemu 0.12.3+noroms-0ubuntu9.2 [13.9kB] Still, running the image gives the same KVM missing error, going to try and see if a different kernel image is needed. On Tue, Aug 10, 2010 at 5:44 PM, Sivan Greenberg si...@omniqueue.com wrote: Hi list, I am just trying to follow the MeeGo QEMU image instructions, but when trying to start the image: si...@sivan-desktop:~/n$ ./qemugl_cmd.sh meego-handset-ia32-1.0.80.9.20100706.1-sdk-pre0729/meego-handset-ia32-1.0.80.9.20100706.1-sdk-pre0729.raw Could not access KVM kernel module: No such file or directory So, if KVM is necessary, maybe we should add this instruction bit to the wiki? I followed it as a simple user, not checking if installing qemu from my vendor would solve this dependency, I think it is reasonable to assume that new users trying to test this will do the same. Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] missing an instruction bit
r...@sivan-desktop:~# modprobe kvm-intel FATAL: Error inserting kvm_intel (/lib/modules/2.6.32-22-generic-pae/kernel/arch/x86/kvm/kvm-intel.ko): Operation not supported I didn't check if the device node was created since this error msg :) What's next? -Sivan On Tue, Aug 10, 2010 at 5:54 PM, Ameya Palande ameya.pala...@nokia.com wrote: On Tue, 2010-08-10 at 16:47 +0200, ext Sivan Greenberg wrote: So , now I tried installing qemu from the lucid repos, and some kvm in name packages were installed: Get:1 http://de.archive.ubuntu.com/ubuntu/ lucid/main libaio1 0.3.107-3ubuntu2 [9,512B] Get:2 http://de.archive.ubuntu.com/ubuntu/ lucid/main seabios 0.5.1-0ubuntu2 [48.2kB] Get:3 http://de.archive.ubuntu.com/ubuntu/ lucid/main vgabios 0.6c-2ubuntu1 [78.5kB] Get:4 http://de.archive.ubuntu.com/ubuntu/ lucid-updates/main qemu-common 0.12.3+noroms-0ubuntu9.2 [30.1kB] Get:5 http://de.archive.ubuntu.com/ubuntu/ lucid-updates/main qemu-kvm 0.12.3+noroms-0ubuntu9.2 [2,556kB] Get:6 http://de.archive.ubuntu.com/ubuntu/ lucid-updates/universe qemu 0.12.3+noroms-0ubuntu9.2 [13.9kB] Still, running the image gives the same KVM missing error, going to try and see if a different kernel image is needed. Can you try: modprobe kvm-intel / kvm-amd (depending on your cpu) and check whether you get /dev/kvm created? In case if /dev/kvm is not getting created then check the error in dmesg | tail Hope this helps! Cheers, Ameya. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] missing an instruction bit
I see this in dmesg: [5356544.289562] kvm: disabled by bios [5357200.226568] kvm: disabled by bios [5357213.770607] kvm: disabled by bios [5357434.252870] kvm: disabled by bios So KVM can be disabled in bios by disabling the hardware virtualization support? On Tue, Aug 10, 2010 at 5:57 PM, Sivan Greenberg si...@omniqueue.com wrote: r...@sivan-desktop:~# modprobe kvm-intel FATAL: Error inserting kvm_intel (/lib/modules/2.6.32-22-generic-pae/kernel/arch/x86/kvm/kvm-intel.ko): Operation not supported I didn't check if the device node was created since this error msg :) What's next? -Sivan On Tue, Aug 10, 2010 at 5:54 PM, Ameya Palande ameya.pala...@nokia.com wrote: On Tue, 2010-08-10 at 16:47 +0200, ext Sivan Greenberg wrote: So , now I tried installing qemu from the lucid repos, and some kvm in name packages were installed: Get:1 http://de.archive.ubuntu.com/ubuntu/ lucid/main libaio1 0.3.107-3ubuntu2 [9,512B] Get:2 http://de.archive.ubuntu.com/ubuntu/ lucid/main seabios 0.5.1-0ubuntu2 [48.2kB] Get:3 http://de.archive.ubuntu.com/ubuntu/ lucid/main vgabios 0.6c-2ubuntu1 [78.5kB] Get:4 http://de.archive.ubuntu.com/ubuntu/ lucid-updates/main qemu-common 0.12.3+noroms-0ubuntu9.2 [30.1kB] Get:5 http://de.archive.ubuntu.com/ubuntu/ lucid-updates/main qemu-kvm 0.12.3+noroms-0ubuntu9.2 [2,556kB] Get:6 http://de.archive.ubuntu.com/ubuntu/ lucid-updates/universe qemu 0.12.3+noroms-0ubuntu9.2 [13.9kB] Still, running the image gives the same KVM missing error, going to try and see if a different kernel image is needed. Can you try: modprobe kvm-intel / kvm-amd (depending on your cpu) and check whether you get /dev/kvm created? In case if /dev/kvm is not getting created then check the error in dmesg | tail Hope this helps! Cheers, Ameya. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] missing an instruction bit
Hi Fathi ! On Tue, Aug 10, 2010 at 6:01 PM, fathi.bou...@nokia.com wrote: I assume you talk about QEMU GL from MeeGo SDK? This page: http://wiki.meego.com/MeeGo_SDK_with_QEMU It is documented: http://wiki.meego.com/MeeGo_SDK_Building_QEMU_Tools http://wiki.meego.com/MeeGo_SDK_with_QEMU http://wiki.meego.com/MeeGo_SDK_Graphics_Acceleration Without getting into the details of the first link, I want the don't-to-it-yourself first :) as in having made binaries I can just run without building myself. Gonna check the other 2 see if they can help me. Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] missing an instruction bit
Great, so it is mentioned in here: http://wiki.meego.com/MeeGo_SDK_Graphics_Acceleration . Can we quick link this from the page where it explains how to execute the image as a quick tip if it fails like it did for me? -Sivan On Tue, Aug 10, 2010 at 6:28 PM, Sivan Greenberg si...@omniqueue.com wrote: note that I installed the deb for qemu-gl and didn't build anything myself. On Tue, Aug 10, 2010 at 6:27 PM, Sivan Greenberg si...@omniqueue.com wrote: Hi Fathi ! On Tue, Aug 10, 2010 at 6:01 PM, fathi.bou...@nokia.com wrote: I assume you talk about QEMU GL from MeeGo SDK? This page: http://wiki.meego.com/MeeGo_SDK_with_QEMU It is documented: http://wiki.meego.com/MeeGo_SDK_Building_QEMU_Tools http://wiki.meego.com/MeeGo_SDK_with_QEMU http://wiki.meego.com/MeeGo_SDK_Graphics_Acceleration Without getting into the details of the first link, I want the don't-to-it-yourself first :) as in having made binaries I can just run without building myself. Gonna check the other 2 see if they can help me. Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] PyQt
Dear Fathi, That was not my intention, well, in better- I meant heading to bind some new libs that did not exist when PyQt was created and thought of a couple of features that I will *personally* very much like in PySide once their finished, like this[0] one for example. Sorry for mis-phrasing! Indeed, there are pros/cons to each and one should use the best tool for the job (tm) :-) Not to mention that PyQt is probably more spread and is heavily used all over since it has been around for longer. Thus could be easier to get going with since there are repository packages and tons of material to get started with both online and printed. This also shows promise to enable to port back and forth at relative ease[1]. [0] http://www.pyside.org/docs/pseps/psep-0102.html [1] http://stackoverflow.com/questions/1297660/pyside-vs-pyqt Fathi, please take liberty to make me stand corrected if I'm wrong and note my notes are just in-my-experience recommendations and should not be considered as authoritative advice. Cheers, Sivan On Mon, Jul 26, 2010 at 9:39 AM, fathi.bou...@nokia.com wrote: Hi, If you want the PySide bindings which are supposed to be a better, more complete version of the original Qt bindings, Please, don't spread FUD but give facts. We have 2 competitors for the Python bindings. Both have pros/cons and both try to push their implementation. I let the reader to search the relevant information to make his own choice. Cheers, Fathi ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] PyQt
Atilla, On Mon, Jul 26, 2010 at 12:30 PM, Attila Csipa me...@csipa.in.rs wrote: Just a smallish note from someone who follows PyQt development fairly closely - I would not be surprised if those new libs (or at least a major subset of them) popped up as supported under PyQt. My OBS-foo is not yet strong enough to allow me to tinker with bindings under MeeGo, but it is on my (rather longish) to-do list, as, though some might disagree, I still feel there is some advantage of having two bindings. OTOH I do think MeeGo should (have) push(ed) for full platform level python availability from day 1, picking a preferred/official binding if necessary. Just to second that- and I know we've already discussed this on IRC, but I strongly support the idea to have full platform support for Python, to the extend of reaching the OVI store and more monetary (but not necessary paid) style distribution channels. I actually agree with every word , and couldn't say this better. The issue is I guess with maintainer ship, who when and how? (having two frameworks strictly speaking suggests 2 maintainership efforts?) Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] PyQt
Yes I would expect it'd be much the same way it is down for Maemo, note that you might need to download and install source versions of the tools since there might not be RPMs for that at this time. [1] http://esbox.garage.maemo.org/2nd_edition/installation.html [2] http://www.forum.nokia.com/info/sw.nokia.com/id/c05693a1-265c-4c7f-a389-fc227db4c465/Maemo_5_SDK.html [3] http://www.pyside.org/downloads/ If you want the PySide bindings which are supposed to be a better, more complete version of the original Qt bindings, you need to consult the download page[3] for the PySide project. You can also attempt development inside the MeeGo SDK given you build the required dependencies there, in Maemo the packages are available from extra-devel. I hope this helps (thanks to Renato and Luca for originally posting this). Sivan On Mon, Jul 26, 2010 at 6:15 AM, Mark S. Townsley mstowns...@gmail.com wrote: Hi: I am looking at developing for MeeGo and I know C/C++ is one choice. Is it possible to develop MeeGo application using Python/PyQt? thanks Mark ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] sdk
On Sat, Jul 3, 2010 at 11:58 PM, Robin Burchell virot...@viroteck.net wrote: Hi Nicola, On Sat, Jul 3, 2010 at 9:43 PM, Nicola De Filippo nic...@nicoladefilippo.it wrote: Hi, i would use the sdk for Meego (phone), but the SDK Currently, the simulator runs only on host systems with an Intel integrated graphics controller. It does not run with ATI or NVIDIA graphics controllers; i have an nVidia card, there is a way to be able to use the SDK and the simulator on my pc? Assuming by SDK you mean the chroot, see: http://forum.meego.com/showthread.php?t=767 Robin, maybe this process of starting the GUI just needs to be done by the SDK or might it be more involved to have it fixed in the SDK? Since there are so many nVidia based boxes out there, I think that officially supporting it is a major thing and should be fixed ASAP. Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] MeeGo UX in VirtualBox
List, After googling around I saw there is no authoritative page with proper instructions to get up MeeGo UX (the complete UX , not just X booting or a very lightweight window manager) under VirtualBox for either Intel or nVidia host GFX chips. I suggest anybody who had success doing so, put his findings and instructions on this page[0] so we can later on tidy it up and have a canonical place to start. Getting the Handset UX working there as well could be very helpful for development for those who don't have a MeeGo compatible handset device. Thanks, Sivan [0]: http://wiki.meego.com/MeeGo_1.0_Netbook_VirtualBox ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] developer hardware mobile from nokia needed
On Sat, Jul 3, 2010 at 7:12 PM, Stone Mirror le...@shugendo.org wrote: Agreed: for a phone form factor, the N900 is what it is at the moment, and if costs what it costs. In comparison with other comparable development platforms, the N900 is quite reasonably priced, I've found. Indeed. My findings as well :-) Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] State of N900 image after Handset Day 1
I would dual boot it on the N900 if you don't have any other device you can fall back to if you need critical phone functionality. But, it is interesting to know the level of openness this release carries. Sivan 2010/7/1 Freyr Magnússon freyr.magnus...@gmail.com: I'm looking for some clarification regarding the current state of the N900 images. With the introduction of handset day 1 it looks like the N900 can function nicely as a phone. Can we install it now and expect decent battery life? Do we still need a special closed image for proper functionality? Where can I find the correct image and installation instructions? I really want to switch over to meego so I can start hacking on my own handset while still having a functional phone :) Freyr ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Tomorrow, sorry .. RE: State of N900 image after Handset Day 1
Thanks Harri for the update! Completely understandable. Any great project starts with a bit of hassle, no one needs to be blamed =) BR, Sivan On Thu, Jul 1, 2010 at 12:49 AM, harri.hakuli...@nokia.com wrote: Hello, There will be more information tomorrow how to get image for N900. We forgot to do one simple thing in time after some hassle, blaim me if you want to. But, please remember that this is Day 1 image, Work In Progress. So don't set your expectations too high. Openess of the image is on the same level than in the earlier ones. Br, //Harri From: meego-dev-boun...@meego.com [meego-dev-boun...@meego.com] On Behalf Of ext Sivan Greenberg [si...@omniqueue.com] Sent: Thursday, July 01, 2010 12:41 AM To: Development for the MeeGo Project (discussion list) Subject: Re: [MeeGo-dev] State of N900 image after Handset Day 1 I would dual boot it on the N900 if you don't have any other device you can fall back to if you need critical phone functionality. But, it is interesting to know the level of openness this release carries. Sivan 2010/7/1 Freyr Magnússon freyr.magnus...@gmail.com: I'm looking for some clarification regarding the current state of the N900 images. With the introduction of handset day 1 it looks like the N900 can function nicely as a phone. Can we install it now and expect decent battery life? Do we still need a special closed image for proper functionality? Where can I find the correct image and installation instructions? I really want to switch over to meego so I can start hacking on my own handset while still having a functional phone :) Freyr ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Qt Mobility says Hello MeeGo World!
On Tue, Jun 22, 2010 at 6:22 AM, gerard.lough...@nokia.com wrote: Only last week we made a program decision to adopt MeeGo as our default development environment for Qt Mobility development. This I hope is great news for all of you. Our plan will involve porting all of the Qt Mobility delivered APIs to the MeeGo platform. The activity will commence gradually at first, but we anticipate it will to become the main focus of the Qt Mobility team toward the 3rd and 4th quarter of this year. What sort of porting are you going to undertake to make it available on MeeGo ? What sort of work and coding is anticipated, I mean other than rebuilding and fixes for ABI compatibility with the toolchain? Are there going to be any new features added to the Qt Mobility due to the fact that you're using MeeGo as your development environment ? This is indeed exciting times and I very much look forward to some excellent success stories :) That is great news. I am sure it will streamline and make the availability of this innovative framework on the MeeGo platform and will save us all the app developers time and effort when starting to develop using the framework, building on your experience and tackle with the system. Kind regards, Gerard. Pleased to read your Gerard, nice to see the transparency flowing in. Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Annoying behavior with current way to answer a phone call on Maemo, hope for improvement for N900.
Dear List, I hope this is a proper forum to bring this up - but I have been annoyed with the fact that once a phone call is arriving in N900 (currently with Maemo Fremantle) there is a rather large room for error when you need to take the device out of a pocket or a backpack's drawer. Since the UI is immediately ready for touch, you usually make an accidental press on the 'RED' button and reject the call from the other party. If you were expecting an important call from overseas where it is hard to trace or sometimes the number is blocked it creates a problem as you can't get back to the other party. Let us note that the 'RED' button is very close to the edge of the touch scree, so if you pull the device backward from a pocket or a backpack bag you will most probably reject the call since you have nowhere else to grab the device with, before you've had a chance to see the identify of the caller. I propose we have something like current S60 (for me on the N97 mini) UI for reciving a call in which you have to swipe your finger over a green button to answer the call, and rejecting is not possible until you've unlocked using the lock/unlock button which in the N900 is the small slide handle on the side of the device. If this is nor the place or the Handheld UX team has already solved this, I apologize for the noise, but if so , please let us review the solution and think how it will behave in the field :-) Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Annoying behavior with current way to answer a phone call on Maemo, hope for improvement for N900.
Maybe I should file this is a MeeGo bug? Since next version of Maemo is actually MeeGo I thought it'd be at least somewhat appropriate to bring attention to it here before I file a usability bug on ... actually where? MeeGo bugtracker? Maemo's bug tracker? Sivan On Thu, Jun 17, 2010 at 6:58 PM, Warren Baird wjba...@alumni.uwaterloo.ca wrote: On Thu, Jun 17, 2010 at 11:54 AM, Sivan Greenberg siv...@gmail.com wrote: Dear List, I hope this is a proper forum to bring this up - but I have been annoyed with the fact that once a phone call is arriving in N900 (currently with Maemo Fremantle) there is a rather large room for error when you need to take the device out of a pocket or a backpack's drawer. Also not sure this is the proper venue --- but +1 to the annoyance you mention. Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
