Development/LibreOffice4

Development plans for LibreOffice 4.x releases
This is about some fine piece of vaporware. It would be the next generation of the UNO-API (which would be introduced with a LibreOffice 4.x releases as an incompatible API) fixing lots of long standing issues of it. This is a page to collect all the topics that need to be discussed when we will decide to release a incompatible API version.

see http://nabble.documentfoundation.org/Proposing-a-new-Easy-Hack-project-consistent-namespaces-td2826117.html and http://sweetshark.livejournal.com/1550.html for details about the origin of this.

Items marked (?) require verifying whether they belong to the section they are in. "LibreOffice4", as used here, usually means "switching to a new LibreOffice version that will allows us to do backwards incompatible changes".

Stuff that people actually will do
In order not to be a vaporware, the current plan is to collect important, binary incompatible stuff that people actually will do. So, please move the points you will do for 4.x to this section, together with your name + ideally with a one line plan how to do the transition smooth (if at all possible) so that we can prioritize.

General changes

 * get rid of oslFileError, FileBase::RC and com.sun.star.ucb.IOErrorCode. Instead just use (32-bit) integers that contain the actual OS errno / GetLastError value. -- tml
 * OK, so maybe that is too radical. But at least FileBase::RC and com.sun.star.ucb.IOErrorCode should be easily removable. (The former maps 1:1 to oslFileError, the latter is very little used.)
 * Check which oslFileError values actually are tested for, drop the others. Add ones for Windows, Mac, iOS, Android specific issues, if needed, and if also adding code to then handle those specific cases. (The current set of oslFileError values map directly to (a subset of) typical POSIX errno values, and might correspond less well with issues on other OSes.)
 * get rid of the UPD / SUPD number (350, 360, 370), the 370minor.mk file and similar weird leftover cruft from CWS days -- tml
 * afaik that is currently used to apply fixes for invalid documents written by broken older versions in xmloff, any impact on that should be evaluated -- Mst
 * stop shipping libstdc++.so.6 on Linux, should be installed by default everywhere by now (and having it in URE prevents gdb from auto-loading python goodies) -- Mst
 * use simply int instead of sal_Int types in places where the exact size does not matter (i.e. should be everything except streaming and possibly UNO API) -- llunak
 * what would be specific benefit of that? -- Mst
 * not introducing bugs by casts, not making the code less readable by casts, no wrong/ambiguous overloads, and, in general, just not having to care
 * overloads generally are unsafe in C++ and should be avoided, whether they use native or sal types doesn't make much of a difference -- Mst
 * if the internal thing is a non-sal type, and there's a UNO API that exposes it, then you have to cast it at the API boundaries, so your proposal seems to me to require more casts than the current situation, and "just not having to care" sounds like a myth -- Mst
 * UNO API is machine independant, so unless we change that it has to stay that way in UNO. Outside UNO its not a LO4 API issue, thus moved to "internal changes" --Bjoern-michaelsen 2012-07-29T14:52:30 (CEST)
 * UNO is not the only public API
 * see also the stdint.h proposal above
 * string API cleanups (obsolete OUStringBuffer, usable operator+, etc.) -- llunak

