LibreOffice / Future / design notes foo ...

[Michael Meeks]

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 at collabora.com  <><, Pseudo Engineer, itinerant idiot