LibreOffice / Future / design notes foo ...
michael.meeks at collabora.com
Thu Sep 4 08:41:08 PDT 2014
Somewhat random, but perhaps there is value in dumping whatever madness
I captured during this discussion on the list:
* Talk/Workshop: Thoughts on future core design ...
A BOF session, where developers can get together to chew over
the next big opportunities for improvement in the code-base, and catch
up with status on existing re-factorings. Several areas of work will
be highlighted, from re-using LibreOffice code, to threading and
rendering infrastructure, VCL widget lifecycle and more.
* Translation framework
+ move to boost' gettext compatible foo
+ multi-thread-safe, suitably licensed
+ Switching from STR_FOO_BAA -> _("baa")
+ goal: move to 'Deckard'
+ shows http://deckard.malizor.org/
+ an incremental approach:
+ smallest SRC -> .po
+ initialy bootstrapping & then ...
+ "string lists" bit of a pain.
+ migrating translations
+ remove all "ImageLists"
+ lists needed for packimages
+ can we tokenize gettext strings (Kendy)
+ cf. binary size.
+ concern wrt. 60Mb iOS images etc.
+ size of translated resources will double (Andras)
+ every .mo file will have en & fr eg.
+ problems with Windows installer too
* do it - when we have an in-binary size fix.
+ concern wrt. .mo etc. file size
+ should look at Blender too (Caolan)
* VCL lifecycle
+ switching to reference counted / smart-pointer
for all VCL Window sub-classes
+ first - find all stack / member created Windows.
+ Noel has a clang plugin to build list
DialogBox aBox( "Hello World" ); // must die
+ its a big - change (Caolan)
+ Lots of 'IsDead' canary checking
* dbgutil vs. normal builds (Miklos)
+ ABI compatibility issues between dbgutil and not
+ changing #if OSL_DEBUG_LEVEL > 1 -> #ifdef DBG_UTIL
+ sw/ was fixed by Bjoern already
+ would love to have 1x not 2x orthogonal bits (Bjoern)
+ not having intersection of different ifdefs
would be good.
+ single one wouldn't work (Michael Stahl)
+ debug STL bits.
+ problem is enabling debug STL to dbg-util ?
+ nice to build just a few bits with debug (Miklos)
+ fundamentally opposed to incompatiblity and useful.
+ extra OSL_DEBUG_LEVEL's > 1 - tend to dump random files
+ finds confusing SAL_DEBUG / SAL_INFO / SAL_WARN (JanM)
+ finding, cataloging & isolating threads that
do VCL / GUI stuff.
+ not -that- many problem sites (?)
+ the ideal sol'n (Noel)
+ the UNO bits are a problem
+ heaviest problem - UNO remoting - all threaded (Sberg)
+ Junit etc.
+ concurrency here.
+ ideal to have 1x dedicated GUI thread
+ JUnit - needs re-working ? (Michael)
+ main work in core impl.
+ writer objects with UNO interfaces
+ could not depend on locking SolarMutex ...
+ use UNO appartment stuff to move ~all core
app UNO calls to that main thread
* DECL_LINK cleanup ?
+ could we use a wrapper around boost::signal (Bjoern)
+ kill them all with an easy hack ?
+ do we require linkage to a library ? (Caolan)
+ good to have a mass-conversion ? vs. wait for C++ 11 (Miklos)
+ C++11 Lambdas rock (Ptyl)
+ mechanism - prolly orthogonal to lamdas (Stephan)
+ 2x different issues.
* Switching to GL rendering (Markus)
+ a new VCL backend based on OpenGL
+ useful for wayland (killing the Linux/X rendering)
+ also critical for mobile
+ can implement a more powerful & fast rendering API
+ free gradients etc.
+ also - finishing GL canvas / drawinglayer
+ rendering scene graph directly.
+ moving co-ordinates to float
+ can we switch to OpenGL everywhere & deprecate (Michael)
+ mobile platforms, Mac + Windows: good OpenGL
+ Linux - ... horrible GL versions etc.
+ 3.2 base-line preferred
+ impacts 50% of Linux users.
+ move from OpenGL 2.1 to 3.1 is a big step
+ writing for something obsolete now
would be sad.
+ OpenGL 2.1 not so controversial.
+ No other long term solution for Linux
+ everyone moving towards GL
+ with S/W fallbacks / llvm-pipe etc.
+ native toolkit integration yet more fun with GL.
+ hoping to use UI / layout to get native widgets (Caolan)
There were another set of issues that we didn't really get
to that may or may not make sense.
* VCL issues
+ main-loop / priorities
* Image issues:
+ BitmapEx - in-line and/or pre-multiplied alpha [!]
+ image handling
+ SfxItemPool / PoolItem - lifecycle etc.
+ add a 'hash me' function ...
+ internal hashing [!?] ...
+ kill more 'Tools' classes ?
+ Color (COL_RED) ?
+ polygons ?
* Core bits:
+ Killing the old SvStream / binary-file-format stuff ..
+ copy/paste in editeng still using it ...
+ complicates & slows down the SfxItemPool eg.
+ LibreOffice Kit
michael.meeks at collabora.com <><, Pseudo Engineer, itinerant idiot
More information about the LibreOffice