Issue 66426

Created attachment 37147 [details]
The configure & set_soenv part.

Created attachment 37148 [details]
Intro bitmaps loading.

Created attachment 37149 [details]
About bitmaps loading & packing into a .zip (for scp2 handling).

Created attachment 37150 [details]
Packing intro bitmaps into .zip (for scp2 handling).

Created attachment 37151 [details]
scp2 bits to actually install the intros & abouts.

Please review ;-)  Thank you in advance!

kendy: what about --with-productname too? There are distros/people who hack also
the productname (like OOo-dev, StarOffice etc).

pjanik: Well, the Suns do not use the config_office/configure anyway, so that's 
not that important I guess ;-)  But of course - it's an easy one, I can do that 
if there's demand for that.

Ause, could you please comment on the way how intro bitmap and vendor name are
handled? IIRC you mentioned an easier way to achieve this

ause: Ping? ;-)

"--with-vendor" just sets the according environment variable. if this is needed
in configure, fine with me.

for the images, it depends on your need for several of them. if you can go with
just one, my idea would be to extend the "include" setting on
"instsetoo_native/util/openoffice.lst" with some "something/{custom}" entries.
with "custom" set by configure and recognized by the pack scripts, most of your
changes wouldn't be required.

regarding the current patches
- passing file lists as defines is error prone as it involves a lot of shell
specific quoting.
- the approach of adding yet another processing makes things intransparent and
(for both cases) leaves unused fragments around.

> for the images, it depends on your need for several of them.
> if you can go with just one,

Having multiple fallback images is rather important - we want to produce the
SLED and OpenSUSE RPMS from the same source base; and preferably allow yet more
easy re-branding post install.

> - passing file lists as defines is error prone as it involves a lot of shell
> specific quoting.

Well, people do not use "'s in the filenames that often ;-)  We could number 
the bitmaps, of course, but I think it is not necessary to introduce there all 
the reading of content of the directory to filter out the actually present 
bitmaps, etc.

> - the approach of adding yet another processing makes things intransparent
> and (for both cases) leaves unused fragments around.

Not sure what exactly do you mean, the scp2 bits?  This is necessary because 
the number of installed bitmaps is not known.  I did not want to turn the 
current way of installing the about.bmp and intro.bmp to this scheme as well 
because I thought you wouldn't like it - because you don't use configure in 
your environment AFAIK.  But for sure I can change it, no problem.

cd: So - it seems that you have an internal issue 135985 that addresses having 
various intro bitmaps for OOo/SO - is that so?  I can just guess from the CVS 
log after the integration of c06v2 which has no description...

Could you please tell us a bit more about that CWS, please?  Does it cover this 
issue as well?  If not - could you extend it to cover it, please?

cd->kendy: I will have a look at your code patch. We have to make sure that HJS
accepts your revised build patch.

cd: Set correct target. It's too late for OOo 2.0.4, but we should be able to
integrate it into 2.0.5. Have to discuss with HJS about his concerns regarding
the build changes.

cd: Discussed problem with HJS. I will adapt the provided desktop patch to use a
generic way for the splash image. Currently HJS cannot accept patch as it will
break our internal build. Thanks kendy for your patch, I hope that we will be
able to integrate it into OOo 2.2.

Hi Carsten,

> I will adapt the provided desktop patch to use a generic way for the splash 
> image. Currently HJS cannot accept patch as it will break our internal build. 

    Thanks so much for that, and your nice IZ comment - good stuff. The key for
us is really having several images that are tried in sequence :-)

cd: Started to think about a solution.

cd: Issue will be part of the CWS oointroaboutbrand

cd: Due to other important tasks (better support for extension developers) this
task has to be fixed in OOo 2.3. I will start it as soon as possible to be sure
that it will be integrated into 2.3.

cd: Changed due date of CWS oointroaboutbrand.

cd: Now checking the patch from kendy to check how to integrate it. IS accepted
the intros-scp2.diff part although he finds a little bit strange. Want to
discuss the intro and about bitmap lists with HJS again. Hopefully we will find
a way to go.

