[MeeGo-dev] MeeGo mailing list shutdown
Dear participants As part of the MeeGo infrastructure ramp down, we will begin to shut down most mailing lists. In the coming days, all mailing lists at lists.meego.com will be shut down, except for the following: NameReason meego-dev general discussions meego-commits automated emails from builds still being sent there meego-security security concerns The mailing list archives will be frozen too, but not deleted until the main infrastructure shuts down completely. Some mailing lists have been archived publicly by other services, such as: http://gmane.org/find.php?list=meego http://www.mail-archive.com/find.php?q=meego In addition, we'd like to ask everyone still using MeeGo services, like OBS, to begin finding other solutions. We will shut down all but essential services in May 2013. If you have questions about this, please contact me or adam.r.gretzin...@intel.com. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-touch-dev] MeeGo mailing list shutdown
Dear participants As part of the MeeGo infrastructure ramp down, we will begin to shut down most mailing lists. In the coming days, all mailing lists at lists.meego.com will be shut down, except for the following: NameReason meego-dev general discussions meego-commits automated emails from builds still being sent there meego-security security concerns The mailing list archives will be frozen too, but not deleted until the main infrastructure shuts down completely. Some mailing lists have been archived publicly by other services, such as: http://gmane.org/find.php?list=meego http://www.mail-archive.com/find.php?q=meego In addition, we'd like to ask everyone still using MeeGo services, like OBS, to begin finding other solutions. We will shut down all but essential services in May 2013. If you have questions about this, please contact me or adam.r.gretzin...@intel.com. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ MeeGo-touch-dev mailing list MeeGo-touch-dev@meego.com http://lists.meego.com/listinfo/meego-touch-dev
Re: [MeeGo-dev] how to be a meego developer
On Sunday, 16 de October de 2011 10:25:40 superccxin wrote: Hi all! As I know, people always divide their system into 3 portions: bootloader, kernel, UI platform(eg. Android). Is meego like that too? If so, how and where i can get these 3 partions? The bootloader part you'll get from your hardware vendor. MeeGo doesn't provide that. The kernel and middleware is what we call MeeGo Core. You can download it from http://repo.meego.com. As for the UI, it depends on the type of vertical we're addressing. Some of the UIs are more advanced stage than others. All of them, depending on whether they built successfully or not, can be downloaded from the same place. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Who will keep pushing MeeGo?
On Monday, 3 de October de 2011 12:08:44 Jeremiah Foster wrote: This is what is important to remember; that Qt and its ecosystem will likely just work on Tizen. But, and this is a big but, will Nokia try and kill Qt now that it is under Microsoft's boot? Not if I have anything to say about it. Nor the hundreds of experienced engineers inside Nokia and outside that have been developing it for years. You simply can't stop an Open Source project if people are willing to continue it. If we look at LiMo we can see it supports Qt and GTK+. I think that Tizen will likely do so as well, if not, it will be trivially to port and I'm sure Quim is right about tools being available for the work, as well as developers and documentation. A toolkit is always needed, even if its just to build browser windows. :-) Without a shipped system library, the cost of using a library as large as Qt is very high. That's exactly the problem that the Qt on Android developers are facing right now, and also the same that the early Qt for Symbian had: a one- time download of 10 to 20 MB. And that's hoping for a decent package management system, not what Symbian had. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Who will keep pushing MeeGo?
On Monday, 3 de October de 2011 13:57:58 Jeremiah Foster wrote: Hmm, that is quite a different story from what I hear from Nokia's marketing material. Somewhere there is a disconnect, either Nokia _is_ porting Qt to WP*, Nokia will continue with Linux for the next billion, or Nokia will use Symbian. Nokia publicly keeps saying the direct opposite of all these options. I can tell you which ports are active for Qt 5. These are the reference platforms: - Linux with X11 - Linux with Wayland - Windows - Mac (Cocoa) There are some other active platforms which are not the reference ones (Android, X11 on other Unix, DirectFB and LinuxFB on Linux, etc.). There are also some people working on iOS port, but it's much behind. And finally, the Symbian port is dead. It's not a target at all for Qt 5. All of the above is public information that anyone can find. There is nothing about a WP port. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Who will keep pushing MeeGo?
On Monday, 3 de October de 2011 16:03:05 Ville M. Vainio wrote: On Mon, Oct 3, 2011 at 3:53 PM, Thiago Macieira thi...@kde.org wrote: And finally, the Symbian port is dead. It's not a target at all for Qt 5. ... until someone decides to do the port, that is. Right, someone could do that. But that port might not be accepted into the mainline anymore, just like a port to DOS or to use the Borland C++ compiler might not be. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Who will keep pushing MeeGo?
On Friday, 30 de September de 2011 14:25:56 Dave Neary wrote: Another added advantage: MeeGo 1.3 was, I hear, below quality and running late. By moving to an SLP based platform, MeeGo gets an existing platform that's actually shipping in devices and has been proven to work. Of course, this advantage also comes with challenges: parts of SLP were closed, and moving to it will result in significant investment in MeeGo being dropped. I think this is a difficult statement to prove or disprove. You're comparing a hypothetical state (MeeGo 1.3 if development were still 100% when it launched) to a future state (SLP turned Tizen 1.0). This is one of those we'll never know. In any case, the situation we're faced with is that: there is no Tizen codebase, repository or even community infrastructure right now. The choices presented are: a) continue working with MeeGo as it is today, given the infrastructure already present b) stop, wait for the new releases and resume from there once they open up At this point, it looks to me like a no-brainer decision. The big question will come when Tizen has something to show and the community can join. In the meantime, the community can do some soul-searching and figure out how it wants to answer that question. And as more information on Tizen becomes available, the community can start adjusting MeeGo to go in that same direction (assuming aligning is what it chooses to do). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Where's the evidence that Tizen will contain *any* MeeGo code?
On Friday, 30 de September de 2011 09:24:04 Alison Chaiken wrote: LiFo owns MeeGo and won't let us the name, to be sure, but we can call it OpenMobMo or OpenMaeLin if you like.(That joke is bound to have turned someone's stomach.) Has anyone asked the LF if we can continue the project, using the trademark, under the same guidance and spirit as it had one week ago? I wouldn't dismiss the name so quickly... But seriously, if the worst case occurs and Tizen bears nearly no resemblance to MeeGo, why shouldn't we consider working on Qt development with Ubuntu Core, which is focused on ARM? With Intel's possible complete departure, MeeGo development on Atom may completely stop, while Ubuntu Core is completely focused on ARM. Yes, I know that would mean going back to .deb's, and I am completely familiar with what a PITA that would be, but if we do nothing as a community, MeeGo is about to die. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Call for Participation for LinuxCon Brazil ends on July 22
On Friday, 22 de July de 2011 15:26:27 Foster, Dawn M wrote: On Jul 22, 2011, at 1:20 PM, Vinícius Costa Gomes wrote: Hi Dawn, The Call for Participation for Brazil ends on July 22: http://events.linuxfoundation.org/events/linuxcon-brazil/cfp From the site: All submissions must be received before midnight September 1, 2011 PDT. Ah, yes. They changed the deadline, so no hurry on submissions :) But no need to leave to the last minute either, as the average Brazilian usually does... -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] which compositer will meego use for wayland?
Em Thursday, 30 de June de 2011, às 14:08:37, Tiago Vignatti escreveu: On 06/30/2011 12:43 PM, steven wrote: how about qt-compositor? Because we don't need that much. In principle, we are happy with a single compositor that contains only a very thin layer for MeeGo. Besides, pushing the effort of building a compositor Qt-independent would ease the adoption for other toolkits. For instance, why the whole code inside qt-compositor/hardware_integration has to be inside a *qt* module? In other words: why it always has to be Qt centric? :) It doesn't. I was going to ask steven what reasons he had for using the qt compositor. It's just a sample compositor, showing what is possible to do if you integrate the wayland libraries into a QML-based application. I've seen other experiments doing the same, some of which would definitely never qualify for a product. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] which compositer will meego use for wayland?
Em Thursday, 30 de June de 2011, às 17:22:48, Ville M. Vainio escreveu: One advantage of using Qt Compositor as starting point would be making the compositor easy to modify, e.g. for OEM's looking for differentiated experience at compositor level. If you don't get worse performance with Qt Compositor, is there a good reason not to use it (as a starting point again, since it's not a product in itself)? This is a question to be asked to the guys who are doing the compositor. If they feel more comfortable with another codebase, they can do that. I'm not sure how much modification of the compositor is expected though. In any case, if you really want to modify, you can use the Qt Compositor in your own product... -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] how to get display resolution using Qt or QtMobility
Em Wednesday, 29 de June de 2011, às 10:37:56, Stylianou, Costas escreveu: Hi, What's the recommended way to get the width and height of your device's screen in MeeGo? QDesktopWidget::screenGeometry http://doc.qt.nokia.com/latest/qdesktopwidget.html#screenGeometry -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] libmeegotouch can not compiled under 1.2.0 SDK
On Thursday, 23 de June de 2011 11:28:18 Michael Hasselmann wrote: On Thu, 2011-06-23 at 14:30 +0800, Jianchun Zhou wrote: Hi, guys: I found that the latest libmeegotouch code can not be built under 1.2.0 SDK, dumped this message: scene/mscene.cpp: In member function ‘void MScenePrivate::handleFocusChange(QGraphicsSceneMouseEvent*)’: scene/mscene.cpp:565:29: error: ‘ItemStopsFocusHandling’ is not a member of ‘QGraphicsItem’ After a while of googling, I know this is a QT problem, I want to know where can I find a new version QT library which had fixed this problem? Should be in Qt 4.7 master (commit 517290f) but you can also remove the ItemStopsFocusHandling flag for your development - without it, text entries will lose focus when user starts panning the contents of MApplicationPage. That's a private flag added during a patch release. I almost created a bug report for the introduction of a new enum value in a patch release of Qt, but decided that asking you to use 0x4 would be useless. Anyway, this commit is not in any released version of Qt. It will be in 4.7.4. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Wayland effort in 1.3 - planning, discussion, activities, etc
On Monday, 20 de June de 2011 10:24:13 Tomasz Sterna wrote: Dnia 2011-06-17, pią o godzinie 17:31 +0200, Carsten Munk pisze: * Wayland WSEGL for SGX drivers - This is a proof of concept[2] that has been working on N900 fine This is about graphics processing only. What about the input stack? What will handle input events? Wayland has input processing too. Second thing: What about X11 compatibility? We can just run a rootless X server on Wayland, the same way that Mac does it. The appeal of having a real Linux in the pocket is a possibility of building any GNU/Linux/XOrg desktop application for it to carry around. And I think I'm not the only one with this point of view. If MeeGo is one-blessed-API-only it doesn't make a real difference to Android etc. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] libproxy and core compliance
Em Monday, 20 de June de 2011, às 13:40:19, Sergio Schvezov escreveu: Is it possible to have this included as part of the API or is there aproject underway to have Qt implement this functionality wrappingaround libproxy or something? QNetworkProxy exists, but I'm not sure where it would be getting its config from on MeeGo. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Wayland effort in 1.3 - planning, discussion, activities, etc
Em Friday, 17 de June de 2011, às 11:52:15, Arjan van de Ven escreveu: as punishment Thiago gets to pronounce this thing fast 10 times in a row (and if he gets it wrong the count resets) oh wait, that's more of a drinking game kind of thing Glad I'm in Berlin then :-) -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] LinuxCon Brazil Prague: Submit MeeGo Sessions by July 8!
Em Wednesday, 15 de June de 2011, às 11:09:21, Michael Hasselmann escreveu: On Wed, 2011-06-15 at 11:02 +0200, Dave Neary wrote: Foster, Dawn M wrote: The Call for Participation for Prague ends July 8: http://events.linuxfoundation.org/events/linuxcon-europe/cfp Hmmm... who do we know in the Czech republic who might be interested in submitting a proposal? Andre, can you think of anyone? ;) The Call for Participation for Brazil ends on July 22: http://events.linuxfoundation.org/events/linuxcon-brazil/cfp I don't know any MeeGo contributors from Brazil. Are INdT doing some MeeGo work these days? Yes, PySide at least. I'll talk to them. There are also some Collabora people living in Brazil. And I want to send something myself too. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Fwd: Call for ideas - preprocessor #define for meego version (Q_MEEGO_VER ?)
Em Tuesday, 14 de June de 2011, às 07:53:12, Andrew Flegg escreveu: 1) Feature detection. Includes screen sizes, orientation default etc. That is understood. We're bringing the Qt Mobility System Information domain into QtCore for Qt 5. 2) Build time. As Attila says, paths icons may need to be different for different platforms. 3) API availability. Raw QML can have an Item as the root item, however MeeGo UX Components and Qt Quick Components have their own window items which should (must?) be the root; and have different import statements. That is a problem that we're trying to solve by getting all the concerned parties together in a workshop and hash out the future. I've even placed some of my trusted subcontractors to analyse the differences and prepare a report. Nothing has happened in the past two weeks though. I'll resume this task after the Qt Contributor Summit this week. As a developer, I want to write a Qt Quick app which can run on Maemo, Harmattan, Symbian, MeeGo and Android; and currently that seems overly difficult. Right, I've complained of the same. But in reality the UIs, UXs and HIGs are quite different from one another, so there's only a limited amount of standardisation that we can create. You will need to adapt your UI to the system you'll be running on so the major objective of QML is to make that easy. This is also where the sysinfo comes in, as your app needs to know which files to load. But personally I don't like the idea of having to change *every* *single* *file* especially if they differ only by the import statement. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Call for ideas - preprocessor #define for meego version (Q_MEEGO_VER ?)
Em Monday, 13 de June de 2011, às 17:30:40, Ville M. Vainio escreveu: We all know and love Q_WS_MAEMO_5 and Q_OS_SYMBIAN for getting work done. However, as everybody ends up seeing,, there is no equivalent for meego. If we ended up having one, what would it look like? Q_MEEGO_VER_MAJOR, Q_MEEGO_VER_MINOR Q_MEEGO_PROFILE tablet-reference There isn't one because MeeGo is just X11 (today). And the build is for all verticals, so you can't add a compile-time define for the MeeGo version and vertical. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Call for ideas - preprocessor #define for meego version (Q_MEEGO_VER ?)
Em Monday, 13 de June de 2011, às 15:32:50, Arjan van de Ven escreveu: On 6/13/2011 3:27 PM, Bernd Stramm wrote: But it could be worse than you think. The size info would be useful for displays that are not build into the meego device. Docking stations, projectors and the like. That is where it gets really interesting, and uxlaunch probably has less control. the good news is that, for things like MacOS and Windows to work, external devices report their dimensions relatively accurately in general with exceptions few and far between (it's an interesting question what size a wall projector has ;-) The problem is that actual dimensions, resolution and DPI are tied to one another. Some systems are known to force the DPI value at a specific number and they do that by changing the actual dimensions reported by X. I've seen this even presented as a configuration setting to users in some systems... -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Call for ideas - preprocessor #define for meego version (Q_MEEGO_VER ?)
Em Monday, 13 de June de 2011, às 15:49:27, Arjan van de Ven escreveu: On 6/13/2011 3:42 PM, Thiago Macieira wrote: The problem is that actual dimensions, resolution and DPI are tied to one another. Some systems are known to force the DPI value at a specific number and they do that by changing the actual dimensions reported by X. I've seen this even presented as a configuration setting to users in some systems... interesting observation for some systems I actually did not mean MeeGo here. The warning on the function comes from the fact that some _other_ systems have it misconfigured, so the number is a lie there. have you seen this with a properly configured meego? (this clearly is all in meego context..) No, I haven't. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Error: Failed to run mic inside bootstrap environment. Return code: 1 --- issue
Em Wednesday, 8 de June de 2011, às 09:51:46, Yuvaraj Ragupathi escreveu: Any Inputs on below issue? undefined symbol: _ZN9QListData11detach_gnowEPii This indicates you compiled your application against one version of Qt but you're now running it against an older version. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] setting TERM in environment
On Monday, 6 de June de 2011 17:20:57 Robin Burchell wrote:
Hi,
I've been doing some cursory kicking of the tires of the (very recently
released) meego-terminal
(https://gitorious.org/meego-terminal/meego-terminal/), and one thing
that came up pretty quick when I tried to run top was that TERM wasn't set.
Who's responsibility is it to have this set? uxlaunch seems one
candidate, but I don't know if that's correct?
The graphical terminal application itself needs to set it to the value of what
it supports.
Or do you mean in a virtual console? If you mean that, it's the kernel that
sets it:
init/main.c:const char * envp_init[MAX_INIT_ENVS+2] = { HOME=/,
TERM=linux, NULL, };
So the question turns from what failed to set it to what unset it?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] QtMobility API to support 9-axis Motion processing
On Friday, 3 de June de 2011 19:48:15 Zhang, Austin wrote: Then was any fusion arithmetic already merged into Qt-Mobility for using those sensors data together? Math is not the province of Qt Mobility. The 9 figures are available for you. The math is up to you. PS: I can't find any relevant documents on fusion arithmetic on the Internet. Can you share some links? The only hits I can find are papers published, only remotely related to sensor technologies. They appear mostly to originate from China, so I'm wondering if this isn't a mis-translated term. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] about uxlaunch support a command line option with enable/disable xsession-errors feature
On Tuesday, 31 de May de 2011 15:59:40 steven wrote: and, please, tell us which package is writing 400mb of output so we can address the issue with the person who wrote the package? the package is third-party package, it doesn't belong to meego package list. Well, then you know who to contact to fix the application. We can't help you there. If the developers won't fix it, then you shouldn't install their app. If you still must, you can start it and redirect its output to /dev/null. What you asked is akin to removing all stop signs because the brakes don't work. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] libmeegotouch in 'MeeGo Core' in 1.3?
On Tuesday, 10 de May de 2011 11:29:09 Sakari Poussa wrote: In future version*s* could be 10 years from now, for all we know (given it took 5 years from Qt 4 to Qt 5 already, the latter not being there yet). You really think you need to prepare for that right now? That (Qt5) is a vision with timeline. It's not 10 years, it is 1+ year as you can read from the blog. These are big and complex things which need long cycles to be planned and communicated correctly. That's what we (MeeGo) are doing now. And not saying do MTF apps now and then say year later that use something else. By the way, please note that the Qt 5 objectives are pretty much aligned with MeeGo's requirements: Wayland support Best possible use of GPU integration QML-based application development (Qt Quick) at the forefront The rest remaining the same Also note that, as a binary-incompatible upgrade, Qt 4 and 5 *can* be installed side by side. They just can't be both loaded into memory at the same time. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] libmeegotouch in 'MeeGo Core' in 1.3?
On Tuesday, 10 de May de 2011 10:42:06 Michael Hasselmann wrote: On Tue, 2011-05-10 at 11:29 +0300, Sakari Poussa wrote: That (Qt5) is a vision with timeline. It's not 10 years, it is 1+ year as you can read from the blog. These are big and complex things which need long cycles to be planned and communicated correctly. That's what we (MeeGo) are doing now. And not saying do MTF apps now and then say year later that use something else. So yes, we need to start the preparation now. Again, nothing has been mentioned in that document that either QWidget or QGraphicsView are or will be deprecated with Qt 5. They aren't deprecated. They are Done (I'll announce this tomorrow). See the definition at: http://labs.qt.nokia.com/2011/05/03/qt-modules-maturity-level/ Unless someone takes them up and moves them back to Maintained. Qt 5 probably will be released next year. The ABI promise then would demand a new major release for Qt before QGraphicsView could be removed/marked as deprecated, and that next version (Qt 6) will certainly *not* happen in 2012. Indeed. Graphics View and the widgets will not be removed in Qt 5, so they'll be around for a number of years to come. With the upcoming Open Governance, deprecation of modules is not decision of the Qt team alone, but outside maintainers could step in (if they realize they are heavily invested in a certain module) and take over. Indeed. Someone has been paying attention to what I've been saying :-) If we already plan for the removal of QGraphicsView (which, by the way, is far more mature than what QML2 will be upon its release, simply because it takes time to mature software), then I think we are planning too far ahead here. We can plan ahead. And Arjan's point is that we want to remove libmeegotouch eventually. For that to happen, we need to know *how* we'll go about it: what is obsoleted by newer technology elsewhere, what should move to other libraries because they are very useful, what needs research and development to be replaced. This is independent of there being a Qt 5 release. This is something MeeGo has decided it wants to do anyway. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Second Call for Proposals for MeeGo Conference
On Monday, 9 de May de 2011 06:48:00 Carsten Munk wrote: 2011/5/9 Zhao, Juan J juan.j.z...@intel.com: Hi Thiago, What is on-line program? Does that mean we can set up the session on line? Just curious:) Means that the session won't be on the printed program that everyone gets when arriving to the conference. We'll have monitors displaying the sessions (I think) and, of course, people can consult online what the schedule is. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] what is bind_mount error about ?
On Monday, 9 de May de 2011 08:31:51 yongbo...@elektrobit.com wrote: what is bind_mount ? A bind mount is when you mount one directory at another place. Usually, you mount a device on a directory, so the filesystem stored on that device is shown to the system. A bind mount doesn't take a device, but an existing, mounted directory and simply shows it again at a different place. Think of it as a directory hardlink. Except it crosses filesystem boundaries and it's ephemeral. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Second Call for Proposals for MeeGo Conference
Hello all The Program Committee is happy to announce that we are opening the Late Breaking News part of the CfP. We are looking for proposals that are new (compared to the first CfP), relevant and interesting. These proposals can be for both full conference sessions (30 min presentation and 10 min QA) as well as for BoFs. The program committee will review proposals as they come in and will inform submitters very quickly on whether their talks have been accepted or not. While we will keep this CfP open all the way to the conference, we will not be able to list talks submitted after May 13 in the printed program - these slots will be listed as LBN with a suggestion to check online or on site for the latest updates. Based on this we plan to publish an updated program (with the accepted sessions so far) on May 16 - submissions after that date will still be accepted (if sufficiently interesting and relevant) but will only be added to the online program and receive ad-hoc signage on site. Please submit your Late Breaking News proposals at http://sf2011.meego.com/node/add/session -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Howto lock screen orientation in MeeGo/Tablet 1.2 ?
Em Friday, 6 de May de 2011, às 13:02:38, Cornelius Hald escreveu: On Fri, 2011-05-06 at 13:42 +0300, Ville M. Vainio wrote: The spec says there should be orientationLock: http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-373 Apparently, there isn't, file a bug :). Hmm, you're revering to Qt Compontents. I don't use them, so I'd need a pure Qt solution. For MeeGo I'm using Qt::WA_LockPortraitOrientation which was included in Qt 4.7.2. Should it work? Are there other options? Those only work on Symbian AFAICT. To me it looks like that API would be the way to go. Also interesting if I use the QML/C++ Wizzard in MeeGo SDKs Qt Creator, it creates code using this API. The WA things work by telling the window manager what to do. On MeeGo, with mcompositor, the window manager doesn't do anything (or didn't use to). It's the application that drew itself 90° rotated. That means pure Qt apps simply don't rotate unless you write the rotation code itself. If you're using MTF classes, this is implemented there though. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Howto lock screen orientation in MeeGo/Tablet 1.2 ?
Em Friday, 6 de May de 2011, às 14:46:15, Cornelius Hald escreveu: I thought I'll try a workaround and use MTF only for rotation. Unfortunately it looks like that's not that easy since MWindow and QWidget are not quite compatible. I really hope we get some framework support for that. You're using QWidget? Then I'm sorry, there's no good rotation practice within Qt. You need help from the window manager / compositor and mcompositor won't do that for you. The only way to do this from inside the application is to do it manually by placing the widget inside a QGraphicsProxyWidget and then rotate the graphics view. This is extremely slow and not recommended. Actually, using QWidget is not recommended. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Howto lock screen orientation in MeeGo/Tablet 1.2 ?
Em Friday, 6 de May de 2011, às 15:16:32, Cornelius Hald escreveu: On Fri, 2011-05-06 at 15:05 +0200, Thiago Macieira wrote: Em Friday, 6 de May de 2011, às 14:46:15, Cornelius Hald escreveu: I thought I'll try a workaround and use MTF only for rotation. Unfortunately it looks like that's not that easy since MWindow and QWidget are not quite compatible. I really hope we get some framework support for that. You're using QWidget? I'm using QDeclarativeView as my root widget, which is a QWidget. How else could I use QML? Can I somehow use QML without QDeclarativeView? Ah, no problem then. But you need to get the sensors information from the Mobility Sensors and apply the transform yourself and animate however you want. Components (both of them) do it for you. Wouldn't a work-around be to rotate my root QML item? If yes, where do I get the physical orientation of the device from? Is there Qt API for that? Yes, use the Sensors. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] https://bugs.meego.com/ can not work now, when will it be recovered?
On Wednesday, 4 de May de 2011 22:54:34 Niels Mayer wrote: On Wed, May 4, 2011 at 8:39 PM, Alexander Bokovoy a...@samba.org wrote: (https://bugs.meego.com) There seem to be some misconfiguration of SSL setup at meego.com. I tried with QtWebkit and it also unable to reach and render it. KDE's Konqueror browser also cannot browse bugs.meego.com over SSL. It outputs the following error: http://nielsmayer.com/meego/bugs-meego-com-bad-certificate.png It's as if the WebKit based browsers (such as Konqueror) do not recognize Go Daddy as CA. (Note the empty certificate chain and this certificate is not signed by any trusted authority in image above). That's not it. The reason is that the certificate presented *is* self-signed. There's no GoDaddy issuer. And the reason for that is that QSslSocket does not send the Server Name Identification SSL extension, whereas Firefox does. You can compare the two behaviours with: openssl s_client -connect bugs.meego.com:443 -servername bugs.meego.com openssl s_client -connect bugs.meego.com:443 QSslSocket in Qt 4.8 does send SNI now. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo vs Harmattan; Tablet vs Handset - (was: Re: Qt/QML or Meego Touch Framework?)
Em Tuesday, 3 de May de 2011, às 13:41:20, Tom Swindell escreveu: 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. Hi Tom That's more or less what's recommended; when your target device is different enough, you want to take a look at your UI and UX to make sure it's still properly written. There's only so much that the components (whichever one) are going to do for you, especially on the first version. The line on how different is different enough is quite blurry though. That said, the expectation is that you don't have to rewrite the *entire* thing. That is, if you change the master layout of your application's main screen, you shouldn't have to change the code for each individual portion of the screen, configuration pages, etc. That being said, Qt Components MeeGo UX Components should really be combined, and I hope they do. Agreed, it's on my to-do list to get this discussion going. It's too late to affect major changes in the first versions, so let's figure out how to help each other on newer versions and bring it back together. We currently don't know how much different the two APIs are, so that's the starting point. The very basic and core components should have the same API: this should be the first goal. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo compliance and Qt Commercial license
On Sunday, 1 de May de 2011 08:39:02 Arjan van de Ven wrote: On 5/1/2011 2:11 AM, VanCutsem, Geoffroy wrote: Hi folks, My apologies if this has been discussed in the past already but I’m struggling to get a definite answer to this question: - Can someone switch to the Qt Commercial license [1],[2] and yet pass the MeeGo compliance test? you're not allowed to replace Qt and stay compliant... (you are allowed to add patches that fix bugs and don't change abi of course) But if you replace it with the same Qt... ? Or replace it with the same Qt minus the extra patches we ship? The problem are patches like the XInput2 multi-point touch support... if you can get a commercial license on the bits we ship, you could be compliant, but my understanding is that you have to use commercial bits to get the commercial support.. and that would not be ok. You can get support on the open source version too. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] FW: execute MTF application by command line error
Em segunda-feira, 11 de abril de 2011, às 16:56:00, Pai, Cary escreveu: Thanks for your response, I am using the root to launch the application, and the DISPLAY have already set to 0, after I tested and the result is the application can be launched successfully if you do not use the root to launch it. Please don't run it as root. The session bus does not allow connections from different users. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] ANNOUNCE: [ABI break] MeeGo 1.2 ARM architecture will only support hardfp ABI
Em segunda-feira, 11 de abril de 2011, às 15:28:59, Juha Kallioinen escreveu: The hardfp scheduler is called armv8el and is up and running in MeeGo Trunk. Why are we calling it ARMv8? All I can find about it are future references, like: http://drdobbs.com/210800195 and talking about future processors like the Cortex-A10. There's absolutely nothing about ARMv8 in ARM's website: http://www.google.com/search?q=armv8+site%3Aarm.com Also, an ARMv8 build implies that it doesn't run on ARMv7 hardware. I think that would be extremely short-sighted. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Technical Steering Group Meeting: New Day / Time
On Sunday, 3 de April de 2011 01:15:18 Jeremiah Foster wrote: By what measure? Most of the people on the mailing lists are from Europe and US. Are we talking corporate head counts or developer participation? Are you on the same mailing lists as I am? There are many Chinese names posting on these mailing lists... -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] tablet user experience source is now open...
Em quinta-feira, 31 de março de 2011, às 11:57:13, Andrew Flegg escreveu: * What is the relationship between MeeGo UX Components and Qt Components[1]? The base API is supposed to be compatible, from what I understand. If it isn't compatible, it's a mistake and should be fixed. There's an API tester as part of components that can be used to verify compatibility. The higher-level API, especially when considering the full layouting and flow may not be compatible, as the UX itself is not compatible. Things like the requirement for a hardware key or how multiple pages should be represented. But it should be similar at least, so as to reuse knowledge as much as possible, like having the same names for properties referring to similar concepts. We may be able to converge later on these when the UXes settle a bit. Right now, it's very hard to do it as they are in flux and one of them, the Harmattan one, is not public, so we can't discuss it. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] libmeegotouch abi comparation
Em quinta-feira, 31 de março de 2011, às 12:11:58, miroslav.s...@tieto.com escreveu: Hi, we have a bit discussion if we can integrate newer libmeegotouch to Meego 1.2. Attached is report between integrated 0.20.89 and proposed current upstream 0.20.100. So any comments welcomed. High risk issues: - MApplication::notify( QObject*, QEvent* ) False positive, checker tool bug. This is not a new virtual, this is an overridden virtual from QCoreApplication. Overriding existing virtuals is permitted, provided that calling of the old method by more-derived classes is acceptable. - MSortFilterProxyModel::lessThan( QModelIndex const, QModelIndex const ) const False positive, checker tool bug, same reason. - MWidgetViewPrivate size change Private class, so size changes are not issues. Medium risk issues: - MStyleSheetParser::StylesheetFileInfo::fromMapedMemory I'm going to guess that this is an older, obsolete method that was removed due to the misspelling (maped - mapped). If no one was using it, it's ok to remove. But it is a BC change. Low risk issues: - MStyleSheetPrivate::SelectorInfoList::selectorInfos Private class, no issue. - MStyleSheetParser::StylesheetFileInfo Seems like a real issue, unless this is a private class. - MTextEdit::retranslateUi( ) No issue. - MToolBarView::orientationChangeEvent( MOrientationChangeEvent* ) No issue. - MWidgetViewPrivate Private class, no issue. - MStyleSheetSelector Incompatible change, unless this is a private class. So I'd say check whether the stylesheet parser in MTF is public API or not. If it's public API, these are BIC changes. Otherwise, the upgrade is completely safe. Even if it's BIC, there was no BC promise for MTF, so the upgrade can be done provided everything linking to MTF is recompiled. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] tablet user experience source is now open...
Em quinta-feira, 31 de março de 2011, às 15:28:22, Thiago Macieira escreveu: The base API is supposed to be compatible, from what I understand. If it isn't compatible, it's a mistake and should be fixed. To be very clear here: I'm told that compatibility is intended, so divergences are unintentional. Also note that a divergence can be solved by adding the same API in the regular Components API spec if there's need for it. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Systray
On Wednesday, 30 de March de 2011 11:20:35 Leonardo Luiz Padovani da Mata wrote: There is an QT API for that: http://doc.qt.nokia.com/latest/desktop-systray.html Using the new protocol for the system tray is preferable. It requires updating QSystemTray to support it, though. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Systray
On Wednesday, 30 de March de 2011 12:01:42 Leonardo Luiz Padovani da Mata wrote: Hello Thiago, On Wed, Mar 30, 2011 at 11:50 AM, Thiago Macieira thi...@kde.org wrote: On Wednesday, 30 de March de 2011 11:20:35 Leonardo Luiz Padovani da Mata wrote: There is an QT API for that: http://doc.qt.nokia.com/latest/desktop-systray.html Using the new protocol for the system tray is preferable. It requires updating what do you mean with new protocol? The new system tray protocol over D-Bus, the notification item or indicators protocol. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions - QSparql
On Saturday, 26 de March de 2011 14:20:36 Patrick Ohly wrote: Is it meant to be part of Qt? Will there be an API review by Qt developers before including QSparql in Qt? I did the API review of QtSparql myself. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Session/BoF Proposals for MeeGo Conference due in 9 hours
On Friday, 25 de March de 2011 18:47:23 Leonardo Luiz Padovani da Mata wrote: On Fri, Mar 25, 2011 at 6:46 PM, Leonardo Luiz Padovani da Mata leonar...@syst.com.br wrote: Mine is there. I hope to get more information about hotel reservation and sponsorship. Since i (and other participants) need to get a visa to go to USA, please, consider to have the final version of sessions as soon as ***consider to have the final version of ACCEPTED sessions as soon as possible! Hello Leonardo We'll try to get the initial list of approved sessions in two weeks. It will be a tight schedule for the program team, but we'll do our best. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Wednesday, 23 de March de 2011 08:41:35 Andrew Flegg wrote: Imad also indicated that the TSG would grow - presumably in response to Nokia's board's decision[3]. However, it would be sensible to The growing of the TSG is to give room for others making investments and shipping (or going to ship) MeeGo devices. If you look at the minutes of the TSG meeting, you see lots of names of joining for STB and IVI work. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Reminder: MeeGo Conference May 2011 CfP closing this Friday
Hello This is just your friendly reminder that proposals for talks during the May 2011 conference are due this Friday, March 18. Don't wait for the last minute to submit your session. We're very much interested in what you're working on and what you're planning to work on soon. We want to make this conference as great a success as Dublin was, if not better. To submit a proposal, please register at the conference website http://sf2011.meego.com and create a proposal at http://sf2011.meego.com/node/add/session . Also, if you have ideas of sessions that you'd like to see when you come to San Francisco, please add them to the wiki page at http://wiki.meego.com/MeeGo_Conference_Spring_2011/Session_ideas so potential presenters will know there's interest. Feel free also to mark up the ideas listed there to demonstrate bigger interest. See the full text of the CfP at: http://sf2011.meego.com/program/call-session-proposals The program committee Dirk Hohndel Carsten Munk Thiago Macieira -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Anyone knows how to enable logging in libQtCore
On Thursday, 3 de March de 2011 00:31:10 Yung, Winson W wrote: What do I set it to? I did export QT_USE_SYSLOG=1, and it doesn't work. I'm pretty sure it is working. But like I said in the other email, there is nothing to *be* logged. A properly-written application generates no warnings. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Wayland Timeline
On Friday, 4 de March de 2011 00:39:12 Mark Constable wrote: You really want: git checkout -b master origin/master Ah great, thanks, that confirms what I eventually stumbled upon but I'm still unsure how best to keep that branch updated? Once you've done the command above, a plain git pull is enough. git pull is equivalent, in this case, to git fetch origin followed by git merge origin/master git fetch or git checkout 4.7 git pull or ? This page doesn't quite cover this exact scenario... http://qt.gitorious.org/qt/pages/GitIntroductionWithQt -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Anyone knows how to enable logging in libQtCore
On Wednesday, 2 de March de 2011 17:13:25 Yung, Winson W wrote: Hi all, I need to debug something related to system wakeup in msyncd, in order to get more info on what's the code is doing inside libQtCore. I want to see it is possible to enable the logging for Qt. MeeGo has a special patch I made that logs all warnings to the syslog. If the code is properly written, there will be no warnings. Qt has no tracing or debugging messages. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] ARM Thumb2 MeeGo test-run results
On Friday, 18 de February de 2011 15:11:32 Carsten Munk wrote:
{standardâinput}:43893:âError:âthumbâconditionalâinstructionâshouldâbe
inâITâblockâ--â`strexeqâr6,r5,[r3]'
{standardâinput}:43894:âError:âthumbâconditionalâinstructionâshouldâbe
inâITâblockâ--â`teqeqâr6,#1'
Known issue. Thumb builds on Linux have never been supported.
The Linaro guys have proposed a patch, though:
http://bugreports.qt.nokia.com/browse/QTBUG-15911
https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/490371
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
pgpwN8Fa8Z0EL.pgp
Description: PGP signature
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] undefined symbol: _Z34QBasicAtomicIn_fetchAndAddOrderedPVii of libQtGui.so.4.7.1
On Monday, 14 de February de 2011 09:56:55 Zhao, Halley wrote: # nm -u /usr/lib/libQtGui.so.4.7.1 | grep fetchAndAddOrdered U _Z34QBasicAtomicInt_fetchAndAddOrderedPVii My platform is a core 2 notebook installed with MeeGo image for netbook. (maybe the âarchâ difference cause the issue, but the package works well in OBS). This is an arch issue. That symbol above is only present in the Generic and Symbian architectures. On any Linux system, there should be inline assembly functions, so this symbol should never appear. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgpu92f6TzXxv.pgp Description: PGP signature ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] updated MeeGo compliance spec available for review
On Friday, 4 de February de 2011 21:21:04 Antti Kaijanmäki wrote: I think IPv6 is mandatory for any product that comes out these days. Even more importantly now that the IPv4 address pool has finally been completely depleted. So yes I think MeeGo 1.1 compliance spec should mention at least even vaguely that IPv6 is required if you don't want to specify any mandatory kernel configuration at this time. Huh... just to correct a little your information: the IPv4 address pool has not been depleted. The IANA has exhausted its pool. But the 5 registries still have some more IPs left, with the APNIC and RIPE NCC expected to exhaust theirs still in 2011, ARIN in 2012 and the LACNIC between 2012 and 2014. However, that is not to dissuade from the urgency. IPv6 support should have been required for any and all devices shipped since 2007, at least. -- Thiago acieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgpKmOwTf1tec.pgp Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Nintendo Meego GameBoy
On Monday, 31 de January de 2011 22:13:29 Randolph Dohm wrote: ok, i am quiet. since 6 months (anroid marketshare = 17 %, see attached mail, today (as posted): 32 %) still no meego hardware. while other post marketing wikis and the thing with coloured tshirts, my understanding of development is not only technically, but strategically. you get no apps and developers if there is no hardware to test. time slot is getting to thin air..: I shouldn't be feeding you but... what do you want us to do? Your complaint is that there's no hardware. What should we do about it? Please remember that this is the MeeGo-dev mailing list, about developing the core MeeGo OS. What software answer is there to your question? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Question on screen rotation functionality
On Friday, 28 de January de 2011 20:22:55 Tzeng, Tonny wrote: Which release are you referring? If you are asking the MeeGo 1.1 handset release, I think itâs libmeegotouch package deals with the screen rotation. And rotation in MTF has nothing to do with the kernel or even the compositor. Each application rotates itself by drawing everything 90° rotated. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgpN23KG7rEBp.pgp Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGO home button and back button
Em quinta-feira, 27 de janeiro de 2011, às 16:46:17, Wang, Shaojun escreveu: Hi We want to implement HOME BUTTON and BACK BUTTON function on MeeGo Handset V1.1.2. Does any know the keycode of these two buttons in MeeGo? They should be Qt::Key_HomePage (not Qt::Key_Home) and Qt::Key_Back. http://doc.qt.nokia.com/latest/qt.html#Key-enum -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] NEON memcpy?
Em quarta-feira, 26 de janeiro de 2011, às 09:48:54, leonid.moiseic...@nokia.com escreveu: Could you please send me source code, I will integrate it into memory testing suite and share results from Harmattan? Btw, if you have access to sources you can check sp-mem-throughput package or glibc itself. Sorry, what source code? Of my benchmarks? I only wrote the x86 parts of it. I didn't have enough free time to try to optimise with ARM code. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Dconf
Em terça-feira, 25 de janeiro de 2011, às 11:33:00, Ross Burton escreveu: On Mon, 2011-01-24 at 22:55 +0800, Arjan van de Ven wrote: but at the end of the day, end users won't even notice either of the two. Actually users do notice: GConf/dconf settings are instant apply with notifications across the desktop, QSettings not so much. That's a difference in philosophy and, more than that, in the application itself. It's not enough that the settings database updates, the application must react to it and apply the settings that changed to its UI and behaviour. Anyway, Arjan was comparing GConf and DConf when he said users wouldn't notice. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Dconf
Em terça-feira, 25 de janeiro de 2011, às 12:17:05, Robin Burchell escreveu: Though, at present, QSettings provides no API for change notifications (something which has irritated me, and obviously others, many times - going by the number of GConf uses and wrappers that have proliferated around Maemo, etc.) Again, difference in design philosophies. We've never implemented this feature because most of our customers (including KDE) don't need it -- not that it would matter for KDE, since it doesn't use QSettings either. I'm not sure the other backends for QSettings support change notifications either. So even if you want instant-apply, it's not trivial to make it Just Work™. Presumably this is something that would be addressed in the DConf work, anyway. Like I said, we'd like to take QSettings to the next level and have (optional) change notification. The how is the big question, since QSettings is actually quite old and complex code. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Dconf
Em terça-feira, 25 de janeiro de 2011, às 15:27:02, Urho Konttori escreveu: Don't we have mobility publish and subscribe (or qvaluespace) for the exact purpose outlined here as the change notification? PS is very good at providing dynamic value changes across the entire system. But as it is not connected to the system settings, it's a separate namespace. There's no guarantee that a system setting found under a certain key can be observed in PS. Also, and here I'm unfamiliar with PS, can any application change the value found in the PS value space? What happens when this app quits? Thus, shouldn't you use that if you need notifications and QSettings for the cases you don't. Seems pretty logical to me. Having said that, I do vote for Marius Vollmers proposal that there should be a dconf backend to the qvaluespace in the future. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Dconf
Em terça-feira, 25 de janeiro de 2011, às 16:15:43, Urho Konttori escreveu: There are different backends to PS. Shared memory is the most volatile and the one people often mistake to be the only backend. Take a peek at: http://doc.qt.nokia.com/qtmobility-1.2/publ-subs.html Gconf is even now available as one of the layers (and so is windows registry and symbian settings). Beauty of PS is that you only need to care about the backend if you want to. You can just select one that provides the features you actually want (e.g. I want to store this tuple to a layer that provides permanent storage), or request for scan of all different backends for the key you need. Layer can be also read only, which then means that an app cannot change the value. Hi Urho Thanks for the explanation. Sounds like app developers' lives can now be made easier. :-) But not mine. Again on the example of the locale, QLocale cannot use PS to find out what the GConf setting is. For the same reason, QtNetwork cannot use PS to find out what proxy configuration is enabled. Dependency reversal. There are some Mobility areas that should be moved into QtCore so that the core can also benefit from it. PS and System Information come to mind (cf the other thread on how to find out what kind of device you're on). I've already discussed this internally, but we haven't had any action on the subject. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Dconf
Em segunda-feira, 24 de janeiro de 2011, às 16:38:46, Dave Neary escreveu: Arjan van de Ven wrote: Heck, app writers wouldn't even notice the difference if you use the proper abstraction API. ... which is, presumably, GSettings? Or a revamped QSettings if we can make it. Besides, the whole point is not to access the same file format, but to access the same settings. This requires searching for the same keys, accepting the same values. A good example is the locale configuration. On GNOME, it's configured somewhere in GConf or DConf. In KDE, it's configured in $KDEHOME/share/config/kdeglobals. On MeeGo, I have no clue where it's supposed to be configured, given the different implementations between netbook and the others. Of course, Qt doesn't integrate with any of those. The only way to configuyre the locale in Qt is via the common denominator: the POSIX configuration (by setting LANG and the LC_* variables). Unfortunately, none of the environments set LANG to a file containing their settings[*], so the common denominator is actually often the wrong config. Now, if we can get an agreement on where the setting should be (blessed by XDG), then we'll be happy to read it from QtCore. [*] Qt doesn't read custom locale files yet, but we might just write that code if MeeGo uses it. This doesn't require XDG blessing. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] NEON memcpy?
Em segunda-feira, 24 de janeiro de 2011, às 12:57:32, Carsten Munk escreveu:
Hi,
Do we have a sane and performing NEON memcpy that would be suitable
for MeeGo glibc version anywhere? Would be useful for glibc armv7nhl
variant.
Shouldn't be very hard to implement one:
NOTE: NOT TESTED!
void *my_memcpy(void *dest, void *src, long n)
{
const int stride_bytes = 16;
uint8_t *d = dest;
uint8_t *s = src;
{
/* main copy, Neon vectorised */
long vector_len = n / stride_bytes;
uint8_t *end = s + vector_len * stride_bytes;
n -= vector_len * stride_bytes;
while (s != end) {
#ifdef __CC_ARM
vst1q_u8(d, vld1q_u8(s));
d += stride_bytes;
s += stride_bytes;
#else
/*
* Assembly equivalent:
*/
asm (vld1.8 {d0, d1}, [%[s]]!\n
vst1.8 {d0, d1}, [%[d]]!\n
: [s] +r (s), [d] +r (d)
: /* no inputs */
: d0, d1);
#endif
}
}
if (stride_bytes 8 n = 8) {
/* one last 8-byte step */
n -= 8;
#ifdef __CC_ARM
vst1_u8(d, vld1_u8(s));
d += 8;
s += 8;
#else
/*
* Assembly equivalent:
*/
asm (vld1.8 {d0}, [%[s]]!\n
vst1.8 {d0}, [%[d]]!\n
: [s] +r (s), [d] +r (d)
: /* no inputs */
: d0);
#endif
}
/* residue */
switch (n) {
case 7: *d++ = *s++;
case 6: *d++ = *s++;
case 5: *d++ = *s++;
case 4: *d++ = *s++;
case 3: *d++ = *s++;
case 2: *d++ = *s++;
case 1: *d++ = *s++;
}
return dest;
}
You can modify the above code:
stride load/store
8 vld1_u8 / vst1_u8
16 vld1q_u8 / vst1q_u8
24 vld3_u8 / vst3_u8
48 vld3q_u8 / vst3q_u8
Given that the 24- and 48-byte strides require a division by 3, I recommend
sticking to the 8- or 16-byte stride versions.
The GCC versions are written in inline assembly because all current versions
of GCC spill the Neon registers to memory with the intrinsics.
Comparing the assembly generated by both GCC and RVCT indicates that the math
portion of the function and the transition from 16-byte to 8-byte stride seem
to be better with RVCT, but the handling of the switch at the function
epilogue seems better with GCC 4.5.
Each of the case statements in GCC is:
ldrbr3, [r4], #1@ zero_extendqisi2
strbr3, [ip], #1
whereas RVCT produces:
LDRB r4,[r1],#1
ADD r2,r3,#1
STRB r4,[r3,#0]
MOV r3,r2
That is, the same first instruction, but it uses two additional instructions to
update the d variable, instead of doing the inline post-update.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Dconf
Em segunda-feira, 24 de janeiro de 2011, às 09:35:28, Foster, Margie escreveu: On MeeGo, I have no clue where it's supposed to be configured, given the different implementations between netbook and the others. Of course, Qt doesn't integrate with any of those. The only way to configuyre the locale in Qt is via the common denominator: the POSIX configuration (by setting LANG and the LC_* variables). Unfortunately, none of the environments set LANG to a file containing their settings[*], so the common denominator is actually often the wrong config. Now, if we can get an agreement on where the setting should be (blessed by XDG), then we'll be happy to read it from QtCore. [*] Qt doesn't read custom locale files yet, but we might just write that code if MeeGo uses it. This doesn't require XDG blessing. Again I ask--how does this affect localization? I still do not understand how I can change locale in MeeGo. Hi Marge. That's why I said I didn't know where it's configured in MeeGo. But looking at this problem from the Qt point of view, the only way today to change the locale is to change the environment variables, which means: 1) apps must be restarted for the change to take effect 2) you can only select one of the pre-defined locales, provided by glibc (this means you cannot customise how the system presents times and dates) For Qt to change this behaviour, we need a standard to follow. It can either be: A) set LANG to a file name, so we'll implement: - parsing of locale files - update when file is modified This requires no communication with XDG. B) agree on a Linux-wide way of setting the locale, by way of XDG, so we don't have to implement this two or three times (KDE, GNOME, MeeGo). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Dconf
On Tuesday, 25 de January de 2011 08:05:46 Marius Vollmer wrote: ext Thiago Macieira thi...@kde.org writes: Em segunda-feira, 24 de janeiro de 2011, às 16:38:46, Dave Neary escreveu: Arjan van de Ven wrote: Heck, app writers wouldn't even notice the difference if you use the proper abstraction API. ... which is, presumably, GSettings? Or a revamped QSettings if we can make it. Yes, please! It would be very nice if QSettings could also use GConf as a backend. That would allow more mobility during the transition. GConf is harder to do, given the dependencies. DConf is more plausible, which is why I connected Mark Shuttleworth with the people who could do the Qt binding. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Framewo ks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgpVHJpbwZema.pgp Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARMv7 thumb2 in 1.2
On Tuesday, 18 de January de 2011 13:03:38 Carsten Munk wrote: Some comments about current hardfp RPM optflags has been that we have -mno-thumb . And some vendors might want to optimize some things for thumb in terms of memory size. So I'd like to preempt this issue before we run into it in deployment by vendors - and help by having a standard set of optimized packages. Thumb2 is problematic on some silicons, due to http://cateee.net/lkddb/web-lkddb/ARM_ERRATA_430973.html - and this includes Nokia N900 and possibly other boards. But it is also very useful when it comes to memory and cache size of the running system. My proposal is to add on top of the 2 (armv7nhl, armv7hl) hardfp architectures, RPM these definitions: armv7thl: -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb armv7tnhl: -march=armv7-a -mfloat-abi=hard -mfpu=neon -mthumb armv7thl would be install compatible with armv7hl armv7tnhl would be install compatible with armv7thl, armv7nhl Do we need to rebuild everything? I'd say that the vendors who have devices that properly run Thumb2 can enable that for their own builds. And by the way, Qt 4.7 does not compile in Thumb mode on Linux. And this includes any code that uses Qt. The Linaro folks have submitted a (rather trivial) patch to fix the issue, but it isn't in yet. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Speech Recognition API for QT?
On Monday, 17 de January de 2011 09:22:44 Zheng, Huan wrote: Hi, dear developers I did a quick search, it looks like there's no speech recognition API in QT yet, am I missing something? Is there any plan to support speech recognition in QT? You're right, there's no such API. We also have no current plans -- speach recognition is not an easy task. But we're open for ideas on how to implement this. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARM RunFast by default in glibc
On Wednesday, 12 de January de 2011 16:01:31 Carsten Munk wrote: 2011/1/12 Arjan van de Ven ar...@linux.intel.com: On 1/12/2011 1:06 AM, Carsten Munk wrote: Hi (ARM toolchain group mostly) Do we have a patch for glibc-2.11-12-g24c0bf7 and/or glibc-2.12.1 that enables ARM RunFast[1] mode by default anywhere? Would be good to push it along with hardfp while we're at it and getting things tested through. can this be turned into something that's passed in via CFLAGS ? that way apps will not be surprised, and there is an easy way for us to toggle Right now, it's a context configuration, so there's nothing that will really work from CFLAGS. Without changing gcc, the only thing we could do is supply different crt1.o, one that puts the FPU in RunFast, the other doesn't. But this will, like I said, apply to all code within a process, so it doesn't help the library case. Libraries will need to cope with running in both modes. of course we can have a default in our OBS that you pick, but it becomes an easy-to-manage (from a distro perspective) property That would be a better way than patching glibc, I would believe? Not necessarily. To do the right thing, the compiler would need to emit the code that changes FPSCR before any FP operation, so this means an increase in code size. I can also bet that there's a pipeline delay in modifying this register. And there's no such GCC patch. Wouldn't -ffast-math correspond to this on x86 side at least? Leonid, does this correspond to an auto-setup of RunFast on ARM, when used there? No, it's different. By the way, I should point out that on Cortex-A8, RunFast only has a perceptible improvement for float. If you use double, you still have performance issues. On Cortex-A9, both are fast. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Hardfp status, january 11
On Tuesday, 11 de January de 2011 11:50:11 Carsten Munk wrote: * I'm having issues with glibc builds with mfpu=neon and -O3, causing segmentation faults in libdl.so when running things like bash. -O2 works fine. Hints in this area welcome. * I'm investigating Linaro 2010.12 to see if this fixes the NEON issues. Downside of this is that it is actually 4.5.2 based, which we don't have current program office approval for changing. See if adding -fno-tree-vrp helps. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] qt style of meego?
On Sunday, 9 de January de 2011 23:08:55 éé« wrote: i wrote a application use Qt for meego..but the style of the application looks ugly..does anyone kown how to modify the style just like the MTF application? It's impossible to make it just like MTF because MTF applications are using Graphics View, whereas traditional applications use QWidget. There's simply no way of doing everything GV does in QWidget -- that's why MTF developers chose GV in the first place. The QWidget style is a best effort approach. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgpVRPfBzY5Xs.pgp Description: This is a dig ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] mono
On Thursday, 6 de January de 2011 09:15:56 Sergio Schvezov wrote: On Wed, 2011-01-05 at 17:09 -0800, Thiago Macieira wrote: On Wednesday, 5 de January de 2011 09:22:22 Pertti Kellomki wrote: On 01/05/2011 12:58 AM, ext Arjan van de Ven wrote: Does this imply that the reference applications are not compliant? Or do they include Mono in the packaging? And yes, reference applications don't need to be compliant. Anyone can ship a MeeGo device with non-compliant applications. In fact, there's nothing that stops non-compliant applications from being allowed on any kind of device. Can you define allowed? The sense of the word in English. The opposite of forbidden. In other words: nothing forbids non-compliant applications. The specification deals with what a compliant application and a compliant device must do, at minimum. What they do in *addition* to the spec is not defined by the spec. What matters is that compliant applications must be accepted and mu t work. I would of thought that by being compliant, your application would work throughout all the verticals. Is that a true statement? That's the idea. But note that work in our sense here means it loads and runs, not that it displays properly or that the application is even suitable for the device. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] mono
On Wednesday, 5 de January de 2011 09:22:22 Pertti Kellomäki wrote: On 01/05/2011 12:58 AM, ext Arjan van de Ven wrote: Mono is being pulled in by some of the reference applications for the Netbook build. you're not required to have Mono, nor can compliant apps expect it to be there; if you decide to replace the reference applications with something else, Mono is likely not there Does this imply that the reference applications are not compliant? Or do they include Mono in the packaging? Mono is included as a dependency of those applications. And yes, reference applications don't need to be compliant. Anyone can ship a MeeGo device with non-compliant applications. In fact, there's nothing that stops non-compliant applications from being allowed on any kind of device. What matters is that compliant applications must be accepted and mu t work. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgpJC6Ng5RpwX.pgp Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] How to call a method with argument MyStruct in QDbus?
On Wednesday, 29 de December de 2010 16:16:44 He, Yunlong wrote:
Hi, experts,
In qt doc, qtdbus supports customized type âMyStructâ, so I write
code as below:
class MyStruct
{
public:
â¦
int type;
QByteArray data;
};
Q_DECLARE_METATYPE(MyStruct);
QDBusArgument operator(QDBusArgument argument, const MyStruct msg);
const QDBusArgument operator(const QDBusArgument argument, MyStruct
msg);
Please direct your Qt questions to qt-inter...@qt.nokia.com. But anyway...
And somewhere you call:
qDBusRegisterMetaTypeMyStruct();
but when I use it as below:
void notify(MyStruct msg) {
â¦
QDBusReplyint reply = iface-call(âmessageArrivedâ, msg);
â¦
}
It reports âno matching function for call to QDBusInterface::call(const
char[21], MyStruct )â
That's a C++ error, nothing to do with QtDBus.
The QDBusInterface::call function has a QString argument, followed by 8
defaulted QVariant arguments. Your MyStruct argument doesn't convert to
QVariant.
How can I use it in this case? Or I must convert to QVariant?
Yes. There are two ways to do that:
1) add operator QVariant() const { return QVariant::fromValue(*this); }
to your MyStruct class
2) make the call as:
call(messageArrived, QVariant::fromValue(msg));
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
pgpLFdvBoHQVs.pgp
Description: This is a digitally signed message part.
___
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?
On Tuesday, 28 de December de 2010 14:37:26 kate.alh...@nokia.com wrote: What is the timescale and roadmap for Qt Quick Components? Thiago or Henrik Harz can comment this issue ? As soon as humanly possible. So sometime in Q1 or Q2 in 2011. Hopefully in time for us to talk about in the MeeGo Conf SFO. But things could change. It's not trivial to make an API that serves handsets, tablets and other things in the future (whose UX we don't know yet), yet is deep enough to make native look-and-feel and broad enough to support almost everything an app needs. Like Ville said, if you want to know more, watch the QTCOMPONENTS-72 task and join the mailing lists. *All* of the source code is public, the tasks are public, etc. The only thing we're not sharing is the actual device's theme. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] What are the advantages of developing QT apps without libmeegotouch over MTF enabled application?
On Tuesday, 28 de December de 2010 19:50:35 kate.alh...@nokia.com wrote: I promise that we in Forum Nokia do everything to get developers informed as well as possible. We release Qt Quick Components pre-alpha as soon as we get it done, we released Qt for Maemo5 with first SDK. Reason that you did not hear our voice in MeeGo conference was not in our decision. And as part of the Program Committee for the conference, I can tell you that we felt that showing a breadth of technologies was a good thing. MeeGo is not a Nokia thing, so we don't have to follow the official company's policy. Nokia will use Qt Quick and OpenGL ES only in the future, even on its MeeGo devices. But the MeeGo OSS project can very well use other technologies it feels necessary, like Xlib, Gtk+, Clutter, PyQt, Evas, etc. In fact, many vendors will make use of those technologies (think Flash players, Chrome browsers, etc.), which is also one of the reasons why switching to Wayland isn't trivial. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] QDBusConnection::ExportAllSlots not supported?
On Monday, 27 de December de 2010 16:58:57 He, Yunlong wrote:
Hi, Experts,
Hello
I am new to QtDBus, so tried simple way to use
QDBusConnection::ExportAllSlots:
MyDaemon mydaemon;
QDBusConnection::sessionBus().registerObject(/, mydaemon,
QDBusConnection::ExportAllSlots);
That's it :-)
Then in client side
QDBusInterface iface(MSIP_CHANNEL_NAME, /, ,
QDBusConnection::sessionBus());
QDBusReplyQString reply =
iface.call(add, 2, 3);
Finally it reports:
Didn't receive a reply. Possibly causes include: the remote application
did
not send a reply
After checking log, the method is never called:
int MyDaemon::add(int a, int b)
{
syslog(LOG_INFO, handling add\n);
return a + b;
}
So I wonder whether ExportAllSlots is supported, or is there anything
wrong in my code.
There must be something wrong in your code, in parts of the code that you
didn't paste here.
It's either because:
1) the server application did not enter an event loop, so it's not processing
any incoming messages
2) the client application failed to connect (usually due to wrong UID) so it
gets a spurious Timeout error
You can tell which case it is by timing how long it takes you to get the
error. If you get a Timeout error immediately, then it's case 2. If it waits
for 25 seconds, then it's case 1.
PS: please don't hijack threads. Your message has nothing to do with the
Pulseaudio reversion plan. If you have a new topic, please create a new
message, don't reply to any existing one. Changing the Subject isn't enough.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Is MeeGo a Google product?
On Friday, 24 de December de 2010 16:53:01 Tomasz Sterna wrote: This just came on #meego @freenode [16:36:26] welfg: meego is google's company? [16:36:39] thiago: no [...] [16:41:40] welfg: Download.MeeGo v1.1 for Netbooks (Google Chrome Browser) [16:41:50] welfg: This release requires accepting the Google Chrome end user license agreement (EULA). [16:42:11] welfg: looks like made by google And right after that: 13:42 welfg whatever 13:42 thiago Chrome is made by google 13:42 thiago MeeGo isn't Is this the image we want to project? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Writing code in Qt for MeeGo platform
On Wednesday, 15 de December de 2010 15:13:51 Stylianou, Costas wrote:
Hi,
Is there a way to differentiate for the MeeGo platform when writing code in
Qt?
No. MeeGo is standard X11.
E.g. if writing for Symbian, we can use
#ifdef Q_OS_SYMBIAN
or
#ifdef Q_WS_S60
in my source code.
And I can use:
symbian {
symbian stuff here
}
in the .PRO file...
For MeeGo, you can use:
#ifdef Q_OS_UNIX
#ifdef Q_OS_LINUX
#ifdef Q_WS_X11
and in the .pro files:
unix { ... }
linux-* { ... }
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Writing code in Qt for MeeGo platform
On Wednesday, 15 de December de 2010 14:19:00 Bernd Stramm wrote: This seems to be the current situation, applications take a wild guess to decide what they are running on. This means different applications take different guesses. It would be really really nice if there was a better way. You know, something reliable and/or organized. I agree. Tell me which information will help you make the right decision. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo migration path?
Em Terça-feira, 14 de Dezembro de 2010, às 16:45:28, Jechlitschek, Christoph escreveu: Hi all, I was wondering if there exists a migration path from MeeGo 1.0 to MeeGo 1.1 and later to MeeGo 1.2. This is very interesting for companies that have devices in the field and want to push an upgrade to the next higher version (instead of just an update within a version). Is it just a zypper dist-upgrade with new repositories? Yeah, sounds about right. :-) -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] What mediaplayer is used in netbook and handset?
On Friday, 10 de December de 2010 10:19:08 He, Yunlong wrote: Sorry, I am using meego SDK 1.1 with qemu emulator, but no built-in mediaplayer found, could you tell me its repo or project home? I don't think the applications are part of the SDK. So you won't find the media player there. Can you clarify what you're trying to do? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] What debug method to use
On Friday, 10 de December de 2010 17:52:57 Berthier, Emmanuel wrote: Hi, I'm a Meego core developer and I wonder what kind of debug methodology is the best for a Handset platform. I have experiment some solutions: o Use a remote debugging method based on osc, gdbserver and Anjuta as gdb frontend: + I can easily recompile module using osc + I can debug the app using Anjuta - but I can not easily debug dynamically linked libraries (as RootFS generated by OSC only contains 1 project) - Anjuta Project backend is not compatible with Qt projects (Dependency Loop detected in makefile generated by qmake4) o Use a local debugging method based on gdb and debug packages: + I need to download/install many debug packages using zipper - I can not recompile a module - gdb provide poor source level debugging experience o Use a remote debugging method based on remote X session, ddd and debug packages: - I need to recompile ddd for Meego. + I need to download/install many debug packages using zipper - I can not recompile a module + ddd provide good source level debugging experience o Use a JTAG based debugger (ITP/Lauterbach probe): + I need to download/install many debug packages using zipper - I can not recompile a module - JTAG break points halt the IA core and so interfere with some realtime system features. + T32 provide good source level and assembly level debugging experience In fact, my need is to get an easy to setup, powerful compilation and debug environment (for user space app) on target (no emulation). My main issue concerns the management of dynamic libraries: I don't have a good solution for now. What is the common usage of debug packages? Hi Emmanuel I would say that the gdbserver option is by far the most attractive solution. You can use whatever debugging environment you're most comfortable with, you don't need the debugging symbols on the device nor do the heavy processing of the debugging information on it. I don't know why you have a limitation of debugging dynamic libraries. My experiences with gdb + gdbserver allow me to debug libraries coming from different places. In my case, I simply NFS mounted my workstation's $HOME on my N900, started gdbserver on a binary I built and then started debugging Qt. Probably easiest would be if you just copied the libraries you built to the sysroot. Local debugging is the lazy case, when you just want to do something and you don't mind the slowness of the device. It's also not a use-case you're going to have available in all devices. Eventually, you'll have to debug problems on production devices, where gdb isn't present. Finally, JTAG is really a specialised case. It's more useful for benchmarking and dissecting why something is slow on device, or maybe for hardware debugging. See: http://labs.qt.nokia.com/2009/09/29/exploring-qt-performance-on-arm-using- finetoothcomb/ -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Launching browser
On Thursday, 9 de December de 2010 16:03:27 Rubanov Ivan wrote: I need to launch web browser from the code. How could I do it? I tried to launch it using dbus. Actually I used maemo dbus code: You're supposed to use QDesktopServices::openUrl. Make sure that xdg-utils is installed. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] fennec(Illegal instruction) issue on MeeGo
Em Terça-feira, 7 de Dezembro de 2010, às 20:49:37, Gabriel M. Beddingfield escreveu: Another clue: following issue: Program received signal SIGILL, Illegal instruction. 0xa144 in __aeabi_d2lz () ^^ While this /could/ be a valid pointer, this address looks like a bogus pointer to me. I rarely see pointers this low in an application. This also suggests a buffer overrun and a corrupted stack. It probably is a valid pointer, because the debugger resolved it to __aeabi_d2lz. I looked at the ABI spec and it says d2lz is convert double to C long and it may be implemented either in software or in hardware. Looks to me like you installed a libgcc_s.so which is not compatible with your hardware. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] signon-qt: ABI/ABI break
Em Quarta-feira, 8 de Dezembro de 2010, às 10:09:32, Patrick Ohly escreveu: Error now is passed by value, so use SignOn::Error, not const SignOn::Error . That's the same thing for Qt's signal-slot mechanism. It's actually recommended that you write T instead of const T and use no spaces around commas or parentheses. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Qt uses OpenSSL, and fails?
Em Quarta-feira, 8 de Dezembro de 2010, às 09:51:18, Patrick Ohly escreveu: A bug report about Buteo not syncing with Google via https [1] showed that Qt tries to load OpenSSL libraries, which fails because they are not installed where they are expected [2]. There is an open request to change that [3]. First, is someone working on 7813? The original issue # was marked as resolved with a comment that Fix is already available in 1.1 branch., but it doesn't say what the fix was, and Trunk obviously is still affected. Makoto, can you clarify? The Qt fix was applied as e4407012815a805d9a7d1a3beb7038a93cdd74dd but it isn't in any release yet. It's post 4.7.1. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Qt uses OpenSSL, and fails?
Em Quarta-feira, 8 de Dezembro de 2010, às 08:49:30, Arjan van de Ven escreveu: On 12/8/2010 8:44 AM, Rémi Denis-Courmont wrote: - use GnuTLS or NSS instead of OpenSSL, we should be using NSS anyway wherever possible, not just for the licensing side, but also because openssl has a history of ABI mess. Which should hopefully be a thing of the past now that OpenSSL has reached version 1.0. NSS is an alternative, but I think our legal department ruled out any Qt-NSS code a while ago. I remember this because when the LSB wanted to standardise on NSS, we reported we could never use it. I don't know if the circumstances are still the same. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] fennec(Illegal instruction) issue on MeeGo
On Tuesday, 7 de December de 2010 21:47:48 imdat.so...@nokia.com wrote: On Dec 7, 2010, at 15:38 , ext Auke Kok wrote: On 12/07/10 01:25, Paul Li wrote: Hi All, I met an issue with fennec on MeeGo, I recompiled this app with ‘-march=armv7-a -mtune=cortex-a8 -mlittle-endian -mfpu=vfpv3-d16 -mfloat-abi=softfp’ and ‘-march=armv7-a -mtune=cortex-a8 -mlittle-endian -mfpu=vfpv3-d16 -mfloat-abi=soft’. Both of them met the following issue: Program received signal SIGILL, Illegal instruction. 0xa144 in __aeabi_d2lz () Could anyone give me some suggestions? Thank you. :) you broke it. illegal instruction means that you instructed the compiler to generate processor instructions that are invalid for your processor type. If the app was running (i.e. you didn't get that when you started), then it can also mean that your stack was corrupted, resulting in an illegal instruction on the stack. Check whether you did anything on your stack that might have negative impact on stack consistency. Stack is not supposed to contain instuctions. But it could be that the stack got corrupted and a return went to the wrong address. I looked at my __aeabi_d2lz (in libgcc_s.so) and I couldn't find any instructions that wouldn't run in most ARM processors. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] fennec(Illegal instruction) issue on MeeGo
On Tuesday, 7 de December de 2010 02:59:46 Paul Li wrote: Hi All, I met an issue with fennec on MeeGo, I recompiled this app with '-march=armv7-a -mtune=cortex-a8 -mlittle-endian -mfpu=vfpv3-d16 -mfloat-abi=softfp' and '-march=armv7-a -mtune=cortex-a8 -mlittle-endian -mfpu=vfpv3-d16 -mfloat-abi=soft'. Both of them met the following issue: Program received signal SIGILL, Illegal instruction. 0xa144 in __aeabi_d2lz () Could anyone give me some suggestions? Thank you. :) Can you tell us which instruction that was? In gdb, type after the crash: x/i $pc -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Downgrading to X1.8 in Meego 1.1
On Sunday, 28 de November de 2010 05:30:10 Ash wrote: Has anyone had any luck downgrading the X version to 1.8 using Meego 1.1? If so, any tips on how we could do this? Note that downgrading will probably put you in violation of the MeeGo Compliance spec. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Behavior of ld in MeeGo (was: Re: Linking of X libraries in meego)
Em Sexta-feira, 26 de Novembro de 2010, às 09:38:52, Pertti Kellomäki escreveu: /usr/bin/gcc -Wall -m32 -lX11 -lXtst -lXi CMakeFiles/fala_pixelchanged.dir/main.c.o -o fala_pixelchanged The reason for the linker complaints is that the X libraries precede main.c.o in the command line. At the point where the linker sees the libraries, there are no references to symbols in them, so the linker just discards the libraries. That's a bug in CMake then. This is an established practice that the libraries must be listed in the reverse order of dependency (usually -lc is last). This is required by linkers, since they may throw away the symbol table from a library when they're done with it. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [Meego-Dev] Dialer could not be launch. Does i missing something when i compile the app with ARM in Meego
On Thursday, 25 de November de 2010 09:14:05 Tom Chen wrote: the dialer.org is original one in Meego release 1.1, the dialer is build by me. when i copy the dailer to my N900 instead of original, the dialer app could not be launch when i press the phone icon in main interface, nothing happened. i try to launch the both of them from terminal, but it's failed also. What was the error from the terminal? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] why my text display scratched
Em Quarta-feira, 24 de Novembro de 2010, às 09:28:29, Leo escreveu: Hi Joern: [?] to hear that, I think we'd check the component one by one, QT depends on the Xlib and X extension, I will do the test to check whether it's ok if I draw the string via Xlib, and to make clear which level it happened. Make sure you're using standard, modern client-side fonts (fontconfig, freetype), not old-style X server-side fonts. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] why my text display scratched
Em Quarta-feira, 24 de Novembro de 2010, às 10:47:17, joern escreveu: So why don't we use the N900 SGX driver generally? Does anybody knows the difference beteween the official TI driver and the N900 Nokia ones? Because the driver is patched to hell by the different device vendors to cope with their specific software and hardware specificities. I don't think anyone has a full view of the patches applied and bugs fixed. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] why my text display scratched
On Thursday, 25 de November de 2010 04:22:08 Leo wrote: Must we use the Ti driver? whether we can write framebuffer directly instead of TI's driver? Or any other methods Several days before, my touchscreen can not work, so I also do the similar workaround to fix it. If some one familiar with this part, please help us! The raster engine wouldn't be enough. You can try it, but it's likely that we won't reach the performance required for the smooth animations we want to have. We need the OpenGL ES drivers. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] compiling qtwebkit in meego
Em Terça-feira, 23 de Novembro de 2010, às 10:47:28, Paul Li escreveu: Hi all, I met an issue when compiling qtwebkit in meego and pls help. When chroot meego: collect2: ld terminated with signal 11 [Segmentation fault] qemu: uncaught target signal 11 (Segmentation fault) - core dumped When compiling on board: collect2: ld terminated with signal 9 [killed] so I cannot compile it successfully, could you give me some suggestions? Sounds like the OOM killer started doing work. You need to add more memory to complete the build. Here's the output from time trying to link it on my Core-i7 workstation: 10.17user 1.01system 0:11.31elapsed 98%CPU (0avgtext+0avgdata 3280896maxresident)k 24inputs+64296outputs (0major+288081minor)pagefaults 0swaps As you can see in maxresident, it used 3 GB of RSS. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Compiling Qt 4.7.1 on Meego?
On Monday, 22 de November de 2010 05:04:10 Carl Snellman wrote: ./configure -meego There's no such option (-meego). You must pass a lot more options to configure and you must pass one option to make install to make it install inside the sysroot. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Compiling Qt 4.7.1 on Meego?
On Saturday, 20 de November de 2010 00:59:01 Carl Snellman wrote: sudo zypper install libx11-dev but no package found. Also tried to find it using 'sudo zypper packages' listing and 'sudo zypper search' Does anyone know how I can find the package needed? The package is libX11-devel (capital letter X, devel not dev). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Compiling Qt 4.7.1 on Meego?
On Friday, 19 de November de 2010 22:22:38 Carl Snellman wrote: Hey, I'm trying to find any instructions how to compile Qt 4.7.1 from source on Meego Netbook UX device (Lenovo S10-3t), with Meego-SDK installed. So I would have few basic questions: - are there 4.7.1. packages available anywhere? Trunk should have them. - is there a specific repo for meego Qt (similar to git://gitorious.org/+qt-developers/qt/x11-maemo.git ) No. MeeGo is just X11, so the official releases and mainline repository apply. The only missing thing is the XInput2 touch hack, which isn't in MeeGo yet. We're working on it. - where could I find the dependencies I would need to install prior to compilation? Usually by trial and error. That's what I do. Look at the configure output of no and find out what you missed. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
