Hi all, 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." > First, let me do one step back. Yesterday I wrote that the simple bootstrap mechanism is designed to work for both gui and non-gui use cases. This statement is wrong. The current implementation of the simple bootstrap mechanism is designed only for GUI office usage. The started soffice process will always be in GUI mode. No "-headless" (or other typical server-only) parameter.
Back to the problem, extending the simple bootstrap mechanism: While it is no problem to provide a way that allows passing "nostartupwizard" to the bootstrapped office, a solution for passing *and respecting* arbitrary properties (command line parameters) to the office process currently is very high effort (if possible at all). Reason for this is how the office startup currently works. If you invoke soffice, it first looks for a possibly running other soffice process with the same user data. If such an office process is found, the parameters of the second soffice will be passed over to the already running instance (via a named pipe). Afer doing so, the second soffice process exists. A very problematic case is, if a first office instance is started in gui-mode and a second office instance is started in non-gui mode (-headless & friends) or vice versa. Currently, this is simply not working, because it is not possible that a running soffice process can be both in gui and non-gui mode. If the soffice master process is created as non-gui, it will stay in this mode until it exits. Contradicting parameters passed over from other soffice processes currently get ignored. That's why it is currently not (easily) possible to implement a bootstrap property with the semantics of "gui" or "nongui". - Kai. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
