date:20130815

On Thu, Aug 15, 2013 at 4:45 AM, sumit Murari  wrote:

> hello all, My name is timus, i've been using OpenOffice, and many OSS, now
> i want to contribute some to openOffice.
>
>
> I'm from India, and i'm interested in contributing to OpenOffice.
>  I've never contributed in any OSS so far, my contribution was limited to
> using software sending statistics and sending the crash report if i
> encountered any.
> Looking for anyone who can guide me ...
>
> Any help will be appreciated ..
>

Hello timus and it's great that you want to get involved with OpenOffice.
It would help if we had an idea of what areas you would like to help with.

Some of our major areas, aside from direct user support through the Forums
or "users" list, are discussed in the orientation modules:

http://openoffice.apache.org/orientation/index.html

So, if you can tell us a little more about what you'd like to do, we can
assist you with your OpenOffice volunteer efforts better.

-- 
-
MzK

"When in doubt, cop an attitude."
-- Cat laws

4.0.1_release_blocker requested: [Bug 118363] Copy From OOo Base Query Fails To Grab Full Selection

Kay  has asked  for 4.0.1_release_blocker:
Bug 118363: Copy From OOo Base Query Fails To Grab Full Selection
https://issues.apache.org/ooo/show_bug.cgi?id=118363


--- Additional Comments from Kay 
Confirmed this some time ago and confirmed. Hoping it can be resolved for 4.0.1

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

Re: [Website]

On Thu, Aug 15, 2013 at 1:15 PM, Marcus (OOo)  wrote:

> Am 08/15/2013 01:37 PM, schrieb Rob Weir:
>
>  On Wed, Aug 14, 2013 at 4:45 PM, Marcus (OOo)
>>  wrote:
>>
>>> Am 08/14/2013 10:32 PM, schrieb Marcus (OOo):
>>>
>>>  Am 08/14/2013 10:11 PM, schrieb Rob Weir:

>
> On Wed, Aug 14, 2013 at 3:37 PM, Marcus (OOo)
> wrote:
>
>>
>> Since a few weeks we get mails with just "[Website]" as subject.
>>
>> Just one word is not really meaningful to classify the mail content
>> on the
>> first view. So, I'm wondering from where they come from and how to
>> improve
>> this?
>>
>>
> These probably come from the contact page:
>
> http://www.openoffice.org/**contact_us.html
>


 ah, thanks.

  See: For problems with the www.openoffice.org website, please contact
> us via Development mailing list.
>
> That page covers contacts for reporting bugs, website and wiki
> problems, press, etc. But the very first link on the page is for
> support. I assume it requires an advanced degree in psychology to
> understand why someone would skip over that link and go to another.
>


 Yes, especially because the hint with the dev@ link is one of the last
 options. So, it doesn't make sense to exchange it with others in the
 section as this would just move the problem to the l10n@ or bz@ mailing
 list.

 OK, seems to be the last remaining 2.5% that never can be improved.

>>>
>>>
>>> Proposal:
>>>
>>> Exchange the predefined mail subject (e.g. "[Website]") with a more
>>> speaking
>>> wording like:
>>>
>>> "I want to report a problem with the OpenOffice website"
>>> "I want to report a problem with the OpenOffice BugZilla"
>>> "I want to report a problem with the OpenOffice Wiki"
>>> "I want to report a problem with the Pootle translation service"
>>>
>>> Maybe this will make it a bit more obvious for the user that her/his mail
>>> doesn't fit to the topic and could lead to think twice before hitting on
>>> [Send].
>>>
>>>
>> This might help.  It certainly would not hurt.
>>
>
> done, lets see what we will get now.
>
>
> Marcus
>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
I think this recent change will help. Maybe we need more?

On this same page, Contact Us, we have this wording in the first section--

If you need user support and don't want to file a bug...

Please navigate to the Support
Page
...


Should we change this to something more friendly, like ...

If you have a problem with OpenOffice...

Please use the Support Page...


-- 
-
MzK

"When in doubt, cop an attitude."
-- Cat laws

Re: erreur 126

2013-08-15 Thread Andrea Pescetti


Forwarding Rory's answers (below) to the original poster. Andrea.

Rory O'Farrell wrote:

On Thu, 15 Aug 2013 12:15:07 +0200 (CEST) Creyf
Daniel  wrote:


Bonjour. j'ai un probleme lorsque je veut imprimer un texte, j'ai
erreur 126 - can not load library - LXBBPRP.DLL?? puis lorsque je
clique plusieurs fois sur le message celui-ci se debloque et j'ai
accés a l'imprimante (Lexmark X74) que faire??


This problem is due to an improperly written Lexmark dll file
(sometimes also used in Dell printers).  The cure is simple

Solution

Locate the product-specific file lx??prp*.* in the directory
C:\WINDOWS\system32\spool\drivers\w32x86\3. Then copy it to
C:\WINDOWS\system32.

this is documented here
http://support.lexmark.com/index?page=content&locale=EN&productCode=&segment=SUPPORT&viewlocale=en_US&searchid=1302585306616&actp=search&userlocale=EN_US&id=SO5144

although in that thread it is reported for MS Outlook.


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

Re: Unnecesary filestructure on images

On Thu, Aug 15, 2013 at 2:24 PM, Andrea Pescetti wrote:

> On 14/08/2013 Alexandro Colorado wrote:
>
>> I created this page:
>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
>> File+handling+proposal+for+**logos+and+graphics
>>
>
> Seems reasonable as it is now. But I'm not scared that much about
> duplication.
>

I am not scared of duplication either, as a matter of fact I think
sometimes duplication is necessary. The problem is when the duplication is
unplanned, then it becomes a mess, and that's the problem.

For example, someone decided it was a great idea to put the OOo Cake on the
root folder, as opposed to images. Then someone instead of duplicated it
for the blog, decided to deep link it. So even now if the ooo cake image is
obsolete, we have a legacy dependency, so we cant move it nor delete it.
This pollute the web work being done.

Point in case is that there were a lot of bad choices made by the
webmasters and this clean up round will try to revert those design
decisions. 

>
> The "branding" area is meant to contain reference materials: an official
> vector version of the logo with a couple of pixel-perfect PNG exports (all
> with clearer names of course). It could also contain a reference square
> icon (with the orb), and maybe a reference favicon: anything that we use as
> branding source on official channels.
>
> Unapproved variations do not belong to "branding". And probably themed
> logos do not belong there too. So the official logo would be in branding
> but also in 
> http://www.openoffice.org/**images/; and a 
> themed logo would be in
> http://www.openoffice.org/**images/ only.
>
> Regards,
>   Andrea.
>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

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

Re: missing BZ for forum 4.0 signature.

2013-08-15 Thread Ricardo Berlasso

2013/8/15 janI 

> hi.
>
> I have solved the 4.0 signature problem in all forums, thanks to an
> excellent hint from terry.
>


Great! Many thanks!



>
> However I cannot find the BZ relating to signatures, is is just because I
> cannot see the wood for trees, or was it never filed ?
>


It seems it was never filled. At least, I cannot find it either. It was
commented on the forums and on the mailing list, but I cannot remember
anyone providing a bug report number.

Regards
Ricardo



>
> rgds
> jan I.
>

Re: [Website]

2013-08-15 Thread Marcus (OOo)


Am 08/15/2013 01:37 PM, schrieb Rob Weir:

On Wed, Aug 14, 2013 at 4:45 PM, Marcus (OOo)  wrote:

Am 08/14/2013 10:32 PM, schrieb Marcus (OOo):


Am 08/14/2013 10:11 PM, schrieb Rob Weir:


On Wed, Aug 14, 2013 at 3:37 PM, Marcus (OOo)
wrote:


Since a few weeks we get mails with just "[Website]" as subject.

Just one word is not really meaningful to classify the mail content
on the
first view. So, I'm wondering from where they come from and how to
improve
this?



These probably come from the contact page:

http://www.openoffice.org/contact_us.html



ah, thanks.


See: For problems with the www.openoffice.org website, please contact
us via Development mailing list.

That page covers contacts for reporting bugs, website and wiki
problems, press, etc. But the very first link on the page is for
support. I assume it requires an advanced degree in psychology to
understand why someone would skip over that link and go to another.



Yes, especially because the hint with the dev@ link is one of the last
options. So, it doesn't make sense to exchange it with others in the
section as this would just move the problem to the l10n@ or bz@ mailing
list.

OK, seems to be the last remaining 2.5% that never can be improved.



Proposal:

Exchange the predefined mail subject (e.g. "[Website]") with a more speaking
wording like:

"I want to report a problem with the OpenOffice website"
"I want to report a problem with the OpenOffice BugZilla"
"I want to report a problem with the OpenOffice Wiki"
"I want to report a problem with the Pootle translation service"

Maybe this will make it a bit more obvious for the user that her/his mail
doesn't fit to the topic and could lead to think twice before hitting on
[Send].



This might help.  It certainly would not hurt.


done, lets see what we will get now.

Marcus


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

Re: Changes needed for /main/solenv/inc/minor.mk in AOO401 branch and trunk

2013-08-15 Thread Marcus (OOo)


Am 08/15/2013 08:25 PM, schrieb Kay Schenk:

I think build number, etc needs updating for our current work in the AOO401
branch and trunk. I don't know how this information gets determined and
changed.


Just open a BZ issue and assign it to Juergen. I'm confident that he 
will take care to change all necessary data. And when committing it's 
also documented in the issue.



Using existing build/version information is problematic for parallel
installs (n multiple VMs) in Linux.


Marcus


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

Re: Unnecesary filestructure on images

On 8/15/13, Rob Weir  wrote:
> On Thu, Aug 15, 2013 at 3:24 PM, Andrea Pescetti 
> wrote:
>> On 14/08/2013 Alexandro Colorado wrote:
>>>
>>> I created this page:
>>>
>>> https://cwiki.apache.org/confluence/display/OOOUSERS/File+handling+proposal+for+logos+and+graphics
>>
>>
>> Seems reasonable as it is now. But I'm not scared that much about
>> duplication.
>>
>> The "branding" area is meant to contain reference materials: an official
>> vector version of the logo with a couple of pixel-perfect PNG exports

not really, for that reason "trademark" should hold another copy too.
Point is that it wasn't created for those porpouses, and I think the
whole community shun the active repo in art and marketing.

>> (all
>> with clearer names of course). It could also contain a reference square
>> icon
>> (with the orb), and maybe a reference favicon: anything that we use as
>> branding source on official channels.
>>
>> Unapproved variations do not belong to "branding". And probably themed
>> logos
>> do not belong there too. So the official logo would be in branding but
>> also
>> in http://www.openoffice.org/images/ ; and a themed logo would be in
>> http://www.openoffice.org/images/ only.
>>
>
> But where do the source files (SVG's) for the themed logos go?

It should have always gone to marketing/art/ either on the www-site or
on the wiki. www-site is fine to have SVG because it allow us to
modify slightly the artwork for webdev porpouses.


>
> -Rob
>
>
>> 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
>
>


-- 
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

Re: Poor user experience with update of extensions

There used to be a dictionary wizard that allow users to select and
use their locale. This was written by Lauren Godard and since the
extentions came through, the development was IMO droped after a drupal
site.

I did suggest to use Drupal REST/XMLRPC to make the calls to retrieve
the extentions of the contnent on a similar fashion to KDE's "Get Hot
new Stuff"
http://dot.kde.org/2005/03/13/kde-technologies-get-hot-new-stuff

There was a GSOC project by Tijana Milanovich that introduce a patch
to make go-OO/libreoffice use OpenClipart to intrgrate, patch is here:
http://cgit.freedesktop.org/libreoffice/build/commit/?id=f3a517b005a31607b373393600ac41237a55b1f4

The code includes a class that consume clipart webservice to read the
feed and retrieve the Openclipart metadata and image to install.
as you can see here:
++public:
++OnlineGalleryThemeEntry() {}
++~OnlineGalleryThemeEntry();
++OnlineGalleryThemeEntry(const rtl::OUString& keyword,
++bool bIsUserSearch = TRUE,
++INetURLObject aBaseURL =
INetURLObject("http://www.openclipart.org/media/feed/rss/";) );
++SgaObject* GetSgaObject( GalleryObject* pEntry);

The code of course is clipart centric, but OpenClipart as well as our
extensions uses Drupal on it's back end, so the feed would be the same
process, only the installation would be a more dedicated process than
import and registering new cliparts on the gallery.


On 8/15/13, Rob Weir  wrote:
> On Thu, Aug 15, 2013 at 6:00 AM, Jürgen Schmidt 
> wrote:
>> Hi,
>>
>> I clicked today on the available extensions update that bothers me since
>> some days ;-) And I clicked to install the update for the English
>> dictionary.
>>
>> I noticed a changed workflow compared to former days and I am redirected
>> now to the webpage where I can download the extension. I can understand
>> the reason behind this but I believe it is not the intended and wanted
>> workflow from a user perspective. I would very much prefer an invisible
>> download in the background and a direct installation as the button
>> "install" suggested.
>>
>> Any opinions on this?
>>
>
> Another opinion on this from a user on Facebook today:
>
> https://www.facebook.com/ApacheOO/posts/572230669502481
>
> -Rob
>
>
>> Juergen
>>
>> -
>> 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
>
>