cd->kendy: What do you think about using only one zip file for both intro and
about bitmaps? It would help us to adapt your patch to our internal (Sun) build
env. Overall we think that your solution is good to handle intro/about bitmaps
in a more flexible way.

cd: Generally it's OK for me - just that one is generated in sfx2 and the other 
in svx.  But if you can join it nicely, no problem from my side :-)

using a .zip file for this stuff means that for our ultra-fast splash screen
application: it is likely that we will have to do a ton of extra work, pain,
size, etc. to get the splash screen pulled off the disk & shown.

ie. not a good plan :-) if our current tiny, native quick-starter has to
initialize UNO, the configuration mess, find the 'package' service, load the zip
file, extract the image etc. Then this will be less of a 'splash' screen and
more a small whimper ;-)

[ or did I mis-understand ? ]

mmeeks: This is something else ;-)  The usage of .zip in this case is just a 
hack to be able to pack an unknown number of files in scp2.  The .zip(s) are 
unpacked during the creation of the installation set.

cd->mmeeks: We only use the zip file for packaging. At installation time the zip
file will be unzipped and 0-n bitmaps are stored into the program folder. No
problem at all with startup performance!

ah perfect :-) I'll shut up & go bother someone else. Thanks :-)

cd->kendy: Please verify the changes from ause and me. We had to adapt your
patch for desktop,sfx2 and svx to be compatible with the latest code changes.
Please let me know if you need the changes as a patch.
The Sun build environment now uses the same approach as the original patch. The
splash and about bitmap are compressed into the "intro.zip" archive. At
installation time the archive will be decompressed and the files are written to
the program folder.

cd: Fixed.

cd->kendy: Please verify our changes and afterwards send the issue back to me.

