Re: [Libreoffice] Revert some changing from last commit
On Sun, Feb 27, 2011 at 09:18:14PM +0100, Xisco Faulí wrote: > In a previous commit, OSL_ASSERT were changed into OSL_FAIL but 2 of them > created the build fail. No, these changes are correct. You are probably missing the definition of OSL_FAIL (which I added over the weekend), in which case you should update ure repo and rebuild and redeliver sal. I.e., bash . Linux*Env.Set.sh cd sal git pull -r build && deliver exit If this is not the problem, I am very interested in the actual error message. D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Compilation failed in libs-gui/toolkit
On Sun, Feb 27, 2011 at 01:31:36PM +0100, Julien Nabet wrote:
> Hello,
>
> I've got a compilation error in libs-gui/toolkit.
> Entering /home/maryline/compile-libreoffice/libo/toolkit/uiconfig/layout
>
> dmake: Warning: -- Found file corresponding to virtual target
> [message-box.xml].
> dmake: Warning: -- Found file corresponding to virtual target
> [tab-dialog.xml].
> mkdir: cannot create directory `../../unxlngi6.pro/lib/en-US/': File exists
> ../../unxlngi6.pro/lib/en-US/%.xml: %.xml
> : &&
> LD_LIBRARY_PATH=${LD_LIBRARY_PATH+${LD_LIBRARY_PATH}:}/home/maryline/compile-libreoffice/libo/solver/330/unxlngi6.pro/lib
> tralay -m localize.sdf -o "../../unxlngi6.pro/lib" -l en-US
> "message-box.xml"
> /bin/bash: tralay: command not found
> dmake: Error code 127, while making
> '../../unxlngi6.pro/lib/en-US/message-box.xml'
tralay was called without path. Should be fixed now.
D.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 34404] LibreOffice 3.3.2 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=34404 Andras Timar changed: What|Removed |Added Depends on||33701 --- Comment #7 from Andras Timar 2011-02-28 22:15:29 PST --- fdo#330701 - Extension Manager: "Check for Updates" – LibO crashes - frequently reported, patch exists, see https://bugs.freedesktop.org/show_bug.cgi?id=33701#c21 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Windows installer size reduction effort - the compression theory
On 28/02/11 21:51, Michael Meeks wrote: >> Why the surprise? How long has Huffman been around - 30 years? 40? And >> > you CANNOT do better than Huffman (there are other equally as good >> > algorithms, though). > Ho hum; glad to know Huffman compression is optimal ;-) (personally I'd > go for arithmetic compression with a good "guess a libreoffice" model > alogorithm to get it down to a handful of bits ;-). Notice - that ZIP is > in fact two layered compression algorithm: Lempel Ziv, and then Huffman, > it is not clear that this makes it obviously non-optimal but it is > certainly somewhat weaker in that regard. Interesting ... I checked on wikipedia after I posted and Huffman is actually SIXTY years old! Set as a class project, and published in 1952. So zip should be tricky to beat for compression if it actually uses Huffman, although I would expect it to take ages. Your figures imply either (a) zip doesn't do Huffman, or (b) bzip2 and lzma use a much larger input block size. Was the wink to say you knew it was optimal already? I thought that was common knowledge :-) although reading wikipedia it reminded me that there is a pathological case - lots of identical elements. Given that I gather Windows files contain large sections of nulls, Huffman won't like that! That's probably the main time you *do* want double-compression - some form of RLE will suppress any pathological input into Huffman. The main reason I suggested adding times to KAMI's table was that it makes explicit the time/compression tradeoff. Cheers, Wol ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Need help with failing cppunit tests
On Mon, Feb 28, 2011 at 09:26:46PM +, Caolán McNamara wrote: > On Mon, 2011-02-28 at 20:07 +0100, Francois Tigeot wrote: > > Program received signal SIGSEGV, Segmentation fault. > > 0x000801535510 in ?? () > > (gdb) bt > > #0 0x000801535510 in ?? () > > #1 0x0008010b7db9 in __cxa_finalize (dso=0x0) at > > /usr/src/lib/libc/../libc/stdlib/atexit.c:178 > > This confirms the theory anyway. Doesn't help exactly pin down the > problem, but it does point to some global dtor, or explicit > atexit/cxa_finalize handler, so, as a guess see rtl_memory_fini in > sal/source/alloc_global.c and the MACOSX entry in the corresponding > makefile.mk. If you tweak those to "do like macosx" does it make a > difference ? Unfortunately, it doesn't. All is not lost, howewer. Thanks to you, I know at least where to look for further investigations :-) -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Tools - Media Player
Hi Fernand, all! Am Freitag, den 25.02.2011, 16:01 +0100 schrieb Fernand Vanrie: > Thomas , > > No we are not placing video in odt, files, but our editors (while there > are working in writer), needs to see some video content as a "source" > for there work. Wow, that seems to be a very special case - so from my side, if the menu item can be added manually (afterwards), then it should be fine for most of the users. Of course, this might add some burden on your and your editors, but most of the other users do have some benefit ... maybe this is some kind of compensation? ;-) > But we would like to add some > video content to our Writerfiles and then transfer them to Epup or > interactive PDF's As far as I understand, that's still possible. By the way, if I can help here ... please let me know. The only downside is, that I'm still not that responsive as I would like to be :-) In such cases like "Media Player use" (especially in the not too far future), it would be nice to set up the usage data collection for LibreOffice. Then we might track the use for "our" product, since the OOo data gets old quickly ... Cheers, Christoph > > > > On 02/25/2011 12:07 PM, Fernand Vanrie wrote: > >> Please consider: We are living and working in a Multi Media world: > >> Not only who is working with Impress needs a media player, all content > >> can have mixed content and LO must be the "one stop" place to handle > >> all multi media stuff. > > I partially reverted the changes for writer. The background calls are > > there again, so anybody who needs Media Player could add this by > > customizing the menu. And I've enabled Media Player for web by default > > as this make really sense. > > > > Fernand, only for my personal interest: are you using videos in odt > > files? Maybe I'm not knowing what's possible with this ;) > > > > Thomas > > ___ > > 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] EasyHack: Improved bug filing form / flow
Hi Daniel, also from my side - thanks for having a look at the bug filing and the results created so far. It's great to see somebody picking up stuff like that to improve some "hidden" sides of LibreOffice ... If anybody wants to continue with this topic, then please CC the Design Team or me, so that we can help here (usability, text descriptions, ... Michael already provided a great proposal). Again, thanks for you work! Cheers, Christoph Am Sonntag, den 27.02.2011, 21:55 -0500 schrieb Daniel Neel: > Alrighty, I've attached the current progress to this message and will > be updating the wiki shortly. Thanks again everyone for your time. > > On Fri, Feb 25, 2011 at 9:37 AM, Jan Holesovsky wrote: > Hi Daniel, > > On 2011-02-24 at 19:37 -0500, Daniel Neel wrote: > > > I think this project is moving a bit beyond what I currently > have > > skill and time to complete with quality. I think it would be > best for > > me to pass the current work on to someone else. > > > Sorry to hear that :-( You are doing great from my point of > view, but > of course, cannot force you ;-) > > > Would the best course of action be to update the EasyHacks > page with > > a notice of the current progress on the hack, an attachment > of the > > file, and maybe a link to this mailing list conversation? I > look > > forward to helping out LO in other ways soon. > > > Yes please - the best would be to send your current work to > this mailing > list (as a mail attachment), and add the description + link to > the mail > with the attachment in the mail archive > (http://lists.freedesktop.org/archives/libreoffice/) + link to > the > entire conversation to the wiki. > > All the best, > Kendy > > ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Remove dead code
ACCESSIBLE_EVENT_NOTIFICATION_ENABLED was never define. So the #ifdef #endif
"brackets" could go away.
---
.../extended/accessibleiconchoicectrlentry.hxx | 16
.../extended/accessibleiconchoicectrlentry.cxx | 15 ---
2 files changed, 0 insertions(+), 31 deletions(-)
diff --git
a/accessibility/inc/accessibility/extended/accessibleiconchoicectrlentry.hxx
b/accessibility/inc/accessibility/extended/accessibleiconchoicectrlentry.hxx
index 3e9cec0..b2c145d 100644
--- a/accessibility/inc/accessibility/extended/accessibleiconchoicectrlentry.hxx
+++ b/accessibility/inc/accessibility/extended/accessibleiconchoicectrlentry.hxx
@@ -83,22 +83,6 @@ namespace accessibility
::com::sun::star::uno::Reference<
::com::sun::star::accessibility::XAccessible > m_xParent;
private:
-#ifdef ACCESSIBLE_EVENT_NOTIFICATION_ENABLED
-// (the following method is unused currently. If you need it, simply
remove the #ifdef thing here and
-// in the cxx)
-/** notifies all listeners that this object has changed
-@param _nEventId
-is the event id
-@param _aOldValue
-is the old value
-@param _aNewValue
-is the new value
-*/
-void NotifyAccessibleEvent( sal_Int16 _nEventId,
- const ::com::sun::star::uno::Any&
_aOldValue,
- const ::com::sun::star::uno::Any&
_aNewValue );
-#endif
-
Rectangle GetBoundingBox_Impl() const;
Rectangle GetBoundingBoxOnScreen_Impl()
const;
sal_Bool IsAlive_Impl() const;
diff --git a/accessibility/source/extended/accessibleiconchoicectrlentry.cxx
b/accessibility/source/extended/accessibleiconchoicectrlentry.cxx
index 6a613de..791d89a 100644
--- a/accessibility/source/extended/accessibleiconchoicectrlentry.cxx
+++ b/accessibility/source/extended/accessibleiconchoicectrlentry.cxx
@@ -122,21 +122,6 @@ throw(RuntimeException)
dispose();
}
}
-#ifdef ACCESSIBLE_EVENT_NOTIFICATION_ENABLED
-// (the following method is unused currently. If you need it, simply
remove the #ifdef thing here and
-// in the hxx)
-//
-
-void AccessibleIconChoiceCtrlEntry::NotifyAccessibleEvent( sal_Int16
_nEventId,
- const
::com::sun::star::uno::Any& _aOldValue,
- const
::com::sun::star::uno::Any& _aNewValue )
-{
-Reference< uno::XInterface > xSource( *this );
-AccessibleEventObject aEventObj( xSource, _nEventId, _aNewValue,
_aOldValue );
-
-if (m_nClientId)
-comphelper::AccessibleEventNotifier::addEvent( m_nClientId,
aEventObj );
-}
-#endif
//
-
Rectangle AccessibleIconChoiceCtrlEntry::GetBoundingBox_Impl() const
{
--
1.7.1
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Windows installer size reduction effort - the compression theory
Hi Wols,
On Mon, 2011-02-28 at 18:04 +, Wols Lists wrote:
> > So - personally, I find it amazing that ZIP is better than LZMA - ever,
> > it is such an older compression algorithm, and this flies in the face of
> > everything I've seen in practise with it [ eg. we use LZMA for our RPMs
> > in openSUSE these days AFAIR, better than bzip2, which in turn was
> > better than .tgz (essentially zip) ].
>
> Why the surprise? How long has Huffman been around - 30 years? 40? And
> you CANNOT do better than Huffman (there are other equally as good
> algorithms, though).
Ho hum; glad to know Huffman compression is optimal ;-) (personally I'd
go for arithmetic compression with a good "guess a libreoffice" model
alogorithm to get it down to a handful of bits ;-). Notice - that ZIP is
in fact two layered compression algorithm: Lempel Ziv, and then Huffman,
it is not clear that this makes it obviously non-optimal but it is
certainly somewhat weaker in that regard.
#!/usr/bin/perl -w
for (my $i = 0; $i < 1; $i++) { print "$i\n"; }
typesize
plain 48k
zip 23k
bzip2 11k
lzma3k
That is not a very representative input (of course ;-), but perhaps not
so far away from the rampant duplication we face. I would (personally)
expect to see lzma do better than plain deflate. Of course, you can
easily imagine a compression algorithm, that turns the file into just
those two lines of perl above ;-)
> Having tried to back up a hard disk over ethernet (dd if=/dev/sda
> of=//samba/archive.hdi), it was direly slow over a 10Mb card. So I tried
> to pipe it through bzip2 to speed up the transfer - it was *even*
> *slower* !
bzip2 is not fast; that is certainly so, OTOH it was far better space
wise than the deflate it replaced; this is why much source code is still
packaged as .bz2 - if you want to bend your mind, read up on the
Burrows-Wheeler transform [ FWIW ;-].
> Why do you think LZMA is better than zip - because it's faster?
More efficient. Slowness of compression we can cope with easily, as
long as decompression is fast: and for most algorithms this balance is
easyish to achieve.
> (I think we need to add compression time to KAMI's nice table :-)
As long as it is within five or so minutes of CPU time on a fast
machine, and/or preferably is multi-thread-able [ though our choice of
tools and platforms strongly limits what we can use at the cab level
anyway ] - compression time is fairly irrelevant.
ATB,
Michael.
--
michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] OString += OString + char ... ?
Le Mon, 28 Feb 2011 21:45:36 +, Caolán McNamara a écrit : > On Sun, 2011-02-27 at 04:27 -0500, Kevin Hunter wrote: > Three possibilities I guess, > > 1) remove the "explicit", but I'm sure its there due to some other > horribly implicit conversion horror > 2) add a operator+(sal_Char), either one that "just works", or one > that raises an error at compile time. > 3) remove the const sal_Char* conversion operator (I'm tempted towards > this one) If someone takes this, he/She should add a operator[](int) to allow byChar access (or a getChar method)... Sébastien signature.asc Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] OString += OString + char ... ?
On Sun, 2011-02-27 at 04:27 -0500, Kevin Hunter wrote:
> Is that + operator expected to work with an O*String and a single character?
>
> From analysis with Sébastien Le Ray, it looks like what's happening is
> that the b OString is converted to sal_Char *, and the compiler uses
> int( '\n' ) (=10) for the + operator. So, the pointer of "Gobble
> Wobble" is moved to "ble" before the += operator takes over.
>
Yeah, looks that way.
> Changing the suspect line to
>
> a += b + "\n";
Indeed, a OString can be constructed from a "const sal_Char*", which is
just a "const char*", so OString+"\n", gets...
OString operator+(const OString &, const OString&), and the
OString(const sal_Char*) ctor is used to generate the 2nd OString from
the "\n". In the other case, the OString(sal_Char) ctor is an explicit
one (i.e. a += b + OString('\n') should do the right thing), so no
OString is generated for '\n', so the other direction is tried, and
OString has a operator const sal_Char*().
This is the kind of monstrosity that has the suggestion for "explicit"
to be allowed for conversion operators in C++0x.
Three possibilities I guess,
1) remove the "explicit", but I'm sure its there due to some other
horribly implicit conversion horror
2) add a operator+(sal_Char), either one that "just works", or one that
raises an error at compile time.
3) remove the const sal_Char* conversion operator (I'm tempted towards
this one)
C.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED][PATCH]Cleanup comments
Hello, pushed, thanks, Maybe not forgetting the [patch] tag in subject will help not to miss your submission. best regards On 02/27/2011 04:51 PM, Arnaud Versini wrote: > Hi, > > This patch remove some useless comments in msfilter. > > Thanks > > -- > Arnaud Versini > > > > ___ > 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] Help here, I think I'm blinded
Guys I have something that I see a lot and do not know way someone will
use it:
//code
static WinSalMenuItem* ImplGetSalMenuItem( HMENU hMenu, UINT nPos, BOOL
bByPosition=TRUE )
{
DWORD err=0;
MENUITEMINFOW mi;
memset(&mi, 0, sizeof(mi));
mi.cbSize = sizeof( mi );
mi.fMask = MIIM_DATA;
if( !GetMenuItemInfoW( hMenu, nPos, bByPosition, &mi) )
err = GetLastError();
return (WinSalMenuItem *) mi.dwItemData;
}
//end
'err' saves some values but who uses it? I see a lot of it on the code,
local variables with attribution, and no one inside the function uses,
and no one sends the variable for others externally.
revol_
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Need help with failing cppunit tests
On Mon, 2011-02-28 at 20:07 +0100, Francois Tigeot wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x000801535510 in ?? () > (gdb) bt > #0 0x000801535510 in ?? () > #1 0x0008010b7db9 in __cxa_finalize (dso=0x0) at > /usr/src/lib/libc/../libc/stdlib/atexit.c:178 > #2 0x0008010b7a4a in exit (status=0) at > /usr/src/lib/libc/../libc/stdlib/exit.c:64 > #3 0x0040223a in _start (ap=0x7fffcd60, cleanup=0x80050ef0d > ) at /usr/src/lib/csu/x86_64/crt1.c:101 > (gdb) quit This confirms the theory anyway. Doesn't help exactly pin down the problem, but it does point to some global dtor, or explicit atexit/cxa_finalize handler, so, as a guess see rtl_memory_fini in sal/source/alloc_global.c and the MACOSX entry in the corresponding makefile.mk. If you tweak those to "do like macosx" does it make a difference ? C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] an attempt to connect LO to the unhosted web
Hi, This message is FYI, to let you know what we're doing, since it's relevant to LO. Since today I am a full-time developer of the Unhosted project. The goal of the Unhosted project is to promote a few decentralization tricks (see http://www.unhosted.org/ for details) and help bring free software to the web. Specifically, our first goal is creating an alternative to Google Docs. The first step towards this will be a proof-of-concept that explains the idea we have. The proof of concept (working title: LibreDocs) will be much like slideshare: To write the document you use LO on your desktop, but then you publish it to the unhosted web in odf format, so that people can read it online, but without the intervention of any commercial website. The idea for doing something that combines LO and Unhosted came from a conversation Charles-H. Schulz (of the Document Foundation) and I had after meeting each other at the FOSDEM conference. The unhosted odf viewer will be based almost entirely on webodf, the excellent javascript library that Jos van den Oever published recently. As I said, this email is FYI, I've only just started working on this today. I'll let you know when I have something working. It's not much use discussing it much before it exists. If you have any questions though, don't hesitate to reply to this thread, email me, or find me on IRC (michiel_unhosted, in the #unhosted channel on freenode). Cheers! Michiel. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [opensuse-announce] openSUSE 11.4 RC2 Steps Out
Le 2011-02-28 07:48, Andreas Jaeger a écrit : On Monday, February 28, 2011 11:46:03 Petr Mladek wrote: Hi Andreas, Andreas Jaeger píše v Po 28. 02. 2011 v 09:49 +0100: The transition from OpenOffice.org to LibreOffice still has a few minor documentation blips but more importantly, users should be cautious. The raft of new functionality has created a few specific issues, such as loss of data in tables. Though not quite ready for the production environment, user feedback is critical for smoothing performance and reliability. I am not aware of any data loos in tables. Could you please be more specific? Is there any bug number? Since i have not found a single bug report for this, I changed the text on news.opensuse.org for now until this gets clarified. The persons writing the text are currently travelling back from SCALE, so I cannot get a direct answer from them ;-( Andreas Thanks for doing this. Cheers Marc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] OpenSuse 11-4-rc2 claiims LibreOffice has minor bugs
Le 2011-02-28 14:09, Andrea Pescetti a écrit : Marc Paré wrote: If this is an official part of the OpenSuse project and if it is not based on facts I would like to see a retraction on their part. I have no idea from where they got their information. I must say I've seen, in non-publicly archived Italian mailing lists, reliable reports about problems with LibreOffice Writer documents containing tables. So the information is not totally made up. The "tables" the post refers to should then be read as "Writer tables", I suppose. The aforementioned discussions spawned the following bug submissions: - https://bugs.freedesktop.org/show_bug.cgi?id=33866 - https://bugs.freedesktop.org/show_bug.cgi?id=34565 - https://bugzilla.novell.com/show_bug.cgi?id=664516 all related to Writer tables; the last one leads to (what the user perceived as) data loss in Writer tables and it was marked as Critical-Urgent and recently resolved. Regards, Andrea. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Great. This just goes to show how the LibreOffice devs are listening. Could someone responds to the article? This will, at least let them know that we are taking these statements seriously. I don't know if Italo has looked into this but I had cc'd him on one of my messages. Cheers Marc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] OpenSuse 11-4-rc2 claiims LibreOffice has minor bugs
Marc Paré wrote: > If this is an official part of the OpenSuse project and if it is not > based on facts I would like to see a retraction on their part. I have no > idea from where they got their information. I must say I've seen, in non-publicly archived Italian mailing lists, reliable reports about problems with LibreOffice Writer documents containing tables. So the information is not totally made up. The "tables" the post refers to should then be read as "Writer tables", I suppose. The aforementioned discussions spawned the following bug submissions: - https://bugs.freedesktop.org/show_bug.cgi?id=33866 - https://bugs.freedesktop.org/show_bug.cgi?id=34565 - https://bugzilla.novell.com/show_bug.cgi?id=664516 all related to Writer tables; the last one leads to (what the user perceived as) data loss in Writer tables and it was marked as Critical-Urgent and recently resolved. Regards, Andrea. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Need help with failing cppunit tests
On Thu, Feb 24, 2011 at 11:56:56AM +0100, Francois Tigeot wrote:
> On Thu, Feb 24, 2011 at 10:11:46AM +, Caolán McNamara wrote:
> > On Thu, 2011-02-24 at 09:30 +0100, Francois Tigeot wrote:
> >
> With STAR_RESOURCEPATH set, gdb ends up in an eternal wait state, exactly
> like when I ran it from build.
I am now using gcc 4.4.2 (was 4.1.2) and this time gdb is a bit more useful.
The cppunit test is taken from sal/qa/OStringBuffer and is a bit simpler
than my original choice.
The command is:
LD_LIBRARY_PATH=${LD_LIBRARY_PATH+${LD_LIBRARY_PATH}:}/home/ftigeot/Projects/LibreOffice/bootstrap/clone/ure/sal/unxdflyx3.pro/lib:/home/ftigeot/Projects/LibreOffice/bootstrap/solver/330/unxdflyx3.pro/lib
../../unxdflyx3.pro/bin/cppunittester
../../unxdflyx3.pro/lib/librtl_OStringBuffer.so
(gdb) run
Starting program:
/home/ftigeot/Projects/LibreOffice/bootstrap/clone/ure/sal/unxdflyx3.pro/bin/cppunittester
../../unxdflyx3.pro/lib/librtl_OStringBuffer.so
OK (0)
Program received signal SIGSEGV, Segmentation fault.
0x000801535510 in ?? ()
(gdb) bt
#0 0x000801535510 in ?? ()
#1 0x0008010b7db9 in __cxa_finalize (dso=0x0) at
/usr/src/lib/libc/../libc/stdlib/atexit.c:178
#2 0x0008010b7a4a in exit (status=0) at
/usr/src/lib/libc/../libc/stdlib/exit.c:64
#3 0x0040223a in _start (ap=0x7fffcd60, cleanup=0x80050ef0d
) at /usr/src/lib/csu/x86_64/crt1.c:101
(gdb) quit
--
Francois Tigeot
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Voreppe Win32 Tinderbox
Hi Fridrich Thanks a lot for your work setting up this !!! I sincerrely hope it will be usefull and that other french public institutions will join the process to give ressources to our wonderfull libreOffice developpers Laurent ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Question about the debian-files of LibreOffice 3.3.1
On Mon, Feb 28, 2011 at 03:33:57PM +0100, Axel Reimer wrote: >Hello, > > > >I had a look at the debian packages of LibreOffice 3.3.1 and I recognized >that all version numbers changed from 3.3.0-19 to 3.3.1-19. Those are not the debian packages of LibreOffice 3.3.1. It's .deb files, yes, but... >But there is one package libreoffice3-ure which had the version number >1.7.0-19 in LO 3.3.0 and still has the number 1.7.0-19 in LO 3.3.1. But: >the MD5SUM of the package has changed! [...] >The problem is: When LibreOffice is installed via a repository, the >package managers do not recognize that a new version is available. This isn't true afair, apt will notice and install the new one. It at least does in some cases. But even if not, there's no repository either way so you need to install using dpkg -i either way, and that one doesn't care :) > >Is this a small issue in the 3.3.1 deb-packages or is planned that the >version number of URE does not change? That issue ic caused by using the "build version" as debian revision. As that one didn't change and won't change in the near future I guess... >If this is an issue: What will be the version number of the URE package in >3.3.2? ... I'd guess this will be still 1.7.0-19 also in 3.3.2. Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [tdf-discuss] Instant Messenger for Libre Office (serverless and open source)
On Mon, Feb 28, 2011 at 6:24 AM, Italo Vignoli wrote: > On 2/28/11 2:22 PM, Randolph Dohm wrote: > > > P.S. - The fact that our email address is on the public website is not an > implicit authorization to write. In addition, you have sent a second message > before getting any answer to the first one. As far as I am concerned, your > email is blaclisted. > > -- > Italo Vignoli - The Document Foundation Blacklisting is sorta harsh. Maybe spank the puppy with a rolled up newspaper for the first offense. Carl ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Windows installer size reduction effort - the compression theory
On 28/02/11 12:16, Michael Meeks wrote: > Hi Kami, > > Wow - I'm so sorry, I missed your sexy mail for a week; that sucks - > over-much merging on another branch :-) Tor has been on FTO, and > Fridrich with his head down releasing 3.3.1 (and the Novell LibreOffice > product) - which in part explains the lack of response to you (and > Steven) - which sucks - sorry guys. Finally found a few minutes to try and catch up - so jumping in late myself ... > > On Tue, 2011-02-22 at 17:32 +0100, Kálmán „KAMI” Szalai wrote: >> I ran few test to figure out what is the best method for installset > > These look great, nice spreadsheet. > >> So I went to other direction, whatif I increase the efficiency of LZM >> compression of makecab. I found that we can use .Set CompressionMemory= >> 21 setting. This setting produces 83,91% of original installer size and > > Oh - nice :-) that solves the install-space problem as well. If I understand correctly, imho this is the best approach too. Note that it's a bad idea to try to compress an already-compressed file. Depending on the relative efficiency of the two algorithms, it's very easy for the second compression to actually *increase* the file size. So compressing the cabs, and just packing them into the download with no compression makes most theoretical sense. Plus, in return for minimal or negative compression, the second compression will also take a LOT of time. > >> In the gray section I tried a special way when I uncompressed every >> zip container (ODF, JAR, ZIP, etc) in the installset and every file >> contains only stored data without compression. In this way I was able >> to gain more 15 MB, but this require zip recompressing at the end of >> installation process that may make it to complex and time consuming. >> Please check the attached document, and if you want to go with it >> apply the attached patches. > > Oh ! that sounds fun :-) 15Mb for that. Actually on master - we could > use flat ODF files and get the same result (for some on-disk size > growth) without having to re-compress, and they're dead fast in master. > > So - personally, I find it amazing that ZIP is better than LZMA - ever, > it is such an older compression algorithm, and this flies in the face of > everything I've seen in practise with it [ eg. we use LZMA for our RPMs > in openSUSE these days AFAIR, better than bzip2, which in turn was > better than .tgz (essentially zip) ]. > Why the surprise? How long has Huffman been around - 30 years? 40? And you CANNOT do better than Huffman (there are other equally as good algorithms, though). The holy grail is an algorithm that is as efficient as Huffman, very quick to decompress, and fairly quick to compress. Having tried to back up a hard disk over ethernet (dd if=/dev/sda of=//samba/archive.hdi), it was direly slow over a 10Mb card. So I tried to pipe it through bzip2 to speed up the transfer - it was *even* *slower*! Why do you think LZMA is better than zip - because it's faster? Or because it's more efficient? I don't know much about the details of either, but I'd be surprised if zip *wasn't* capable of very good compression. It's just that as you crank up the compression efficiency, you also crank up the time taken to do the compression - witness bz2's inability to flood my 10Mbit network card. (I think we need to add compression time to KAMI's nice table :-) Cheers, Wol ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Accelerate Perl installer builder
Hi Jan, On Fri, 2011-02-25 at 16:51 +0100, Jan Darmochwal wrote: > This patch speeds up make_installer.pl by about 5% on linux > (probably much less speedup on windows). The Patch is LGPLv3+/MPL. Nice :-) not only faster, but smaller, cleaner and more readable - I like it, pushed to master. > The next patch will focus on Windows speed (if I succeed in setting > up a Windows build environment for LibreOffice). Thanks - it is fairly hard to profile that. The archive piece seems to be a tad slow, but it is unclear why - luckily when we merge m98 we'll get much better and faster component registration, so then the perl speedups will be even more remarkable I think :-) Anyhow - thanks for putting love in here ! ATB, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] OpenSuse 11-4-rc2 claiims LibreOffice has minor bugs
Le 2011-02-28 06:52, Andreas Jaeger a écrit : On Monday, February 28, 2011 11:55:28 Michael Meeks wrote: Hi Marc / AJ, On Sun, 2011-02-27 at 21:56 -0500, Marc Paré wrote: We just had this posted on the Marketing list. I am not sure if this is true. Can anyone comment on this? Are there reports of loss of data? This is news to me too; AJ - where did this block come from: I'm already on it - but indeed, I have not found evidence yet. raft of new functionality has created a few specific issues, such as loss of data in tables. Though not quite ready for the production And why ? it would be extraordinarily helpful to know - we're not aware of this bug, and it sounds serious. It would also be great to know who was pinged from the SUSE / LibreOffice team before including that. Andreas Thanks Michael and Andreas I am just as annoyed as you seem to be to see these claims. The message come to our Marketing pages here: http://permalink.gmane.org/gmane.comp.documentation.libreoffice.marketing/2573 If this is an official part of the OpenSuse project and if it is not based on facts I would like to see a retraction on their part. I have no idea from where they got their information. I don't think that leaving a note, in my name, on their comments box would make enough impact. It would have to be someone with recognized authority to question it. The claim of loss of data in Calc, in my mind, is quite a serious statement. Cheers Marc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Nonsense comments?
Hi Christina, On Mon, Feb 28, 2011 at 4:19 PM, Christina Roßmanith wrote: > > I admit, I can't follow the discussion. But during translation: are the '~' > important? ~ specifies the mnemonic in the menu (the underlined letter in the menu, used for keyboard-access) ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] PUSHED building index at Win32 install time ...
I pushed both of the patches. Thank you for the custom action. Now, the thing would be to teach the installer to execute it and try how costly it is on install time. Thanks again F. On 19/02/11 15:32, Steven Butler wrote: Hi Again, I forgot to add this change to have it build the custom action. All changes are MPL/LGPL as per standard libreoffice licensing terms. Regards Steven Butler ___ 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] Nonsense comments?
2011/2/28 Christina Roßmanith : > Hi, > > I admit, I can't follow the discussion. But during translation: are the '~' > important? > > Some lines of a diff for translation of comments: > > - /* ### ACHTUNG: Neuer Text in Resource? Grafik ~kopieren : > ~Grafik kopieren */ > - /* ### ACHTUNG: Neuer Text in Resource? Grafik ~kopieren : > ~Grafik kopieren */ > - /* ### ACHTUNG: Neuer Text in Resource? Grafik ~kopieren : > ~Grafik kopieren */ > + /* ### ATTENTION: new text in resource? copy graphic : copy > graphic */ > + /* ### ATTENTION: new text in resource? copy graphic : copy > graphic */ > + /* ### ATTENTION: new text in resource? copy graphic : copy > graphic */ > > And it seems that there is a certain redundancy. Or is it important to keep > three copies of the same line. Is "ACHTUNG" a keywort which is searched for? > Or is it safe to translate it to "ATTENTION"? > > Thank you for any low-level explanation :-) Hi, I don't think we need /* ### ACHTUNG: comments at all in resource files. Probably they were inserted by a script long time ago, when the source language was German. They do not look useful now. They can be removed. Just my 2 cents... Cheers, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 34404] LibreOffice 3.3.2 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=34404 --- Comment #6 from sasha.libreoff...@gmail.com 2011-02-28 07:29:40 PST --- I am sorry about incorrect previous bug. bug 34834 instead -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] binfilter breakage
Hi Norbert, *, On Mon, Feb 28, 2011 at 3:46 PM, Norbert Thiebaud wrote: > the Mac daily build has been failing for the last 2 iteration: > > http://dev-builds.libreoffice.org/daily/MacOS/master/2011-02-28-09.00.54/master~2011-02-28-09.00.54.failed.log.bz2 line 114112 ff. (see also http://tinderbox.go-oo.org/cgi-bin/gunzip.cgi?tree=MASTER&brief-log=1298836816.26002#31603 ) > Note: a clean build of binfilter is needed to see the breakage. > Note: apparently there is more than one breakage as different commit > after the aforementioned commit fail for different reasons. Yes, the previous failure (the dochdl one) http://tinderbox.go-oo.org/cgi-bin/gunzip.cgi?tree=MASTER&brief-log=1298752816.5882#err26 was fixed with http://cgit.freedesktop.org/libreoffice/filters/commit/?id=4a95a625e4bd07067a81ba37b39ad6cc7e6e16c5 ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Nonsense comments?
Hi, I admit, I can't follow the discussion. But during translation: are the '~' important? Some lines of a diff for translation of comments: -/* ### ACHTUNG: Neuer Text in Resource? Grafik ~kopieren : ~Grafik kopieren */ -/* ### ACHTUNG: Neuer Text in Resource? Grafik ~kopieren : ~Grafik kopieren */ -/* ### ACHTUNG: Neuer Text in Resource? Grafik ~kopieren : ~Grafik kopieren */ +/* ### ATTENTION: new text in resource? copy graphic : copy graphic */ +/* ### ATTENTION: new text in resource? copy graphic : copy graphic */ +/* ### ATTENTION: new text in resource? copy graphic : copy graphic */ And it seems that there is a certain redundancy. Or is it important to keep three copies of the same line. Is "ACHTUNG" a keywort which is searched for? Or is it safe to translate it to "ATTENTION"? Thank you for any low-level explanation :-) Christina Am 27.02.2011 10:27, schrieb Andras Timar: Hi, 2011/2/25 Caolán McNamara: On Fri, 2011-02-25 at 20:37 +0100, Christina Roßmanith wrote: timar: po files can have translator-comments in them to help translators about ambiguous terms/words, while the .src/.sdf format doesn't though, right ? I recall a problem with trying to get the Spanish translation of an obscure paper size (8.5" x 13" ) set as "Oficio" given that this paper size is known as that in the handful of Latin American nations that use it, rather than some literal Spanish translation of "Long Bond" as the size is known in e.g. the Philippines. Would it be helpful to have a medium-level hack to add translator-comment support to the translation tools to help flag that sort of thing ? In fact it is possible to add comments to strings, there is the special "language code" x-comment. Alas, it is not extracted to SDF so it is not very useful for translators. It would be helpful, if it worked. Best regards, Andras ___ 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] remove using namespace rtl
At 10:14am -0500 Mon, 28 Feb 2011, Kohei Yoshida wrote: So, the idea behind this easy hack task is *not* to convert rtl::OUString to OUString by using "using ::rtl::OUString" per se. The idea behind it is to remove using namespace rtl, and if that causes build breakage because of the use of non-fully qualified OUString in that file, then we'll add "using ::rtl::OUString" to that file. Noted. I misunderstood, obviously. Thanks, Kevin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] remove using namespace rtl
On Sat, 2011-02-26 at 01:45 -0500, Kevin Hunter wrote: > Hullo List, > > A simpleton patch to convert the more sane using ::rtl::* syntax. Hi Kevin, So, the idea behind this easy hack task is *not* to convert rtl::OUString to OUString by using "using ::rtl::OUString" per se. The idea behind it is to remove using namespace rtl, and if that causes build breakage because of the use of non-fully qualified OUString in that file, then we'll add "using ::rtl::OUString" to that file. Using rtl::OUString directly, or using OUString in the code and adding using ::rtl::OUString at the top is mostly just a matter of taste, so I don't think we want to do this conversion across the board. Regards, Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 34404] LibreOffice 3.3.2 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=34404 Cédric Bosdonnat changed: What|Removed |Added Depends on|34821 | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 34404] LibreOffice 3.3.2 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=34404 sasha.libreoff...@gmail.com changed: What|Removed |Added Depends on||34821 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH 4/4] Translate german comments
This translates the rest of the german comments in writer/sw/source/ui/docvw
to english.
This is contributed under the terms of the MPL 1.1 / GPLv3+ / LGPLv3+ triple
license.
---
sw/source/ui/docvw/SidebarWin.cxx |2 +-
sw/source/ui/docvw/romenu.cxx | 13 +++---
sw/source/ui/docvw/srcedtw.cxx| 81 ++---
3 files changed, 47 insertions(+), 49 deletions(-)
diff --git a/sw/source/ui/docvw/SidebarWin.cxx
b/sw/source/ui/docvw/SidebarWin.cxx
index 40c5bfa..8bb1f90 100644
--- a/sw/source/ui/docvw/SidebarWin.cxx
+++ b/sw/source/ui/docvw/SidebarWin.cxx
@@ -758,7 +758,7 @@ void SwSidebarWin::SetColor(Color aColorDark,Color
aColorLight, Color aColorAnch
AllSettings aSettings2 = mpVScrollbar->GetSettings();
StyleSettings aStyleSettings2 = aSettings2.GetStyleSettings();
aStyleSettings2.SetButtonTextColor(Color(0,0,0));
-aStyleSettings2.SetCheckedColor(mColorLight); //hintergund
+aStyleSettings2.SetCheckedColor(mColorLight); // backgound
aStyleSettings2.SetShadowColor(mColorAnchor);
aStyleSettings2.SetFaceColor(mColorDark);
aSettings2.SetStyleSettings(aStyleSettings2);
diff --git a/sw/source/ui/docvw/romenu.cxx b/sw/source/ui/docvw/romenu.cxx
index e24963e..f99226e 100644
--- a/sw/source/ui/docvw/romenu.cxx
+++ b/sw/source/ui/docvw/romenu.cxx
@@ -78,8 +78,7 @@ using namespace ::sfx2;
void GetPreferedExtension( String &rExt, const Graphic &rGrf )
{
-// dann ggfs. ueber die native-Info der Grafik den "besten"
-// Filter vorschlagen
+// then propose the "best" filter using the native-info, if applicable
const sal_Char* pExt = "png";
switch( const_cast(rGrf).GetLink().GetType() )
{
@@ -399,7 +398,7 @@ void SwReadOnlyPopup::Execute( Window* pWin, USHORT nId )
String SwReadOnlyPopup::SaveGraphic( USHORT nId )
{
-//Namen der Grafik herausfischen.
+// fish out the graphic's name
String aName;
if ( MN_READONLY_SAVEBACKGROUND == nId )
{
@@ -430,7 +429,7 @@ String ExportGraphic( const Graphic &rGraphic, const String
&rGrfName )
INetURLObject aPath;
aPath.SetSmartURL( sGrfPath );
-//Namen der Grafik herausfischen.
+// fish out the graphic's name
String aName = rGrfName;
aDlgHelper.SetTitle( SW_RESSTR(STR_EXPORT_GRAFIK_TITLE));
@@ -459,7 +458,7 @@ String ExportGraphic( const Graphic &rGraphic, const String
&rGrfName )
}
if ( USHRT_MAX == nDfltFilter )
{
-//"falsche" Extension?
+// "wrong" extension?
GetPreferedExtension( aExt, rGraphic );
for ( USHORT i = 0; i < nCount; ++i )
if ( aExt == rGF.GetExportFormatShortName( i ).ToLowerAscii() )
@@ -476,14 +475,14 @@ String ExportGraphic( const Graphic &rGraphic, const
String &rGrfName )
if( aDlgHelper.Execute() == ERRCODE_NONE )
{
String sPath( xFP->getFiles().getConstArray()[0] );
-//verwendeten Pfad merken - bitte nicht wieder wegoptimieren!
+// remember used path - please don't optimize away!
aPath.SetSmartURL( sPath);
sGrfPath = aPath.GetPath();
if( rGrfName.Len() &&
nDfltFilter == rGF.GetExportFormatNumber(
xFltMgr->getCurrentFilter()))
{
-//Versuchen die Originalgrafik zu speichern.
+// try to save the original graphic
SfxMedium aIn( rGrfName, STREAM_READ | STREAM_NOCREATE,
TRUE );
if( aIn.GetInStream() && !aIn.GetInStream()->GetError() )
diff --git a/sw/source/ui/docvw/srcedtw.cxx b/sw/source/ui/docvw/srcedtw.cxx
index e961632..447b42c 100644
--- a/sw/source/ui/docvw/srcedtw.cxx
+++ b/sw/source/ui/docvw/srcedtw.cxx
@@ -82,10 +82,10 @@ static void lcl_Highlight(const String& rSource,
SwTextPortions& aPortionList)
const USHORT nStrLen = rSource.Len();
-USHORT nInsert = 0;// Anzahl der eingefuegten
Portions
-USHORT nActPos = 0;//Position, an der '<' gefunden
wurde
-USHORT nOffset = 0;//Offset von nActPos zur '<'
-USHORT nPortStart = USHRT_MAX; // fuer die TextPortion
+USHORT nInsert = 0;// number of inserted portions
+USHORT nActPos = 0;// position, where '<' was found
+USHORT nOffset = 0;// Offset of nActPos to '<'
+USHORT nPortStart = USHRT_MAX; // for the TextPortion
USHORT nPortEnd = 0; //
SwTextPortion aText;
while(nActPos < nStrLen)
@@ -93,11 +93,11 @@ static void lcl_Highlight(const String& rSource,
SwTextPortions& aPortionList)
svtools::ColorConfigEntry eFoundType = svtools::HTMLUNKNOWN;
if(rSource.GetChar(nActPos) == cOpenBracket && nActPos < nStrLen - 2 )
{
-// 'leere' Portion einfuegen
+// insert 'empty' portion
if
[Libreoffice] [PATCH 3/4] Translate german comments in edtwin.cxx
This translates the german code comments in edtwin.cxx to english.
This is contributed under the terms of the MPL 1.1 / GPLv3+ / LGPLv3+ triple
license.
---
sw/source/ui/docvw/edtwin.cxx | 322 -
1 files changed, 154 insertions(+), 168 deletions(-)
diff --git a/sw/source/ui/docvw/edtwin.cxx b/sw/source/ui/docvw/edtwin.cxx
index 058c148..21f94b6 100644
--- a/sw/source/ui/docvw/edtwin.cxx
+++ b/sw/source/ui/docvw/edtwin.cxx
@@ -143,18 +143,17 @@ using namespace sw::mark;
using namespace ::com::sun::star;
/*
-Beschreibung: Globals
+Description: Globals
*/
static bool bInputLanguageSwitched = false;
extern BOOL bNoInterrupt; // in mainwn.cxx
-//Normalerweise wird im MouseButtonUp eine Selektion aufgehoben wenn die
-//Selektion nicht gerade aufgezogen wird. Leider wird im MouseButtonDown
-//bei doppel-/dreifach-Klick Selektiert, diese Selektion wird in dem Handler
-//komplett abgeschlossen und kann deshalb im Up nicht mehr unterschieden
-//werden. Um dies Aufzuloese wird bHoldSelection im Down gesetzt und im
-//Up ausgewertet.
+// Usually in MouseButtonUp a selection is revoked when the selection is
+// not currently being pulled open. Unfortunately in MouseButtonDown there
+// is being selected at double/triple click. That selection is completely
+// finished in the Handler and thus can't be distinguished in the Up.
+// To resolve this bHoldSelection is set in Down at evaluated in Up.
static BOOL bHoldSelection = FALSE;
BOOL bFrmDrag = FALSE;
@@ -172,7 +171,7 @@ longSwEditWin::nDDStartPosY = 0;
longSwEditWin::nDDStartPosX = 0;
Color SwEditWin::aTextBackColor(COL_YELLOW);
Color SwEditWin::aTextColor(COL_RED);
-BOOLSwEditWin::bTransparentBackColor = FALSE; // Hintergrund nicht
transparent
+BOOLSwEditWin::bTransparentBackColor = FALSE; // background not transparent
extern BOOL bExecuteDrag;
@@ -256,10 +255,10 @@ struct QuickHelpData
};
/*
-Beschreibung: Minimale Bewegung Zittern vermeiden
+Description: avoid minimal movement shiver
*/
-#define HIT_PIX 2 /* Hit-Toleranz in Pixel */
+#define HIT_PIX 2 /* hit tolerance in pixel */
#define MIN_MOVE 4
inline BOOL IsMinMove(const Point &rStartPos, const Point &rLPt)
@@ -269,10 +268,10 @@ inline BOOL IsMinMove(const Point &rStartPos, const Point
&rLPt)
}
/*
-fuer MouseButtonDown - feststellen, ob ein DrawObject
-und KEIN SwgFrame getroffen wurde! Shift/Ctrl sollen
-nur bei DrawObjecte zum Selektieren fuehren, bei SwgFlys
-ggfs zum ausloesen von Hyperlinks (DownLoad/NewWindow!)
+for MouseButtonDown - determine whether a DrawObject
+an NO SwgFrame was hit! Shift/Ctrl should only result
+in selecting, with DrawObjects; at SwgFlys to trigger
+hyperlinks if applicable (DownLoad/NewWindow!)
*/
inline BOOL IsDrawObjSelectable( const SwWrtShell& rSh, const Point& rPt )
{
@@ -292,7 +291,7 @@ inline BOOL IsDrawObjSelectable( const SwWrtShell& rSh,
const Point& rPt )
}
/*
-Beschreibung: Pointer umschalten
+Description: switch pointer
*/
void SwEditWin::UpdatePointer(const Point &rLPt, USHORT nModifier )
@@ -326,7 +325,7 @@ void SwEditWin::UpdatePointer(const Point &rLPt, USHORT
nModifier )
0 !=(pFmt = rSh.GetFmtFromObj( rLPt, &pRect )) &&
PTR_CAST(SwFlyFrmFmt, pFmt))
{
-//Highlight fuer Rahmen anwerfen
+//turn on highlight for frame
Rectangle aTmp( pRect->SVRect() );
if ( !pUserMarker )
@@ -543,7 +542,7 @@ void SwEditWin::UpdatePointer(const Point &rLPt, USHORT
nModifier )
}
/*
-Beschreibung: Timer fuer Selektion vergroessern
+Description: increase timer for selection
*/
IMPL_LINK( SwEditWin, TimerHandler, Timer *, EMPTYARG )
@@ -581,9 +580,8 @@ IMPL_LINK( SwEditWin, TimerHandler, Timer *, EMPTYARG )
else
(rSh.*rSh.fnSetCrsr)( &aModPt, FALSE );
-// Es kann sein, dass der "Sprung" ueber eine Tabelle so
-//nicht geschafft wird. Deshalb wir hier eben per Up/Down ueber die
-//Tabelle gesprungen.
+// I
[Libreoffice] [PATCH 2/4] Translate german comments
This translates the german code comments of edtwin2.cxx and edtwin3.cxx to
english.
This is contributed under the terms of the MPL 1.1 / GPLv3+ / LGPLv3+ triple
license.
---
sw/source/ui/docvw/edtwin2.cxx | 18 +-
sw/source/ui/docvw/edtwin3.cxx | 26 +-
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/sw/source/ui/docvw/edtwin2.cxx b/sw/source/ui/docvw/edtwin2.cxx
index 54b8638..f6134e0 100644
--- a/sw/source/ui/docvw/edtwin2.cxx
+++ b/sw/source/ui/docvw/edtwin2.cxx
@@ -82,7 +82,7 @@
// <--
/*
-Beschreibung: KeyEvents
+Description: KeyEvents
*/
static void lcl_GetRedlineHelp( const SwRedline& rRedl, String& rTxt, BOOL
bBalloon )
{
@@ -313,7 +313,7 @@ void SwEditWin::RequestHelp(const HelpEvent &rEvt)
{
break;
}
-case RES_INPUTFLD: // BubbleHelp, da der Hinweis
ggf ziemlich lang sein kann
+case RES_INPUTFLD: // BubbleHelp, because the
suggestion could be quite long
bBalloon = TRUE;
/* no break */
case RES_JUMPEDITFLD:
@@ -381,7 +381,7 @@ void SwEditWin::RequestHelp(const HelpEvent &rEvt)
Help::ShowBalloon( this, rEvt.GetMousePosPixel(), sTxt );
else
{
-// dann zeige die Hilfe mal an:
+// the show the help
Rectangle aRect( aFldRect.SVRect() );
Point aPt( OutputToScreenPixel( LogicToPixel(
aRect.TopLeft() )));
aRect.Left() = aPt.X();
@@ -445,7 +445,7 @@ void SwEditWin::RequestHelp(const HelpEvent &rEvt)
if ((pField = aVEvt.pURLField) != 0)
{
-// URL-Feld getroffen
+// hit an URL field
if (pField)
{
pObj = aVEvt.pObj;
@@ -456,7 +456,7 @@ void SwEditWin::RequestHelp(const HelpEvent &rEvt)
}
if (bWeiter && eHit == SDRHIT_TEXTEDIT)
{
-// URL-Feld in zum Editieren ge?ffneten DrawText-Objekt suchen
+// look for URL field in DrawText object that is opened for editing
OutlinerView* pOLV = pSdrView->GetTextEditOutlinerView();
const SvxFieldItem* pFieldItem;
@@ -519,15 +519,15 @@ void SwEditWin::Paint(const Rectangle& rRect)
if( pShadCrsr )
{
Rectangle aRect( pShadCrsr->GetRect());
-// liegt vollstaendig drin?
+// fully resides inside?
if( rRect.IsInside( aRect ) )
// dann aufheben
delete pShadCrsr, pShadCrsr = 0;
else if( rRect.IsOver( aRect ))
{
-// liegt irgendwie drueber, dann ist alles ausserhalb geclippt
-// und wir muessen den "inneren Teil" am Ende vom Paint
-// wieder sichtbar machen. Sonst kommt es zu Paintfehlern!
+// resides somewhat above, then everything is clipped outside
+// and we have to make the "inner part" at the end of the
+// Paint visible again. Otherwise Paint errors occur!
bPaintShadowCrsr = TRUE;
}
}
diff --git a/sw/source/ui/docvw/edtwin3.cxx b/sw/source/ui/docvw/edtwin3.cxx
index b8b0276..5164048 100644
--- a/sw/source/ui/docvw/edtwin3.cxx
+++ b/sw/source/ui/docvw/edtwin3.cxx
@@ -51,7 +51,7 @@
/*
-Beschreibung: Core-Notify
+Description: Core-Notify
*/
@@ -65,7 +65,7 @@ void ScrollMDI( ViewShell* pVwSh, const SwRect &rRect,
}
/*
-Beschreibung: Docmdi - verschiebbar
+Description: Docmdi - movable
*/
@@ -79,7 +79,7 @@ BOOL IsScrollMDI( ViewShell* pVwSh, const SwRect &rRect )
}
/*
-Beschreibung: Notify fuer Groessen-Aenderung
+Description: Notify for size change
*/
@@ -97,7 +97,7 @@ void SizeNotify(ViewShell* pVwSh, const Size &rSize)
}
/*
-Beschreibung: Notify fuer Seitenzahl-Update
+Description: Notify for page number update
*/
@@ -112,8 +112,8 @@ void PageNumNotify( ViewShell* pVwSh, USHORT nPhyNum,
USHORT nVirtNum,
}
/*
[Libreoffice] [PATCH 1/4] Translate german comments
This translates the german code comments of docvw.hrc, docvw.src and edtdd.cxx
to english.
This is contributed under the terms of the MPL 1.1 / GPLv3+ / LGPLv3+ triple
license.
---
sw/source/ui/docvw/docvw.hrc |2 +-
sw/source/ui/docvw/docvw.src |6 +++---
sw/source/ui/docvw/edtdd.cxx | 33 -
3 files changed, 20 insertions(+), 21 deletions(-)
diff --git a/sw/source/ui/docvw/docvw.hrc b/sw/source/ui/docvw/docvw.hrc
index c0f1529..9a8987c 100644
--- a/sw/source/ui/docvw/docvw.hrc
+++ b/sw/source/ui/docvw/docvw.hrc
@@ -52,7 +52,7 @@
#define MN_READONLY_RELOAD (RC_DOCVW_BEGIN + 22)
#define MN_READONLY_COPY(RC_DOCVW_BEGIN + 23)
-//Bei den folgenden brauchen wir Luft fuer die Gallery-Themen
+//For the following we need space for the gallery-themes
#define MN_READONLY_GRAPHICTOGALLERY(RC_DOCVW_BEGIN + 24)
#define MN_READONLY_BACKGROUNDTOGALLERY (RC_DOCVW_BEGIN + 60)
diff --git a/sw/source/ui/docvw/docvw.src b/sw/source/ui/docvw/docvw.src
index dcd0f98..341f8ab 100644
--- a/sw/source/ui/docvw/docvw.src
+++ b/sw/source/ui/docvw/docvw.src
@@ -162,9 +162,9 @@ Menu MN_READONLY_POPUP
{
Identifier = MN_READONLY_COPYGRAPHIC ;
HelpID = HID_MN_READONLY_COPYGRAPHIC ;
-/* ### ACHTUNG: Neuer Text in Resource? Grafik ~kopieren : ~Grafik
kopieren */
-/* ### ACHTUNG: Neuer Text in Resource? Grafik ~kopieren : ~Grafik
kopieren */
-/* ### ACHTUNG: Neuer Text in Resource? Grafik ~kopieren : ~Grafik
kopieren */
+/* ### ATTENTION: new text in resource? copy graphic : copy
graphic */
+/* ### ATTENTION: new text in resource? copy graphic : copy
graphic */
+/* ### ATTENTION: new text in resource? copy graphic : copy
graphic */
Text [ en-US ] = "Copy ~Graphics" ;
};
SEPARATOR
diff --git a/sw/source/ui/docvw/edtdd.cxx b/sw/source/ui/docvw/edtdd.cxx
index 61563ee..1f2112d 100644
--- a/sw/source/ui/docvw/edtdd.cxx
+++ b/sw/source/ui/docvw/edtdd.cxx
@@ -100,14 +100,13 @@ void SwEditWin::StartDrag( sal_Int8 /*nAction*/, const
Point& rPosPixel )
SdrObject *pObj = NULL;
Point aDocPos( PixelToLogic( rPosPixel ) );
if ( !rSh.IsInSelect() && rSh.ChgCurrPam( aDocPos, TRUE, TRUE))
-//Wir sind nicht beim Selektieren und stehen auf einer
-//Selektion
+//We are not selecting and aren't at a selection
bStart = TRUE;
else if ( !bFrmDrag && rSh.IsSelFrmMode() &&
rSh.IsInsideSelectedObj( aDocPos ) )
{
-//Wir sind nicht am internen Draggen und stehen auf
-//einem Objekt (Rahmen, Zeichenobjekt)
+//We are not dragging internally and are not at an
+//object (frame, draw object)
bStart = TRUE;
}
@@ -173,7 +172,7 @@ void SwEditWin::DropCleanup()
{
SwWrtShell &rSh = rView.GetWrtShell();
-// Stati zuruecksetzen
+// reset statuses
bNoInterrupt = FALSE;
if ( bOldIdleSet )
{
@@ -198,7 +197,7 @@ void SwEditWin::CleanupDropUserMarker()
}
-//Messehack (MA,MBA)
+//exhibition hack (MA,MBA)
void lcl_SelectShellForDrop( SwView &rView )
{
if ( !rView.GetCurShell() )
@@ -211,7 +210,7 @@ sal_Int8 SwEditWin::ExecuteDrop( const ExecuteDropEvent&
rEvt )
DropCleanup();
sal_Int8 nRet = DND_ACTION_NONE;
-//Ein Drop auf eine offene OutlinerView geht uns nichts an (siehe auch
QueryDrop)
+//A Drop to an open OutlinerView doesn't concern us (also see QueryDrop)
SwWrtShell &rSh = rView.GetWrtShell();
const Point aDocPt( PixelToLogic( rEvt.maPosPixel ));
SdrObject *pObj = 0;
@@ -256,7 +255,7 @@ sal_Int8 SwEditWin::ExecuteDrop( const ExecuteDropEvent&
rEvt )
m_nDropDestination, FALSE, rEvt.mbDefault,
&aDocPt, nRet))
nRet = DND_ACTION_NONE;
else if ( SW_MOD()->pDragDrop )
-//Bei internem D&D nicht mehr aufraeumen!
+//Don't clean up anymore at internal D&D!
SW_MOD()->pDragDrop->SetCleanUp( FALSE );
return nRet;
@@ -273,7 +272,7 @@ USHORT SwEditWin::GetDropDestination( const Point& rPixPnt,
SdrObject ** ppObj )
SdrObject *pObj = NULL;
const ObjCntType eType = rSh.GetObjCntType( aDocPt, pObj );
-//Drop auf OutlinerView (TextEdit im Drawing) soll diese selbst
entscheiden!
+//Drop to OutlinerView (TextEdit in Drawing) should decide it on its own!
if( pObj )
{
OutlinerView* pOLV = rSh.GetDrawView()->GetTextEditOutlinerView();
@@ -287,10 +286,10 @@ USHORT SwEditWin::GetDropDestination( const Point&
rPixPnt, SdrObject ** ppObj )
}
}
-//Auf was wollen wir denn gerade droppen?
+//What do we want to drop on now?
USHORT nDropDestination = 0;
-//Sonst etwas aus der DrawingEngine getroffen?
+//Did anything else arrive from the DrawingEngine?
if( OBJCN
[Libreoffice] Comment translation of writer/sw/source/ui/docvw
Hi, This translates the german code comments of writer/sw/source/ui/docvw to english. Thanks! martin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] binfilter breakage
the Mac daily build has been failing for the last 2 iteration: after bisection, this seems due to binfilter which is broken starting filter:49a4e7c852493cad34b97d212be6dc55fcf23cad the failed build.log can be found at: http://dev-builds.libreoffice.org/daily/MacOS/master/2011-02-28-09.00.54/master~2011-02-28-09.00.54.failed.log.bz2 Note: a clean build of binfilter is needed to see the breakage. Note: apparently there is more than one breakage as different commit after the aforementioned commit fail for different reasons. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Question about the debian-files of LibreOffice 3.3.1
Hello, I had a look at the debian packages of LibreOffice 3.3.1 and I recognized that all version numbers changed from 3.3.0-19 to 3.3.1-19. But there is one package libreoffice3-ure which had the version number 1.7.0-19 in LO 3.3.0 and still has the number 1.7.0-19 in LO 3.3.1. But: the MD5SUM of the package has changed! The problem is: When LibreOffice is installed via a repository, the package managers do not recognize that a new version is available. Is this a small issue in the 3.3.1 deb-packages or is planned that the version number of URE does not change? If this is an issue: What will be the version number of the URE package in 3.3.2? A small info would be nice. Thank you, Axel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 34404] LibreOffice 3.3.2 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=34404 Cédric Bosdonnat changed: What|Removed |Added Depends on|34757 | --- Comment #5 from Cédric Bosdonnat 2011-02-28 06:25:59 PST --- A bug but not a blocker. Please ask for advises on the developers mailing list before nominating a bug as a release blocker! Imagine what mess it would be here if anyone added his pet bug as a blocker for the next release! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [tdf-discuss] Instant Messenger for Libre Office (serverless and open source)
On 2/28/11 2:22 PM, Randolph Dohm wrote: Please send me your Key and we can chat there about the options of a bundle or integration or gui style branding/adjustment. Hi Randolph, we are supposed to be the media spokespersons and not the official representatives of The Document Foundation. We are not going to test products, and we are not supposed to discuss the integration of any product with LibreOffice now, or at least for the foreseeable future. I do not think that there are integration opportunities with LibreOffice for any instant messenger. Best regards. P.S. - The fact that our email address is on the public website is not an implicit authorization to write. In addition, you have sent a second message before getting any answer to the first one. As far as I am concerned, your email is blaclisted. -- Italo Vignoli - The Document Foundation ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 34404] LibreOffice 3.3.2 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=34404 Cédric Bosdonnat changed: What|Removed |Added Depends on|34821 | --- Comment #4 from Cédric Bosdonnat 2011-02-28 06:08:03 PST --- You shouldn't add blocker bugs without having them correctly qualified first. This one simply doesn't make sense for anyone! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 34404] LibreOffice 3.3.2 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=34404 sasha.libreoff...@gmail.com changed: What|Removed |Added Depends on||33361, 34821, 34757 --- Comment #3 from sasha.libreoff...@gmail.com 2011-02-28 05:54:42 PST --- bug 33361, bug 34821, bug 34757 with this bugs Impress becomes useless for students -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Instant Messenger for Libre Office (serverless and open source)
Dear Florian, Olivier, Charles, Italo, and all I want to suggest that libreoffice gets an open source and serverless (maintainance free) Instant Messenger - or even more than that, a secure communication platform, which allows users in the office to communicate secure. This is done over 0.5.1.a Release of http://retroshare.sf.net http://retroshare.sourceforge.net/downloads.html an I want to suggest to make it the libre office Instant Messenger. Can we test this? you need to generate a gnupg key and swap it with the chat friend. It is working all serverless, over a DHT. Please send me your Key and we can chat there about the options of a bundle or integration or gui style branding/adjustment. Thanks for a feedback and evaluation Kind Regards Randolph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 34404] LibreOffice 3.3.2 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=34404 Alex Thurgood changed: What|Removed |Added Depends on||33904 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [opensuse-announce] openSUSE 11.4 RC2 Steps Out
Hi Andreas, Andreas Jaeger píše v Po 28. 02. 2011 v 09:49 +0100: > The transition from OpenOffice.org to LibreOffice still has a few minor > documentation blips but more importantly, users should be cautious. The raft > of new functionality has created a few specific issues, such as loss of data > in tables. Though not quite ready for the production environment, user > feedback is critical for smoothing performance and reliability. I am not aware of any data loos in tables. Could you please be more specific? Is there any bug number? Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 32894] [Task] LibreOffice 3.3.1 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=32894 Alex Thurgood changed: What|Removed |Added Depends on|33904 | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] OpenSuse 11-4-rc2 claiims LibreOffice has minor bugs
Hi Marc / AJ, On Sun, 2011-02-27 at 21:56 -0500, Marc Paré wrote: > We just had this posted on the Marketing list. I am not sure if this is > true. Can anyone comment on this? Are there reports of loss of data? This is news to me too; AJ - where did this block come from: > raft of new functionality has created a few specific issues, such as > loss of data in tables. Though not quite ready for the production And why ? it would be extraordinarily helpful to know - we're not aware of this bug, and it sounds serious. It would also be great to know who was pinged from the SUSE / LibreOffice team before including that. ATB, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] suggestions/instructions needed
Hi, Finally, finished the first time full build of LO on windows with the help from some really kind guys here, thank you all, Cheers! I, as a kind one also, am a chinese with few years of java and C/C++ experience. Have just convinced my boss to use LO, take over MSOffice and OOo. Honestly speaking, LO is better than OOo in term of stability and compatibility, at least most of my colleagues say so. This strongly increased my confidence about convincing the boss to make some donation to TDF someday. Right now, I am working on a documentary project, the track change feature of word/Writer processor acts an important role in the project, in short, need to invoke the LO from a java application and get access to the track change funtion. Two things, one is that I need to write something like a 'macro' to automatically shape the 'track change' feature when the LO Writer is called, furthermore, maybe also need to improve the current 'track change' function a little bit. I am new to this LO development, am reading the developer guide (OOo guide), have not yet been completely aware of where and how to start the work in the case mentioned above. By guess, the first one shold have some to do with UNO, and the second 'Hack' thing should involve the direct source codes revision? the latter must be awesome! :) Anyhow, suggestiongs/ instructions on both is definitely appreciated, hope I can get equipped very soon. Look forward to hearing from you guys! BR zongbo zhang ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] Comment translation of writer/sw/source/ui/dochdl
Hi, reviewed and pushed. Changed your translation of "Textbaustein" = "text block" to "auto text" because I think that is what LibreOffice uses as term. Christina Am 27.02.2011 21:21, schrieb Martin Kepplinger: Hi, This translates all german code comments in writer/sw/source/ui/dochdl to english. For reviewing, thanks in advance! martin ___ 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] [opensuse-announce] openSUSE 11.4 RC2 Steps Out
On Monday, February 28, 2011 11:46:03 Petr Mladek wrote:
> Hi Andreas,
>
> Andreas Jaeger píše v Po 28. 02. 2011 v 09:49 +0100:
> > The transition from OpenOffice.org to LibreOffice still has a few minor
> > documentation blips but more importantly, users should be cautious. The
> > raft of new functionality has created a few specific issues, such as
> > loss of data in tables. Though not quite ready for the production
> > environment, user feedback is critical for smoothing performance and
> > reliability.
>
> I am not aware of any data loos in tables. Could you please be more
> specific? Is there any bug number?
Since i have not found a single bug report for this, I changed the text on
news.opensuse.org for now until this gets clarified. The persons writing the
text are currently travelling back from SCALE, so I cannot get a direct answer
from them ;-(
Andreas
--
Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org}
Twitter: jaegerandi | Identica: jaegerandi
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
Maxfeldstr. 5, 90409 Nürnberg, Germany
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] renamed MACASSGN_TEXTBAUST -> MACASSGN_AUTOTEXT
Sorry - I accidentally pushed that patch while I pushed some translation patches. So if there are any objections please explain, how I can undo this... Christina Rossmanith Am 25.02.2011 21:52, schrieb Christina Roßmanith: Hi, the "Textbaustein" (German) feature is "auto text" in LibreOffice. I renamed the constant accordingly. Build of sw was successful. Submitted under LGPLv3+ / MPL Christina Rossmanith ___ 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] renamed MACASSGN_TEXTBAUST -> MACASSGN_AUTOTEXT
On Fri, 2011-02-25 at 21:52 +0100, Christina Roßmanith wrote: > the "Textbaustein" (German) feature is "auto text" in LibreOffice. I > renamed the constant accordingly. Build of sw was successful. Lovely; please do commit it :-) with this stuff, if you don't have to change a .idl file, and nothing in the 'ure' directory - you are safe to commit such cleanups without review :-) [ assuming that it builds; using 'g grep' can help give confidence too :-] ATB, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Windows installer size reduction effort - the compression theory
Hi Kami, Wow - I'm so sorry, I missed your sexy mail for a week; that sucks - over-much merging on another branch :-) Tor has been on FTO, and Fridrich with his head down releasing 3.3.1 (and the Novell LibreOffice product) - which in part explains the lack of response to you (and Steven) - which sucks - sorry guys. On Tue, 2011-02-22 at 17:32 +0100, Kálmán „KAMI” Szalai wrote: > I ran few test to figure out what is the best method for installset These look great, nice spreadsheet. > So I went to other direction, whatif I increase the efficiency of LZM > compression of makecab. I found that we can use .Set CompressionMemory= > 21 setting. This setting produces 83,91% of original installer size and Oh - nice :-) that solves the install-space problem as well. > In the gray section I tried a special way when I uncompressed every > zip container (ODF, JAR, ZIP, etc) in the installset and every file > contains only stored data without compression. In this way I was able > to gain more 15 MB, but this require zip recompressing at the end of > installation process that may make it to complex and time consuming. > Please check the attached document, and if you want to go with it > apply the attached patches. Oh ! that sounds fun :-) 15Mb for that. Actually on master - we could use flat ODF files and get the same result (for some on-disk size growth) without having to re-compress, and they're dead fast in master. So - personally, I find it amazing that ZIP is better than LZMA - ever, it is such an older compression algorithm, and this flies in the face of everything I've seen in practise with it [ eg. we use LZMA for our RPMs in openSUSE these days AFAIR, better than bzip2, which in turn was better than .tgz (essentially zip) ]. It'd be great to commit the first patch but can we instead hack: solenv/bin/modules/installer/globals.pm to patch: $cabfilecompressionlevel = 7; rather than hard-coding that and leaving the variable there. The second - can you really confirm that LZMA is worse than zip ? Anyhow - great work :-) Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] OpenSuse 11-4-rc2 claiims LibreOffice has minor bugs
On Monday, February 28, 2011 11:55:28 Michael Meeks wrote:
> Hi Marc / AJ,
>
> On Sun, 2011-02-27 at 21:56 -0500, Marc Paré wrote:
> > We just had this posted on the Marketing list. I am not sure if this is
> > true. Can anyone comment on this? Are there reports of loss of data?
>
> This is news to me too; AJ - where did this block come from:
I'm already on it - but indeed, I have not found evidence yet.
> > raft of new functionality has created a few specific issues, such as
> > loss of data in tables. Though not quite ready for the production
>
> And why ? it would be extraordinarily helpful to know - we're not aware
> of this bug, and it sounds serious. It would also be great to know who
> was pinged from the SUSE / LibreOffice team before including that.
Andreas
--
Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org}
Twitter: jaegerandi | Identica: jaegerandi
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
Maxfeldstr. 5, 90409 Nürnberg, Germany
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
