ESC / Rome discussion ...

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)