Hi I'm curious,
How modular is the LibO code base? In other words, do we have separate
* document model (Model)
* page renderer | slide renderer | drawing renderer &c. (View)
* bunch of action modules (one for each user action), that can be rendered
as menu/context items, toolbar items, or API calls (Controller)
Just wondered, because I think it presses on the need to build a solid and
flexible foundation that will enable efficacy and ease of restructuring LibO
to implement great plans like Mirek's Citrus.
If the code is a jungle, we'd be better advised to make it fit for purpose. A
goal and a roadmap would be a great idea. Architectural simplification would
also leave some breathing space for the design team to test and refine Mirek's
ideas (and competing proposals) with users.
Hope that makes sense?
Cheers,
Noh
--
Unsubscribe instructions: E-mail to design+help@global.libreoffice.org
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
Context
- [libreoffice-design] Model View separation? · Greg
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.