500conversions

Converting LibreOffice dialogs to .ui format, 500 conversions milestone

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

Using the guesstimate tool ./bin/count-todo-dialogs the current status is:

500 .ui files currently exist
There are 213 unconverted dialogs
There are 127 unconverted tabpages
An estimated additional 340 .ui are required

Digging down a little there is just 1 tabpage + 2 dialogs in draw/impress (sd) and 6 tabpages + 8 dialogs in writer remaining to convert from the old format. The remainder are in calc or in the various shared modules.

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

UniString

Death of UniString

It's always been a source of frustration for me that LibreOffice and its predecessors had two different String class families. A "new" set in sal and an "old" set in tools, where "new" is > 13 years old. Each set had a string for 8 bit characters and one for 16 bit UTF-16. The old classes are limited to 64k characters while the new ones use a 32bit length.

So, one of the oldest easy hacks we had on launching LibreOffice was
Removal/Replacement of the String/UniString with OUString once and for all. We managed quickly enough to remove the old 8 bit "ByteString" class, but the UTF-16 UniString class lingered on.


Now finally, after being painstakingly chipped away one method at a time and incrementally brush-clearing one file, one dir, one module of the enemy string, UniString is gone. I think this commit is the one that removes the last stray UniString usage from LibreOffice.

While a load of people worked on this, Noel Grandin put in an awesome effort to convert  a staggering amount of code over to finish this.

Now we just need to
a) update our wiki pages to root out all mentions of UniString
b) audit and remove the uses of the 64k STRING_MAXLEN limit define and remove that length limitation in places like max paragraph size allowed to be imported from .doc and .html files

New Menu Placement

Traditionally if a menu can't fit in the available desktop space in LibreOffice it gets rearranged to some other location where it does fit. So first attempt is underneath the menu entry, then above, then left, then right. Which can give this type of placement.

Which is rather undesirable. For Libreoffice 4.2 for menus from menubars we will just attempt placement under or above and on failure to fit, then pick which has the most space and place there anyway and instead scroll. Like so:

Which means that you can always just move left and right after activating a menu to navigate to the next one without a poorly placed menu getting in the way.