cd: Reopening, unfortunately the build in 'desktop' fails during a parallel 
build :-(

cd desktop
build -- -P10

/local/ooo-build/ooo-build-locking/build/oof680-m14/desktop/zipintro
dmake: Executing shell macro: +-test -d {$(subst,$/$(LANGDIR), $(null,
$(ZIP1DIR) . $(ZIP1DIR)))}/ && find {$(subst,$/$(LANGDIR), $(null,$(ZIP1DIR) . 
$(ZIP1DIR)))}/ -type d ! -name CVS ! -name "." | sed "s/\.\/\///" | sed "s/\.
\///"
dmake: Executing shell macro: +-test -d {$(subst,$/$(LANGDIR), $(null,
$(ZIP2DIR) . $(ZIP2DIR)))}/ && find {$(subst,$/$(LANGDIR), $(null,$(ZIP2DIR) . 
$(ZIP2DIR)))}/ -type d ! -name CVS ! -name "." | sed "s/\.\/\///" | sed "s/\.
\///"
dmake: Executing shell macro: +-test -d {$(subst,$/$(LANGDIR), $(null,
$(ZIP3DIR) . $(ZIP3DIR)))}/ && find {$(subst,$/$(LANGDIR), $(null,$(ZIP3DIR) . 
$(ZIP3DIR)))}/ -type d ! -name CVS ! -name "." | sed "s/\.\/\///" | sed "s/\.
\///"
dmake: Executing shell macro: +-test -d {$(subst,$/$(LANGDIR), $(null,
$(ZIP4DIR) . $(ZIP4DIR)))}/ && find {$(subst,$/$(LANGDIR), $(null,$(ZIP4DIR) . 
$(ZIP4DIR)))}/ -type d ! -name CVS ! -name "." | sed "s/\.\/\///" | sed "s/\.
\///"
------------------------------
Making: ../unxlngx6.pro/misc/zipintro.dpz
dmake -P10 -f makefile.mk  
make_zip_deps=true ../unxlngx6.pro/misc/dev_intro.dpzz ../unxlngx6.pro/misc/dev_nologo_intro.dpzz ../unxlngx6.pro/misc/nologo_intro.dpzz ../unxlngx6.pro/misc/intro.dpzz
dmake: Executing shell macro: +-test -d {$(subst,$/$(LANGDIR), $(null,
$(ZIP1DIR) . $(ZIP1DIR)))}/ && find {$(subst,$/$(LANGDIR), $(null,$(ZIP1DIR) . 
$(ZIP1DIR)))}/ -type d ! -name CVS ! -name "." | sed "s/\.\/\///" | sed "s/\.
\///"
dmake: Executing shell macro: +-test -d {$(subst,$/$(LANGDIR), $(null,
$(ZIP2DIR) . $(ZIP2DIR)))}/ && find {$(subst,$/$(LANGDIR), $(null,$(ZIP2DIR) . 
$(ZIP2DIR)))}/ -type d ! -name CVS ! -name "." | sed "s/\.\/\///" | sed "s/\.
\///"
dmake: Executing shell macro: +-test -d {$(subst,$/$(LANGDIR), $(null,
$(ZIP3DIR) . $(ZIP3DIR)))}/ && find {$(subst,$/$(LANGDIR), $(null,$(ZIP3DIR) . 
$(ZIP3DIR)))}/ -type d ! -name CVS ! -name "." | sed "s/\.\/\///" | sed "s/\.
\///"
dmake: Executing shell macro: +-test -d {$(subst,$/$(LANGDIR), $(null,
$(ZIP4DIR) . $(ZIP4DIR)))}/ && find {$(subst,$/$(LANGDIR), $(null,$(ZIP4DIR) . 
$(ZIP4DIR)))}/ -type d ! -name CVS ! -name "." | sed "s/\.\/\///" | sed "s/\.
\///"
echo # > ../unxlngx6.pro/misc/dev_intro.dpzz
zipdep.pl -u -j ../unxlngx6.pro/bin/dev_intro.zip 
"/local/ooo-build/ooo-build-locking/build/oof680-m14/ooo_custom_images/dev/introabout/intro.bmp" 
"/local/ooo-build/ooo-build-locking/build/oof680-m14/default_images/introabout/about.bmp" 
-x "*CVS*" >> ../unxlngx6.pro/misc/dev_intro.dpzz
echo # > ../unxlngx6.pro/misc/dev_nologo_intro.dpzz


zipdep.pl -u -j ../unxlngx6.pro/bin/dev_nologo_intro.zip 
"/local/ooo-build/ooo-build-locking/build/oof680-m14/ooo_custom_images/dev_nologo/introabout/intro.bmp" 
"/local/ooo-build/ooo-build-locking/build/oof680-m14/default_images/introabout/about.bmp" 
-x "*CVS*" >> ../unxlngx6.pro/misc/dev_nologo_intro.dpzz
echo # > ../unxlngx6.pro/misc/nologo_intro.dpzz
zipdep.pl -u -j ../unxlngx6.pro/bin/nologo_intro.zip 
"/local/ooo-build/ooo-build-locking/build/oof680-m14/ooo_custom_images/nologo/introabout/intro.bmp" 
"/local/ooo-build/ooo-build-locking/build/oof680-m14/default_images/introabout/about.bmp" 
-x "*CVS*" >> ../unxlngx6.pro/misc/nologo_intro.dpzz
echo # > ../unxlngx6.pro/misc/intro.dpzz
zipdep.pl -u -j ../unxlngx6.pro/bin/intro.zip 
"/local/ooo-build/ooo-build-locking/build/oof680-m14/default_images/introabout/intro.bmp" 
"/local/ooo-build/ooo-build-locking/build/oof680-m14/default_images/introabout/about.bmp" 
-x "*CVS*" >> ../unxlngx6.pro/misc/intro.dpzz
type 4
type 4


type 4
type 4
zipdep -- version: 1.12
Multi Platform Enabled Edition
zipdep -- version: 1.12
Multi Platform Enabled Edition
zipdep -- version: 1.12
Multi Platform Enabled Edition
zipdep -- version: 1.12
Multi Platform Enabled Edition
cat ../unxlngx6.pro/misc/dev_intro.dpzz ../unxlngx6.pro/misc/dev_nologo_intro.dpzz ../unxlngx6.pro/misc/nologo_intro.dpzz ../unxlngx6.pro/misc/intro.dpzz /tmp/mkuJYobl 
| grep -v "CVS" >> ../unxlngx6.pro/misc/zipintro.dpz
echo zipdep_langs=en-US >> ../unxlngx6.pro/misc/zipintro.dpz
-------------
------------------------------
zip -u 
-j ../unxlngx6.pro/bin/intro.zip /local/ooo-build/ooo-build-locking/build/oof680-m14/default_images/introabout/intro.bmp /local/ooo-build/ooo-build-locking/build/oof680-m14/default_images/introabout/about.bmp 
-x delzip -x "*CVS*" || if test "$?" != "12" && "$?" != "1" ; then exit $? ; 
fi && echo "Nothing to update for zip"
Making: ../unxlngx6.pro/bin/intro.zip
mkdir: cannot create directory `../unxlngx6.pro/bin/dev/': File exists
mkdir: cannot create directory `../unxlngx6.pro/bin/dev_nologo/': File exists
mkdir: cannot create directory `../unxlngx6.pro/bin/nologo/': File exists
cp: cannot stat `../unxlngx6.pro/bin/dev_intro.zip': No such file or directory
cp: cannot stat `../unxlngx6.pro/bin/dev_nologo_intro.zip': No such file or 
directory
rebuilding zipfiles
------------------------------
cp: cannot stat `../unxlngx6.pro/bin/nologo_intro.zip': No such file or 
directory
dmake:  Error code 1, while making '../unxlngx6.pro/bin/dev/intro.zip'
'---* tg_merge.mk *---'

ERROR: Error 65280 occurred while 
making /local/ooo-build/ooo-build-locking/build/oof680-m14/desktop/zipintro

Reassign back to Carsten.

Another problem is that the controlling variables are called 
INTRO_BITMAP_NAMES and ABOUT_BITMAP_NAMES in configure.in and set_soenv.in, 
but INTRO_BMP_NAMES and ABOUT_BMP_NAMES in the makefiles.

I also did not see any usage of INTRO_BITMAPS and ABOUT_BITMAPS - these should 
be copied into the .zip's.

ok, seems like i messed up the variable names...

the only variables used in build, beside configure internal, should be
*_BITMAPS. *_BITMAP_NAMES doesn't even need to be exported from configure.

regarding the mp issue, i'll try to reproduce but up to now it builds fine here
with -P10

fixed variable names. touched desktop, sfx2 and config_office

cd->kendy: Ause fixed your provided issues. We couldn't reproduce your mp issue. 

cd->kendy: Please verify our changes again.

cd->kendy: PING! Please verify the changes in this CWS. We want to integrate
this enhancement as soon as possible in OOo 2.3.

Sorry for the prolonged time :-(  There seems to be some dissonance in what
separator should be used when more bmp's is provided:

+        haveBitmap = loadBitmap( aIntroBitmapFiles.getToken( 0, ',', nIndex ),
+                                 _sExecutePath, _aIntroBmp );

but

const char INTRO_BITMAP_STRINGLIST[]="intro-nld.bmp intro.bmp";

I would change it & commit, but I'm not sure which of the separators is
preferred :-)

I'll try locally with space, and if it works well for me and you are OK with
space, I can commit & mark as verified.

Now works fine, VERIFIED.  Thank you!

[Maybe a nitpick - we could even avoid the getToken() by something like:
#include <stdio.h>

const char* lst[] = { "name1", "name ugh 2", 0 }; /* in the header */

int main( void )
{
    const char **l = lst;
    for ( ; *l != 0; ++l )
	printf( "%s\n", *l );
    return 0;
}
but...]

This issue is closed automatically and wasn't rechecked in a current version of
OOo. The fixed issue should be integrated in OOo since more than half a year. If
you think this issue isn't fixed in a current version (OOo 3.1), please reopen
it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
http://download.openoffice.org/index.html
If you want to know more about the handling of fixed/verified issues =>
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues