Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index

sberg wrote
On 06/17/2016 03:47 PM, Heiko Tietze wrote:
Enhancements and proposals
    + Push extensions (Heiko)
      + e.g. tdf#71176, tdf#91874, or color replacer, or overall
paragraph changer etc.
      + Extensions keep the main UI clean and simple but allows to
enhance the app for special use cases
      + Suggestion is to have a separate component/keyword in the
bugtracker for tasks that can be enhancements
      + Find users/coders to work on extensions
      + We have a component extension (kendy), qa team should make clear
what it is used for (Jay)
      + Would need some needDevEval before moving a bug to this component
      + Will bring it up to ESC for pushing it to the community

Just to clarify: You're talking about .oxt extensions here?

Would they have to be?    From the UI Design/UX perspective we should not
care. But from a development, implementation, and maintenance
perspective--worlds of difference.

If the "extension" allows us to modularize  the UI -- and to not install or 
simply disable  "extensions" that the OS/DE directly support--that should
allow for a UI "clean and simple".   It should not matter if that is an
embedded feature enabled/disabled by UI or Expert Configuration, or is
"external" and configured via the Extension manager. 

Take as an example--the LibreOffice "native" dialogs.   Disabled by default
and using the file management provided by  OS/DE.  But for some users--the
OS / DE does not support the use case(s) and they *have* to switch to the
LibreOffice dialogs.

The bigger issue becomes how consistently an "extension" would be maintained
relative to the core UI elements.   It seems our history has been that
"extensions", whether bundled with LO installers or offered via the
Extensions web site,  are treated with benign neglect by the QA and
development cadre. If the developer looses interest--the extension dies.

It would be unfortunate if we end up pushing substantial UI features and
functionality out of the core and into "extensions" and then have the
project disown them.  For this to move forward there needs to be a class of
"extensions", either as OXT *or* embedded contributions, that will have ESC
oversight to assure long term support.

Otherwise great idea.

View this message in context:
Sent from the Design mailing list archive at

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.