[Libreoffice] Patches to review in IssueZilla

[Kálmán „KAMI” Szalai]

Title: Szalai Kálmán


  
  
Hi,

I searched across OOo issues. Do we have interesting item to review
and/or integrate?
http://tools.openoffice.org/issues/buglist.cgi?issue_type=PATCH;issue_status=UNCONFIRMED;issue_status=NEW;issue_status=STARTED;issue_status=REOPENED;email1=;emailtype1=exact;email2=;emailtype2=exact;issueidtype=include;issue_id=;changedin=;votes=;chfieldfrom=;chfieldto=;chfieldvalue=;short_desc=;short_desc_type=allwords;long_desc=;long_desc_type=allwords;issue_f
ile_loc=;issue_file_loc_type=fulltext;status_whiteboard=;status_whiteboard_type=fulltext;keywords=;keywords_type=anytokens;field0-0-0=noop;type0-0-0=noop;value0-0-0=;Submit%20query=Submit%20query&order=issues.issue_id
 
-- 
  
  
  Best regards,

Kálmán „KAMI” Szalai | 神 | kami911 [at] gmail [dot] com


My favorite projects:

OxygenOffice Professional - office suite - for everybody | Magyarul - In Hungarian

Blog | Support 

Follow me, if you can



  



signature.asc
Description: OpenPGP digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] libreoffice Uebersetzung

[Rene Engelhard]

Hallo,

On Thu, Nov 18, 2010 at 12:28:27AM -0300, wer...@guyane.yi.org wrote:
> Das Installieren geht ueberhaupt nicht
> 
> Ich habe das im Oo support Forum gepostet, aber es kam keine brauchbare 
> Antwort.
> 
> http://user.services.openoffice.org/en/forum/viewtopic.php?f=16&t=35931
> 
> Bitte um Ueberpruefung/  Dasmake Skript funktioniert halt nicht richtig.

Doch, tut. Nur haben Sue die extensions, die da erwartet wirst nicht gebaut. 
Wenn man solche supertollen
extra features enabled.. Ich würde die Option einfach abschalten.

> / Aber auch das globale Programm sollte, statt/ausser mit bin/ooinstaller , 
> auch mit make destdir=X install installierbar sein.   Dabei ist die Option 
> destdir=... besonders wichtig.  So dass man das Ganze in einen Ordner 
> installieren kann. Naemlich man will sich dann selbst Verschiedenes in 
> einzelne Pakete unterteilen (zBsp jede Sprache als einzelnes Paket)

Tut. Und genauso wird es auch von den distros gemacht (auch mit der 
Unterteilung)

> 
> / Normalerweise laden die Packer zu uebersetzende Programme .tar.bz2 selbst 
> down, ebenso ggf. zusaetzliche Programme. Es gibt zwar eine Option in 
> configure fuer den ordner wo die source-Programme sind ... die funktioniert 
> jedoch nicht. Und bei jeder (nach Fehler) wiederholten Uebersetzung, wird 
> alles nochmal neu downgeladen ... 

Falsch. Wenn Du den ./download-Schritt meinst

> Das sollte unbedingt funktionierend gemacht werden. Dabei sollten auch die 
> Source-Programme im Original bleiben -- nicht mit langen Nummern versehen 
> werden.BITTE ALLES UNNUETZ KOMPLIZIERTE VERMEIDEN.  Die Packer 
> uebersetzen / packen sehr viele Programme, wen da jedes Extrawuerste oder 
> individuelle Prozedur zum Uebersetzen / linken hat, wird man wahnsinnig.  
> dasSchema configure - make - make destdir=PKGDIR install sollte immer 
> moeglich sein.

Und geht auch. Und Sie machen es sich selbsr kompliziert(er).

Und vielleicht sollten sie auf einer internationalen Liste auch nicht auf 
Deutsch
schreiben sondern auf Englisch. Und sinnvoll Ihre Zeilen umbrechen.

Grüße/Regards,

René
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PUSHED] RTL_CONSTASCII_USTRINGPARAM for libs-core/connectivity/drivers/ado

[David Tardon]

On Wed, Nov 17, 2010 at 10:52:47PM +0100, Julien Nabet wrote:
> Hello,
> 
> Here's patch for libs-core/connectivity/drivers/ado
> 
> Julien.
> (LGPLv3+ / MPL)

Pushed, thanks!

D.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PUSHED] Clean code at writer (core/{access, attr, bastyp, crsr, doc})

[David Tardon]

On Tue, Nov 16, 2010 at 10:18:18AM -0800, Kayo Hamid wrote:
> Hello, sending this for review. It covers five dirs at core/
> core/accesscore/attrcore/bastypcore/crsrcore/doc
> revol_
> 
> 
>   

I pushed it with several changes:
* reverted several comments that remain valid after the removals
* reverted one removed vim modeline
* removed issue numbers only related to the removed code. Nonexistent
  code doesn't need comments .-)
* removed all refs to old bug tracker (Bug:  -- I don't remember
  ever seeing this form before...)

D.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] libreoffice Uebersetzung

[werner]

Hallo

Ich wollte fuer meine SYS Distro libreoffice kompilieren und packen.  Meine 
Pakete sind normalerweise kompatibel mit allen Slackware -aehnlichen Distros

Das Uebersetzen ging, bis zum anschliessenden logo mit Glueckwuenschen zum 
erfolgreichen build

Das Installieren geht ueberhaupt nicht

Ich habe das im Oo support Forum gepostet, aber es kam keine brauchbare Antwort.

http://user.services.openoffice.org/en/forum/viewtopic.php?f=16&t=35931

Bitte um Ueberpruefung/  Dasmake Skript funktioniert halt nicht richtig.


Noch folgende DRINGENDE Hinweise:

Ich uebersetze und packe sehr viele Programme, bin da auch 'einiges' gewoehnt 
und kriege auch komplizierte Sachen durch.

Ich empfehle DRINGEND:

/ Die Uebersetzung von allen source-Modulen sollte fuer jedes Modul getrennt 
abgespeichert werden, insgesamt in einem Ordner, und das build-Skript sollte in 
jedes dann sein eigenes configure und make -File hineinschreiben, ausserdem 
sollte ein default configure schon von Haus aus drin sein. So dass man jedes 
Modul einzeln uebersetzen und installieren kann, nach demSchema ./configure , 
make , make destdir=X install .   Mit modul ist damit gemeint, jedes der ca. 10 
programme von libO die als .tar.bz2 einzeln geliefert werden

/ Aber auch das globale Programm sollte, statt/ausser mit bin/ooinstaller , 
auch mit make destdir=X install installierbar sein.   Dabei ist die Option 
destdir=... besonders wichtig.  So dass man das Ganze in einen Ordner 
installieren kann. Naemlich man will sich dann selbst Verschiedenes in einzelne 
Pakete unterteilen (zBsp jede Sprache als einzelnes Paket)

/ Normalerweise laden die Packer zu uebersetzende Programme .tar.bz2 selbst 
down, ebenso ggf. zusaetzliche Programme. Es gibt zwar eine Option in configure 
fuer den ordner wo die source-Programme sind ... die funktioniert jedoch nicht. 
Und bei jeder (nach Fehler) wiederholten Uebersetzung, wird alles nochmal neu 
downgeladen ...  Das sollte unbedingt funktionierend gemacht werden. Dabei 
sollten auch die Source-Programme im Original bleiben -- nicht mit langen 
Nummern versehen werden.BITTE ALLES UNNUETZ KOMPLIZIERTE VERMEIDEN.  Die 
Packer uebersetzen / packen sehr viele Programme, wen da jedes Extrawuerste 
oder individuelle Prozedur zum Uebersetzen / linken hat, wird man wahnsinnig.  
dasSchema configure - make - make destdir=PKGDIR install sollte immer moeglich 
sein.

/ Ich empfehle ausserdem, alle ueberfluessigen Programme wegzulassen. Und wenn 
ein nicht wichtiges Zusatz-Programm nicht downloadbar ist, sollte rueckgefragt 
und man die Option haben, es zu streichen, sodaß ohne ihm die Uebersetzung / 
Installation weitergeht.

Bitte helfen Sie mir jetzt, das installiert zu kriegen.


Mit freundlichen gruessen

Werner Landgraf


Linux SYS distro, mirrors:
 ftp: //ftp5.gwdg.de/pub/linux/install/sys/ ,  http: 
//ftp5.gwdg.de/pub/linux/install/sys/
 ftp: //ftp.uni-siegen.de/pub/sys-linux

=

libreoffice 3.3b3 : it compiled , but dont install

Postby wl59 » Tue Nov 16, 2010 4:18 am
I have the following problem with libreoffice 3.3b3:

It compiled, and reached the congratulations of a sucessful building at the end.

But the installation don't work. No matter if I start it using bin/ooinstall or 
make install , it came an error message like below, w.r.t. convert text to 
number, and lightproof. When I recompile with --without-lightproof and 
--without-numbertext , then the first message disappears, the second continues. 
The building itself seems to be correct, all presumed files are present (and 
compiled).

How to get this installed ???


At this oportunity, I want to suggest, that urgently the building program 
should provide (at the beginning) to each part of the program what has its own 
.tar.bz2 file, also its own makefile. So that each module can be compiled for 
itself. To can compile / recompile only the whole program, is very time 
consuming





