Re: Request for review build.pl.

2013-08-05 Thread Andre Fischer

On 04.08.2013 23:19, janI wrote:

On 4 August 2013 22:53, janI  wrote:


Hi.

I have taken a very deep breath and added a new option to build.pl

if you run
build --all --genPO

dmake will not (as usual be called without parameters), but as "dmake
genPO". I need this to let the makefiles extract all texts from the source
files.

I have little experience with perl, so I hope someone can do a review
please.

I have committed the change in branch l1040 as R1510342.

Look forward to hear comments (or get changes).


I forgot a test message and removed the need for --all, please look at
R1510347 instead.


I looked at your changes ([r1510342], [r1510347]) and have some 
questions and remarks:


- Maybe this would be an opportunity to start readable variable names: I 
have no idea what $corDmake means.


- Instead of setting up the local $corDmake, maybe you could add the 
genPO target (or option?) to $dmake in get_commands()


- Maybe it would be possible to avoid a new build option altogether and 
use something like 'debug=t'?
  In get_options() such unrecognized "options" are appended to 
@dmake_args, and in get_commands() @dmake_args is

  appended to $dmake.

Best regards,

Andre


r1510342: 
http://svn.apache.org/viewvc/openoffice/branches/l10n40/main/solenv/bin/build.pl?r1=1505507&r2=1510342&pathrev=1510347
r1510347: 
http://svn.apache.org/viewvc/openoffice/branches/l10n40/main/solenv/bin/build.pl?r1=1510342&r2=1510347&pathrev=1510347


rgds
jan I.


rgds
jan I




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: [Build Environment] Windows - build using Java 7 (JDK 1.7) without having Visual Studio

2013-08-05 Thread Oliver-Rainer Wittmann

Hi,

On 03.08.2013 10:18, Andrea Pescetti wrote:

On 01/08/2013 Oliver-Rainer Wittmann wrote:

Version 2.7.1-1 now takes line endings in the patch file and in the file
to be patch serious. Thus, the application of a patch fails when the
line endings are different.


I haven't investigated this deeply at the time, but the hsqldb module
has a mix of line endings (that led to a broken patch too) and uses
CONVERTFILES in makefile.mk to harmonize them.



Thx for the feedback.

In the meanwhile my changes regarding 'patch' version 2.7.1-1 broke the 
Linux build - see our Linux 64bit and 32bit build bots.

I am working on a corresponding patch.




There are issues 121690 [3] and 121754 [4] regarding building with Java
7 (JDK 1.7) and HSQLDB. I think these issues are the duplicates of each
other [please, can one of the people involved in these issues - e.g.
Fred, Ariel or Andrea confirm this? Thx in advance]. As far as I
understood these issues are solved. Please correct me, if I am wrong.


121754 is fixed. 121690 is more generic; I confirm that after fixing
121754 I had no problems in building with Java 7, so it might be that
HSQLDB was the only problem. But I only tried with some "standard" build
options. Namely, I didn't try with --with-junit or similar, and Kay
reported issues with that.



On a Windows system with JRE 6 the installation of my build does not
recognize installed JRE 6 as an Java runtime environment (Menu - Tools -
Option - Java). This is no problem from my point of view as our Windows
users should not have JRE 6 installed anymore on their systems due to
its security risks. Does somebody contradicts?


As far as I know, this would be a significant limitation. We can now
build with Java 5, 6 or 7 and the build can work with Java 5, 6 or 7
(regardless of the version used for building). Restricting this would
require discussion, especially on less common platforms.



I agree that it would be a restriction, but due to the security risks of 
Oracle's JRE 6 I do not think that such a restriction hurts. In contrast 
it would 'help' our Windows users to update their Java environment.


Thus, let us start a new thread to discuss this topic.


Best regards, Oliver.


Regards,
   Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



review canceled: [Bug 122600] [SVG] problems in SvgSvgNode : [Attachment 81247] Patch to solve several errors with svgsvgnode

2013-08-05 Thread bugzilla
Regina Henschel  has canceled Regina Henschel
's request for review:
Bug 122600: [SVG] problems in SvgSvgNode
https://issues.apache.org/ooo/show_bug.cgi?id=122600

Attachment 81247: Patch to solve several errors with svgsvgnode
https://issues.apache.org/ooo/attachment.cgi?id=81247&action=edit

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



review requested: [Bug 122600] [SVG] problems in SvgSvgNode : [Attachment 81251] Updated patch

2013-08-05 Thread bugzilla
Regina Henschel  has asked Armin Le Grand
 for review:
Bug 122600: [SVG] problems in SvgSvgNode
https://issues.apache.org/ooo/show_bug.cgi?id=122600

Attachment 81251: Updated patch
https://issues.apache.org/ooo/attachment.cgi?id=81251&action=edit

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Help build ... I am frustrated.

2013-08-05 Thread janI
On 5 August 2013 08:57, Andre Fischer  wrote:

> On 03.08.2013 13:58, janI wrote:
>
>> This is solved on IRC thanks.
>>
>
> Can you give a short summary of the solution?  Thanks.
>

of course:

1)  build --show gives you a list of what is going to be built
2) /extras/l10n is referred to as L10N:ll10n in the build.lst (who could
know that)
3) for some unknown reason build does not write the usual header
(building) when entering extras/l10n

So my problem turned out to be in extras/source and not as the output
suggest in l10ntools.

I look forward to implement a more understandable build system.
rgds
jan I.


> -Andre
>
>
>>
>> rgds
>> jan I.
>>
>>
>>
>> On 2 August 2013 17:02, janI  wrote:
>>
>>
>>> On 2 August 2013 16:49, janI  wrote:
>>>
>>>

 On 2 August 2013 08:32, Oliver-Rainer Wittmann <
 orwittm...@googlemail.com

