Date: prev next · Thread: first prev next last
2010 Archives by date, by thread · List index


Hi David,

On Tue, 2010-12-07 at 10:54 +0100, David Tardon wrote:
I think the simplest thing here is to run SessionManagerClient::open
when initializing the quickstarter (the function is exported, so there
should be no problem with that), but there might be a cleaner solution.

What if we do this when SalSession is created? Does anyone see any
problem with that approach ?

        There are some potential risks here; we don't want to do this if we are
just going to push our arguments off to another process or before we
start the splash (that is prolly the legacy explanation for deferring it
- since it is a set of synchronous calls AFAICS).

        Luckily the new standalone unix splash / quick-starter handles both of
these before we even start, and deprecates those concerns, so I suspect
there is no issue here. Having said that - this is another miracle of
UNO-isation - with the SessionManagerClient stuff being instantiated in
framework/ via a service, which itself is (presuambly) instantiated via
another service etc. etc. - making the code not only slower, but far
more difficult to follow :-)

        So - anyhow, I'd say whack the patch in, and hopefully it will solve
your abrt issues in an elegant way :-)

        Thanks !

                Michael.

-- 
 michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.