UNO related changes

 * TimeValue is not correctly osl:: namespaced in sal
 * remove autodoc, replace it with doxygen for IDL documentation -- Mst
 * write in-code documentation for menu and IDL framework -- Lennard
 * remove various HyperLinkFoo cursor properties, and add a HyperLink service instead that works like other TextContent services -- Mst
 * css.beans.XPropertySet contains various add/remove*Listener methods that are largely un-implemented in applications; consider moving these to a new interface derived from XPropertySet -- Mst
 * why does it need to be derived from XPropertySet? IMHO having two separate interfaces that just work together is preferable. Also it does not lead to interface names like XPropertySetWithListeners, XPropertySetWithListenersAndBellsAndWhistles etc. --Dtardon 2012-07-28T07:32:20 (CEST)
 * it doesn't technically need to be derived from XPropertySet, but since we are talking about addPropertyChangeListener and addVetoableChangeListener, why would anybody implement these and not XPropertySet? -- Mst
 * remove obsolete, non-prefixed shlib loader methods in cppuhelper's loadSharedLibComponentFactory and obsolete writeInfo helpers -- mmeeks
 * drop gross, hard-to-maintain map-file semantics in URE libraries, to use maintainable dllexport style markup instead -- mmeeks
 * remove unpleasant shlib.cxx back-compat component_getImplementationEnvironment and ~Ext as a bad job in favor of relevant XML component markup -- mmeeks
 * bin the horrible XFilePicker 'getFiles' method which has hideous semantics for multi-select. Use only the XFilePicker2 interface - cf. sc's vbaapplication.cxx and vbafilepicker.cxx mess -- mmeeks
 * Fold all '2' or '3' variant IDL interfaces into base interfaces so XInvocation + XInvocation2 to XInvocation etc. -- mmeeks
 * un-'publish' a lot of pointlessly published interfaces - eg. the UNO accessibility API is never going to be used externally - mmeeks
 * kill the bogus XInputStream 'readSomeBytes' method - there is no way of doing non-blocking I/O sensibly here anyway, and readBytes vs. readSomeBytes seems to be a rather random decision; but needs a little audit - mmeeks
 * configmgr/source/components.cxx has a couple of back-compat comments /probably OOo 4/ to drop. - mmeeks
 * get rid of padmin, drop the awful unix specific 'fax' and old-style 'pdf' filter logic from vcl. - mmeeks
 * remove exception specifications from: -- llunak
 * cppu/ uno headers (Any/Sequence/Reference). While doing so, also bin the SAL_THROW  macro in favour of plain throw
 * see http://drdobbs.com/cpp/184401544 for why C++ exception specs are pointless
 * replace  with better data format -- Sb
 * which ultimately allows to drop  and   when backwards support for old   (incl. active component registration) and   formats is dropped
 * still unclear how best to do that, but it could impact all of UNOIDL (incl. the current need for ) and the current  / / /etc. tool chain
 * redesign service instantiation details, bypassing  and thus allowing for more general overloading of service constructors -- Sb
 * remove API entities marked @deprecated -- Sb
 * rework some of the css::i18n::* API --erAck 2012-08-30T18:00:54 (CEST)
 * change enums that might need to have new values added to constants and adapt interface methods, namely TransliterationModules, TransliterationModulesNew and UnicodeScript
 * get rid of awkward enum TransliterationModules altogether if possible
 * check for overloads like addEventListener which probably create problems for uni-typed languagues like Python or BASIC. -- Mst
 * get rid of ? (see &ldquo;Java/SWING + VCL / X crasher ...&rdquo;) -- Sb

Proposed changes (without doer)
Items in this section might break things. They can be done now, when we are switching to LibreOffice4 (where we decided to have unstable API/ABI).

General changes

 * drop the mozilla code completely on Windows now we have the nice new mork backend
 * replace rtl::OUString with a UTF-8 string for better space efficiency, and Unicode coverage.
 * remove rtl::OString - and do charset conversion at the code periphary
 * use consistent and noninsane names for libraries
 * this can be done any time, except for URE libs --Dtardon 2012-07-28T06:59:40 (CEST)
 * rename silly terms to more meaningful ones, also in comments, like "fly", "heaven" and "hell" (I am not kidding), etc
 * "heaven" and "hell" are perfectly intuitive layer names -- Mst
 * Needed to be done only in public API for LibreOffice4.
 * use C++ instead of C for sal/osl
 * Consolidate and re-write our stream interfaces, abstract and push them right down the stack - into or below sal, base new UNO interfaces on these - more thoughts here in mail "inelegancy in XStorage path handling" - we also need some way to propagate the 'fsync on close' functionality we want for documents down into the local-filesystem stream implementation.
 * consider moving all 16-Bit integer types to 32-Bit at least
 * this cant be done in bulk as the are still a lot of SAL_MAX_INT16-2 style magic numbers in the applications, so needs a very careful evaluation --Bjoern-michaelsen 2012-07-29T17:09:34 (CEST)
 * remove two layer structure - switch back to a single layer, no split URE
 * salhelper: re-think tiny, separate helper library
 * (?) Bootstrap's rtl_bootstrap_setIniFilename - actually takes a URI - so rename it.
 * (?) merge many libraries and hope that LibreOffice starts quickly enough even on moderately old machines that we can remove the quickstarter once and for all and disable the splash screen by default
 * This belongs to this section only if it involved also merging all public API libraries into one (or more).
 * get rid of the internal allocator and use a standart one like jemalloc, tcmalloc or the system allocator and get rid of its API

UNO related changes

 * replace 'sal_Bool' with 'bool' globally in UNO interfaces
 * replace sal_Int* types with standard sized C types from stdint.h/cstdint, which is said to be availabe in MSVC2010 even
 * this can be done in a compatible way: we can replace the types in _our_ header and keep the sal_Int* types as typedefs for the stdint types for backward compatibility. No need to cause pain to extension developers by removing them completely (at least not from the start). thus moving to "internal change" --Bjoern-michaelsen 2012-07-29T15:28:21 (CEST)
 * it is not guaranteed that this can be done compatibly: e.g. sal_Int32 and int32_t could map to either long or int on 32bit platforms, which probably result in different mangled names, so switching would change the name mangling at least, and probably at least cause new warnings for client code. -- Mst
 * actually this is a real problem: MSVC uses "typedef int int32_t", while for Windows we use "typedef signed long sal_Int32"
 * perhaps re-work some of the horrible UNO APIs used by scripts to something more useful and familiar
 * this is horribly vague -- Mst
 * Get rid of the overloaded operator<<= and operator>>= in UNO's Any; instead use setXYZ / getXYZ methods to improve readability. The use of the overloaded operators is counterintuitive, and does not save too much typing either.
 * create a C++ stream output operator << for Any that uses the existing comphelper's anyToString
 * Rename XComponent to XDisposeable - to reflect it's actual function and reduces over-genericisation
 * re-write desktop/source/deployment to remove all UNO-isation - the XPackage stuff is not useful externally, and it just complicates and fragments the code.
 * For LibreOffice4 this probably means just removing XPackage UNO stuff
 * in Basic, manipulating zip files is done using CreateUnoService("com.sun.star.packages.Package") lgodard
 * does it mean that an extension will not be able to know if there exists some new version for itself ? lgodard
 * remove the XUnoTunnel interface if possible, and use dynamic_cast in all these places.
 * remove symbol versioning madness 'UDK3_0_0' type nonsense map-files wherever they still exist in libuno* etc.
 * Remove XMultiServiceFactory interface, and replace everywhere with XMultiComponentFactory
 * provide two versions of the public UNO symbols - in a separate library for extension developers to link to - with only those symbols - and also in-line all of that code inside LibreOffice, so we can get substantial link-time-optimization wins.
 * drop the pointless UNO-isation of the calc formula APIs
 * retire DataPilot source API's (com::sun::star::sheet::DataPilotSource* services and com::sun::star::sheet::XDataPilot* interfaces that are provided by those datapilot source services). At least make them non-published to allow future changes or retirement.  This will make it possible to do more aggressive speed optimization of the pivot table engine. --Kohei
 * consolidate all the "*rc" files - we have a dozen interlocking ini files eg. versionrc or two copies of unorc that are not so useful - we should cut all of that down to one or two files.
 * UNO APIs that take a sequence of PropertyValue "properties", i.e. a set of pesky Anys, but where the set of possible properties is quite small. should be redesigned to take them as separate optional parameters instead (that could be null, however one expresses that in idl).
 * IDL does not support optional parameters, so in effect you would currently get methods with a non-extensible set of non-optional parameters. -- Mst
 * new UNO API for conditional formats(including color scales and data bars)
 * if this does not require changing existing APIs, it can be done any time --Dtardon 2012-07-28T07:13:53 (CEST)
 * the old API can't deal deal with the new design and should be at least deprecated and the next design step will most likely break the old API -- moggi
 * with all these changes parts of the Developer Guide on the OOo Wiki become obsolete; we probably have to fork that & change it, including installing all the necessary MediaWiki extensions it depends on


 * (?) nonsense to use UTF-16 strings down in cppu/typelib
 * (?) drop the monstrous 'store' code, and the old types.rdb file
 * failing that - at least drop the old 'registry' tooling 'regview' etc.
 * (?) As part of 'drop store code' - ignore legacy .rdb files for component info, and require the new cleaner XML registration files.
 * (?) Update calc sheet indexes everywhere to be 32bit not unsigned 16bit to reflect the improved core
 * (?) drop map files for UNO libraries, and use symbol visibility markup instead.
 * shouldn't affect binary compatibility if done right, I think? -- Kendy
 * Drop support of obsolete /  from   implementation, once  is fixed.

