[MeeGo-inputmethods] Next IRC meeting: How can we simplify development and maintenance of input contexts?

[Michael Hasselmann]

Heya,

please find the (slightly redacted) IRC log from yesterday in the
attachment. I also summarized the outcome here:

http://wiki.meego.com/Maliit/Meetings

regards,
Michael
-------------- next part --------------
== MeeGo Input Methods IRC meeting, March 29th 2011 ==
Topic: How can we simplify development and maintenance of input contexts?
Participants: Michael Hasselmann (Openismus), Jon Nordby (Openismus), Andy Ross (Windriver), Pekka Vuorela (Nokia), Gary Birkett (Collabora), Robin Burchell (Collabora)

Meeting starts at 7pm UTC.

<mikhas>andyross, pvuorela - you know each other already?
 or need to introduce?
<andyross> Not directly, no.  Hi. :)
<pvuorela> hi :)
<mikhas> Well, Pekka's our lead developer and has been with the project in Harmattan since the beginning.
<andyross> Yup, recognize you from the git logs. :)
<mikhas> He's also the one knowing the in and outs of Qt's inputmethods
 andyross is working on Tablet UX and trying to get inputmethods to work in the browser for example
 perhaps you can start by mentioning a bit of the patches you had to provide, andyross
<andyross> Sure. There are only two at this point. One is a forward-port of a fix we've been carrying for a while (can't find the BMC bug number offhand) which stores the "current orientation" in MInputContext instead of MInputMethodState.
 Qt apps obviously don't have a working MInputMethodState.
<mikhas> (BMC#13375)
<pvuorela> http://meego.gitorious.org/meegotouch/meegotouch-inputmethodframework/merge_requests/123
<andyross> The other is a hack: the dismiss logic in meego-qml-launcher (which provides it as a library to the browser too) needs pulse notification of "keyboard activity" to avoid dismissing.  I patched that into MInputContext with an extra signal, but that's not an upstream-ready patch
<mikhas> Can you perhaps tell us a bit more about the browser in tablet UX?
<andyross> I don't do the browser directly, that's handled by a team in PRC.  I consulted a bit with them about how to get the integration done with the core stuff in qml-launcher.
<mikhas> OK, that's fine. thanks
<mikhas> now, perhaps pvuorela can give a brief summary of Qt inputmethods, and what we added to it?
<pvuorela> well, you probably know the public interface to input method side in qt is QInputContext and we have tried to keep our stuff replaceable. so the extensions so far live in meegotouch.
 and that is what we follow for rotation changes.
 most other extensions are smaller details like allowing apps to modify the looks of the keyboard by overriding key labels or adding a toolbar on top of the keyboard.
 but the meegotouch dependency is now what is causing these problems more or less.
<andyross> It's a growing pain, yeah.  The dependency itself is treatable, it's the side effects: for a while the theme initialization in MInputContext was creating an entire unused MApplication object (which created a dbus interface which collided with other instances of the same app, thus defeating the pop-to-foreground feature in qml-launcher), for one example. :)
<andyross> MInputMethodState is the other current thorn.  That class is in libmeegotouch, but a lot of features seem to depend on it.  The orientation patch was one.
<andyross> Yeah.  Honestly my favored trick would be to add all the features to MInputContext, and expose them via signals/slots, leaving MInputMethodState as a simple wrapper.  Not sure how many people would agree though
<mikhas> I guess pvuorela has something against this :-)
<andyross> For an app that wants to use these features, MInputContext is really part of the public API anyway.  You have to instantiate it explicitly so you know it's there.  And the QInputContext instance is always available everywhere, so it's convenient code-wise.
<pvuorela> well, i'd like to avoid these assumptions for MInputContext. using signals/slots would make it a bit better, but would require to either connect to them or call with metaobject stuff.
 andyross: explicit instantiation is not really true. for us it's an environment variable that loads it nowadays.
 (QT_IM_MODULE)
<mikhas> Actually, we should aim towards reducing the business logic inside MInputContext itself. Because the more we add there, the more work we create for a GTK+ or Clutter input context, for example.
<pvuorela> true also.
<mikhas> I feel that an extra library - if provided separately from the meego-im-framework stuff, would look cleanest
<andyross> Yes, but if you're going to do anything with it you have to know that it's loaded and the right type.   So IMHO that's isomorphic to just calling qApp()->setInputContext() yourself.  But that's not really my point.  I'd be happy to throw method invokations at a soft-ocnfigured input method as long as there was a signature to query that told me it was the right kind.
 No complaints about a separate library either.  Though it's significantly more code to write and maintain.
<andyross> And +1 for shrinking MInputContext.  Ideally it's just a wrapper around the server IPC, plus whatever fixups need to happen for Qt-specific behavior.
AGREEMENT: We need to provide a fully working alternative for MInputMethodState
 And this would also fit with our plans to offer better support for plain Qt, QML (and GTK+ on MeeGo)
 We can decide to add the less important features (toolbar and keyboard customization) at a later point, for example.
