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 >> (Jay) >> + 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: http://nabble.documentfoundation.org/Minutes-of-the-Design-Hangout-2016-Jun-17-tp4186453p4186479.html Sent from the Design mailing list archive at Nabble.com. -- To unsubscribe e-mail to: [email protected] Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/design/ All messages sent to this list will be publicly archived and cannot be deleted
