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


Le 2010-11-23 14:44, Harold Fuchs a écrit :

"Marc Paré" <marc@marcpare.com> wrote in message
news:ich2tj$ol7$2@dough.gmane.org...
Le 2010-11-23 12:33, Nathan a écrit :
On 11/23/2010 05:37 AM, Rainer Bielefeld wrote:
Marc Paré schrieb:

[...] IMO, the user
should always be left in control of the extensions. If they are so
necessary, then they should be coded in and not be called extensions.

+1

I have a non removable Zulu hyphenation dictionary from 2008, but no
Help.

Rainer

This isnt practical with the user base we service. Each user has
different expectations and needs from LibO, there for each user may need
different plugins, extensions, templates, etc etc. This is giving the
user true control and choice. With that said, the popularity of plugins
in itself(automatic installation, removal, and updating) will be
beneficial to LibO in the general scheme of things.

Agreed.


But then there needs to be
- a *proper* management system so that one's extensions are not blown
away by new versions
- a *proper* scheme for notifying a user when a new [sub-[sub-]...
version of LO invalidates an extension
- a scheme whereby a user can easily remove *any* extension, even those
that came *in the box" with LO
- a scheme whereby a user can easily re-install *any* extension that
came *in the box* with LO and was removed by the above scheme.
- a *proper* scheme whereby users can request notification of upgrades
to *individual* extensions

My main "relationship" with extensions has come from using Firefox. Yes,
extensions are great but it is nevertheless extremely frustrating when
an upgrade to FF comes along that invalidates an extension one has been
relying on for quite a while. LO really must try to avoid this if it is
to rely on extensions in the future.

The same points apply to templates, plugins etc.


Agreed on this as well. We are in the process of re-building the distro. Now is the time to start fine tuning the process of all of these external pieces by which they function. It is important to document clearly the problems and suggest a remedy and someone will step up to the plate and help fix it. We presently have approximately 90 devs (according to a blog somewhere) working on the distro, so once the first official version if out and the pressure is off the devs, they will have a lot to pick from as well as to prioritize.

It would be nice if someone on this thread assembled all of the documentation on one post here once the discussions has concluded. If the subject to the thread does not fit, feel free to move it to a subject line that best suits the discussion. These discussions will surely get lost as the subject line does not even discuss extensions. IMO if you are trying to make a credible statement, I would create a new thread with a more descriptive subject line and continue the discussion there.

Just keep fine tuning suggestions and someone will help present it to the right people.

Marc


--
Unsubscribe instructions: E-mail to discuss+help@documentfoundation.org
Archive: http://www.documentfoundation.org/lists/discuss/
*** All posts to this list are publicly archived for eternity ***

Context


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.