==
Reading setup from bin/setup
Running OOo installer
Subroutine installer::epmfile::getcwd redefined at 
/usr/lib/perl5/5.8.8/Exporter.pm line 65.
 at /usr/lib/perl5/5.8.8/i486-linux-thread-multi/POSIX.pm line 19
.. checking environment variables ...


make_installer.pl, version 1.0
Product list file: openoffice.lst
Taking setup script from solver
Unpackpath: 
/LibO-330/libreoffice-3.2.99.3/build/libreoffice-3.2.99.3/instsetoo_native/util
Compiler: unxlngi6
Product: LibreOffice
BuildID: 1
Build: OOO330
No minor set
Product version
Installpath: /LibO-330/libreoffice-3.2.99.3/build/libreoffice-3.2.99.3/extra
Package format: native
Not calling epm
No file stripping
Unzip ARCHIVE files
services.rdb can be created
Languages:
en-US

.. checking required files ...
. search

Re: [Libreoffice] HC Error

[Norbert Thiebaud]

On Nov 17, 2010, at 18:14, Joseph Powers  wrote:

> Your patch looks good.
> 
> Sorry about that; now I'm wondering why it built for me...

Because on MacOS you probably don't buid gtk related stuff ?

Norbert

> 
> Joe P.
> 
> 
> Message: 6
> Date: Wed, 17 Nov 2010 20:58:20 +0100
> From: C?dric Bosdonnat 
> Subject: [Libreoffice] HC Image fix
> To: libreoffice@lists.freedesktop.org
> Message-ID:
>   <1290023900.7450.1.ca...@workstation.bosdonnat.homelinux.org>
> Content-Type: text/plain; charset="UTF-8"
> 
> Hi all and mostly Joseph,
> 
> We all had to face some build error in vcl... I pushed the following
> quick hack... but I'ld like Joseph to review it and correct it if
> needed:
> 
> http://cgit.freedesktop.org/libreoffice/libs-gui/commit/?id=a2603a2edb54f78a746e5edfba181d429727dea7
> 
> Regards,
> --
> Cedric
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] HC Error

[Joseph Powers]

Your patch looks good.

Sorry about that; now I'm wondering why it built for me...

Joe P.


Message: 6
Date: Wed, 17 Nov 2010 20:58:20 +0100
From: C?dric Bosdonnat 
Subject: [Libreoffice] HC Image fix
To: libreoffice@lists.freedesktop.org
Message-ID:
<1290023900.7450.1.ca...@workstation.bosdonnat.homelinux.org>
Content-Type: text/plain; charset="UTF-8"

Hi all and mostly Joseph,

We all had to face some build error in vcl... I pushed the following
quick hack... but I'ld like Joseph to review it and correct it if
needed:

http://cgit.freedesktop.org/libreoffice/libs-gui/commit/?id=a2603a2edb54f78a746e5edfba181d429727dea7

Regards,
--
Cedric
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Git server-side hooks

[Kohei Yoshida]

On Thu, 2010-11-18 at 00:57 +0100, Miklos Vajna wrote:
> 1) Non-fastforwards (ie. pushing a rebase) are not allowed in repos at
> all.
> 
> 2) In case non-fastforwards are worked around by deleting the branch +
> creating it again, the CIA bot spams the #libreoffice channel. (That
> happened tonight when Kohei updated
> feature/calc-dp-unlimited-fields.) 

Also...

3) When creating a feature branch, by default, the autosetuprebase
option is set to true, which forces rebase when pulling from the master
branch even without the -r switch.  You need to manually specify
--no-rebase to disable rebase.

I'm very concerned about this, because with this setting, pulling from
the master into a feature branch, and push to the remote feature branch
fails (because you rebased).  Worse, when pushing to the remote fails,
git tells you to pull from the remote feature branch, but when you do
that, you lose the merging of the master you just did (bad).

And continuously pulling from the master branch is very common when you
are in a long-term feature branch, and messing up the branch history is
the last thing you want to see happen while the branch is still being
worked on.

The current workaround is to directly edit the .git/config file to
manually remove autosetuprebase=true from every feature branch you have,
but I wouldn't necessarily call it intuitive...

Kohei

-- 
Kohei Yoshida, LibreOffice hacker, Calc


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PUSHED] Re: [PATCH 02/12] RTL_CONSTASCII_USTRINGPARAM in components cui options

[Pierre-André Jacquod]

Hello,
Sharp eyes.. Just to keep you trainded..:-(
No really sorry, Despite reviewing diff, I did not catch this one.
Will take more care


On 11/17/2010 05:18 PM, Caolán McNamara wrote:
> On Tue, 2010-11-16 at 22:39 +0100, Pierre-André Jacquod wrote:
>> On 11/16/2010 10:37 PM, Pierre-André Jacquod wrote:
>>> Hello,
>>> being off for some days, here the collection of patches I produced in
>>> between.
> 
> Mostly good, but careful here, see...
> 
> -aAutoStr += ::rtl::OUString::createFromAscii( " (" );
> +aAutoStr += ::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("(") );
> 
> you changed the string by accident from a bracket with a preceding space
> to one with no preceding space, clearly what's between "" has to remain
> the same :-). Fixed that typo and the rest looks good, pushed.
> 
> C.
> 
> 
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
> 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] Git server-side hooks

[Miklos Vajna]

Hi Kendy,

Tonight on IRC we had a discussion about two issues related to git
hooks:

1) Non-fastforwards (ie. pushing a rebase) are not allowed in repos at
all.

2) In case non-fastforwards are worked around by deleting the branch +
creating it again, the CIA bot spams the #libreoffice channel. (That
happened tonight when Kohei updated feature/calc-dp-unlimited-fields.)

Let's ignore the second problem for now. 1) is because the
receive.denyNonFastforwards setting is set to true in the repos.

Considering that keeping the history clean in a feature branch by
rebasing it from time to time sounds sane, I think we could do the
followings:

a) Disable receive.denyNonFastforwards in the config in each repo.
b) Enable the attached hook, that will still deny non-fastforwards in
   case the updated ref is not a feature branch.
c) Just to be safe, core.logallrefupdates could be set to true, so that
   a reflog will contain all the previous values of the refs, which means
   if someone did a 'git push -f' and updated a feature branch and it turns
   out it was a bad idea, the reflog can be still used to restore the
   branch's (good) old value.

Does this sound sane?

About 2) - is the script feeding the CIA bot public? I would like to
extend it so that in case of non-fastforwads and merges only the last
commit is announced to avoid spamming.

Thanks.
#!/bin/sh

while read oldrev newrev refname
do
case $refname in
refs/heads/feature/*)
# we allow non-fastforwards here
;;
*)
if [ -n "$(git rev-list $newrev..$oldrev)" ]; then
echo "Non-fastforward in non-feature branches is not allowed."
exit 1
fi
;;
esac
done

# vim:set shiftwidth=4 softtabstop=4 expandtab:


pgpIl6NRCwuks.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [UX] Progress bars - convey "this make take some time, dunno how long"

[Thorsten Behrens]

Christoph Noack wrote:
> Okay, so we just "move" the problem. To better understand the issue...
> 
>   * The patch just changes the progress bar behavior, but the time
> to be waited is the same?
> 
>   * The progress bar is the only information - as far as I know,
> there is no percentage completed (on any platform), or?
> 
Yes, both times.

> ALTERNATIVE
> 
> If (and only for that reason) the save/load process gets stuck for
> (e.g.) min. 5 seconds, and there is no way of availability-checking of
> the network connection in advance, then we might simply bring up a
> message box that says something like "File XYZ is being saved which
> requires some time. Please wait ..." (not final, of course).
> 
Possible, though prolly not for 3.3 (string/UI freeze).
Additionally, we may not know in advance, how long these operations
may take (it's not always transparently retrievable information, if
e.g. a file resides on a network volume).

Given your answer, I'd tend to not touch this for 3.3, and maybe
work on a better solution post-3.3.

> Cancel is optional
>
Even impossible, with the current code. ;)

Thanks for your insight anyway,

-- Thorsten


pgp5eN0pviz5c.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Examing unicode strings in gdb (while debugging LibO)

[Miklos Vajna]

On Wed, Nov 17, 2010 at 04:44:19PM +, Caolán McNamara  
wrote:
> print dbg_dump(string)
> 
> should (in theory) generally work with rtl::OUString,rtl::OString,String
> and ByteString, etc.

See also scratch/writer/gdbinit-cbosdo in build.git. :)


pgpTfdkus7frX.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] What are these /*N*/ comments?

[Kevin Hunter]

Hullo List,

Is there a reason for lines that look like this?

[...]
/*N*/   String  aGraphicId( rGraphicId );
/*N*/ 	BfGraphicObject aGrfObject( ByteString( aGraphicId, 
RTL_TEXTENCODING_ASCII_US ) );

