>>> Is it? The framework, yes, but I think the actual virtual keyboard and >>> handwriting recognition plugins are closed. >>> >>> >>> >> The input framework is OSS and it includes a example VKB. I >> believe the example VKB is different from what is included >> in ITOS. >> >> > Has anyone had any problem ever with the example VKB? > > In my testing it has worked fine. My intention was to say to Marius that the "actual virtual keyboard" included in ITOS is still closed, but hildon-input includes a functional VKB nevertheless.
>> >> The layering violation is including a function >> hildon_gtk_im_context_show() inside *gtk-2-0*. And the call for >> >> > What's the problem? Why we could not have our own custom functionality > in our Gtk+ tree? > > It breaks API and ABI compatibility, and makes it very probable that future ITOS editions are not binary compatible with applications compiled with current version. It becomes a maintenance headache for Nokia when you cannot upgrade to new versions of gtk+2.0 before extracting all the modifications from the old versions. If adding hildon_* functions to gtk is not a problem, why bother creating a libhildon in first place? Custom functionality in gtk is evil. Adding functionality to gtk that have been coordinated with upstream to be added in future versions of gtk is good. _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
