"Maliit aims to be _the_ input method project for MeeGo and other GNU/Linux-based embedded/mobile platforms" from www.maliit.org Originally Maliit was a part of Meego/Harmattan, but we are now establishing it as a stand-alone project, where these platforms are considered downstream consumers of it. Project name: Maliit Requested services: bugzilla, mailing lists, file upload space* Member approval: Jon Nordby (jonnor) Mailing lists: maliit-discuss, maliit-bugs, maliit-announce Mailing list listadmin: Jon Nordby (jonnor) Bugzilla default assignee: maliit-bugs (if possible) Bugzilla project owner: Jon Nordby (jonnor) Bugzilla components and descriptions: Framework - Issues with the Maliit framework, including maliit-server, engines, feedback framework Plugins - Issues in the provided reference plugins Documentation - Documentation issues (API docs, SDK, website and wiki) General - General issues * We use gitorious for git repos: https://gitorious.org/Maliit
Please let us know if there is something we can or need to do for this to move forward as quickly as possible.
Ping.
It's been over a month now, and this bug has been triaged at all. Could we please get some visible feedback here? Thanks!
Another month has passed. Has any decision been made?
First off, sorry about the delay; this one fell between the cracks. Secondly, given MeeGo's ... current status ... have you talked much with other mobile platforms or toolkits about possibly integrating Maliit? I guess I'm mostly worried that this project will fade with MeeGo. If it's a viable long-term project rather than just a dump of the Harmattan IM, then I'd be more than happy to host it.
(In reply to comment #5) > First off, sorry about the delay; this one fell between the cracks. Secondly, > given MeeGo's ... current status ... have you talked much with other mobile > platforms or toolkits about possibly integrating Maliit? We're trying to convince KDE folks to adapt the Maliit framework for their Plasma Active project. Or GNOME demo in April was not convincing enough for GNOME folks though. > If it's a viable long-term project rather than just a dump of the Harmattan IM, then I'd be more than happy to host it. See, that's a chicken-egg problem here: In order to look attractive to other downstreams, we need to get rid of Harmattan/MeeGo smell. In every single discussion so far, we've been confronted with "But aren't you Harmattan (MeeGo) only?", and it gets tiring. We have our own website but lack the independent infrastructure for mailing lists and bugzilla (we depend on Nokia and MeeGo facilities here and I don't really have the time nor energy to maintain my own bugtracker).
(In reply to comment #6) > We're trying to convince KDE folks to adapt the Maliit framework for their > Plasma Active project. Or GNOME demo in April was not convincing enough for > GNOME folks though. Did you get any feedback from GNOME people as to why it wasn't convincing enough, and if so is there any chance for Maliit to play any role in GNOME, or is that opportunity gone now? And how is the KDE conversation progressing? If you manage to get accepted as the reference IM for Plasma Active, would it then make more sense to shift Maliit to be a KDE project, or would you still keep a keen cross-desktop focus? > See, that's a chicken-egg problem here: In order to look attractive to other > downstreams, we need to get rid of Harmattan/MeeGo smell. In every single > discussion so far, we've been confronted with "But aren't you Harmattan (MeeGo) > only?", and it gets tiring. > > We have our own website but lack the independent infrastructure for mailing > lists and bugzilla (we depend on Nokia and MeeGo facilities here and I don't > really have the time nor energy to maintain my own bugtracker). Yeah, that's understandable and not entirely surprising either. Unfortunately though we can't really just act as a clearing house for projects to make them seem like cross-desktop projects and launder the 'Harmattan/MeeGo smell', as you put it. Sorry if this sounds harsh: it's not meant to slate Maliit, but if Samsung came and offered the Bada IM framework or OpenMoko theirs, or etc, then we'd have three separate mobile IM frameworks without wide adoption. Usually we use fd.o to document adoption after the fact: multiple desktops use a project and thus we offer them hosting, rather than the other way around where a project gets hosting on fd.o and then uses that to advertise to potential users. Again, sorry if any of this sounds harsh: Maliit certainly looks useful from the feature list and the screenshots look quite neat as well. But we have to be fairly picky in what we accept, after having been burned numerous times in the past.
(In reply to comment #7) > (In reply to comment #6) > > We're trying to convince KDE folks to adapt the Maliit framework for their > > Plasma Active project. Or GNOME demo in April was not convincing enough for > > GNOME folks though. > > Did you get any feedback from GNOME people as to why it wasn't convincing > enough, and if so is there any chance for Maliit to play any role in GNOME, or > is that opportunity gone now? I think the main issue was that they had already made a decision on how an virtual keyboard should be implemented: inside the Gnome Shell. They argued you could not get the look'n'feel right if not done in the shell. We showed a working VKB that looked exactly like their mockup specified, demonstrating that this is not correct, but that was apparently not enough. For Maliit to play an official role in GNOME seems unlikely to me in the short term. Of course Maliit can still be used in GNOME and can still be integrated with it as third party software. > If you manage to get accepted as the reference IM for Plasma Active, would it > then make more sense to shift Maliit to be a KDE project, or would you still > keep a keen cross-desktop focus? Our goal is set: all GNU/Linux based embedded/mobile platforms, as said in the first post. The main value in Maliit is enabled by the framework that sits between application and the input method. This means you can add new input method plugins (like a virtual keyboard), or support for new application toolkits without touching any of the other components. Add support for the Enlightment toolkit -> works for all input method plugins on all platforms. Add a Dasher input method plugin -> works for all supported application toolkits on all platforms. I think this is one of the reasons it makes sense for Maliit to be on FDO, compared to many other IM solutions.
It was also rejected by GNOME because IIRC it would make GNOME core depend on Qt / QObject or something like that. Maliit seems to be really cool, but it has to fit.
The GNOME discussion was here: https://bugzilla.gnome.org/show_bug.cgi?id=612662 Maliit depends on Qt, so yes, the package group/compilation you want to add it, will get an indirect Qt dependency.
Closing, Maliit has had its own infrastructure for a while now. https://wiki.maliit.org/Infrastructure
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.