<pvuorela> i'd feel there's some pressure to get almost everything to qt components too.
 but, +1.
<mikhas> Oh right, sorry - for me QML == Qt components
<pvuorela> what i'm worried about, is how fast we could have such new library included in meego and elsewhere..
<mikhas> But yes, it is a separate issue, and Qt components is actually easier for us to target, right?
<pvuorela> it is.
<andyross> Note that the tablet apps don't use the qt components stuff at all.  They're a separate framework (if you can call it that -- it's pretty lean).
<mikhas> so plain QML for now?
 any plans to go Qt components?
<pvuorela> all the same. if qt components can implement this stuff without meegotouch dependency, then so can apps using plain qml.
<mikhas> OK, that's great!
<andyross> Pure QML, though with some shared components.  The qt-components was maturing at the same time, so it wasn't an option.  I think it's wait-n-see as far as whether it will be picked up.
<mikhas> well, for us it only means that the library needs to be QML-consumable
 IE, declare the properties and whatnot
<pvuorela> not a requirement. app developers can connect themselves with c++ too.
<mikhas> I am sure that pvuorela can fill in the blanks where needed, as I am not involved with Qt components.
<andyross> Right.  Which, FWIW, argues in favor of a meta-object API on MInputContext. :)  You can get that already from QML; there's an inputContext property on QApplication :)
<mikhas> If we want to move on  -- my next agenda item tells me to ask our GTK+ friends, Carlos and Claudio from Igalia, for a brief status report on the GTK+/MeeGo integration story.
 But both couldn't make it today. However, jonnor should be able to tell us something about this.
 Jon's been working on MeeGo Input Methods since the beginning of this year.
* andyross doesn't have any current need/interest/involvement in gtk+, but if this work invovles nailing down a better specification for the dbus IPC, he stands ready to applaud.
<jonnor> I don't have much details, Claudio/Carlo have those. However, Claudio has started on updating the existing gtk inputcontext to the current DBus API
 I asked explicitly if there looked to be any issues with this, but I have not gotten any feedback yet
<mikhas> ok, thanks jonnor
 next thing I wanted to ask: should we focus on cleaning up the D-Bus API, or hide it away altogether?
 We currently do sent a QDataStream over the wire, we don't use session bus, ... all those un-D-Bus-y things we do.
<andyross> Clean up, please.  Since there are already going to be two client implementations, I don't see that another layer of abstraction has value.
<pvuorela> i'd go with cleanup too.
 though wouldn't consider private connection as something needing a cleanup.
<mikhas> it was not the private connection, rather the socket
 andyross pointed out that the second D-Bus connection was created through a bug, though I already forgot the details.
 the socket is not really optimal for non-handhelds, or how to put it :-)
<pvuorela> why's that?
<andyross> It's extra code (instantiating a whole glib-dbus handler instead of freeloading on the existing one in QApplication).  It can't be traced, which was an annoyance to me.  I'm pretty sure the reason it was done was because glib-dbus and Qt can't share the same bus socket.
<mikhas> ah yes, thanks!
<andyross> Seems the Right Thing here would be to just rewrite the dbus handling using Qt.
<mikhas> andyross, we'd like to do that - if there was peer-to-peer support in Qt's D-Bus
<andyross> I looked briefly, it's a ton of code motion but doesn't seem to have any gotchas (it helps that the XML files are "live", so I know they're right).  I might give this a shot myself in the next few weeks.
<pvuorela> andyross: actually we first had a qt implementation but then found out that even qt 4.7 didn't really support direct connection though it had an API for it.
<mikhas> we should target that for 4.8
<andyross> Is direct connection a requirement?  What's wrong with just using the regular session bus?  Are latencies a problem?
<mikhas> latencies and security
<pvuorela> yes.
<mikhas> we could negotiate latency, we cant negotiate the latter, in Harmattan
<andyross> dbus security has an existing solution in policykit though.  Latencies I guess I'd believe, but would be good to measure too.
<mikhas> I'd be fine, however, to make this peer-to-per optional?
 *peer-to-peer
AGREEMENT: We clean up the D-Bus API cleanup, instead of further abstraction
<pvuorela> so im server would listen to both?
<andyross> OK, so this is more complicated than simple code motion.  I'll send email to the list before I do anything.
<mikhas> pvuorela, I was thinking compile-time option only
<andyross> im-uiserver is already listening to the session bus by virtue of being a dbus client, so that's not a problem
<mikhas> ok
<jonnor> mikhas: I don't see why it could not be runtime switch (cmd line option)
<mikhas> well, I will let andyross make a proposal, and we can discuss that in our team :-)
<pvuorela> but maybe this p2p vs session bus wouldn't be the most important thing right now.
<mikhas> agree
<pvuorela> and 4.8 can make things better if we get back to using qt's dbus interface.
<andyross> agree in principle, though it's kind of a pet peeve... :)
<jonnor> agreed. For Dbus cleanup I see two things as neccesary: 1) using native dbus types instead of serialized qt datatypes, and 2) documentation
<pvuorela> jonnor: +1
<mikhas> thanks jonnor
<andyross> Definitely documentation.  The serialized attribute hash is a little weird, but I don't see it as a big problem.  It's extensible.
<mikhas> but D-Bus has a map type?
<andyross> It does, though I don't know the details.
<andyross> (see dict entry docs under http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-signatures I think)
<jonnor> andyross: You cant expect to be able to deserialize it without using Qt though?
<jonnor> or well, I guess the serialization done by Qt might be well-defined (haven't checked)
<andyross> jonnor: Well, without knowing the Qt serialization protocol yeah.  Sorry, I forgot the Gtk+ side.  Yeah, that's a problem there.
<mikhas> Qt reserves the right the bump the protocol version with minor releases, I think
 whenever new types would get introduced, for example
 let's try this dictionary type
 we know where to ask for help
AGREEMENT: Check QtDBus situation in 4.8 and switch to Qt's D-Bus interface, if possible.
AGREEMENT: Use native D-Bus types instead of (serialized) Qt datatypes, provide documentation for the D-Bus API.
<jonnor> so, should we assign names to these two tasks? :)
<jonnor> at least someone needs to be responsible for making sure it gets done
<mikhas> well, I will write a summary of this meeting
 then we'll have a nice table in the wiki where everyone can put his name