/*N*/
/*N*/ maTmp.EnableKillingFile();
/*N*/
/*N*/   if( aGrfObject.GetType() != GRAPHIC_NONE )
/*N*/   {
[...]

The code is compiled, but what was the initial reason to have them in there?

Kevin
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Questions about Timers

[Kevin Hunter]

At 5:13pm -0500 Wed, 17 Nov 2010, Julien Nabet wrote:

PS : in the easy hack, "for RTL_CONSTASCII_USTRINGPARAM macro",
wouldn't it be better to change the "grep" in "fgrep" in order to
make the searching faster ?


That might have marginally been an issue once upon a time, but now, 
they're likely to be linked to the same binary.  If they aren't linked 
on your implementation, unless you're doing lots of recursive uses of 
grep on extremely large files, I think you'll barely notice any speed 
difference, especially compared to the time it takes to read data from 
the disk or to edit any code.


Since the origin of fgrep, algorithms and computer hardware have come a 
/long/ way.  Certainly in this context, I doubt grep will be a workflow 
bottleneck.


For reference, GNU's grep specifically deprecates fgrep in favor of grep -F.

http://www.gnu.org/software/grep/manual/grep.html

Another source of potentially useful info:

http://en.wikipedia.org/wiki/Grep

Cheers,

Kevin
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] Questions about Timers

[Julien Nabet]

Hello,

In the easy hacks, could it be possible to have more information on what 
to do with timers ?

For example :
- what's a "leaked timer", is it the same as "permanent timer" that i 
read on this http://qa.openoffice.org/issues/show_bug.cgi?id=106485 ?

- how to find a leaked timer ?
- how to correct them ? (must we delete them or change them ?)

For example, the timer mpOnlineSpellingTimer that we can find in these 
files :

impress/sd/inc/drawdoc.hxx
impress/sd/source/core/drawdoc4.cxx
impress/sd/source/core/drawdoc.cxx

Is this timer ok ? Is there something we can improve/optimize in it ?

Julien.

PS : in the easy hack, "for RTL_CONSTASCII_USTRINGPARAM macro", wouldn't 
it be better to change the "grep" in "fgrep" in order to make the 
searching faster ?


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Error in for libuno_sal.so.3 sal + lots of undefined references

[Julien Nabet]

Le 17/11/2010 22:13, Caolán McNamara a écrit :

On Wed, 2010-11-17 at 22:03 +0100, Julien Nabet wrote:
   

alloc_arena.c:(.text+0x1255): undefined reference to `pthread_once'
 

Woops, bit of fallout from the Unix GCC .mk merging, try pulling again
and see does it work.

C.


   
I pulled again then typed "rm -rf unxlngi6.pro" in the sal directory (i 
did it though i don't know if it was mandatory) and that's ok now.


Julien.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PUSHED] Draw a visible line under the current line

[Jonas Finnemann Jensen]

Hi Luke,

I've pushed your patch, it looks good and works great...
Now there's a chance that users will notice that 3 and 4 are in two
different lines in the following formula: 3 + 4^2
The way the SmSubSupNode works isn't very intuitive for visual editing (at
least compared to MathType), but with this patch people should have a chance
to actually notice this obscurity... Thanks! :)

 I made a couple of methods for SmGraphicWindow, IsLineVisible and ShowLine.
> I made them public, as I would imagine they would be used for number 7 of
> the complex and non-essential tasks on the todo list.

That's a great idea, we will probably need that when trying to address that
issue...
(btw, you're welcome to work on the extra dream feature if you  feel like
it).

As always just move the issue from the easy hacks page, when you're done
with it... :)

Again, thanks for a great patch... That's on more off the todo-list...

--
Regards Jonas Finnemann Jensen.


On Wed, Nov 17, 2010 at 00:43, Luke Dixon <6b8b4...@gmail.com> wrote:

> Hello Jonas,
> > I think the patch looks great, I've pushed it... But when we need to
> > draw a thin solid line under the visual line that the caret is in, we
> > will probably need to pass a boolean value to SmCursor::Draw in
> > SmGraphicWindow::Paint and from SmCursor::Draw to
> > SmCaretDrawingVisitor... So that only the vertical line blinks, but
> > the solid underline of the visual line doesn't blink...
> > This is as opposed to not calling SmCursor::Draw in
> > SmGraphicWindow::Paint which is what currently happens...
>
> Thanks very much for your help in pointing me in the right direction for
> this.
>
> I've attempted the other easy hack, this information meant I didn't have
> to spend any time working out what to do.
> I made a couple of methods for SmGraphicWindow, IsLineVisible and
> ShowLine. I made them public, as I would imagine they would be used for
> number 7 of the complex and non-essential tasks on the todo list.
>
> > By the way, I think that it's really cool that you found the setting
> > for the caret blink timer... Nice work!
> That was all thanks to opengrok.go-oo.org (thanks for pointing that out
> to me).
>
>
> Regards,
> Luke
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [UX] Progress bars - convey "this make take some time, dunno how long"

[Christoph Noack]

Hi Thorsten!

Progress bar issue summary: Cannot be solved easily :-) But should it be
solved?

Am Mittwoch, den 17.11.2010, 15:47 +0100 schrieb Thorsten Behrens:
> Hi,
> 
> chatting with some folks yesterday at the OOo congress for business
> and administration, and two users approached me with a problem most
> prevalent when saving to network volumes:

Okay.

> LibO save progress bars [...] stuck at 100% (because all
> xml content is written), but the apps are still unresponsive
> (sometimes for a minute or so).

Not that good ...

> Changing SaveTo_Impl() to use async IO is prolly out of scope for
> 3.3, so another workaround would be to keep the progress bar from
> reaching 100% before all work is finished - see attached patches 
> for a sketchy attempt. Problem here: the progress bar will not move
> either way, it's just not stuck at 100%, but at 90% now.

QUESTIONS

Okay, so we just "move" the problem. To better understand the issue...

  * The patch just changes the progress bar behavior, but the time
to be waited is the same?

  * The progress bar is the only information - as far as I know,
there is no percentage completed (on any platform), or?


ISSUES

Two main problems: Users don't know ...
 1. ... how long it will take (the idea of progress bars is to
provide something which enables people to anticipate the
duration of the task and to get some rough information on the
percentage completed)
 2. ... if LibO is still running and will (finally) complete the
task (no real lockup).

Item 1 cannot be solved - the progress bars (better: the task) will get
stuck, no way to change that (easily).

Item 2 is only partly addressed - only few platforms bring "spinning
progress bars" that visualize some "activity" (Apple, Windows
Vista, ...) if progress bars get stuck for a short time. Although this
is just "psychological magic", it works :-)


IMPACT

So there is no solution that can be addressed with a progress bar ...
but is this a real problem at the moment? How often might that occur to
people who don't know that LibO will finally finish their request? So
how much negative impact does this issue have - in comparison to the
"short-term solution"?

>From my point-of-view, working on a "real" improvement would be better.
But if there is none within the next few months, and quite some users
experience this, then ...


ALTERNATIVE

If (and only for that reason) the save/load process gets stuck for
(e.g.) min. 5 seconds, and there is no way of availability-checking of
the network connection in advance, then we might simply bring up a
message box that says something like "File XYZ is being saved which
requires some time. Please wait ..." (not final, of course).

++
| LibreOffice Writer |
++
||
||
||
|   ++   |
|   | Saving |   |
|   ++   |
|   ||   |
|   |  File "Bad-UX-Hack.odt" is |   |
|   |  being saved which requires|   |
|   |  some time. Please wait ...|   |
|   ||   |
|   |   [ Cancel ]   |   |
|   ++   |
||
||
||
++
| Saving ### |
++


A bad and (from UX point-of-view) hacky solution, but it should work
with the given tools we do have (without hacking the status bar, ...).
But, another dialog to be translated. Cancel is optional - but having
such functionality is "good manner". 

That might be an interim (!) "solution".

> Any UX insight on how to best get this across? 

Might that work?

Cheers,
Christoph

PS: By the way, well tagged message :-)

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] RTL_CONST patch: binfilter

[Kevin Hunter]

Hullo List,

A quick two-line patch against binfilter.

Kevin


0001-EasyHack-RTL_CONST-from-createFromAscii.patch.gz
Description: GNU Zip compressed data
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PATCH] RTL_CONSTASCII_USTRINGPARAM for libs-core/connectivity/drivers/ado

[Julien Nabet]

Hello,

Here's patch for libs-core/connectivity/drivers/ado

Julien.
(LGPLv3+ / MPL)


libs_core_connectivity_drivers_ado.txt.bz2
Description: application/bzip
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Fwd: Re: cppcheck : snprintf size is out of bounds

[Julien Nabet]

Le 17/11/2010 22:19, Caolán McNamara a écrit :

On Wed, 2010-11-17 at 21:50 +0100, julien wrote:
   

There's no more cppcheck errors if if i change the line :
const sal_uInt32 nBezString = 1024;

into this :
sal_uInt32 nBezString = 1024;

Before i create a tracker for cppcheck guy, i'd like to know what you
think about it ?
 

Yeah, that basically confirms it for me.

C.

   

I created the ticket 2210 for this bug.
I noticed that sal_uInt32 is defined in sal/inc/sal/types.h and that it 
depended of preprocessor, perhaps it's the pb.

I attached this remark in the tracker.

Julien.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] HC Image fix

[Caolán McNamara]

On Wed, 2010-11-17 at 21:28 +0100, Joost Eekhoorn wrote:
> Hi
> 
> The hack work, but now my build brake in sal:

try pulling again, hopefully a temporary cockup that I've fixed now :-)

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Fwd: Re: cppcheck : snprintf size is out of bounds

[Caolán McNamara]

On Wed, 2010-11-17 at 21:50 +0100, julien wrote:
> There's no more cppcheck errors if if i change the line :
> const sal_uInt32 nBezString = 1024;
> 
> into this :
> sal_uInt32 nBezString = 1024;
> 
> Before i create a tracker for cppcheck guy, i'd like to know what you
> think about it ?

Yeah, that basically confirms it for me.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Error in for libuno_sal.so.3 sal + lots of undefined references

[Caolán McNamara]

On Wed, 2010-11-17 at 22:03 +0100, Julien Nabet wrote:
> alloc_arena.c:(.text+0x1255): undefined reference to `pthread_once'