-- 
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

Re: Unnecesary filestructure on images

On Thu, Aug 15, 2013 at 3:24 PM, Andrea Pescetti  wrote:
> On 14/08/2013 Alexandro Colorado wrote:
>>
>> I created this page:
>>
>> https://cwiki.apache.org/confluence/display/OOOUSERS/File+handling+proposal+for+logos+and+graphics
>
>
> Seems reasonable as it is now. But I'm not scared that much about
> duplication.
>
> The "branding" area is meant to contain reference materials: an official
> vector version of the logo with a couple of pixel-perfect PNG exports (all
> with clearer names of course). It could also contain a reference square icon
> (with the orb), and maybe a reference favicon: anything that we use as
> branding source on official channels.
>
> Unapproved variations do not belong to "branding". And probably themed logos
> do not belong there too. So the official logo would be in branding but also
> in http://www.openoffice.org/images/ ; and a themed logo would be in
> http://www.openoffice.org/images/ only.
>

But where do the source files (SVG's) for the themed logos go?

-Rob


> 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: Unnecesary filestructure on images

2013-08-15 Thread Andrea Pescetti


On 14/08/2013 Alexandro Colorado wrote:

I created this page:
https://cwiki.apache.org/confluence/display/OOOUSERS/File+handling+proposal+for+logos+and+graphics


Seems reasonable as it is now. But I'm not scared that much about 
duplication.


The "branding" area is meant to contain reference materials: an 
official vector version of the logo with a couple of pixel-perfect PNG 
exports (all with clearer names of course). It could also contain a 
reference square icon (with the orb), and maybe a reference favicon: 
anything that we use as branding source on official channels.


Unapproved variations do not belong to "branding". And probably themed 
logos do not belong there too. So the official logo would be in branding 
but also in http://www.openoffice.org/images/ ; and a themed logo would 
be in http://www.openoffice.org/images/ only.


Regards,
  Andrea.

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

Re: Poor user experience with update of extensions

On Thu, Aug 15, 2013 at 6:00 AM, Jürgen Schmidt  wrote:
> Hi,
>
> I clicked today on the available extensions update that bothers me since
> some days ;-) And I clicked to install the update for the English
> dictionary.
>
> I noticed a changed workflow compared to former days and I am redirected
> now to the webpage where I can download the extension. I can understand
> the reason behind this but I believe it is not the intended and wanted
> workflow from a user perspective. I would very much prefer an invisible
> download in the background and a direct installation as the button
> "install" suggested.
>
> Any opinions on this?
>

Another opinion on this from a user on Facebook today:

https://www.facebook.com/ApacheOO/posts/572230669502481

-Rob


> Juergen
>
> -
> 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: Poor user experience with update of extensions

2013-08-15 Thread Roberto Galoppini

2013/8/15 Andrea Pescetti 

> Oliver-Rainer Wittmann wrote:
>
>> On 15.08.2013 12:00, Jürgen Schmidt wrote:
>>
>>> I noticed a changed workflow compared to former days and I am redirected
>>> now to the webpage where I can download the extension.
>>>
>> The update of an extension should work like the update of the extension
>> "Watching Window" from 0.4.4 to 0.5.0. ...
>> For the English dictionary I need to download manually the new
>> extension. Then I need to install it manually.
>>
>
> The exception here is "Watching Window", that uses custom updates. The
> English dictionary behaves like virtually all other extensions. I give some
> more details for those who are unfamiliar with the extensions packaging.
>
> Whoever packaged the English dictionary back in 2010 made the (right)
> choice to leave to the Extensions site the responsibility to manage
> updates. "Watching Window", instead, specifies its own update feed, that
> lives on Github; but this is a more fragile setup; for example, I've seen
> countless mentions of this problem (for the OxygenOffice gallery extension,
> that specified its own update feed but then moved it...) over the years:
> http://forum.openoffice.org/**en/forum/viewtopic.php?f=6&t=**31360
>
> If you specify (and host) your own update feed, you can choose the update
> policy (direct or indirect download); if you don't, the Extensions site
> manages everything for you and you, as the extension maintainer, can't
> choose between direct and indirect download.
>
> So what is under discussion here is not whether the 2010 maintainer of the
> English dictionary made the right choice in relying on the generic update
> feed (he did; otherwise I wouldn't have been able to republish his
> extension and push updates), but is that the generic update feed on the
> Extensions site is configured to serve updates as indirect downloads and
> not as direct downloads.
>

The indirect download approach could be used to communicate with end-users
through the landing pages. May be this is something we might want to
explore to outreach our user base.

Roberto


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

Best practice for description.xml

2013-08-15 Thread Jörg Schmidt

Hello,

I have read:
http://wiki.openoffice.org/wiki/Documentation/DevGuide/Extensions/Localized_XML_Elements

but I'm not sure which is the better practice in a description.xml:

(a)

  http://de.openoffice.info";>Klaus Meyer


(in this case "de" is only an example)

(b)

  http://de.openoffice.info";>Klaus Meyer



If (a) or (b) better for an entry that will apply in all languages?



greetings,
Jörg


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

Re: Changes needed for /main/solenv/inc/minor.mk in AOO401 branch and trunk

On Thu, Aug 15, 2013 at 11:25 AM, Kay Schenk  wrote:

> I think build number, etc needs updating for our current work in the
> AOO401 branch and trunk. I don't know how this information gets determined
> and changed.
>
> Using existing build/version information is problematic for parallel
> installs (n multiple VMs) in Linux.
>

Sorry, this should have said:

(NO multiple VMs) in Linux


> Thanks.
>
> --
>
> -
> MzK
>
> "When in doubt, cop an attitude."
> -- Cat laws
>



-- 
-
MzK

"When in doubt, cop an attitude."
-- Cat laws

Changes needed for /main/solenv/inc/minor.mk in AOO401 branch and trunk

I think build number, etc needs updating for our current work in the AOO401
branch and trunk. I don't know how this information gets determined and
changed.

Using existing build/version information is problematic for parallel
installs (n multiple VMs) in Linux.

Thanks.

-- 
-
MzK

"When in doubt, cop an attitude."
-- Cat laws

Re: Poor user experience with update of extensions

2013-08-15 Thread Andrea Pescetti


Oliver-Rainer Wittmann wrote:

On 15.08.2013 12:00, Jürgen Schmidt wrote:

I noticed a changed workflow compared to former days and I am redirected
now to the webpage where I can download the extension.

The update of an extension should work like the update of the extension
"Watching Window" from 0.4.4 to 0.5.0. ...
For the English dictionary I need to download manually the new
extension. Then I need to install it manually.


The exception here is "Watching Window", that uses custom updates. The 
English dictionary behaves like virtually all other extensions. I give 
some more details for those who are unfamiliar with the extensions 
packaging.


Whoever packaged the English dictionary back in 2010 made the (right) 
choice to leave to the Extensions site the responsibility to manage 
updates. "Watching Window", instead, specifies its own update feed, that 
lives on Github; but this is a more fragile setup; for example, I've 
seen countless mentions of this problem (for the OxygenOffice gallery 
extension, that specified its own update feed but then moved it...) over 
the years: http://forum.openoffice.org/en/forum/viewtopic.php?f=6&t=31360


If you specify (and host) your own update feed, you can choose the 
update policy (direct or indirect download); if you don't, the 
Extensions site manages everything for you and you, as the extension 
maintainer, can't choose between direct and indirect download.


So what is under discussion here is not whether the 2010 maintainer of 
the English dictionary made the right choice in relying on the generic 
update feed (he did; otherwise I wouldn't have been able to republish 
his extension and push updates), but is that the generic update feed on 
the Extensions site is configured to serve updates as indirect downloads 
and not as direct downloads.


Regards,
  Andrea.

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

missing BZ for forum 4.0 signature.

hi.

I have solved the 4.0 signature problem in all forums, thanks to an
excellent hint from terry.

However I cannot find the BZ relating to signatures, is is just because I
cannot see the wood for trees, or was it never filed ?

rgds
jan I.

Re: need help

On Thu, Aug 15, 2013 at 12:09 PM, oilersd...@telus.net  wrote:
> do you have a 800 number i can call for help
>

We don't have any phone support.  You can find the community support
forums here:

http://forum.openoffice.org/

And other support options are described here:

http://www.openoffice.org/support/

Regards,

-Rob

>
> Murray hill
>
> -
> 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

need help

2013-08-15 Thread oilersd...@telus.net

do you have a 800 number i can call for help


Murray hill

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

Re: [WWW] Convention for images and logos

On Thu, Aug 15, 2013 at 7:57 AM, Rob Weir  wrote:

> On Thu, Aug 15, 2013 at 3:13 AM, Alexandro Colorado  wrote:
> > Dave has been updating the cWiki for conventions about the relationship
> > between some of the image files as well as address orphan sites on the
> > www-site root level.
> >
> > This clean up is important, however the core proposal is to have a more
> > uniform convention on the file name.
> >
>
> Is the cleanup important?   Is the idea that it will make maintenance
> easier?   This is certainly possible.  But it is also possible to
> break things in the short term.
>

> So I wonder:   Is there any easy way to test the entire website, all
> www.openoffice.org, for broken links?  It might be good to do this
> test now, before the cleanup, and then repeat again after the cleanup,
> so we can diff the two lists to see what broke.
>

There are all kinds of scripts to perform this tasks ssuch as linkchecker
and others. However the point is to introduce conventions, so the first
point is to agree on such.



>
> In fact, having a list of broken links in general would be good.
>
> -Rob
>
> > I wrote some proposed conventions, I would like to get some
> > approval/comment on these, or overhead agreement why this is/isn't
> > necessary.
> >
> >
> https://cwiki.apache.org/confluence/display/OOOUSERS/File+handling+proposal+for+logos+and+graphics#New+conventions
> >
> >
> >
> > --
> > 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
>
>


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

resume

2013-08-15 Thread oilersd...@telus.net

hi there i want to update my resume but i am having alot of trouble doing this, 
how do i do this with this program


Murray Hill

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

Re: [Website]

2013-08-15 Thread Ricardo Berlasso

2013/8/15 

> where’s the download link ?


Try here:

http://www.openoffice.org/download/

Re: Issue 122927 -- spreadsheet formula compatibility

On Thu, Aug 15, 2013 at 10:35 AM, sebb  wrote:
> On 15 August 2013 15:21, Rob Weir  wrote:
>> On Thu, Aug 15, 2013 at 10:07 AM, sebb  wrote:
>>> On 15 August 2013 14:47, Rob Weir  wrote:
 On Thu, Aug 15, 2013 at 9:41 AM, janI  wrote:
> On Aug 15, 2013 3:06 PM, "Rob Weir"  wrote:
>>
>> https://issues.apache.org/ooo/show_bug.cgi?id=122927
>>
>> It boils down to how an IF() statements are evaluated.
>>
>> Remember, the typical form is IF(Condition;X;Y) where you give a
>> return value for the case where Condition is TRUE and another value
>> when Condition is FALSE.
>>
>> But it is also possible to leave out the last parameter and have a
>> formula like this:
>>
>> IF(Condition;X)
>>
>> So what does the formula evaluate to if Condition is FALSE?
>>
>> The behavior in 4.0.0, returning FALSE, is correct according to the
>> ODF 1.2 specification and is the same as what Excel does.  However, it
>> is different than what earlier versions of OpenOffice did, namely
>> returning 0.0.
>>
>> We obviously cannot do both.  I think the AOO 4.0.0 behavior is
>> correct and should remain.
>
> I dont understand why we cannot do both, most programming languages
> interpret falase==0 and true==1, that allows the use of boolean functions
> in calculations.
>

 If the user takes the results of the IF() calculation and uses it in
 another formula, then FALSE is automatically treated as 0 in any other
 formula where a number is expected.  You are correct in your
 assumption there.   So no one gets a wrong answer in a calculation
 because of the change.

 What is different is what appears in the cell that actually has the
 IF() statement in it.  AOO 4.0 and Excel show FALSE.  Earlier versions
 of AOO showed 0.   In this sense we can have one default behavior or
 the other, but not both.
