Caolan McNamara

Piggy backing on some of the Unity LibreOffice Application Menubar work and the existing support for the MacOSX equivalent. I finally got around to adding a GNOME3 application menu to LibreOffice

We’ve now reached 300 dialogs and tabpages converted from LibreOffice’s classic fixed widget size and position .src format to the GtkBuilder .ui format.

So, by my earlier estimates this puts us at about the half-way conversion mark.

The How to conversion guide is still relevant, and help is always appreciated.

In terms of writer, the major dialogs which are not completely converted are the frame and “table of contents” ones which are only partially converted, while there’s no conversion of any of the hyperlink dialog pages yet. While the paragraph and character dialogs are now fully converted over.

My WAC700′s hard drive died a while ago, and my efforts to find a disk image I could use to clone a replacement didn’t pan out, leaving me with three useless WAS700 stations which I wanted to reuse as generic stations playing back from a software ps3mediaserver solution. But the blasted stations were configured to use some now long-dead wifi configuration I wasn’t using anymore and they need the station in order to be reconfigured to use a new wiki config.

This thread looked promising, but no success

On the other hand the source for the WAC700 is available from philips, so with a bit of digging it turns out the WEP key for the WAS700 ad-hoc installation mode network WASC700-INST is PHILIPS123XYZ and not Philips123ABC or PhilipsABC123

With the right key, then the WAC700 emulator works wonderfully to reconfigure the stations, and then they can easily find and playback from the ps3mediaserver via auxillary input->select server.

—
1. wget http://www.p4c.philips.com/files/w/wac700_05/wac700_05_osf_eng.tgz
2. tar xf wac700_05_osf_eng.tgz
3. strings src_release_r4258_6720_1.2.10_en/linux/work/has/appfs/resources/fpm_firmware/20060221_was5_code_IVT1.2.10_release.rom|grep PHILIPS

We’ve now reached 200 dialogs and tabpages converted from LibreOffice’s classic fixed widget size and position .src format to the GtkBuilder .ui format. These are still our own widgets, we just reuse the file format and map the Gtk widgets to our own equivalents. I’ve now finally refreshed the original sample screen shots to reflect the current reality.

I estimate we require an additional 200 to 400 .ui files, unless a lot of the existing .src dialogs turn out to be orphaned dialog descriptions that are not in use. (This is unlikely)

The How to conversion guide is still relevant, and help is appreciated.

Additionally, there’s a short list of selected dialogs awaiting review for any HIG compliance issues or general layout improvements. We have a python script as ./bin/lint-ui.py (thanks leighman) to check for basic compliance with guidelines, but there’s room for improvement, e.g. checking that widgets have mnemonic widgets, etc.

We’ve now reached 150 dialogs and tabpages converted from LibreOffice’s classic fixed widget size and position .src format to the GtkBuilder .ui editable by glade format. I’m getting pretty sick of dialogs by now, dialog fatigue setting in

If you want to help, my last post on the topic, at the 100 conversion mark, has a tutorial on how to do a conversion, and my FOSDEM slides might be helpful too.

Linux LibreOffice 4.1.0 will now support opentype localized forms. Here’s a screenshot of the Linux Libertine O font applied to the same text on each line. One line’s language set to Serbian, the other to Russian. The language of the text gets propagated down correctly to the underlying text layout engine to allow the correct localized Serbian forms to be rendered.

We’ve now reached 100 dialogs and tabpages converted from LibreOffice’s classic fixed widget size and position .src format to the GtkBuilder .ui editable by glade format. I won’t repeat the full reasons for the conversion, but I’m particularly happy with the new accessibility support, both for the new containers and the .ui loaded.

The a11y stuff can now generally be describable in the .ui file rather than sporadic hard-coded calls here and there. And with the new mnemonic widget for label support, setting in the .ui explicitly what a label is a label for overrides the (eventually to be removed) ugly guessing short-cut code in vcl and sets the default a11y relationship between the label and labelee.

So setting mnemonic widgets in LibreOffice .ui files is now strongly indicated.

Here’s a hopefully helpful step-by-step tutorial for converting a simple dialog from .src to .ui

