Created attachment 33299 [details]
a patch.

pl->cd: please have a look

cd->hro: Can you please take over as you are much more familiar with the Unix
environment. You also implemented the Unix part in CWS splashperform.

Created attachment 33383 [details]
make the IPC pipe name easy to generate

@mmeeks: You got it. That was just the intention of the win32 loaders, to have a
small and fast binary that just passes the command line parameters and shows the
splash screen without any overhead. MD5 was just because of compatibility with
Win9x as it does not support named objects with names longer than 256 characters.

Let me take your patch as a source base for further i9mprovements as I'm
planning to change some more details. F.e. actually the pipename is generated
from the userid + userpath. To prevent the same user configuration to be used
from different concurrent processes there's also a lock mechanism that verifies
wether the user data is already used by a process on a different machine.

Beside that user data is not a good criteria to differentiate between two
instances (installation dir would be better) $DISPLAY should also be included in
the pipe name (or session id on non Linux platforms, as Terminal Server or
SunRays). Actually if you open a second display on the same machine and start a
second office with the same userid, the windows will pop up in the other display
- not was is desireable.

.

On Mon, 2006-02-06 at 17:37 +0000, hro@openoffice.org wrote:
@mmeeks: You got it. That was just the intention of the win32 loaders, to have a
> small and fast binary that just passes the command line parameters and shows the
> splash screen without any overhead. MD5 was just because of compatibility with
> Win9x as it does not support named objects with names longer than 256 characters.
> 
	Sure - so, as you know - one of my concerns is code re-use inside OO.o instead
of the galloping cut/paste that we see currently :-) what does that mean for
argument parsing ? not obvious ;-) clearly I'd like to see a 'plain C' argument
handling thing that can be a shared module between 'start.c' and cmdlineargs.cxx
etc. doing simple utf-8 parsing.

	Or - failing that, a more table-driven approach with a nice shared struct in a
header that annotates arguments with eg. 'unsigned int nosplash_with_this_one :1;'

	That sort of thing ;-) clearly having 3 separate argument parsers doesn't help
anyone.

Let me take your patch as a source base for further i9mprovements as I'm
> planning to change some more details.
> 
	Great :-) it's certainly in need of some more love: urgh - particularly, you
don't want the version actually filed in that patch ! - it has tons of hideous bugs.

	Can you poke at the
http://go-oo.org/ooo-build/patches/src680/speed-ooqstart.diff version instead ?
that fixes a number of nasty issues - argument paths etc.

 F.e. actually the pipename is generated
> from the userid + userpath. To prevent the same user configuration to be used
> from different concurrent processes there's also a lock mechanism that verifies
> wether the user data is already used by a process on a different machine.
> 
	Sure - I still fret about that; AFAICS the factory is there not just for
performance but also to protect the config data - so perhaps using the path to
that config data is the right thing ? but of course, then the multi-display
angle immediately breaks that anyway ;-)

$DISPLAY should also be included in
> the pipe name (or session id on non Linux platforms, as Terminal Server or
> SunRays). Actually if you open a second display on the same machine and start a
> second office with the same userid, the windows will pop up in the other display
> - not was is desireable.
> 
	Well - yes; of course DISPLAY should be mangled in - but OTOH we never did that
in the past.

	Also *HEALTH WARNING* ;-) there are serious problems with DISPLAY, that we have
suffered in GNOME for some years ;-) eg. on a single-user, 1 display box these
DISPLAY values are all equivalent:

	DISPLAY=':0'
	DISPLAY=':0.0'
	DISPLAY='localhost:0'

	And the 1st two are in fact remarkably common; and this is of course without
ssh -Y localhost type problems ;-) ie. the whole '1 activation per display' idea
is acutely complicated & unpleasant and there is no good way to do this.
Unfortunately - you have to connect to the given display and poke around at root
window properties to have anything reliable: not something we want to do in a
fast-quickstarter and not so useful for the common case. IMHO if we do that at
all it should be pushed into the main process.

	Anyhow - wonderful to have you working on this.

*** Issue 63268 has been marked as a duplicate of this issue. ***

I'll attach an updated version.

- Uses just Xlib+glib instead of Gtk+ (but dithers on 16bit displays)
- Does not need the startup notification at all - it appears instantly
- Fixes some smaller problems

Created attachment 34933 [details]
The patch.

Committed to 'unxsplash' CWS.