>>>
>>> Could you not add a setting that controls the behaviour?
>>>
>>> For a fresh install AOO 4.x will show FALSE.
>>> But if the user sets the appropriate backwards compatibilty option, it
>>> will show 0.
>>>
>>
>> In theory yes, but in practice users don't really think about this as
>> a per-installation setting.
>
> Maybe not, but if it was documented it could solve problems for some users.
> And it is a fairly simple solution.
>
>> They want their spreadsheet to look the
>> same as it was when it was created, even if it was created in a
>> different version of OpenOffice,
>
> That I can understand.
>
>> or in a different spreadsheet application altogether.
>
> In which case the default may be something else entirely - e.g.
> omitted trailing values are not allowed.
>
>> So a more targeted fix would be to trigger backwards compatibility
>> mode whenever you read a spreadsheet that was created in older
>> versions of AOO.
>
> In which case, there needs to be some way to change the behaviour in
> case the user wants to update to the new behaviour without recreating
> the spreadsheet.
>
>> Even better is to have a declarative approach where the behaviors are
>> encoded in the document itself as metadata.  This approach has been
>> discussed, but is not yet standardized.
>
> That would require older sheets to be updated, unless the default for
> missing metadata varied between versions.
>
> When context-sensitive solutions work, it's great.
> However when they fail to work, it's usually not at all obvious what
> the problem is - nor the solution.
>

Maybe it is clearer if you look at it from the perspective of a future
AOO 4.2. user who receives a spreadsheet from a AOO 4.1 user who
(hypothetically) has a version that allows the user to set the default
in their application, on how IF() behaves.  The 4.1 document could
have been saved in 3.4 mode, or in 4.0 (Excel compatible) mode.  So
how does the document appear to the 4.2 user?

1) Application per-install user settings are messy.  The 4.2 user has
no idea what the setting was for the 4.1 user.

2) Logic that tries to render the appearance of a specific version of
AOO fails.  It might have worked in the 3.4 to 4.1 transition, since
3.4 had only a single behavior.  But it breaks in the 4.1 to 4.2
transition since 4.1 would (hypothetically) allow two behaviors.

3) So the only thing that works is to store the setting used in the
document itself.  This won't fix the past, of course.  3.4 to 4.0 is
still messy.  But it makes the future a little cleaner.

Now you could imagine a per-install setting that gives the defaults to
apply to new documents as they are created.  But this starts
increasing complexity quite quickly.   But if done right you could
imagine several "compatibility" modes, including one for reading Excel
documents, as well as when reading older AOO documents.

-Rob

>> -Rob
>>
 -Rob

> rgds
> jan i
>>
>> I'd like to close the issue as NOTABUG.  But I'd like to get a few
>> more thoughts on

Re: Issue 122927 -- spreadsheet formula compatibility

2013-08-15 Thread sebb

On 15 August 2013 15:21, Rob Weir  wrote:
> On Thu, Aug 15, 2013 at 10:07 AM, sebb  wrote:
>> On 15 August 2013 14:47, Rob Weir  wrote:
>>> On Thu, Aug 15, 2013 at 9:41 AM, janI  wrote:
 On Aug 15, 2013 3:06 PM, "Rob Weir"  wrote:
>
> https://issues.apache.org/ooo/show_bug.cgi?id=122927
>
> It boils down to how an IF() statements are evaluated.
>
> Remember, the typical form is IF(Condition;X;Y) where you give a
> return value for the case where Condition is TRUE and another value
> when Condition is FALSE.
>
> But it is also possible to leave out the last parameter and have a
> formula like this:
>
> IF(Condition;X)
>
> So what does the formula evaluate to if Condition is FALSE?
>
> The behavior in 4.0.0, returning FALSE, is correct according to the
> ODF 1.2 specification and is the same as what Excel does.  However, it
> is different than what earlier versions of OpenOffice did, namely
> returning 0.0.
>
> We obviously cannot do both.  I think the AOO 4.0.0 behavior is
> correct and should remain.

 I dont understand why we cannot do both, most programming languages
 interpret falase==0 and true==1, that allows the use of boolean functions
 in calculations.

>>>
>>> If the user takes the results of the IF() calculation and uses it in
>>> another formula, then FALSE is automatically treated as 0 in any other
>>> formula where a number is expected.  You are correct in your
>>> assumption there.   So no one gets a wrong answer in a calculation
>>> because of the change.
>>>
>>> What is different is what appears in the cell that actually has the
>>> IF() statement in it.  AOO 4.0 and Excel show FALSE.  Earlier versions
>>> of AOO showed 0.   In this sense we can have one default behavior or
>>> the other, but not both.
>>
>> Could you not add a setting that controls the behaviour?
>>
>> For a fresh install AOO 4.x will show FALSE.
>> But if the user sets the appropriate backwards compatibilty option, it
>> will show 0.
>>
>
> In theory yes, but in practice users don't really think about this as
> a per-installation setting.

Maybe not, but if it was documented it could solve problems for some users.
And it is a fairly simple solution.

> They want their spreadsheet to look the
> same as it was when it was created, even if it was created in a
> different version of OpenOffice,

That I can understand.

> or in a different spreadsheet application altogether.

In which case the default may be something else entirely - e.g.
omitted trailing values are not allowed.

> So a more targeted fix would be to trigger backwards compatibility
> mode whenever you read a spreadsheet that was created in older
> versions of AOO.

In which case, there needs to be some way to change the behaviour in
case the user wants to update to the new behaviour without recreating
the spreadsheet.

> Even better is to have a declarative approach where the behaviors are
> encoded in the document itself as metadata.  This approach has been
> discussed, but is not yet standardized.

That would require older sheets to be updated, unless the default for
missing metadata varied between versions.

When context-sensitive solutions work, it's great.
However when they fail to work, it's usually not at all obvious what
the problem is - nor the solution.

> -Rob
>
>>> -Rob
>>>
>>>
 rgds
 jan i
>
> I'd like to close the issue as NOTABUG.  But I'd like to get a few
> more thoughts on this first.
>
> 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
>>>
>>
>> -
>> 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: Issue 122927 -- spreadsheet formula compatibility

On Thu, Aug 15, 2013 at 10:07 AM, sebb  wrote:
> On 15 August 2013 14:47, Rob Weir  wrote:
>> On Thu, Aug 15, 2013 at 9:41 AM, janI  wrote:
>>> On Aug 15, 2013 3:06 PM, "Rob Weir"  wrote:

 https://issues.apache.org/ooo/show_bug.cgi?id=122927

 It boils down to how an IF() statements are evaluated.

 Remember, the typical form is IF(Condition;X;Y) where you give a
 return value for the case where Condition is TRUE and another value
 when Condition is FALSE.

 But it is also possible to leave out the last parameter and have a
 formula like this:

 IF(Condition;X)

 So what does the formula evaluate to if Condition is FALSE?

 The behavior in 4.0.0, returning FALSE, is correct according to the
 ODF 1.2 specification and is the same as what Excel does.  However, it
 is different than what earlier versions of OpenOffice did, namely
 returning 0.0.

 We obviously cannot do both.  I think the AOO 4.0.0 behavior is
 correct and should remain.
>>>
>>> I dont understand why we cannot do both, most programming languages
>>> interpret falase==0 and true==1, that allows the use of boolean functions
>>> in calculations.
>>>
>>
>> If the user takes the results of the IF() calculation and uses it in
>> another formula, then FALSE is automatically treated as 0 in any other
>> formula where a number is expected.  You are correct in your
>> assumption there.   So no one gets a wrong answer in a calculation
>> because of the change.
>>
>> What is different is what appears in the cell that actually has the
>> IF() statement in it.  AOO 4.0 and Excel show FALSE.  Earlier versions
>> of AOO showed 0.   In this sense we can have one default behavior or
>> the other, but not both.
>
> Could you not add a setting that controls the behaviour?
>
> For a fresh install AOO 4.x will show FALSE.
> But if the user sets the appropriate backwards compatibilty option, it
> will show 0.
>

In theory yes, but in practice users don't really think about this as
a per-installation setting.  They want their spreadsheet to look the
same as it was when it was created, even if it was created in a
different version of OpenOffice, or in a different spreadsheet
application altogether.

So a more targeted fix would be to trigger backwards compatibility
mode whenever you read a spreadsheet that was created in older
versions of AOO.

Even better is to have a declarative approach where the behaviors are
encoded in the document itself as metadata.  This approach has been
discussed, but is not yet standardized.

-Rob

>> -Rob
>>
>>
>>> rgds
>>> jan i

 I'd like to close the issue as NOTABUG.  But I'd like to get a few
 more thoughts on this first.

 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
>>
>
> -
> 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-15 Thread jchavins

where’s the download link ?

Re: Issue 122927 -- spreadsheet formula compatibility

2013-08-15 Thread sebb

On 15 August 2013 14:47, Rob Weir  wrote:
> On Thu, Aug 15, 2013 at 9:41 AM, janI  wrote:
>> On Aug 15, 2013 3:06 PM, "Rob Weir"  wrote:
>>>
>>> https://issues.apache.org/ooo/show_bug.cgi?id=122927
>>>
>>> It boils down to how an IF() statements are evaluated.
>>>
>>> Remember, the typical form is IF(Condition;X;Y) where you give a
>>> return value for the case where Condition is TRUE and another value
>>> when Condition is FALSE.
>>>
>>> But it is also possible to leave out the last parameter and have a
>>> formula like this:
>>>
>>> IF(Condition;X)
>>>
>>> So what does the formula evaluate to if Condition is FALSE?
>>>
>>> The behavior in 4.0.0, returning FALSE, is correct according to the
>>> ODF 1.2 specification and is the same as what Excel does.  However, it
>>> is different than what earlier versions of OpenOffice did, namely
>>> returning 0.0.
>>>
>>> We obviously cannot do both.  I think the AOO 4.0.0 behavior is
>>> correct and should remain.
>>
>> I dont understand why we cannot do both, most programming languages
>> interpret falase==0 and true==1, that allows the use of boolean functions
>> in calculations.
>>
>
> If the user takes the results of the IF() calculation and uses it in
> another formula, then FALSE is automatically treated as 0 in any other
> formula where a number is expected.  You are correct in your
> assumption there.   So no one gets a wrong answer in a calculation
> because of the change.
>
> What is different is what appears in the cell that actually has the
> IF() statement in it.  AOO 4.0 and Excel show FALSE.  Earlier versions
> of AOO showed 0.   In this sense we can have one default behavior or
> the other, but not both.

Could you not add a setting that controls the behaviour?

For a fresh install AOO 4.x will show FALSE.
But if the user sets the appropriate backwards compatibilty option, it
will show 0.

> -Rob
>
>
>> rgds
>> jan i
>>>
>>> I'd like to close the issue as NOTABUG.  But I'd like to get a few
>>> more thoughts on this first.
>>>
>>> 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
>

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

Re: Issue 122927 -- spreadsheet formula compatibility

On Thu, Aug 15, 2013 at 9:47 AM, Rob Weir  wrote:
> On Thu, Aug 15, 2013 at 9:41 AM, janI  wrote:
>> On Aug 15, 2013 3:06 PM, "Rob Weir"  wrote:
>>>
>>> https://issues.apache.org/ooo/show_bug.cgi?id=122927
>>>
>>> It boils down to how an IF() statements are evaluated.
>>>
>>> Remember, the typical form is IF(Condition;X;Y) where you give a
>>> return value for the case where Condition is TRUE and another value
>>> when Condition is FALSE.
>>>
>>> But it is also possible to leave out the last parameter and have a
>>> formula like this:
>>>
>>> IF(Condition;X)
>>>
>>> So what does the formula evaluate to if Condition is FALSE?
>>>
>>> The behavior in 4.0.0, returning FALSE, is correct according to the
>>> ODF 1.2 specification and is the same as what Excel does.  However, it
>>> is different than what earlier versions of OpenOffice did, namely
>>> returning 0.0.
>>>
>>> We obviously cannot do both.  I think the AOO 4.0.0 behavior is
>>> correct and should remain.
>>
>> I dont understand why we cannot do both, most programming languages
>> interpret falase==0 and true==1, that allows the use of boolean functions
>> in calculations.
>>
>
> If the user takes the results of the IF() calculation and uses it in
> another formula, then FALSE is automatically treated as 0 in any other
> formula where a number is expected.  You are correct in your
> assumption there.   So no one gets a wrong answer in a calculation
> because of the change.
>
> What is different is what appears in the cell that actually has the
> IF() statement in it.  AOO 4.0 and Excel show FALSE.  Earlier versions
> of AOO showed 0.   In this sense we can have one default behavior or
> the other, but not both.
>

