Riku Voipio wrote: > >>>> 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. >
Yep, I agree that custom functionality that upstream accepts is always best solution. However, it might well be that upstream is not interested at all on some functionality or it can take year or two to get a patch accepted. It may happen that due to release schedule there is no time to wait or depend on single busy control point like most libraries tend to have. // Tapani Pälli -- Software Engineer Open Source Software Operations _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