Hopefully this CWS could be integrated ~quickly, and if modifications
were needed, they could be done in the splashperform (or any other) CWS later;
what do you think?

Created attachment 34934 [details]
Sorry :-( - the patch I attached is not the newest.  This one is.

Reopened so that it gets on the radar of the not yet solved issues...

Other than that, the comment from kendy Thu Mar 16 11:03:08 -0700 2006 is still
valid ;-)

@kendy: Excuse the delay in working on that but I was ill for 3 weeks followed
by 1 week training so i wasn't able to work on this. As you can imagine there's
much work waiting for me as nobody took over my tasks. Currently I can't promise
that it will get into 2.0.3 I've to prioritize the issues first.

I'm sorry but I've to retarget this one to 2.0.4 we don't have enough resources
to integrate the patch with the timeline for 2.0.3. The fix only works for UNIX
and would break the Windows build. Additionally it will break functionality of
unoexe and the -env command line switches. So this can't be integrated into the
master now.

So I understand that this patch needs some additional work.
Hennes, could you be a bit more specific what has to be done before it can be
integrated (in whatever release)?

hro: eg. we could cut/paste the md5sum code & write a very simple cut/down
bootstraprc parser to use the same pipe path if you really want - to further
reduce footprint / impact.

cd: It seems you have been working on the splash code recently - any chance to 
have a look at these patches as well, please?

cd->kendy: I cannot comment to your gtk specific changes as I am not familiar
with X/gtk. You have to wait for HRO. You now have to two different approaches
(Unix/Windows) to create the pipe name. I am not sure, but I think there are
some external application which uses the pipe to check if an Office is currently
running. They would have to change their code in a platform specific manner. I
think this is not really acceptable. I am also not sure that using only the
application path as the pipe name is a good idea. A second user wouldn't be able
to to start the Office using the same installation. It should be clear that the
current Office implementation needs exclusive write access to the user data
directory. A second Office instance using the same user data directory would
result in a nightmare. The pipe communication between starter and splash screen
service looks ok, although we should prevent to use #ifdef UNX in non-platform
specific code. Why cannot you use osl here? I can see that HRO already added his
concerns about your patch. I fear we have to wait for HRO (currently he is ill
and will be available start of August) and discuss the feature in detail.

hro, cd: wrt. the #ifdefs, would it be acceptable for you to implement another 
splash UNO service for the external splash that would be used in case 
-splash-pipe= argument was present?  The current implementation does not break 
the Win32 build, but this could be cleaner, right?

hro: wrt. comments from mmeeks Wed Apr 26 01:23:34 -0700 2006, is it really 
needed?

Please, are these two the only concerns, or did I forget something?  Thank you 
in advance!

OK - so I updated the patches to implement 
"com.sun.star.office.PipeSplashScreen" service - it is a SplashScreen that does 
not render any output, just sends the progress values back to the external 
splash process that started OOo.  This service is used just in case 
-splash-pipe= argument is present.  The sources:

http://www.go-oo.org/patches/src680/unxsplash-desktop-unx-source.diff:
Implements the tiny executable (ooqstart) that draws the splash screen, creates 
the pipe and starts OOo.

http://www.go-oo.org/patches/src680/unxsplash-desktop-unx-splash.diff:
Implementation of the PipeSplashScreen service.

http://www.go-oo.org/patches/src680/unxsplash-desktop.diff:
Build bits, choose PipeSplashScreen when -splash-pipe=XYZ is present, make the 
progress bar going more smoothly, fix Set/GetStringParam(), ...

http://www.go-oo.org/patches/src680/unxsplash-scp2.diff:
Install bits.

I can also have a look at the second problem - if it stops the integration.  
Does it?

cd->kendy: I am sorry, but I am very busy with OOo 2.0.4 show stoppers.
The pipe service is an important step for a platform independent solution for an
external startup executable. I know that you are only interested into a Unix
solution, but I think we should have a solution ready for all platforms
(including Windows). CWS splashperform has a Windows prototype which also needs
a way to communicate with the splash executable.

> I know that you are only interested into a Unix solution, but I think we
> should have a solution ready for all platforms (including Windows).

I don't quite understand what you're saying here. Are you saying that we should
block platform specific unix-only improvements until Win32 versions can be
created ? [ that would be an incredible view IMHO ].