Woops, bit of fallout from the Unix GCC .mk merging, try pulling again
and see does it work.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Disable GCC optimizations when building with --enable-symbols

[Jesús Corrius]

On Wed, Nov 17, 2010 at 9:16 PM, Caolán McNamara  wrote:
> On Wed, 2010-11-17 at 15:50 -0300, Santiago Bosio wrote:
>> Hi!
>>
>> When LibO is built using --enable-symbols, it still uses -O2
>> optimizations, making hard to debug execution with GDB.
>>
>> So, I think that it should default to -O2 on a normal build, and to -O0
>> when using --enable-symbols.
>
> I'm not a fan of that idea really. I'd prefer to retain the
> --enable-debug option as the one that sets -O0 and leave
> --enable-symbols as -g and not touching the -O2.

Yes, exactly.
We should be able to debug production code the same way it's shipped.

-- 
Jesús Corrius 
Document Foundation founding member
Skype: jcorrius | Twitter: @jcorrius
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] Error in for libuno_sal.so.3 sal + lots of undefined references

[Julien Nabet]

Hello,

Even with an "rm -rf unxlngi6.pro" in sal, I got this :
Entering 
/home/serval/libreoffice-source/build/build/libreoffice-3.2.99.2/sal/util, 
I typed this :

/bin/bash
cd /home/serval/libreoffice-source/build/build/libreoffice-3.2.99.2
source ./LinuxX86Env.Set.sh
cd sal
build verbose=1


Making:libuno_sal.so.3
g++ -Wl,-z,noexecstack -Wl,-z,combreloc -Wl,-z,defs 
-Wl,-Bsymbolic-functions -Wl,--dynamic-list-cpp-new 
-Wl,--dynamic-list-cpp-typeinfo -Wl,--hash-style=both 
-Wl,-rpath,'$ORIGIN' "-Wl,-hlibuno_sal.so.3" -shared -Wl,-O1 
-Wl,--version-script ../unxlngi6.pro/misc/sal_uno_sal.map 
-L../unxlngi6.pro/lib -L../lib 
-L/home/serval/libreoffice-source/build/build/libreoffice-3.2.99.2/solenv/unxlngi6/lib 
-L/home/serval/libreoffice-source/build/build/libreoffice-3.2.99.2/solver/330/unxlngi6.pro/lib 
-L/home/serval/libreoffice-source/build/build/libreoffice-3.2.99.2/solenv/unxlngi6/lib 
-L/usr/lib/jvm/java-6-openjdk/lib 
-L/usr/lib/jvm/java-6-openjdk/jre/lib/i386 
-L/usr/lib/jvm/java-6-openjdk/jre/lib/i386/client 
-L/usr/lib/jvm/java-6-openjdk/jre/lib/i386/native_threads 
../unxlngi6.pro/slo/uno_sal_version.o -o 
../unxlngi6.pro/lib/libuno_sal.so.3 ../unxlngi6.pro/slo/utility.o 
../unxlngi6.pro/slo/filepath.o ../unxlngi6.pro/slo/debugbase.o 
../unxlngi6.pro/slo/loadmodulerelative.o ../unxlngi6.pro/slo/conditn.o 
../unxlngi6.pro/slo/diagnose.o ../unxlngi6.pro/slo/semaphor.o 
../unxlngi6.pro/slo/socket.o ../unxlngi6.pro/slo/interlck.o 
../unxlngi6.pro/slo/mutex.o ../unxlngi6.pro/slo/nlsupport.o 
../unxlngi6.pro/slo/thread.o ../unxlngi6.pro/slo/module.o 
../unxlngi6.pro/slo/process.o ../unxlngi6.pro/slo/security.o 
../unxlngi6.pro/slo/profile.o ../unxlngi6.pro/slo/time.o 
../unxlngi6.pro/slo/signal.o ../unxlngi6.pro/slo/pipe.o 
../unxlngi6.pro/slo/system.o ../unxlngi6.pro/slo/util.o 
../unxlngi6.pro/slo/tempfile.o ../unxlngi6.pro/slo/file.o 
../unxlngi6.pro/slo/file_misc.o ../unxlngi6.pro/slo/file_url.o 
../unxlngi6.pro/slo/file_error_transl.o 
../unxlngi6.pro/slo/file_path_helper.o ../unxlngi6.pro/slo/file_stat.o 
../unxlngi6.pro/slo/file_volume.o ../unxlngi6.pro/slo/uunxapi.o 
../unxlngi6.pro/slo/process_impl.o ../unxlngi6.pro/slo/salinit.o 
../unxlngi6.pro/slo/memory.o ../unxlngi6.pro/slo/cipher.o 
../unxlngi6.pro/slo/crc.o ../unxlngi6.pro/slo/digest.o 
../unxlngi6.pro/slo/random.o ../unxlngi6.pro/slo/locale.o 
../unxlngi6.pro/slo/strimp.o ../unxlngi6.pro/slo/hash.o 
../unxlngi6.pro/slo/string.o ../unxlngi6.pro/slo/ustring.o 
../unxlngi6.pro/slo/strbuf.o ../unxlngi6.pro/slo/ustrbuf.o 
../unxlngi6.pro/slo/uuid.o ../unxlngi6.pro/slo/rtl_process.o 
../unxlngi6.pro/slo/byteseq.o ../unxlngi6.pro/slo/uri.o 
../unxlngi6.pro/slo/bootstrap.o ../unxlngi6.pro/slo/cmdargs.o 
../unxlngi6.pro/slo/unload.o ../unxlngi6.pro/slo/logfile.o 
../unxlngi6.pro/slo/tres.o ../unxlngi6.pro/slo/debugprint.o 
../unxlngi6.pro/slo/math.o ../unxlngi6.pro/slo/alloc_global.o 
../unxlngi6.pro/slo/alloc_cache.o ../unxlngi6.pro/slo/alloc_arena.o 
../unxlngi6.pro/slo/context.o ../unxlngi6.pro/slo/convertbig5hkscs.o 
../unxlngi6.pro/slo/converter.o ../unxlngi6.pro/slo/converteuctw.o 
../unxlngi6.pro/slo/convertgb18030.o 
../unxlngi6.pro/slo/convertiso2022cn.o 
../unxlngi6.pro/slo/convertiso2022jp.o 
../unxlngi6.pro/slo/convertiso2022kr.o 
../unxlngi6.pro/slo/convertsinglebytetobmpunicode.o 
../unxlngi6.pro/slo/tcvtbyte.o ../unxlngi6.pro/slo/tcvtmb.o 
../unxlngi6.pro/slo/tcvtutf7.o ../unxlngi6.pro/slo/tcvtutf8.o 
../unxlngi6.pro/slo/tenchelp.o ../unxlngi6.pro/slo/tencinfo.o 
../unxlngi6.pro/slo/textcvt.o ../unxlngi6.pro/slo/textenc.o 
../unxlngi6.pro/slo/unichars.o -Wl,--as-needed -ldl -lm -Wl,--no-as-needed

../unxlngi6.pro/slo/semaphor.o: In function `osl_releaseSemaphore':
semaphor.c:(.text+0x20): undefined reference to `sem_post'
../unxlngi6.pro/slo/semaphor.o: In function `osl_tryToAcquireSemaphore':
semaphor.c:(.text+0x51): undefined reference to `sem_trywait'
../unxlngi6.pro/slo/semaphor.o: In function `osl_acquireSemaphore':
semaphor.c:(.text+0x82): undefined reference to `sem_wait'
../unxlngi6.pro/slo/semaphor.o: In function `osl_destroySemaphore':
semaphor.c:(.text+0xaf): undefined reference to `sem_destroy'
../unxlngi6.pro/slo/semaphor.o: In function `osl_createSemaphore':
semaphor.c:(.text+0xf0): undefined reference to `sem_init'
../unxlngi6.pro/slo/mutex.o: In function `osl_getGlobalMutex':
mutex.c:(.text+0x21): undefined reference to `pthread_once'
../unxlngi6.pro/slo/mutex.o: In function `globalMutexInitImpl':
mutex.c:(.text+0x54): undefined reference to `pthread_mutexattr_init'
mutex.c:(.text+0x65): undefined reference to `pthread_mutexattr_setkind_np'
mutex.c:(.text+0x8b): undefined reference to `pthread_mutexattr_destroy'
../unxlngi6.pro/slo/mutex.o: In function `osl_tryToAcquireMutex':
mutex.c:(.text+0xf3): undefined reference to `pthread_mutex_trylock'
../unxlngi6.pro/slo/mutex.o: In function `osl_createMutex':
mutex.c:(.text+0x193): undefined reference to `pthread_mutexattr_init'
mutex.c:(.text+0x19d): undefined 

