Hi guys,
Markus - nice catch - really cool to get that nailed :-)
On Fri, 2012-01-13 at 09:05 +0100, Stephan Bergmann wrote:
> > bool IsLockingUsed()
> > {
> > return officecfg::Office::Common::Misc::UseLocking::get(
> > comphelper::getProcessComponentContext());
> > }
>
> (I haven't announced this new C++ API yet, as some issues about
> change-notification are not yet completely thought out for it.
Oooh ! :-) it looks really rather nice; how efficient is the compiled
representation ? hopefully much more so than the big chunks of in-lined
UNO-ness that existing code uses :-)
> Shame on me, should really do that soon.)
I'm excited. Re-thinking my annoyance with getting VCL bootstrapped,
and seeing the level of build parallelism that gnumake exposes - it is
not clear to me that we need to use UNO APIs as a tool to expose more of
that, though clearly some level of circular dependency breaking via
interfaces is useful.
What do I mean ? - I'd like us to consider building configmgr rather
early in the build, and simply linking VCL & above to it, leaving the
UNO API in place for back-compat & extensions, but using a native API
for new code.
If we could combine that with avoiding the need to load types.rdb to do
struct <-> Any handling for PropertyValues - perhaps we could make our
bootstrapping logic, code structure etc. rather simpler for unit tests &
simple test apps in the tree.
Anyhow - fun :-)
Regards,
Michael.
--
michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