cd: I am sorry, but nonavailability of the Win32 implementation is not an 
argument ;-)  Win32 system file picker was implemented far before there was one 
for Gnome/KDE; it would be ridiculous to block it on availability of them...

From what I see in CWS splashperform, there's no communication between the 
splash process & OOo there yet, right?  I'm quite sure the idea of 
PipeSplashScreen could be re-used even there - as the -splash-pipe= you can use 
whatever works on Win32 (I guess it has something like the unx pipes?) & 
implement an own PipeSplashScreen service for Win32.  Or the switch can be 
simply renamed later if you need something other than a pipe (eg. to 
-splash-communication= together with renaming the service to 
ExternalSplashScreen).  It is just an internal parameter, and the user is not 
supposed to even know about its existence anyway.

And - of course I do not expect this to get into 2.0.4, we are behind a 
feature-freeze - but it would be really great to see it in early 2.0.5, ASAP 
after branching for OOD680 - so that we had more testers after the recent 
changes.  (We have already quite lot of them for the previous implementation - 
all the SUSE 10.1 & SLED 10 users :-) )

I've updated the patches to create exactly the same OSL pipe as OOo currently 
does (the md5 one).  The patches are here:

http://www.go-oo.org/patches/src680/unxsplash-desktop-unx-source.diff
http://www.go-oo.org/patches/src680/unxsplash-desktop-unx-splash.diff
http://www.go-oo.org/patches/src680/unxsplash-desktop.diff
http://www.go-oo.org/patches/src680/unxsplash-scp2.diff

The description is above in comment from kendy Fri Aug 4 07:57:20 -0700 2006.

BTW, is that bug or feature that the md5 sum is not really a md5 sum if there 
are numbers < 0x10 in the OSL pipe name?  I mean eg. aa0bcc is shortened to 
aabcc...

hro, cd: The deadlines for 2.1 are approaching - any chance to have a look at 
the recent version of the patches & approve them, please? ;-)  I can do the 
CWS, etc. if you do not have a suitable one.

Thank you!

As it looks your patch only works if the bootstraprc does only contain
SYSUSERCONFIG but no other variables. There are a lot of more bootstrap
variables that could be used here. The problem is that to support all possible
variables you have to write a lot of code - or you can link against sal and use
the existing functionality there (perhaps sal could be linked statically?!).

Another missing feature is that you need to evaluate the command line as it
might contain a value for the "UserInstallation" variable that overwrites the
value from bootstraprc.

wrt. the bug in the MD5 hash: this is a known issue (though only available in
our inhouse bugtracking system).

We can't fix it without creating problems for other apps (unopkg, setup and any
3rd party software relying on the pipe name to detect a running instance), at
least we should reserve the fix for a major release.

mba: thanks for the great feedback:

    "or you can link against sal and use the existing functionality
     there (perhaps sal could be linked statically?!)."

This was my preferred solution when the use of the Pipe & md5 code was mandated,
unfortunately - as soon as you use certain parts of sal (anything string
related) you pull in a huge chunk of code [ I guess the textenc stuff ], and
your 'small' quick-starter baloons from 40k -> 2Mb ;-) so it's not feasible.

Indeed - you could question -why- we have 1.6Mb of 'textenc.o' linked into our
(~2Mb) platform library, the vast majority of which is never used in any locale
;-) The vast majority of strings are either UTF-8 or ASCII on my system. [
performance wise we should prolly try to re-factor that out, it'd be interesting
to see how much ISO12345 stuff is used in .de / .european locales too ? - at
least on Unix the world is going UTF-8 fast ].

Would linking sal dynamically really hurt ? The exports out of that are c only
and it is comparable in size to the X11 library itself. And then there is gtk
with its 3MB not counting its dependencies. I guess the splash would show up a
little  later, but would it matter whether this is in 25 milliseconds or 75 ?
Personally I'd say, no, the smallest thing a user can notice is ~50 ms anyway.
But perhaps the numbers are different, if so please tell.

Just an idea :-)

> The problem is that to support all possible
> variables you have to write a lot of code - or you can link against sal and
> use the existing functionality there (perhaps sal could be linked
> statically?!).

