LibreOffice / Future / design notes foo ...

So,

        Somewhat random, but perhaps there is value in dumping whatever madness
I captured during this discussion on the list:

        FYI,

                Michael.

* 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 ...
                          parallelism.
                        + "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)

        * Threading
                + 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

        * Others:
                + etc.
                + 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@collabora.com  <><, Pseudo Engineer, itinerant idiot