ESC / Rome discussion ...

Michael Meeks michael.meeks at
Wed Oct 11 15:46:20 UTC 2017

Rather free-form, and not entirely serious:

Miklos‘ (Heretical) style plan
	Encouraging style consistency – with tooling.
	Re-formatting the whole code-base is rather controversial
	Compromise: build a black-list of all existing code, for new code enforce existing style
	Do we want that ?
		If so – use clang-format – seems to be most mature project for this.
			LLVM, Chromium using this
			a new dependency for a developer
			life of windows/mac devs should be easy.
				Provide statically linked windows / mac here.
					Chrome already does this.

	What should be the actual config ?
		3 years ago – Caolan sent a clang-format config, see
			close-enough to the binary doc-filter.
		some git-hook to enforce this for non-black-listed files.
	Bit of perl hacking for the git commit hook needed.
		Good to get input from the wider community first.

	If you say – existing code is allowed to keep its diversity (Bjoern)
  		only new code in specific style.
		Derive from class that is pre-existing.
		Criteria would be per-file (Stephan)
			style is mostly white-space (Miklos)

	Lets try to avoid lots of new file splitting (Michael)

  	If someone does a very large change in a file anyway (Kendy)
  		and if not touched very often, no back-port pain
		re-formatting could be possible
		if done for lots of files → ESC.
		Cosmetic renaming in writer just before branch (Miklos)

	Last 3 months – 150 new files (Miklos)
		A good test-bed.

	New vs. Renamed files (Stephan)
		when we get to the point that we can‘t see it is moved.
		When move a file – do cleans as separate commit.
		Important it is an easy-workflow
			Can you add a demo for this ?

	Requirements – enforcing script (Miklos)
		print a diff – and auto-fix your code so doesn‘t have to be manual
		Chromium does this automatically … a pre-gerrit hook.
		Can do something similar for pre-gerrit.

	Would you have a website to see what it should be ? (Cloph)
		not planned (Miklos)
			some website with clang-format options.

	Style bits doesn‘t break stuff on master (Bjoern)
		If it is wrong, doesn‘t break someone from working on master.
		Is it better to start with a weekly that fixes up the style in new commits
		Prefer a single commit (Miklos)

	Like an option of a different clang config per sub-dir (Michael)
		The benefits should out-weigh the ideas of what code should look like (Stephan)

	Chromium – clang-format gets a number of fixes (Stephan)
		using clang-trunk / your version from your distro
		if they have different ideas: turns into an edit-war.
		Is it a real issue for Chromium ?
			Clang-format developers guarentee some back-compat
			What does Chromium do for this ?
				1 layout-change; sort include in the same block alphabetically
				system-headers previously, others afterwards eg.
				Small enough to live with it.

	Chromium – has a static binary provided even for Linux → same everywhere.

	Do we want to re-order headers ? (Kendy)
		can break the build – in a new file ? …
		if this happens – can fix the code – headers self-contained (Miklos)
			just an example of behavior change.
			Currently proposed config doesn’t sort includes (Miklos)

	Should Miklos come up with a prototype ?

Image format / separate Alpha (Caolan)
	Dual bitmaps – normal content & doesn’t map very well
	Transparency is different to cairo, Mac, and GL.
		0 is complete transparency, 255 means transparent (VCL)
		we re-write all our alpha as we use it.
	Would be nice to have ‘normal’ RGBA bits.
	Would kill the old 16bit horrors in the X11/VCL backend
		drop old / non-24bit X – and re-use gtk3 / cairo backend for everything.
		Drop the generic backend.
			Useful for bisection (?)
		If we’re 24bit – can remove the transparency.
			Keep an eye out for the meta-files.
			Push it out the file-formats.
		Should give more acceleration on the H/W
	Drop X11 / 16bit and below stuff.
	Use cairo for gtk2 and generic backend.
	Skia – unclear how to do things
		Cairo has extensive documentation.
	How would it affect KDE ? (Kendy)
		which one ? Old KDE integration re-uses generic (Caolan)
		new-one; takes same approach as gtk3
		taking content of Cairo surface → putting in there.
		Expect Bubli’s VCLplug re-uses the cairo backend too.
	Did some experiments to get Alpha into Bitmap & VirtualDevice (Tomaz)
		Doing this with cairo & gtk
		Was mainly working; backends need changing.
			Windows backend needs most work.
		OSX needs some too
		Need to use GDI+ or Direct2D for alpha – not GDI.
		For bitmaps → now use GDI & GDI+ thing – needs work.
		Checkout: feature/nativealpha

Mergelibs ? (Noel)
	we ship with it as of now (Cloph)
		was off for a tinderbox only

Anyone looked at T-san (Noel)
	Stephan had a look; but got stuck.
	Reports many of multiple mutexes / lock-order violations.
	Main thread – lock A/B vs. B/A
		never cause problems but both on main-thread and recursive(?)
	Very useful.

Java OID hash collisions (Stephan)
	did have some problems 10 years ago using hashid for identity
	thought it had become a non-issue in the meantime.
	Horrors with Java in the past (Michael)
		could be this (Stephan)

Working on protected / private / scope bits (Noel)
	trying to find things that make sense here
	lots of classes with grim public/private/etc. In-line

Modeless dialogs ? (Caolan)
	Really nasty sequences of grabs to get right 
		modeless – focus onto the intermediate bits
		lot of problems getting it right.
	Extra argument to the file-dialog, to get transient parents right.
	Not a good idea to do this for app dialogs unless in Kit mode
		Grim transience issues closing dialogs in the stack.
	No argument against it in concept (Caolan)
	Synchronous and Async execiute in base ‘Dialog’ class 
	tdf#88101 – practical example of focus.

Linux32 / Java / LibreOffice explodes bug (Bjoern) 
	un-resolved in Fedora (Bjoern)
		what is the impact on 	quality ?
		Makes LibreOffice crash
			Kernel fix vs. Java fix …
	Security mitigation wrt. Stack (Michael S)
		guard-pages – used to be 1 now 1Mb
		JVM does bizarre thing on stack, work around
		in JVM busted by sec. Fix in the kernel
	as TDF we shouldn’t do anything (Stephan)
	could just not provide 32bit binaries & see what happens (Cloph)
	Ubuntu seems to drop 32bit Linux (Bjoern)
	Should we drop our own Linux / 32bit builds for 6.0 (Michael)
		perhaps just harder to find (Cloph)

More information about the LibreOffice mailing list