I already link to sal statically (see desktop/unx/source/makefile.mk) to get 
the md5 digest.  Unfortunately, using more is not possible - once I use part of 
the code that accesses OUString/rtl_ustring, all the conversion tables get in 
and I end up with >2M stripped binary (I've tried that already) which is not an 
option for a lightweight (quick)starter.

So - I have to copy the functionality I'm afraid.

> Another missing feature is that you need to evaluate the command line as it
> might contain a value for the "UserInstallation" variable that overwrites the
> value from bootstraprc.

OK.

Anything more I should be aware of, please?

pl: X11 is in the memory for sure, glib most probably as well (and has just 
libc as a dependency), sal is not in the cold-start case; so it still takes 
some time to load it (though I have no numbers to show, unfortunately).  
Linking it statically would be better, but 2M still too much from my point of 
view...

(I forgot to emphasize that the current implementation does not link to Gtk+, 
just to glib which is ~500k & dependent just on glibc.)

Michael, Kendy, would you consider the option to factor out the conversion
tables? Would be interesting to see why they are it is pulled in when you use
any string functions.

Or should we go for the dynamic linking and try out how much milliseconds we
have to pay for it?

A small test on Windows revealed that after removing all textenc functions from
the export and the textenc.lib from the makefile map the following symbols show
up as unresolved:

sal.lib(thread.obj) : error LNK2019: unresolved external symbol
_rtl_getTextEncodingFromWindowsCodePage referenced in function
_osl_getThreadTextEncoding
sal.lib(nlsupport.obj) : error LNK2001: unresolved external symbol
_rtl_getTextEncodingFromWindowsCodePage 
sal.lib(ustring.obj) : error LNK2019: unresolved external symbol
_rtl_destroyTextToUnicodeConverter referenced in function _rtl_string2UString
sal.lib(uri.obj) : error LNK2001: unresolved external symbol
_rtl_destroyTextToUnicodeConverter
sal.lib(ustring.obj) : error LNK2019: unresolved external symbol
_rtl_convertTextToUnicode referenced in function _rtl_string2UString
sal.lib(uri.obj) : error LNK2001: unresolved external symbol
_rtl_convertTextToUnicode
sal.lib(ustring.obj) : error LNK2019: unresolved external symbol
_rtl_createTextToUnicodeConverter referenced in function _rtl_string2UString
sal.lib(uri.obj) : error LNK2001: unresolved external symbol
_rtl_createTextToUnicodeConverter
sal.lib(string.obj) : error LNK2019: unresolved external symbol
_rtl_destroyUnicodeToTextConverter referenced in function
_rtl_impl_convertUStringToString
sal.lib(uri.obj) : error LNK2001: unresolved external symbol
_rtl_destroyUnicodeToTextConverter
sal.lib(string.obj) : error LNK2019: unresolved external symbol
_rtl_convertUnicodeToText referenced in function _rtl_impl_convertUStringToString
sal.lib(uri.obj) : error LNK2001: unresolved external symbol
_rtl_convertUnicodeToText
sal.lib(string.obj) : error LNK2019: unresolved external symbol
_rtl_createUnicodeToTextConverter referenced in function
_rtl_impl_convertUStringToString
sal.lib(uri.obj) : error LNK2001: unresolved external symbol
_rtl_createUnicodeToTextConverter
sal.lib(string.obj) : error LNK2019: unresolved external symbol
_rtl_getTextEncodingInfo referenced in function _rtl_impl_convertUStringToString

We could consider to put textenc into a separate library that will be loaded on
demand, at least for these functions. The functions in sal would just be
wrappers around the load-on-demand call.
To keep the sal library compatible we must do the same for the other 15 symbols
from textenc also. Shouldn't be a lot of work and we would never need to load
the tables as long as nobody needs to convert anything than UTF-8.

ccing me

> A small test on Windows revealed that after removing all textenc functions
> from the export and the textenc.lib from the makefile map the following
> symbols show up as unresolved:

Ah - so tooling is everything ;-) if you poke at
http://go-oo.org/ooo-build/bin/oosize - there is a (Linux only) tool that shows
object size breakdown by source directory: eg. you can look at 'svx' and say:
wow that is a big pile of code, then break it down by source directory and
source file to find the offendors (some of which are quite suprising); anyhow it
shows:

michael@t60p:/opt/OpenOffice/ood680-m4/sal/textenc>
/opt/OpenOffice/HEAD/bin/oosize --ls
Found module '/data/OpenOffice/ood680-m4/sal'
Size breakdown
context.c       664
tenchelp.c      1036
unichars.c      1064
textcvt.c       1128
converter.c     1144
convertsinglebytetobmpunicode.cxx       1244
converteuctw.c  2140
convertgb18030.c        2176
tcvtutf8.c      2176
convertiso2022kr.c      2316
convertiso2022jp.c      2340
convertbig5hkscs.c      2420
tcvtutf7.c      2428
tcvtmb.c        2728
convertiso2022cn.c      3472
tcvtbyte.c      3672
tencinfo.c      9108
textenc.cxx     1490820

so - as you see, 1 file is a huge proportion of the problem here; luckily that
file exports only 1 symbol ;-)

ImplTextEncodingData const *
Impl_getTextEncodingData(rtl_TextEncoding nEncoding)

By commenting out the contents of that I get:

1797832 ../../unxlngi6.pro.before/lib/libuno_sal.so
 273544  libuno_sal.so # after

So - AFAICS this is really the obvious place to cut to loose 85% of the code at
a single stroke ;-) [ of course, we'd prolly need to re-instate / in-line at
least some of the common ASCII / common Win32 code-page / UTF8 stuff ] but it
should be fairly trivial to save a nice whack of code there in the common case.
I'm even interested enough to have a go myself now ;-)

cloned grist of the sal shrink to i#70166#

kso->all: hro is currently sick and will not be available before January 2007.
That's why there is currenly no activity from hro here.

I think "porting" is the best matching component and it better matches the
people working on this issue.

Hope I'll have enough resource to get this integrated for next minor relase on a
multiplatform basis.

I won't just apply the patch without implementing this for Windows too and
without deep testing in different configurations (Terminal Server, Sun Ray
Server etc.)

There was already another task where a patch like this worked on Linux but
Windows functionality was broken afterwards and not detected for over 6 month.

textenc and other stuff from sal is not really needed. Bootstraprc actually is
only used by the patch to find the userinstallation path as it's part of the
pipe name.

But the userinstallation path in the pipe name IMHO is a bug.

Pipe should be created from <program installation path>+<userid>+<display/session>

So there's no need to reso9lve any bootstrap variables.

Yes there are some tools (like unopkg etc.) that have to be adjusted too but
actually they rely on an implementation detail of a different module (which is
the next design bug).

I don't like duplicating code (including the above mentioned). What I would like
to see is a small piece of code that generates the pipe name and is linked
against all other modules statically.

A good place for this is sal/systool. The output should be a static lib which
only uses native system code. sal, the splashloader, desktop and other modules
should link against this library.

hro: an issue of incredible infamy: it got QA on Win32, but we didn't detect
that  - and, as you say - it was so critical it took 6 months to find ;-)

wrt. the patch - yes, we were blocking on re-writing this for you using 'sal',
blocking on fixing the sal bloat issues mainly; since that is now ~mostly done
it should be child's play to make an efficient 2nd starter based on our work [ I
guess ] that is except for the native splash code :-)

*** Issue 55417 has been marked as a duplicate of this issue. ***

Setting the target for 2.4 at least.

I really really want this feature but I'm not sure whether it can be realized
within 2.3 time line.
Performance is not only the startup time until the user can work with OOo but
the time until he get's the first UI feedback. For a desktop application quick
responsivenesses is as important as pure performance.

There are several design issues that have to be addressed beside the simple task
of implementing a working splashscreen along with a native pipe connection.

The key is creating the right pipename based on the right variables which depend
on the scenario where OOo is used.

My quick suggestions:

Desktop scenario pipe name = System User ID + Program Installation Path +
Normalized Display/Session (no need for bootstrap variable resolution)

For other scenarios the pipename may be constructed by

SystemUserID + UserInstallation Path + some context information.

I'd like to look at the design from a more abstract view: Given a scenario for
OOo - what information is needed to find the intended running process to connect
to ?

So first I want to collect all scenarios:

- OOo as single user/multi user desktop office suite
- OOo as UI-less server
- OOo as a plugin in other applications
- ...

@kso: Need some input about the possible scenarios and what is intended how OOo
should behave from an abstract point of view regardless of any currently
implemented bootstrap mechanism.

@mmeeks: Taking your patch and what is in my mind I guess I'll have to change
design a little bit. But the "core implementation" stuff of your patch seems to
be usable.

hro: I don't understand one thing ;-)  It is a patch that we use for ages in 
all our products; also Debians and the other distros do.  Why don't you just 
take it as it is, ship it with 2.3, and do the redesign for 2.4 (which is in 
about 9 months if I count correctly) as you like it?