UserInstallation changes

 * Per-user information about bundled and shared extensions:
 * Either remove   and   again (as, at least theoretically, it was only necessary to work around broken   data copied over by LibreOffice ≤ 3.5.x);
 * or let the above also cover per-user information about shared extensions, to be on the safe side in scenarios where a user shares a single UserInstallation across different versions of LibreOffice (i.e., keeps up- and downgrading; also cf. “fdo#53006: And detect LO downgrading scenarios...”);
 * or fundamentally rethink scenarios where a UserInstallation is reused across a downgrade—whether they work at all anyway.
 * Get rid of Berkeley DB files in  and.

Discontinued support for obsolete platform releases
Those that aren't supported by the platform vendor
 * support for Mac OS X 10.5 and therefore PPC platform will be discontinued
 * support for Windows 2000 will be discontinued
 * support for Java 5 will be discontinued
 * Mozilla based LDAP backend for address book is discontinued on all non windows platforms
 * raise Linux baseline to at least ~RHEL5 or possibly even ~RHEL6

Windows release binaries produced using MinGW

 * if the MinGW port proves to be good enough (no major regressions), switch to MinGW cross-compiling for building the release builds
 * this would decrease the Windows build time substantially
 * it would be binary incompatible with MSVC

Internal changes
Changes that affect only LibreOffice itself and as such actually don't really have anything to do with LibreOffice4, as they can be done at any time. They should be moved away from this page into some other place (EasyHacks, ...) if confirmed they really don't belong here.


 * verify consistent a11y support -- Vsfoote
 * QA actions upon implementation of ATK/AT-SPI and IAccessible2 APIs for ALL OS, with adoption of IBM Symphony contribution to Apache \winaccessibility native bridge under ALv2, and adjustments to UNO Accessibility roles to fill all needed a11y roles for various Assistive Technology will all need to be validated as functioning correctly.
 * See meta tracking bugs: OS X,  GNOME-ATK and several open enhancement requests for Windows
 * provide a 64 Bit build also for Mac and Windows
 * what's the point? are there any benefits other than marketing? -- Mst
 * I believe there would be improved speeds? Also, I believe, we have already delayed enough to move to 64bit versions ? -- sumuthu
 * re-combine source files that have been split into ones with numeric suffixes (sometimes up to hex digits...) just because of some compiler limitation ages ago. (Of course, make sure current compilers are still OK with that.)/ rename source files to match the class implementation in them, in cases where there is a 1-1 match
 * Needed to be done only in public API for LibreOffice4.
 * this can be done at any time, nothing special about LO4 -- Mst
 * Well, actually most of those need splitting, just sensible one (e.g. by class) and not by "we dump all writer uno stuff in one long stream and than randomly cut and number that" -- --Bjoern-michaelsen 2012-07-28T12:30:51 (CEST)
 * in ucb (I think it was) some code uses "UNC" as part of identifiers referring to files and/or URLs. Might be a leftover from some time when StarOffice was OS/2 and Windows only, and UNC paths were cool and new and "universal"? In reality these variables/parameters nowadays refer to URLs or pathnames, so rename accordingly
 * get rid of ASCII graphics noise (//=================== etc)
 * get rid of nonsense information-less boilerplate comments like // include of my own project
 * get rid of empty boilerplate Doxygen (or something) boilerplate comments
 * revisit the internal structure of connectivity::ORowSetValue:
 * DONE add a "sal_Int64 m_nInt64" to m_aValue union to store 64bit integers directly instead of via dynamic allocation and the m_pValue pointer: on 64 bit (that is most) platforms, it won't make the struct any bigger, since the union already has pointer members
 * DONE add sal_uInt* members to m_aValue union to store unsigned integers "naturally" instead of in a bigger signed integer type
 * DONE since now m_aValue is 64 bits anyway, also add float and double members
 * com::sun::star::util::Time and Date now also fit, assuming the struct is packed?
 * get rid of the silly concept of "delivering" headers, just use them from wherever they are
 * replace "solver" with a runnable office installation

or if your debug objects need state (untested pseudocode): Essential about this is that class RealClass (and all other non-debug classes) stay binary compatible, e.g. code that runs against the non-debug version also runs against the debug version. Anyway: As we are not shipping a debug version, this is not really a LibreOffice4 API question.
 * (?) de-UNO-ize the ODF import and export filters.
 * (?) drop published service ProductRegistration in offapi/com/sun/star/setup/ProductRegistration.idl
 * use one debugging implementation, move DBG_UTIL to OSL_DEBUG and rethink OSL_DEBUG for a clean future
 * DBG_UTIL is necessary for adding debug code with "extern" linkage. anybody who proposes a replacement that does not guarantee ODR is met will be hit with cluebat -- Mst
 * debugging code with "extern" linkage is evil anyway (if it depends on other libs to have modified objects too). I would be fine with something like (untested pseudocode):
 * this could actually work, provided that all access to instance of RealClass are already guarded by some global mutex, which should be the case for existing uses of DBG_UTIL; linking object files with incompatible OSL_DEBUG_LEVEL would fail at link time, which is sub-optimal but better than runtime failure. -- Mst

General changes

 * get rid of rtl/memory.h functions -- Arnaud Versini
 * Removing internal usage for 4.0 and mark them deprecated -- DONE (see: gerrit patch)
 * drop the platform-specific DLLPOSTFIX / gb_Library_DLLPOSTFIX string from shared libraries names
 * get rid of the ODMA stuff
 * Upgraded internal python to current stable 3.3 version - breaking some plugins -- Mst (see Upgrade internal python discussion)
 * Deprecated rtl/memory.h functions -- Arnaud Versini
 * to be removed in 4.1
 * Removed the ODMA connector: ODMA is dead as a technology. This feature was de facto used only to interface with Novell GroupWise as far as I know, and the GW people say we can drop it. There was never much interest in actually making sure that it kept working, and most likely it didn't actually work in recent releases anyway.
 * got rid of binfilter
 * not done yet - Ensure that afterwards, when files of this format are loaded, people are warned that this code has been removed, and that they need to migrate their documents with an older version.
 * drop bundling of STLport library for backwards compatibility with old extensions -- Sb
 * as discussed at &ldquo;modules removal surprises&rdquo; and &ldquo;minutes of ESC call ...&rdquo;
 * at least among the top 50 (of 178) highest rated extensions in the extension center there are only three that contain /  files  and none of those appears to be affected

UNO related changes

 * various changes flagged with &ldquo;API CHANGE&rdquo; in the git commit messages
 * drop support for /etc/opt/ure and ~/.ure, cf. ure/source/README -- Stephan Bergmann -- DONE (see: git commit)
 * add a "position" parameter to various css.text.XAppendFoo methods that are used by writerfilter so we can use the new RTF import for clipboard pastes in Writer and get rid of old RTF import -- Vmiklos -- DONE (see: git commit)
 * &ldquo; don't crash when setting too small size&rdquo;:
 * can additionally raise
 * setting com::sun::star::report::XReportComponent::{Height,Width} now can throw com::sun::star::beans::PropertyVetoException. This makes it consistent with com::sun::star::drawing::XShape::setSize, in terms of which Height/Width are implemented anyway.
 * removed cppuhelper's stdidlclass.hxx and createStandardClass method variants - obsolete for years.
 * remove css.document.XDocumentInfo and related interfaces and services (deprecated and replaced by XDocumentProperties) -- Mst
 * css.lang.IllegalArgumentException should derive from RuntimeException so it can be thrown by any method (usually a bare RuntimeException is thrown currently because adding the IllegalArgumentException to a method would be an incompatible change, because it is not a RuntimeException) -- Mst
 * remove exception specifications from: -- llunak
 * generated uno idl headers
 * provide a additional short and sweet alias for what is the com::sun::star::* namespaces now (and the org::openoffice:: one too) -- llunak
 * hmm... this change would break every existing extension and macro for relatively small benefit; do we really want this? -- Mst
 * I really want this :-) and there is no need to break every extension and macro; as a first approximation, we can add some special cases to the UNO type system that simply map com::sun::star:: to Uno:: or whatever thus mirroring the types in another namespace - ditto for the IDL compiler for a back-compat namespaceing regimen - so I've snipped the other comments of doom here. IMHO we should start by building and testing this the other way around - using a shorter namespace to reflect the css one -- mmeeks
 * readding the comments of doom if the intention is indeed "drop the com::sun::star::* namespaces (and the org::openoffice:: one too) for something short & simple (like com::sun::star::uno:: -> uno:: perhaps)." -- they only apply for dropping the old namespace. If we only add an new sweet and short alias (to be migrated to over the years) they dont apply and everything is fine and shiny: --Bjoern-michaelsen 2012-08-02T16:21:50 (CEST)
 * how many people who think writing macros in BASIC is an acceptable practice know how to use sed? and macros can be contained in documents... -- Mst
 * it may be, but will not: because of the nested namespaces, people will have used "com.sun.star" prefix strings (in basic), using com::sun::star (or com::sun or whatever) in C++, namespace-aliases or plain old #DEFINEs. assuming this to be sed-able is terribly naive. --Bjoern-michaelsen 2012-07-28T13:50:50 (CEST)
 * what was actually done is just to allow omitting com::sun::star in C++ code, which does not break anything
 * salhelper: remove unused headers: queue.hxx futurequeue.hxx monitor.hxx future.hxx - none of which appear to be used. -- Sb

Internal changes

 * remove build.pl and dmake
 * get rid of silly #define XCHILD ::com::sun::star::container::XChild style code in sfx2

Changes deferred until 4.1

 * com::sun::star::util::struct DateTime should be extended to nanosecond precision, time zone and sign
 * also struct Duration, struct DateTimeRange, struct Time
 * Rationale
 * milliseconds needed so we can finally store the minimum precision required for XMLSchema-2 date/dateTime used in ODF, see
 * nanoseconds needed for maximal interoperability with databases (nanosecond = ODBC precision); see the discussion in
 * Transition plan
 * keep some cruft and add a new field "NanoSeconds" that stores digits 3-9 of seconds fraction; leave digits 1-2 in HundredthsSeconds. Still ABI-incompatible, but some level of API-compatibility. Is it worth the cruft?
 * the point of doing an incompatible break is to get rid of cruft like HundredthSeconds
 * nanosecond precision
 * switch+adapt Base code (ODBC, ...): Lionel Elie Mamane
 * rest of codebase: mst
 * XMLSchema-2 date/dateTime used in ODF: mst
 * sign
 * Who added that? Please explain: required for XMLSchema-2, see
 * is that a sign on the year for dates BCE? exactly that
 * is that a global sign for use as date interval? No, should use struct duration for that.
 * timezone
 * who will do: required for XMLSchema-2, see
 * Then we also need utility functions to convert between timezones... best use a (system?) library
 * For Base use, please allow a special timezone value "NONE"; this corresponds to two different SQL types: "timestamp" and "timestamp with time zone"
 * in XMLSchema-2 the timezone is also optional so there has to be some way to say "no timezone"


 * at least drop deprecated rtl::O[U]StringBuffer::{charAt,setCharAt} (as follow-up to ) (proposed patch)