Re: [tdf-discuss] Re: PPC Mac, Solaris and windows x86_64 Releases
Hi Carlo, Am Wed, 27 Oct 2010 11:03:58 +0200 schrieb Carlo Strata: Il 27/10/2010 08:13, jonathon ha scritto: On 10/26/2010 07:17 PM, Carlo Strata wrote: - MacOSX 64 bit on both PPC and X86-64 platforms (I don't know if it exists a MacOSX PPC 64 bit OS...); Mac OS X is intrinsically 64 bits. Ok, but when Apple released firsts Intel based Mac not all CPUs were EM64T capable (please correct me if this is wrong) Right. The first generation of at least the Mac Mini has only IntelCore processors which are 32bit only which from time to time begins to harm me when newer versions become 64bit only. and this is, in my opinion, a lost opportunity/chance/occasion for Apple. So Intel Mac OSX for those hardware platforms were 32 bit only. Not quite right. Mac OS X is hast sort of two kinds of universal binaries. The first kind are the ones for ppc/x86 which can run on both chip architectures. The second kind are the ones that contain the 32bit and 64bit code. And now you can combine as you like it. At least the last generation G5 PPC processors used are 64bit. To allow LO to be run on as much apple hardware that is still used and runs with 10.4 we should build binaries that contain both 32bit and 64 bit for both PPC and x86. This is because I ask for: I don't know if PPC(32)/PPC64 yielded, in the past, a MacOS X 32/64 for PPC* platforms. Do you? It was once asked and discussed but by that time there was no need seen to build a 64bit OOo and we couldn't waist developer time to just do it because it can be done while the native version was in heavy development and priority one. I'm not a MacOS X user (I am an OpenSuSE x86-64 one), but I hope this builds are released if they are meaningful as well as I hope NeoOffice groups and efforts converge (!) in LibreOffice in the same way Go-OO already is. NeoOffice has chosen the GPL license so they need to re-license their code. The latter may reasults in a NeoOffice updater releases (now still on an old 3.1.2!), but is only an easy first advantage. This way is possible they can use LO 3.2.0 or 3.3.0 code. (IA64 one may not interest to people) Does a version of Windows currently ship for that chip? May be Windows server 2008/2008-R2? Afaik there was a Windows XP version for this chip, later on only the server versions of windows supported itanium and server 2008-R2 will be the last windows to run on Itanium http://www.microsoft.com/windowsserver2008/en/us/2008-IA.aspx. Eric -- ## de.OpenOffice.org - Office für MacOS X, Linux, Solaris Windows ## Openoffice.org - ich steck mit drin! -- Unsubscribe information: 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] Installing LibreOffice Extensions
Hi, Am Fri, 15 Oct 2010 11:08:10 -0300 schrieb Gustavo Pacheco: Hi! This is an important question... IMHO, many of these extensions are unuseful for the most users (like MySQL Connector or Wiki Publisher, for example). While they may be of no use for you it doesn't mean that they are for everyone out there. Maybe even users you don't assume needing those extensions are the ones actually using them. But I see a point that it is discussable if there should be any extensions in the default installation at all and if so the next discussion would be which ones and there we wouldn't agree on because everyone favors the extensions he uses and therefore thinks others need/use them as well. And, if you don´t have a JRE in your computer, you will recieve a message about it. (OK, an installed JRE is very common but, if the message appears for a simple user, it sounds like an error ...). In other case, in some companies, extensions are limited use. Many extensions in the original installation pack can force the corporative IT team to repack the installation to remove extensions. Additionaly, many extensions in LibreOffice are provided by Oracle . I think this isn´t a good way to provide more functionallity for LibreOffice. What do you think about LibreOffice without Oracle extensions? Only because Oracle wrote extensions LibO shouldn't include them? And the next step would be to rewrite extensions, that already exist just because they are from Oracle? For me this is not necessary but if you'd like to to do it and you feel better with it go on do it. Wouldn't it be better to allow the user to select which extensions [s]he wants to install, adding a special [warning] note to ones that require JRE? For the end-user I favor this too but companies may want a vanilla OOo without any extensions or the chance to disable the installations by default during the silent installation process or whichever process is chosen to install larger amounts of OOo on company PCs. Eric -- ## de.OpenOffice.org - Office für MacOS X, Linux, Solaris Windows ## Openoffice.org - ich steck mit drin! -- 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)
Hi Todd, Am Tue, 12 Oct 2010 16:27:47 -0400 schrieb todd rme: On Tue, Oct 12, 2010 at 2:47 PM, Eric Hoch eric_openoff...@gmx.de wrote: Hi Todd, Am Tue, 12 Oct 2010 13:14:49 -0400 schrieb todd rme: On Tue, Oct 12, 2010 at 8:47 AM, Charles Marcus cmar...@media-brokers.com wrote: On 2010-10-10 12:48 AM, 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. At least on my system writer is 19 mb, impress is 11 mb, and calc is 24 mb, while the core is about 120 mb. So the individual applications are anywhere from about 10% to about 2% the size of the core. Together the individual applications are about 85 mb. So yes, they are less than the core components, but I wouldn't say they are insignificant. You could cut out about 40% of the download size if you just wanted some of the smaller components. At the start of the process you would likely have to add those core 120MB to the 19 for writer, the 11 for Impress and the 24 for Calc, meaning that you have 414 MB installed instead of just 174MB for the whole Suite. I know that today hard disks are cheap and have at least 300GB or on desktops 500 or much more likely 1TB but again there are still company and home PCs out there which aren't up to date and on which 414MB compared to 174MB are significant. This calculation is based on your informations I don't have Windows here and so I cannot verify if current LibO only is 174MB under Windows. Eric -- ## de.OpenOffice.org - Office für MacOS X, Linux, Solaris Windows ## Openoffice.org - ich steck mit drin! -- 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)
Hi Todd, Scott, Am Sun, 10 Oct 2010 00:48:23 -0400 schrieb todd rme: On Sat, Oct 9, 2010 at 9:35 PM, Marc Paré m...@marcpare.com wrote: Le 2010-10-09 16:50, Scott Furry a écrit : On 09/10/10 02:11 PM, Marc Paré wrote: snip I agree, direction from the whole community on this, now that we have hashed it out a bit, would give clearer direction of expectations. snip 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 No problem. That is what we are here for. :-) Marc 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. I don't know how modular OOo or LibO are at this point but for a quite some time it was and still is known to me that the core of LibO/OOo is the biggest part of the Office and the stand alone app would require to download this core and its own modules meaning that if you install say Draw, Writer and Impress you would have to install the core three times plus three times additional module specific additions and therefore you need more disk space in the end then you will save by not installing a monolith OOo. So I see two tasks here. Task 1: Make OOo less monolith so that you can have small stand alone applications Task 2: Find a proper way to distribute and install them. 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. Very bad idea. I know a lot of end-users that are quite frustrated by the fact that they don't own the application they bought on a physical medium and have to re download it time and time again and that sometimes the company even tells them that they reached their maximum download and/or activations and that they now have to call this number or even send their bill to certify they bought the software. I know that we don't have those behavior but we would make the user believe that we are no better than the big money companies. In addition I know that most of us are used to fast internet connections with a lots of bandwidth but this isn't the case when you go out into the wild even here in germany are lots of places were DSL 1000 is the fastest you can get and try to install an whole office only via the net if you are on such a machine. You want the whole package which you download at your company, ask a friend to download and burn on a CD or give it to you on an usb stick. Also think of the older computers out there very slow to install applications and even though they are capable of going online installing e.g. the new Acrobat reader on such an older computer takes its while. I just had to deal with this and now it wasn't an option to use a free PDF reader because the form that needed to fill out was only shown and capable of being filled out correct in Adobe Reader. Eric -- ## de.OpenOffice.org - Office für MacOS X, Linux, Solaris Windows ## Openoffice.org - ich steck mit drin! -- 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] Automatic Updates
Hi Scott, Am Thu, 07 Oct 2010 17:49:48 -0600 schrieb Scott Furry: 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: 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. +1 This is a really good idea and some from german community were and are still working on getting the major distro package maintainers of OOo to one table and according to Mechtilde she had quite some success during FrosCon or was it OOoCon? 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. Agreed. Most, if not all, of the major distributions build the packages from source. Mostly because they add additional patches to either remove functions that don't match their policies and/or are possibly patent protected, are not 100% legal, not 100% free in the way the distribution understands it, etc. The Debian distribution has over 25,000 different packages in their repository. You think Debian has the time to look after this stuff? Yes, they do so. Rene builds every single OOo Milestone for Debian so that he can apply or remove patches and make OOo meet the debian guidelines. Especially since its staffed with volunteers around the globe? If somebody from the organization and/or community does not do the work (or DF pays someone to do it) LibO will either *never make into the repositories* -or- *become an extremely low priority* for distribution. Were did you get this information from? Which distribution maintainer told you this? 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. sigh so compress it. That's what the workflow of creating a deb/rpm/et al does. 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. Yes, and the deb package maintainers generally pull *the source* from the source provider (in this case, the LibO repositories), then builds their packages. Right. Again - let the distro package maintainers do the heavy lifting there... all LibO needs to do is provide access to the source. See my comments above. This is why I suggestion packaging specialists. See my comments about Debian above. I read them but they aren't quite right. I maybe wrong too and in the end only rene could really tell how he works on the Debian LibO/OOo. Eric -- ## de.OpenOffice.org - Office für MacOS X, Linux, Solaris Windows ## Openoffice.org - ich steck mit drin! -- 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
Hi Am Fri, 8 Oct 2010 00:18:19 +0700 schrieb Nguyen Vu Hung: On Thu, Oct 7, 2010 at 4:27 AM, Michele Zarri m.za...@gmail.com wrote: On 06/10/10 22:21, Jean Hollis Weber wrote: On Wed, 2010-10-06 at 14:21 -0400, 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 li k e unpacking to the environments /tmp directory, launching the installer after unpacking (like it does now), then - and here is the trickey pa r t I guess - detect a current installation, and offer to upgrade it, or t o install a parallel version. Oh - and one thing that I'd really like to see is a simple 'incrementa l updater' that just downloads a 'patch' file and patches itself, like Firefox and Thunderbird and lots of other programs do now. +10 --Jean +1 +1. And for Mac OS X, as it doesn't (?) have a package management system, we can leave the update agent as it is. There are various systems that take care of applying updates on Mac OS X but I don't know the name of the most popular one and if it has a license that allows it to use with LibO. However I know that when you use the underlying BSD to create pkg-packages for installation you can make update packages. While this would solve the automatic update problem partially it again would bring up discussions which is the right way to install Mac OS X applications. For the hardcore Mac user there is no other way than dragging and dropping the app into a folder he likes it to be and run it. However the switcher, most of the time coming from windows, is used to make a double click and either an installation routine occurs. If no installation routine occurs I've seen switcher use the app out of the diskimage all the time. They simple didn't copy the app into their application directory they left the dmg on their desktop/another folder, opened it every time they wanted to use the app and ejected it afterwards. I myself would prefer the drag and drop way and see if any of the licenses the automatic update mechanism used into apps like Bean, iTerm, MacTracker, VLC, Thunderbird is compatible with LGPL v3 and therefore the mechanism could be used in LibO. Eric -- ## de.OpenOffice.org - Office für MacOS X, Linux, Solaris Windows ## Openoffice.org - ich steck mit drin! -- 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] [MAILING LIST] interim structuring - a proposal
Hi Christoph, Thorsten, Am Mon, 4 Oct 2010 23:10:27 +0200 schrieb Thorsten Behrens: I do see the don't irritate non-technical QA people argument - but on the other hand I *do* want to get them technically savvy over time, and pick up the 'smell' on were to invest time, if stereotypeDev A starts to hack on the uno registry code again/stereotype. That's how it started for me. I'm still at the very beginning of coding at maybe I'm way to old to ever learn it entirely but I wanted to have some menu points in the Mac Menu of OOo once the Start Center and/or the last window is closed and you only see the menu bar. So I asked Eric Bachard where to look in the code for this menu part and after he told me I began reading that code parts and after some trial and error figured out how to manipulate them. I'm now happy that - at least in LibreOffice Beta - the changes I did are in the build and perhaps even better than I could have done them but it's a starting point. And when you do QA and talk about this on various fairs people come up with ideas and now that I did my first hackings I'm a step further into LibO/OOo. Building two camps again, I fear, will not yield the kind of collaborative athmosphere I so clearly envision for QA/Dev - case in point is one Raphael Bircher, who loudly complains about perceived problems doing QA in LibO - I want those concerns voiced on a list were they can be discussed with the devs, not to echo unheard in some zoo made up for QA. ;) +1 (I could probably live with a b...@tdf alias, where discussions is purely about bugs, how to reproduce them, etc - but really, QA is much more than that) +1 Eric -- ## de.OpenOffice.org - Office für MacOS X, Linux, Solaris Windows ## Openoffice.org - ich steck mit drin! -- 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] Very large icons in toolbar
Hi James, Am Sun, 3 Oct 2010 17:23:05 +0200 schrieb James Wilde: On Oct 3, 2010, at 17:17 , James Wilde wrote: LO 3.3beta Mac OSX 10.6.4 Have just opened a writer document, and the toolbar icons are very much bigger than the ones I have been using in OOo. Have not yet found a way to reduce the size of them, neither by checking intuitive locations nor from the help. Never mind - found it. Sorry. It would be more useful for other users out there if you tell them how you solved your problem. Eric -- ## de.OpenOffice.org - Office für MacOS X, Linux, Solaris Windows ## Openoffice.org - ich steck mit drin! -- 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/