When it is up-stream, it decreases our maintenance burden, the users have the 
feature, you can do the redesign - everyone is happy...

hro: I'm not aware of -any- Unix application that has succesfully solved all the
use-cases for a factory process, and (as I say), many of them are extremely
non-trivial.

It seems a shame to defer any integration until the impossible is achieved.

Clearly the code needs re-writing to use sal/ such that we don't change the pipe
name, or the way the current code works. Can we not split the blue-sky
"fix-all-possible-problems" part of this into some other task & not tie the
integration of this to that ?

@kendy, @mmeks:

Guys - do you really want me to integrate this into the master just because it 
runs well with your OOo distribution ?

Without ensuring that other currently working scenarios won't break ?

You think it's a shame that I don't integrate it because I KNOW that at least 
for the bootstrap variables the patch will definetly break existing 
functionality that is already used ?

I should integrate it, introduce some regression and fix it afterwards because 
your distribution will not be affected by the regression regardless what 
happens to other users of OOo that use it in a different scenario that's 
currently working ?

You must be kidding ;-)

What we can do is:

1) Collect and define the currently working scenarios
2) Test your patch on a CWS and see which scenarios will break (and there will 
be at least 2 scenarios I'm aware of).
3) Find a solution how to fix the problems detect at 2).

> Guys - do you really want me to integrate this into the master just because
> it runs well with your OOo distribution ?
>
> Without ensuring that other currently working scenarios won't break ?

Heh, how much time does it take to do so?  Definitely not 9 months to 2.4 ;-)

> You think it's a shame that I don't integrate it because I KNOW that at
> least for the bootstrap variables the patch will definetly break existing
> functionality that is already used ?

What _exactly_ do you mean?  Did you see my most recent changes (well, recent, 
from Tue Aug 22 14:46:11 +0000 2006) that use bootstraprc and exactly the same 
OSL pipe as OOo without the external splash [even with the bug in storing the 
md5sum in some cases].  Please tell me which variables/scenario _exactly_ break 
and I'll fix it.  So far I've heard just that commandline can contain value 
that overrides the 'UserInstallation' variable [fixable in about the same time 
you can write me 'Fix it for me please']; other cases were just 'I know of 
scenarios' without actually telling them.

Of course - we can statically link to the entire sal [patch to do so is an easy 
homework doable in few hours] if we agree that the slight ugliness in issue 
70166 is worth it.

> What we can do is:
> 
> 1) Collect and define the currently working scenarios

Yes, perfectly OK for me.  Let's say this can take 2 mandays of your work; I 
guess you don't expect _us_ to collect the scenarios, right? ;-)

> 2) Test your patch on a CWS

1 manday.

> and see which scenarios will break (and there
> will be at least 2 scenarios I'm aware of).

Exactly, please!

> 3) Find a solution how to fix the problems detect at 2).

3 mandays.

Even if this is too optimistic, we can have it in a month at most, or not?

kendy,

> Even if this is too optimistic, we can have it in a month at most, or not?

 Unfortunately not, I'm afraid. hro is on vacation this week and he has a lot of
other duties to attend to when he is back. He cannot immediately start working
on this issue. It's a question of (yes, even sun-internal) priorities. Sorry.

kso: Hahahaa! :-))  I would be weeping if this were not sooo funny.

Of course I don't want him to start immediately, I want more - this bug should 
have been solved for several months already...  Users would have the experience 
of seemingly better cold start, and really faster start of 2nd, 3rd, etc. 
instances [== with QuickStarter it is every case] in _your_ product, I could 
focus on another tasks, hro as well, etc.  And all this with just few hours of 
your work on a feature on which we spent ~50 hours.  Or should we bring you 
every feature that makes our product better on a silver plate? ;-)

@kendy: For just one platform with just one use case 1 manday of testing may be
right. But OOo is not just designed for one use case on one single platform.

I've already seen the last patch from Aug, 22th, but MBA already stated what's
missing. The pipe name will only be the same if you don't touch the bootstraprc
and don't make use of -env switch. The patch just works for the "default" use
case - not more.

1. Link against SAL and use rtl/bootstrap functions to support full bootstrap
variable support
2. Support -env command line

Linking against SAL is not what I would prefer - I already stated what kind of
aproach would be better. 
But if you want it to get into the master quickly without finding dedicated
solutions for each use case we must ensure that there will be no regressions.