<jonnor> ok
<mikhas> and I will keep annoying people until all tasks are assigned ;-)
 you can then take over and annoy anyone who doesnt deliver ;-)
 lcuk will happily help with that part, I am sure
<jonnor> sounds like a plan.
<mikhas> One last item for today (we're nearing the 1h mark) was asking about the features we deeply burried inside MeeGo Touch
<lcuk> that sounds reasonable, at present I am pondering who to poke about the qtdbus elements and have a few people in mind
<mikhas> most prominently: focus widget relocation and certain specifics to focus handling
 pvuorela and I - long long ago - wanted better support in Qt for inputmethods in QGraphicsView
* andyross is secretly hoping that the requirements will turn out not to include direct-connection after all and we can just use the session bus as the creator intended.
<mikhas> stuff like tracking focus changes (we should check those old mails again, maybe)
<lcuk> mikhas, I was going to file a whole new set of related bugs based on the current tablet ux implementation
<mikhas> can we salvage anything from MeeGo Touch here, or does each toolkit need to implement these features without any support from us?
 lcuk, "thanks" I guess, even if it's more bugs for us ;-)
<lcuk> purely because the same works on LMTand broken on QML
<mikhas> pvuorela, what's your experience so far with reimplementing MeeGo Touch features in Qt components?
<pvuorela> mikhas: well, lot of stuff is reimplemented.
<mikhas> was it easy?
<pvuorela> uses now preeditinjectionevent from meegotouch for word activation.
 it seems it's been relatively easy to do stuff on qml.
<pvuorela> about the little things we have on meegotouch, i think qt should be the target.
<mikhas> +3 for mentioning "upstream"
<pvuorela> i've tried to push that a bit.
<mikhas> we can perhaps mention the efforts on the wiki
 others can help pushing
<pvuorela> hopefully we'll see something. or we make those ourselves :)
<mikhas> s/efforts/current contacts and what
<pvuorela> i'd maybe not mention on wiki to bug this or that guy.
<mikhas> heh, I totally would =p
 anyhow, we got some training in how to get things into Qt I guess
<pvuorela> i'd guess you're the most recent qt developer here :)
<mikhas> that's it from my side - thanks for everyone joining the meeting. we'll do this again the future I hope - perhaps once or twice a month
<andyross> Sounds good.  Have fun all
<jonnor> Did we reach a conclusion about how certain API will be provided to QML and Tablet UX apps?
 will we put signals/slots on the inputcontext?
<pvuorela> i don't think we got a conclusion on that.
<mikhas> no conclusion yet
 only that it cannot be MInputMethodState
<pvuorela> though true that it will be a bit better than making whole MInputContext public.
<mikhas> We can try to have a discussion about that in the mailing list
<pvuorela> sure.
NO AGREEMENT: Is it better to provide needed API through signals/slots in inputcontext or is it better to provide a separate library?
<jonnor> andyross: you have the requirement/usecase, perhaps you can initiate that discussion?
 but ok, I guess we've covered everything then :)
<andyross> I have ideas, not so much a requirements list.  But sure, I can write something up.  One note is that I'm going to be away on vacation until wednesday of next week, so it will likely have to wait until then.
<mikhas> that's fine
 I'll get jonnor or lcuk to remind you ;-)
 have a nice evening everyone!
 or day, or whatever
<lcuk> \o ta mikhas :)

Meeting ends at 8.15pm UTC