I should mention one other subtlety.  Cells have values, types and
formats.  Types are really numeric and string.  Things like currency,
date and boolean are just formats.  You can type in a number like
123456 and format it as a number, a date, a boolean, etc.

The tricky part is that some formulas automatically set a format,
without requiring user intervention.  So if I type =TODAY() into a a
cell I see "08/15/13" instead of "41501".  The spreadsheet is smart
enough to know that with that formula the cell should be formatted as
date.  Pretty cool, yes?

Similar thing occurs with booleans.  Type FALSE() into a cell.  It
automatically is formatted as a boolean, not a number.

So with the IF(Condition;TrueValue) case, the ODF spec says that
FALSE() is returned if Condition is false.  So that is essentially why
the user sees FALSE in the end.  The spreadsheet determines the
appropriate format based on the return value being boolean.

There are ways for the user to override this.  For example, if they
use the full form, IF(Condition;TrueValue;FalseValue) then they can
simply set FalseValue to be equal to 0.  That will ensure that they
get the numeric return value.

Or, they can wrap the IF() to force the outcome to be numeric, e.g.,
=N(IF(Condition;TrueValue)).  The N() function will explicitly convert
the boolean return value into a number.

Regards,

-Rob

> -Rob
>
>
>> rgds
>> jan i
>>>
>>> I'd like to close the issue as NOTABUG.  But I'd like to get a few
>>> more thoughts on this first.
>>>
>>> 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

Re: Issue 122927 -- spreadsheet formula compatibility

On Thu, Aug 15, 2013 at 9:41 AM, janI  wrote:
> On Aug 15, 2013 3:06 PM, "Rob Weir"  wrote:
>>
>> https://issues.apache.org/ooo/show_bug.cgi?id=122927
>>
>> It boils down to how an IF() statements are evaluated.
>>
>> Remember, the typical form is IF(Condition;X;Y) where you give a
>> return value for the case where Condition is TRUE and another value
>> when Condition is FALSE.
>>
>> But it is also possible to leave out the last parameter and have a
>> formula like this:
>>
>> IF(Condition;X)
>>
>> So what does the formula evaluate to if Condition is FALSE?
>>
>> The behavior in 4.0.0, returning FALSE, is correct according to the
>> ODF 1.2 specification and is the same as what Excel does.  However, it
>> is different than what earlier versions of OpenOffice did, namely
>> returning 0.0.
>>
>> We obviously cannot do both.  I think the AOO 4.0.0 behavior is
>> correct and should remain.
>
> I dont understand why we cannot do both, most programming languages
> interpret falase==0 and true==1, that allows the use of boolean functions
> in calculations.
>

If the user takes the results of the IF() calculation and uses it in
another formula, then FALSE is automatically treated as 0 in any other
formula where a number is expected.  You are correct in your
assumption there.   So no one gets a wrong answer in a calculation
because of the change.

What is different is what appears in the cell that actually has the
IF() statement in it.  AOO 4.0 and Excel show FALSE.  Earlier versions
of AOO showed 0.   In this sense we can have one default behavior or
the other, but not both.

-Rob


> rgds
> jan i
>>
>> I'd like to close the issue as NOTABUG.  But I'd like to get a few
>> more thoughts on this first.
>>
>> 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

Re: Issue 122927 -- spreadsheet formula compatibility

On Aug 15, 2013 3:06 PM, "Rob Weir"  wrote:
>
> https://issues.apache.org/ooo/show_bug.cgi?id=122927
>
> It boils down to how an IF() statements are evaluated.
>
> Remember, the typical form is IF(Condition;X;Y) where you give a
> return value for the case where Condition is TRUE and another value
> when Condition is FALSE.
>
> But it is also possible to leave out the last parameter and have a
> formula like this:
>
> IF(Condition;X)
>
> So what does the formula evaluate to if Condition is FALSE?
>
> The behavior in 4.0.0, returning FALSE, is correct according to the
> ODF 1.2 specification and is the same as what Excel does.  However, it
> is different than what earlier versions of OpenOffice did, namely
> returning 0.0.
>
> We obviously cannot do both.  I think the AOO 4.0.0 behavior is
> correct and should remain.

I dont understand why we cannot do both, most programming languages
interpret falase==0 and true==1, that allows the use of boolean functions
in calculations.

rgds
jan i
>
> I'd like to close the issue as NOTABUG.  But I'd like to get a few
> more thoughts on this first.
>
> Regards,
>
> -Rob
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

Re: Issue 122927 -- spreadsheet formula compatibility

On 8/15/13 3:06 PM, Rob Weir wrote:
> https://issues.apache.org/ooo/show_bug.cgi?id=122927
> 
> It boils down to how an IF() statements are evaluated.
> 
> Remember, the typical form is IF(Condition;X;Y) where you give a
> return value for the case where Condition is TRUE and another value
> when Condition is FALSE.
> 
> But it is also possible to leave out the last parameter and have a
> formula like this:
> 
> IF(Condition;X)
> 
> So what does the formula evaluate to if Condition is FALSE?
> 
> The behavior in 4.0.0, returning FALSE, is correct according to the
> ODF 1.2 specification and is the same as what Excel does.  However, it
> is different than what earlier versions of OpenOffice did, namely
> returning 0.0.
> 
> We obviously cannot do both.  I think the AOO 4.0.0 behavior is
> correct and should remain.
> 
> I'd like to close the issue as NOTABUG.  But I'd like to get a few
> more thoughts on this first.

I tend to agree because the current behaviour is correct according the
specification and behaves as Excel which increase the interoperability
as well.

We should explain it and why we keep the change, the affected users
won't be happy but hopefully understand that long term the change is
better for all the current and future users ...

Juergen

> 
> 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

Issue 122927 -- spreadsheet formula compatibility

https://issues.apache.org/ooo/show_bug.cgi?id=122927

It boils down to how an IF() statements are evaluated.

Remember, the typical form is IF(Condition;X;Y) where you give a
return value for the case where Condition is TRUE and another value
when Condition is FALSE.

But it is also possible to leave out the last parameter and have a
formula like this:

IF(Condition;X)

So what does the formula evaluate to if Condition is FALSE?

The behavior in 4.0.0, returning FALSE, is correct according to the
ODF 1.2 specification and is the same as what Excel does.  However, it
is different than what earlier versions of OpenOffice did, namely
returning 0.0.

We obviously cannot do both.  I think the AOO 4.0.0 behavior is
correct and should remain.

I'd like to close the issue as NOTABUG.  But I'd like to get a few
more thoughts on this first.

Regards,

-Rob

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

Re: Help with forms....so impossible to get with with openoffice!!!!

2013-08-15 Thread Fernand Vanrie


 Dominic ,

the trick is to use the form "explorer" to add a extra subform to a form
open first the forms toolbar

hi

  


I need help with openoffice base.  i created a form with a subform using the 
wizard.  i need more than one subform and dont know how to add additional 
subforms.  i tried researching on the web but nothing helps.  can you help me 
insert more subforms into a form.  thanks

  


kind regards,

  
  		 	   		



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

Re: [WWW] Convention for images and logos

On Thu, Aug 15, 2013 at 3:13 AM, Alexandro Colorado  wrote:
> Dave has been updating the cWiki for conventions about the relationship
> between some of the image files as well as address orphan sites on the
> www-site root level.
>
> This clean up is important, however the core proposal is to have a more
> uniform convention on the file name.
>

Is the cleanup important?   Is the idea that it will make maintenance
easier?   This is certainly possible.  But it is also possible to
break things in the short term.

So I wonder:   Is there any easy way to test the entire website, all
www.openoffice.org, for broken links?  It might be good to do this
test now, before the cleanup, and then repeat again after the cleanup,
so we can diff the two lists to see what broke.

In fact, having a list of broken links in general would be good.

-Rob

> I wrote some proposed conventions, I would like to get some
> approval/comment on these, or overhead agreement why this is/isn't
> necessary.
>
> https://cwiki.apache.org/confluence/display/OOOUSERS/File+handling+proposal+for+logos+and+graphics#New+conventions
>
>
>
> --
> 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

Re: Some thoughts on quality

On Thu, Aug 15, 2013 at 8:29 AM, Jürgen Schmidt  wrote:
> On 8/15/13 1:33 PM, Rob Weir wrote:
>> On Thu, Aug 15, 2013 at 6:58 AM, Jürgen Schmidt  
>> wrote:
>>> On 8/15/13 12:19 PM, janI wrote:
 On Aug 15, 2013 11:14 AM, "Jürgen Schmidt"  wrote:
>
> On 8/14/13 8:30 PM, Rob Weir wrote:
>> On Wed, Aug 14, 2013 at 1:55 PM, janI  wrote:
>>> On 14 August 2013 19:36, Edwin Sharp  wrote:
>>>
 Dear Rob
 The 4.0 release was too ambitious - we should advance in smaller
 steps.
 Nothing compares to general public testing - betas and release
 candidates
 should not be avoided.
 TestLink cases should be less comprehesive (in terms of feature
 coverage)
 and more stress testing oriented.
 Regards,
 Edwin

 On Wed, Aug 14, 2013, at 19:59, Rob Weir wrote:
> We're working now on AOO 4.0.1, to fix defects in AOO 4.0.0.  The
 fact
> that we're doing this, and their are no arguments against it, shows
> that we value quality.   I'd like to take this a step further, and
 see
> what we can learn from the defects in AOO 4.0.0 and what we can do
> going forward to improve.
>
> Quality, in the end, is a process, not a state of grace.  We improve
> by working smarter, not working harder.  The goal should be to learn
> and improve, as individuals and as a community.
>
> Every regression that made it into 4.0.0 was added there by a
> programmer.  And the defect went undetected by testers.  This is not
> to blame.  It just means that we're all human.  We know that.  We all
> make mistakes.  I make mistakes.  A quality process is not about
> becoming perfect, but about acknowledging that we make mistakes and
> that certain formal and informal practices are needed to prevent and
> detect these mistakes.
>
> But enough about generalities.  I'm hoping you'll join with me in
> examining the 32 confirmed 4.0.0 regression defects and answering a
> few questions:
>
> 1) What caused the bug?   What was the "root cause"?  Note:
> "programmer error" is not really a cause.  We should ask what caused
> the error.
>
> 2) What can we do to prevent bugs like this from being checked in?
>
> 3) Why wasn't the bug found during testing?  Was it not covered by
 any
> existing test case?  Was a test case run but the defect was not
> recognized?  Was the defect introduced into the software after the
> tests had already been executed?
>
> 4) What can we do to ensure that bugs like this are caught during
 testing?
>
> So 2 basic questions -- what went wrong and how can we prevent it in
> the future, looked at from perspective of programmers and testers.
  If
> we can keep these questions in mind, and try to answer them, we may
 be
> able to find some patterns that can lead to some process changes for
> AOO 4.1.
>
> You can find the 4.0.0 regressions in Bugzilla here:
>
>

 https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=400_regressions&sharer_id=248521&list_id=80834
>
>
> Regards,
>
> -Rob

>>>
>>> I strongly believe that one of the things that went wrong is our
 limited
>>> possibility to retest (due to resources), when I look at our current
 manual
>>
>> I wonder about that as well.  That's one reason it would be good to
>> know how many of the confirmed regressions were introduced late in the
>> release process, and thus missed coverage in our full test pass.
>>
>>> testcases, a lot of those could be automated, e.g. with a simple UI
 macro,
>>> that would enable us to run these test cases with every build. It may
 sound
>>> like a dream but where I come from, we did that every night, and it
 caught
>>> a lot of regression bugs and sideeffects.
>>>
>>
>> This begs the question:  Is the functionality of the regressions
>> covered by our test cases?  Or are they covered but we didn't execute
>> them?  Or we executed them but didn't recognize the defect?  I don't
>> know (yet).
>>
>>> A simple start, if to request that every bug fix, is issued with at
 least