If you agree with this quick approach please come along with an adjusted patch.

Regarding the "silver plate" - you know - you got 10 million lines of working
code on a silver plate too ;-)

The problem is that developing a prototype that works with 90 percent of the use
cases takes 10 percent of development time. The other 90 percent of time are
used to fix the missing 10 percent and make it reliable, maintainable.
Regardless whether this relation is 90/10 or 70/30 - this is common software
development knowledge. Writing a prototype is always fast, easy and very
satisfying ;-)

Second quick approach:

As I understand the patch ooqstart is the loader used for system integration and
for starting OOo within your distribution. The existing soffice.bin code is
mostly untouched with just minor changes when updating the splash screen and
instantiating a splashscreen service.

So with your distribution if you start soffice.bin with a modified bootstraprc
(UserInstallationPath != SYSUSERCONFIG) and start ooqstart afterwards you will
get a second instance and will not find the running soffice.bin process.

So would it be O.K. to leave the patch as it is but don't use ooqstart in the
official OOo build or advertise it as a goody with the hint "this only works if
you don't touch the bootstraprc and user configuration resolving will be
disabled/not working" ?

hro: First of all, I apologize for my offending statements; I suddenly got very 
angry that this issue takes so much time to solve.

I'll update the patch(es) to align with 1) and 2), and also I'll rename the 
'ooqstart' binary to 'oosplash' - it better describes what it does.  As long as 
it is not called from 'soffice' or the .desktop files, this feature will be 
available only to ones who know about it - and thus further reducing the risk 
for the users.

Ping.

Any news on this issue ?

hro: Sorry, I've been distracted by other tasks a bit :-(  I'll do the changes 
as promised on Jun 14, 2007 as soon as possible, hopefully until the end of 
the week.  The code is under the JCA, and I really want to see it finally 
up-stream :-)

hro: Committed to CWS unxsplash2.

Please review the code, now it links just to SAL and X11, no glib dependency 
any more.  [Thanks to linking to SAL, it should also solve the -env: thing.]  
I have also enabled it in soffice.sh so that it is used by default - if you 
don't agree & should it prolong the integration, I'll disable it there.  [But 
of course, from my point of view it is better to be 'on' in the Dev builds so 
that we can uncover problems if any.]

I also had to convert the intro.bmp's that are in the OOo CVS to 24bit 
TrueColor, the code cannot handle Palette.  If you want smaller intro bitmaps, 
I'll extend oosplash.bin to handle .png's in a follow-up CWS; extending the 
bmp reading is not the right way, the PNG is still nearly 1/3 of the paletted 
BMP.

Also, please could you recommend me a QA person?  I hope a buildbot will be 
able to provide me with an install set...

Reassigning to Eric, our QA guy.

Installsets are available as:

http://termite.go-oo.org/install_sets/O3-build-328-unxsplash2-install_set.zip
http://termite.go-oo.org/install_sets/Win-XP-143-unxsplash2-install_set.zip

Specification:

http://wiki.services.openoffice.org/wiki/Spec:Fast_external_splash_-_oosplash

I was able to successfully install and run the topten QATESTTOOL tests on both
the Windows and Linux Unxsplash2 CWS builds without any issues. Below are the
builds I used for my testing:

http://termite.go-oo.org/install_sets/O3-build-328-unxsplash2-install_set.zip
http://termite.go-oo.org/install_sets/Win-XP-143-unxsplash2-install_set.zip

I was also able to successfully start soffice (which on Linux exercised
oosplash) under the following conditions:

xnest window (DISPLAY=:22.0)
vnc session (DISPLAY=127.0.0.1:1.0)
Windows XP using 16 bit color
Windows XP using 24 bit color
openSUSE 10.3 GNOME session using 15 bit color
openSUSE 10.3 GNOME session using 24 bit color

Under the openSUSE 10.3 Linux system I tested to make sure that the following
commands worked correctly when no soffice.bin process was running as well as
when an existing process was already running:

soffice -writer
soffice -calc
soffice -impress
soffice -dbase
soffice -minimized
soffice -invisible
soffice -norestore
soffice -quickstart
soffice -nologo
soffice -nolockcheck
soffice -nodefault
soffice -headless
soffice -help
soffice -h
soffice -?
soffice -o
soffice -n
soffice -display
soffice -view
soffice -show

