To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=60696
------- Additional comments from [EMAIL PROTECTED] Tue Feb 7 02:13:17 -0800
2006 -------
On Mon, 2006-02-06 at 17:37 +0000, [EMAIL PROTECTED] 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.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
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]