Re: [Libreoffice] [PUSHED] Re: [PATCH 11/12] RTL_CONSTASCII_USTRINGPARAM components - zipapi

[Pierre-André Jacquod]

Hello,
I saw it too, this allow me to rize a question. My firt though was to
remove this one - since commentted out - but I left it there not knowing
if this was a way to handle this here.?

For my taste, I would have remove it. -> Debug it at home, not on public
branch... Your input?

regards


On 11/17/2010 05:39 PM, Caolán McNamara wrote:
> On Tue, 2010-11-16 at 22:50 +0100, Pierre-André Jacquod wrote:
>> regards
> 
> heh, I had a bit of a moment when I saw file:///d:/777/Encrypted/picture
> in there before I realized this is someones debugging code with an if
> (0) around it.
> 
> Anyway, that's beside the point. Your changes were good, thanks for
> them, now pushed.
> 
> C.
> 
> 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] Fwd: Re: cppcheck : snprintf size is out of bounds

[julien]

Le 17/11/2010 17:08, Caolán McNamara a écrit :


 On Fri, 2010-11-12 at 12:44 +0100, Julien wrote:


 Hello,

 I'm currently running the last version of cppcheck (i updated with git
 this morning) and i get this error :
 I don't understand where's the pb with snprintf, pString has a size of
 1024 and snprintf takes a size of 1024.

 Is this a false positive to give to the cppcheck guys ?


 Well I think so. if you replace nBezString in the sprintf line with a
 raw 1024 does it complain ?

 C.



After several tests, i noticed for these lines in
libs-gui/vcl/unx/source/printergfx/common_gfx.cxx (from line 530):
PrinterGfx::DrawPolyLineBezier (sal_uInt32 nPoints, const Point* pPath,
const BYTE* pFlgAry)
{
const sal_uInt32 nBezString = 1024;
sal_Char pString[nBezString];

if ( nPoints>  1&&  maLineColor.Is()&&  pPath )
{
PSSetColor (maLineColor);
PSSetColor ();
PSSetLineWidth ();

snprintf(pString, nBezString, "%li %li moveto\n", pPath[0].X(),
pPath[0].Y());

There's no more cppcheck errors if if i change the line :
const sal_uInt32 nBezString = 1024;

into this :
sal_uInt32 nBezString = 1024;

Before i create a tracker for cppcheck guy, i'd like to know what you
think about it ?

Julien.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] HC Image fix

[Joost Eekhoorn]

Hi

The hack work, but now my build brake in sal:
Making:libuno_sal.so.3
../unxlngx6.pro/slo/semaphor.o: In function `osl_createSemaphore':
semaphor.c:(.text+0x2a): undefined reference to `sem_init'
../unxlngx6.pro/slo/semaphor.o: In function `osl_destroySemaphore':
semaphor.c:(.text+0x6a): undefined reference to `sem_destroy'
../unxlngx6.pro/slo/semaphor.o: In function `osl_acquireSemaphore':
semaphor.c:(.text+0x9c): undefined reference to `sem_wait'
../unxlngx6.pro/slo/semaphor.o: In function `osl_tryToAcquireSemaphore':
semaphor.c:(.text+0xbc): undefined reference to `sem_trywait'
../unxlngx6.pro/slo/semaphor.o: In function `osl_releaseSemaphore':
semaphor.c:(.text+0xdc): undefined reference to `sem_post'

Maybe that I do somthing wrong in my pull and building procedure.

Joost

2010/11/17 Cédric Bosdonnat 

> Hi all and mostly Joseph,
>
> We all had to face some build error in vcl... I pushed the following
> quick hack... but I'ld like Joseph to review it and correct it if
> needed:
>
>
> http://cgit.freedesktop.org/libreoffice/libs-gui/commit/?id=a2603a2edb54f78a746e5edfba181d429727dea7
>
> Regards,
> --
> Cedric
>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Disable GCC optimizations when building with --enable-symbols

[Caolán McNamara]

On Wed, 2010-11-17 at 15:50 -0300, Santiago Bosio wrote:
> Hi!
> 
> When LibO is built using --enable-symbols, it still uses -O2 
> optimizations, making hard to debug execution with GDB.
> 
> So, I think that it should default to -O2 on a normal build, and to -O0 
> when using --enable-symbols. 

I'm not a fan of that idea really. I'd prefer to retain the
--enable-debug option as the one that sets -O0 and leave
--enable-symbols as -g and not touching the -O2.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] HC Image fix

[Cédric Bosdonnat]

Hi all and mostly Joseph,

We all had to face some build error in vcl... I pushed the following
quick hack... but I'ld like Joseph to review it and correct it if
needed:

http://cgit.freedesktop.org/libreoffice/libs-gui/commit/?id=a2603a2edb54f78a746e5edfba181d429727dea7

Regards,
--
Cedric

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] 5 times LGPL installed

[Tor Lillqvist]

>>  I disagree here. odt is the native format of LibO.
> 
> In what way?

This is indeed just a question, BTW. See the question mark.

I am open to convincing arguments that ODF really is in some clear sense the 
native format of OOo/LibO, for instance if the structure of an ODF document 
corresponds closely to the internal data structures. Does it?

(Although in that case, I don't really see how people can yell/laugh at 
Microsoft for their "native" formats being in the same fashion just a 
serialization of internal data structures in MS Office...) (Note that this is a 
technical comparison only. Originally, the MS formats of course were not 
publicly documented and thus inherently "evil".)

--tml


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] 5 times LGPL installed

[Juan Pablo Arias]

I think it doesn't matter if it's the native format or not, the issue here
is that LO ships with 5 copies of the LGPL. In my opinion, just leave the
clear text one, and delete the others, like Robert Nagy suggested.

Juan

2010/11/17 Tor Lillqvist 

> > I disagree here. odt is the native format of LibO.
>
> In what way? (That it "warns" if you save in a non-ODF format doesn't
> count, that's marketing.)
>
> --tml
>
>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] 5 times LGPL installed

[Tor Lillqvist]

> I disagree here. odt is the native format of LibO.

In what way? (That it "warns" if you save in a non-ODF format doesn't count, 
that's marketing.)

--tml


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] setting ulimit before running soffice

[Kevin Hunter]

At 11:07am -0500 Wed, 17 Nov 2010, Caolán McNamara wrote:

Am I the only one seeing this error?  If yes, then does this imply
that others are running as root?


Nah, I don't run as root ulimit -c unlimited works fine. I'd guess
that there some hard limits set that ordinary users aren't allowed
to override set for you.


Thanks.  I suppose it's an Ubuntu thing then.  I've used ulimit files 
minimally in my career thus far.  I suppose I'll get some practice this 
go round ...


Cheers,

Kevin

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] Disable GCC optimizations when building with --enable-symbols

[Santiago Bosio]

Hi!

When LibO is built using --enable-symbols, it still uses -O2 
optimizations, making hard to debug execution with GDB.


So, I think that it should default to -O2 on a normal build, and to -O0 
when using --enable-symbols. Don't see the point of using optimizations 
when building a version for debugging purposes.


I'm not clever enough to know what magic lines should be changed on 
autogen.sh or configure to get this done, so currently I'm exporting 
CFLAGS before calling autogen.sh and make to disable optimizations.


Perhaps, somebody with a deeper knowledge of autotools or configure 
script could change this behaviour and commit it?


Best regards,

Santiago
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Fwd: Re: [PATCH] Use a generic unxgcc.mk

[Kohei Yoshida]

On Wed, 2010-11-17 at 17:18 +0100, René Kjellerup wrote:

> 
> Why the oracle copyright notice in the new file too?
> Shouldn't they have a TDF notice instead ?

Yes, for new files, we should use the following header notice.

/*
 * Version: MPL 1.1 / GPLv3+ / LGPLv3+
 *
 * The contents of this file are subject to the Mozilla Public License Version
 * 1.1 (the "License"); you may not use this file except in compliance with
 * the License. You may obtain a copy of the License at
 * http://www.mozilla.org/MPL/
 *
 * Software distributed under the License is distributed on an "AS IS" basis,
 * WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
 * for the specific language governing rights and limitations under the
 * License.
 *
 * The Initial Developer of the Original Code is
 *   [ insert your name / company etc. here eg. Jim Bob  ]
 * Portions created by the Initial Developer are Copyright (C) 2010 the
 * Initial Developer. All Rights Reserved.
 *
 * Contributor(s): Jim Bob 
 * Ted 
 *
 * Alternatively, the contents of this file may be used under the terms of
 * either the GNU General Public License Version 3 or later (the "GPLv3+"), or
 * the GNU Lesser General Public License Version 3 or later (the "LGPLv3+"),
 * in which case the provisions of the GPLv3+ or the LGPLv3+ are applicable
 * instead of those above.
 */

with (obviously) the name of the developer(s) being you.

This header boilerplate is also available as COPYING.NEWFILES at the
root of the build repository.

http://cgit.freedesktop.org/libreoffice/build/tree/COPYING.NEWFILES

Kohei

-- 
Kohei Yoshida, LibreOffice hacker, Calc


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PATCH] Use a generic unxgcc.mk

[Caolán McNamara]

