Re: [MeeGo-dev] libmeegotouch in 'MeeGo Core' in 1.3?
On Tue, 2011-05-10 at 07:14 -0700, Arjan van de Ven wrote: On 5/10/2011 2:16 AM, Murray Cumming wrote: I hope to see some official acceptance for Maalit in Meego 1.3. After all, it's gotta have a serious input method framework. The libmeegotouch dependency seems to be the only problem so far. But you need to be loud, clear and direct to Nokia that they need to devote time to removing that libmeegotouch dependency from Maalit. Since it was Nokia itself that told us a year ago that libmeegotouch should be designed out... ... I'm pretty sure they know. Good, but that's a long way from a direct discussion about the keyboard and what is needed to get it into Meego. We are all here. I don't see why we can't have a clear public conversation about things rather than guessing at what each other thinks. That's not the best way to make sure concrete things actually happen. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ 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 May 10, 2011, at 12:48 PM, Thiago Macieira wrote: 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/ Okay. My wording was bit off but the main point about the libmeegotouch remains. -sakari ___ 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 May 9, 2011, at 4:01 PM, Michael Hasselmann wrote: On Mon, 2011-05-09 at 14:49 +0200, Carsten Munk wrote: As we know, in the future Qt versions the QtGraphicsView will be deprecated in the favor of SceneGraph. Never heard of this. AFAIK, the scene graph doesn't even exist as an API yet. What's your source? I believe http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/ should help answer that question. It mentions a *vision* that Qt will be less QWidget centric. It does not say that QGraphicsView will be deprecated. We should be more careful with such unfounded speculations, really. 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. So yes, we need to start the preparation now. -sakari regards, Michael ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] libmeegotouch in 'MeeGo Core' in 1.3?
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. 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. Also, if you followed a strict deprecation cycle (where modules first need to be marked as deprecated before they can be removed in the next version), then QGraphicsView can only go away with Qt 7. 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. 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. regards, Michael ___ 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 5/10/2011 1:42 AM, 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. regardless of that, for MeeGo libmeegotouch is not our preferred way of writing applications, or even a supported one. so cleaning that up is a target anyway. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] libmeegotouch in 'MeeGo Core' in 1.3?
On Tue, 2011-05-10 at 01:45 -0700, Arjan van de Ven wrote: regardless of that, for MeeGo libmeegotouch is not our preferred way of writing applications, or even a supported one. so cleaning that up is a target anyway. As Meego 1.3 is planned for 6 months from now, that doesn't seem entirely unreasonable. But we need to make sure that everyone understands that libmeegotouch dependencies must be removed from anything that is being proposed as part of Meego. And that work needs to start now if it has a chance of being done in time. I'm most concerned with the the Maalit virtual keyboard (Meego Input Methods). This is a really successful project that's working well, meeting real requirements. It's being developed in a truly open way - a side-effect of my company Openismus being the one doing much of the contracting work for Nokia. I hope to see some official acceptance for Maalit in Meego 1.3. After all, it's gotta have a serious input method framework. The libmeegotouch dependency seems to be the only problem so far. But you need to be loud, clear and direct to Nokia that they need to devote time to removing that libmeegotouch dependency from Maalit. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ 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 Tue, 2011-05-10 at 11:16 +0200, Murray Cumming wrote: On Tue, 2011-05-10 at 01:45 -0700, Arjan van de Ven wrote: regardless of that, for MeeGo libmeegotouch is not our preferred way of writing applications, or even a supported one. so cleaning that up is a target anyway. As Meego 1.3 is planned for 6 months from now, that doesn't seem entirely unreasonable. But we need to make sure that everyone understands that libmeegotouch dependencies must be removed from anything that is being proposed as part of Meego. And that work needs to start now if it has a chance of being done in time. I'm most concerned with the the Maalit Ahem. I mean Maliit, of course: http://wiki.meego.com/Maliit virtual keyboard (Meego Input Methods). This is a really successful project that's working well, meeting real requirements. It's being developed in a truly open way - a side-effect of my company Openismus being the one doing much of the contracting work for Nokia. I hope to see some official acceptance for Maalit in Meego 1.3. After all, it's gotta have a serious input method framework. The libmeegotouch dependency seems to be the only problem so far. But you need to be loud, clear and direct to Nokia that they need to devote time to removing that libmeegotouch dependency from Maalit. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ 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] libmeegotouch in 'MeeGo Core' in 1.3?
On 5/10/2011 2:16 AM, Murray Cumming wrote: I hope to see some official acceptance for Maalit in Meego 1.3. After all, it's gotta have a serious input method framework. The libmeegotouch dependency seems to be the only problem so far. But you need to be loud, clear and direct to Nokia that they need to devote time to removing that libmeegotouch dependency from Maalit. Since it was Nokia itself that told us a year ago that libmeegotouch should be designed out... ... I'm pretty sure they know. ___ 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 May 6, 2011, at 10:45 PM, Michael Hasselmann wrote: On Fri, 2011-05-06 at 11:46 -0700, Arjan van de Ven wrote: MTF as a whole got deprecated with less than minimal resources on it... That's not quite what the git logs say. I count 60 commits for this Friday alone. Looks rather well maintained and active to me (also check [0], [1]) Again, what are the concrete technical reasons? One technical reason is that libmeegotouch is build on top of the QtGraphicsView. As we know, in the future Qt versions the QtGraphicsView will be deprecated in the favor of SceneGraph. Further, the QML/SceneGraph/GLES is the future in Qt and in MeeGo as well. -sakari I have no problems with the decision itself, as I know that we can adapt to that in MeeGo Input Methods. It's even in our own roadmap [2] for 1.3. And there is a certain value in having less dependencies, of course. But the deprecated argument as such is meaningless and arbitrary. There's nothing technical to it. regards, Michael [0] http://www.ohloh.net/p/mtf/factoids/5154599 [1] http://www.ohloh.net/p/mtf/analyses/latest [2] http://wiki.meego.com/Maliit/Roadmap#MeeGo_Keyboard ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] libmeegotouch in 'MeeGo Core' in 1.3?
Hi, On 05/09/2011 01:23 PM, Sakari Poussa wrote: [...] As we know, in the future Qt versions the QtGraphicsView will be deprecated in the favor of SceneGraph. Never heard of this. AFAIK, the scene graph doesn't even exist as an API yet. What's your source? Ciao, Alberto -- http://blog.mardy.it -- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] libmeegotouch in 'MeeGo Core' in 1.3?
2011/5/9 Alberto Mardegan ma...@users.sourceforge.net: Hi, On 05/09/2011 01:23 PM, Sakari Poussa wrote: [...] As we know, in the future Qt versions the QtGraphicsView will be deprecated in the favor of SceneGraph. Never heard of this. AFAIK, the scene graph doesn't even exist as an API yet. What's your source? I believe http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/ should help answer that question. /Carsten Ciao, Alberto -- http://blog.mardy.it -- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] libmeegotouch in 'MeeGo Core' in 1.3?
On Mon, 2011-05-09 at 14:49 +0200, Carsten Munk wrote: As we know, in the future Qt versions the QtGraphicsView will be deprecated in the favor of SceneGraph. Never heard of this. AFAIK, the scene graph doesn't even exist as an API yet. What's your source? I believe http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/ should help answer that question. It mentions a *vision* that Qt will be less QWidget centric. It does not say that QGraphicsView will be deprecated. We should be more careful with such unfounded speculations, really. 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? regards, Michael ___ 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 Fri, May 6, 2011 at 8:06 PM, Shane Bryan shane.br...@linux.intel.com wrote: OK, I'll start, but please don't take this list, or my response to this thread as a complaint to the change away from MTF, but rather observations Have you checked out the mlite library that has some of the stuff you mention? ___ 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 Sat, May 07, 2011 at 07:25:43AM -0400, Ville M. Vainio wrote: On Fri, May 6, 2011 at 8:06 PM, Shane Bryan shane.br...@linux.intel.com wrote: OK, I'll start, but please don't take this list, or my response to this thread as a complaint to the change away from MTF, but rather observations Have you checked out the mlite library that has some of the stuff you mention? If you'll look closer, I mention that at least two of the items I listed are in mlite, in some state of completion. So yes ;) -- Shane... ___ 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 Sat, May 7, 2011 at 10:48 AM, Shane Bryan shane.br...@linux.intel.com wrote: Have you checked out the mlite library that has some of the stuff you mention? If you'll look closer, I mention that at least two of the items I listed are in mlite, in some state of completion. So yes ;) Dret, sorry about that, my 22secs/email budget backfired ;-). ___ 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 5/6/2011 8:04 AM, Carsten Munk wrote: Hi, I was surprised to find libmeegotouch in MeeGo Core package group (as a dependancy, I think) for 1.3. Is this intentional and if not, is it fair game to send patches to help reduce dependancies to libmeegotouch in the core system? Examples are xdg-utils - libcontentaction - libmeegotouch for 1.3, libmeegotouch needs to be removed, so yes, any patches to reduce deps on it are very welcome... ___ 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 Fri, 2011-05-06 at 08:11 -0700, Arjan van de Ven wrote: Examples are xdg-utils - libcontentaction - libmeegotouch for 1.3, libmeegotouch needs to be removed, so yes, any patches to reduce deps on it are very welcome... Who drives that need? What are the technical reasons why it has to go? Please clarify, otherwise it feels like an imaginated need, quite honestly. ___ 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?
2011/5/6 Michael Hasselmann micha...@openismus.com: On Fri, 2011-05-06 at 08:11 -0700, Arjan van de Ven wrote: Examples are xdg-utils - libcontentaction - libmeegotouch for 1.3, libmeegotouch needs to be removed, so yes, any patches to reduce deps on it are very welcome... Who drives that need? What are the technical reasons why it has to go? Please clarify, otherwise it feels like an imaginated need, quite honestly. It was clearly stated (even before feb11) that MTF is deprecated for 3rd party development and QML and Qt Components are the future of development. If it's deprecated and not a MeeGo API it shouldn't be mandatory in compliance and hence MeeGo core shouldn't depend on it. If it was already deprecated in MeeGo 1.2, next step would be removal. There has been email threads where people have been confused if to use MTF or not for apps and personally I think MTF might belong better in a community repository as to not confuse the developer story, along the lines of David Greaves' idea about Surrounds. BR Carsten Munk ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] libmeegotouch in 'MeeGo Core' in 1.3?
On Fri, 2011-05-06 at 11:46 -0700, Arjan van de Ven wrote: MTF as a whole got deprecated with less than minimal resources on it... That's not quite what the git logs say. I count 60 commits for this Friday alone. Looks rather well maintained and active to me (also check [0], [1]) Again, what are the concrete technical reasons? I have no problems with the decision itself, as I know that we can adapt to that in MeeGo Input Methods. It's even in our own roadmap [2] for 1.3. And there is a certain value in having less dependencies, of course. But the deprecated argument as such is meaningless and arbitrary. There's nothing technical to it. regards, Michael [0] http://www.ohloh.net/p/mtf/factoids/5154599 [1] http://www.ohloh.net/p/mtf/analyses/latest [2] http://wiki.meego.com/Maliit/Roadmap#MeeGo_Keyboard ___ 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 5/6/2011 12:45 PM, Michael Hasselmann wrote: On Fri, 2011-05-06 at 11:46 -0700, Arjan van de Ven wrote: MTF as a whole got deprecated with less than minimal resources on it... That's not quite what the git logs say. I count 60 commits for this Friday alone. Looks rather well maintained and active to me (also check [0], [1]) Again, what are the concrete technical reasons? I have no problems with the decision itself, as I know that we can adapt to that in MeeGo Input Methods. It's even in our own roadmap [2] for 1.3. And there is a certain value in having less dependencies, of course. But the deprecated argument as such is meaningless and arbitrary. There's nothing technical to it. not all decisions are pure technical in the sense that you mean it. we want ONE api for apps. MTF is not that. QML is that. after that it becomes a maintenance/etc issue, that we do not want to take on. ___ 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?
In general: Rotation and size/position of the vkb most like need mtf. Also controlling of the screen (dim/blank) you need mtf since at least qmsystem2 is also deprecated. There might be other things which mtf supports and no api is around to do it otherwise. (maybe we should start to gather all that things and find alternatives) - Jeremias Am 06.05.2011 21:48, schrieb Arjan van de Ven: On 5/6/2011 12:45 PM, Michael Hasselmann wrote: On Fri, 2011-05-06 at 11:46 -0700, Arjan van de Ven wrote: MTF as a whole got deprecated with less than minimal resources on it... That's not quite what the git logs say. I count 60 commits for this Friday alone. Looks rather well maintained and active to me (also check [0], [1]) Again, what are the concrete technical reasons? I have no problems with the decision itself, as I know that we can adapt to that in MeeGo Input Methods. It's even in our own roadmap [2] for 1.3. And there is a certain value in having less dependencies, of course. But the deprecated argument as such is meaningless and arbitrary. There's nothing technical to it. not all decisions are pure technical in the sense that you mean it. we want ONE api for apps. MTF is not that. QML is that. after that it becomes a maintenance/etc issue, that we do not want to take on. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] libmeegotouch in 'MeeGo Core' in 1.3?
On Fri, May 06, 2011 at 11:22:02PM +0200, jeremias bosch wrote: In general: Rotation and size/position of the vkb most like need mtf. Also controlling of the screen (dim/blank) you need mtf since at least qmsystem2 is also deprecated. There might be other things which mtf supports and no api is around to do it otherwise. (maybe we should start to gather all that things and find alternatives) OK, I'll start, but please don't take this list, or my response to this thread as a complaint to the change away from MTF, but rather observations from one currently porting their existing, non-trivial, MTF application to QML, and where I am finding gaps that I'm not yet aware of solutions for... With that in mind, here's some gaps I've found so far: - MApplicationService (default DBus process managemet services, used in conjunction with applifed and applauncherd) http://apidocs.meego.com/git-tip/mtf-old/mtf/class_m_application_service.html - MRemoteAction (DBus interfaces to client MAction/QAction for remote invocation by other apps/services) http://apidocs.meego.com/git-tip/mtf-old/mtf/class_m_remote_action.html These first two would definately relieve the complicated and less than ideal current means of having to make system() calls to mego-qml-launcher from our QML apps right now to, for example, launch email client from the contacts client to compose a new email to someone. - MLayout and MAbstractLayoutPolicy (allowing for more than one policy per layout, managing which is active) http://apidocs.meego.com/git-tip/mtf-old/mtf/class_m_layout.html http://apidocs.meego.com/git-tip/mtf-old/mtf/layouts.html - MGconfItem (Access to GConf keys and signals on them changing, though this has been pulled into mlite, so still technically available) http://apidocs.meego.com/git-tip/mtf-old/mtf/class_m_g_conf_item.html - MNotification* (Sending, managing and rendering various messages to the session manager, desktop or other system wide handler. This too has been pulled into mlite, so still technically available, though not yet complete) http://apidocs.meego.com/git-tip/mtf-old/mtf/class_m_notification.html http://apidocs.meego.com/git-tip/mtf-old/mtf/notifications.html - MTheme (CSS based theming with caching and SVG based assets) http://apidocs.meego.com/git-tip/mtf-old/mtf/class_m_theme.html http://apidocs.meego.com/git-tip/mtf-old/mtf/styling_stylesheets.html - The retranslateUI() virtual method on all MWidgets, allowing for live runtime reaction to changes in the Language or Locale http://apidocs.meego.com/git-tip/mtf-old/mtf/class_m_widget.html#a7e9580366ec4fe9d4bd79ec2ecb9ddb8 - The StatusBar shared pixmap. Currently, the MTF status bar is not rendered into the meego-ux apps that use meego-qml-launcher or libmeegoqmllauncher. Simialrly, the meego-ux status bar does not render into MTF applications either. I can only assume there is also no story for plain Qt apps and status bar rendering, since, IIRC, it's not reserving space via ICCCM Struts - Application prestarting... Shane... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