>>> one test case (automated or manual).
>>>
>>
>> Often there is, though this information lives in Bugzilla.  One thing
>> we did on another (non open source) project is to mark defects in our
>> bugtracking system that should become test cases.   Not every bug did
>> that.  For example, a defect report to update a mispelling in the UI
>> would not lead to a new test case.  But many would.
>
>

Forum, last call, less than 24 hours to operation "rejuvenate".

Hi.

Sorry for starting a new thread, but I wanted to make sure to catch the
attention, and since you read this I succeeded  :-)

This is just a last warning mail, to be sure, nobody feel "run over",

In less than 24 hours, I will take all forums down for the weekend, and do
a lot of updating as described earlier.

I have not received any objections to the earlier thread regarding the
upgrades/enhancements/changes I proposed to do, which (I asked for lazy
consensus) means I will just go ahead and do it.

Forums might be temporary active during the weekend (e.g. for testing), but
I cannot guarantee that any changes made will be kept.

I have not received any html suggestion (as asked for) for "we are down for
maintenance", so the url will simply not respond, which is anyhow the case
for the bigger part of the time.

have a nice weekend, and hope you all will see a faster and better forum
monday.

rgds
jan I

New volunteer introduction

2013-08-15 Thread sumit Murari

hello all, My name is timus, i've been using OpenOffice, and many OSS, now
i want to contribute some to openOffice.


I'm from India, and i'm interested in contributing to OpenOffice.
 I've never contributed in any OSS so far, my contribution was limited to
using software sending statistics and sending the crash report if i
encountered any.
Looking for anyone who can guide me ...

Any help will be appreciated ..

Re: [Website]

On Wed, Aug 14, 2013 at 4:45 PM, Marcus (OOo)  wrote:
> Am 08/14/2013 10:32 PM, schrieb Marcus (OOo):
>
>> Am 08/14/2013 10:11 PM, schrieb Rob Weir:
>>>
>>> On Wed, Aug 14, 2013 at 3:37 PM, Marcus (OOo)
>>> wrote:

 Since a few weeks we get mails with just "[Website]" as subject.

 Just one word is not really meaningful to classify the mail content
 on the
 first view. So, I'm wondering from where they come from and how to
 improve
 this?

>>>
>>> These probably come from the contact page:
>>>
>>> http://www.openoffice.org/contact_us.html
>>
>>
>> ah, thanks.
>>
>>> See: For problems with the www.openoffice.org website, please contact
>>> us via Development mailing list.
>>>
>>> That page covers contacts for reporting bugs, website and wiki
>>> problems, press, etc. But the very first link on the page is for
>>> support. I assume it requires an advanced degree in psychology to
>>> understand why someone would skip over that link and go to another.
>>
>>
>> Yes, especially because the hint with the dev@ link is one of the last
>> options. So, it doesn't make sense to exchange it with others in the
>> section as this would just move the problem to the l10n@ or bz@ mailing
>> list.
>>
>> OK, seems to be the last remaining 2.5% that never can be improved.
>
>
> Proposal:
>
> Exchange the predefined mail subject (e.g. "[Website]") with a more speaking
> wording like:
>
> "I want to report a problem with the OpenOffice website"
> "I want to report a problem with the OpenOffice BugZilla"
> "I want to report a problem with the OpenOffice Wiki"
> "I want to report a problem with the Pootle translation service"
>
> Maybe this will make it a bit more obvious for the user that her/his mail
> doesn't fit to the topic and could lead to think twice before hitting on
> [Send].
>

This might help.  It certainly would not hurt.

-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: Some thoughts on quality

On Thu, Aug 15, 2013 at 4:08 AM, Oliver-Rainer Wittmann
 wrote:
> Hi,
>
>
> On 14.08.2013 18:59, Rob Weir wrote:
>>
>> We're working now on AOO 4.0.1, to fix defects in AOO 4.0.0.  The fact
>> that we're doing this, and their are no arguments against it, shows
>> that we value quality.   I'd like to take this a step further, and see
>> what we can learn from the defects in AOO 4.0.0 and what we can do
>> going forward to improve.
>>
>> Quality, in the end, is a process, not a state of grace.  We improve
>> by working smarter, not working harder.  The goal should be to learn
>> and improve, as individuals and as a community.
>>
>> Every regression that made it into 4.0.0 was added there by a
>> programmer.  And the defect went undetected by testers.  This is not
>> to blame.  It just means that we're all human.  We know that.  We all
>> make mistakes.  I make mistakes.  A quality process is not about
>> becoming perfect, but about acknowledging that we make mistakes and
>> that certain formal and informal practices are needed to prevent and
>> detect these mistakes.
>>
>> But enough about generalities.  I'm hoping you'll join with me in
>> examining the 32 confirmed 4.0.0 regression defects and answering a
>> few questions:
>>
>> 1) What caused the bug?   What was the "root cause"?  Note:
>> "programmer error" is not really a cause.  We should ask what caused
>> the error.
>>
>> 2) What can we do to prevent bugs like this from being checked in?
>>
>> 3) Why wasn't the bug found during testing?  Was it not covered by any
>> existing test case?  Was a test case run but the defect was not
>> recognized?  Was the defect introduced into the software after the
>> tests had already been executed?
>>
>> 4) What can we do to ensure that bugs like this are caught during testing?
>>
>> So 2 basic questions -- what went wrong and how can we prevent it in
>> the future, looked at from perspective of programmers and testers.  If
>> we can keep these questions in mind, and try to answer them, we may be
>> able to find some patterns that can lead to some process changes for
>> AOO 4.1.
>>
>> You can find the 4.0.0 regressions in Bugzilla here:
>>
>>
>> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=400_regressions&sharer_id=248521&list_id=80834
>>
>
> Please include also issue with status ACCEPTED.
>

Done.  That now gives us 36.

-Rob


> Best regards, Oliver.
>
>>
>> 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
>

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

Re: Some thoughts on quality

On Thu, Aug 15, 2013 at 6:58 AM, Jürgen Schmidt  wrote:
> On 8/15/13 12:19 PM, janI wrote:
>> On Aug 15, 2013 11:14 AM, "Jürgen Schmidt"  wrote:
>>>
>>> On 8/14/13 8:30 PM, Rob Weir wrote:
 On Wed, Aug 14, 2013 at 1:55 PM, janI  wrote:
> On 14 August 2013 19:36, Edwin Sharp  wrote:
>
>> Dear Rob
>> The 4.0 release was too ambitious - we should advance in smaller
>> steps.
>> Nothing compares to general public testing - betas and release
>> candidates
>> should not be avoided.
>> TestLink cases should be less comprehesive (in terms of feature
>> coverage)
>> and more stress testing oriented.
>> Regards,
>> Edwin
>>
>> On Wed, Aug 14, 2013, at 19:59, Rob Weir wrote:
>>> We're working now on AOO 4.0.1, to fix defects in AOO 4.0.0.  The
>> fact
>>> that we're doing this, and their are no arguments against it, shows
>>> that we value quality.   I'd like to take this a step further, and
>> see
>>> what we can learn from the defects in AOO 4.0.0 and what we can do
>>> going forward to improve.
>>>
>>> Quality, in the end, is a process, not a state of grace.  We improve
>>> by working smarter, not working harder.  The goal should be to learn
>>> and improve, as individuals and as a community.
>>>
>>> Every regression that made it into 4.0.0 was added there by a
>>> programmer.  And the defect went undetected by testers.  This is not
>>> to blame.  It just means that we're all human.  We know that.  We all
>>> make mistakes.  I make mistakes.  A quality process is not about
>>> becoming perfect, but about acknowledging that we make mistakes and
>>> that certain formal and informal practices are needed to prevent and
>>> detect these mistakes.
>>>
>>> But enough about generalities.  I'm hoping you'll join with me in
>>> examining the 32 confirmed 4.0.0 regression defects and answering a
>>> few questions:
>>>
>>> 1) What caused the bug?   What was the "root cause"?  Note:
>>> "programmer error" is not really a cause.  We should ask what caused
>>> the error.
>>>
>>> 2) What can we do to prevent bugs like this from being checked in?
>>>
>>> 3) Why wasn't the bug found during testing?  Was it not covered by
>> any
>>> existing test case?  Was a test case run but the defect was not
>>> recognized?  Was the defect introduced into the software after the
>>> tests had already been executed?
>>>
>>> 4) What can we do to ensure that bugs like this are caught during
>> testing?
>>>
>>> So 2 basic questions -- what went wrong and how can we prevent it in
>>> the future, looked at from perspective of programmers and testers.
>>  If
>>> we can keep these questions in mind, and try to answer them, we may
>> be
>>> able to find some patterns that can lead to some process changes for
>>> AOO 4.1.
>>>
>>> You can find the 4.0.0 regressions in Bugzilla here:
>>>
>>>
>>
>> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=400_regressions&sharer_id=248521&list_id=80834
>>>
>>>
>>> Regards,
>>>
>>> -Rob
>>
>
> I strongly believe that one of the things that went wrong is our
>> limited
> possibility to retest (due to resources), when I look at our current
>> manual

 I wonder about that as well.  That's one reason it would be good to
 know how many of the confirmed regressions were introduced late in the
 release process, and thus missed coverage in our full test pass.

> testcases, a lot of those could be automated, e.g. with a simple UI
>> macro,
> that would enable us to run these test cases with every build. It may
>> sound
> like a dream but where I come from, we did that every night, and it
>> caught
> a lot of regression bugs and sideeffects.
>

 This begs the question:  Is the functionality of the regressions
 covered by our test cases?  Or are they covered but we didn't execute
 them?  Or we executed them but didn't recognize the defect?  I don't
 know (yet).

> A simple start, if to request that every bug fix, is issued with at
>> least
> one test case (automated or manual).
>

 Often there is, though this information lives in Bugzilla.  One thing
 we did on another (non open source) project is to mark defects in our
 bugtracking system that should become test cases.   Not every bug did
 that.  For example, a defect report to update a mispelling in the UI
 would not lead to a new test case.  But many would.
>>>
>>> we have the automated test framework that needs some more attention and
>>> polishing. And of course the tests have to improved to get satisfying
>>> result.
>>>
>>> We have
>>>
>>> BVT - build verification test
>>> FVT - functional verification test
>>> PVT - performance verification test
>>> SVT - system verification tes

Re: Some thoughts on quality

On Thu, Aug 15, 2013 at 2:59 AM, Edwin Sharp  wrote:
>
>
> On Wed, Aug 14, 2013, at 22:58, Rob Weir wrote:
>>
>> Finally, I think we can all point to a similar open source project
>> that has numerous betas, but still suffers from poor quality.  So a
>> public beta, by itself, is not sufficient.  We need some upstream
>> improvements as well, I think.  But we should do a beta as well.  But
>> aim to have the highest quality beta we can, right?
>>
>> Regards,
>>
>> -Rob
>
> This comparison is not fair because the release frequency of the two projects 
> is totally different.
>

To the original question you had suggested more frequent releases.
Raphael and Hagar suggested beta releases.  So it is entirely relevant
to point out that a sister project that had adopted both of those
practices has not achieved any great quality improvements.

When you think of it, why should release pacing have any impact on
quality?  Quality is increased if you prevent bugs, detect them before
you release, or fix them before you release.  Anything that claims to
improve quality should have a direct impact on one of those three
actions.  Does a release prevent bugs?  Detect them?  Fix them?  No,
not really.

What a release can do is prompt increase QA attention as the release
approaches.  But this is an indirect and not obligatory practice.  We
could have frequent releases that are tested less, because of the less
time available for testing.  This would lead to lower quality.  Or we
could have multiple full test passes with a longer release, taking
better advantage of the time, and leading to higher quality.

So the thing that matters here is the testing time, testing coverage,
testing efficiency, etc.  The release pace has no direct effect on
quality.

> Quality can also be improved by better community culture. No offense, but I 
> found this inappropriate:
>

Culture is important, yes, to the extent it leads to the adoption of
quality practices.  One good cultural point would be a community that
is not offended by facts and fact-based reasoning.

Regards,

-Rob

> On Fri, Jun 7, 2013, at 3:33, Rob Weir wrote:
>>
>> I'll try to clean up a few tonight while I watch TV.
>>
>
>
>
>
> -
> 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: Some thoughts on quality

On 8/15/13 12:19 PM, janI wrote:
> On Aug 15, 2013 11:14 AM, "Jürgen Schmidt"  wrote:
>>
>> On 8/14/13 8:30 PM, Rob Weir wrote:
>>> On Wed, Aug 14, 2013 at 1:55 PM, janI  wrote:
 On 14 August 2013 19:36, Edwin Sharp  wrote:

