gtk3 vclplug, some more gesture support
With the demo that a long-press in presentation mode will bring up the context menu for switching between using the pointer for draw-on-slide vs normal slide navigation.
gtk3 vclplug, some more gesture support
gtk3 vclplug, basic gesture support
gtk3's gesture support is the functionality I'm actually interested in, so now that presentations work in full-screen mode, I've added basic GtkGestureSwipe support to LibreOffice (for gtk3 >= 3.14) and hooked it up the slideshow, so now swiping towards the left advances to the next slide, to the right for the the previous slide.
gtk3 vclplug, full-screen presentation canvas mode
Newly added simple support to the gtk3 vclplug for "canvas" support which is the thing we draw onto for presentations. Which means the gtk3 vclplug now supports full screen presentations. Which required a whole massive pile of reorganization of the existing canvas backends to move them from their own per-platform concept in canvas to the per-desktop concept in vcl.
So now rather than having only one cairo canvas backend based on the xlib apis which is for "Linux" we have a cairo canvas for each vcl plug. The old school xlib one is moved from inside its #ifdef LINUX in canvas to the shared base of the gtk2, kde, etc backends in vcl, and there is now a new one for gtk3
Presumably there are lots of performance gains to be made to the new canvas backend seeing as I'm just invalidating the whole slide window when the canvas declares that it's flush time but slides appear to appear instantaneously for me and fly ins and move around a patch effects are smooth even in -O0 debug mode so I'll hold back on any optimizations efforts for now.
gtk3 vclplug,I've been hacking the gtk3 vclplug for LibreOffice recently, here's the before image after scrolling up and down a few times. UI font not rendered the same as the rest of the desktop, bit droppings everywhere, text missing from style listbox, mouse-wheel non-functional
gtk3 vclplug, text rendering via cairo
The LibreOffice gtk3 vclplug is currently basically rendering everything via the "svp" plugin code which renders to basebmp surfaces and then blits the result of all this onto the cairo surface belonging to the toplevel gtk3 widget
So the text is rendered with the svp freetype based text rendering and looks like this...
LibreOffice Coverity Defect Density 0.00So today's statistics for the latest coverity run over LibreOffic:
LibreOffice: 5,973,881 lines of code in Selected Components and 0.00 defect density
Defect density is measured by the number of defects per 1,000 lines of code, identified by the Coverity platform
11,751 Total defects, 21 Outstanding, 331 Dismissed, 11,399 FixedThat's the dashboard reported figure. There are 21 unresolved warnings at the moment which works out at a true defect density of 0.003515303, we're in rounding to 0 territory. I reckon 11 of the remaining are really false positives but I'd still like to figure out how to "wiggle" the code to get their data validity check detected correctly.
LibreOffice Coverity Defect Density 0.02
The "lines of code" here is 7,271,857 vs 9,500,825 in older reports because I'm now building against system-libraries instead of building those in-tree in order to speed up the process. Those "external" libraries have always been marked as "ignore in analysis" in coverity so that change has no effect on the defect density of our own code.
LibreOffice: 7,271,857 line of code and 0.02 defect density
Open Source Defect Density By Project Size
Note: Defect density is measured by the number of defects per 1,000 lines of code, identified by the Coverity platform. The numbers shown above are from our 2013 Coverity Scan Report, which analyzed 250 million lines of open source code.
Line of Code (LOC) Defect Density Less than 100,000 0.35 100,000 to 499,999 0.5 500,000 to 1 million 0.7 More than 1 million 0.65
Select and toggle off master elements directly via delete
Master Document Templates
Writer has long had Master Documents. A master document lets you manage large documents, such as a book with many chapters. One odt per chapter, bundled into a single document via a master odm
LibreOffice 4.4 introduces Master Document Templates. What that means is that these Master Document Templates can be added to the Template Manager and from there you can create a new Master Document (odm) based on a Master Document Template (otm). The new odm of course having the same initial content as the Template it is based upon.
Thanks to Máirín Duffy (of Red Hat, Inc.) for prompting this feature. Any failures in execution are mine however.
More Font Support
Playing around with some Mac OS X fonts under Linux I noticed that LibreOffice wasn't listing a lot of them despite fontconfig announcing their existence. A little digging and some very small tweaks means that we now have mac ttf fontname encoding support along with support for version 2 ttc fonts. This is more fixing some oversights (version 2 of ttc came into existence after the ttc support was added so there was a "only if version is 1" condition) than implementing anything particularly new, but now LibreOffice under Linux works with a lot more ttf/ttc/otf fonts than it did before.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!