• Tutorial step #1 initial .ui prototype
• Tutorial step #2 improve .ui prototype
• Tutorial step #3 change Dialog constructor
• Tutorial step #4 remove redundant button widget constructors
• Tutorial step #5 remove redundant FixedLine/FixedText constructors
• Tutorial step #6 convert first remaining widget
• Tutorial step #7 convert remaining widgets
• Tutorial step #8 remove FreeResource
• Tutorial step #9 clean unused .src|.hrc remainders
• Tutorial step #10 update help for .ui conversion

Output of sloccount on the fedora libreoffice pre-build unpacked libreoffice, i.e. basically the sloccount of libreoffice minus the external modules otherwise normally found in the cross-distro build like libxml2/mozilla/libwpd/etc. So it’s a lower-bound count of libreoffice. Summary comes to 5,167,387 lines.

cpp:        4567442 (88.39%)
java:        387446 (7.50%)
ansic:        92834 (1.80%)
perl:         49149 (0.95%)
python:       27399 (0.53%)
sh:           18174 (0.35%)
yacc:          8235 (0.16%)
cs:            6648 (0.13%)
asm:           3245 (0.06%)
objc:          2600 (0.05%)
lex:           1991 (0.04%)
pascal:         900 (0.02%)
awk:            849 (0.02%)
csh:            247 (0.00%)
lisp:           115 (0.00%)
php:            104 (0.00%)
sed:              9 (0.00%)

don’t get too bogged down in the small numbers of possibly mis-detected source languages

Just noticed that a random fairly lowlevel-dependency-affecting commit caused four LibreOffice tinderbox buildbots to kick off at the same time. Shorter green bars the faster, so as the Olympics has begun, the gold goes to Norbert’s MacOSX Intel box, silver goes to Norbert’s Gentoo box, bronze goes to my Fedora box… but drug test proves that its an incremental build, not a true from-scratch build, so embarrassing disqualification awards the bronze to Lubos’s OpenSUSE-clang box.

“picture size; don’t use this value for picture size”

“specifies a service which allows interfacing the core components of the core”, that’s clear then I hope.

More nostalgia. Some time around 2010 all the easter egg photos got stripped out of OpenOffice.org. FWIW…
Calc Team circe 2002 (?). What you used to get with =STARCALCTEAM(). This one is still available apparently in the last version of Symphony
writerteam Geordi Release 2002/2003 (?). This one was the last picture you used to get on StarWriterTeam + F3. (Yes, there was a sequence of Star Trek related release names.) I met mmaher, back row, second from right, at my brother’s housewarming earlier this year.
writerteam StarOffice 6.0 Release 2000-2001. This was the earlier version. Seeing as I’m pasted in at the back but mtg (front row, second from right) is present in the flesh it must have been made after March/April 2001 after I transferred from Hamburg to Sun Ireland. Finally met up with mtg at Dublin Zoo + Ballymore Eustace a month ago after a long gap.

The Easter egg police didn’t find them all. At least one of the most ridiculously obscure and pointless Easter eggs still apparently persists in all descendents of StarOffice in each exported .doc. Only mtg ever noticed as far as I know, and only noticed a few months ago after a gap of 11 years or so

The earlier “remove rude comment” police didn’t quite grok the light weight version of hungarian notation we use either, so my use of airlied‘s (then at least) favorite metasyntactic variable in it’s hungarian notation variant of nArse survived that cull and lives on in the rather crufty starmath/equation editor import code.

I miss =game(“StarWars”). If a demonstration was heading south it could always be recovered by launching starwars. “My god, they translated it to German” is the most memorable comment from some LinuxTag or other that I can remember. German was the only language it was in.

Did some tidying today, and inside the box containing my (vitally important) vt220 and (equally vitally important) Ximian Monkey I found some hard drawn class diagrams for the core writer classes. The back of the sheets have some unrelated text with a 1998 date on them. I think I got these from khz who probably got them from jp, looks like that class diagram style anyway. Here’s the scanned pdf for posterity

ohloh reckons that this week the count of commits in LibreOffice belonging to me hit 8000 accumulated over last approx 12 years.

I thought I’d sample each per-thousand rollover to see what they were…

