Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
On Tue, 2011-10-04 at 13:58 +0200, Jeremiah Foster 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? OBS is built with packaging in mind, so it builds packages locally and on servers in a sanitized environment. Scratchbox may be polluted by whatever packages a developer has installed and makes dependency tracking a bit harder IMO. 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. OBS may not offer anything more or less than Launchpad or buildd, but it is completely open source and it targets many more distributions than Launchpad or buildd do. 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. 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. 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. Regards, Jeremiah ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev 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
Other reasons for keeping OBS include trying to change as little as possible from what MeeGo has done. So those vendors that are possibly already accustomed and are currently using MeeGo facilities, like OBS. Can easily migrate to Mer. There really isn't much point in debating this, Carsten has made his decision ... Thanks, Tom. On Tue, 2011-10-04 at 14:19 +0200, Jeremiah Foster wrote: On Tue, Oct 4, 2011 at 2:08 PM, Tom Swindell t.swind...@rubyx.co.uk wrote: On Tue, 2011-10-04 at 13:58 +0200, Jeremiah Foster 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? OBS is built with packaging in mind, so it builds packages locally and on servers in a sanitized environment. Scratchbox may be polluted by whatever packages a developer has installed and makes dependency tracking a bit harder IMO. I agree that working in a dirty chroot is problematic. That is why there is pbuilder and cowdancer. 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. OBS may not offer anything more or less than Launchpad or buildd, but it is completely open source and it targets many more distributions than Launchpad or buildd do. And more package formats, processor virtualization, per-package compiler flags, and a mock version control tool, etc. But all these things can mean that your package will not work with other distros and then we are back to everyone doing their own thing. How does that help move free software forward? It doesn't, it only encourages the silo effect and Not Invented Here. Before it was just big companies that could create their own Linux distros (before that everyone had their bespoke UNIX distro) nowadays fragmentation is brought to you by every Tom, Dick and Harry with an OBS login. I've been down the fragmentation road before. It always ends with retracing your path back to the main highway. Regards, Jeremiah ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] D-Bus APIs on QML
Hi, Currently, unfortunately, there is no way to integrate with dbus from QML directly. The easiest way is to write a C++ wrapper which exposes your QML friendly methods and handles making the dbus calls. I appreciate that this isn't ideal if you're not a C++ dev and are trying to learn QML only, but there is currently no other way. Cheers, Tom. - Original message - Hi List! What is the easiest way to use D-Bus APIs on QML ? I've seen this article on the ineternet: http://minimoesfuerzo.org/2010/03/30/playing-qml-and-dbus/ But It looks quite complicate. It need a lot of preparation works (xml desc - qdbusxml2cpp - register into qml). Is there way to directly use D-Bus API by using Javascript on QML code ? (Actually, I expected that javascript interface such as like python-dbus.) Best regards, JC ___ 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] D-Bus APIs on QML
- Original message - I would suspect that QML only is not a great start; while QML is great for writing some very basic apps once you want something fancy you very likely end up doing C++ work Yes, I completely agree. Otoh, the fact is a lot of potential developers seem to think that they can use pure QML to build their apps. I'm hoping one day that QML through the community creating plugins etc will make QML much more useful, maybe someone should think about setting up something like cpan or rubygems for QML C++ plugins. Best to think of these things now rather than rush it later. ___ 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 vs Harmattan; Tablet vs Handset - (was: Re: Qt/QML or Meego Touch Framework?)
Though I agree with most of what you're saying, I think a lot of app developers, at least the professional kind, will probably end up using pure QML based UXs tailored to their apps. MeeGo/Qt/Harmatten Components I suppose give certain developers/applications the ability to camouflage themselves into the UX, which is indeed a good thing, and, if this is only really happening on the QML layer, then it's arguably not a huge deal as it should just be the thin UX layer on top of the proper application code, whether in Python, JavaScript or Qt/C++, etc. I think from my perspective, I'd probably be writing several QML UXs for my apps anyway, one for tablets (large screen) and another for handsets, the main reason being, though a perfect UX designed in QML could be scalable across all screen dimensions. Separating the paradigms into seperate QML UX profiles is just a lot simpler and probably a lot less of a time investment. That being said, Qt Components MeeGo UX Components should really be combined, and I hope they do. As I understand it Harmatten UX and MeeGo Touch UX are essentially the same thing. It's just the recent MeeGo UX Components have nothing to do with MTF, this will make theming double the effort, where as using Qt Components, which should be using MTF/Harmatten theming, means that 1.2 MeeGo is at least compatible with Harmatten if Qt Components is used ... But yeah .. Very confusing :( On Tue, 2011-05-03 at 13:23 +0100, Robin Burchell wrote: On 03/05/11 09:21, kate.alh...@nokia.com wrote: Yes, they are in Harmattan. Does they have real-world use just depends that do you like offer optimum user experience for certain class of devices. Intel components offers best match with Intel's tablet UX, Harmattan components offer best user experience for handset. Without going into details of just how wrong I think this is, a short version of my opinion is: if you think that further fracturing a currently fledgling and immature developer community into arbitrary device categories after the last ~5 year's worth of disasters of rewrites and fragmentation is a good approach, we'll have to agree to disagree. I don't think hobbyists will be too happy to find out they have to rewrite the basics for every seperate device, either, given that is the #1 thing I hear Android developers complaining about. The netbook/handset/* differences certainly haven't done much except to confuse people, from my time watching #meego/forums/mailing lists. When you already have less appeal to developers, the last thing you want to do is to make it harder for them to write applications for you. And you want it easy to write applications that target a lot of devices. It's utter insanity to want to fragment what was finally starting to become a coherent and appealing developer story. -- Robin Burchell http://rburchell.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Qt/QML or Meego Touch Framework?
On Tue, 2011-05-03 at 16:00 +0300, Adrian Yanes wrote: libmeegotouch has been deprecated by its creators (Nokia) for almost a year now However several features implemented in MTF still missing in Qt/QML. Even if the main decision is to move to Qt/QML, some technologies implemented in MTF are good and would be an advantage to keep them on MeeGo. Out of curiosity, such as? :) I was under the understanding that the way things were going in Qt is through Scene Graph and MTF wont take advantage of that? But QML will. ___ 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] [ANNOUNCE] First commit of QML based MeeGo Dialer application.
The QML dialer has made it to my public OBS: http://repo.pub.meego.com/home:/tswindell:/branches:/MeeGo.com:/Trunk/Project_DE_Trunk_Testing_standard/ Thanks to Carsten for help getting packaging/obs to working for me. Please test and let me know what you think. To make the dialer start on boot you need to add the below line to /etc/prestart/nokia.conf: application name=dialer service=com.meego.dialer priority=1/ Then restart your device and you should be able to receive calls straight away, even without the Call UI open! :D Thanks, Tom. On Sun, 2011-05-01 at 14:00 +0100, Tom Swindell wrote: Hello All, For those interested, made a few screenshots of the app on the Nokia N900, running the N900 MeeGo 1.2 DE Alpha release: http://stage.rubyx.co.uk/meego/screenshots/handset/ Enjoy! Tom Swindell (AKA alterego) On Sat, 2011-04-30 at 16:24 +0100, Tom Swindell wrote: I've been working over the past few months, when I could, on replacing the current MeeGo Touch Framework based user interface of the reference dialer application with a QML based user experience. I've hit a good state to start publishing my work and have published and will continue to update a QML branch of the reference dialer on gitorious.org Currently my QML dialer branch can make and receive calls, if set up correctly, a handset can receive calls from power on. This is something that mainly Shane Bryan (sabotage) and others have been working on in the headless (now master) branch of the meego-handset-dialer reference project: (https://meego.gitorious.org/meego-handset-ux/meego-handset-dialer) Anyhow, the source for my branch can be found here: https://meego.gitorious.org/~tswindell/meego-handset-ux/qml-meego-handset-dialer All input and comments welcome. There is certainly still quite a bit of work that needs to be done; implementing second call and group call UX as well as modify history, contacts and favourite contacts data models so they expose QML friendly interfaces and can be used correctly in QML list views. Enjoy! Tom Swindell (AKA alterego) ___ MeeGo-handset mailing list meego-hand...@lists.meego.com http://lists.meego.com/listinfo/meego-handset ___ MeeGo-handset mailing list meego-hand...@lists.meego.com http://lists.meego.com/listinfo/meego-handset ___ 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] [ANNOUNCE] First commit of QML based MeeGo Dialer application.
Hello All, For those interested, made a few screenshots of the app on the Nokia N900, running the N900 MeeGo 1.2 DE Alpha release: http://stage.rubyx.co.uk/meego/screenshots/handset/ Enjoy! Tom Swindell (AKA alterego) On Sat, 2011-04-30 at 16:24 +0100, Tom Swindell wrote: I've been working over the past few months, when I could, on replacing the current MeeGo Touch Framework based user interface of the reference dialer application with a QML based user experience. I've hit a good state to start publishing my work and have published and will continue to update a QML branch of the reference dialer on gitorious.org Currently my QML dialer branch can make and receive calls, if set up correctly, a handset can receive calls from power on. This is something that mainly Shane Bryan (sabotage) and others have been working on in the headless (now master) branch of the meego-handset-dialer reference project: (https://meego.gitorious.org/meego-handset-ux/meego-handset-dialer) Anyhow, the source for my branch can be found here: https://meego.gitorious.org/~tswindell/meego-handset-ux/qml-meego-handset-dialer All input and comments welcome. There is certainly still quite a bit of work that needs to be done; implementing second call and group call UX as well as modify history, contacts and favourite contacts data models so they expose QML friendly interfaces and can be used correctly in QML list views. Enjoy! Tom Swindell (AKA alterego) ___ MeeGo-handset mailing list meego-hand...@lists.meego.com http://lists.meego.com/listinfo/meego-handset ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] [ANNOUNCE] First commit of QML based MeeGo Dialer application.
I've been working over the past few months, when I could, on replacing the current MeeGo Touch Framework based user interface of the reference dialer application with a QML based user experience. I've hit a good state to start publishing my work and have published and will continue to update a QML branch of the reference dialer on gitorious.org Currently my QML dialer branch can make and receive calls, if set up correctly, a handset can receive calls from power on. This is something that mainly Shane Bryan (sabotage) and others have been working on in the headless (now master) branch of the meego-handset-dialer reference project: (https://meego.gitorious.org/meego-handset-ux/meego-handset-dialer) Anyhow, the source for my branch can be found here: https://meego.gitorious.org/~tswindell/meego-handset-ux/qml-meego-handset-dialer All input and comments welcome. There is certainly still quite a bit of work that needs to be done; implementing second call and group call UX as well as modify history, contacts and favourite contacts data models so they expose QML friendly interfaces and can be used correctly in QML list views. Enjoy! Tom Swindell (AKA alterego) ___ 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] QMainWindow flags
In addition some source code wouldn't go amiss :) - Original message - On Mon, 25 Apr 2011, Vincent Yau wrote: Hi: I have an app written in Qt C++. It seg'ed fault and I finally traced it down to QMainWindow::setWindowFlags(). It looks like it can seg fault in whatever flags I put in. It looks like there are some DBus objects that have changed? Any tip/pointer on what this error mean will be much appreciated. Sounds similar to Bug 14812. If you start your app with `-style plastique` does it still crash? -gabriel https://bugs.meego.com/show_bug.cgi?id=14812 ___ 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] PATCH: OSC local building and armv8el architecture usage issue.
Below is a patch for /usr/lib/build/Build.pm to make local builds work
properly when using the armv8el architecture to select through
changetarget directive the armv7hl-meego-linux compilation target.
--- /usr/lib/build/Build.pm.bk 2011-04-17 16:32:58.945575001 +0100
+++ /usr/lib/build/Build.pm 2011-04-17 16:33:35.675574999 +0100
@@ -29,9 +29,9 @@ sub import {
my $std_macros = q{
%define nil
%define ix86 i386 i486 i586 i686 athlon
-%define arm armv4l armv4b armv5l armv5b armv5el armv5eb armv5tel
armv5teb armv6el armv6eb armv7el armv7eb
-%define arml armv4l armv5l armv5tel armv5el armv6el armv7el
-%define armb armv4b armv5b armv5teb armv5eb armv6eb armv7eb
+%define arm armv4l armv4b armv5l armv5b armv5el armv5eb armv5tel
armv5teb armv6el armv6eb armv7el armv7eb armv8el armv8eb
+%define arml armv4l armv5l armv5tel armv5el armv6el armv7el armv8el
+%define armb armv4b armv5b armv5teb armv5eb armv6eb armv7eb armv8eb
%define sparc sparc sparcv8 sparcv9 sparcv9v sparc64 sparc64v
};
my $extra_macros = '';
___
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] porting from DirectX 9.0c to OpenGL ES2.0??
It may be worth your time looking for how to port from DirectX to standard OpenGL 2/3 using the shaders over fixed pipeline functionality. As GLES2 is effectively a subset of that and there's probably a lot more information on doing that on the web. Cheers, Tom. - Original message - Hi, I need to get a feel for what's involved generally porting from DirectX 9.0c (shader models 2.0 and 3.0) to OpenGL ES. Can anyone help? Thanks Costas - Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Compatible device with EGL/GLX support
The N900 does indeed support EGL/GLES development. On Mon, 2011-01-24 at 12:27 -0800, Andy Ross wrote: On 01/24/2011 12:48 AM, Oleg Romashin wrote: Is there are any Meego Compatible device where I can develop EGL/GLX application with Real drivers support (non-mesa)? Recent pinetrail handset images are installing the Mesa EGL libraries and targetting their Qt builds at it. That supports Real drivers on Atom N4x0 netbooks. I believe the same is true for the N900 builds, which are using the sgx GLES stack. Andy ___ 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