On Wed, 2010-11-17 at 15:33 +, Caolán McNamara wrote:
> On Wed, 2010-11-17 at 15:13 +0100, Robert Nagy wrote:
> > Move unxlng.mk to unxgcc.mk and use that on OpenBSD and Linux
> > too as a default and then overwrite or add variables.
> 
> Oh good, wanted to unify those things. As far as I can see it looks
> good, Linux is building for me at the moment and it all seems ok.

Built, passed smoketest. Looks good, feel free to push IMO

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Examing unicode strings in gdb (while debugging LibO)

[Caolán McNamara]

On Wed, 2010-11-17 at 17:17 +0100, Giuseppe Castagno wrote:
> Hi all,
> 
> I remember there was a way to examine in human readable way a Unicode 
> string in OOo.
> 
> It should be the same in LibO, but, alas :-(, I don't remember how.
> 
> Does somebody remember how?

print dbg_dump(string)

should (in theory) generally work with rtl::OUString,rtl::OString,String
and ByteString, etc.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Fwd: Re: [PATCH] Use a generic unxgcc.mk

[Wols Lists]

On 17/11/10 16:18, René Kjellerup wrote:
>
> sent from my phone
>
> -- Forwarded message --
> From: "René Kjellerup"  >
> Date: Nov 17, 2010 5:17 PM
> Subject: Re: [Libreoffice] [PATCH] Use a generic unxgcc.mk
> 
> To: "Caolán McNamara" mailto:caol...@redhat.com>>
>
> Why the oracle copyright notice in the new file too?
> Shouldn't they have a TDF notice instead ?
>

The whole point of a copyright notice is to say who *OWNS* the
copyright, and the date of that ownership.

Just because TDF has forked OOo doesn't mean we now legally own it.
>
> Just asking
>

Doing as you suggest (removing the Oracle notice) is actually
*illegal*!!! (unless we remove all the Oracle-owned code at the same
time :-) If you don't know what you're doing, you should NEVER alter a
copyright notice - just add a new one claiming your own copyright on the
code you yourself wrote and added.

Whoops - just noticed what you said about "new" file. If it truly is
new, then no it shouldn't have an Oracle notice. However, I get the
impression that it's actually just a rename, so no, legally it isn't new.
>
> Regards
> René
>
>
Cheers,
Wol
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PUSHED] Re: [PATCH 12/12] RTL_CONSTASCII_USTRINGPARAM in components - xmlsecurity- helpd

[Caolán McNamara]

On Tue, 2010-11-16 at 22:51 +0100, Pierre-André Jacquod wrote:
> regards


Looks good, thanks for this. I pushed this, though with some slight
modifications. 

When I see
foo = rtl::OUString::createFromAscii("")
I think I prefer just
foo = rtl::OUString();
as the replacement. I reckon its simpler and more to the point.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PUSHED] Re: [PATCH 11/12] RTL_CONSTASCII_USTRINGPARAM components - zipapi

[Caolán McNamara]

On Tue, 2010-11-16 at 22:50 +0100, Pierre-André Jacquod wrote:
> regards

heh, I had a bit of a moment when I saw file:///d:/777/Encrypted/picture
in there before I realized this is someones debugging code with an if
(0) around it.

Anyway, that's beside the point. Your changes were good, thanks for
them, now pushed.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PUSHED] Re: [PATCH 10/12] RTL_CONSTASCII_USTRINGPARAM components - zippackage

[Caolán McNamara]

On Tue, 2010-11-16 at 22:50 +0100, Pierre-André Jacquod wrote:
> regards

Yup, also looks good, thanks for your efforts. Pushed.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PUSHED] Re: [PATCH 09/12] RTL_CONSTASCII_USTRINGPARAM in components - xstor

[Caolán McNamara]

On Tue, 2010-11-16 at 22:49 +0100, Pierre-André Jacquod wrote:
> regards

Looks good, thanks for this, Pushed.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PUSHED] Re: [PATCH 08/12] RTL_CONSTASCII_USTRINGPARAM in components misc

[Caolán McNamara]

On Tue, 2010-11-16 at 22:49 +0100, Pierre-André Jacquod wrote:
> regards

Looks good, thanks for this. Pushed.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PUSHED] Re: [PATCH 07/12] RTL_CONSTASCII_USTRINGPARAM components in runtime

[Caolán McNamara]

On Tue, 2010-11-16 at 22:48 +0100, Pierre-André Jacquod wrote:
> regards

Looks good, thanks for this. Pushed.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PUSHED] Re: [PATCH 06/12] RTL_CONSTASCII_USTRINGPARAM components xpathlib

[Caolán McNamara]

On Tue, 2010-11-16 at 22:47 +0100, Pierre-André Jacquod wrote:
> regards

All looks good, thanks for this. Pushed, though I made the same syntax
simplifications for constructors as on patch 1 before pushing.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PUSHED] Re: [PATCH 05/12] RTL_CONSTASCII_USTRINGPARAM in components .. submission

[Caolán McNamara]

On Tue, 2010-11-16 at 22:47 +0100, Pierre-André Jacquod wrote:
> regards

All looks good, pushed, thanks for this.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PUSHED] Re: [PATCH 04/12] RTL_CONSTASCII_USTRINGPARAM in components - inc

[Caolán McNamara]

On Tue, 2010-11-16 at 22:46 +0100, Pierre-André Jacquod wrote:
> regards

All looks good, pushed, thanks for this.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PUSHED] Re: [PATCH 03/12] RTL_CONSTASCII_USTRINGPARAM in components - forms

[Caolán McNamara]

On Tue, 2010-11-16 at 22:45 +0100, Pierre-André Jacquod wrote:
> regards

Looks good, thanks for this, now pushed.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PUSHED] Re: [PATCH 02/12] RTL_CONSTASCII_USTRINGPARAM in components cui options

[Caolán McNamara]

On Tue, 2010-11-16 at 22:39 +0100, Pierre-André Jacquod wrote:
> On 11/16/2010 10:37 PM, Pierre-André Jacquod wrote:
> > Hello,
> > being off for some days, here the collection of patches I produced in
> > between.

Mostly good, but careful here, see...

-aAutoStr += ::rtl::OUString::createFromAscii( " (" );
+aAutoStr += ::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("(") );

you changed the string by accident from a bracket with a preceding space
to one with no preceding space, clearly what's between "" has to remain
the same :-). Fixed that typo and the rest looks good, pushed.

C.


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] Fwd: Re: [PATCH] Use a generic unxgcc.mk

[René Kjellerup]

sent from my phone
-- Forwarded message --
From: "René Kjellerup" 
Date: Nov 17, 2010 5:17 PM
Subject: Re: [Libreoffice] [PATCH] Use a generic unxgcc.mk
To: "Caolán McNamara" 

Why the oracle copyright notice in the new file too?
Shouldn't they have a TDF notice instead ?

Just asking

Regards
René
On Nov 17, 2010 4:33 PM, "Caolán McNamara"  wrote:
> On Wed, 2010-11-17 at 15:13 +0100, Robert Nagy wrote:
>> Move unxlng.mk to unxgcc.mk and use that on OpenBSD and Linux
>> too as a default and then overwrite or add variables.
>
> Oh good, wanted to unify those things. As far as I can see it looks
> good, Linux is building for me at the moment and it all seems ok.
>
> C.
>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] Examing unicode strings in gdb (while debugging LibO)

[Giuseppe Castagno]

Hi all,

I remember there was a way to examine in human readable way a Unicode 
string in OOo.


It should be the same in LibO, but, alas :-(, I don't remember how.

Does somebody remember how?

TIA.

beppec56.

--
Kind Regards,
Giuseppe Castagno
Acca Esse http://www.acca-esse.eu
giuseppe.castagno at acca-esse.eu
beppec56 at openoffice.org
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PUSHED] Re: [PATCH 01/12] RTL_CONSTASCII_USTRINGPARAM in components/cui/...option

[Caolán McNamara]

On Tue, 2010-11-16 at 22:37 +0100, Pierre-André Jacquod wrote:
> Hello,
> being off for some days, here the collection of patches I produced in
> between. 

Looks good, thanks for this, pushed, though with a few tiny mods, i.e. I
prefer, when we end up with e.g.

static ::rtl::OUString s_sNodeName
(::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("FOO") ) );

to simplify the syntax of constructors to just

static ::rtl::OUString s_sNodeName (RTL_CONSTASCII_USTRINGPARAM("FOO"));

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] cppcheck : snprintf size is out of bounds

[Caolán McNamara]

On Fri, 2010-11-12 at 12:44 +0100, Julien wrote:
> Hello,
> 
> I'm currently running the last version of cppcheck (i updated with git 
> this morning) and i get this error :
> I don't understand where's the pb with snprintf, pString has a size of 
> 1024 and snprintf takes a size of 1024.
> 
> Is this a false positive to give to the cppcheck guys ?

Well I think so. if you replace nBezString in the sprintf line with a
raw 1024 does it complain ?

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] setting ulimit before running soffice

[Caolán McNamara]

On Wed, 2010-11-17 at 10:57 -0500, Kevin Hunter wrote:
> Hullo List,
> 
> What's the story with the ulimit set in 'ooenv' right before running a 
> freshly built LO:

ulimit -c unlimited is supposed to give core dumps on a crash, unlimited
in size

> Am I the only one seeing this error?  If yes, then does this imply that 
> others are running as root?

