[tdf-discuss] unsubscribe
-- 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 ***
[tdf-discuss] unsuscribe
-- 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] LibreOffice UI should be tweaked, not reinvented
On 02/11/10 12:05 PM, T. J. Brumfield wrote: The OOo team has been working two years on Project Renaissance. And there is a long running thread here in the discuss archives of a UI prototype. While that particular prototype looks clean/sharp, I think all this dicussion on radically altering the UI is unnecessary. I truly believe the current approach works and should be maintained, but improved. There might be some slight tweaks in how the menus are organized. Toolbar defaults might be optimized. And the overall UI could be shined up with some gloss, new icons, gradients, spot color, etc. If anything, I think we should be going the opposite direction. Instead of chasing the Ribbon of 2007/2010, I think we should embrace the abandoned Office 2003 UI even more. Perhaps provide an option to all but completely mimic it. People forget, but Microsoft used this tactic themselves, allowing an option for Word users to use Wordperfect key-mappings, and provided specific help for Wordperfect Users trying to migrate to Word. Since we know most users coming to Lo/OOo are coming from Microsoft Office, shouldn't we do our best to ease that transition? It would also be considerably less work than completely redesigning the UI from scratch. That is more time that could be dedicated to improving the project in other ways. -- T. J. Brumfield +1 Thanks T. J. for putting into words what I was thinking about the UI redesign. I concur with this thinking. Why re-invent an unpopular feature. This kind of idea was brought up when OOo unveiled a ribbon-like interface. Just because we can redo the UI doesn't mean we should. Can we avoid the "bikeshedding" and "chasing after the cool kids", please? I vote for the application of the K.I.S.S. principle. Scott Furry -- Unsubscribe instructions: Email to discuss+h...@documentfoundation.org Posting guidelines: http://netmeister.org/news/learn2quote.html Archive: http://www.documentfoundation.org/lists/discuss/ *** All posts to this list are publicly archived ***
Re: [tdf-discuss] OpenSuSE and Libò
On 19/10/10 10:25 AM, Carlo Strata wrote: Il 15/10/2010 12:50, Petr Mladek ha scritto: Libò Writer -> Tools -> Options -> Language Settings -> Languages -> Language of -> User interface shows only: - Default - English (USA) - English (USA) Any setting yields English UI! What's wrong? What is my mistake? Is it a bug? Thank you, Carlo Carlo, This isn't a bug. Beta2 has been released as EN-US so far. Regards, Scott Furry -- E-mail to discuss+h...@documentfoundation.org for instructions on how to unsubscribe List archives are available at http://www.documentfoundation.org/lists/discuss/ All messages you send to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Houston, we have a problem.
On 18/10/10 10:22 PM, Jean Hollis Weber wrote: On Tue, 2010-10-19 at 17:09 +1300, Paul A Norman wrote: Yep I've had two confirmtatoin that I have left the list and still the emails come rolling Does this constitute nuisnace email now? It's probably a glitch in the email system. Unfortunately, it's the middle of the night for the people who take care of that, so it will probably be at least another 4 to 6 hours before someone can look into it. And yes, that sucks, and I'm not defending it. --Jean Roxy / Paul, Not to stick my nose in...but if you would really like to stop the mails until the unsubscribe works, there is always the possibility of turning on your spam filtering. Its a rather semi-permanent, forceful solution. If you do subscribe in future you would have to remember to remove the filter to accept mail from the TDF. Sorry you're having a bad time with this. Hope this helps. Scott Furry -- E-mail to discuss+h...@documentfoundation.org for instructions on how to unsubscribe List archives are available at http://www.documentfoundation.org/lists/discuss/ All messages you send to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Problems installing LibO beta2 on Debian
On 17/10/10 04:26 AM, AG wrote: On 16/10/10 22:33, Scott Furry wrote: In TDF archive is the message thread of observations about the deb repository and setting it up. See the thread: http://www.mail-archive.com/discuss@documentfoundation.org/msg00497.html "[TDF discuss] LO deb repo" for more details. I found that I had to uninstall beta1 to get things to work. Once I squared away beta1/beta2 issues things went swimmingly. Install from the cmd line for apt I had to use "libreoffice3* libobasis3* libreoffice-menus*" when I first installed but after that updates were picked up normally. Can you elaborate a bit pls? prompt> sudo apt-get install libreoffice3* lobasis3.3* libreoffice-debian-menus Thanks for the details Scott I followed this, removed the previously installed beta 2 version of LibO and attempted an installation as per your apt-get line. The result: Errors were encountered while processing: /var/cache/apt/archives/libobasis3.3-core01_3.3.0-9_i386.deb ... /var/cache/apt/archives/libobasis3.3-writer_3.3.0-9_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) So no go. Perhaps this is just me, but I really don't think that one should have this degree of difficulty installing an application, especially when - generally speaking - apt-get is one of the more robust package managers available. So, back to removing any partial installs and re-installing by hand. Thanks anyway. AG I would take a guess that if you did an "apt-get install" prior to this, then you may have some kind of "unclean" copies of debs. Did you happen to think of doing an "apt-get clean" or "apt-get autoremove" before trying the download again? SF -- E-mail to discuss+h...@documentfoundation.org for instructions on how to unsubscribe List archives are available at http://www.documentfoundation.org/lists/discuss/ All messages you send to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] A few initial comments on Beta2
On 16/10/10 01:30 PM, AG wrote: On 16/10/10 19:50, Scott Furry wrote: On 16/10/10 12:01 PM, AG wrote: (ii) there is still no Quickstarter available - nothing under Tools/ Options/ General/ Memory to even enable this. Not critical, but very nice to have and the code already exists for OOo so no good reason why it shouldn't be carried over into LibO I have the QuickStarter running on XFCE desktop. For the beta2 I'm using, the checkbox for enabling QuickStarter in the User Preferences is there. How do you access that? I'm using Gnome. Its was set up "automagically" with the LibO Beta2 install. I'm under the impression that if Beta2 is installed properly, this should be made available to you [by default] as soon as you open any LibO program (i.e. writer, calc, et al). The setting for this in LibO's configuration (Tools>Options>Memory) is present in Beta2 (wasn't there in Beta1). Hope this helps. With a bit more detail, it might :-) AG If you have a look at my other message, maybe this will help clear away the problems. Shout back if this doesn't work for you and we can piece things together from there. Cheers, Scott Furry -- E-mail to discuss+h...@documentfoundation.org for instructions on how to unsubscribe List archives are available at http://www.documentfoundation.org/lists/discuss/ All messages you send to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Problems installing LibO beta2 on Debian
On 16/10/10 01:45 PM, AG wrote: On 16/10/10 19:42, Scott Furry wrote: On 16/10/10 05:21 AM, AG wrote: AG, I used Nikola's Deb archive (adding it to my sources.list). Scott, what's the line for that? 1. Adding the repository: sudo echo “debhttp://download.tuxfamily.org/gericom/libreoffice /#geri...@hummer” | tee -a /etc/apt/sources.list 2. Adding the signing key: wget debhttp://download.tuxfamily.org/gericom/gericom.asc -q -O- | sudo apt-key add - In TDF archive is the message thread of observations about the deb repository and setting it up. See the thread: http://www.mail-archive.com/discuss@documentfoundation.org/msg00497.html "[TDF discuss] LO deb repo" for more details. I found that I had to uninstall beta1 to get things to work. Once I squared away beta1/beta2 issues things went swimmingly. Install from the cmd line for apt I had to use "libreoffice3* libobasis3* libreoffice-menus*" when I first installed but after that updates were picked up normally. Can you elaborate a bit pls? AG, I used the line: prompt> sudo apt-get install libreoffice3* lobasis3.3* libreoffice-debian-menus to install LibO from the Nikola's LibO deb repository. When it came time to install beta2, I uninstalled beta1 then used the line above to install beta2. Although apt did pick up the fact that the packages were updated and installed them, I discovered after the fact that beta1 had to be uninstalled first. Regards, Scott Furry -- E-mail to discuss+h...@documentfoundation.org for instructions on how to unsubscribe List archives are available at http://www.documentfoundation.org/lists/discuss/ All messages you send to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] A few initial comments on Beta2
On 16/10/10 12:01 PM, AG wrote: Hi list Now that I have LibO beta 2 working, I'd like to offer a few comments if I may: (i) the installation process - at least for Deb - needs to be streamlined and made more intuitive (this may be superseded once the Deb maintainers get their hands on LibO however) Again, I used a different repository for Debian(Squeeze). After a couple of glitches on beta1, everything went rather well after that. (ii) there is still no Quickstarter available - nothing under Tools/ Options/ General/ Memory to even enable this. Not critical, but very nice to have and the code already exists for OOo so no good reason why it shouldn't be carried over into LibO I have the QuickStarter running on XFCE desktop. For the beta2 I'm using, the checkbox for enabling QuickStarter in the User Preferences is there. Hope this helps. Regards, Scott Furry -- E-mail to discuss+h...@documentfoundation.org for instructions on how to unsubscribe List archives are available at http://www.documentfoundation.org/lists/discuss/ All messages you send to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Problems installing LibO beta2 on Debian
On 16/10/10 05:21 AM, AG wrote: Hi all I dropped this into the thread on the beta 2 release, but that was the wrong place and it subsequently got lost. So, to give it its own thread just in case others need it in the future. For my Debian system, I found http://download.documentfoundation.org/libreoffice/testing/3.3.0-beta2/deb/x86/ and once I downloaded the relevant deb tarball I ran into some difficulties installing it. I unpacked the tarball and ran, as sudo, sh update. Errors were encountered while processing: en-US/DEBS/libobasis3.3-core01_3.3.0-9_i386.deb en-US/DEBS/libobasis3.3-en-us_3.3.0-9_i386.deb libreoffice3 libreoffice3-writer libreoffice3-math libreoffice3-impress libreoffice3-en-us libreoffice3-draw libreoffice3-calc libreoffice3-base Therefore: (1) was running update the appropriate installation/ updating method to install beta 2 and if not, what is? and/ or (2) have these issues been reported by others using the debian packages? FWIW, I'm running an up-to-date Debian testing on a stand alone machine. It has OOo and LibO beta 1 installed (& these actually seem to co-exist quite happily). Thank you for any ideas on how to install beta 2. AG AG, I used Nikola's Deb archive (adding it to my sources.list). I found that I had to uninstall beta1 to get things to work. Once I squared away beta1/beta2 issues things went swimmingly. Install from the cmd line for apt I had to use "libreoffice3* libobasis3* libreoffice-menus*" when I first installed but after that updates were picked up normally. Hope this helps. Regards, Scott Furry -- E-mail to discuss+h...@documentfoundation.org for instructions on how to unsubscribe List archives are available at http://www.documentfoundation.org/lists/discuss/ All messages you send to this list will be publicly archived and cannot be deleted
[tdf-discuss] (Re-Post) Survey|Opinion - LibreOffice Install and Update
Dear LibreOffice Community, I am Re-Posting the original survey under new title. If you wish to have a discussion about the survey or aspects of someone's responses, I would kindly ask that you start a new thread (please add "discussion" or similar to the title so as to distinguish the discussion from the survey itself). For those of you who have replied, thank you. I have your answers tucked away and you do not have to fill this out again. For those who have not replied, with a rather "timely" new beta release, please give thought about what is important to you when it comes to installing/updating LibreOffice. Your responses will help TDF understand its users. I intend to keep this thread going for a couple more weeks. At that time, I'll compile and report back the results. Thanks to all, Scott Furry Original Survey Follows - As suggested, this post is intended to get the opinion of the community about how best to deliver LibreOffice to its users. Given that LibreOffice is an important and viable alternative to paid-for office productivity software, and we all feel strongly and passionately about the direction of LibreOffice, input about the community members' expectations/needs/users is needed. From what we have heard on this topic so far: - Mac users have commented that they do not have an issue with the current installer available on the Mac platform. - Window users indicated that an update mechanism would be great. Some commented that the current Windows installer leaves artifacts behind. The Windows Installer does not detect/remove previous installations properly. - Linux users have discussed vast amounts opinions on packaging in Linux. Some have questioned if distributing packages is a good thing. --- This survey is to gauge the views of the LibreOffice community on the install/update method of LibreOffice. Please voice your opinion so that these considerations may be taken into account when the LibreOffice method of install/update is studied by the developer team. Please *bottom-post* your opinions. How do you expect LibreOffice to be updated? How do you Install/Update LibreOffice? What do you expect when Installing/Updating LibreOffice? Other programs have separate updating programs (iTunes being an example), if it was technically feasible, would having a separate install program for LibreOffice (with updating features) be useful to you? Would having a download and update site, as well as a Unix|Linux package repository site, be of value to you? --- Please note that I am not affiliated with DocumentFoundation. I am like you, a community member who wants to see LibreOffice be very successful. So let's hear what you think folks? Regards, Scott Furry -- To unsubscribe, e-mail to discuss+h...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Beta2 Install Results (was Re: [tdf-discuss] Windows Install)
On 13/10/10 11:52 AM, Volker Merschmann wrote: It is very much recommended to do the uninstall of beta1. If you try to over-install with beta2 you will have twowill have two entries for LO in the system control panel afterwards. This is a known bug from beta1. Found that out the hard way today. Uninstalled both then installed beta2 from Nikola's deb repository. apt line: deb http://download.tuxfamily.org/gericom/libreoffice / #LibreOffice Things work well. Even the bug with the QuickStarter in the system tray is fixed. Debian Squeeze (2.6.32-5-686) w/LXDE Regards, Scott Furry -- To unsubscribe, e-mail to discuss+h...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: [tdf-discuss] Windows Install
On 11/10/10 07:44 PM, NoOp wrote: On 10/11/2010 05:44 PM, Marc Paré wrote: There is a survey on the list where we are trying to tie in all of these opinions and requests together. Could you add your remarks there too. Just look for the thread entitled: "[tdf-discuss] Survey|Opinion - LibreOffice Install and Update" I'll be happy to following discussion in this thread if you think it necessary/useful. This thread addresses a specific issue& I would rather have it addressed/discussed here rather than get lost in those two threads. Its actually four threads that have been re-spawned, I think. But whose counting ;-) I do think that discussing the merits of your ideas in a separate thread is perfectly fine. However, it would be great if you can use your experiences and observations with OOo|Go-OO|LibO to answer the questions in the survey Mark mentioned above. Please? Let me assure you that your answers are import and won't get lost|forgotten. I've received about a dozen responses so far and each has been tucked away for easy retrieval when I go to do a final summation. I was thinking of giving the thread at least a couple more weeks to give everyone a chance to comment. Regards, Scott Furry -- To unsubscribe, e-mail to discuss+h...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On 09/10/10 10:48 PM, todd rme wrote: There is another, somewhat independent issue that has occurred to me. What about how the components are split up? The issues are somewhat different for windows and mac than they are for linux. For windows and mac, if someone, for instance, only wants a database program, should they have to download the entire program suite just to install that one program? There are a couple possible solutions to this (in addition to the status quo). One is that we supply the current all-inclusive installer, as well as a separate installers for the individual parts. An alternative is that we provide an online installer, where you download a small program, tell it what you want to install, and it retrieves those bits and installs them. This also has the advantage that the actual download the user has to worry about deleting later is very small, the rest of the downloads would be stored in a temporary directory that would be automatically deleted later. It occurred to me that this is, in essence, what the updater would do. So really you would only need one program, the updater, which would also be able to handle the original installation. You could just download the updater and have it retrieve the latest versions of whatever parts of the program you want from the servers. This also makes it easier for users who, say, install writer and find they like it to easily install other components right from within the program. For Linux, the issue is how the parts of the suite are divided up and named. Different distributions use lots of different ways to break up the suite into individual packages and lots of different names for those packages. It is not possible to force distributions to use any particular naming scheme, but I think that providing recommendations and guidelines for how the packages should be divided up would be very helpful. Users would have a better idea what they need to install to get the features they want, tech support will be easier because people using different distributions can communicate more effectively about what they have installed, and switching between different versions of the software provided by different groups would be easier. Of course the content of these guidelines would require a lot of discussion with distributions, but I would like to think distributions would be willing to follow such guidelines if they are reasonable. -Todd Todd, Nice thought. As soon as I read your post I was smacking my forehead as this makes quite a bit of sense to me. As I understand the current install from a strictly "Debian/Apt" perspective, what you describe exists in some form. LibO has a common or core package, individual packages for the different major LibO components and (I'm assuming here) the LibO Basis. If you have a look at Nicola's deb work ( http://download.tuxfamily.org/gericom/libreoffice/ ) you can get a better idea of how LibO's components are packaged for Debian/Ubuntu/Mint etc users. The devs would have to comment further about technical feasibility, but from this user's point of view I like the idea. Regards, Scott Furry -- To unsubscribe, e-mail to discuss+h...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
[tdf-discuss] Survey|Opinion - LibreOffice Install and Update
LibreOffice Community, As suggested, this post is intended to get the opinion of the community about how best to deliver LibreOffice to its users. Given that LibreOffice is an important and viable alternative to paid-for office productivity software, and we all feel strongly and passionately about the direction of LibreOffice, input about the community members' expectations/needs/users is needed. From what we have heard on this topic so far: - Mac users have commented that they do not have an issue with the current installer available on the Mac platform. - Window users indicated that an update mechanism would be great. Some commented that the current Windows installer leaves artifacts behind. The Windows Installer does not detect/remove previous installations properly. - Linux users have discussed vast amounts opinions on packaging in Linux. Some have questioned if distributing packages is a good thing. --- This survey is to gauge the views of the LibreOffice community on the install/update method of LibreOffice. Please voice your opinion so that these considerations may be taken into account when the LibreOffice method of install/update is studied by the developer team. Please *bottom-post* your opinions. How do you expect LibreOffice to be updated? How do you Install/Update LibreOffice? What do you expect when Installing/Updating LibreOffice? Other programs have separate updating programs (iTunes being an example), if it was technically feasible, would having a separate install program for LibreOffice (with updating features) be useful to you? Would having a download and update site, as well as a Unix|Linux package repository site, be of value to you? --- Please note that I am not affiliated with DocumentFoundation. I am like you, a community member who wants to see LibreOffice be very successful. So let's hear what you think folks? Regards, Scott Furry -- To unsubscribe, e-mail to discuss+h...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On 09/10/10 03:13 PM, RGB ES wrote: 2010/10/9 Scott Furry: And IMO that is the point. Distributions will only incorporate into the releases what /they feel/ is appropriate. And is that wrong? If you want "the last" on your computer "as soon as possible", then you need to change to a rolling release distro... There is a reason because there are so many distros out there: they are different. If you need to upgrade the very second there is a new version of software X then you need a bleeding edge distro, I disagree. As you suggest, there is the core software, and is also a host of software applications (some even have their own QA/Testing programs - Mozilla being a prominent example). If that's what openSUSE does, great! But users of other distributions have different needs and level of knowledge. They have chosen their distribution/platform. Should LibO not respect that user decision? Holding back on incorporating another software program, from my understanding, is done because of distribution revision testing/development. AFAIK, some distributions (for example Debian stable/unstable/testing/experimental) show a tendency to not incorporate software major revisions (i.e. software ver x.y.z increases from 1.1.1 to 2.0.0) . Should users be punished because the development cycles of the distribution and software group are different? Regards, Scott Furry -- To unsubscribe, e-mail to discuss+h...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On 09/10/10 02:11 PM, Marc Paré wrote: I agree, direction from the whole community on this, now that we have hashed it out a bit, would give clearer direction of expectations. This could then be put to the community as a new thread and the results could be monitored/taken into note for the future planning of the LibO method of updates from the dev team. Marc Mark, I like you rewrite. I can work with that, mind if I 'borrow it?' ;-) I'll post a new thread shortly. Regards, Scott Furry -- To unsubscribe, e-mail to discuss+h...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On 09/10/10 02:41 PM, NoOp wrote: On 10/09/2010 12:38 PM, jonathon wrote: ... OOo in the official Ubuntu repository is version 3.1. In the PPA 3.2 is available. Actually, for the current stable (LTS) released version of Ubuntu (Lucid) the version is 3.2.0 (3.2.1 in proposed): If you are only at 3.1, then you probably are still using Karmic (9.10)? Or haven't updated in some time. And IMO that is the point. Distributions will only incorporate into the releases what /they feel/ is appropriate. The Ubuntu PPA becomes the catchall for what users want. The point here is how can DocumentFoundation simply put the latest/greatest LibreOffice into the hands of the most users? Regards, Scott Furry -- To unsubscribe, e-mail to discuss+h...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
IMO, the discussion on packaging seems strange considering that quite a few open source sites I visited in the last couple of days most have some form of downloads available for the different distribution: PostgreSQL and Go-OO being just a couple of examples. And as suggested by the Go-OO site, the rationale for distribution was to avoid some of the politics and interpretations of open source that can occur. Packaging to me just makes sense. If other distributions want to repack, fine - that's their prerogative. To me it isn't a waste of resources. They just want certain changes that LibO doesn't have (and why they didn't push those changes back to us to incorporate is an entirely different discussion). Moving on from the discussions dwelling on specific topics of Unix/Linux distributions... From what I have seen on this topic so far: - Mac users (three? ) have commented that they do not have an issue with the current installer. - In the initial thread, many Windows Users indicated that an update mechanism would be great. - Some commented the current Windows installer leaves artifacts behind - Windows Installer does not detect/remove previous installations - Lots (vast) amounts of discussion on packaging in Linux - some have question if distributing packages is a good thing What would be nice to see discussion on from the *community*: - How do you expect LibO to be updated? - What are your use cases of Install/Update - Other programs have separate updating programs (iTunes being an example), if it was technically feasible, would having this feature be useful to you? - Would having a download site/accessible package repository be of value to you? Regards, Scott Furry -- To unsubscribe, e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On 08/10/10 03:06 PM, Marc Paré wrote: I had not heard of Go-OO ( http://go-oo.org ) before until this discussion thread. Visiting their page, it seems like they have the kind of distribution model that we could leverage. Are you talking of the "Universal Linux" on this page? http://go-oo.org/download/ If so, how would a user be able to add this easily as a repo if he were using a system such as Mageia (Mandriva) as I am using? (Just as an example.) I was actually commenting on the delivery as a whole and not on any specific features. Sure they have "Universal Linux", but cater to a larger crowd with different distributions. Windows, MacOSX, et al can download from one place. Not sure what patches the downstream distributions have picked up, but this group appears (on the surface) to have the kind of distribution being discussed. -- To unsubscribe, e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On 08/10/10 02:53 PM, Marc Paré wrote: Le 2010-10-08 16:47, RGB ES a écrit : Would this be a security headache? Could this work for the average user? Does this not seem a convenience for the end-user community at large? Others could mirror this repository, but this would be the "upstream source" for both users/distributions. Are there other factors I'm missing? AFAIK, go-oo people maintained a yum repository. So it is possible. From a marketing point of view, this would be in LibO's interest as the update to LibO would then be a no brainer even from the user point of view. Almost a form of "pushing" the LibO updates/upgrades through without having to go through distro packaging. In this case, then, it would be a case of having a dedicated dev-packager for each flavour of packaging system used by the distros. Marc, That sums it up rather nicely. ;) I had not heard of Go-OO ( http://go-oo.org ) before until this discussion thread. Visiting their page, it seems like they have the kind of distribution model that we could leverage. Scott -- To unsubscribe, e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On 08/10/10 02:32 PM, RGB ES wrote: Software repositories managed by system applications (yum, libzipp... whatever) ARE an unified upgrade system, reliable, secure and fast that simplify your life. You just need online storage capacity and someone who build the packages, but that someone do not need to be a developer: almost anyone can build packages (after a period of training, of course ;) ) And that's why I was asking about whether it was possible to have repositories on the documentfoundation.org servers. Users of Debian (and its derivatives) could put "apt.documentfoundation.org" into their sources.list file and there would be a one-stop shop for that distribution to put LibO into users hands. I'm assuming rpm's and other distribution packaging could be setup in a similar fashion. In the same light, Windows users would have a download source for updates. Would this be a security headache? Could this work for the average user? Does this not seem a convenience for the end-user community at large? Others could mirror this repository, but this would be the "upstream source" for both users/distributions. Are there other factors I'm missing? Regards, Scott Furry -- To unsubscribe, e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
As todd rme has suggested, there exists automated packaging tools. I had not run across that in my readings. I don't use openSUSE, but good to know. My original suggestions regarding a separate repository had been meant to avoid 'package purgatory' where the distributions would relegate LibO to, strictly for example, debian/unstable or debian/experimental. This may preclude the average user from finding and installing LibO to their computer. Even if there are build services available, the suggestion of packaging LibO , even if it was temporary, was to enable LibO availability for the average user. I'm under the assumption that distributions won't pick up LibO just because of what it once was. Sure, other distributions will apply their own stuff to the packaging (Ubuntu being the prime example) but can we put LibO *now* into the hands of the average user? The idea of a distinct and stand-alone updater was to allow for the different use cases with variable distribution/OS platforms, end use environment (single user vs group vs enterprise). The idea is not to build something from scratch, but to pull out the existing updater and make a standalone program. As a standalone program, it can be tweaked/altered/improved without affecting the revision of the main program as a whole. Regards, Scott Furry -- To unsubscribe, e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
LibO Install/Update ( was [tdf-discuss] Automatic Updates)
Hello all, I'm thinking the its time to dig out of the weeds/details and make this a more meaningful discussion for everyone. I'll do my best to avoid excessive verbiage, as well as keep the my "soap box" stances to a minimum. Charles M (the Original Poster - OP) thought that a better install update mechanism was needed. The discussion likened this to what Mozilla is doing for Firefox, et al. Now, examples and comparisons aside, many expressed thoughts that this was a much needed feature. However, there were some differences realized in how this could be achieved for the different OS platforms (e.g. Unix|Linux|Windows). Unfortunately, AFAICR only one Mac user identified them self and commented on this topic. So apologies to the Mac User crowd (I now you're out there somewhere) ;-) So,lets start with the Unix|Linux crowd: -> Package Maintainers (I like 'specialists' but let's use the term people recognize) can build and distribute both installs and updates to different OS users. We are respecting the OS and working on the OS in a way with which people get taught/learned/accustomed to use the OS. Q01) Can we have repositories for LibO packages? (e.g. deb - apt.documentfoundation.org or rpm.documentfoundation.org) The idea about having a repository does not have to be permanent solution, but would allow downstream maintainers to pull/mirror packages for their OS community. LibO (and by extension DF) would gain credibility and good will in the community. We can start to build rapport and lines of communication with the PTBs in the different OS groups. Just a thought. Q02) If there are people in the community that are good at this, would it be a bother for them put up the binary packages to the documentfoundation.org servers? Q03) Could extensions be lumped in with this topic? (to ensure future OOo extensions don't cause LibO grief as the two projects start to diverge) One last point I should make here - once a user installs a package, normally that user should continue to update via package management (dpkg, apt, yum, et al.) However, OOo and post-divergence LibO has a built-in updating mechanism. Great for Windows users but lousy for others where superuser/root permissions are required. Q04) How hard would it be to pull out the Update Mechanism and make it a stand-alone program? (before everyone jumps to 'reply' - let me talk about Windows - this question will then become self-evident) For the Windows crowd: The current install is, to put it mildly, less than desirable. Negative comments were made about how the current installer on Windows behaves. These, IMHO, were fair and critical observations. Q05) Can the current install be cleaned up? Users cited having left over files on the desktop and not being aware that one has to uninstall the old version to install the later version (big PITA in my books). Q06) Do we have people that can work on the Windows Installer? Now...as for my left over question above...I believe that a separate 'Update Mechanism' independent of LibO would be a boon for a variety of reasons. -- OS specifics of update and networking could be pulled out of the main LibO development. -- It would remove the problems of corrupting an install if not a superuser (packaged LibO wouldn't have separate updater program for Unix|Linux or if it was disabled by an ADMIN) -- a separate update program could then 'check-in' with the servers (once a week, once a month) to verify if updates are available (get permission from the user to shut down the current LibO instance, update, then start LibO back up) -- and the really cool idea...plays into Charles' idea of enterprise installation. A separate install program that is: - scriptable ( can install/update many computers via a script) - allows local or remote repositories to be identified ( a corporate IT Admin downloads behind his/her firewall and users update from that local store rather than reaching out to the internet) Q07) Does this seem a useful way to push into enterprise/group usage of LibO? Q(rhetorical)) Am I dreaming in Technicolor/Panavision or just 720p HD? I would very much like to hear from the community on this one (and you Mac users - don't be shy). Regards, Scott Furry -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: [tdf-discuss] Automatic Updates
On 07/10/10 05:00 PM, Charles Marcus wrote: On 2010-10-07 6:05 PM, Scott Furry wrote: On 07/10/10 03:04 PM, Charles Marcus wrote: Their incremental updater works very well on Windows - and with the Update Notifier extension, all updates can be made pretty much silent and automatic. True enough. But this feature is not available to non-root users on *nix. Why not? If the software is installed somewhere that does not require root permissions, why would root perms be needed to update it? Makes no sense. *nix is perfectly capable of allowing normal users to install software. For a local user only in there own directory, ok. For any Firefox user, type "about:plugins" into your search bar and see what comes back. You will find that MS has (more often through Windows Update) installed ActiveX, Eh? ActiveX in Firefox? Methinks you typed without thinking... ;) Yes, its disused and out of favor, but WinXP users would still see the plugin installed. No, they wouldn't (in the case of ActiveX) - since apparently you missed my point that there is no ActiveX for Firefox - never has been, never will be (unless someone pony's up a bunch of cash). I have seen an ActiveX plugin installed in Firefox (which I promptly removed). A quick google search shows that: a) Mozilla doesn't support it (no surprise) - http://support.mozilla.com/en-US/kb/activex b) there are others who have created add-ins/plugins for firefox (why is beyond me) ...but the one (ActiveX) has nothing to do with the other (Microsoft silently installing .net extensions)... Agree to disagree... But we are agreed that its bad to silently push plugins/software/extensions/ onto an application without the user knowing what to expect. Regardless of the examples...its just bad. Right? This is a problem. Why should package managers dig into the code to disable something? ?? They don't have to 'dig into the code' to flip compile switches for specific packages - they do that all the time (some packages are built with SSL support, some aren't, etc). Agreed. Your previous text led me to believe you were suggesting that the person doing the packaging was to edit the source code. This person doesn't have a need to open up and/or change source code. And on *nix, root(or superuser) is required. You are either root or on the "sudoer" list. Can't get away from that. My understanding is this is only true if you're installing something for everyone. If you're installing something only for yourself - ie, like I said earlier, in /usr/local, or even in /home/user/apps - then I am fairly certain that root is *not* required... Am I wrong? No. Your not wrong. But installing locally is usually done either for development purposes or some other very-special need. Package installations do not install for "local use only" as that is not the recommend methodology. My bad - I forgot I had replied to myself... apologies... No worries. :) Sounds like GPO (or enterprise installs) should be looked as a separate usability case once the dust settles here. No doubt... I sense a "task force" would be useful to resolve this issue (not as grand as the IETF mind you). Just a few select people to document the use cases, identify risks/roadblocks, detail requirements...usual project management. Eh? I have never seen an 'updater', incremental or otherwise... when/where have updaters ever been provided? That's the purpose of package management programs (apt, dpkg, yum, rpm, etc.). I was speaking to an updater for Windows... there never has been one. What about Windows Update? From a non-os software side, I do recall seeing a update/notify program. Can't remember the name and I no longer can find the link. Maybe what is needed is some simple communication to the major distros to see what form would be best. I cannot imagine this would be that difficult - they should all be able to work with standard tarballs and do whatever is needed on their end to make it work. Not all of them. Case in point is the person who put together the Debian packages (Nikola Yanev - great work BTW :D ). There are others out there in the community. It would be great if they (and their skills) could be be brought together allowing for a one-stop-download location of packages for the different OS distributions. This would then be considered the "upstream repository" from which the various OS distribution teams could then mirror/pull down LibO for distribution to users of that OS. I do not think that LibO should be in the business of providing individual distro packages - let the distro package managers do that. It will free up lots of developer resources to focus on programming, not building/providing packages. The Debian distribution has over 25,000 different packages in their repository. You think Debian has the time to look after this stuff? Espec
Re: [tdf-discuss] Document Foundation - list archive - emails in clear
On 07/10/10 04:56 PM, Jean Hollis Weber wrote: On Thu, 2010-10-07 at 15:24 -0700, Andy Brown wrote: On Thu Oct 07 2010 15:18:23 GMT-0700 (PDT) Scott Furry wrote: Is anybody else concerned by the fact that emails are in clear in the list archives (not to mention easily delineated by angle brackets)? All mailing list archives are in plain text. Did you not read the warnings when you singed up? I'm sorry Andy, what warnings are you talking about. Clicking on the "subscribe" link from the site window just brings up an email client window. And the site privacy statement doesn't given state anything specific about forum contributions. IIRC, the warnings say that all the *messages* can be read in a public archive. Scott is talking about the email *addresses* on those messages in the archives. Many of the other lists that I subscribe to have the email addresses given as something like j...@ in the archives. However, the OOo archives have them in plain text. I don't know about gmane and the others. To answer Scott's original question: It's not something that concerns me personally. My many email addresses are all over the internet, so having my address harvested from another list makes no difference. I get a zillion spam messages a day, almost all of which gmail filters out for me. --Jean Thanks for clarify my point, Jean. I should have asked about "email addresses". Again, I didn't see a warning message. Did I sign up too early in the process? I don't have the same faith in gmail filters as you do. Regards, Scott Furry -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
[tdf-discuss] Document Foundation - list archive - emails in clear
Is anybody else concerned by the fact that emails are in clear in the list archives (not to mention easily delineated by angle brackets)? I don't think it would take much for an enterprising hacker to compile all the emails from the list archives. Can we not feed the spammers easy targets, please? Regards, Scott Furry -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: [tdf-discuss] Automatic Updates
balls and do whatever is needed on their end to make it work. Not all of them. Case in point is the person who put together the Debian packages (Nikola Yanev - great work BTW :D ). There are others out there in the community. It would be great if they (and their skills) could be be brought together allowing for a one-stop-download location of packages for the different OS distributions. This would then be considered the "upstream repository" from which the various OS distribution teams could then mirror/pull down LibO for distribution to users of that OS. From all the discussions so far, we have three criteria for Windows installs: - clean up after itself - update (uninstall previous installation) - Group Policy installs/configuration Sound about right? And a wish for an Incremental Update Mechanism similar in nature to what Mozilla offers. Yes, sounds about right... the native incremental update would be mainly for 'home' type users, and the .msi/gpo updates would be for corporate environments making use of GPO for managing their software. Also, the use of tar.gz, tar.bz2 or zip should be IMHO reserved for source file distribution. Okay... but for a package as large as LibreOffice, it seems to me that a .diff approach would be much better... the only time it wouldn't be practical is for major updates (ie, going from 2.0.1 to 3.3)... but code the update routine to check for that and just download the new version, uninstall the old version and install the new version. Again...a package is supplied in a compressed archive format, albeit with a different extension. Debian packages are standard Unix ar archives that include two gzipped, bzipped or lzmaed tar archives: one that holds the control information and another that contains the data. http://en.wikipedia.org/wiki/Deb_(file_format) And as I mentioned earlier, we should look at engaging 'package specialists' - people who can alleviate some of the burden from devs about distribution. Am I missing anything from the discussions? No, that covers it. I wish I were a programmer so I could help with the heavy lifting, but I'm not... +1 You and me both. Know just enough to be dangerous, but not enough to be helpful. :D Regards, Scott Furry -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: [tdf-discuss] LibO beta deb packages causes freeze using pdf-export and several menu entries
On 07/10/10 07:08 AM, Friedrich Strohmaier wrote: LibreOffice 3.3.0 OOO330m7 (Build:9526) libreoffice-build 3.2.99.0 Installed using deb-repo source deb http://download.tuxfamily.org/gericom/libreoffice / Does pdf-export have a package dependency that you may be missing? (do we use iBatis or some kde lib?) Don't know. I ride KDE-3.5.8 here the list of installed packages: ~$ aptitude search libreoffice lobas | grep ^i And that ones remaining: ~$ aptitude search libreoffice lobas | grep ^p Gruß/regards Fredrich, It looks like you got all the LibO packages. I'm just wondering if there is some functionality provided for PDF conversion from another library. It may be the problem you are experiencing. Sorry I can't offer any more help. Regards, Scott Furry -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: [tdf-discuss] Automatic Updates
On 07/10/10 11:04 AM, Per Eriksson wrote: Hi, If we would implement this for Windows i think it would be a great win, specially since most users are downloading and using the Windows version of the software. Then, maybe completing the functionality with distro-specific solutions leveraging different technologies etc? I am not sure if Mozilla offer out-of-the-box updating for Firefox on Linux? Best Per Charles Marcus skrev 2010-10-07 15:32: On 2010-10-07 9:15 AM, Charles Marcus wrote: I agree, but the problem here is that the individual package managers should be *disabling* the internal updaters in their packages, so that they can only be updated using the package management system. And Mozilla should provide a simple compile switch that can be invoked to accomplish this (maybe they do already?). Again, I have to go back to my earlier posts - Mozilla is not the shinning example. For any Firefox user, type "about:plugins" into your search bar and see what comes back. You will find that MS has (more often through Windows Update) installed ActiveX, Silverlight, .Net Framework plugins all without the users knowledge and consent. Even Java has this behavior on Windows (*nix requires a separate package). And you can't scream if you don't know its being done. There were some noises on forums when this first came to light, but the average user ether doesn't know or doesn't care that some other company is forcing their will on how your browser behaves. On 07/10/10 07:32 AM, Charles Marcus wrote: On 2010-10-07 9:15 AM, Charles Marcus wrote: I agree, but the problem here is that the individual package managers should be *disabling* the internal updaters in their packages, so that they can only be updated using the package management system. And Mozilla should provide a simple compile switch that can be invoked to accomplish this (maybe they do already?). This is accomplished through user permissions. Is the person root? no - disable menu updates On 07/10/10 07:15 AM, Charles Marcus wrote: One caveat though - .msi installers are required (I think) if you want to incorporate GPO (Group Policies in windows domains) support, and that is something else that I'd dearly love to see. Can these 3rd party tools generate .msi files, or at least installers that will work with GPO? I have no insight on Group Policies. A look through their documentation should give you the answer. On 07/10/10 07:15 AM, Charles Marcus wrote: Fine, so use them... my main point was incremental updates, not doing it using the application updater (guess I could have been more clear on this point). We do use them. I just wish we had people who specialize in this capability. If there were 'package specialists', the burden of distribution/updating could be unloaded from the LibO dev community. On 07/10/10 07:15 AM, Charles Marcus wrote: Windows becomes the corner case... Fine, let it be the corner case where the internal updater is used. The mozilla auto-updaters work*great* on Windows, so the LibO auto-updater should be able to do the same (if coded properly). > There is no defined standard of where to install files, just > suggestions. And an update mechanism becomes an external program. > There are 3rd party apps for updating sources. I believe we should > explore those options. I vote for 'whatever works', as long as the efforts will also work toward full support for GPO...:) From all the discussions so far, we have three criteria for Windows installs: - clean up after itself - update (uninstall previous installation) - Group Policy installs/configuration Sound about right? And a wish for an Incremental Update Mechanism similar in nature to what Mozilla offers. For the *nix environment, I would like to get away from the large bash shell script file (*.sh). Also, the use of tar.gz, tar.bz2 or zip should be IMHO reserved for source file distribution. And as I mentioned earlier, we should look at engaging 'package specialists' - people who can alleviate some of the burden from devs about distribution. Am I missing anything from the discussions? Regards, Scott Furry -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: [tdf-discuss] LO deb repo
On 06/10/10 09:59 PM, Traduction.BIZ wrote: Hi, :-) I installed LibreOffice 3.3 beta on Ubuntu 10.10. My language support settings were set to en_ph and LibO would not load. I got the message: "Missing vcl resource. This indicates that files vital to localisation are missing. You might have a corrupt installation." followed by: "The program cannot be started. A general error occurred while accessing your central configuration." I changed my system-wide language to en and en_us but I'm still getting the same result. I have OOo 3.2 installed also (it's still working). Anyone got any ideas? David Nelson David, You may not have got all the needed packages. I got the same error message. do a sudo apt-get install libreoffice3* lobasis3.3* libreoffice-debian-menus ...will install "everything" including the extensions. Write back if you have issues. Regards, Scott Furry -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: [tdf-discuss] [GENERAL] New name
On 06/10/10 08:19 PM, Jean Hollis Weber wrote: On Wed, 2010-10-06 at 19:59 -0600, Scott Furry wrote: [snip] I thought the original suggestion was a very funny joke and did not take it seriously, and I thought the comments by Marc were in the same vein. Lighten up, mate. --Jean I did mention I liked the idea too. But where does a joke cross the line to show callousness? My vote is for MacGyver-Office "No paperclips were harmed". Scott -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: [tdf-discuss] [GENERAL] New name
On 06/10/10 07:17 PM, Marc Paré wrote: Marc, Nice thought. I like it. However, put that en francais... Front d'Liberation Buereau? (FLB - apologizes for bad French) I should point out that some may have an issue with the idea of a "Front" as it has some rather negative connotations. Also history may work against this idea (do a wiki search for FLQ to see why - I won't delve into the politics here). Just a thought. Regards, Scott Furry That would only work if you wore a headband, tatoos and your camouflage outfit! "It may not be pretty, but it's your swiss army knife of documents. Liberate your office! LibO!" LOL Marc Marc, I have to take issue with this sentiment. Applying an American-movie-styled stereotype and showing insensitivity to these situations doesn't help. Case in point, "The October Crisis" in Canada was a water-shed moment in the 1970's where the FLQ kidnapped government officials (one of whom later died in captivity). As a result the Federal Government imposed "The War Measures Act" that effectively squashed civil rights in all of Canada. This was all before the word 'terrorism' entered are daily lexicon. Believe me when I tell you that the Separatism movement in Quebec is passionate, runs deep and something you do not want to even remotely invoke. There are other situations around the world where such movements calling themselves 'fronts' have caused or are causing real, great harm to people. I was trying to draw your attention that any use of terms that implies a "front" or "movement" should be apolitical, culturally sensitive and demonstrate inclusiveness and change. Yes, we live in a hyper-sensitive, touch, politically correct and knee-jerk world. It sucks. And we should be going to great lengths at not stirring that pot. Change is good, implying revolution not so much. Regards, Scott Furry -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: [tdf-discuss] [GENERAL] New name
On 06/10/10 06:50 PM, Paul A Norman wrote: Design: 'The Office Liberaton Front" :) On 7 October 2010 12:51, Marc Paré wrote: Le 2010-10-06 19:02, Roman Gelbort a écrit : El 06/10/10 16:32, Marc Paré escribió: We could have our own ti-dyed T-shirt with LibO on them. :-) Oh and the pens too! We need the artwork... someone did something? No we are just musing. (Estamos hablando de los T-shirts solamente para divertirnos.) Marc -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot b e deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/ Marc, Nice thought. I like it. However, put that en francais... Front d'Liberation Buereau? (FLB - apologizes for bad French) I should point out that some may have an issue with the idea of a "Front" as it has some rather negative connotations. Also history may work against this idea (do a wiki search for FLQ to see why - I won't delve into the politics here). Just a thought. Regards, Scott Furry -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: [tdf-discuss] LibO beta deb packages causes freeze using pdf-export and several menu entries
On 06/10/10 05:06 PM, Friedrich Strohmaier wrote: Hi All, does anyone else experience frozen windows using pdf-export and "file" -> save as menuentry? file -> open doesn't start as doesn' the related icon System: Linux kubuntu 7.10 LibreOffice 3.3.0 OOO330m7 (Build:9526) libreoffice-build 3.2.99.0 Installed using deb-repo source deb http://download.tuxfamily.org/gericom/libreoffice / Gruß/regards I just tried a PDF-export with a Draw file I had open. No problems here. Using Debian(Squeeze) and same build. There are lots of settings that can be tweeked, could one of those settings cause your problem? Does pdf-export have a package dependency that you may be missing? (do we use iBatis or some kde lib?) Regards, Scott Furry -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: [tdf-discuss] Automatic Updates
On 06/10/10 05:00 PM, Jon Hamkins wrote: On 10/06/2010 11:39 AM, Marc Paré wrote: Le 2010-10-06 14:30, Steven Shelton a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/6/2010 2:21 PM, Charles Marcus wrote: Oh - and one thing that I'd really like to see is a simple 'incremental updater' that just downloads a 'patch' file and patches itself, like Firefox and Thunderbird and lots of other programs do now I would vote for this too. It would be amazing if it were capable. This functionality is already available in package managers, if we just take care to use it. yum, for example, supports delta RPMs. The way this works is LibO would publish delta RPMs that contain all the differences from the previous release, and then the users yum package manager would download the delta RPM, build the full RPM from it, and install. This approach has been in use for about a year and a half by fedora. I'm not sure about apt-get systems -- they probably have something similar. It really saves on bandwidth. Jon And I agree with Jon. +1 I've run into situations with OOo where installing/updating an extension becomes a mess. End result is having to clean out configurations/cache and start from scratch. Not Fun :( Not Recommended :P IIRC, apt-get uses a .diff file mechanism to apply patches. What I would very much like to avoid is the situation of a repository full of 'abandonware'. Having vast amounts of choice for extensions is wonderful for the community, so long as these extensions are being actively maintained. This I think is the problem faced by many community projects where users contribute the extension, based on some version of the main program. As the main program evolves, the extension suffers 'code rot' and joins a storage device full of unmaintained/abandoned extensions based on a particular version of the main program. (e.g. Apple - app store, Mozilla - add-on, Netbeans, etc.) Package Management, through dependencies, would ensure that an unsuitable extension is not used or installed. The end user can rely on this system to help keep their install stable and secure. Just tweaking a file in a package (like being able to edit a Mozilla add-on install.rdf file to pass a basic revision check) can't be accomplished. The extension contributor needs to update the extension, or someone else can pickup maintaining the extension. To me its a bit of waste where every large development entity has its own software repository based on their own update mechanisms. Someone else has figured out the hard parts, lets leverage their work rather than reinvent. Let's strive to let the users work on the operating system they've chosen and work in a way that is consistent with that OS. @Roman TY. Just trying to keep the conversation lively and informed. :D Cheers, Scott Furry -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: [tdf-discuss] Automatic Updates
On 06/10/10 12:21 PM, Charles Marcus wrote: On 2010-10-06 2:06 PM, Charles Marcus wrote: Yes there is... use the MSI system, which will take care of things like unpacking to the environments /tmp directory, launching the installer after unpacking (like it does now), then - and here is the trickey part I guess - detect a current installation, and offer to upgrade it, or to install a parallel version. Oh - and one thing that I'd really like to see is a simple 'incremental updater' that just downloads a 'patch' file and patches itself, like Firefox and Thunderbird and lots of other programs do now. Charles, For the most part I agree with you. Where, I have a problem is with: a) what MSIEXEC does b) purpose/function of incremental updates a) AFAIK, MSIEXEC doesn't enforce any kind of standards/best practices. Sure it does a lovely job of unpacking things and installing, but so do a lot of other 3rd party installer programs (NSIS, IzPack, Bitrock, et al.). Where these windows-based installers fail is that they do not guide or enforce a standard install methodology. Case in point is that the install path can be defined to whatever your heart desires. Sure you can use a predefined value to fill this variable (e.g. %programfiles%, %homedir%, etc), but there is no direction in the documentation as to what/where is the correct/best place - just suggestions. MSIEXEC is a means to an end - install methodology. Granted, how LibO uses the windows install is put into question. And I agree, we(community plural) should be doing a better job. I know of other programs whose installers ask if you want to remove the previous installation. So it is possible. The capabilities are there to install/uninstall, but the update mechanism is up for grabs as several programs each have their own ideas about how to scan the WWW for and incorporate updates. Which leads to... b) In my original post I mentioned that any install should respect the package management of the base operating system. I still agree with this notion. And unfortunately, Mozilla breaks this mold. *nix users will run into permission issues if they try to update Firefox and/or Thunderbird from the program menus. Even Ubuntuzilla (a command line python script to perform updates) is external to Mozilla and needs permissions to perform an update. I agree an incremental update is a good idea, but to emulate these two programs I suggest is not the shining example of 'best of bread'. The reason I object is that I have run into instances where entities external to Mozilla would hijack the install function placing plugins into the framework that the user either has no knowledge of and/or the installed code can only be removed through extraordinary measures (deleting from the command line/file manager). Lovely thought, but security becomes a major issue if we go this route. Package management (i.e. such as apt, yum, rpm, etc) means the download is coming from a well defined location (you can trace the source) and is put into a specific format (deb, rpm, et al). Security is a factor in these methodologies and you can reinstall, remove/purge the package through the command line or GUI. Incremental updates are apart of this function. OOo, and post-divergence - LibO, has an internal mechanism for updating extensions and itself. But this leads invariably to the situation I described above with Mozilla. Security and User Permissions then become serious factors. I agree that a better job of identifying an existing install and clean up is necessary. Windows becomes the corner case... There is no defined standard of where to install files, just suggestions. And an update mechanism becomes an external program. There are 3rd party apps for updating sources. I believe we should explore those options. Regards, Scott Furry -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: [tdf-discuss] Automatic Updates
And I wholeheartedly agree with the notion that M$ missed the boat here. Also, some kind of 'package management' feature would be nice. Note that Windows is only one OS (albeit with a rather large user base) out of many that can run LibO. The garbage that gets left behind after typical application install/uninstall on Windows both in the registry or dll files is in my mind a security flaw in its own right. There is a little known tool from M$ Download Centre called Windows Installer Cleanup that does some searching for registry and file/folder remnants. However, as for LibO, I concur that we should lead by example. For example, Debian publishes deb package guidelines and we should encourage devs to follow these guidelines as best as possible (and we probably do already, but state it anyway). And in some cases, these 'guidelines' can sometimes be more like hard&fast rules to live by. Conversely, there are 'guidelines'/'best practices' for Windows that leave one the impression that "they're not rules. They're more like guidelines." (POTC-TBP). In the end, the devs (guided by the community) have to define those 'best practices'. And cleaning up after an install is a good place to start. After that? That depends on feedback. Again, we're left with a plethora of 3rd party tools to choose from (if this choice isn't set in stone already) to handle install/update/uninstall functions. If there is an update functionality available (and AFAIK there is - tiger something springs to mind), let's use that rather than expecting devs to delve into MS OS fundamentals/package system. I don't think WE(community inclusive variety of the word) have the kind of bandwidth to develop a one-off windows based package system. That subject alone would probably open up barrels (to heck with cans) of worms. Food for thought. Regards, Scott Furry On 06/10/10 12:11 AM, Paul A Norman wrote: Nice clear thinking thanks Scott. I have heard from people that they don't like these artifacts of install, and also they often don't realise that they need to uninstall a previous version of OOO - and you can use quite a bit of disk space up, you end up with an install set and and install for each version of OOO at present afaik. The non-real package manager situation on Windows was I believe a business decission of M$ early in the piece focussed around commercial matters and policy ratrher than the User experience and good OS management. The Control Panel Add/Remove feature to my knowledge presents little or no behind the scenes core management tools for developers in the light of what you are talking about. Maybe an auto detect determined - LiBO package management routine for M$ systems, auto-detect as OOO presrntly does for other OS specific needs/features? I reckon that LiBO could give a really good lead in this - M$ also often leaves messes behind including large un-needed install and update files under WIndows DIR TREE - maybe this could be a point of differecne for LiBo amongst Office Products on M$ at least? Better management of these files could be a real draw card for people on M$, and there are still an awful lot of those M$ OS potential LiBO people! Paul On 6 October 2010 18:04, Scott Furry wrote: On 05/10/10 07:36 PM, Paul A Norman wrote: What I have found is that under OOO I have always been left with install directories with Mbs of space used for previous installations, the uninstall or new install doesn't seem to have removed them. I have been thinking tha it would be neat to have as it were, one install of LiBO and have it "updated" in all the same directories all the time, even if it were a new version of LiBO that was being "installed - updated", unless the User specifically elected to have multiple installations of different versions, making the default that there is only ever one main copy that is updated all the time. Paul On 6 October 2010 13:35, Goran Rakicwrote: У сре, 06. 10 2010. у 13:22 +1300, Paul A Norm an пише: Not sure where thinking is on this for LiBO at the moment, but is it concievable that updating even to each new version could, after a User response, be automatic and if elected by the User - replace the previous version automatically please? Paul Hi Paul, A first step would be to replicate the update notification feature available in the OpenOffice.org. I guess only infrastructure is missing for that one. I remember last year in Orvieto there were some talks about new packaging for all platforms that would allow online installation (allowing user to select, download and install any combination of languages, cutting space requirements to do full install sets). I do not know what is the current status of this development and if it would be easier to add autoupdate feature after that task is completed. Kind regards, Gor
Re: [tdf-discuss] Automatic Updates
On 05/10/10 07:36 PM, Paul A Norman wrote: What I have found is that under OOO I have always been left with install directories with Mbs of space used for previous installations, the uninstall or new install doesn't seem to have removed them. I have been thinking tha it would be neat to have as it were, one install of LiBO and have it "updated" in all the same directories all the time, even if it were a new version of LiBO that was being "installed - updated", unless the User specifically elected to have multiple installations of different versions, making the default that there is only ever one main copy that is updated all the time. Paul On 6 October 2010 13:35, Goran Rakic wrote: У сре, 06. 10 2010. у 13:22 +1300, Paul A Norman пише: Not sure where thinking is on this for LiBO at the moment, but is it concievable that updating even to each new version could, after a User response, be automatic and if elected by the User - replace the previous version automatically please? Paul Hi Paul, A first step would be to replicate the update notification feature available in the OpenOffice.org. I guess only infrastructure is missing for that one. I remember last year in Orvieto there were some talks about new packaging for all platforms that would allow online installation (allowing user to select, download and install any combination of languages, cutting space requirements to do full install sets). I do not know what is the current status of this development and if it would be easier to add autoupdate feature after that task is completed. Kind regards, Goran Rakic -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/ Paul, I do agree with the principles of your suggestion. Certainly on Windows installs this is true as evidenced by the "Install Folder" left on the desktop. And leaving the install folders around, not cleaning up after the install, or an uninstall not removing everything that was installed seems rather unprofessional. So, yes, I concur. However, I believe that may be only for Windows... *nix(Linux|Unix) installs can use a variety of install/package management programs (e.g. apt, yum, rpm, et al.) that resolve this issue. And these package management programs can also purge configuration files when removing a package. Package management also handle the kind of automatic update functionality you mention. But this is for *nix only... Any installation method that is deployed, in my mind, must 'respect' the package management of the base operating system. I get rather annoyed with multiple types of update/install mechanisms (setup.py for certain python based apps for example) that seem to circumvent OS package management programs. But there is no 'one size fits all' solution. There are numerous install frameworks (e.g. NSIS - NullSoft Install Script[Win only], or IzPack[Java - used by scala]). Again, they seem to circumvent package management on *nix machines while catering to Windows based installs. Problem is that Windows doesn't have a package management system. There is no one simple way to install, update or uninstall. Yes, there is msiexec, but that just provides a means to an end and doesn't handle update mechanisms nor framework/standardize installs. As for update mechanisms, we're left with 3rd party programs. Other than making sure that LibO cleans up after itself, how much effort do we want to put into installers? Regards, Scott Furry -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: [tdf-discuss] [GENERAL] New name
On 03/10/10 07:55 PM, Charles Marcus wrote: On 2010-10-03 5:10 PM, Charles-H. Schulz wrote: Let me clear so that we can move on: Unless Oracle gives us the trademark of OpenOffice.org, we're using LibreOffice, and some people love it, some people hate it, but as a matter of fact, we're not changing it anymore, so it's useless to request a change. It would be impossible to please everyone. I like it personally, but understand the arguments of those that don't - that said, it is not something that can just be changed at the drop of a hat, so, LibreOffice it is... :) Not to belabor this point... But there is also the issue of news reports. I've read at least a half-dozen stories about the "forking of Oracle" on online news sites. The list of articles include: - Glyn Moody's blog (OpenOffice.org Discovers the Joy of Forking http://rss.feedsportal.com/c/432/f/530831/s/e2f1b2c/l/0Lblogs0Nputerworlduk0N0Copen0Eenterprise0C20A10A0C0A90Copenofficeorg0Ediscovers0Ethe0Ejoy0Eof0Eforking0Cindex0Bhtm/story01.htm ) - and the H-Online ( LibreOffice - A fresh page for OpenOffice http://www.h-online.com/open/features/LibreOffice-A-fresh-page-for-OpenOffice-1097358.html ) There are other great write-ups. My point? With the press LibO has received, how would it look if there was a name change? Would the DF recover from the PR nightmare if there were a sudden announcement of a name change to the flagship product? Personally, I don't have a problem with the name. I'm presuming there was a host of discussion before the announcement of the DF, of which I missed. Fair enough. The decision has been made. I can accept that. I can appreciate that others have different viewpoints about the current name and decisions reached. Maybe we can revisit this issue when LibO reaches a major development milestone? And no, I do not recommend nor suggest naming LibO after Stephen Colbert ;-) Any chance we can move on to other issues? Regards, Scott Furry -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: [tdf-discuss] LO Quickstarter for GNOME?
On 03/10/10 03:16 PM, Jean Hollis Weber wrote:
On Sun, 2010-10-03 at 17:51 +0100, AG wrote:
On 03/10/10 17:03, Stefan Weigel wrote:
Hi,
Strange, because I do have this Option under Tools | Options | Memory.
LibreOffice 3.3.0
OOO330m7 (Build:9526)
libreoffice-build 3.2.99.0
Stefan
Mine is:
LibreOffice 3.3.0
OOO330m7 (Build:9526)
libreoffice-build 3.2.99.0
so snap. This is running on Debian testing using the *debs from the
site.
Go figure.
Well, the debs from the site are not promoted for download at
http://www.documentfoundation.org/download/ but only hidden at
http://download.documentfoundation.org/libreoffice/testing/ . A reason
may be, that the debs haven´t reached beta-state yet. I used the rpms
and aliened them for installing on my Ubuntu.
Stefan
That may make the difference then. I wasn't keen on aliening the rpms,
hence the straight *.deb route. Hopefully the upstream developers will
make the LibO packages available for apt-get installs.
OK - I'll assume that is what the issue is and just wait and see what
happens.
I used the debs from the testing link Stefan mentioned. I am on Ubuntu
10.04 with all the latest updates installed. My LibO is the same build
as yours. And *I* see the LibreOffice Quickstarter "Enable systray
Quickstater" option on the Tools> Options> Memory page. I don't see a
Quickstarter, but it was there the first time I opened LibO after
installing it.
If someone can tell me the bug report for this, I'll be happy to add my
comments. Or someone can add them for me.
--Jean
FYI...
Check mark not present on LibreOffice version I'm using currently on
Debian(Squeeze/testing) xfce.
Distribution ("cat /proc/version"):
Linux version 2.6.32-5-686 (Debian 2.6.32-23) (da...@debian.org) (gcc
version 4.3.5 (Debian 4.3.5-3) ) #1 SMP Sat Sep 18 02:14:45 UTC 2010
Java (from Debian Repositories - "java -version"):
java-6-sun-1.6.0.21
Info (from http://download.tuxfamily.org/gericom/libreoffice repository
- LibO about screen):
LibreOffice 3.3.0
OOO330m7 (Build:9526)
libreoffice-build 3.2.99.0
Regards,
Scott Furry
--
To unsubscribe, send an empty e-mail to
discuss+unsubscr...@documentfoundation.org
All messages you send to this list will be publicly archived and cannot be
deleted.
List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: [tdf-discuss] LO deb repo
On 03/10/10 04:25 AM, Scott Furry wrote: To amend #3 above: sudo apt-get install libreoffice3* lobasis3.3* ...will install "everything" including the extensions. Using wildcard characters for install AFAIK is not recommended. However, I was able to get the full LibreOffice installed and running. Opening documents from OpenOffice3.2 worked without a hitch. Just to amend my last... sudo apt-get install libreoffice-debian-menus will install the menu items for LibreOffice under the "Office" heading. Cheers to all, Scott Furry -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: [tdf-discuss] LO deb repo
On 03/10/10 03:42 AM, Nikola Yanev wrote: About the localizations, i thin LO is only in en_us for now and the other abt the repo, i think is kind of mail format that's why there's a space at / Thanx Once again :) On Sun, Oct 3, 2010 at 12:35 PM, Scott Furrywrot e: On 02/10/10 08:14 PM, Nikola Yanev wrote: Hi all Just to remid you that, Also all Debian, Ubuntu, Mint and other deb-based Linux users can use this temporary repository, until LibreOffice is included in main repos 1. Adding the repository: sudo echo “deb http://download.tuxfamily.org/gericom/libreoffice / #geri...@hummer” | tee -a /etc/apt/sources.list 2. Adding the signing key: wget deb http://download.tuxfamily.org/gericom/gericom.asc -q -O- | sudo apt-key add - And finaly: sudo apt-get update Nikola, Excellent Work! I found the following useful for Debian Squeeze(testing) XFCE: 1.(altered) add the line to /etc/apt/sources.list (remove quotes) "deb http://download.tuxfamily.org/gericom/libreoffice /" (note: observe spaces around last slash '/') 2. same as above 3. sudo apt-get install libreoffice3 installs libreoffice (meta package?) and picks up dependencies [ note: listing of what was installed: Get:1 http://download.tuxfamily.org/gericom/libreoffice/ libreoffice-ure 1.7.0-7 [3,932kB] Get:2 http://download.tuxfamily.org/gericom/libreoffice/ lobasis3.3-core0 1 3.3.0-7 [7,135kB] Get:3 http://download.tuxfamily.org/gericom/libreoffice/ lobasis3.3-core0 2 3.3.0-7 [301kB] Get:4 http://download.tuxfamily.org/gericom/libreoffice/ lobasis3.3-core0 3 3.3.0-7 [7,080kB] Get:5 http://download.tuxfamily.org/gericom/libreoffice/ lobasis3.3-core0 4 3.3.0-7 [30.9MB] Get:6 http://download.tuxfamily.org/gericom/libreoffice/ lobasis3.3-core0 5 3.3.0-7 [17.4MB] Get:7 http://download.tuxfamily.org/gericom/libreoffice/ lobasis3.3-core0 6 3.3.0-7 [12.2MB] Get:8 http://download.tuxfamily.org/gericom/libreoffice/ lobasis3.3-core0 7 3.3.0-7 [3,804kB] Get:9 http://download.tuxfamily.org/gericom/libreoffice/ lobasis3.3-image s 3.3.0-7 [16.4MB] Get:10 http://download.tuxfamily.org/gericom/libreoffice/ libreoffice3 3.3.0-7 [194kB] ] However, the libreoffice3 package didn't install the debian-menus deb archive. I must be missing something about apt-get usage as I had to manually downloaded the deb archive and perform a "dpkg -i [file].deb" on it. And presto - libreoffice is in my menus under "Office" [Yeah!] The only problem I found was when I started the base program I received an error message about: "...missing vcl resource. This indicates that files vital to localization are missing. You might have a corrupt installation." Any suggestions as to how I can convince apt to use "en-us" when my computer is using "en-ca"? Or should I just download the available en-us LibO deb files? Regards, Scott Furry -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/ Thanks Nikola. I had seen the discussion thread in an earlier message about en-us only. I was hoping that you might have an idea as to how to "encourage" apt to install the en-us packages. However, a search found a reference to the installation of OxygenOffice (derivative of OpenOffice http://sourceforge.net/apps/trac/ooop/wiki/Download ) where they show apt-get commands. To amend #3 above: sudo apt-get install libreoffice3* lobasis3.3* ...will install "everything" including the extensions. Using wildcard characters for install AFAIK is not recommended. However, I was able to get the full LibreOffice installed and running. Opening documents from OpenOffice3.2 worked without a hitch. Thank you for your efforts!! Regards, Scott Furry -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: [tdf-discuss] LO deb repo
On 02/10/10 08:14 PM, Nikola Yanev wrote: Hi all Just to remid you that, Also all Debian, Ubuntu, Mint and other deb-based Linux users can use this temporary repository, until LibreOffice is included in main repos 1. Adding the repository: sudo echo “deb http://download.tuxfamily.org/gericom/libreoffice / #geri...@hummer” | tee -a /etc/apt/sources.list 2. Adding the signing key: wget deb http://download.tuxfamily.org/gericom/gericom.asc -q -O- | sudo apt-key add - And finaly: sudo apt-get update Nikola, Excellent Work! I found the following useful for Debian Squeeze(testing) XFCE: 1.(altered) add the line to /etc/apt/sources.list (remove quotes) "deb http://download.tuxfamily.org/gericom/libreoffice / " (note: observe spaces around last slash '/') 2. same as above 3. sudo apt-get install libreoffice3 installs libreoffice (meta package?) and picks up dependencies [ note: listing of what was installed: Get:1 http://download.tuxfamily.org/gericom/libreoffice/ libreoffice-ure 1.7.0-7 [3,932kB] Get:2 http://download.tuxfamily.org/gericom/libreoffice/ lobasis3.3-core01 3.3.0-7 [7,135kB] Get:3 http://download.tuxfamily.org/gericom/libreoffice/ lobasis3.3-core02 3.3.0-7 [301kB] Get:4 http://download.tuxfamily.org/gericom/libreoffice/ lobasis3.3-core03 3.3.0-7 [7,080kB] Get:5 http://download.tuxfamily.org/gericom/libreoffice/ lobasis3.3-core04 3.3.0-7 [30.9MB] Get:6 http://download.tuxfamily.org/gericom/libreoffice/ lobasis3.3-core05 3.3.0-7 [17.4MB] Get:7 http://download.tuxfamily.org/gericom/libreoffice/ lobasis3.3-core06 3.3.0-7 [12.2MB] Get:8 http://download.tuxfamily.org/gericom/libreoffice/ lobasis3.3-core07 3.3.0-7 [3,804kB] Get:9 http://download.tuxfamily.org/gericom/libreoffice/ lobasis3.3-images 3.3.0-7 [16.4MB] Get:10 http://download.tuxfamily.org/gericom/libreoffice/ libreoffice3 3.3.0-7 [194kB] ] However, the libreoffice3 package didn't install the debian-menus deb archive. I must be missing something about apt-get usage as I had to manually downloaded the deb archive and perform a "dpkg -i [file].deb" on it. And presto - libreoffice is in my menus under "Office" [Yeah!] The only problem I found was when I started the base program I received an error message about: "...missing vcl resource. This indicates that files vital to localization are missing. You might have a corrupt installation." Any suggestions as to how I can convince apt to use "en-us" when my computer is using "en-ca"? Or should I just download the available en-us LibO deb files? Regards, Scott Furry -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
Re: [tdf-discuss] New GUI for OOo/Libreoffice....
On 02/10/10 01:45 PM, Friedrich Strohmaier wrote: Hi Mike, *, Mike Houben schrieb: Hey you all, I'm starting to make some scratches, but i need some help with your ideas from your point of vue. You knew the GUI of Microsoft's Office and the one Apple has done. Have you some things you like to have also in the GUI of our app? do you like to have other things that they don't have? what do you don't like about our GUI? I was involved in a discussion on that topic in Apr 2007 started by Chris Monahan: [discuss] Configuration Sets +++ excerpts http://www.mail-archive.com/disc...@openoffice.org/msg13753.html "Thu, 12 Apr 2007 13:32:01 -0700 It seems to me that those seeking to make decisions about OpenOffice, particularly the user interface, are plagued by the perpetual question: Is this for power users, or average users?" [..] "on top of that it would make sense to, at install time, or first use time, query the user as to what default configuration set they would like to use. for example: 1:power user. 2:simplified. 3:Microsoft Office like. 4:Open Office Classic" I introduced "capes" - configurationset + skin, which make it possible to compose those different environments of UI. http://www.mail-archive.com/disc...@openoffice.org/msg13845.html "André Wyrwa: [..] More particularly, such an option would have the benefit of enabling not only scaled configurations, but specialized setups for certain tasks or branches. me: In addition an other point of view: Imagine there was a framework, which allowed building that configuration sets (let's call them "capes" to complete the suite? :o))) in an easy way. This made it possible to widely extend the resources of active OOo development by separating core development from GUI development. The latter could be done by the new founded ux project." [..] +++ /excerpts I think this is a topic for: http://www.freedesktop.org/wiki/Software/LibreOffice/CrazyIdeas ;o)) Thanks for your help :) de nada :o)) possibly the time has come, old dreams to come true. Gruß/regards -1 I very much like the current OOo GUI interface. Simple, clean and usable. I understand the need to "improve things", but let's remember the adage: "A camel is a horse designed by committee" Not to dissuade this heartfelt and overwhelming need to help and improve LO, I would suggest that now is not the time to be entertaining ideas of rebuilding the wheel. We (an inclusive plural meaning the whole community) have a laundry list of things to take care that to me seem to have more of a priority. I would prefer that LO have a very solid and stable user base (including branding and word-of-mouth advertising) leaving all users (new and not-so-new) the impression that this project is serious and means business. And that LO is a viable alternative to that other expensive and constantly-needing-purchased-upgrade office suite. I've seen quite a bit of discussion threads on other topics. My summation so far of these topics includes (and not in any particular order): internationalization (multi-lingual LO), domains (international/national/regional), branding (if we can't get the OOo donated - work is needed to eradicate any/all references to OOo from the existing code base/documentation), advertising (i.e. encouraging others to "take the plunge" to ODF), and last but not least *documentation, documentation, documentation*! (The last one I will emphasize!). Once the dust settles, I have no problem with the discussion of visiting the user interface. This just seems to be wrong time to me. My 2 cents (no VAT/GST). Regards, Scott Furry -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
