Re: [tdf-discuss] Re: Google now integrates with MSO, what about Libre/OO?
A word of warning when using Google Docs in combination with ODF - Google usually goes with Excel behaviour rather than OOo/LO behaviour. For instance, they've always used the comma for parameter separation in formulae rather than semicolon (although it exports and imports ODF ok), and their random numbers re-randomize every time anything changes, whereas OOo/LO only re-randomize a cell when it changes. There is a more serious problem, that Google Docs will export a non-working ODF spreadsheet if you use an entire column range, e.g. =SUM(A:A), which OOo/LO do not support. Phil Hibbs. -- Don't you just hate self-referential sigs? -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Archive: http://www.documentfoundation.org/lists/discuss/ *** All posts to this list are publicly archived for eternity ***
Re: [tdf-discuss] Re: Google now integrates with MSO, what about Libre/OO?
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 -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Archive: http://www.documentfoundation.org/lists/discuss/ *** All posts to this list are publicly archived for eternity ***
Re: [tdf-discuss] Re: Google now integrates with MSO, what about Libre/OO?
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. -- Thanks for your time, Nathan Heafner -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Archive: http://www.documentfoundation.org/lists/discuss/ *** All posts to this list are publicly archived for eternity ***
Re: [tdf-discuss] Re: Google now integrates with MSO, what about Libre/OO?
On 11/23/2010 02:59 PM, Marc Paré wrote: Le 2010-11-23 14:44, Harold Fuchs a écrit : Marc Paré m...@marcpare.com wrote in message news:ich2tj$ol...@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 I would like to chime in. for the record I will use the term Extensions vaguely but am ultimately referring to plugins/add-ons/extensions/ etc etc. I think, in the world of extensions there are some issues present in very popular open source apps That LibO could attempt to solve to create a seamless user experience. The example listed above was excellent regarding updating the main app and having extensions that are non compatible with newer versions. Heres what I have in mind. 1. How extensions are chosen for Core inclusion. (I think this should be done by user statics, the most used extensions should get consideration for core inclusion) 2. Balancing the core app with the appropriate number of extensions. Some projects leave everything to extensions, leaving the user to install 10 - 20 at a time making a lot of work. 3. Extension licensing, very complex. 4. Core developers contributing to extensions. 5. Plugin repo clean up. I think each time a new version of Lib0 is released, when extensions are deemed to be unusable, the developer can either update the extension or have it removed from the listing, moving it to a archived listing if you will. After typing this up, I've found myself pondering the idea of extensions in an office Suite. Mostly, can an office suite be extended? How? If any of the current features were removed for a fresh install to be offered as an extension, would this create a bad user experience? If we keep all current features in core, what else would there be to extend? -- Thanks for your time, Nathan Heafner -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Archive: http://www.documentfoundation.org/lists/discuss/ *** All posts to this list are publicly archived for eternity ***
Re: [tdf-discuss] Re: Google now integrates with MSO, what about Libre/OO?
Hi everyone, 2010/11/22 T. J. Brumfield enderand...@gmail.com On Mon, Nov 22, 2010 at 2:21 PM, Marc Paré m...@marcpare.com wrote: Le 2010-11-22 14:02, Graham Lauder a écrit : On Tuesday 23 November 2010 06:29:01 Frank Esposito wrote: Will this ever happen with Libre Office? Google Launches Plugin That Fuses Microsoft Office With Google Docs http://techcrunch.com/2010/11/22/google-launches-plugin-that-fuses-mic rosoft-office-with-google-docs/ just thoughts -fe What it should read is: Google helps MSOffice play catch up a little on OOo. OOo/LibreO/Go-ooo communities ask: What took you so long. I've had this functionality for quite some time. So therefore, the second question is how did you not know this? And the third question: How do we let the world know? Cheers GL Someone could blog on this and then point it out. You could also add a comment to the article. There is still no mention of LibreOffice or OOo on the comments sections. Seing this on a LibreOffice blog would be cool, then we could advertise the blog on something like http://www.LinuxToday.com http://www.linuxtoday.com/. They average 1 million hits a day. Marc Some of the most popular extensions should be reevaluated as core features as opposed to extensions that ship seperately. If this was a baked in feature, more people might be exposed to it. As I see it, the problem here is that cool, useful extensions aren't being really exposed to most OOo/LibO users. We should definitely expose these extensions more: advertise them on the LibO website, maybe redesign the Extension website and manager to be more friendly and showcase the most popular extensions. There are a lot of really great extensions, way more than we could possibly hope to package with LibreOffice. If people aren't hearing about them, then we need to make these extensions discoverable. (Personally, when I started using OOo, it took me a while to find where I could get the language packs I needed.) P. S. I'm not against including extensions with LibreOffice, but these extensions would definitely need to be removable. -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Archive: http://www.documentfoundation.org/lists/discuss/ *** All posts to this list are publicly archived for eternity ***
Re: [tdf-discuss] Re: Google now integrates with MSO, what about Libre/OO?
As I see it, the problem here is that cool, useful extensions aren't being really exposed to most OOo/LibO users. if they are really cool and useful (as this one is that was just pointed out) then they should become standard features of part of an add-on pack. imho... -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Archive: http://www.documentfoundation.org/lists/discuss/ *** All posts to this list are publicly archived for eternity ***
