incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: Permissive UI Libraries
Date Tue, 08 Sep 2015 15:55:03 GMT
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.hamilton@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:gstein@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" <blackdrag@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message