An after-thought. These days, a critical provision of GUI support involves adaptability for form factors and methods of interaction (e.g., tablets, touch, and audio controls) as well as provisions for internationalization and assistive technologies including text to speech, audio context and position announcement, speech to text and speech control as well as interoperability and customization with assistive technologies.
That would be very important in a roadmap for permissively-licensed UI frameworks/libraries and a powerful contribution in the context of public good. - Dennis -----Original Message----- From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] Sent: Tuesday, September 8, 2015 08:12 To: general@incubator.apache.org Subject: Permissive UI Libraries (was RE: [NOTICE] corinthia ...) Designing a cross-platform UI library is not a trivial task and I am certain the false starts far outnumber the few notable successes. Although the idea does make my heart pound, that also reminds me I may not have the youthful vigor and developer chops that would make such an undertaking realistic on my part. On the other hand, being in on one from the beginning would be an exciting experience. There is also a cautionary issue. When it comes to lean development and a startup project, the obvious teething approach is via HTML5 and the JavaScript route. Maybe client-side is under node.js, etc. At some point there is a moment of truth that suggests models can be handled well in portable code, but views and their controllers tend to be best adjusted to the platform and context of use, not just for performance but to satisfy scaling and lifecyle concerns on the platform and always confirming what users already know in their comfort zone. So, even with a common, permissive view, there must be a way to rely on platform resources in a manner that provides UX familiarity and critical GUI performance. 'Lo and Behold! There are permissive UI libraries, and they are part of an *Apache* project. And some of the work on platform adaptability has been done. It is a major part of Apache OpenOffice. There are two layers. - UNO is plumbing used throughout Apache OpenOffice. While it is object-oriented and C++ in the main, it is a COM-alike layer and that makes it amenable to extraction and reuse/interop with Java, Python, certain EcmaScript implementations, etc. There is much experience with this layer. There would probably need to be more work done to free this layer more (and have binary-compatibility with COM). - VCL the Visual Control Library, is designed to operate above platforms such as Windows and OS X using native provisions. It also has a plug-in mechanism, used on *nix distributions, to map to other GUI frameworks, including GTK and KDE. It is thought to be workable with Qt as well, and more/other (adapter) plugins are possible. The plug-in mechanism may need to be extended for multi-platform employment, especially with regard to platform and GUI discovery. Freeing these as separate libraries would be a project in itself. I am certain that both UNO and VCL would morph, and it would be useful to see how well interface versioning could work in any such progression, preserving legacy use from substantial products, such as Apache OpenOffice. It is not a short-term activity, and it would have to be grown from some small core and expanded through carefully-developed feature-set levels. I think this could be a worthy effort. To have tested, confirmed development for use outside of the current host application would be valuable in both directions. OpenOffice is much bigger than this, even though it provides a worked, archetypical case. It would be overpowering to attempt this from within the project along with everything else there is to deal with. But a parallel effort on the side could have a synergistic outcome. This is not high on *my* bucket list; it is not entirely off that list either. It is not on the "real-soon-now" list either. I suggest this is worthy of investigation by those who are keen about GUI interfaces. - Dennis -----Original Message----- From: Greg Stein [mailto:gst...@gmail.com] Sent: Monday, September 7, 2015 02:38 To: general@incubator.apache.org Subject: Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, jani, louis, pmkelly On Sep 7, 2015 4:12 PM, "Jochen Theodorou" <blackd...@gmx.org> wrote: >... > I am not sure that approach is realistic. I mean, if you say it must be optional and not required, then there must be an existing alternative. And that alternative must be not LGPL. If there is such a toolkit, then why not go with that right away? The project has to manage its resources well. Exactly. Without an alternative, then you have a pile of code that doesn't meet any user expectations. If it can be released as a library, for downstream users to produce an editor, then okay. But an releasing an editor with no UI is kind of a non-starter. :-( Given the UI landscape, and its licensing, I can see why Corinthia would like to host elsewhere. One day, we'll see some permissive UI libraries.... Cheers, -g --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
