minutes of ESC meeting in Bruno ...

[Michael Meeks]

* Present:

    + Caolán, Michael M., Thorsten, Miklos, Stephan, Andras, Tomaz, Tor,
Jan-Marek,

      Eike, Olivier, Giuseppe, JanI, Xisco, Matus, Armin, Robinson,
Norbert, David,

      Michael S., Samuel, , Andreas, Heiko, Lionel, Pranav, Christian,
Bjoern

    + and many more people in the room.

 

* Legacy plugins

    . activex plugins going away soonish

    . notified for removal in the future already ?

    . we use the COM bridge very actively (Michael)

        . ties into the ActiveX control (Thorsten)

        . the other consumer of get the native handle API (Caolan)

            . firefox plugin native handle pieces got cargo-culted in.

        . declared ActiveX deprecated in 5.1 release notes (Stephan)

        . concern wrt. native handles (Caolan)

            . gtk3 has complexity to handle X11 and Wayland.

    . canvas using it ? (Michael)

        . not sure its used (Thorsten)

    . native video backends (Caolan)

        . gstreamer has all the magic wrapped in a gtk3 widget

    => keep handles for now.

 

* Cairo canvas vs. VCL 100% cairo rendering ? (Thorsten)

    . probably entire canvas story can be cleaned up quite a bit.

    . newer OutputDevice features for nice polygon rendering etc.

    . so - up for dropping the cairo-canvas backend.

       . consolidate remaining things down into VCL API ideally.

    . still wrap the cairo API ? (Kendy)

       . not recommending using Cairo directly in the codebase (Caolan)

       . nothing against with cairo on all platforms as default impl.

       . but not use directly - need GL etc. (Michael)

    . GL canvas backend uses VCL directly for acceleration (Michael)

        . DirectX backend has a number of wins (Thorsten)

            . compositing, running animations.

        . using OpenGL instead - good idea (Thorsten)

            . abstraction is not ideal.

            . need to check compositing around animations & performance.

 

* VCL - move to indirect rendering ? (Michael)

    . would like to move every platform to do indirect rendering.

        . ie. to a back-buffer.

    . currently Mac, GL/Windows, gtk3

    . would love to render to an OutputDevice centrally ... (Michael)

        . rather than per backend.

    . would like to have a way to not render direct (Tomaz)

        . the swapbuffer issue - we already have another buffer ...

    => no objections to moving this way

 

* Harfbuzz layout (Caolan)

    . there on all the linux platforms.

    . project completed to use it on all the other platforms too.

    . it can be integrated with harfbuzz disabled for new platforms.

    . love the same shaping backend everywhere (Michael)

    . can create test cases for eg. PDF output, on every platform (Caolan)

    . concerns resolved wrt. harfbuzz dedicated windows backend (Thorsten)

        . wrt. windows font rendering.

    . assuming it works well on platforms ?

        . better font shaping on platforms ? (Tor)

           . can use Uniscribe on windows if necessary (Caolan)

    => switch to harfbuzz exclusively everywhere.

        -> check the known issues.

        

* rename all environment variables (Tor)

    . some with VCL_ some with SAL_ etc.

    . with some mapping ? deprecation ? (Thorsten)

        . if you like, no-one switches.

    . clang plugin for this preferred (Norbert)

* Office Bean - is it still useful ? (Caolan)

    . not much maintenance needed (Stephan)

    . customers using it (Thorsten, Michael)

    . problem is the native window handle eg. wayland etc. (Caolan)

    . can deprecate - so not supported on new platforms ? (Thorsten)

 

* VCL de-couple meta-file from file-format (Tomaz)

    . use SVG in the future ?

    . still used for slideshow & PDF export (Thorsten)

        . hate it for past 15 years.

    . suggestion - not to throw away meta-file, but allow changes (Tomaz)

        . an internal meta-file flag as a transport - never serialized

    . drawing layer primitives close to what you want (Thorsten)

        . but not in VCL.

        . svg maps to primitives.

    . use tiny svg instead ?

 

* VCL change proposal (Caolan)

     . drop TDE, keep KDE4 stuff until there is a KDE5 version

       have a single KDE backend - to avoid parallel pieces.

          . should we not just integrate with Qt ? (Tomaz)

              . plan is for us to do the KDE5 work in 2017 for
our 2018 release (Jan-Marek)

                  . kio & mounted network shares important in the file
picker

                  * probably we can do a Qt5 one and extend it with KF5
stuff - will see (Jan-Marek)

                    KF5 is supposed to be modular enough

     . remove ability to use 'gen' / X11 only VCL plug

         . on windows can run without theming (Kendy)

             . possibility to test generic theming ?

             . goes through code-paths, where no native widget rendering

             . Windows 95-alike scroll-bars.

             . already a switch to disable native widgets (Tomaz)

         . gtk3 - lots of stuff truly native (Caolan)

             . menus, tooltips, toolbars, etc.

             . so can't disable those but ...

         . eager to improve that code for online (Michael)

     . use the headless backend

     . what version of gtk2 in our CentOS 6 base-line ? (Caolan)

         . gtk 2.24 - becomes the absolute minimum you need.

         . so we will require this.

         . CI but is CentOS7

     => retire TDE, single KDE4 backend, no gen backend.

     

    + what if there is a gtk3 vs. gtk4 change ? (Tomaz)

         . plan to have gtk4 unstable initially

         . wouldn't follow the unstable bits (Caolan)

             . and pick a place to jump to gtk4.

* Java build-time requirements (Thorsten)

    . people doing java stuff - want a new version.

    . objections ? would like to go to 1.7.x

        . generics and improved run-time

        . some consumed projects are now 1.7+

        . using 1.7 in Munich (jmux)

            . build-time not run-time requirement (Thorsten)

        . validator consume java projects that require 1.7 (Thorsten)

        . build-time will prolly require new run-time ? (Stephan)

            . already doing this for CI build bits - no issues (Norbert)

            . target environment is set to 1.5 already (Thorsten)

    . gcj bits removed recently ? (Miklos)

        . Rene was ok with moving (Thorsten)

            . using OpenJDK anyway now.

    => require 1.7 for build, and 1.5 for run-time in master / 5.3

 

* "Speaking of wiki build instructions, the IDE instructions for Windows
have

  not worked for almost a year now." (Bjoern)

 
- http://nabble.documentfoundation.org/Recommended-build-instructions-tp4193014p4193353.html

  - srsly, whats wrong with contributors building on win that they dont
fix this?

    (either in the build or at least in the documentation)

-- 
michael.meeks at collabora.com <><, Pseudo Engineer, itinerant idiot