Stephan et al.,
we obviously need a solution to the requested points,
-1- accessing OOo via the API only, the first start of the office should
happen _without_ showing the wizard,
-2- kind of headless mode when accessing OOo per API only,
-3- accessing OOo via GUI, the first start of the office should happen
_with_ a wizard,
-4- easy access, basically meaning, that typical operations should be
transparent,
-5- a defined life cycle, e.g. the office process should live as long as
their is activity around it (via the API from outside, via the API from
inside, via the GUI).
These points need to be addressed in a Uno compliant fashion! E.g.
passing the path to an OOo installation to the Uno bootstrap method is
_not_ Uno compliant (as may be meant by i70428). Passing a path to a Uno
service repository may be compliant, but should not be necessary.
Being able to pass potentially conflicting arguments to OOo services is
not an option, the same serving components should be suitable for API
and GUI clients. Note, the office should be regarded as a collection of
Uno services, rather than being a (fat) application. This is the only
choice, if we want to ensure that OOo is going to be usable in upcoming
more complex scenarios, including a bunch of 3rd party provided services
(extensions).
If I understand correctly, people currently face problems when using
Java-Uno in Frameworks as Netbeans or Eclipse (i70248), I am going to
take a look to see what other solutions are possible.
Kay
Stephan Bergmann wrote:
Tobias Krais wrote:
Good morning Kai,
As you wrote the non-GUI use case is neglected in your
argumentation. In
my opinion, there should be a solution for this use case, too.
What do you suggest?
Good question. My aim is, to allow bootstrapping a completly new
installed OOo, without any graphic interruptions. E.g. I wrote a
converter and it would be very harmful if it does not work without
klicking through the FirstStartWizard.
To reach this aim, there are some possible solutions. Some might not
work, because I don't know the code or the architecture behind.
1. If OOo is bootstrapped and a document is opened in hidden mode ->
don't show any wizard. Show the wizard next time when OOo is opened
visible.
2. Allow bootstrapping with a PropertyValue, where I can change the
behaviour myself.
May be someone knows even a third solution. Kai, what do you think
about it?
In my opinion this boils down to a more flexible bootstrap process
(e.g., more flexibility in passing specific command line args to
soffice), as I already outlined in my "Additional comments from sb Wed
Oct 18 00:38:31 -0800 2006" at
<http://www.openoffice.org/issues/show_bug.cgi?id=70428>. Tobias, if
you like you can add your thoughts to that issue's "wish list."
-Stephan
Greetings, Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
