* 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.me...@collabora.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