Nah, I don't run as root ulimit -c unlimited works fine. I'd guess that
there some hard limits set that ordinary users aren't allowed to
override set for you.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] setting ulimit before running soffice

[Kevin Hunter]

Hullo List,

What's the story with the ulimit set in 'ooenv' right before running a 
freshly built LO:


$ cd install/program/

$ ./soffice
ulimit: 5: error setting limit (Operation not permitted)

 [LO running]

$

Am I the only one seeing this error?  If yes, then does this imply that 
others are running as root?


Kevin
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] 5 times LGPL installed

[Robert Nagy]

What I meant was, remove the .odt and make the menu
open the cleartext one.

On (2010-11-17 16:18), Robert Nagy wrote:
> Well remove it from the menu then.
> 
> On (2010-11-17 16:15), Rene Engelhard wrote:
> > On Wed, Nov 17, 2010 at 03:46:23PM +0100, Robert Nagy wrote:
> > > Just keep the plaintext one and kill the odt and
> > > the html ones. They are useless.
> > 
> > That's no true, the odt is used by the menu.
> > 
> > Grüße/Regards,
> > 
> > René
> > ___
> > LibreOffice mailing list
> > LibreOffice@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/libreoffice
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PATCH] Use a generic unxgcc.mk

[Caolán McNamara]

On Wed, 2010-11-17 at 15:13 +0100, Robert Nagy wrote:
> Move unxlng.mk to unxgcc.mk and use that on OpenBSD and Linux
> too as a default and then overwrite or add variables.

Oh good, wanted to unify those things. As far as I can see it looks
good, Linux is building for me at the moment and it all seems ok.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] 5 times LGPL installed

[Robert Nagy]

Well remove it from the menu then.

On (2010-11-17 16:15), Rene Engelhard wrote:
> On Wed, Nov 17, 2010 at 03:46:23PM +0100, Robert Nagy wrote:
> > Just keep the plaintext one and kill the odt and
> > the html ones. They are useless.
> 
> That's no true, the odt is used by the menu.
> 
> Grüße/Regards,
> 
> René
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] 5 times LGPL installed

[Rene Engelhard]

On Wed, Nov 17, 2010 at 03:46:23PM +0100, Robert Nagy wrote:
> Just keep the plaintext one and kill the odt and
> the html ones. They are useless.

That's no true, the odt is used by the menu.

Grüße/Regards,

René
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [UX] Progress bars - convey "this make take some time, dunno how long"

[Thorsten Behrens]

Hi,

chatting with some folks yesterday at the OOo congress for business
and administration, and two users approached me with a problem most
prevalent when saving to network volumes:

LibO save progress bars are basically driven by the xml export code
(when saving to odf, of course), but there's some non-trivial
postprocessing happening inside
sfx2/source/doc/objstor.cxx:SaveTo_Impl(), some of which is bound to
IO. The observed behaviour thusly, when saving to a slowish network
volume, is that the save progress bar is stuck at 100% (because all
xml content is written), but the apps are still unresponsive
(sometimes for a minute or so).

Changing SaveTo_Impl() to use async IO is prolly out of scope for
3.3, so another workaround would be to keep the progress bar from
reaching 100% before all work is finished - see attached patches 
for a sketchy attempt. Problem here: the progress bar will not move
either way, it's just not stuck at 100%, but at 90% now.

Any UX insight on how to best get this across? 

Cheers,

-- Thorsten
diff --git a/sc/source/filter/xml/xmlexprt.cxx b/sc/source/filter/xml/xmlexprt.cxx
index e160861..102068a 100644
--- a/sc/source/filter/xml/xmlexprt.cxx
+++ b/sc/source/filter/xml/xmlexprt.cxx
@@ -730,7 +730,8 @@ void ScXMLExport::CollectSharedData(sal_Int32& nTableCount, sal_Int32& nShapesCo
 }
 }
 sal_Int32 nRef(nCellCount + (2 * nTableCount) + (2 * nShapesCount));
-GetProgressBarHelper()->SetReference(nRef);
+// leave ~10% for zip swappage
+GetProgressBarHelper()->SetReference(nRef*10/9);
 GetProgressBarHelper()->SetValue(0);
 }
 
diff --git a/xmloff/source/draw/sdxmlexp.cxx b/xmloff/source/draw/sdxmlexp.cxx
index 82d6078..5868fab 100644
--- a/xmloff/source/draw/sdxmlexp.cxx
+++ b/xmloff/source/draw/sdxmlexp.cxx
@@ -620,8 +620,9 @@ void SAL_CALL SdXMLExport::setSourceDocument( const Reference< lang::XComponent
 }
 }
 
-// #82003# init progress bar
-GetProgressBarHelper()->SetReference(mnObjectCount);
+// #82003# init progress bar - leave ~10% of progress for
+// final zip swappage
+GetProgressBarHelper()->SetReference(std::max(mnObjectCount*10/9,sal_uInt32(1)));
 }
 
 // add namespaces
diff --git a/sw/source/filter/xml/xmlexp.cxx b/sw/source/filter/xml/xmlexp.cxx
index ba0bde7..117fd28 100644
--- a/sw/source/filter/xml/xmlexp.cxx
+++ b/sw/source/filter/xml/xmlexp.cxx
@@ -325,7 +325,8 @@ sal_uInt32 SwXMLExport::exportDoc( enum XMLTokenEnum eClass )
 nRef *= 2; // for the above styles, xmloff will increment by 2!
 // #i93174#: count all paragraphs for the progress bar
 nRef += aDocStat.nAllPara; // 1: only content, no autostyle
-pProgress->SetReference( nRef );
+// leave ~10% for zip swappage
+pProgress->SetReference( nRef*10/9 );
 pProgress->SetValue( 0 );
 }
 }


pgpl0367UBNj8.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] 5 times LGPL installed

[Robert Nagy]

Just keep the plaintext one and kill the odt and
the html ones. They are useless.

On (2010-11-17 15:37), Sebastian Spaeth wrote:
> We use up 3 MB in order to copy the LGPL 5 times in my LO install
> folder. I know we care about obeying to licensing, but isn't that a bit
> over the top? And I guess that if I installed more languages I would get
> it even more often...
> 
> .: 
> 164K LICENSE.odt 629K LICENSE.html 419K LICENSE
> licenses: 
> 629K LICENSE_en-US.html 419K LICENSE_en-US
> 
> Sebastian
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] 5 times LGPL installed

[Sebastian Spaeth]

We use up 3 MB in order to copy the LGPL 5 times in my LO install
folder. I know we care about obeying to licensing, but isn't that a bit
over the top? And I guess that if I installed more languages I would get
it even more often...

.: 
164K LICENSE.odt 629K LICENSE.html 419K LICENSE
licenses: 
629K LICENSE_en-US.html 419K LICENSE_en-US

Sebastian
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PATCH] Use a generic unxgcc.mk

[Robert Nagy]

Move unxlng.mk to unxgcc.mk and use that on OpenBSD and Linux
too as a default and then overwrite or add variables.
---
 solenv/inc/unxgcc.mk  |  279 +
 solenv/inc/unxlng.mk  |  253 +---
 solenv/inc/unxobsd.mk |  229 +
 3 files changed, 284 insertions(+), 477 deletions(-)
 create mode 100644 solenv/inc/unxgcc.mk

