Re: [tdf-discuss] Re: PPC Mac, Solaris and windows x86_64 Releases

2010-10-27 Thread Eric Hoch
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

2010-10-15 Thread Eric Hoch
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)

2010-10-13 Thread Eric Hoch
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)

2010-10-12 Thread Eric Hoch
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

2010-10-08 Thread Eric Hoch
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

2010-10-08 Thread Eric Hoch
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

2010-10-05 Thread Eric Hoch
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

2010-10-05 Thread Eric Hoch
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/