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 https://lists.freedesktop.org/archives/libreoffice/2014-August/062802.html
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 ?
Yes.
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)
https://lkml.org/lkml/2017/7/4/610
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)