diff --git a/solenv/inc/unxgcc.mk b/solenv/inc/unxgcc.mk
new file mode 100644
index 000..b54736c
--- /dev/null
+++ b/solenv/inc/unxgcc.mk
@@ -0,0 +1,279 @@
+#*
+#
+# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+# 
+# Copyright 2000, 2010 Oracle and/or its affiliates.
+#
+# OpenOffice.org - a multi-platform office productivity suite
+#
+# This file is part of OpenOffice.org.
+#
+# OpenOffice.org is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Lesser General Public License version 3
+# only, as published by the Free Software Foundation.
+#
+# OpenOffice.org is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Lesser General Public License version 3 for more details
+# (a copy is included in the LICENSE file that accompanied this code).
+#
+# You should have received a copy of the GNU Lesser General Public License
+# version 3 along with OpenOffice.org.  If not, see
+# 
+# for a copy of the LGPLv3 License.
+#
+#*
+
+# generic mk file for gcc on unix systems
+
+ASM*=
+AFLAGS*=
+SOLAR_JAVA*=
+# default optimization level for product code
+CDEFAULTOPT*=-O2
+# architecture dependent flags for the C and C++ compiler that can be changed 
by
+# exporting the variable ARCH_FLAGS="..." in the shell, which is used to start 
build
+ARCH_FLAGS*=
+# position independent code switch
+PICSWITCH*:=-fpic
+JAVAFLAGSDEBUG=-g
+
+# filter for supressing verbose messages from linker
+#not needed at the moment
+#LINKOUTPUT_FILTER=" |& $(SOLARENV)/bin/msg_filter"
+
+# _PTHREADS is needed for the stl
+CDEFS+=-D_PTHREADS -D_REENTRANT -DNEW_SOLAR -D_USE_NAMESPACE=1 
-DSTLPORT_VERSION=$(STLPORT_VER)
+
+# enable visibility define in "sal/types.h"
+.IF "$(HAVE_GCC_VISIBILITY_FEATURE)" == "TRUE"
+CDEFS += -DHAVE_GCC_VISIBILITY_FEATURE
+.ENDIF # "$(HAVE_GCC_VISIBILITY_FEATURE)" == "TRUE"
+
+# this is a platform with JAVA support
+.IF "$(SOLAR_JAVA)"!=""
+JAVADEF=-DSOLAR_JAVA
+.IF "$(debug)"==""
+JAVA_RUNTIME=-ljava
+.ELSE
+JAVA_RUNTIME=-ljava_g
+.ENDIF
+.ENDIF
+
+# name of C++ Compiler
+CXX*=g++
+# name of C Compiler
+CC*=gcc
+.IF "$(SYSBASE)"!=""
+CFLAGS_SYSBASE:=-isystem $(SYSBASE)$/usr$/include
+CXX+:=$(CFLAGS_SYSBASE)
+CC+:=$(CFLAGS_SYSBASE)
+.ENDIF  # "$(SYSBASE)"!=""
+CFLAGS+=-fmessage-length=0 -c
+
+# flags to enable build with symbols; required for crashdump feature
+.IF "$(ENABLE_SYMBOLS)"=="SMALL"
+CFLAGSENABLESYMBOLS=-g1
+.ELSE
+CFLAGSENABLESYMBOLS=-g # was temporarily commented out, reenabled before Beta
+
+.ENDIF
+
+# flags for the C++ Compiler
+CFLAGSCC= -pipe $(ARCH_FLAGS)
+# Flags for enabling exception handling
+CFLAGSEXCEPTIONS=-fexceptions -fno-enforce-eh-specs
+# Flags for disabling exception handling
+CFLAGS_NO_EXCEPTIONS=-fno-exceptions
+
+# -fpermissive should be removed as soon as possible
+CFLAGSCXX= -pipe $(ARCH_FLAGS)
+.IF "$(HAVE_GCC_VISIBILITY_FEATURE)" == "TRUE"
+CFLAGSCXX += -fvisibility-inlines-hidden
+.ENDIF # "$(HAVE_GCC_VISIBILITY_FEATURE)" == "TRUE"
+
+CFLAGS_CREATE_PCH=-x c++-header -I$(INCPCH) -DPRECOMPILED_HEADERS
+CFLAGS_USE_PCH=-I$(SLO)$/pch -DPRECOMPILED_HEADERS -Winvalid-pch
+CFLAGS_USE_EXCEPTIONS_PCH=-I$(SLO)$/pch_ex -DPRECOMPILED_HEADERS -Winvalid-pch
+
+# Compiler flags for compiling static object in multi threaded environment 
with graphical user interface
+CFLAGSOBJGUIMT=
+# Compiler flags for compiling static object in multi threaded environment 
with character user interface
+CFLAGSOBJCUIMT=
+# Compiler flags for compiling shared object in multi threaded environment 
with graphical user interface
+CFLAGSSLOGUIMT=$(PICSWITCH)
+# Compiler flags for compiling shared object in multi threaded environment 
with character user interface
+CFLAGSSLOCUIMT=$(PICSWITCH)
+# Compiler flags for profiling
+CFLAGSPROF=
+# Compiler flags for debugging
+CFLAGSDEBUG=-g
+CFLAGSDBGUTIL=
+# Compiler flags for enabling optimizations
+.IF "$(PRODUCT)"!=""
+CFLAGSOPT=$(CDEFAULTOPT) # optimizing for products
+
+GCCNUMVERSION_CMD=-dumpversion $(PIPEERROR) $(AWK) -v num=true -f 
$(SOLARENV)/bin/getcompver.awk
+GCCNUMVER:=$(shell @-$(CXX) $(GCCNUMVERSION_CMD))
+
+.IF "$(USE_SYSTEM_STL)"!="YES" || "$(GCCNUMVER)" <= "00040005"
+#STLPort headers are full of aliasing warnings and
+#At least SLED 10.2 gc

Re: [Libreoffice] Icons

[Sebastian Spaeth]

On Tue, 16 Nov 2010 19:54:17 +, "Andrew C. E. Dent" wrote:
> * brand/shell * Still in Default (not sure if this is used? Would suggest 
> deletion...):backing_hc-pt_BR.png , backing_right_hc-pt_BR.png
> All artwork in hicontrast is just stock (not hc). I have created a HC 
> replacement (just hacked together), that saves 53.5KB > 0.8KB! Download 
> here:http://people.bath.ac.uk/ea2aced/OOo/Backing_HC.zip

Deleted the identical HC ones. Did not take your HC version, as someone
should make a decision whether we need a HC logo on that one, I guess.

> * chart2 * Move 7x HC icons from Default to hicontrast:dataeditor_icon_h0*.png

done
> * dbaccess * Delete two extra icons from hicontrast:sx03187.png
> , sx16670.png

Done
> * framework *Replace Branding images in hicontrast as 
> before:http://people.bath.ac.uk/ea2aced/OOo/Backing_HC.zip

Why is that duplicated in the first place? I have simply deleted the
highcontrast ones for now as they are identical with the normal ones.

> * res * In hicontrast, delete 6x stock filetype icons:od*_32.pngThese are 
> something we probably want to eventually replace with proper HC icons when 
> the final 

Done

> * sfx2 * Move closedochc.png

done
> * svx/source/svdraw * From Default, move over (and check this doesn't break 
> LibO!):cropmarkersACC.png , markersACC.png

requires code changes, so not done yet. Filed a bug so I don't forget it.

> * toolkit/source/awt *From Default, move over 12x HC spinner 
> images:spinner03-32-hc_0*.png

done
> * vcl * Move closedochc.png

done

> * General *Remove all Placeholder icons (Red cross on Yellow square) from 
> hicontrast theme. They have not been stripped from Default yet, but we might 
> as well cleanup here anyway. They may be 122, 161 or 170  bytes. Can be found 
> in (but may not be limited to...):res/ and res/commandimagelist/

not done yet, if someone comes up with a file list of those that would
be appreciated.

I will rebuild LO first from scratch to make sure that moving the icons
over doesn't break anything and will commit then.

Thanks!
Sebatian
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] presenterconsole in writer ? ...

[Tor Lillqvist]

Oh, so there is nothing Windows-specific in this problem then?

--tml


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] presenterconsole in writer ? ...

[Thorsten Behrens]

Michael Meeks wrote:
>   Any volunteer interesting in debugging that ? one good way would be to
> put a breakpoint in osl_psz_loadModule - and just stepping through until
> we hit the one that pulls it in, grabbing a backtrace and posting it for
> this module ;-)
> 
There's an initial patch for that:
framework-extra-job-config.diff (in patches/dev300 of course)

(see the comments in the ooo issue - the fix could have some extra
love, any help / input appreciated)

Cheers,

-- Thorsten


pgpRdOT3OAbXw.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] presenterconsole in writer ? ...

[Tor Lillqvist]

I can't see this in a fresh build of the libreoffice-3-3 branch, so possibly it 
was something that has been fixed in the latest OOo milestones and merged in?

--tml

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] RID_FRENCH_50_NAMES and RID_FRENCH_60_NAMES

[Caolán McNamara]

On Mon, 2010-11-15 at 21:49 -0300, Júlio Hoffimann wrote:
> Hi,
> 
> 
> I'm finishing a patch to add portuguese labels for symbols in
> starmath. In the file "symbol.src" exists two lists of labels for each
> language:
> 
> 
> RID_FRENCH_50_NAMES
> RID_FRENCH_60_NAMES
> 
> 
> RID_ITALIAN_50_NAMES
> RID_ITALIAN_60_NAMES

The "50" and "60" here refer to basically "StarOffice 5" and "StarOffice
6". You don't want to add anything here. i.e. no RID_PORTUGUESE_50 or
_60 names. I'm reliably informed that these exist only to replace
localized strings which made their way into the equation text of some
older localized versions of StarOffice 5.X and 6.X. In modern version
the text is always physically saved as the "canonical" english equation
text (the entries in RID_EXPORT_SYMBOL_NAMES).

So ignore those, don't add any 50/60 new ones, and just translate the
RID_UI_SYMBOL_NAMEs etc.

C.


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Icons

[Sebastian Spaeth]

On Tue, 16 Nov 2010 15:15:39 +, "Andrew C. E. Dent" wrote:
> I think the Classic theme should no longer be shipped, in the same way we 
> dropped Industrial. 
> 
> I also can not see the point of including Oxygen, with less than 1% of 
> original artwork...

I'll defer decisions as to which icon themes to include and which not to
the steering committee, or someone else. But I'd agree, *we* should
probably not ship that many themes by default (especially if
incomplete). (What Linux distros include and do is up to them.)

Sebastian


pgp3HVsFy8r9a.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Crash while closing the document (with fix)

[Caolán McNamara]

On Tue, 2010-11-16 at 23:29 -0500, Andriy Rysin wrote:
> There's a OOo bug
> http://www.openoffice.org/issues/show_bug.cgi?id=84159 which describes
> a crash happening if document has too much formatting. This also
> applies to LO. It usually happens at closing the document but can also
> happen at some other (almost) random times.

This is the classic overflow in the 16bit property count. including the
infamous AndrewMacro.odt.

Its very tempting to bring it in. On the other hand though, it is a
rather large amount of somewhat fundamental change to introduce during
the 3.3 stabilization time. 

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice