Older blog entries for caolan (starting at number 270)

28 Feb 2016 »

native gtk3 menubar in libreoffice

Following quickly on native gtk3 popup context menus is implementation of native gtk3 menubar and menus.

For comparison here's the (not utterly awful) emulated look prior to this. You can compare the spacing of elements in the menubar, menu separator rendering, distance of checkmarks to the following text, the display of the short cuts in different font attributes with different positioning, and menu entry line spacing.


This is mostly achieved by reusing the export of the toplevel menubar and menu structure via GMenuModel work by Antonio Fernandez and Bjoern Michaelsen and just stuffing a GtkMenuBar into a GtkGrid in the toplevel widget and moving the LibreOffice "guts" widget a level down with no LibreOffice menubar visible.

Syndicated 2016-02-28 21:14:00 (Updated 2016-02-28 21:14:58) from Caolán McNamara

24 Feb 2016 »

current LibreOffice native gtk3 elements

LibreOffice typically basically has just one gtk widget per top level window and draws everything you see itself, using the gtk themeing apis to make what it draws look like they do in gtk.

But there are some truly native gtk elements. Some of them new.

 

Tooltips


Tooltips, like the above transparent example, are real gtk tooltips now. Here's what they used to look like

 

Popovers

We recently in master began using GtkPopovers for informational messages such as the above calc formula formatting help.

 

Context Menus

As of today, context menus are native Gtk menus. This has the advantage of making managing overlarge menu scrolling all a gtk issue instead of faffing around endless in vcl to emulate what a native gtk menu would do. Flipping on/off mnemonics depending on keyboard input or whether the menu was launched by keyboard instead of mouse similarly becomes "someone elses problem". Here's the same menu launched via the menu key, automatically with mnemonics on start.
The menubar and menus launched from that menubar are currently still emulated ones, but they're the next target for nativization. We have mechanisms in place for the MacOSX and Unity menu integration that can probably be adapted and extended to support driving a native GtkMenuBar hosted in the GtkFixed-alike toplevel widget that fills each toplevel window.



Syndicated 2016-02-24 16:54:00 (Updated 2016-02-24 16:54:21) from Caolán McNamara

16 Feb 2016 »

gtk3 and LibreOffice

Couple of changes to the gtk3 support in LibreOffice master recently.

Theming stuff

The gtk3 support in master LibreOffice is now updated to support the relatively recent changes in gtk 3.19's style mechanism.

With mclasen's help I've added simple demos to the foreign-drawing demo of gtk-demo for the different elements that we render via those rendering apis. So what we attempt to do in LibreOffice is basically documented in gtk-demo now. So from 3.20 onwards if there are styling flaws in LibreOffice, then gtk-demo can be checked if it has the same problem or not.

Drag and Drop

Drag and Drop is now implemented in the gtk3 backend. DnD here includes moving blocks of cells around a calc spreadsheet using the mouse alone.

Wayland gstreamer video playback

If the gtksink gstreamer element is present (e.g. gstreamer >= 1.7.1 as in Fedora 24) then the gtksink gtk widget integration will be used to play video. Which means support for video playback in LibreOffice under wayland.

Syndicated 2016-02-16 16:39:00 (Updated 2016-02-16 16:39:56) from Caolán McNamara

20 Nov 2015 »

Better polygon rendering in LibreOffice's Gtk3 Support

Above is how LibreOffice's "svp" backend rendered rotated text outlines in chart where the text is represented by polygon paths. Because the gtk3 backend is based on that svp backend that's what you got with the gtk3 support enabled.

After today's work above is how the svp backend now renders those paths when rendering to a cairo-compatible surface such as the gtk3 support provides.

If we mandate that "svp" only operates on cairo compatible surfaces, then we can get this niceness into android and online too, and can ditch our non-cairo text rendering code paths.

Syndicated 2015-11-20 13:17:00 (Updated 2015-11-20 13:18:21) from Caolán McNamara

13 Nov 2015 »

Insert Special Character in Spelling Dialog

LibreOffice 5.1 spelling dialog now has a little toolbar to enable inserting special characters into the spelling editing widget. Also Added paste, so the insert icon isn't lonely.

Syndicated 2015-11-13 10:57:00 (Updated 2015-11-13 10:57:38) from Caolán McNamara

23 Oct 2015 »

finding UI crashes by fuzzing input events with american fuzzy lop

As mentioned previously I've been experimenting using afl as a fuzzing engine to fuzz a stream of serialized keyboard events which LibreOffice reads and dispatches.

Performance is still pretty poor, but by tweaking our headless mode to allow dialogs to be created, then using that headless mode for eventtesting and then hacking out the actual rendering of the UI to the headless backend I've got something that performs reasonably well enough to enable me to set a far higher limit of 50 input events per cycle and start to discover real bugs in impress.

  1. 5.1 only crash in impress sidebar under some circumstances
  2. null marked obj still in impress mark cache
  3. another null deref in impress sidebar panels
  4. crash in impress if you exit while the annotation window is open
  5. divide by zero in an impress sidebar panel
  6. another annotation window null deref issue
  7. crash on sending a keystroke to an empty impress page list widget
  8. missing dispose on annotation windows
  9. missing dispose on alive by unshown panels
  10. crash if frame is destroyed before keystroke gets to it
  11. crash if you close impress main frame while slideshow is running

all of which is encouraging, though some of these are possibly very unlikely in real world use. But the prized find is

intermittent crash on undo of insert slide

because I've seen that happen plenty in the real world, and is the problem I was hoping to find.

Turns out its been so difficult to track down because there's a timer involved which is triggered by earlier modifications to the document. To get it to crash by undoing insert slide you have to modify an object in the document, which triggers an object-modified timer, and then very quickly, before the modified-timer fires, undo insert slide. Which has the effect of impress not registering that the slide has been deleted. Some time later, in far away code, impress will crash on use of the deleted slide.

afl-eventtesting was able to find a sequence of keystrokes (which isn't a huge surprise seeing as I primed it with some insert and undo slide sequences so it didn't have to mutate things too far before it modified a document object after an insert and before the undo) to trigger the crash and the eventtesting + headless modes of LibreOffice gave a reproducible platform where the same events happen in the same sequence without any intermediate system-ui events to throw off the delicate timing. Once the thing is reliably reproducible then its just a matter of grinding through the debugging.


Syndicated 2015-10-23 11:52:00 (Updated 2015-10-23 11:52:12) from Caolán McNamara

15 Oct 2015 »

fuzzing LibreOffice input events with american fuzzy lop