> Dear Rob
> The 4.0 release was too ambitious - we should advance in smaller
> steps.
> Nothing compares to general public testing - betas and release
> candidates
> should not be avoided.
> TestLink cases should be less comprehesive (in terms of feature
> coverage)
> and more stress testing oriented.
> Regards,
> Edwin
>
> On Wed, Aug 14, 2013, at 19:59, Rob Weir wrote:
>> We're working now on AOO 4.0.1, to fix defects in AOO 4.0.0.  The
> fact
>> that we're doing this, and their are no arguments against it, shows
>> that we value quality.   I'd like to take this a step further, and
> see
>> what we can learn from the defects in AOO 4.0.0 and what we can do
>> going forward to improve.
>>
>> Quality, in the end, is a process, not a state of grace.  We improve
>> by working smarter, not working harder.  The goal should be to learn
>> and improve, as individuals and as a community.
>>
>> Every regression that made it into 4.0.0 was added there by a
>> programmer.  And the defect went undetected by testers.  This is not
>> to blame.  It just means that we're all human.  We know that.  We all
>> make mistakes.  I make mistakes.  A quality process is not about
>> becoming perfect, but about acknowledging that we make mistakes and
>> that certain formal and informal practices are needed to prevent and
>> detect these mistakes.
>>
>> But enough about generalities.  I'm hoping you'll join with me in
>> examining the 32 confirmed 4.0.0 regression defects and answering a
>> few questions:
>>
>> 1) What caused the bug?   What was the "root cause"?  Note:
>> "programmer error" is not really a cause.  We should ask what caused
>> the error.
>>
>> 2) What can we do to prevent bugs like this from being checked in?
>>
>> 3) Why wasn't the bug found during testing?  Was it not covered by
> any
>> existing test case?  Was a test case run but the defect was not
>> recognized?  Was the defect introduced into the software after the
>> tests had already been executed?
>>
>> 4) What can we do to ensure that bugs like this are caught during
> testing?
>>
>> So 2 basic questions -- what went wrong and how can we prevent it in
>> the future, looked at from perspective of programmers and testers.
>  If
>> we can keep these questions in mind, and try to answer them, we may
> be
>> able to find some patterns that can lead to some process changes for
>> AOO 4.1.
>>
>> You can find the 4.0.0 regressions in Bugzilla here:
>>
>>
>
> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=400_regressions&sharer_id=248521&list_id=80834
>>
>>
>> Regards,
>>
>> -Rob
>

 I strongly believe that one of the things that went wrong is our
> limited
 possibility to retest (due to resources), when I look at our current
> manual
>>>
>>> I wonder about that as well.  That's one reason it would be good to
>>> know how many of the confirmed regressions were introduced late in the
>>> release process, and thus missed coverage in our full test pass.
>>>
 testcases, a lot of those could be automated, e.g. with a simple UI
> macro,
 that would enable us to run these test cases with every build. It may
> sound
 like a dream but where I come from, we did that every night, and it
> caught
 a lot of regression bugs and sideeffects.

>>>
>>> This begs the question:  Is the functionality of the regressions
>>> covered by our test cases?  Or are they covered but we didn't execute
>>> them?  Or we executed them but didn't recognize the defect?  I don't
>>> know (yet).
>>>
 A simple start, if to request that every bug fix, is issued with at
> least
 one test case (automated or manual).

>>>
>>> Often there is, though this information lives in Bugzilla.  One thing
>>> we did on another (non open source) project is to mark defects in our
>>> bugtracking system that should become test cases.   Not every bug did
>>> that.  For example, a defect report to update a mispelling in the UI
>>> would not lead to a new test case.  But many would.
>>
>> we have the automated test framework that needs some more attention and
>> polishing. And of course the tests have to improved to get satisfying
>> result.
>>
>> We have
>>
>> BVT - build verification test
>> FVT - functional verification test
>> PVT - performance verification test
>> SVT - system verification test
>>
>> But I have to confess that I have limited knowledge about it yet
> 
> I aware that we ha a limited automated framework, at least thats what I
> found and played with.
> 
>

Re: erreur 126

2013-08-15 Thread Rory O'Farrell

On Thu, 15 Aug 2013 12:15:07 +0200 (CEST)
Creyf Daniel  wrote:

> Bonjour. j'ai un probleme lorsque je veut imprimer un texte, j'ai erreur 126 
> - can not load library - LXBBPRP.DLL?? puis lorsque je clique plusieurs fois 
> sur le message celui-ci se debloque et j'ai accés a l'imprimante (Lexmark 
> X74) que faire??

This problem is due to an improperly written Lexmark dll file (sometimes also 
used in Dell printers).  The cure is simple

Solution

Locate the product-specific file lx??prp*.* in the directory 
C:\WINDOWS\system32\spool\drivers\w32x86\3.
Then copy it to C:\WINDOWS\system32.

this is documented here
http://support.lexmark.com/index?page=content&locale=EN&productCode=&segment=SUPPORT&viewlocale=en_US&searchid=1302585306616&actp=search&userlocale=EN_US&id=SO5144
although in that thread it is reported for MS Outlook.
-- 
Rory O'Farrell 

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

Re: Some thoughts on quality

On Aug 15, 2013 11:14 AM, "Jürgen Schmidt"  wrote:
>
> On 8/14/13 8:30 PM, Rob Weir wrote:
> > On Wed, Aug 14, 2013 at 1:55 PM, janI  wrote:
> >> On 14 August 2013 19:36, Edwin Sharp  wrote:
> >>
> >>> Dear Rob
> >>> The 4.0 release was too ambitious - we should advance in smaller
steps.
> >>> Nothing compares to general public testing - betas and release
candidates
> >>> should not be avoided.
> >>> TestLink cases should be less comprehesive (in terms of feature
coverage)
> >>> and more stress testing oriented.
> >>> Regards,
> >>> Edwin
> >>>
> >>> On Wed, Aug 14, 2013, at 19:59, Rob Weir wrote:
>  We're working now on AOO 4.0.1, to fix defects in AOO 4.0.0.  The
fact
>  that we're doing this, and their are no arguments against it, shows
>  that we value quality.   I'd like to take this a step further, and
see
>  what we can learn from the defects in AOO 4.0.0 and what we can do
>  going forward to improve.
> 
>  Quality, in the end, is a process, not a state of grace.  We improve
>  by working smarter, not working harder.  The goal should be to learn
>  and improve, as individuals and as a community.
> 
>  Every regression that made it into 4.0.0 was added there by a
>  programmer.  And the defect went undetected by testers.  This is not
>  to blame.  It just means that we're all human.  We know that.  We all
>  make mistakes.  I make mistakes.  A quality process is not about
>  becoming perfect, but about acknowledging that we make mistakes and
>  that certain formal and informal practices are needed to prevent and
>  detect these mistakes.
> 
>  But enough about generalities.  I'm hoping you'll join with me in
>  examining the 32 confirmed 4.0.0 regression defects and answering a
>  few questions:
> 
>  1) What caused the bug?   What was the "root cause"?  Note:
>  "programmer error" is not really a cause.  We should ask what caused
>  the error.
> 
>  2) What can we do to prevent bugs like this from being checked in?
> 
>  3) Why wasn't the bug found during testing?  Was it not covered by
any
>  existing test case?  Was a test case run but the defect was not
>  recognized?  Was the defect introduced into the software after the
>  tests had already been executed?
> 
>  4) What can we do to ensure that bugs like this are caught during
> >>> testing?
> 
>  So 2 basic questions -- what went wrong and how can we prevent it in
>  the future, looked at from perspective of programmers and testers.
 If
>  we can keep these questions in mind, and try to answer them, we may
be
>  able to find some patterns that can lead to some process changes for
>  AOO 4.1.
> 
>  You can find the 4.0.0 regressions in Bugzilla here:
> 
> 
> >>>
https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=400_regressions&sharer_id=248521&list_id=80834
> 
> 
>  Regards,
> 
>  -Rob
> >>>
> >>
> >> I strongly believe that one of the things that went wrong is our
limited
> >> possibility to retest (due to resources), when I look at our current
manual
> >
> > I wonder about that as well.  That's one reason it would be good to
> > know how many of the confirmed regressions were introduced late in the
> > release process, and thus missed coverage in our full test pass.
> >
> >> testcases, a lot of those could be automated, e.g. with a simple UI
macro,
> >> that would enable us to run these test cases with every build. It may
sound
> >> like a dream but where I come from, we did that every night, and it
caught
> >> a lot of regression bugs and sideeffects.
> >>
> >
> > This begs the question:  Is the functionality of the regressions
> > covered by our test cases?  Or are they covered but we didn't execute
> > them?  Or we executed them but didn't recognize the defect?  I don't
> > know (yet).
> >
> >> A simple start, if to request that every bug fix, is issued with at
least
> >> one test case (automated or manual).
> >>
> >
> > Often there is, though this information lives in Bugzilla.  One thing
> > we did on another (non open source) project is to mark defects in our
> > bugtracking system that should become test cases.   Not every bug did
> > that.  For example, a defect report to update a mispelling in the UI
> > would not lead to a new test case.  But many would.
>
> we have the automated test framework that needs some more attention and
> polishing. And of course the tests have to improved to get satisfying
> result.
>
> We have
>
> BVT - build verification test
> FVT - functional verification test
> PVT - performance verification test
> SVT - system verification test
>
> But I have to confess that I have limited knowledge about it yet

I aware that we ha a limited automated framework, at least thats what I
found and played with.

but, it is not integrated into our build, or our buildbot. Especially
testing in buildbot

erreur 126

2013-08-15 Thread Creyf Daniel

Bonjour. j'ai un probleme lorsque je veut imprimer un texte, j'ai erreur 126 - 
can not load library - LXBBPRP.DLL?? puis lorsque je clique plusieurs fois sur 
le message celui-ci se debloque et j'ai accés a l'imprimante (Lexmark X74) que 
faire??

Re: Poor user experience with update of extensions


Hi,

On 15.08.2013 12:00, Jürgen Schmidt wrote:

Hi,

I clicked today on the available extensions update that bothers me since
some days ;-) And I clicked to install the update for the English
dictionary.

I noticed a changed workflow compared to former days and I am redirected
now to the webpage where I can download the extension. I can understand
the reason behind this but I believe it is not the intended and wanted
workflow from a user perspective. I would very much prefer an invisible
download in the background and a direct installation as the button
"install" suggested.

Any opinions on this?



I agree.

The update of an extension should work like the update of the extension 
"Watching Window" from 0.4.4 to 0.5.0. When updating this extension I 
got the window telling me that the new extension version is downloaded 
and then installed without error.

--> expected user experience.

For the English dictionary I need to download manually the new 
extension. Then I need to install it manually. During its installation I 
need to confirm that I want to replace its former version.

--> really unexpected user experience.

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

Poor user experience with update of extensions

Hi,

I clicked today on the available extensions update that bothers me since
some days ;-) And I clicked to install the update for the English
dictionary.

I noticed a changed workflow compared to former days and I am redirected
now to the webpage where I can download the extension. I can understand
the reason behind this but I believe it is not the intended and wanted
workflow from a user perspective. I would very much prefer an invisible
download in the background and a direct installation as the button
"install" suggested.

Any opinions on this?

Juergen

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

Re: svn commit: r1514218 - /openoffice/trunk/main/basegfx/source/polygon/b2dpolypolygoncutter.cxx


Hi,

On 15.08.2013 11:24, pavelja...@apache.org wrote:

Author: paveljanik
Date: Thu Aug 15 09:24:25 2013
New Revision: 1514218

URL: http://svn.apache.org/r1514218
Log:
WaE: Initialize boolean variable to false to prevent compiler warning about 
uninitialized variable.



kudos to Pavel to find this defect.


Thx and best regards, Oliver.


Modified:
 openoffice/trunk/main/basegfx/source/polygon/b2dpolypolygoncutter.cxx

Modified: openoffice/trunk/main/basegfx/source/polygon/b2dpolypolygoncutter.cxx
URL: 
http://svn.apache.org/viewvc/openoffice/trunk/main/basegfx/source/polygon/b2dpolypolygoncutter.cxx?rev=1514218&r1=1514217&r2=1514218&view=diff
==
--- openoffice/trunk/main/basegfx/source/polygon/b2dpolypolygoncutter.cxx 
(original)
+++ openoffice/trunk/main/basegfx/source/polygon/b2dpolypolygoncutter.cxx Thu 
Aug 15 09:24:25 2013
@@ -690,7 +690,7 @@ namespace basegfx
  {
  basegfx::B2DPolygon aTemp(aRetval.getB2DPolygon(a));
  const sal_uInt32 nPointCount(aTemp.count());
-bool bChanged;
+bool bChanged(false);

  for(sal_uInt32 b(0); b < nPointCount; b++)
  {




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

Re: [BUILD] Linux32 snapshot configure


Hi Regina,

On 15.08.2013 11:26, Regina Henschel wrote:

Hi Oliver,

Oliver-Rainer Wittmann schrieb:

Hi,

On 15.08.2013 10:10, Regina Henschel wrote:

Hi Oliver,

Oliver-Rainer Wittmann schrieb:

Hi,

Herbert, Andre and myself had a closer look on the error log of the
recent Linux 32bit build bot build (#456) and at the corresponding
code.
It seems that there is a programming error in method
.

I am working on it.


Please tell me, what is the problem there. I wrote it.



What Herbert, Andre and myself have figured out is the following:
Error message from Linux 32bit build bot says:
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/svgreader/svgsvgnode.cxx:

In member function 'virtual const basegfx::B2DRange*
svgio::svgreader::SvgSvgNode::getCurrentViewPort() const':
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/svgreader/svgsvgnode.cxx:636:71:

error: taking address of temporary [-fpermissive]
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/svgreader/svgsvgnode.cxx:679:75:

error: taking address of temporary [-fpermissive]
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/svgreader/svgsvgnode.cxx:698:67:

error: taking address of temporary [-fpermissive]
make: ***
[/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/solver/400/unxlngi6.pro/workdir/CxxObject/svgio/source/svgreader/svgsvgnode.o]

Error 1

The corresponding code line are:
- 636: return &basegfx::B2DRange(fX, fY, fX+fW, fY+fH);
- 679: return &basegfx::B2DRange(fX, fY, fX+fW, fY+fH);
- 698: return &basegfx::B2DRange(0.0, 0.0, fW, fH);
Thus, a pointer to a temporary created object is returned here and the
return type of this method is . The life time of
such an object ends when the method ends. Thus, accessing the returned
pointer outside the method means accessing 'dead' memory.


Sorry, MS compiler not even gave a warning. I'm not experienced and
still struggling with C++. Therefore I had ask for review. Sadly it
slipped through. If you knew a solution, I would be happy.

I suggest, you replace the method getCurrentViewport with the previous
version of it. The crash has happened in method decomposeSvgNode and the
solution there is independent of method getCurrentViewport.

In content the method getCurrentViewport has to return 4 double values,
which are calculated inside the method. Changing it that way, would
result in a change in signature with deep impact on the whole class. I
think, a solutions needs to be discussed with Armin. But as far as I
know, Armin is now in vacation.



Please have a look at the corresponding issue 122600 and its mail thread 
- I have attached a solution.


Best regards, Oliver.

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

Re: review requested: [Bug 122600] [SVG] problems in SvgSvgNode : [Attachment 81333] patch to solve build breaker on Linux 32bit build bot


Hi Regina,

I have a attached a patch.
Could you please apply it to your local environment and check it?

Thanks in advance,
Oliver.

On 15.08.2013 11:26, bugzi...@apache.org wrote:

Oliver-Rainer Wittmann  has asked  for review:
Bug 122600: [SVG] problems in SvgSvgNode
https://issues.apache.org/ooo/show_bug.cgi?id=122600

Attachment 81333: patch to solve build breaker on Linux 32bit build bot
https://issues.apache.org/ooo/attachment.cgi?id=81333&action=edit


--- Additional Comments from Oliver-Rainer Wittmann 
adjustment to correct compile error on Linux 32bit build bot.

the compile error is:
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/s
vgreader/svgsvgnode.cxx: In member function 'virtual const basegfx::B2DRange*
svgio::svgreader::SvgSvgNode::getCurrentViewPort() const':
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/s
vgreader/svgsvgnode.cxx:636:71: error: taking address of temporary
[-fpermissive]
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/s
vgreader/svgsvgnode.cxx:679:75: error: taking address of temporary
[-fpermissive]
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/s
vgreader/svgsvgnode.cxx:698:67: error: taking address of temporary
[-fpermissive]
make: ***
[/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/solver/400/un
xlngi6.pro/workdir/CxxObject/svgio/source/svgreader/svgsvgnode.o] Error 1

-
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] Linux32 snapshot configure

2013-08-15 Thread Regina Henschel


Hi Oliver,

Oliver-Rainer Wittmann schrieb:

Hi,

On 15.08.2013 10:10, Regina Henschel wrote:

Hi Oliver,

Oliver-Rainer Wittmann schrieb:

Hi,

Herbert, Andre and myself had a closer look on the error log of the
recent Linux 32bit build bot build (#456) and at the corresponding code.
It seems that there is a programming error in method
.

I am working on it.


Please tell me, what is the problem there. I wrote it.



What Herbert, Andre and myself have figured out is the following:
Error message from Linux 32bit build bot says:
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/svgreader/svgsvgnode.cxx:
In member function 'virtual const basegfx::B2DRange*
svgio::svgreader::SvgSvgNode::getCurrentViewPort() const':
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/svgreader/svgsvgnode.cxx:636:71:
error: taking address of temporary [-fpermissive]
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/svgreader/svgsvgnode.cxx:679:75:
error: taking address of temporary [-fpermissive]
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/svgreader/svgsvgnode.cxx:698:67:
error: taking address of temporary [-fpermissive]
make: ***
[/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/solver/400/unxlngi6.pro/workdir/CxxObject/svgio/source/svgreader/svgsvgnode.o]
Error 1

The corresponding code line are:
- 636: return &basegfx::B2DRange(fX, fY, fX+fW, fY+fH);
- 679: return &basegfx::B2DRange(fX, fY, fX+fW, fY+fH);
- 698: return &basegfx::B2DRange(0.0, 0.0, fW, fH);
Thus, a pointer to a temporary created object is returned here and the
return type of this method is . The life time of
such an object ends when the method ends. Thus, accessing the returned
pointer outside the method means accessing 'dead' memory.


Sorry, MS compiler not even gave a warning. I'm not experienced and 
still struggling with C++. Therefore I had ask for review. Sadly it 
slipped through. If you knew a solution, I would be happy.


I suggest, you replace the method getCurrentViewport with the previous 
version of it. The crash has happened in method decomposeSvgNode and the 
solution there is independent of method getCurrentViewport.


In content the method getCurrentViewport has to return 4 double values, 
which are calculated inside the method. Changing it that way, would 
result in a change in signature with deep impact on the whole class. I 
think, a solutions needs to be discussed with Armin. But as far as I 
know, Armin is now in vacation.


Kind regards
Regina

-
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 81333] patch to solve build breaker on Linux 32bit build bot

Oliver-Rainer Wittmann  has asked  for review:
Bug 122600: [SVG] problems in SvgSvgNode
https://issues.apache.org/ooo/show_bug.cgi?id=122600

Attachment 81333: patch to solve build breaker on Linux 32bit build bot
https://issues.apache.org/ooo/attachment.cgi?id=81333&action=edit


--- Additional Comments from Oliver-Rainer Wittmann 
adjustment to correct compile error on Linux 32bit build bot.

the compile error is:
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/s
vgreader/svgsvgnode.cxx: In member function 'virtual const basegfx::B2DRange*
svgio::svgreader::SvgSvgNode::getCurrentViewPort() const':
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/s
vgreader/svgsvgnode.cxx:636:71: error: taking address of temporary
[-fpermissive]
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/s
vgreader/svgsvgnode.cxx:679:75: error: taking address of temporary
[-fpermissive]
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/s
vgreader/svgsvgnode.cxx:698:67: error: taking address of temporary
[-fpermissive]
make: ***
[/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/solver/400/un
xlngi6.pro/workdir/CxxObject/svgio/source/svgreader/svgsvgnode.o] Error 1

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

4.0.1_release_blocker granted: [Bug 122822] Correct viewing of XY-, Column- and Line-Charts limited to 10000 records + 1 Heading row

j...@apache.org has granted h...@apache.org 's request for
4.0.1_release_blocker:
Bug 122822: Correct viewing of XY-, Column- and Line-Charts limited to 1
records + 1 Heading row
https://issues.apache.org/ooo/show_bug.cgi?id=122822


--- Additional Comments from j...@apache.org
approve showstopper request

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

Re: Some thoughts on quality

On 8/14/13 8:30 PM, Rob Weir wrote:
> On Wed, Aug 14, 2013 at 1:55 PM, janI  wrote:
>> On 14 August 2013 19:36, Edwin Sharp  wrote:
>>
>>> Dear Rob
>>> The 4.0 release was too ambitious - we should advance in smaller steps.
>>> Nothing compares to general public testing - betas and release candidates
>>> should not be avoided.
>>> TestLink cases should be less comprehesive (in terms of feature coverage)
>>> and more stress testing oriented.
>>> Regards,
>>> Edwin
>>>
>>> On Wed, Aug 14, 2013, at 19:59, Rob Weir wrote:
 We're working now on AOO 4.0.1, to fix defects in AOO 4.0.0.  The fact
 that we're doing this, and their are no arguments against it, shows
 that we value quality.   I'd like to take this a step further, and see
 what we can learn from the defects in AOO 4.0.0 and what we can do
 going forward to improve.

 Quality, in the end, is a process, not a state of grace.  We improve
 by working smarter, not working harder.  The goal should be to learn
 and improve, as individuals and as a community.

 Every regression that made it into 4.0.0 was added there by a
 programmer.  And the defect went undetected by testers.  This is not
 to blame.  It just means that we're all human.  We know that.  We all
 make mistakes.  I make mistakes.  A quality process is not about
 becoming perfect, but about acknowledging that we make mistakes and
 that certain formal and informal practices are needed to prevent and
 detect these mistakes.

 But enough about generalities.  I'm hoping you'll join with me in
 examining the 32 confirmed 4.0.0 regression defects and answering a
 few questions:

 1) What caused the bug?   What was the "root cause"?  Note:
 "programmer error" is not really a cause.  We should ask what caused
 the error.

 2) What can we do to prevent bugs like this from being checked in?

 3) Why wasn't the bug found during testing?  Was it not covered by any
 existing test case?  Was a test case run but the defect was not
 recognized?  Was the defect introduced into the software after the
 tests had already been executed?

 4) What can we do to ensure that bugs like this are caught during
>>> testing?

 So 2 basic questions -- what went wrong and how can we prevent it in
 the future, looked at from perspective of programmers and testers.  If
 we can keep these questions in mind, and try to answer them, we may be
 able to find some patterns that can lead to some process changes for
 AOO 4.1.

 You can find the 4.0.0 regressions in Bugzilla here:

>>> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=400_regressions&sharer_id=248521&list_id=80834

 Regards,

 -Rob
>>>
>>
>> I strongly believe that one of the things that went wrong is our limited
>> possibility to retest (due to resources), when I look at our current manual
> 
> I wonder about that as well.  That's one reason it would be good to
> know how many of the confirmed regressions were introduced late in the
> release process, and thus missed coverage in our full test pass.
> 
>> testcases, a lot of those could be automated, e.g. with a simple UI macro,
>> that would enable us to run these test cases with every build. It may sound
>> like a dream but where I come from, we did that every night, and it caught
>> a lot of regression bugs and sideeffects.
>>
> 
> This begs the question:  Is the functionality of the regressions
> covered by our test cases?  Or are they covered but we didn't execute
> them?  Or we executed them but didn't recognize the defect?  I don't
> know (yet).
> 
>> A simple start, if to request that every bug fix, is issued with at least
>> one test case (automated or manual).
>>
> 
> Often there is, though this information lives in Bugzilla.  One thing
> we did on another (non open source) project is to mark defects in our
> bugtracking system that should become test cases.   Not every bug did
> that.  For example, a defect report to update a mispelling in the UI
> would not lead to a new test case.  But many would.

we have the automated test framework that needs some more attention and
polishing. And of course the tests have to improved to get satisfying
result.

We have

BVT - build verification test
FVT - functional verification test
PVT - performance verification test
SVT - system verification test

But I have to confess that I have limited knowledge about it yet

Juergen

> 
> Regards,
> 
> -Rob
> 
>> rgds
>> jan I.
>>
>>

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

>>>
>>> -
>>> To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
>>> For additional co

