Estimated read time: 1 minutes
We were in Munich during this weekend, and I think all of us had great fun, kudos go to the organizers! If you are curious, there is a growing list of features implemented during the event.
Update: Oh, and I forgot to mention that we (Andras and me) especially thank the FSF.hu foundation for funding our travel!
Estimated read time: 1 minutes
The next major LibreOffice version, 3.4, means some work for (Linux
distribution, and other) packagers, as the build repo is now
deprecated and packagers are suggested to use the bootstrap repo
directly, which is a different build system.
On one hand, this is a nice cleanup - there is now a single configure script. OTOH this needs major rework of distro build scripts.
The interesting part here is that the official binary installers are not
using the make DESTDIR=/some/path install method to install the
compiled binaries, so it was discovered quite late that it wasn’t
working properly. First Hanno and Petr
worked
on this, then I
fixed
a minor, but blocking glitch.
As a result 3.4 beta4 will be something packagers (even the ones not using the split build) can offer to distro users for testing without patching. Binaries for Frugalware users here (i686-only at the moment).
Estimated read time: 1 minutes
I just got the mail about my LibreOffice proposal got accepted to Google Summer of Code 2011. I’m looking forward to an exciting summer. :)
Estimated read time: 1 minutes
LibreOffice 3.4 will have a new feature, if you edit styles in Writer, then you can test your style changes without manually closing and opening the style edit dialog again.
Do you like this feature? There are still similar remaining dialogs to improve like this, send in a patch!
Estimated read time: 1 minutes
I got a report about two problems which got fixed in master now.
The first error is triggered, if you have special (in RTF terms, so for
example { or }) characters in style names. The result was not so
friendly when you opened such a document:
After applying the first fix, the document was imported but the original Тест text was replaced by something non-unicode:
The second fix addresses this, and now the result is the expected one:
Estimated read time: 1 minutes
There was a thread about this topic already, but just refusing to commit new files without documentation sounded too aggressive. So the current code just prints a warning.
It was also requested to show some good/bad examples. Lubos volunteered to add detailed instructions in the wiki, so I’m just describing in short what did I test so far.
A good example:
/// Handles export of foos using RTF markup class RtfFoo { };
A bad example:
class RtfBarBuggy { };
Example output when a warning is emitted:
~/git/libreoffice/master/sw$ git commit -a -m foo
sw/source/filter/ww8/bar.hxx:30: warning: Compound RtfBarBuggy is not documented.
[master 1b11571] foo
3 files changed, 68 insertions(+), 0 deletions(-)
create mode 100644 sw/source/filter/ww8/bar.hxx
create mode 100644 sw/source/filter/ww8/foo.hxxEstimated read time: 1 minutes
I’ve got a report which turned out to be two separate issues. One is a regression from Go-OO 3.2.x, this post is about this part. The other part is about the improvement of both the import/export RTF filter, the bug has some detail on that part as well.
So the problem was that wrapped images (when the image is a frame and not a character) had some extremely small height. I did not notice this bug in LO as an LO-specific extension hides that value, but in Word you can see it:
The fix is to use the height of the containing frame instead of the height of the picture itself, then it’ll look fine:
Estimated read time: 1 minutes
About four days ago it has been asked on #libreoffice if it’s possible
to bind functions to F13..F16 in Calc. The short answer is no, but it
turned out it’s pretty trivial to allow that (and of course not only in
Calc).
Cedric’s great post is helpful here to find the relevant code. It also truned out that VCL already supports those keys, so only the user interface has to be improvied to export that feature.
The patch is here.
Estimated read time: 1 minutes
Background: OSL_TRACE() is an internal LibreOffice macro that is like
printf(), but it’s only enabled in debug mode. Without it, you would
add a debug printf during development:
printf("debug, foo\n");
then you would comment it out when the code started working,:
//printf("debug, foo\n");then remove the comment when it breaks again, etc.
In the past, if you built a LibreOffice module, then you executed:
buildinside a module, and in case you wanted debug symbols and such messages you built using:
build debug=twhich increased the debug level to 2 (from 0), where 1 is required for debug symbols, 2 for debug messages. (See the OOo wiki page.)
The recent update, why I’m writing this post: Now this has been
changed,
and debug=t gives you debug symbols only, but no extra debug output.
While this is
great
in most cases, sometimes you still want the old behaviour to get the
debug messages. In that case the solution (as pointed out in the mailing
list post) is to use:
build debug=t dbglevel=2(Hopefully this post will be handy for who missed that post, like I did the first time.)
Estimated read time: 1 minutes