> wrote:
> Hi,
>
>
> On 01.08.2013 17:30, janI wrote:
>
>  Hi.
>>
>> When I e.g. stand in trunk/main/l10ntools and say
>>
>> build
>>
>> no params, it does not run prj/d.lst and does not copy to solver.
>>
>>
>>  Command 'build' called inside a non-gbuild module does not deliver
> the
> build results to the solver - it only creates the build results.
> To deliver the build results of a non-gbuild module into the solver you
> need to call command 'deliver'
>
> thx for the help, but now I am more confused, I keep getting an error
> in
>
 "build --all"

 cd l10ntools
 build --> success
 deliver --> success

 cd ../instsetoo_native
 build --all:l10ntool

 =
 Building module l10n
 =

 Entering /share/opensource/aoo/**branches/l10n40/extras/l10n/**source

 dmake: Executing shell macro: cd $(PRJ)/source && ls -1 */localize.sdf
 if [ -f ../unxlngx6.pro/misc/sdf ] ; then mv ../unxlngx6.pro/misc/sdf../
 unxlngx6.pro/misc/sdfunxlngx6.**pro_begone;
  fi
 rm -rf 
 ../unxlngx6.pro/misc/**sdfunxlngx6.pro_begone
 mkdir -p ../unxlngx6.pro/misc/sdf
 /usr/bin/perl /share/opensource/aoo/**branches/l10n40/main/solver/**
 400/
 unxlngx6.pro/bin/fast_merge.pl -sdf_files /tmp/mkqLKUYi -merge_dir ../
 unxlngx6.pro/misc/sdf && touch 
 ../unxlngx6.pro/misc/merge.**done
 Can't open perl script
 "/share/opensource/aoo/**branches/l10n40/main/solver/**400/
 unxlngx6.pro/bin/fast_merge.pl**": No such file or directory
 dmake:  Error code 2, while making 
 '../unxlngx6.pro/misc/merge.**done
 '


 I have renamed all l10ntools modules (to be sure I catch all places
 where
 the old modules are called), so it is correct that fast_merge does not
 exist.

 but, when its not "build" and not "deliver", where can I find the "shell
 macro" ?

  Sorry I reformulate my question, find it, its in extras/l10n/source/
>>> makefile.mk.
>>>
>>> Now I just wonder why and  where extras/l10n is called when building
>>> main/l10ntools.
>>>
>>> I look forward to the day, where we have a build system that is
>>> understandable :-)
>>>
>>> rgds
>>> jan I.
>>>
>>>
>>>  thx in advance.
 rgds
 jan I.

 Best regards, Oliver.

>
>   How can I pursuade build to build the targets AND copy to solver.
>
>> thx in advance.
>> rgds
>> jan I.
>>
>> Ps. the more frustrated I get, the more I think about replacing the
>> whole
>> build, but please dont let that stop you from giving me a hint.
>>
>>
>>  --**--**
> -
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**a**pache.org
> 
> >
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


Re: Open office Calc

2013-08-05 Thread Andre Fischer

On 02.08.2013 14:57, Rob Weir wrote:

BTW, I received a more detailed note from the user, to my personal
mail.  It sounds like this was an unintentional use of drag & drop
rather than a bug in how drag & drop works.

It looks like there is a system-wide registry setting for rag & drop
sensitivity in Windows:

http://answers.microsoft.com/en-us/windows/forum/windows_7-performance/can-you-turn-off-drag-and-drop-in-windows-7/81804779-a061-e011-8dfc-68b599b31bf5


The link above leads to a community forum that explains how to change 
the values of registry entry'HKEY_CURRENT_USER\Control Panel\Desktop'.  
To me that does not look like something other applications (like AOO) 
should use.


-Andre



But I don't know whether OpenOffice follows that setting or not.

I suggest we treat this like an accessibility issue.  Some users may
have limited finger coordination and accidentally invoke drag & drop.
But it will be best if we can hook into OS-level accessibility
settings for this.  For example, we don't have "sticky keys" support
or a setting for determining how fast a pair of clicks must be to be
considered a double-click.  We rely on the OS for that.   If we could
do something similar for drag & drop that would be great.

-Rob

On Fri, Aug 2, 2013 at 8:22 AM, Rob Weir  wrote:

On Fri, Aug 2, 2013 at 4:26 AM, Andris Vanags [Multistate]
 wrote:

Please disable the DRAG AND DROP (probably called a feature but it's really a 
bug), or put in an option to disable it.
I've just noticed that I've ruined a spreadsheet that's taken years to produce 
with data recorded in it daily.


Could you say a bit more about exactly how drag & drop caused
problems?  Did it crash your machine?  Did it work incorrectly?  Or
are you saying that you were not aware of drag & drop and so you
caused changes to your spreadsheet that you did not intend?

It would be good to narrow down the issue, so we can see whether this
is a bug in drag & drop itself, or something else.

Regards,

-Rob


Today I've found it's now all crap, useless, irreparable, a total waste of some 
7 years work and research!
Why didn't I create backups? I did, but the unadulterated ones are (before 
using open office calc)  now well over a year old, so all the data entered 
since then is lost or patchy/intermittent at best; all the continuity is gone! 
Thanks for that!   Seven years of work destroyed because someone didn't have 
the brains to disable this data ruining feature!

I have to revert to Microsoft where this evil feature can be disabled and start 
work all over again. It really does go to show that there's a big difference 
between professionally produced packages and something that's free or just 
knocked up in someone's bedroom!

If you want to help your users, get someone to look at this abomination before 
more work is irretrievably ruined.




This email and any files transmitted with it  are confidential
and intended solely for the use of the individual or entity to
whom they are addressed.

If you receive this message in error, please notify:
andris.van...@multistate.co.uk

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Request for review build.pl.

2013-08-05 Thread janI
On 5 August 2013 09:18, Andre Fischer  wrote:

> On 04.08.2013 23:19, janI wrote:
>
>> On 4 August 2013 22:53, janI  wrote:
>>
>>  Hi.
>>>
>>> I have taken a very deep breath and added a new option to build.pl
>>>
>>> if you run
>>> build --all --genPO
>>>
>>> dmake will not (as usual be called without parameters), but as "dmake
>>> genPO". I need this to let the makefiles extract all texts from the
>>> source
>>> files.
>>>
>>> I have little experience with perl, so I hope someone can do a review
>>> please.
>>>
>>> I have committed the change in branch l1040 as R1510342.
>>>
>>> Look forward to hear comments (or get changes).
>>>
>>>  I forgot a test message and removed the need for --all, please look at
>> R1510347 instead.
>>
>
> I looked at your changes ([r1510342], [r1510347]) and have some questions
> and remarks:
>
> - Maybe this would be an opportunity to start readable variable names: I
> have no idea what $corDmake means.
>
it meant corrected dmake, but its gone.

>
> - Instead of setting up the local $corDmake, maybe you could add the genPO
> target (or option?) to $dmake in get_commands()


> - Maybe it would be possible to avoid a new build option altogether and
> use something like 'debug=t'?
>   In get_options() such unrecognized "options" are appended to
> @dmake_args, and in get_commands() @dmake_args is
>   appended to $dmake.
>

good idea, I did it slightly different. Check on --genPO and then make a
push.

central change is removed, now its much more elegant and readable (if you
can call perl for readable).

see R1510396

thanks for the ideas.

rgds
jan I.


> Best regards,
>
> Andre
>
>
> r1510342: http://svn.apache.org/viewvc/**openoffice/branches/l10n40/**
> main/solenv/bin/build.pl?r1=**1505507&r2=1510342&pathrev=**1510347
> r1510347: http://svn.apache.org/viewvc/**openoffice/branches/l10n40/**
> main/solenv/bin/build.pl?r1=**1510342&r2=1510347&pathrev=**1510347
>
>
>> rgds
>> jan I.
>>
>>  rgds
>>> jan I
>>>
>>>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


Re: Wrong link on fr main page

2013-08-05 Thread Marcus (OOo)

Am 08/04/2013 03:34 PM, schrieb Guilhem Bonnefille:

Hi,

I've just noticed that the link called "liste des
nouveautés"
on the main page ( http://www.openoffice.org/fr/ ) points to an unrelated
page.

Best regards,


Thanks for the hint. I've fixed it.

Marcus

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Request for review build.pl.

2013-08-05 Thread Andre Fischer

On 05.08.2013 11:01, janI wrote:

On 5 August 2013 09:18, Andre Fischer  wrote:


On 04.08.2013 23:19, janI wrote:


On 4 August 2013 22:53, janI  wrote:

  Hi.

I have taken a very deep breath and added a new option to build.pl

if you run
 build --all --genPO

dmake will not (as usual be called without parameters), but as "dmake
genPO". I need this to let the makefiles extract all texts from the
source
files.

I have little experience with perl, so I hope someone can do a review
please.

I have committed the change in branch l1040 as R1510342.

Look forward to hear comments (or get changes).

  I forgot a test message and removed the need for --all, please look at

R1510347 instead.


I looked at your changes ([r1510342], [r1510347]) and have some questions
and remarks:

- Maybe this would be an opportunity to start readable variable names: I
have no idea what $corDmake means.


it meant corrected dmake, but its gone.


- Instead of setting up the local $corDmake, maybe you could add the genPO
target (or option?) to $dmake in get_commands()



- Maybe it would be possible to avoid a new build option altogether and
use something like 'debug=t'?
   In get_options() such unrecognized "options" are appended to
@dmake_args, and in get_commands() @dmake_args is
   appended to $dmake.


good idea, I did it slightly different. Check on --genPO and then make a
push.


I like the new version much better.  The use of the --genPO option 
instead of something like genPO=true makes it clear that dmake or build 
is not used for a regular build but for string extraction.




central change is removed, now its much more elegant and readable (if you
can call perl for readable).


You are right, much more elegant.
And yes, I think that one can write readable Perl scripts. At least I 
don't have to put on night vision goggles to distinguish spaces from 
tabs like I do for Python :-)


-Andre



see R1510396

thanks for the ideas.

rgds
jan I.



Best regards,

Andre


r1510342: http://svn.apache.org/viewvc/**openoffice/branches/l10n40/**
main/solenv/bin/build.pl?r1=**1505507&r2=1510342&pathrev=**1510347
r1510347: http://svn.apache.org/viewvc/**openoffice/branches/l10n40/**
main/solenv/bin/build.pl?r1=**1510342&r2=1510347&pathrev=**1510347



rgds
jan I.

  rgds

jan I



--**--**-
To unsubscribe, e-mail: 
dev-unsubscribe@openoffice.**apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: New Features and Enhancements video

2013-08-05 Thread Jürgen Schmidt
On 8/2/13 10:30 PM, Andrea Pescetti wrote:
> On 30/07/2013 Drew Jensen wrote:
>> I've been plowing ahead with my ideas here; not just as a single activity
>> to produce one or two videos but rather to start a framework for a
>> project
>> multi-media resources library, from which multiple videos, for multiple
>> purposes, would be generated. It could also be used to generate themed
>> artifacts for fliers/presentations/artwork(wallpapers, etc) that tie in
>> with these videos.
> 
> This is a great idea. The project can surely use better marketing
> materials, be it video chunks, screenshots, images, nice documents that
> show the new features...

I agree it's a good idea and I had the same ... But I wasn't able to
finish my tests in time for the 4.0 release.

But in general I think we should establish our own YouTube channel where
we provide screencasts and other media files on a regular basis.

Important is that we use a common framework and Drew started in this
direction already.

We need a common credit section for the end of all media files, with
some community info, links, donation info etc.

A common intro section would also make sense, or maybe a collection of
1-5 different including seasonal ones like a Christmas branded intro or so.

Screencast are better than a slideshow, at least if possible we should
trz to produce short screencast sections based on a script. And ideally
a native speaker with a good voice can provide a related spoken
explanation to the screencast (Drew's voice sounds well to me).

> 
>> For the 'community' category - These pieces:
>> CommunityBeforeCode_loop.mp4, suitable for use at a show table running
>> on a
>> laptop, voice over, no musical background - notice I did not tag this
>> with
>> a license.
>> AOO4_HotTamaleBaby.mp4 and hottamale.mp4 take that basic loop and add a
>> little party music.
> 
> The result is nice, but the music covers the voice at times. Also, I
> would keep links very simple, so not openoffice.apache.org and not the
> full URL to the inner pages. I think it's "Community over code" and not
> "before code". For the rest, it's impressive to see how the single
> chunks can be rearranged to target different use cases. The voiceover is
> good and clear.

we can have both music sections (with hopefully different music ;-)) and
voice over sections where a clear voice give explanations.

> 
>> So, my vision would be to at the end deliver, somehow, for the
>> projects use
>> an ISO with all the files used to produce the works, this would
>> include the
>> OpenShot and Pitivi (and other) project files, it would include some
>> instructions (which we would build as we do this) on how to make use
>> of the
>> material.
> 
> This would be perfect. At the moment we don't have many OpenOffice 4
> specific materials, so any well-done videos/graphics are welcome.

yes and with some more experience it should be really fun to produce
stuff like this ... I tried to play with iMovie on my Mac (see my very
first attempts http://people.apache.org/~jsc/test/AOO40_Test.mov) and I
just played around a bit...

Juergen



>> What I would hope could be done, if the good folks at source forge are
>> willing which I expect hey would be, is to generate a small and changing
>> over time set of videos and have these dished out to users in round robin
>> fashion.
> 
> This is stuff that we could also use on the main openoffice.org website,
> not only on the download site.
> 
> Regards,
>   Andrea.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: [Build Environment] Windows - build using Java 7 (JDK 1.7) without having Visual Studio

2013-08-05 Thread Jürgen Schmidt
On 8/5/13 10:11 AM, Oliver-Rainer Wittmann wrote:
> Hi,
> 
> On 03.08.2013 10:18, Andrea Pescetti wrote:
>> On 01/08/2013 Oliver-Rainer Wittmann wrote:
>>> Version 2.7.1-1 now takes line endings in the patch file and in the file
>>> to be patch serious. Thus, the application of a patch fails when the
>>> line endings are different.
>>
>> I haven't investigated this deeply at the time, but the hsqldb module
>> has a mix of line endings (that led to a broken patch too) and uses
>> CONVERTFILES in makefile.mk to harmonize them.
>>
> 
> Thx for the feedback.
> 
> In the meanwhile my changes regarding 'patch' version 2.7.1-1 broke the
> Linux build - see our Linux 64bit and 32bit build bots.
> I am working on a corresponding patch.
> 
>>
>>> There are issues 121690 [3] and 121754 [4] regarding building with Java
>>> 7 (JDK 1.7) and HSQLDB. I think these issues are the duplicates of each
>>> other [please, can one of the people involved in these issues - e.g.
>>> Fred, Ariel or Andrea confirm this? Thx in advance]. As far as I
>>> understood these issues are solved. Please correct me, if I am wrong.
>>
>> 121754 is fixed. 121690 is more generic; I confirm that after fixing
>> 121754 I had no problems in building with Java 7, so it might be that
>> HSQLDB was the only problem. But I only tried with some "standard" build
>> options. Namely, I didn't try with --with-junit or similar, and Kay
>> reported issues with that.
>>
>>
>>> On a Windows system with JRE 6 the installation of my build does not
>>> recognize installed JRE 6 as an Java runtime environment (Menu - Tools -
>>> Option - Java). This is no problem from my point of view as our Windows
>>> users should not have JRE 6 installed anymore on their systems due to
>>> its security risks. Does somebody contradicts?
>>
>> As far as I know, this would be a significant limitation. We can now
>> build with Java 5, 6 or 7 and the build can work with Java 5, 6 or 7
>> (regardless of the version used for building). Restricting this would
>> require discussion, especially on less common platforms.
>>
> 
> I agree that it would be a restriction, but due to the security risks of
> Oracle's JRE 6 I do not think that such a restriction hurts. In contrast
> it would 'help' our Windows users to update their Java environment.
> 
> Thus, let us start a new thread to discuss this topic.

we should think how relevant it is and if we have more work to support
it. As Oliver pointed out, the latest security problems of Java result
in probably many updated systems. I don't see that Java 5 or 6 is
important in the future and we should focus on the future.

Juergen

> 
> 
> Best regards, Oliver.
> 
>> Regards,
>>Andrea.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: IA2 branch testing of r1484083 merege with trunk

2013-08-05 Thread James Teh

On 2/08/2013 3:59 PM, V Stuart Foote wrote:

Also, no problems before or after the reboot with navigating onto the AOO
ia2 Writer session with  movments so not sure what was happening
there for you.
I've since discovered that I can only reproduce this if I run Writer 
directly; i.e. via the icon named "OpenOffice Writer" in the Start Menu 
or by running swriter.exe. If I run the main OpenOffice application 
(i.e. the icon named "OpenOffice" in the Start Menu or soffice.exe), 
everything works as it should, even after I select to open a new text 
document. If I open a file associated with OpenOffice, everything works 
correctly also.


Can you reproduce this by running Writer directly?

Jamie

--
James Teh
Director, NV Access Limited
Email: ja...@nvaccess.org
Web site: http://www.nvaccess.org/
Phone: +61 7 5667 8372


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Open office Calc

2013-08-05 Thread Rob Weir
On Mon, Aug 5, 2013 at 4:49 AM, Andre Fischer  wrote:
> On 02.08.2013 14:57, Rob Weir wrote:
>>
>> BTW, I received a more detailed note from the user, to my personal
>> mail.  It sounds like this was an unintentional use of drag & drop
>> rather than a bug in how drag & drop works.
>>
>> It looks like there is a system-wide registry setting for rag & drop
>> sensitivity in Windows:
>>
>>
>> http://answers.microsoft.com/en-us/windows/forum/windows_7-performance/can-you-turn-off-drag-and-drop-in-windows-7/81804779-a061-e011-8dfc-68b599b31bf5
>
>
> The link above leads to a community forum that explains how to change the
> values of registry entry'HKEY_CURRENT_USER\Control Panel\Desktop'.  To me
> that does not look like something other applications (like AOO) should use.
>

I don't think we should set a value there.  But if a value is already
set there, is there a reason why we should not follow it?

Drag & drop is across applications as well, e..g, from browser to
OpenOffice, as well as intra-app.  So it make sense for there to be a
system-wide setting for sensitivity.

-Rob


> -Andre
>
>>
>> But I don't know whether OpenOffice follows that setting or not.
>>
>> I suggest we treat this like an accessibility issue.  Some users may
>> have limited finger coordination and accidentally invoke drag & drop.
>> But it will be best if we can hook into OS-level accessibility
>> settings for this.  For example, we don't have "sticky keys" support
>> or a setting for determining how fast a pair of clicks must be to be
>> considered a double-click.  We rely on the OS for that.   If we could
>> do something similar for drag & drop that would be great.
>>
>> -Rob
>>
>> On Fri, Aug 2, 2013 at 8:22 AM, Rob Weir  wrote:
>>>
>>> On Fri, Aug 2, 2013 at 4:26 AM, Andris Vanags [Multistate]
>>>  wrote:

 Please disable the DRAG AND DROP (probably called a feature but it's
 really a bug), or put in an option to disable it.
 I've just noticed that I've ruined a spreadsheet that's taken years to
 produce with data recorded in it daily.

>>> Could you say a bit more about exactly how drag & drop caused
>>> problems?  Did it crash your machine?  Did it work incorrectly?  Or
>>> are you saying that you were not aware of drag & drop and so you
>>> caused changes to your spreadsheet that you did not intend?
>>>
>>> It would be good to narrow down the issue, so we can see whether this
>>> is a bug in drag & drop itself, or something else.
>>>
>>> Regards,
>>>
>>> -Rob
>>>
 Today I've found it's now all crap, useless, irreparable, a total waste
 of some 7 years work and research!
 Why didn't I create backups? I did, but the unadulterated ones are
 (before using open office calc)  now well over a year old, so all the data
 entered since then is lost or patchy/intermittent at best; all the
 continuity is gone! Thanks for that!   Seven years of work destroyed 
 because
 someone didn't have the brains to disable this data ruining feature!

 I have to revert to Microsoft where this evil feature can be disabled
 and start work all over again. It really does go to show that there's a big
 difference between professionally produced packages and something that's
 free or just knocked up in someone's bedroom!

 If you want to help your users, get someone to look at this abomination
 before more work is irretrievably ruined.




 This email and any files transmitted with it  are confidential
 and intended solely for the use of the individual or entity to
 whom they are addressed.

 If you receive this message in error, please notify:
 andris.van...@multistate.co.uk
>>
>> -
>>
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Wrong link on fr main page

2013-08-05 Thread FR web forum
This news is outdated.
I write another with AOO 4.0 available.
The hyperlink has been updated to jump to correct location

- Mail original -
De: "Marcus (OOo)" 
À: dev@openoffice.apache.org
Cc: "Guilhem Bonnefille" 
Envoyé: Lundi 5 Août 2013 11:05:11
Objet: Re: Wrong link on fr main page

Am 08/04/2013 03:34 PM, schrieb Guilhem Bonnefille:
> Hi,
>
> I've just noticed that the link called "liste des
> nouveautés"
> on the main page ( http://www.openoffice.org/fr/ ) points to an unrelated
> page.
>
> Best regards,

Thanks for the hint. I've fixed it.

Marcus

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: IA2 branch testing of r1484083 merege with trunk

2013-08-05 Thread V Stuart Foote
Jamie,


James Teh wrote
> I've since discovered that I can only reproduce this if I run Writer 
> directly; i.e. via the icon named "OpenOffice Writer" in the Start Menu 
> or by running swriter.exe. If I run the main OpenOffice application 
> (i.e. the icon named "OpenOffice" in the Start Menu or soffice.exe), 
> everything works as it should, even after I select to open a new text 
> document. If I open a file associated with OpenOffice, everything works 
> correctly also.
> 
> Can you reproduce this by running Writer directly?

Yes I get exactly the same result with this r1484083 based ia2 branch build. 

Except for the swriter.exe launcher, all the other components launch without
issue as does the Start Center.  And like you, when Writer is launched from
the start center, it comes up cleanly.

On an initial launch from the Writer shortcut, or if running the writer.exe
directly--the swriter.exe, soffice.exe, and soffice.bin will all run--but
the writer session hangs.  Have to manually end the writer process from task
manager.  A relaunch of any OpenOffice launcher or the start center panel
results in a recovery panel that will not complete.  

A reset of user profile (i.e. delete %AppData%\Openffice ) is the clean way
to return function, as edit of the XML recovery stanzas in the OpenOffice
registrymodifications.xcu configuration file is not worth the hassle.  The
user profile will rebuild to default, and just reactivate the Tools -->
Options --> Accessibility --> Support assistive technology tools.

This issue with the writer.exe launcher is not a problem on the AOO 4.0.0
release, so should resolve when Steve Y. rebases the ia2 branch.  Meanwhile,
best to simply not use the writer.exe launcher in working with the ia2
branch.

Stuart



--
View this message in context: 
http://openoffice.2283327.n4.nabble.com/IA2-branch-testing-of-r1484083-merege-with-trunk-tp4644296p4649355.html
Sent from the Development mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Download page could give approximate file size

2013-08-05 Thread Marcus (OOo)

Am 08/04/2013 09:11 PM, schrieb Kay Schenk:

On Sun, Aug 4, 2013 at 11:45 AM, Marcus (OOo)  wrote:


Am 07/27/2013 10:14 PM, schrieb Marcus (OOo):


Am 07/27/2013 10:10 PM, schrieb sebb:


It might be helpful if the download page showed the approximate file
size downloads.

This would help users to know how long it might take (and do they have
the space!) as well as offering an obvious sign if a download is
truncated by more than a few kB. Not perfect, but would have helped
the recent downloader.



Right, this would be much more helpful than having nothing.

I'll think about how to implement this into the current DL scripting.



I've created some new scripting and the result can be seen here:

http://ooo-site.staging.**apache.org/download/test/**index.html

Marcus


--**--**-
To unsubscribe, e-mail: 
dev-unsubscribe@openoffice.**apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



uh - oh -- I'm getting "unknown platform/OS" on this right now.

Still good on the production DL for LInux/RPM though.


The root cause was that the term "i686" wasn't recognized as x86 
platform. This was fixed and now it's working.


Marcus

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Updating BZ versions for next releases

2013-08-05 Thread Rob Weir
I'd like to update BZ to reflect the next release of AOO.

Version are tracked in three different fields:

Version, which currently allows the values "AOO 4.0.0" and "AOO410-dev"

Target Milestone, which currently allows the values "AOO 4.0", "AOO
4.1" and "AOO PleaseHelp"

Last Confirmation on, which currently allows the values "AOO 3.4.0",
"AOO 3.4.1", and "AOO 4.0.0".

I'd like to clean this up a little, as follows:

1) It is reasonable for someone to report a bug using 3.4.0, 3.4.1 or
4.0.0.  None of these versions are "end of life" so they should be
allowed for new bug reports.

2) I don't see the purpose of "AOO PleaseHelp" as a milestone version.
 Are we overloading meaning in this field?  If we really need track
issues that need help we should define a keyword for this.  So I'm
inclined to delete this milestone version number.

3) I'd also like to simplify the versions across the board to be just
"3.4.1", "4.0.0", etc., without the "AOO" prefix.

4) For Last Confirmation On, I'd like to hide values except for 4.0.
We should not be confirming bugs without testing on the most recent
version.  Sure, new bugs can set "Version" to 3.4.0 or 3.4.1, but
confirmation should occur on 4.0.

5)  I'll add a new Target Milestone of "4.0.1" and Version of
"4.0.1-dev" since it is likely that we will have a 4.0.1 release to
address some of the defects that have been reported on 4.0.0.

I'd love to hear your thoughts on this, even if it is just a quick +1.
 I'll hold off making any of these changes until this time Thursday.

Regards,

-Rob

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Updating BZ versions for next releases

2013-08-05 Thread janI
On 5 August 2013 17:38, Rob Weir  wrote:

> I'd like to update BZ to reflect the next release of AOO.
>
> Version are tracked in three different fields:
>
> Version, which currently allows the values "AOO 4.0.0" and "AOO410-dev"
>
> Target Milestone, which currently allows the values "AOO 4.0", "AOO
> 4.1" and "AOO PleaseHelp"
>
> Last Confirmation on, which currently allows the values "AOO 3.4.0",
> "AOO 3.4.1", and "AOO 4.0.0".
>
> I'd like to clean this up a little, as follows:
>
> 1) It is reasonable for someone to report a bug using 3.4.0, 3.4.1 or
> 4.0.0.  None of these versions are "end of life" so they should be
> allowed for new bug reports.
>
> 2) I don't see the purpose of "AOO PleaseHelp" as a milestone version.
>  Are we overloading meaning in this field?  If we really need track
> issues that need help we should define a keyword for this.  So I'm
> inclined to delete this milestone version number.
>
> 3) I'd also like to simplify the versions across the board to be just
> "3.4.1", "4.0.0", etc., without the "AOO" prefix.
>
> 4) For Last Confirmation On, I'd like to hide values except for 4.0.
> We should not be confirming bugs without testing on the most recent
> version.  Sure, new bugs can set "Version" to 3.4.0 or 3.4.1, but
> confirmation should occur on 4.0.
>
Since 3.4.0 and 3.4.1 (I actually thought it was only 3.4.1) are live
version, which we support, all bugs reported there must also be tested
there.

I agree they should also be tested in 4.0, but not only in 4.0.

So we would actually need a double confirmation, 3.4.x and 4.0 ?


>
> 5)  I'll add a new Target Milestone of "4.0.1" and Version of
> "4.0.1-dev" since it is likely that we will have a 4.0.1 release to
> address some of the defects that have been reported on 4.0.0.
>
> I'd love to hear your thoughts on this, even if it is just a quick +1.
>  I'll hold off making any of these changes until this time Thursday.
>

+1 to all except 4).

rgds
jan I.


>
> Regards,
>
> -Rob
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


RE: Updating BZ versions for next releases

2013-08-05 Thread V Stuart Foote
All reasonable changes that should improve the QA process using BZ, 
especially the "last confirmed on" 4.0.0--just will need to be kept up going 
forward.

My +1

ps.s thanks for asking this time ;-)
p.p.s a special CC for you Rainer so you are aware, here is the thread link in 
Nabble
http://openoffice.2283327.n4.nabble.com/Updating-BZ-versions-for-next-releases-tp4649357.html


From: Rob Weir [robw...@apache.org]
Sent: Monday, August 05, 2013 10:38 AM

...
I'd like to clean this up a little, as follows:

1) It is reasonable for someone to report a bug using 3.4.0, 3.4.1 or
4.0.0.  None of these versions are "end of life" so they should be
allowed for new bug reports.

2) I don't see the purpose of "AOO PleaseHelp" as a milestone version.
 Are we overloading meaning in this field?  If we really need track
issues that need help we should define a keyword for this.  So I'm
inclined to delete this milestone version number.

3) I'd also like to simplify the versions across the board to be just
"3.4.1", "4.0.0", etc., without the "AOO" prefix.

4) For Last Confirmation On, I'd like to hide values except for 4.0.
We should not be confirming bugs without testing on the most recent
version.  Sure, new bugs can set "Version" to 3.4.0 or 3.4.1, but
confirmation should occur on 4.0.

5)  I'll add a new Target Milestone of "4.0.1" and Version of
"4.0.1-dev" since it is likely that we will have a 4.0.1 release to
address some of the defects that have been reported on 4.0.0.

I'd love to hear your thoughts on this, even if it is just a quick +1.
 I'll hold off making any of these changes until this time Thursday.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Updating BZ versions for next releases

2013-08-05 Thread Rob Weir
On Mon, Aug 5, 2013 at 11:47 AM, janI  wrote:
> On 5 August 2013 17:38, Rob Weir  wrote:
>
>> I'd like to update BZ to reflect the next release of AOO.
>>
>> Version are tracked in three different fields:
>>
>> Version, which currently allows the values "AOO 4.0.0" and "AOO410-dev"
>>
>> Target Milestone, which currently allows the values "AOO 4.0", "AOO
>> 4.1" and "AOO PleaseHelp"
>>
>> Last Confirmation on, which currently allows the values "AOO 3.4.0",
>> "AOO 3.4.1", and "AOO 4.0.0".
>>
>> I'd like to clean this up a little, as follows:
>>
>> 1) It is reasonable for someone to report a bug using 3.4.0, 3.4.1 or
>> 4.0.0.  None of these versions are "end of life" so they should be
>> allowed for new bug reports.
>>
>> 2) I don't see the purpose of "AOO PleaseHelp" as a milestone version.
>>  Are we overloading meaning in this field?  If we really need track
>> issues that need help we should define a keyword for this.  So I'm
>> inclined to delete this milestone version number.
>>
>> 3) I'd also like to simplify the versions across the board to be just
>> "3.4.1", "4.0.0", etc., without the "AOO" prefix.
>>
>> 4) For Last Confirmation On, I'd like to hide values except for 4.0.
>> We should not be confirming bugs without testing on the most recent
>> version.  Sure, new bugs can set "Version" to 3.4.0 or 3.4.1, but
>> confirmation should occur on 4.0.
>>
> Since 3.4.0 and 3.4.1 (I actually thought it was only 3.4.1) are live
> version, which we support, all bugs reported there must also be tested
> there.
>
> I agree they should also be tested in 4.0, but not only in 4.0.
>
> So we would actually need a double confirmation, 3.4.x and 4.0 ?
>

It is a relatively new field, a custom field we added to BZ after
3.4.1.  The intent was to go through the old defect reports, the ones
that were reported against 3.3.0 and earlier, and retest them with
3.4.1 to see if they still existed.  In many cases the bugs no longer
existed.  So the "Last Confirmed On" field was there to record the
most-recent version of AOO that exhibited the bug.

We don't currently have a structured way of tracking a list of all
versions where the bug exists.  In general I don't think the QA
volunteers are going back and retesting bugs with earlier versions.
It is more the opposite -- retesting old bugs with the most recent
version of AOO.

>
>>
>> 5)  I'll add a new Target Milestone of "4.0.1" and Version of
>> "4.0.1-dev" since it is likely that we will have a 4.0.1 release to
>> address some of the defects that have been reported on 4.0.0.
>>
>> I'd love to hear your thoughts on this, even if it is just a quick +1.
>>  I'll hold off making any of these changes until this time Thursday.
>>
>
> +1 to all except 4).
>
> rgds
> jan I.
>
>
>>
>> Regards,
>>
>> -Rob
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



[Website]

2013-08-05 Thread Danielle Lambert
Bonjour,
J'aimerais que tout affichage dans "Open Office" soit en français. Je viens 
d'installer "Open Office 4.0" et les mots
sont en anglais. J'ai essayé de changer cela mais je n'y arrive pas. 
Pourriez-vous me dire comment mais en français
s.v.p. Merci. Danielle Lambert.

Re: Updating BZ versions for next releases

2013-08-05 Thread Rainer Bielefeld

Rob Weir schrieb:

Hi Rob,


1) It is reasonable for someone to report a bug using 3.4.0, 3.4.1 or
4.0.0.  None of these versions are "end of life" so they should be
allowed for new bug reports.


I agree.
An additional hint: for me the Version is an important distinguishing 
mark. Of course the exact version of appearance can be mentioned in a 
comment, but that is not very clear and can not be used for reliable 
queries. So for me selectable versions like 3.3.x or similar to narrow 
down version of appearance would have some benefit, and may be also for 
developers it might be useful to have easy access to reliable version 
info, what might ease to find the code and commit causing the problem. 
But of course, such versions only are useful if many users use them that 
way.



2) I don't see the purpose of "AOO PleaseHelp" as a milestone version.
  Are we overloading meaning in this field?  If we really need track
issues that need help we should define a keyword for this.  So I'm
inclined to delete this milestone version number.


+1



3) I'd also like to simplify the versions across the board to be just
"3.4.1", "4.0.0", etc., without the "AOO" prefix.


+1
Discharging that ballast also eases use of regular expressions in queries


4) For Last Confirmation On, I'd like to hide values except for 4.0.
We should not be confirming bugs without testing on the most recent
version.  Sure, new bugs can set "Version" to 3.4.0 or 3.4.1, but
confirmation should occur on 4.0.


+1
If someone can confirm a bug with 3.4.1, but no longer with 4.0, he 
should close that bug, or ask for help, but I can't see any benefit for 
a new entry "Last confirmed with 3.4." or so.



5)  I'll add a new Target Milestone of "4.0.1" and Version of
"4.0.1-dev" since it is likely that we will have a 4.0.1 release to
address some of the defects that have been reported on 4.0.0.


Sounds plausible.

Best Regards


Rainer

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Updating BZ versions for next releases

2013-08-05 Thread Andrea Pescetti

On 05/08/2013 Rob Weir wrote:

I'd love to hear your thoughts on this, even if it is just a quick +1.


Here's my quick +1, with a question: when I report a bug (typically a 
small regression) that I would like to see fixed in the possible 4.0.1 
release, shall I already set the Target to 4.0.1? In ancient times this 
was left to the developer who had accepted the bug, but we are now less 
strict in Bugzilla usage. And setting the target to 4.0.1 would help in 
evaluating if/when we need a 4.0.1.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Updating BZ versions for next releases

2013-08-05 Thread Marcus (OOo)

Am 08/05/2013 05:47 PM, schrieb janI:

On 5 August 2013 17:38, Rob Weir  wrote:


I'd like to update BZ to reflect the next release of AOO.

Version are tracked in three different fields:

Version, which currently allows the values "AOO 4.0.0" and "AOO410-dev"

Target Milestone, which currently allows the values "AOO 4.0", "AOO
4.1" and "AOO PleaseHelp"

Last Confirmation on, which currently allows the values "AOO 3.4.0",
"AOO 3.4.1", and "AOO 4.0.0".

I'd like to clean this up a little, as follows:

1) It is reasonable for someone to report a bug using 3.4.0, 3.4.1 or
4.0.0.  None of these versions are "end of life" so they should be
allowed for new bug reports.


+1


2) I don't see the purpose of "AOO PleaseHelp" as a milestone version.
  Are we overloading meaning in this field?  If we really need track
issues that need help we should define a keyword for this.  So I'm
inclined to delete this milestone version number.


If it's possible to delete the item without to leave gaps in the issues 
itself then +1.



3) I'd also like to simplify the versions across the board to be just
"3.4.1", "4.0.0", etc., without the "AOO" prefix.


+1


4) For Last Confirmation On, I'd like to hide values except for 4.0.
We should not be confirming bugs without testing on the most recent
version.  Sure, new bugs can set "Version" to 3.4.0 or 3.4.1, but
confirmation should occur on 4.0.


Since 3.4.0 and 3.4.1 (I actually thought it was only 3.4.1) are live
version, which we support, all bugs reported there must also be tested
there.

I agree they should also be tested in 4.0, but not only in 4.0.

So we would actually need a double confirmation, 3.4.x and 4.0 ?


Right, to recognize a regression faster it should be possible to set the 
values to 3.4.1 and 4.0.0 (is it possible to enable multiselection for 
this field?). Then you can see on the first view that the issue is not a 
new thing in 4.0.0 but was already exisiting also in 3.4.1.



5)  I'll add a new Target Milestone of "4.0.1" and Version of
"4.0.1-dev" since it is likely that we will have a 4.0.1 release to
address some of the defects that have been reported on 4.0.0.


+1

Then we can separate easily:

- fast fixed for 4.0.1
- general new things for 4.1.0


I'd love to hear your thoughts on this, even if it is just a quick +1.
  I'll hold off making any of these changes until this time Thursday.



+1 to all except 4).


I agree with Jan.

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: [Website]

2013-08-05 Thread Rory O'Farrell
On Mon, 05 Aug 2013 11:53:55 -0400
Danielle Lambert  wrote:

> Bonjour,
> J'aimerais que tout affichage dans "Open Office" soit en français. Je viens 
> d'installer "Open Office 4.0" et les mots
> sont en anglais. J'ai essayé de changer cela mais je n'y arrive pas. 
> Pourriez-vous me dire comment mais en français
> s.v.p. Merci. Danielle Lambert.

Vous pourriez telecharger un "Language pack" en français, qui changerait votre 
OpenOffice 4.0 en français (circa 15MO). Ou autrement, vous pourriez 
telecharger OpenOffice 4.0 en langue français (circa 140MO). Il n'y aurait 
aucune difference finalment.

Telecharger seulement de www.openoffice.org/download

-- 
Rory O'Farrell 

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Updating BZ versions for next releases

2013-08-05 Thread Rob Weir
On Mon, Aug 5, 2013 at 12:06 PM, Andrea Pescetti  wrote:
> On 05/08/2013 Rob Weir wrote:
>>
>> I'd love to hear your thoughts on this, even if it is just a quick +1.
>
>
> Here's my quick +1, with a question: when I report a bug (typically a small
> regression) that I would like to see fixed in the possible 4.0.1 release,
> shall I already set the Target to 4.0.1? In ancient times this was left to
> the developer who had accepted the bug, but we are now less strict in
> Bugzilla usage. And setting the target to 4.0.1 would help in evaluating
> if/when we need a 4.0.1.
>

That question probably deserves its own thread.  IMHO we need to
decide what a 4.0.1 is:

1) We might want to have it contain fixes for only the most urgent
bugs.  We could include new translations that are available as well.
If we make that restriction then the QA impact is less.  We don't need
to do a complete regression test pass.   If we did that then we could
use the "release blocker" field to track these issues.  We'd only fix
issues in 4.0.1 that have been discussed as release blockers.

2) Or we could open 4.0.1 up to all changes, in which case new bugs
can be introduced anywhere, possible translation impact, etc.

Personally I think 4.0.1 should be more like #1 -- strictly limited to
specific bug fixes.   We then use 4.1 (the trunk) for non-urgent
fixes.

-Rob


> Regards,
>   Andrea.
>
>
> -
> To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: qa-h...@openoffice.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: [Website]

2013-08-05 Thread Sylvain DENIS
Le 05/08/13 18:10, Rory O'Farrell a écrit :
> On Mon, 05 Aug 2013 11:53:55 -0400
> Danielle Lambert  wrote:
>
>> Bonjour,
>> J'aimerais que tout affichage dans "Open Office" soit en français. Je viens 
>> d'installer "Open Office 4.0" et les mots
>> sont en anglais. J'ai essayé de changer cela mais je n'y arrive pas. 
>> Pourriez-vous me dire comment mais en français
>> s.v.p. Merci. Danielle Lambert.
> Vous pourriez telecharger un "Language pack" en français, qui changerait 
> votre OpenOffice 4.0 en français (circa 15MO). Ou autrement, vous pourriez 
> telecharger OpenOffice 4.0 en langue français (circa 140MO). Il n'y aurait 
> aucune difference finalment.
>
> Telecharger seulement de www.openoffice.org/download
>
Pour confirmer le message de Rory, vous pouvez télécharger la version
française, ici : http://www.openoffice.org/fr/Telecharger/

Est-ce à cette adresse que vous avez télécharger votre version ?

Sylvain DENIS


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Updating BZ versions for next releases

2013-08-05 Thread Rob Weir
On Mon, Aug 5, 2013 at 12:07 PM, Marcus (OOo)  wrote:
> Am 08/05/2013 05:47 PM, schrieb janI:
>
>> On 5 August 2013 17:38, Rob Weir  wrote:
>>
>>> I'd like to update BZ to reflect the next release of AOO.
>>>
>>> Version are tracked in three different fields:
>>>
>>> Version, which currently allows the values "AOO 4.0.0" and "AOO410-dev"
>>>
>>> Target Milestone, which currently allows the values "AOO 4.0", "AOO
>>> 4.1" and "AOO PleaseHelp"
>>>
>>> Last Confirmation on, which currently allows the values "AOO 3.4.0",
>>> "AOO 3.4.1", and "AOO 4.0.0".
>>>
>>> I'd like to clean this up a little, as follows:
>>>
>>> 1) It is reasonable for someone to report a bug using 3.4.0, 3.4.1 or
>>> 4.0.0.  None of these versions are "end of life" so they should be
>>> allowed for new bug reports.
>
>
> +1
>
>
>>> 2) I don't see the purpose of "AOO PleaseHelp" as a milestone version.
>>>   Are we overloading meaning in this field?  If we really need track
>>> issues that need help we should define a keyword for this.  So I'm
>>> inclined to delete this milestone version number.
>
>
> If it's possible to delete the item without to leave gaps in the issues
> itself then +1.
>
>
>>> 3) I'd also like to simplify the versions across the board to be just
>>> "3.4.1", "4.0.0", etc., without the "AOO" prefix.
>
>
> +1
>
>
>>> 4) For Last Confirmation On, I'd like to hide values except for 4.0.
>>> We should not be confirming bugs without testing on the most recent
>>> version.  Sure, new bugs can set "Version" to 3.4.0 or 3.4.1, but
>>> confirmation should occur on 4.0.
>>>
>> Since 3.4.0 and 3.4.1 (I actually thought it was only 3.4.1) are live
>> version, which we support, all bugs reported there must also be tested
>> there.
>>
>> I agree they should also be tested in 4.0, but not only in 4.0.
>>
>> So we would actually need a double confirmation, 3.4.x and 4.0 ?
>

Current field is a single-selection drop down.  BZ does allow
multiple-selection fields, but I don't see any way to switch the type
of a field once it has been used.

In any case I'm not inviting debate of the process.  I appreciate that
some might wish that the QA volunteers spent twice as much time and
tested on twice as many versions of AOO.  But changing a BZ field
obviously doesn't cause that to happen.  My intent was merely to
update the field to support the purpose the field was added  in the
first place, to track the most-recent version of AOO the bug was
confirmed on.

>
> Right, to recognize a regression faster it should be possible to set the
> values to 3.4.1 and 4.0.0 (is it possible to enable multiselection for this
> field?). Then you can see on the first view that the issue is not a new
> thing in 4.0.0 but was already exisiting also in 3.4.1.
>
>
>>> 5)  I'll add a new Target Milestone of "4.0.1" and Version of
>>> "4.0.1-dev" since it is likely that we will have a 4.0.1 release to
>>> address some of the defects that have been reported on 4.0.0.
>
>
> +1
>
> Then we can separate easily:
>
> - fast fixed for 4.0.1
> - general new things for 4.1.0
>
>
>>> I'd love to hear your thoughts on this, even if it is just a quick +1.
>>>   I'll hold off making any of these changes until this time Thursday.
>>>
>>
>> +1 to all except 4).
>
>
> I agree with Jan.
>
> Marcus
>
>
>
> -
> To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: qa-h...@openoffice.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Updating BZ versions for next releases

2013-08-05 Thread Marcus (OOo)

Am 08/05/2013 06:26 PM, schrieb Rob Weir:

On Mon, Aug 5, 2013 at 12:06 PM, Andrea Pescetti  wrote:

On 05/08/2013 Rob Weir wrote:


I'd love to hear your thoughts on this, even if it is just a quick +1.



Here's my quick +1, with a question: when I report a bug (typically a small
regression) that I would like to see fixed in the possible 4.0.1 release,
shall I already set the Target to 4.0.1? In ancient times this was left to
the developer who had accepted the bug, but we are now less strict in
Bugzilla usage. And setting the target to 4.0.1 would help in evaluating
if/when we need a 4.0.1.



That question probably deserves its own thread.  IMHO we need to
decide what a 4.0.1 is:

1) We might want to have it contain fixes for only the most urgent
bugs.  We could include new translations that are available as well.
If we make that restriction then the QA impact is less.  We don't need
to do a complete regression test pass.   If we did that then we could
use the "release blocker" field to track these issues.  We'd only fix
issues in 4.0.1 that have been discussed as release blockers.

2) Or we could open 4.0.1 up to all changes, in which case new bugs
can be introduced anywhere, possible translation impact, etc.

Personally I think 4.0.1 should be more like #1 -- strictly limited to
specific bug fixes.   We then use 4.1 (the trunk) for non-urgent
fixes.


OK, before I put in my 2 cents also here. Rob or Andrea, will you open a 
new thread?


Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Updating BZ versions for next releases

2013-08-05 Thread Marcus (OOo)

Am 08/05/2013 06:31 PM, schrieb Rob Weir:

On Mon, Aug 5, 2013 at 12:07 PM, Marcus (OOo)  wrote:

Am 08/05/2013 05:47 PM, schrieb janI:


On 5 August 2013 17:38, Rob Weir   wrote:


I'd like to update BZ to reflect the next release of AOO.

Version are tracked in three different fields:

Version, which currently allows the values "AOO 4.0.0" and "AOO410-dev"

Target Milestone, which currently allows the values "AOO 4.0", "AOO
4.1" and "AOO PleaseHelp"

Last Confirmation on, which currently allows the values "AOO 3.4.0",
"AOO 3.4.1", and "AOO 4.0.0".

I'd like to clean this up a little, as follows:

1) It is reasonable for someone to report a bug using 3.4.0, 3.4.1 or
4.0.0.  None of these versions are "end of life" so they should be
allowed for new bug reports.



+1



2) I don't see the purpose of "AOO PleaseHelp" as a milestone version.
   Are we overloading meaning in this field?  If we really need track
issues that need help we should define a keyword for this.  So I'm
inclined to delete this milestone version number.



If it's possible to delete the item without to leave gaps in the issues
itself then +1.



3) I'd also like to simplify the versions across the board to be just
"3.4.1", "4.0.0", etc., without the "AOO" prefix.



+1



4) For Last Confirmation On, I'd like to hide values except for 4.0.
We should not be confirming bugs without testing on the most recent
version.  Sure, new bugs can set "Version" to 3.4.0 or 3.4.1, but
confirmation should occur on 4.0.


Since 3.4.0 and 3.4.1 (I actually thought it was only 3.4.1) are live
version, which we support, all bugs reported there must also be tested
there.

I agree they should also be tested in 4.0, but not only in 4.0.

So we would actually need a double confirmation, 3.4.x and 4.0 ?




Current field is a single-selection drop down.  BZ does allow
multiple-selection fields, but I don't see any way to switch the type
of a field once it has been used.

In any case I'm not inviting debate of the process.  I appreciate that


You asked for feedback. ;-)

> I appreciate that

some might wish that the QA volunteers spent twice as much time and
tested on twice as many versions of AOO.  But changing a BZ field
obviously doesn't cause that to happen.  My intent was merely to


I don't wish this. If they do it, they do it on their own. I believe 
there is also a way sometimes to trust the user or developer when they 
choose 3.4.1 and 4.0.0 as confirmed versions.



update the field to support the purpose the field was added  in the
first place, to track the most-recent version of AOO the bug was
confirmed on.


OK, looking at the title of the field then indeed only one version is 
possible.


However, I still think there is a value add to have the confirmation 
that a bug is occurring in more than just the most recent version.


Marcus




Right, to recognize a regression faster it should be possible to set the
values to 3.4.1 and 4.0.0 (is it possible to enable multiselection for this
field?). Then you can see on the first view that the issue is not a new
thing in 4.0.0 but was already exisiting also in 3.4.1.



5)  I'll add a new Target Milestone of "4.0.1" and Version of
"4.0.1-dev" since it is likely that we will have a 4.0.1 release to
address some of the defects that have been reported on 4.0.0.



+1

Then we can separate easily:

- fast fixed for 4.0.1
- general new things for 4.1.0



I'd love to hear your thoughts on this, even if it is just a quick +1.
   I'll hold off making any of these changes until this time Thursday.



+1 to all except 4).



I agree with Jan.

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Updating BZ versions for next releases

2013-08-05 Thread Rob Weir
On Mon, Aug 5, 2013 at 12:42 PM, Marcus (OOo)  wrote:
> Am 08/05/2013 06:31 PM, schrieb Rob Weir:
>
>> On Mon, Aug 5, 2013 at 12:07 PM, Marcus (OOo)
>> wrote:
>>>
>>> Am 08/05/2013 05:47 PM, schrieb janI:
>>>
 On 5 August 2013 17:38, Rob Weir   wrote:

> I'd like to update BZ to reflect the next release of AOO.
>
> Version are tracked in three different fields:
>
> Version, which currently allows the values "AOO 4.0.0" and "AOO410-dev"
>
> Target Milestone, which currently allows the values "AOO 4.0", "AOO
> 4.1" and "AOO PleaseHelp"
>
> Last Confirmation on, which currently allows the values "AOO 3.4.0",
> "AOO 3.4.1", and "AOO 4.0.0".
>
> I'd like to clean this up a little, as follows:
>
> 1) It is reasonable for someone to report a bug using 3.4.0, 3.4.1 or
> 4.0.0.  None of these versions are "end of life" so they should be
> allowed for new bug reports.
>>>
>>>
>>>
>>> +1
>>>
>>>
> 2) I don't see the purpose of "AOO PleaseHelp" as a milestone version.
>Are we overloading meaning in this field?  If we really need track
> issues that need help we should define a keyword for this.  So I'm
> inclined to delete this milestone version number.
>>>
>>>
>>>
>>> If it's possible to delete the item without to leave gaps in the issues
>>> itself then +1.
>>>
>>>
> 3) I'd also like to simplify the versions across the board to be just
> "3.4.1", "4.0.0", etc., without the "AOO" prefix.
>>>
>>>
>>>
>>> +1
>>>
>>>
> 4) For Last Confirmation On, I'd like to hide values except for 4.0.
> We should not be confirming bugs without testing on the most recent
> version.  Sure, new bugs can set "Version" to 3.4.0 or 3.4.1, but
> confirmation should occur on 4.0.
>
 Since 3.4.0 and 3.4.1 (I actually thought it was only 3.4.1) are live
 version, which we support, all bugs reported there must also be tested
 there.

 I agree they should also be tested in 4.0, but not only in 4.0.

 So we would actually need a double confirmation, 3.4.x and 4.0 ?
>>>
>>>
>>
>> Current field is a single-selection drop down.  BZ does allow
>> multiple-selection fields, but I don't see any way to switch the type
>> of a field once it has been used.
>>
>> In any case I'm not inviting debate of the process.  I appreciate that
>
>
> You asked for feedback. ;-)
>
>
>> I appreciate that
>>
>> some might wish that the QA volunteers spent twice as much time and
>> tested on twice as many versions of AOO.  But changing a BZ field
>> obviously doesn't cause that to happen.  My intent was merely to
>
>
> I don't wish this. If they do it, they do it on their own. I believe there
> is also a way sometimes to trust the user or developer when they choose
> 3.4.1 and 4.0.0 as confirmed versions.
>
>
>> update the field to support the purpose the field was added  in the
>> first place, to track the most-recent version of AOO the bug was
>> confirmed on.
>
>
> OK, looking at the title of the field then indeed only one version is
> possible.
>
> However, I still think there is a value add to have the confirmation that a
> bug is occurring in more than just the most recent version.
>

It can be useful in some cases.  If you can identify the last version
that did not have the defect, and the first version that did have the
defect, then you can narrow down the range of commits that could have
caused the bug.

Unfortunately I don't see an admin-accessible way to change the field
type.  In theory someone could work with Infra to get direct DB access
and  create a new multi-value field and then write some SQL to migrate
the old values into the multi-value schema.

But I'm not sure that would have much more value than noting these
facts in a comment field.  In terms of workflow, searching for all
confirmed bugs that have not been tested with at least 3.4.0 is
useful.  It gives us a list of bugs that we should re-test.  But I'm
not sure why I would search for bugs that were confirmed in a specific
old version like 3.4.0.

-Rob

> Marcus
>
>
>
>
>>> Right, to recognize a regression faster it should be possible to set the
>>> values to 3.4.1 and 4.0.0 (is it possible to enable multiselection for
>>> this
>>> field?). Then you can see on the first view that the issue is not a new
>>> thing in 4.0.0 but was already exisiting also in 3.4.1.
>>>
>>>
> 5)  I'll add a new Target Milestone of "4.0.1" and Version of
> "4.0.1-dev" since it is likely that we will have a 4.0.1 release to
> address some of the defects that have been reported on 4.0.0.
>>>
>>>
>>>
>>> +1
>>>
>>> Then we can separate easily:
>>>
>>> - fast fixed for 4.0.1
>>> - general new things for 4.1.0
>>>
>>>
> I'd love to hear your thoughts on this, even if it is just a quick +1.
>I'll hold off making any of these changes until this time Thursday.
>

 +1 to all except 4).
>>>
>>>
>>>
>>> I agree with Jan.
>>>
>>> Marcus
>
>
> --

Re: Updating BZ versions for next releases

2013-08-05 Thread Marcus (OOo)

Am 08/05/2013 06:51 PM, schrieb Rob Weir:

On Mon, Aug 5, 2013 at 12:42 PM, Marcus (OOo)  wrote:

Am 08/05/2013 06:31 PM, schrieb Rob Weir:


On Mon, Aug 5, 2013 at 12:07 PM, Marcus (OOo)
wrote:


Am 08/05/2013 05:47 PM, schrieb janI:


On 5 August 2013 17:38, Rob Weirwrote:


I'd like to update BZ to reflect the next release of AOO.

Version are tracked in three different fields:

Version, which currently allows the values "AOO 4.0.0" and "AOO410-dev"

Target Milestone, which currently allows the values "AOO 4.0", "AOO
4.1" and "AOO PleaseHelp"

Last Confirmation on, which currently allows the values "AOO 3.4.0",
"AOO 3.4.1", and "AOO 4.0.0".

I'd like to clean this up a little, as follows:

1) It is reasonable for someone to report a bug using 3.4.0, 3.4.1 or
4.0.0.  None of these versions are "end of life" so they should be
allowed for new bug reports.




+1



2) I don't see the purpose of "AOO PleaseHelp" as a milestone version.
Are we overloading meaning in this field?  If we really need track
issues that need help we should define a keyword for this.  So I'm
inclined to delete this milestone version number.




If it's possible to delete the item without to leave gaps in the issues
itself then +1.



3) I'd also like to simplify the versions across the board to be just
"3.4.1", "4.0.0", etc., without the "AOO" prefix.




+1



4) For Last Confirmation On, I'd like to hide values except for 4.0.
We should not be confirming bugs without testing on the most recent
version.  Sure, new bugs can set "Version" to 3.4.0 or 3.4.1, but
confirmation should occur on 4.0.


Since 3.4.0 and 3.4.1 (I actually thought it was only 3.4.1) are live
version, which we support, all bugs reported there must also be tested
there.

I agree they should also be tested in 4.0, but not only in 4.0.

So we would actually need a double confirmation, 3.4.x and 4.0 ?





Current field is a single-selection drop down.  BZ does allow
multiple-selection fields, but I don't see any way to switch the type
of a field once it has been used.

In any case I'm not inviting debate of the process.  I appreciate that



You asked for feedback. ;-)



I appreciate that

some might wish that the QA volunteers spent twice as much time and
tested on twice as many versions of AOO.  But changing a BZ field
obviously doesn't cause that to happen.  My intent was merely to



I don't wish this. If they do it, they do it on their own. I believe there
is also a way sometimes to trust the user or developer when they choose
3.4.1 and 4.0.0 as confirmed versions.



update the field to support the purpose the field was added  in the
first place, to track the most-recent version of AOO the bug was
confirmed on.



OK, looking at the title of the field then indeed only one version is
possible.

However, I still think there is a value add to have the confirmation that a
bug is occurring in more than just the most recent version.



It can be useful in some cases.  If you can identify the last version
that did not have the defect, and the first version that did have the
defect, then you can narrow down the range of commits that could have
caused the bug.

Unfortunately I don't see an admin-accessible way to change the field
type.  In theory someone could work with Infra to get direct DB access
and  create a new multi-value field and then write some SQL to migrate
the old values into the multi-value schema.


OK, then this discussion can end here if we have a technical limit.


But I'm not sure that would have much more value than noting these
facts in a comment field.  In terms of workflow, searching for all
confirmed bugs that have not been tested with at least 3.4.0 is
useful.  It gives us a list of bugs that we should re-test.  But I'm
not sure why I would search for bugs that were confirmed in a specific
old version like 3.4.0.


I don't talked about searching for old bugs or restesting them. Just 
about the possibilitiy to give a fast and visible indication if it's a 
new bug or a regression. That's all.


Marcus




Right, to recognize a regression faster it should be possible to set the
values to 3.4.1 and 4.0.0 (is it possible to enable multiselection for
this
field?). Then you can see on the first view that the issue is not a new
thing in 4.0.0 but was already exisiting also in 3.4.1.



5)  I'll add a new Target Milestone of "4.0.1" and Version of
"4.0.1-dev" since it is likely that we will have a 4.0.1 release to
address some of the defects that have been reported on 4.0.0.




+1

Then we can separate easily:

- fast fixed for 4.0.1
- general new things for 4.1.0



I'd love to hear your thoughts on this, even if it is just a quick +1.
I'll hold off making any of these changes until this time Thursday.



+1 to all except 4).




I agree with Jan.

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openof

Re: Download page could give approximate file size

2013-08-05 Thread sebb
On 4 August 2013 19:45, Marcus (OOo)  wrote:
> Am 07/27/2013 10:14 PM, schrieb Marcus (OOo):
>
>> Am 07/27/2013 10:10 PM, schrieb sebb:
>>>
>>> It might be helpful if the download page showed the approximate file
>>> size downloads.
>>>
>>> This would help users to know how long it might take (and do they have
>>> the space!) as well as offering an obvious sign if a download is
>>> truncated by more than a few kB. Not perfect, but would have helped
>>> the recent downloader.
>>
>>
>> Right, this would be much more helpful than having nothing.
>>
>> I'll think about how to implement this into the current DL scripting.
>
>
> I've created some new scripting and the result can be seen here:
>
> http://ooo-site.staging.apache.org/download/test/index.html

That's good to have the size in the main download box.
However, given that the size is approximate, I'm not sure it's
necessary to provide it to two decimal places.
Either give the exact size, or round to the nearest MB.

The page shows me:

Windows (EXE) and English (British) (~129.89 MByte).

Once downloaded, the Windows XP property page shows:
129 MB (136,201,626 bytes)

So I think the download box should also show 129MB

Unhelpfully, the SF downloads page [1] shows 136.2MB - looks as though
they divided by 1000 rather than 1024 - though it's unlikely anyone
would/could use that page as the file names are all truncated.  I
don't know if it's possible to change the column sze for the name
column. Would be good if that could be corrected along with the size.

[1] 
http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/en-GB/

Also, the KEYS/sigs/hashes ought to be shown before the alternate
downloads, ideally within the main green box as they relate to the
main download
The other downloads ought to be shown in a bit more detail in a separate box

> Marcus
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: New OpenOffice volunteer

2013-08-05 Thread Rob Weir
On Tue, Jul 30, 2013 at 10:05 PM, Edward Kuang  wrote:
> My name is Edward and I'm from the bay area in California. I'm a university
> student in my second year studying computer science. I use OpenOffice and I
> like it. Contributing to this project would improve my coding skills as
> well as making the project better. I've never worked on an open source
> project before and was wondering if this is a good first project to
> contribute to. I realize that the scope of the project is immense, but
> because there are so many people working on it, I'll get a lot of help too.
> I'm free most nights during the summer and I figured this would be quite
> productive for me. Thanks for your time.
>

Hi Edward,

Welcome to the Apache OpenOffice project.  This is a good code base,
but we have marked a number of issues in our Bugzilla database as
"easy" tasks, suitable for someone new to the codebase.  And we have
other, more seasoned developers who can answer questions and review
your first patch.

The first hurdle is to get a successful build.  My advice is:  ask
plenty of questions.  Everyone needs help at this stage, so don't
hesitate to post your build progress and what error message you are
seeing.

Regards,

-Rob


> -Ed

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Starting Introduction to Contributing to Apache OpenOffice Module

2013-08-05 Thread Rob Weir
On Sun, Aug 4, 2013 at 12:13 AM, Joshua Gaines  wrote:
> Hello,
>
> My name is Joshua Gaines. I am interested in contributing to Apache Open
> Office because I want to keep my coding skills up to date. I am from
> central Kentucky. I currently work as a Quality Assurance Engineer in the
> Software Development.
>

Hi Joshua,

Welcome to the Apache OpenOffice project!

Are you interested in volunteering on QA?  Or are you interested in
doing C++ work?   We also have some QA test automation in Java that
could use some attention, if you want to work in Java rather than C++.

In any case, I see that you have started the orientation modules.
That's a great first step.

Regards,

-Rob

> Thank you,
> Josh

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Starting Introduction to Contributing to Apache OpenOffice Module

2013-08-05 Thread Rob Weir
On Fri, Aug 2, 2013 at 9:56 AM, Sylvia Greenberg  wrote:
> Hello. My name is Sylvia. I live in Maryland. I am an experienced trainer and 
> writer who uses technology daily, including Microsoft Office, iPhoto, iMovie, 
> and GoogleDocs.
>
> My previous jobs include training adults in a business setting, training 
> teachers in K-12 education, and software documentation. Now that my three 
> children are getting older, I am looking for ways to write again and  
> volunteering to document Apache OpenOffice seems like a good fit.
>
> Apache OpenOffice is new to me, but I have used, written about, and trained 
> people to utilize similar software in the past. I use Macintosh at home and 
> have easy access to a fast internet connection.
>

Hi Sylvia,

Welcome to the Apache OpenOffice project!

I see you have already started the "new volunteer orientation"
modules.  That should give you some background on the project.  As
you'll see we have volunteers working on many different things, from
programming to testing, writing documentation, answering user support
questions, translations, marketing, maintaining our servers, etc.

You mentioned an interest in documentation.  We do have a dedicated
mailing list for doc.  If you could subscribe to that mailing list,
and re-introduce yourself there, the other doc volunteers can brief
you on where we are with the AOO 4.0 User Guide.   You can subscribe
by sending a blank email to doc-subscr...@openoffice.apache.org.  Once
subscribed you can send emails to d...@openoffice.apache.org.

Regards,

-Rob


> I'm looking forward to working with you.
> Sylvia Greenberg

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: [Website]

2013-08-05 Thread Rob Weir
2013/8/2 Tomasz Wawer 

> Hello,
>
> We are interested In implementing Open Office applications (writer, etc.)
> In our CRM.
>
> Our CRM is a Cloud model application available via website.
>
> ** **
>
> Do you have API we can use it?
>
> I it free of charge?
>
> **
>


Hello Tomasz,

OpenOffice has an SDK which includes an API for developing extensions to
OpenOffice.   You can download the SDK here:

http://www.openoffice.org/download/other.html#source

The OpenOffice SDK is open source, under the Apache License 2.0, the same
license that the OpenOffice application users.

Also, we have a dedicated mailing list for OpenOffice extension authors.
You might want to subscribe to that mailing list for any follow up
questions:

http://openoffice.apache.org/mailing-lists.html#api-mailing-list-public

Regards,

-Rob



> **
>
> Pozdrawiam / Regards,
>
> ** **
>
>
> [image: cid:C31B0C4E-263F-447A-86B0-3B2C3D3535F8]
>
> *
> Tomasz Wawer***
>
> *E-commerce Manager***
>
> * ***
>
> kom. 533 308 302
>
> e-mail:tomasz.wa...@trimtab.pl
>
> www.trimtab.pl
>
> * *
>
> [image: cid:2FDE5012-5917-4BF4-99FC-A3CA256680D7]
>
> ** **
>
> *Trimtab Arteria Management Sp. z o.o S.K.A z siedzibą w Warszawie, ul. **Jana
> Rosoła 10, wpisana do Rejestru Przedsiębiorców prowadzonego przez Sąd
> Rejonowy dla miasta stołecznego Warszawy, Wydział XIII Gospodarczy
> Krajowego Rejestru Sądowego pod numerem KRS 285680, NIP: 522-26-93-182,
> REGON: 015517421, wysokość kapitału zakładowego: 1.500.000,00 złotych (w
> pełni opłacony).***
>
> ** **
>
> ** **
>
> ** **
>


Re: Voluntário do Projeto

2013-08-05 Thread Rob Weir
Can someone who knows Portuguese respond to Prof. Sena?

Thanks!

-Rob

2013/8/1 Eduardo Lucas Sena :
> Prezados, boa noite!
>
> Meu nome é Eduardo Lucas Sena, sou professor de tecnologia para faculdades
> de pequeno, medio e grande porte localizas no Norte do Estado do Espirito
> Santo, Leste de Minas, Sul e Extremos Sul da Bahia, tecnico, graduado, Pós
> Latus Senso e Stritus Senso com titulação final de Mestre e aluno especial
> do curso de Doutorado em Engenharia de Computação pela Universidade Federal
> do Espirito Santo. Pretendo contribuir com o projeto, na divulgação,
> suporte técnico e teste de versões a fim de dirimir melhorias para o mesmo.
> O meu curriculo completo na base Lattes do MEC esta no Link abaixo como
> também o endereço da minha wiki no Projeto fedora o qual sou embaixador
> aqui no Norte do Estado do ES. Atualmente trabalho como professor das
> disciplinas de Engenharia de Software, Sistemas de Informação e Rede de
> Computadores da Faculdade vale do Cricaré a qual estou mediando uma
> parceria com a Red Hat.
>
> Atenciosamente.
>
> --
> Prof. MSc. Eduardo Lucas Sena
> Doutorando Eng. Computação - UFES
> prof.se...@gmail.com
> https://fedoraproject.org/wiki/User:Senna - Fedoraproject.org
> http://lattes.cnpq.br/8510338316521208
>  -
> CV-Lattes
>
> *P* *Antes de imprimir pense* *em* *seu compromisso* *com o* *meio ambiente.
> *
>
> Esta mensagem pode conter informação confidencial. Se você não for o
> destinatário ou a pessoa autorizada a receber esta mensagem, não poderá
> usar, copiar ou divulgar as informações nela contidas ou tomar qualquer
> ação baseada nessas informações. Se você recebeu esta mensagem por engano,
> favor avisar imediatamente o remetente, respondendo o e-mail e, em seguida,
> apague-o. Agradecemos sua cooperação. This message may contain confidential
> information. If you are not the addressee or authorized person to receive
> it for the addressee, you must not use, copy, disclose or take any action
> based on this message or any information herein. If you have received this
> message in error, please advise the sender immediately by replying this
> e-mail message and delete it. Thanks in advance for your cooperation.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: [REQUEST] database schema

2013-08-05 Thread Rob Weir
On Thu, Aug 1, 2013 at 12:32 PM, Itzel Morales Ramírez
 wrote:
> To whom it may concern,
>
> I'm a PhD student at Fondazione Bruno Kessler (ref 
> http://se.fbk.eu/publications/author/53897). I am considering Apache 
> OpenOffice bugzilla platform as a case study for my PhD research. I am 
> writing to you because I would like to analyse an excerpt of the database 
> (specifically bugs related to the product Writer) and specially the database 
> schema, in order to understand how is the storage of the comments from a 
> discussion and how they are linked.
>
> I really appreciate your time and support.
>

Hello Itzel,

What can we provide that would help you?  If you have any questions,
feel free to send them to this mailing list.

If you need an extract of data, or a database dump, then we would need
details on what you are seeking.

Some of the data can be extracting as an user, via the web interface.
But I would discourage "screen scraping" to extract large amounts of
data, since unusually access patterns from a single IP address can get
your IP address banned.

Regards,

-Rob


> Thanks in advance,
> Best regards,
> Itzel

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Solaris builds

2013-08-05 Thread Rob Weir
On Tue, Jul 30, 2013 at 9:20 PM, Kazunari Hirano  wrote:
> Happy AOO 4.0 release!
>
> But we don't have AOO 4.0 Solaris builds, do we?
> AOO 4.0 is buildable on Solaris, right?
> Should we get a volunteer who can build AOO 4.0 on Solaris?
>

I thought Adfinis Sygroup was working on the Solaris port.  But it was
done as a 3rd party port.  We have not released official Solaris
binaries from Apache.

Their latest posted version is 3.4.1:

https://adfinis-sygroup.ch/aoo-solaris-sparc

Regards,

-Rob


> Some Japanese Solaris users are asking for AOO 4.0 Solaris build.
>
> Thanks,
> khirano
> --
> khir...@apache.org
> Apache OpenOffice
> http://openoffice.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Proposal -- AOO 4.0.1 Release

2013-08-05 Thread Rob Weir
It looks like some regressions slipped through into AOO 4.0.0, and I'd
hate to wait until 4.1 to see them fixed.  So I wonder if we can aim
for a 4.0.1 release in the next few weeks to address the specific
high-urgency issues?   We could also use this opportunity to roll in
whatever new translations are available.

Suggested parameters of the release:

1) No string changes.  So existing translations don't need to change,
unless they are correcting a translation defect.

2) We carefully screen the code changes that are made.  A fast
turnaround release depends on not introducing any new bugs.  If we can
control carefully the changes going in then we can avoid spending a
month to re-test.  We'd focus the test effort on the fixes made, and
related areas.

3) Use the "release blocker" flag to propose defects for inclusion in
the 4.0.1 release.

4) New translations are rolled in, since a new translation cannot
break core code.

5) The one "feature" that I'd consider rolling in would be changes to
work with Mac OS 10.9.  It is not a regression in our code per se, but
it is a new issue, and a critical one.

6) Obviously, all bug fixes get checked into trunk as well, so they
are included in 4.1.

7) Aim to have 4.0.1 ready for September X, where 0

Re: Proposal -- AOO 4.0.1 Release

2013-08-05 Thread Hagar Delest

Top posting.

+1.
The quality of 4.0 is beyond what we used to see in the past. There are many 
users rather disappointed in the forum, especially Calc users. Many have to 
downgrade.

The sooner we correct that, the better, especially if we can do that before 
September.

Hagar


Le 05/08/2013 20:16, Rob Weir a écrit :


It looks like some regressions slipped through into AOO 4.0.0, and I'd
hate to wait until 4.1 to see them fixed.  So I wonder if we can aim
for a 4.0.1 release in the next few weeks to address the specific
high-urgency issues?   We could also use this opportunity to roll in
whatever new translations are available.

Suggested parameters of the release:

1) No string changes.  So existing translations don't need to change,
unless they are correcting a translation defect.

2) We carefully screen the code changes that are made.  A fast
turnaround release depends on not introducing any new bugs.  If we can
control carefully the changes going in then we can avoid spending a
month to re-test.  We'd focus the test effort on the fixes made, and
related areas.

3) Use the "release blocker" flag to propose defects for inclusion in
the 4.0.1 release.

4) New translations are rolled in, since a new translation cannot
break core code.

5) The one "feature" that I'd consider rolling in would be changes to
work with Mac OS 10.9.  It is not a regression in our code per se, but
it is a new issue, and a critical one.

6) Obviously, all bug fixes get checked into trunk as well, so they
are included in 4.1.

7) Aim to have 4.0.1 ready for September X, where 0

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Proposal -- AOO 4.0.1 Release

2013-08-05 Thread Marcus (OOo)

Am 08/05/2013 08:16 PM, schrieb Rob Weir:

It looks like some regressions slipped through into AOO 4.0.0, and I'd
hate to wait until 4.1 to see them fixed.  So I wonder if we can aim
for a 4.0.1 release in the next few weeks to address the specific
high-urgency issues?   We could also use this opportunity to roll in
whatever new translations are available.

Suggested parameters of the release:

1) No string changes.  So existing translations don't need to change,
unless they are correcting a translation defect.

2) We carefully screen the code changes that are made.  A fast
turnaround release depends on not introducing any new bugs.  If we can
control carefully the changes going in then we can avoid spending a
month to re-test.  We'd focus the test effort on the fixes made, and
related areas.

3) Use the "release blocker" flag to propose defects for inclusion in
the 4.0.1 release.


+1 to the 3 above.


4) New translations are rolled in, since a new translation cannot
break core code.


That's not automatically correct. Please remember the Calc issue were 
functions names had the same name (was it in Italian?) even when they 
had different purposes. The result were unusable spreadsheets.


So, in general yes but it is not 100% save.


5) The one "feature" that I'd consider rolling in would be changes to
work with Mac OS 10.9.  It is not a regression in our code per se, but
it is a new issue, and a critical one.


I don't follow Mac issues closely but I'm sure there is already a BZ issue.


6) Obviously, all bug fixes get checked into trunk as well, so they
are included in 4.1.


Ahm, yes, obviously.


7) Aim to have 4.0.1 ready for September X, where 0

I wouldn't set a (more or less) fixed date. In any case we should make 
sure that all the issue candidates are considered.


Marcus

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Download page could give approximate file size

2013-08-05 Thread Marcus (OOo)

Am 08/05/2013 07:11 PM, schrieb sebb:

On 4 August 2013 19:45, Marcus (OOo)  wrote:

Am 07/27/2013 10:14 PM, schrieb Marcus (OOo):


Am 07/27/2013 10:10 PM, schrieb sebb:


It might be helpful if the download page showed the approximate file
size downloads.

This would help users to know how long it might take (and do they have
the space!) as well as offering an obvious sign if a download is
truncated by more than a few kB. Not perfect, but would have helped
the recent downloader.



Right, this would be much more helpful than having nothing.

I'll think about how to implement this into the current DL scripting.



I've created some new scripting and the result can be seen here:

http://ooo-site.staging.apache.org/download/test/index.html


That's good to have the size in the main download box.
However, given that the size is approximate, I'm not sure it's
necessary to provide it to two decimal places.
Either give the exact size, or round to the nearest MB.

The page shows me:

Windows (EXE) and English (British) (~129.89 MByte).

Once downloaded, the Windows XP property page shows:
129 MB (136,201,626 bytes)

So I think the download box should also show 129MB


OK, I've eliminated the decimal places.


Unhelpfully, the SF downloads page [1] shows 136.2MB - looks as though
they divided by 1000 rather than 1024 - though it's unlikely anyone
would/could use that page as the file names are all truncated.  I
don't know if it's possible to change the column sze for the name
column. Would be good if that could be corrected along with the size.


Please have a look into this issue:
https://issues.apache.org/ooo/show_bug.cgi?id=122233


[1] 
http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/en-GB/

Also, the KEYS/sigs/hashes ought to be shown before the alternate
downloads, ideally within the main green box as they relate to the
main download


I've tried to realize that. But I think it's not possible as there is 
only one link possible as the whole pper green box has to be clickable: 
for the install file or for one of the signature/hash files.


The most important part is the install file. Everything else is secondary.


The other downloads ought to be shown in a bit more detail in a separate box


What do you mean with more details? What do you think is missing?

Thanks

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Proposal -- AOO 4.0.1 Release

2013-08-05 Thread Rob Weir
On Mon, Aug 5, 2013 at 3:30 PM, Marcus (OOo)  wrote:
> Am 08/05/2013 08:16 PM, schrieb Rob Weir:
>
>> It looks like some regressions slipped through into AOO 4.0.0, and I'd
>> hate to wait until 4.1 to see them fixed.  So I wonder if we can aim
>> for a 4.0.1 release in the next few weeks to address the specific
>> high-urgency issues?   We could also use this opportunity to roll in
>> whatever new translations are available.
>>
>> Suggested parameters of the release:
>>
>> 1) No string changes.  So existing translations don't need to change,
>> unless they are correcting a translation defect.
>>
>> 2) We carefully screen the code changes that are made.  A fast
>> turnaround release depends on not introducing any new bugs.  If we can
>> control carefully the changes going in then we can avoid spending a
>> month to re-test.  We'd focus the test effort on the fixes made, and
>> related areas.
>>
>> 3) Use the "release blocker" flag to propose defects for inclusion in
>> the 4.0.1 release.
>
>
> +1 to the 3 above.
>
>
>> 4) New translations are rolled in, since a new translation cannot
>> break core code.
>
>
> That's not automatically correct. Please remember the Calc issue were
> functions names had the same name (was it in Italian?) even when they had
> different purposes. The result were unusable spreadsheets.
>


I think of it this way:  Adding a new translation cannot break other
translations.  It can only break itself.  So adding translations has a
localized impact in terms of testing.

> So, in general yes but it is not 100% save.
>
>
>> 5) The one "feature" that I'd consider rolling in would be changes to
>> work with Mac OS 10.9.  It is not a regression in our code per se, but
>> it is a new issue, and a critical one.
>
>
> I don't follow Mac issues closely but I'm sure there is already a BZ issue.
>
>
>> 6) Obviously, all bug fixes get checked into trunk as well, so they
>> are included in 4.1.
>
>
> Ahm, yes, obviously.
>
>
>> 7) Aim to have 4.0.1 ready for September X, where 0> the better, IMHO.
>
>
> I wouldn't set a (more or less) fixed date. In any case we should make sure
> that all the issue candidates are considered.
>

As in most cases it will come down to the question:  Do we hold back
on fixes we've already made because there are other fixes that we have
not yet made?   So I'd start out with a goal date that we can all aim
for. That helps coordinate the effort.  But we all know that dates are
not carved in marble.

-Rob

> Marcus
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Call for volunteers to confirm 4.0 defects

2013-08-05 Thread Hagar Delest

Have reviewed all of them and added some comments. Some about the display issue 
with Calc.
Many are related to Mac.

Hagar


Le 05/08/2013 07:25, Yuzhen Fan a écrit :


Hi All,

Currently we have about 45 unconfirmed bugs in 4.0[1], if you have
interest in joining the bug confirmation work, could you please let me
know your Bugzilla ID and platforms you have, I will assign bugs to
you.

Thanks very much!

[1] 
https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Unconfirmed_Defects_on_4.0&sharer_id=249089&list_id=78518

Regard,
Yu Zhen

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Download page could give approximate file size

2013-08-05 Thread sebb
On 5 August 2013 20:38, Marcus (OOo)  wrote:
> Am 08/05/2013 07:11 PM, schrieb sebb:
>
>> On 4 August 2013 19:45, Marcus (OOo)  wrote:
>>>
>>> Am 07/27/2013 10:14 PM, schrieb Marcus (OOo):
>>>
 Am 07/27/2013 10:10 PM, schrieb sebb:
>
>
> It might be helpful if the download page showed the approximate file
> size downloads.
>
> This would help users to know how long it might take (and do they have
> the space!) as well as offering an obvious sign if a download is
> truncated by more than a few kB. Not perfect, but would have helped
> the recent downloader.



 Right, this would be much more helpful than having nothing.

 I'll think about how to implement this into the current DL scripting.
>>>
>>>
>>>
>>> I've created some new scripting and the result can be seen here:
>>>
>>> http://ooo-site.staging.apache.org/download/test/index.html
>>
>>
>> That's good to have the size in the main download box.
>> However, given that the size is approximate, I'm not sure it's
>> necessary to provide it to two decimal places.
>> Either give the exact size, or round to the nearest MB.
>>
>> The page shows me:
>>
>> Windows (EXE) and English (British) (~129.89 MByte).
>>
>> Once downloaded, the Windows XP property page shows:
>> 129 MB (136,201,626 bytes)
>>
>> So I think the download box should also show 129MB
>
>
> OK, I've eliminated the decimal places.
>
>
>> Unhelpfully, the SF downloads page [1] shows 136.2MB - looks as though
>> they divided by 1000 rather than 1024 - though it's unlikely anyone
>> would/could use that page as the file names are all truncated.  I
>> don't know if it's possible to change the column sze for the name
>> column. Would be good if that could be corrected along with the size.
>
>
> Please have a look into this issue:
> https://issues.apache.org/ooo/show_bug.cgi?id=122233
>
>
>> [1]
>> http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/en-GB/
>>
>> Also, the KEYS/sigs/hashes ought to be shown before the alternate
>> downloads, ideally within the main green box as they relate to the
>> main download
>
>
> I've tried to realize that. But I think it's not possible as there is only
> one link possible as the whole pper green box has to be clickable: for the
> install file or for one of the signature/hash files.
>
> The most important part is the install file. Everything else is secondary.

In that case, put the KEYS etc. in a separate box immediately under
the clickable box.

>
>> The other downloads ought to be shown in a bit more detail in a separate
>> box
>
>
> What do you mean with more details? What do you think is missing?

The links are very cramped, and there is no explanation of what they are for.

At present the page reads:

[LARGE GREEN DOWNLOAD BOX]
Get all platforms, languages, language packs | Source code and SDK |
Portable USB versions and third-party ports | Older and legacy
versions: 3.4.1 + 3.3.0 |
Signatures and hashes: KEYS , ASC , MD5 , SHA256 , How to verify? |
Release Notes

It should read something like:

[LARGE GREEN DOWNLOAD BOX]
Signatures and hashes: KEYS , ASC , MD5 , SHA256 , How to verify? |
Release Notes


Looking for other downloads?
* Builds of OpenOffice 4.0.0 for other platforms and languages
* Additional Language packs for your OpenOffice installation
* The source code and the SDK (Software Development Kit)
* Portable USB versions and third-party ports of OpenOffice
* Older and Legacy versions [should probably link to a separate page
that explains the difference between 3.4.1 and 3.3.0]

==

The rest of the page is laid out with plenty of space between items.
At present the light green box looks out of place, and is tricky to
read unless you know exactly what you are looking for (and you
understand the jargon).

> Thanks
>
> Marcus
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Proposal -- AOO 4.0.1 Release

2013-08-05 Thread Kay Schenk
On Mon, Aug 5, 2013 at 11:16 AM, Rob Weir  wrote:

> It looks like some regressions slipped through into AOO 4.0.0, and I'd
> hate to wait until 4.1 to see them fixed.  So I wonder if we can aim
> for a 4.0.1 release in the next few weeks to address the specific
> high-urgency issues?   We could also use this opportunity to roll in
> whatever new translations are available.
>
> Suggested parameters of the release:
>
> 1) No string changes.  So existing translations don't need to change,
> unless they are correcting a translation defect.
>
> 2) We carefully screen the code changes that are made.  A fast
> turnaround release depends on not introducing any new bugs.  If we can
> control carefully the changes going in then we can avoid spending a
> month to re-test.  We'd focus the test effort on the fixes made, and
> related areas.
>
> 3) Use the "release blocker" flag to propose defects for inclusion in
> the 4.0.1 release.
>

yes, please ... can we emphasize this more in some way? Maybe a post to
"users" or by some means to the forums.

And, I wish we had some kind of "BZ blender" to combine similar  items. :/


>
> 4) New translations are rolled in, since a new translation cannot
> break core code.
>
> 5) The one "feature" that I'd consider rolling in would be changes to
> work with Mac OS 10.9.  It is not a regression in our code per se, but
> it is a new issue, and a critical one.
>
> 6) Obviously, all bug fixes get checked into trunk as well, so they
> are included in 4.1.
>
> 7) Aim to have 4.0.1 ready for September X, where 0 the better, IMHO.
>

OK -- I think we'd already slated mid-Sept for new translations so this
would work well for us I think.


>
> -Rob
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
-
MzK

Success is falling nine times and getting up ten."
 -- Jon Bon Jovi


Re: [proposal] Establish new svn area for "branding" objects

2013-08-05 Thread Kay Schenk
On Fri, Aug 2, 2013 at 2:06 PM, Marcus (OOo)  wrote:

> Am 08/02/2013 10:41 PM, schrieb Dave Fisher:
>
>
>> On Aug 2, 2013, at 11:25 AM, Marcus (OOo) wrote:
>>
>>  Am 08/02/2013 06:46 PM, schrieb Kay Schenk:
>>>
 Re the discussion started Jul 24, 2013

 http://markmail.org/message/**6aoohsq4jbx5z7us

 This proposal is to establish an svn area for branding elements (svg
 files
 of logos, and other similar branding sources) in a new  area
 /openoffice/branding

 This will be outside the web access area.

 Lazy Consensus will be used for this proposal. If no objections are
 raised,
 work on establishing this area  can begin on Monday, noon PDT.

>>>
>>> I've looked into the root of the website and found that there is already
>>> an area for the website:
>>> .../ooo-site/branding/
>>>
>>
>> Do you mean ooo-site/trunk/content/**branding?
>>
>> That is the old branding folder that has commonly used graphical elements
>> like a tiny q.
>>
>> It is totally legacy. Please do not use it for this purpose at all.
>>
>
> Yes, I've seen the nice content. However, there is at least the
> *directory* that could be re-used.
>
> To have the one and only in the code section of SVN is better. For the
> website we can copy the best and most useful to this "branding/" directory
> in ooo-site.
>
> Marcus
>
>
>
>
>  so, this proposal is not for the website? How do we want to handle the
>>> other one?
>>>
>>> Thanks
>>>
>>> Marcus
>>>
>>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
OK, I am ready to move on this. Setting up a directory for "source" of
branding elements -- svg -- and accessible only as svn repository. This
means no access via the web server except through maybe viewvc.

Can someone tell me if setting up an area like:

/openoffice/branding

 is something we do or infra? I haven't tried anything and I'm not sure
about this.



-- 
-
MzK

Success is falling nine times and getting up ten."
 -- Jon Bon Jovi


Re: Download page could give approximate file size

2013-08-05 Thread Marcus (OOo)

Am 08/05/2013 10:24 PM, schrieb sebb:

On 5 August 2013 20:38, Marcus (OOo)  wrote:

Am 08/05/2013 07:11 PM, schrieb sebb:


On 4 August 2013 19:45, Marcus (OOo)   wrote:


Am 07/27/2013 10:14 PM, schrieb Marcus (OOo):


Am 07/27/2013 10:10 PM, schrieb sebb:



It might be helpful if the download page showed the approximate file
size downloads.

This would help users to know how long it might take (and do they have
the space!) as well as offering an obvious sign if a download is
truncated by more than a few kB. Not perfect, but would have helped
the recent downloader.




Right, this would be much more helpful than having nothing.

I'll think about how to implement this into the current DL scripting.




I've created some new scripting and the result can be seen here:

http://ooo-site.staging.apache.org/download/test/index.html



That's good to have the size in the main download box.
However, given that the size is approximate, I'm not sure it's
necessary to provide it to two decimal places.
Either give the exact size, or round to the nearest MB.

The page shows me:

Windows (EXE) and English (British) (~129.89 MByte).

Once downloaded, the Windows XP property page shows:
129 MB (136,201,626 bytes)

So I think the download box should also show 129MB



OK, I've eliminated the decimal places.



Unhelpfully, the SF downloads page [1] shows 136.2MB - looks as though
they divided by 1000 rather than 1024 - though it's unlikely anyone
would/could use that page as the file names are all truncated.  I
don't know if it's possible to change the column sze for the name
column. Would be good if that could be corrected along with the size.



Please have a look into this issue:
https://issues.apache.org/ooo/show_bug.cgi?id=122233



[1]
http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/en-GB/

Also, the KEYS/sigs/hashes ought to be shown before the alternate
downloads, ideally within the main green box as they relate to the
main download



I've tried to realize that. But I think it's not possible as there is only
one link possible as the whole pper green box has to be clickable: for the
install file or for one of the signature/hash files.

The most important part is the install file. Everything else is secondary.


In that case, put the KEYS etc. in a separate box immediately under
the clickable box.


I've rearranged the content of the sub-green box. Now the hash links are 
on top.



The other downloads ought to be shown in a bit more detail in a separate
box



What do you mean with more details? What do you think is missing?


The links are very cramped, and there is no explanation of what they are for.


Yes, that's right. A new format how these are presented to the users is 
needed.



At present the page reads:

[LARGE GREEN DOWNLOAD BOX]
Get all platforms, languages, language packs | Source code and SDK |
Portable USB versions and third-party ports | Older and legacy
versions: 3.4.1 + 3.3.0 |
Signatures and hashes: KEYS , ASC , MD5 , SHA256 , How to verify? |
Release Notes

It should read something like:

[LARGE GREEN DOWNLOAD BOX]
Signatures and hashes: KEYS , ASC , MD5 , SHA256 , How to verify? |
Release Notes


Looking for other downloads?
* Builds of OpenOffice 4.0.0 for other platforms and languages
* Additional Language packs for your OpenOffice installation
* The source code and the SDK (Software Development Kit)
* Portable USB versions and third-party ports of OpenOffice
* Older and Legacy versions [should probably link to a separate page
that explains the difference between 3.4.1 and 3.3.0]


OK. Let's see how this can be solved. This will be a bigger task. I'll 
put this into the Wiki for improvement.



==

The rest of the page is laid out with plenty of space between items.
At present the light green box looks out of place, and is tricky to


In general, because it's also green I don't think that it is out of 
place. The connection to the normal green box - and therefore to the 
most current release - should be obvious and not that it is something 
different. But ...



read unless you know exactly what you are looking for (and you
understand the jargon).


... yes, that's right. A new format could be better.

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: [proposal] Establish new svn area for "branding" objects

2013-08-05 Thread janI
On 5 August 2013 23:05, Kay Schenk  wrote:

> On Fri, Aug 2, 2013 at 2:06 PM, Marcus (OOo)  wrote:
>
> > Am 08/02/2013 10:41 PM, schrieb Dave Fisher:
> >
> >
> >> On Aug 2, 2013, at 11:25 AM, Marcus (OOo) wrote:
> >>
> >>  Am 08/02/2013 06:46 PM, schrieb Kay Schenk:
> >>>
>  Re the discussion started Jul 24, 2013
> 
>  http://markmail.org/message/**6aoohsq4jbx5z7us<
> http://markmail.org/message/6aoohsq4jbx5z7us>
> 
>  This proposal is to establish an svn area for branding elements (svg
>  files
>  of logos, and other similar branding sources) in a new  area
>  /openoffice/branding
> 
>  This will be outside the web access area.
> 
>  Lazy Consensus will be used for this proposal. If no objections are
>  raised,
>  work on establishing this area  can begin on Monday, noon PDT.
> 
> >>>
> >>> I've looked into the root of the website and found that there is
> already
> >>> an area for the website:
> >>> .../ooo-site/branding/
> >>>
> >>
> >> Do you mean ooo-site/trunk/content/**branding?
> >>
> >> That is the old branding folder that has commonly used graphical
> elements
> >> like a tiny q.
> >>
> >> It is totally legacy. Please do not use it for this purpose at all.
> >>
> >
> > Yes, I've seen the nice content. However, there is at least the
> > *directory* that could be re-used.
> >
> > To have the one and only in the code section of SVN is better. For the
> > website we can copy the best and most useful to this "branding/"
> directory
> > in ooo-site.
> >
> > Marcus
> >
> >
> >
> >
> >  so, this proposal is not for the website? How do we want to handle the
> >>> other one?
> >>>
> >>> Thanks
> >>>
> >>> Marcus
> >>>
> >>
> > --**--**-
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> dev-unsubscr...@openoffice.apache.org>
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
> >
> OK, I am ready to move on this. Setting up a directory for "source" of
> branding elements -- svg -- and accessible only as svn repository. This
> means no access via the web server except through maybe viewvc.
>
> Can someone tell me if setting up an area like:
>
> /openoffice/branding
>
>  is something we do or infra? I haven't tried anything and I'm not sure
> about this.
>
you should be able to do that with normal committer karma and the help of
"svn add"

rgds
jan I.

>
>
>
> --
>
> -
> MzK
>
> Success is falling nine times and getting up ten."
>  -- Jon Bon Jovi
>


Re: Proposal -- AOO 4.0.1 Release

2013-08-05 Thread janI
On 5 August 2013 21:55, Rob Weir  wrote:

> On Mon, Aug 5, 2013 at 3:30 PM, Marcus (OOo)  wrote:
> > Am 08/05/2013 08:16 PM, schrieb Rob Weir:
> >
> >> It looks like some regressions slipped through into AOO 4.0.0, and I'd
> >> hate to wait until 4.1 to see them fixed.  So I wonder if we can aim
> >> for a 4.0.1 release in the next few weeks to address the specific
> >> high-urgency issues?   We could also use this opportunity to roll in
> >> whatever new translations are available.
> >>
> >> Suggested parameters of the release:
> >>
> >> 1) No string changes.  So existing translations don't need to change,
> >> unless they are correcting a translation defect.
> >>
> >> 2) We carefully screen the code changes that are made.  A fast
> >> turnaround release depends on not introducing any new bugs.  If we can
> >> control carefully the changes going in then we can avoid spending a
> >> month to re-test.  We'd focus the test effort on the fixes made, and
> >> related areas.
> >>
> >> 3) Use the "release blocker" flag to propose defects for inclusion in
> >> the 4.0.1 release.
> >
> >
> > +1 to the 3 above.
> >
> >
> >> 4) New translations are rolled in, since a new translation cannot
> >> break core code.
> >
> >
> > That's not automatically correct. Please remember the Calc issue were
> > functions names had the same name (was it in Italian?) even when they had
> > different purposes. The result were unusable spreadsheets.
> >
>
>
> I think of it this way:  Adding a new translation cannot break other
> translations.  It can only break itself.  So adding translations has a
> localized impact in terms of testing.
>

I agree with rob, its only a theory that one translation can break another.

>
> > So, in general yes but it is not 100% save.
> >
> >
> >> 5) The one "feature" that I'd consider rolling in would be changes to
> >> work with Mac OS 10.9.  It is not a regression in our code per se, but
> >> it is a new issue, and a critical one.
> >
> >
> > I don't follow Mac issues closely but I'm sure there is already a BZ
> issue.
> >
> >
> >> 6) Obviously, all bug fixes get checked into trunk as well, so they
> >> are included in 4.1.
> >
> >
> > Ahm, yes, obviously.
> >
> >
> >> 7) Aim to have 4.0.1 ready for September X, where 0 >> the better, IMHO.
> >
> >
> > I wouldn't set a (more or less) fixed date. In any case we should make
> sure
> > that all the issue candidates are considered.
> >
>
> As in most cases it will come down to the question:  Do we hold back
> on fixes we've already made because there are other fixes that we have
> not yet made?   So I'd start out with a goal date that we can all aim
> for. That helps coordinate the effort.  But we all know that dates are
> not carved in marble.
>

When I consider what I hear in the "real" world, I would prefer a fast
release, solving the most important issues. We always have the possibility
to make a 4.02 if really needed.

rgds
jan I.

>
> -Rob
>
> > Marcus
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


Re: Proposal -- AOO 4.0.1 Release

2013-08-05 Thread David Gerard
On 5 August 2013 22:32, janI  wrote:

> When I consider what I hear in the "real" world, I would prefer a fast
> release, solving the most important issues. We always have the possibility
> to make a 4.02 if really needed.


x.0.x releases monthly are the way to go. I think LibreOffice really
got this right. If you do this, the users will be happier because they
anticipate happiness in the *near* future, not a year from now.


- d.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Download page could give approximate file size

2013-08-05 Thread sebb
On 5 August 2013 22:23, Marcus (OOo)  wrote:
> Am 08/05/2013 10:24 PM, schrieb sebb:
>
>> On 5 August 2013 20:38, Marcus (OOo)  wrote:
>>>
>>> Am 08/05/2013 07:11 PM, schrieb sebb:
>>>
 On 4 August 2013 19:45, Marcus (OOo)   wrote:
>
>
> Am 07/27/2013 10:14 PM, schrieb Marcus (OOo):
>
>> Am 07/27/2013 10:10 PM, schrieb sebb:
>>>
>>>
>>>
>>> It might be helpful if the download page showed the approximate file
>>> size downloads.
>>>
>>> This would help users to know how long it might take (and do they
>>> have
>>> the space!) as well as offering an obvious sign if a download is
>>> truncated by more than a few kB. Not perfect, but would have helped
>>> the recent downloader.
>>
>>
>>
>>
>> Right, this would be much more helpful than having nothing.
>>
>> I'll think about how to implement this into the current DL scripting.
>
>
>
>
> I've created some new scripting and the result can be seen here:
>
> http://ooo-site.staging.apache.org/download/test/index.html



 That's good to have the size in the main download box.
 However, given that the size is approximate, I'm not sure it's
 necessary to provide it to two decimal places.
 Either give the exact size, or round to the nearest MB.

 The page shows me:

 Windows (EXE) and English (British) (~129.89 MByte).

 Once downloaded, the Windows XP property page shows:
 129 MB (136,201,626 bytes)

 So I think the download box should also show 129MB
>>>
>>>
>>>
>>> OK, I've eliminated the decimal places.
>>>
>>>
 Unhelpfully, the SF downloads page [1] shows 136.2MB - looks as though
 they divided by 1000 rather than 1024 - though it's unlikely anyone
 would/could use that page as the file names are all truncated.  I
 don't know if it's possible to change the column sze for the name
 column. Would be good if that could be corrected along with the size.
>>>
>>>
>>>
>>> Please have a look into this issue:
>>> https://issues.apache.org/ooo/show_bug.cgi?id=122233
>>>
>>>
 [1]

 http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/en-GB/

 Also, the KEYS/sigs/hashes ought to be shown before the alternate
 downloads, ideally within the main green box as they relate to the
 main download
>>>
>>>
>>>
>>> I've tried to realize that. But I think it's not possible as there is
>>> only
>>> one link possible as the whole pper green box has to be clickable: for
>>> the
>>> install file or for one of the signature/hash files.
>>>
>>> The most important part is the install file. Everything else is
>>> secondary.
>>
>>
>> In that case, put the KEYS etc. in a separate box immediately under
>> the clickable box.
>
>
> I've rearranged the content of the sub-green box. Now the hash links are on
> top.
>
>
 The other downloads ought to be shown in a bit more detail in a separate
 box
>>>
>>>
>>>
>>> What do you mean with more details? What do you think is missing?
>>
>>
>> The links are very cramped, and there is no explanation of what they are
>> for.
>
>
> Yes, that's right. A new format how these are presented to the users is
> needed.
>
>
>> At present the page reads:
>>
>> [LARGE GREEN DOWNLOAD BOX]
>> Get all platforms, languages, language packs | Source code and SDK |
>> Portable USB versions and third-party ports | Older and legacy
>> versions: 3.4.1 + 3.3.0 |
>> Signatures and hashes: KEYS , ASC , MD5 , SHA256 , How to verify? |
>> Release Notes
>>
>> It should read something like:
>>
>> [LARGE GREEN DOWNLOAD BOX]
>> Signatures and hashes: KEYS , ASC , MD5 , SHA256 , How to verify? |
>> Release Notes
>> 
>> 
>> Looking for other downloads?
>> * Builds of OpenOffice 4.0.0 for other platforms and languages
>> * Additional Language packs for your OpenOffice installation
>> * The source code and the SDK (Software Development Kit)
>> * Portable USB versions and third-party ports of OpenOffice
>> * Older and Legacy versions [should probably link to a separate page
>> that explains the difference between 3.4.1 and 3.3.0]
>
>
> OK. Let's see how this can be solved. This will be a bigger task. I'll put
> this into the Wiki for improvement.
>
>
>> ==
>>
>> The rest of the page is laid out with plenty of space between items.
>> At present the light green box looks out of place, and is tricky to
>
>
> In general, because it's also green I don't think that it is out of place.
> The connection to the normal green box - and therefore to the most current
> release - should be obvious and not that it is something different. But ...

By "looks out of place" I meant that the styling/layout of the box
does not agree with the rest of the page.

>
>> read unless you know exactly what you are looking for (and you
>> understand the jargon).
>
>
> ... yes, that's right. A new format could be better.
>
> Marcus
>

---

Re: [proposal] Establish new svn area for "branding" objects

2013-08-05 Thread Kay Schenk
On Mon, Aug 5, 2013 at 2:26 PM, janI  wrote:

> On 5 August 2013 23:05, Kay Schenk  wrote:
>
> > On Fri, Aug 2, 2013 at 2:06 PM, Marcus (OOo) 
> wrote:
> >
> > > Am 08/02/2013 10:41 PM, schrieb Dave Fisher:
> > >
> > >
> > >> On Aug 2, 2013, at 11:25 AM, Marcus (OOo) wrote:
> > >>
> > >>  Am 08/02/2013 06:46 PM, schrieb Kay Schenk:
> > >>>
> >  Re the discussion started Jul 24, 2013
> > 
> >  http://markmail.org/message/**6aoohsq4jbx5z7us<
> > http://markmail.org/message/6aoohsq4jbx5z7us>
> > 
> >  This proposal is to establish an svn area for branding elements (svg
> >  files
> >  of logos, and other similar branding sources) in a new  area
> >  /openoffice/branding
> > 
> >  This will be outside the web access area.
> > 
> >  Lazy Consensus will be used for this proposal. If no objections are
> >  raised,
> >  work on establishing this area  can begin on Monday, noon PDT.
> > 
> > >>>
> > >>> I've looked into the root of the website and found that there is
> > already
> > >>> an area for the website:
> > >>> .../ooo-site/branding/
> > >>>
> > >>
> > >> Do you mean ooo-site/trunk/content/**branding?
> > >>
> > >> That is the old branding folder that has commonly used graphical
> > elements
> > >> like a tiny q.
> > >>
> > >> It is totally legacy. Please do not use it for this purpose at all.
> > >>
> > >
> > > Yes, I've seen the nice content. However, there is at least the
> > > *directory* that could be re-used.
> > >
> > > To have the one and only in the code section of SVN is better. For the
> > > website we can copy the best and most useful to this "branding/"
> > directory
> > > in ooo-site.
> > >
> > > Marcus
> > >
> > >
> > >
> > >
> > >  so, this proposal is not for the website? How do we want to handle the
> > >>> other one?
> > >>>
> > >>> Thanks
> > >>>
> > >>> Marcus
> > >>>
> > >>
> > >
> --**--**-
> > > To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> > dev-unsubscr...@openoffice.apache.org>
> > > For additional commands, e-mail: dev-h...@openoffice.apache.org
> > >
> > >
> > OK, I am ready to move on this. Setting up a directory for "source" of
> > branding elements -- svg -- and accessible only as svn repository. This
> > means no access via the web server except through maybe viewvc.
> >
> > Can someone tell me if setting up an area like:
> >
> > /openoffice/branding
> >
> >  is something we do or infra? I haven't tried anything and I'm not sure
> > about this.
> >
> you should be able to do that with normal committer karma and the help of
> "svn add"
>
> rgds
> jan I.
>

Ok, I added this new area, but nothing else yet -- everything else OK.

Do you think this needs "trunk"? Nothing under the "branches" has trunk but
we have this structure for "updates-site".  really I am confused about this
aspect.
Advice?


>
> >
> >
> >
> > --
> >
> >
> -
> > MzK
> >
> > Success is falling nine times and getting up ten."
> >  -- Jon Bon Jovi
> >
>



-- 
-
MzK

Success is falling nine times and getting up ten."
 -- Jon Bon Jovi


Re: Download page could give approximate file size

2013-08-05 Thread Marcus (OOo)

Am 08/05/2013 11:45 PM, schrieb sebb:

On 5 August 2013 22:23, Marcus (OOo)  wrote:

Am 08/05/2013 10:24 PM, schrieb sebb:


On 5 August 2013 20:38, Marcus (OOo)   wrote:


Am 08/05/2013 07:11 PM, schrieb sebb:


On 4 August 2013 19:45, Marcus (OOo)wrote:



Am 07/27/2013 10:14 PM, schrieb Marcus (OOo):


Am 07/27/2013 10:10 PM, schrieb sebb:




It might be helpful if the download page showed the approximate file
size downloads.

This would help users to know how long it might take (and do they
have
the space!) as well as offering an obvious sign if a download is
truncated by more than a few kB. Not perfect, but would have helped
the recent downloader.





Right, this would be much more helpful than having nothing.

I'll think about how to implement this into the current DL scripting.





I've created some new scripting and the result can be seen here:

http://ooo-site.staging.apache.org/download/test/index.html




That's good to have the size in the main download box.
However, given that the size is approximate, I'm not sure it's
necessary to provide it to two decimal places.
Either give the exact size, or round to the nearest MB.

The page shows me:

Windows (EXE) and English (British) (~129.89 MByte).

Once downloaded, the Windows XP property page shows:
129 MB (136,201,626 bytes)

So I think the download box should also show 129MB




OK, I've eliminated the decimal places.



Unhelpfully, the SF downloads page [1] shows 136.2MB - looks as though
they divided by 1000 rather than 1024 - though it's unlikely anyone
would/could use that page as the file names are all truncated.  I
don't know if it's possible to change the column sze for the name
column. Would be good if that could be corrected along with the size.




Please have a look into this issue:
https://issues.apache.org/ooo/show_bug.cgi?id=122233



[1]

http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/en-GB/

Also, the KEYS/sigs/hashes ought to be shown before the alternate
downloads, ideally within the main green box as they relate to the
main download




I've tried to realize that. But I think it's not possible as there is
only
one link possible as the whole pper green box has to be clickable: for
the
install file or for one of the signature/hash files.

The most important part is the install file. Everything else is
secondary.



In that case, put the KEYS etc. in a separate box immediately under
the clickable box.



I've rearranged the content of the sub-green box. Now the hash links are on
top.



The other downloads ought to be shown in a bit more detail in a separate
box




What do you mean with more details? What do you think is missing?



The links are very cramped, and there is no explanation of what they are
for.



Yes, that's right. A new format how these are presented to the users is
needed.



At present the page reads:

[LARGE GREEN DOWNLOAD BOX]
Get all platforms, languages, language packs | Source code and SDK |
Portable USB versions and third-party ports | Older and legacy
versions: 3.4.1 + 3.3.0 |
Signatures and hashes: KEYS , ASC , MD5 , SHA256 , How to verify? |
Release Notes

It should read something like:

[LARGE GREEN DOWNLOAD BOX]
Signatures and hashes: KEYS , ASC , MD5 , SHA256 , How to verify? |
Release Notes


Looking for other downloads?
* Builds of OpenOffice 4.0.0 for other platforms and languages
* Additional Language packs for your OpenOffice installation
* The source code and the SDK (Software Development Kit)
* Portable USB versions and third-party ports of OpenOffice
* Older and Legacy versions [should probably link to a separate page
that explains the difference between 3.4.1 and 3.3.0]



OK. Let's see how this can be solved. This will be a bigger task. I'll put
this into the Wiki for improvement.



==

The rest of the page is laid out with plenty of space between items.
At present the light green box looks out of place, and is tricky to



In general, because it's also green I don't think that it is out of place.
The connection to the normal green box - and therefore to the most current
release - should be obvious and not that it is something different. But ...


By "looks out of place" I meant that the styling/layout of the box
does not agree with the rest of the page.


Ah, understood. The green boxes are indeed the only colored boxes with 
two very similar meanings and two slightly different look & feel.


Marcus




read unless you know exactly what you are looking for (and you
understand the jargon).



... yes, that's right. A new format could be better.

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Updating BZ versions for next releases

2013-08-05 Thread Kay Schenk
On Mon, Aug 5, 2013 at 8:47 AM, janI  wrote:

> On 5 August 2013 17:38, Rob Weir  wrote:
>
> > I'd like to update BZ to reflect the next release of AOO.
> >
> > Version are tracked in three different fields:
> >
> > Version, which currently allows the values "AOO 4.0.0" and "AOO410-dev"
> >
> > Target Milestone, which currently allows the values "AOO 4.0", "AOO
> > 4.1" and "AOO PleaseHelp"
> >
> > Last Confirmation on, which currently allows the values "AOO 3.4.0",
> > "AOO 3.4.1", and "AOO 4.0.0".
> >
> > I'd like to clean this up a little, as follows:
> >
> > 1) It is reasonable for someone to report a bug using 3.4.0, 3.4.1 or
> > 4.0.0.  None of these versions are "end of life" so they should be
> > allowed for new bug reports.
> >
> > 2) I don't see the purpose of "AOO PleaseHelp" as a milestone version.
> >  Are we overloading meaning in this field?  If we really need track
> > issues that need help we should define a keyword for this.  So I'm
> > inclined to delete this milestone version number.
> >
> > 3) I'd also like to simplify the versions across the board to be just
> > "3.4.1", "4.0.0", etc., without the "AOO" prefix.
> >
> > 4) For Last Confirmation On, I'd like to hide values except for 4.0.
> > We should not be confirming bugs without testing on the most recent
> > version.  Sure, new bugs can set "Version" to 3.4.0 or 3.4.1, but
> > confirmation should occur on 4.0.
> >
> Since 3.4.0 and 3.4.1 (I actually thought it was only 3.4.1) are live
> version, which we support, all bugs reported there must also be tested
> there.
>
> I agree they should also be tested in 4.0, but not only in 4.0.
>
> So we would actually need a double confirmation, 3.4.x and 4.0 ?
>
>
> >
> > 5)  I'll add a new Target Milestone of "4.0.1" and Version of
> > "4.0.1-dev" since it is likely that we will have a 4.0.1 release to
> > address some of the defects that have been reported on 4.0.0.
> >
> > I'd love to hear your thoughts on this, even if it is just a quick +1.
> >  I'll hold off making any of these changes until this time Thursday.
> >
>
> +1 to all except 4).
>
> rgds
> jan I.
>

+1, same as Jan's comments



>
>
> >
> > Regards,
> >
> > -Rob
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
> >
>



-- 
-
MzK

Success is falling nine times and getting up ten."
 -- Jon Bon Jovi


Re: Proposal -- AOO 4.0.1 Release

2013-08-05 Thread Rob Weir
On Mon, Aug 5, 2013 at 5:34 PM, David Gerard  wrote:
> On 5 August 2013 22:32, janI  wrote:
>
>> When I consider what I hear in the "real" world, I would prefer a fast
>> release, solving the most important issues. We always have the possibility
>> to make a 4.02 if really needed.
>
>
> x.0.x releases monthly are the way to go. I think LibreOffice really
> got this right. If you do this, the users will be happier because they
> anticipate happiness in the *near* future, not a year from now.
>

I don't think LO has this figured out at all.  Saw this on Twitter
today, for example:

https://twitter.com/camerongray1515/status/364393046768484353/photo/1

The goal should be moving from stability to stability through a
disciplined process, not speed for its own sake.

Having large, "anything goes" releases are fine, provided we dedicate
enough time for testing.  And small, carefully controlled releases are
fine, since they don't require as much testing.  But frequent,
uncontrolled releases, without enough testing, I don't like what that
leads to.

Regards,

-Rob

>
> - d.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Proposal -- AOO 4.0.1 Release

2013-08-05 Thread Kay Schenk
On Mon, Aug 5, 2013 at 3:29 PM, Rob Weir  wrote:

> On Mon, Aug 5, 2013 at 5:34 PM, David Gerard  wrote:
> > On 5 August 2013 22:32, janI  wrote:
> >
> >> When I consider what I hear in the "real" world, I would prefer a fast
> >> release, solving the most important issues. We always have the
> possibility
> >> to make a 4.02 if really needed.
> >
> >
> > x.0.x releases monthly are the way to go. I think LibreOffice really
> > got this right. If you do this, the users will be happier because they
> > anticipate happiness in the *near* future, not a year from now.
> >
>
> I don't think LO has this figured out at all.  Saw this on Twitter
> today, for example:
>
> https://twitter.com/camerongray1515/status/364393046768484353/photo/1
>
> The goal should be moving from stability to stability through a
> disciplined process, not speed for its own sake.
>

+1 on this opinion...


>
> Having large, "anything goes" releases are fine, provided we dedicate
> enough time for testing.  And small, carefully controlled releases are
> fine, since they don't require as much testing.  But frequent,
> uncontrolled releases, without enough testing, I don't like what that
> leads to.
>
> Regards,
>
> -Rob
>
> >
> > - d.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
-
MzK

Success is falling nine times and getting up ten."
 -- Jon Bon Jovi


Build breaks in Curl

2013-08-05 Thread Regina Henschel

Hi,

I try to build current trunk r1510523 and get the error:

=
Building module curl
=

Entering /cygdrive/c/AOO_2013_08_05/trunk/main/curl

patching file curl-7.19.7/configure
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
3 out of 3 hunks ignored -- saving rejects to file curl-7.19.7/configure.rej
patching file curl-7.19.7/lib/setup.h
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file 
curl-7.19.7/lib/setup.h.rej

patching file curl-7.19.7/ltmain.sh
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file curl-7.19.7/ltmain.sh.rej
patching file curl-7.19.7/lib/ssh.c
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file curl-7.19.7/lib/ssh.c.rej
patching file curl-7.19.7/lib/Makefile.vc9
Hunk #1 FAILED at 46.
1 out of 1 hunk FAILED -- saving rejects to file 
curl-7.19.7/lib/Makefile.vc9.rej
dmake:  Error code 1, while making 
'./wntmsci12/misc/build/so_patched_so_curl'


1 module(s):
curl
need(s) to be rebuilt

My configure is
./configure \
 --with-directx-home="/cygdrive/c/Program Files/Microsoft DirectX SDK 
(June 2010)" \
 --with-cl-home="/cygdrive/c/Program Files/Microsoft Visual Studio 
9.0/VC" \

 --disable-build-mozilla \
 --disable-activex \
 --with-mozilla-build="/cygdrive/c/mozillabuild" \
 --enable-dbgutil \
 --with-asm-home="/cygdrive/c/Program Files/Microsoft Visual Studio 
9.0/VC/bin" \

 --with-jdk-home="/cygdrive/c/Program Files/Java/jdk1.6.0_38" \
 --with-ant-home=/ant \
 --with-mspdb-path="/cygdrive/c/Program Files/Microsoft Visual Studio 
9.0/Common7/IDE" \

 --without-junit \

--with-dmake-url="http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2"; 
\

 --without-fonts \
 --with-atl-include-dir="/cygdrive/c/WinDDK/7600.16385.1/inc/atl71" \
 --with-atl-lib-dir="/cygdrive/c/WinDDK/7600.16385.1/lib/ATL/i386" \
 --with-mfc-include-dir="/cygdrive/c/WinDDK/7600.16385.1/inc/mfc42" \
 --with-mfc-lib-dir="/cygdrive/c/WinDDK/7600.16385.1/lib/Mfc/i386" \
 --with-lang="de en kid" \
 --enable-category-b \
 --with-vendor="Regina_Henschel" \
 --with-build-version="r1510523_debug_category_b"

Kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



KeyID - UI Translation

2013-08-05 Thread Mechtilde
Hello,

is it possible to have a sonamed KeyID Build. I need it to improve the
menu shortcuts. It seems there is no automatism to do it right.

I mean th shortcuts with ALT and the underlined charakter not the
shortcuts with STRG.

Or do I miss something?

I want to clean it up for the next 4.0.1.

Kind reagrds

Mechtilde

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Proposal -- AOO 4.0.1 Release

2013-08-05 Thread O.Felka

Am 05.08.2013 23:34, schrieb David Gerard:

On 5 August 2013 22:32, janI  wrote:


When I consider what I hear in the "real" world, I would prefer a fast
release, solving the most important issues. We always have the possibility
to make a 4.02 if really needed.



x.0.x releases monthly are the way to go. I think LibreOffice really
got this right. If you do this, the users will be happier because they
anticipate happiness in the *near* future, not a year from now.



If we get quality we don't need quantity. We don't have to bother the 
user with monthly installations.
The majority of feedback I remember is: 'We don't want all these new 
features but we want it stable.'

Monthly updates are a pain in business areas.

Groetjes,
Olaf


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: KeyID - UI Translation

2013-08-05 Thread Alexandro Colorado
This should be asked on l...@apache.openoffice.org... I think there
were some talks about the KeyID buid some time ago.

On 8/6/13, Mechtilde  wrote:
> Hello,
>
> is it possible to have a sonamed KeyID Build. I need it to improve the
> menu shortcuts. It seems there is no automatism to do it right.
>
> I mean th shortcuts with ALT and the underlined charakter not the
> shortcuts with STRG.
>
> Or do I miss something?
>
> I want to clean it up for the next 4.0.1.
>
> Kind reagrds
>
> Mechtilde
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
Alexandro Colorado
Apache OpenOffice Contributor
http://www.openoffice.org

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org