Commit 8000: A minor startup time improvement and code simplication
Commit 7000: fix dnd crash. Generic bug fixing of fdo#39950
Commit 6000: callcatcher: remove unused code. Removing a few hunks of code that get compiled into the product, but that nothing calls. Some of the callcatcher foo which we use to trim the fat off LibreOffice
Commit 5000: Generic bug-fixing from grovelling over abrt traces, rhbz#710004 band-aid for immediate crash in IsAlignPossible.
Commit 4000: Workaround a weird-ass warning. from a minor compiler bug gcc#47679.
Commit 3000: Fix BSD uno bridges. We merged the various uno bridges together for the various unix platforms that use gcc to reduce the burden of maintaining so many. So needed to add the little register return quirk of the BSD platforms.
Commit 2000: Silence the (then) new gcc 4.5 warnings in our code
Commit 1000: Documented FSPA anchor values should override escher attributes when different. Efforts to get object positioning right on .doc import
Commit 1: MSOffice Controls {Im|Ex}port. Apparently my first post-StarOffice commit. Getting those “OCX” controls imported from MSOffice file formats.

Does this mean I’m an awesomely productive coder versus everybody else ? Nah, not really. For one thing, we started off with CVS went through mercurial and end up with git, and there’s generally a lot of difference in how many commits you generate with commit-unfriendly CVS vs git which makes you commit gung ho.

And there’s differences in commit style from one person to another too of course. I tend to generate a lot of commits because I like to refactor and code in “see my train of thought so you (ok me when I have to revisit it) can see where I went wrong if I do” steps rather than dump in a single commit that affects a hundred interconnected things. But it’s all the same amount of code at the end of the day.

Another wrinkle is that various development rules ended up hiding the true ownership of a lot of older commits. e.g.
a) Per day-0-release commits were all flattened of course, I only worked on StarOffice a short while before that event, so that’s a fairly small amount for me. But presumably a truly frightening number of commits for e.g. jp
b) for a while we worked by commiting only to cvs branches which release engineering would merge into master, e.g. this commit is an example, which is why the Hamburg release engineers hold unbeatable commit rates
c) And later the burden of commiting to OpenOffice.org for non Sun staff became almost impossible to bear, e.g. provide install sets for Windows and Linux, get a QA volunteer to QA the install set for you and sign off on it. Which was all pretty hard to do given the speed of the one or two windows buildbots available for the purpose and the limited number of QA people. Much easier to just dump the patch into bugzilla and see if someone inside the bunker could take care of all that for you, e.g. commits like this

liblangtag looks very nice. I wonder if there’s anything in my abandonware localehelper that might be useful to stuff in there. Maybe some of the locale to langtag mapping stuff.

From the things that make me happy department. Years ago our help documentation source was parsed with a bunch of java tools. At the time gcj was the only possibility for us in RHEL/Fedora and the build time for all localized langpacks that we included was about 26 hours in our build system.

Which was a bit depressing.

So I rewrote it in c++, taking super care to keep the same JavaHelp-derived format and so forth. Which brought build times down to about 10 hours.

Which made me happy.

At some stage though, then it was decided to then index our help with lucene, which brought back java as a build-time and run-time dependency for building help and searching it at run-time.

Which made me sad again, though openjdk was the default for us at this stage, so it wasn’t as much of a pain, though that’s why you have that perceptual lag when you first search for a term in help.

But now, for LibreOffice 3.6, Gert van Valkenhoef has ported our lucene code to clucene. helpcontent builds faster, and there’s no lag on searching for something in help.

Which made me happy.

Distro’s that want to use –with-system-clucene will need to build and install clucene’s contribs-lib

Dave Tardon’s new howto cross-compile LibreOffice under Fedora to target mingw32 under Fedora, http://dtardon.fedorapeople.org/mingw/

When debugging font related stuff its typical that the problem can only be triggered by a specific set of fonts. Here’s a rough-and-ready syncfonts script which when given the output of fc-list -v will try and install the fonts that are missing and remove the extraenous ones via yum, which works for the common case

For debugging mail problem, e.g. when debugging some emailmerge stuff in LibreOffice recently, fakemail was really really handy when you have a bug which requires generating a couple of hundred emails in quick succession to trigger.

Released libexttextcat 3.2.0 (Extended Text Categorization used to guess the language that input text is written in). It can be found in this download dir. No code changes from 3.1.1, but adds a large collection of extra language signatures to nearly add the same language support to libexttextcat as LibreOffice supports, modulo languages that LibreOffice supports which don’t have a convenient UDHR translation to use as a basis to generate a language fingerprint.