Re: [BUILD] Linux32 snapshot configure

On Aug 15, 2013 11:00 AM, "Herbert Duerr"  wrote:
>
> On 15.08.2013 10:27, Oliver-Rainer Wittmann wrote:
>>
>> Error message from Linux 32bit build bot says:
>>
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/svgreader/svgsvgnode.cxx:
>> In member function 'virtual const basegfx::B2DRange*
>> svgio::svgreader::SvgSvgNode::getCurrentViewPort() const':
>>
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/svgreader/svgsvgnode.cxx:636:71:
>> error: taking address of temporary [-fpermissive]
>
>
> This bug was only found by the buildbot because it has a recent version
of the compiler. This proves yet again that buildbots as code quality
testers are very valuable.
>
> There is an interesting discrepancy:
> - builds for a wide test audience are best created for the greatest
common denominator target which on Linux requires that they are built on
very old systems
> - compile testing should best be done on very up-to-date buildbots but
the usability of their build output is usually quite limited
>
> Maybe we should reserve some buildbots to be always up-to-date whose
purpose is just for compile testing. Only their build reports with warnings
and errors should be kept and the builds themselves be should be discarded.

If we make such a setup correct on the centOS box, the footprint of the vm
wille be smalll, and can even be tarted on demand. I have a similar setup,
the vm only contains build environment, no svn files, they are attached as
local network drives (very fast). Starting/stopping can be done by making a
buildbot job for the centos.

that way we can have multiple test env.

rgds
jan i
>
> Herbert
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

Re: [BUILD] Linux32 snapshot configure

2013-08-15 Thread Herbert Duerr


On 15.08.2013 10:27, Oliver-Rainer Wittmann wrote:

Error message from Linux 32bit build bot says:
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/svgreader/svgsvgnode.cxx:
In member function 'virtual const basegfx::B2DRange*
svgio::svgreader::SvgSvgNode::getCurrentViewPort() const':
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/svgreader/svgsvgnode.cxx:636:71:
error: taking address of temporary [-fpermissive]


This bug was only found by the buildbot because it has a recent version 
of the compiler. This proves yet again that buildbots as code quality 
testers are very valuable.


There is an interesting discrepancy:
- builds for a wide test audience are best created for the greatest 
common denominator target which on Linux requires that they are built on 
very old systems
- compile testing should best be done on very up-to-date buildbots but 
the usability of their build output is usually quite limited


Maybe we should reserve some buildbots to be always up-to-date whose 
purpose is just for compile testing. Only their build reports with 
warnings and errors should be kept and the builds themselves be should 
be discarded.


Herbert

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

4.0.1_release_blocker granted: [Bug 123031] Update ES translation to latest pootle version

j...@apache.org has granted rgb 's request for
4.0.1_release_blocker:
Bug 123031: Update ES translation to latest pootle version
https://issues.apache.org/ooo/show_bug.cgi?id=123031


--- Additional Comments from j...@apache.org
approve showstopper request

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

4.0.1_release_blocker granted: [Bug 123039] Khmer (km) translation for OpenOffice 4.0.1

j...@apache.org has granted Andrea Pescetti 's request for
4.0.1_release_blocker:
Bug 123039: Khmer (km) translation for OpenOffice 4.0.1
https://issues.apache.org/ooo/show_bug.cgi?id=123039


--- Additional Comments from j...@apache.org
approve showstopper request

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

4.0.1_release_blocker granted: [Bug 122996] Polish (pl) translation for OpenOffice 4.0.1

j...@apache.org has granted Andrea Pescetti 's request for
4.0.1_release_blocker:
Bug 122996: Polish (pl) translation for OpenOffice 4.0.1
https://issues.apache.org/ooo/show_bug.cgi?id=122996

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

4.0.1_release_blocker granted: [Bug 122881] OpenOffice Application icon invisible

j...@apache.org has granted Raphael Bircher 's request for
4.0.1_release_blocker:
Bug 122881: OpenOffice Application icon invisible
https://issues.apache.org/ooo/show_bug.cgi?id=122881


--- Additional Comments from j...@apache.org
approve showstopper request

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

4.0.1_release_blocker granted: [Bug 122829] python ctypes library fails to import

j...@apache.org has granted h...@apache.org 's request for
4.0.1_release_blocker:
Bug 122829: python ctypes library fails to import
https://issues.apache.org/ooo/show_bug.cgi?id=122829


--- Additional Comments from j...@apache.org
approve as showstopper

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

4.0.1_release_blocker granted: [Bug 122827] calc slow saving in xls

j...@apache.org has granted h...@apache.org 's request for
4.0.1_release_blocker:
Bug 122827: calc slow saving in xls
https://issues.apache.org/ooo/show_bug.cgi?id=122827


--- Additional Comments from j...@apache.org
approve as showstopper

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

Re: [BUILD] Linux32 snapshot configure


Hi,

On 15.08.2013 10:10, Regina Henschel wrote:

Hi Oliver,

Oliver-Rainer Wittmann schrieb:

Hi,

Herbert, Andre and myself had a closer look on the error log of the
recent Linux 32bit build bot build (#456) and at the corresponding code.
It seems that there is a programming error in method
.

I am working on it.


Please tell me, what is the problem there. I wrote it.



What Herbert, Andre and myself have figured out is the following:
Error message from Linux 32bit build bot says:
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/svgreader/svgsvgnode.cxx: 
In member function 'virtual const basegfx::B2DRange* 
svgio::svgreader::SvgSvgNode::getCurrentViewPort() const':
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/svgreader/svgsvgnode.cxx:636:71: 
error: taking address of temporary [-fpermissive]
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/svgreader/svgsvgnode.cxx:679:75: 
error: taking address of temporary [-fpermissive]
/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/svgio/source/svgreader/svgsvgnode.cxx:698:67: 
error: taking address of temporary [-fpermissive]
make: *** 
[/home/buildslave20/slave20/openoffice-linux32-nightly/build/main/solver/400/unxlngi6.pro/workdir/CxxObject/svgio/source/svgreader/svgsvgnode.o] 
Error 1


The corresponding code line are:
- 636: return &basegfx::B2DRange(fX, fY, fX+fW, fY+fH);
- 679: return &basegfx::B2DRange(fX, fY, fX+fW, fY+fH);
- 698: return &basegfx::B2DRange(0.0, 0.0, fW, fH);
Thus, a pointer to a temporary created object is returned here and the 
return type of this method is . The life time of 
such an object ends when the method ends. Thus, accessing the returned 
pointer outside the method means accessing 'dead' memory.


Best regards, Oliver.

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

Re: [BUILD] Linux32 snapshot configure

2013-08-15 Thread Regina Henschel


Hi Oliver,

Oliver-Rainer Wittmann schrieb:

Hi,

Herbert, Andre and myself had a closer look on the error log of the
recent Linux 32bit build bot build (#456) and at the corresponding code.
It seems that there is a programming error in method
.

I am working on it.


Please tell me, what is the problem there. I wrote it.

Kind regards
Regina


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

Re: Some thoughts on quality

Hi,

On 14.08.2013 18:59, Rob Weir wrote:

We're working now on AOO 4.0.1, to fix defects in AOO 4.0.0. The fact
that we're doing this, and their are no arguments against it, shows
that we value quality. I'd like to take this a step further, and see
what we can learn from the defects in AOO 4.0.0 and what we can do
going forward to improve.

Quality, in the end, is a process, not a state of grace. We improve
by working smarter, not working harder. The goal should be to learn
and improve, as individuals and as a community.

Every regression that made it into 4.0.0 was added there by a
programmer. And the defect went undetected by testers. This is not
to blame. It just means that we're all human. We know that. We all
make mistakes. I make mistakes. A quality process is not about
becoming perfect, but about acknowledging that we make mistakes and
that certain formal and informal practices are needed to prevent and
detect these mistakes.

But enough about generalities. I'm hoping you'll join with me in
examining the 32 confirmed 4.0.0 regression defects and answering a
few questions:

1) What caused the bug? What was the "root cause"? Note:
"programmer error" is not really a cause. We should ask what caused
the error.

2) What can we do to prevent bugs like this from being checked in?

3) Why wasn't the bug found during testing? Was it not covered by any
existing test case? Was a test case run but the defect was not
recognized? Was the defect introduced into the software after the
tests had already been executed?

4) What can we do to ensure that bugs like this are caught during testing?

So 2 basic questions -- what went wrong and how can we prevent it in
the future, looked at from perspective of programmers and testers. If
we can keep these questions in mind, and try to answer them, we may be
able to find some patterns that can lead to some process changes for
AOO 4.1.

You can find the 4.0.0 regressions in Bugzilla here:

https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=400_regressions&sharer_id=248521&list_id=80834

Please include also issue with status ACCEPTED.

Best regards, Oliver.

Regards,

-Rob

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

Re: [BUILD] Linux32 snapshot configure


Hi,

On 15.08.2013 09:00, Oliver-Rainer Wittmann wrote:

Hi,

On 14.08.2013 19:29, Andrew Rist wrote:

Here is the current configure statement for the Linux32 bot - is this
correct, and what changes would make it better?

 ./configure \
 --with-jdk-home="/usr/lib/jvm/java-6-openjdk" \

--with-epm-url="http://www.msweet.org/files/project2/epm-3.7-source.tar.gz

" \

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


\
 --enable-verbose \
 --without-stlport \
 --enable-category-b \
 --enable-opengl \
 --enable-dbus \
 --enable-gstreamer \
  --with-package-format="installed rpm deb" \
  --enable-bundled-dictionaries \
  --with-lang="ast cs de el en-GB en-US es fi fr gd gl hu it
ja km ko nl pl pt pt-BR ru sk sl ta zh-CN zh-TW ca eu he hi id lt sv
th tr " \
 --with-vendor="Apache OpenOffice buildbot" \
 --with-build-version="%(today)s-Rev.%(got_revision)s" \





These configure options correspond to the ones which I am using on my
Ubuntu 11.10 32bit VM.
I will perform a clean build on my VM in order to check, if I can
reproduce the build breaker from our Linux 32bit build bot.

Stay tuned for my results.



Herbert, Andre and myself had a closer look on the error log of the 
recent Linux 32bit build bot build (#456) and at the corresponding code.
It seems that there is a programming error in method 
.


I am working on it.

Best regards, Oliver.

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

Re: [BUILD] Linux32 snapshot configure

2013-08-15 Thread Herbert Duerr


Hi Andrew,

On 14.08.2013 19:29, Andrew Rist wrote:

Here is the current configure statement for the Linux32 bot - is this
correct, and what changes would make it better?
[...]
  --with-package-format="installed rpm deb" \


I'd suggest to change that line to
--with-package-format="archive rpm deb"
The "installed" target is great for developers who want to run a build 
directly, but for buildbots it doesn't make sense. The "archive" target 
is great for quickly testing a build.


Herbert

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

4.0.1_release_blocker requested: [Bug 122996] Polish (pl) translation for OpenOffice 4.0.1

Andrea Pescetti  has asked  for 4.0.1_release_blocker:
Bug 122996: Polish (pl) translation for OpenOffice 4.0.1
https://issues.apache.org/ooo/show_bug.cgi?id=122996

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

4.0.1_release_blocker requested: [Bug 123039] Khmer (km) translation for OpenOffice 4.0.1

Andrea Pescetti  has asked  for 4.0.1_release_blocker:
Bug 123039: Khmer (km) translation for OpenOffice 4.0.1
https://issues.apache.org/ooo/show_bug.cgi?id=123039


--- Additional Comments from Andrea Pescetti 
This is the tracking issue for the Khmer (km) translation of Apache OpenOffice.


The translation is already at 100% in Pootle:
https://translate.apache.org/km/aoo40/
(courtesy of khoemsokhem) and should be integrated in 4.0.1.

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

[WWW] Convention for images and logos

Dave has been updating the cWiki for conventions about the relationship
between some of the image files as well as address orphan sites on the
www-site root level.

This clean up is important, however the core proposal is to have a more
uniform convention on the file name.

I wrote some proposed conventions, I would like to get some
approval/comment on these, or overhead agreement why this is/isn't
necessary.

https://cwiki.apache.org/confluence/display/OOOUSERS/File+handling+proposal+for+logos+and+graphics#New+conventions



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

We have to talk....

2013-08-15 Thread Dong-Mei Feng

 - This mail is in HTML. Some elements may be ommited in plain text. -

Hello,
We have to finish this.
Mei

Re: [BUILD] Linux32 snapshot configure