The commandline options that failed for me when no soffice processes was already
running were:

soffice -p <document>
soffice -pt <printername> <document>

I also ran into problems with the application not starting on the correct
DISPLAY only when I had the same user logged into two sessions at the same time
(ie a vnc and xnest sessions). Once OpenOffice was opened and started from one
of the sessions, any attempts from the other session would result in the OOo
application starting up in the first session. However, I did notice the same
behavior using the upstream OOo 2.3
(OOo_2.3.0_LinuxIntel_install_wJRE_en-US.tar.gz) downloaded from here:

http://openoffice.bouncer.osuosl.org/?product=OpenOffice.org&os=linuxintelwjre&lang=en-US&version=2.3.0

So I do not believe this is an issue behavior that was introduced in this CWS.

While reading the previous comments in this issue, I realized that I may not
have tested all of the command line or headless test environments for this CWS.
I'm not exactly sure what other scenarios the upstream developers believe will
break with this CWS. Besides having kendy look into the printing failure, could
one of the upstream developers help explain to me what other tests should be
exercise if any before we nominate this CWS?

I will take a look at the patch this week. Thanks for the work.

hro: Great, thanks!

In the meantime, the behavior of the OSL pipe has changed a bit [see my 
confusion in issue 84045 ;-)].  Will it help you if I resync the CWS & apply 
there the patch that adapts it to the new behavior?

Just in case hro / kendy are still working on this, it might be worth looking at
fixing up / handling splash bitmaps as per Kendy's suggestion earlier. This will
affect Issue 73786 (and I imagine the new artwork that will be generated for
3.0). Cheers.

Interestingly, this was proposed as a GSoC task: 
http://wiki.services.openoffice.org/wiki/Summer_of_Code_2008/proposals#Enhance.2FCreate_native_loader_to_reduce_startup_time

hro: Our patches are still in ooo-build, it makes no sense to resync them again 
and again.  Please have a look at

http://svn.gnome.org/viewvc/ooo-build/trunk/patches/src680/unxsplash-rework.diff?view=markup
http://svn.gnome.org/viewvc/ooo-build/trunk/patches/src680/unxsplash-new-osl-pipe.diff?view=markup
http://svn.gnome.org/viewvc/ooo-build/trunk/patches/src680/unxsplash-finish-on-hangup.diff?view=markup

All these patches have to be applied; the first one implements the 
functionality, the second fixes it according to the changes in the OSL 
protocol, the third one fixes an endless loop in case OOo crashes on startup.

I'll be happy to fix concerns, explain stuff, etc.

Reopening, because the CWS got terribly outdated in the meantime.

reset target because 2.4 is already released.

sb: Please, could you help me with code review of this?  It is quite tightly 
coupled with the OSL_PIPE (and I see you had to change the protocol a bit 
again), so it would be really great to have all this up-stream.

If yes - should I create a patch that contains all the unxsplash-related work 
for you?

@kendy: yes, I can look at it, but probably not before next week

@kendy: finally found time to take a look at this (sorry for the delay), but all
three http://svn.gnome.org links from #desc66 just give 404; could you please
"create a patch that contains all the unxsplash-related work"

Here's my workaround

As root rename oosplash.bin (on my machine it is in in /usr/lib/ooo-2.3/program)
to oosplash.bin.org

Create a new oosplash.bin script at the same directory with the below  content


#!/bin/bash
CNT=`ps aux | grep oosplash | grep -v grep | wc -l`
# expect exactly two lines lines (CNT = 2):
# this process, and the sub-shell (CNT=`...` command)
if [ "${CNT}" = "2" ]; then
$(dirname $0)/oosplash.bin.org "$@"
fi

This script allows oospalsh.bin.org to run only after any running oosplash
terminates.

Ugly hack, but works for me

+me .. 

I'm adding this comment to all open issues with Issue Type == PATCH.  We have 220 such issues, many of them quite old.  I apologize for that.  

We need your help in prioritizing which patches should be integrated into our next release, Apache OpenOffice 4.0.

If you have submitted a patch and think it is applicable for AOO 4.0, please respond with a comment to let us know.

On the other hand, if the patch is no longer relevant, please let us know that as well.

If you have any general questions or want to discuss this further, please send a note to our dev mailing list:  dev@openoffice.apache.org

Thanks!

-Rob

Reset assignee on issues not touched by assignee in more than 1000 days.