Issue 66426 - Easier branding of OOo builds
Summary: Easier branding of OOo builds
Status: CLOSED FIXED
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 2.0.3
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 2.3
Assignee: kendy
QA Contact: issues@framework
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-14 13:20 UTC by kendy
Modified: 2009-07-20 14:52 UTC (History)
8 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
The configure & set_soenv part. (3.87 KB, patch)
2006-06-14 13:21 UTC, kendy
no flags Details | Diff
Intro bitmaps loading. (4.68 KB, patch)
2006-06-14 13:22 UTC, kendy
no flags Details | Diff
About bitmaps loading & packing into a .zip (for scp2 handling). (2.93 KB, patch)
2006-06-14 13:24 UTC, kendy
no flags Details | Diff
Packing intro bitmaps into .zip (for scp2 handling). (897 bytes, patch)
2006-06-14 13:25 UTC, kendy
no flags Details | Diff
scp2 bits to actually install the intros & abouts. (1.03 KB, patch)
2006-06-14 13:26 UTC, kendy
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description kendy 2006-06-14 13:20:54 UTC
From a mail (2006-03-08, "branding artwork location ..."):
----- 8< -----
       So - Mathias is ok with the idea of having a number of splash / about
images & fetching them from disk - as a step in removing our NLD
specific branding patch, and also the multiple distro specific branding
bits.
----- 8< -----

The implementation extends config_office/configure with 3 more switches: 
--with-vendor (specifies vendor of the build), --with-intro-bitmaps, and 
--with-about-bitmaps (specify the intro/about bitmaps).

One can specify more than one bitmap in the --with-*-bitmaps; then the order 
means priority.  Eg. when you specify 
--with-intro-bitmaps="/path/to/first.bmp /another/path/second.bmp", first.bmp 
will be used during OOo startup if exists.  If not, second.bmp will be used.  
If even that one does not exist, the OOo default bitmap will be used.  This 
is interesting for packagers that package OOo for several products.

Please have a look at the attached patches.  If OK, I'll create a CWS for them, 
etc.
Comment 1 kendy 2006-06-14 13:21:47 UTC
Created attachment 37147 [details]
The configure & set_soenv part.
Comment 2 kendy 2006-06-14 13:22:56 UTC
Created attachment 37148 [details]
Intro bitmaps loading.
Comment 3 kendy 2006-06-14 13:24:15 UTC
Created attachment 37149 [details]
About bitmaps loading & packing into a .zip (for scp2 handling).
Comment 4 kendy 2006-06-14 13:25:28 UTC
Created attachment 37150 [details]
Packing intro bitmaps into .zip (for scp2 handling).
Comment 5 kendy 2006-06-14 13:26:33 UTC
Created attachment 37151 [details]
scp2 bits to actually install the intros & abouts.
Comment 6 kendy 2006-06-14 13:28:07 UTC
Please review ;-)  Thank you in advance!
Comment 7 pavel 2006-06-14 17:10:40 UTC
kendy: what about --with-productname too? There are distros/people who hack also
the productname (like OOo-dev, StarOffice etc).

Comment 8 kendy 2006-06-15 09:08:13 UTC
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.
Comment 9 Mathias_Bauer 2006-06-26 15:51:03 UTC
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
Comment 10 kendy 2006-07-04 09:09:00 UTC
ause: Ping? ;-)
Comment 11 hjs 2006-07-04 12:01:52 UTC
"--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.
Comment 12 mmeeks 2006-07-04 12:15:50 UTC
> 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.
Comment 13 kendy 2006-07-12 10:18:44 UTC
> - 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.
Comment 14 kendy 2006-07-27 16:44:22 UTC
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?
Comment 15 carsten.driesner 2006-07-31 12:12:33 UTC
cd->kendy: I will have a look at your code patch. We have to make sure that HJS
accepts your revised build patch.
Comment 16 carsten.driesner 2006-08-01 06:56:15 UTC
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.
Comment 17 carsten.driesner 2006-10-23 10:23:22 UTC
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.
Comment 18 mmeeks 2006-10-23 10:34:59 UTC
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 :-)
Comment 19 carsten.driesner 2006-12-01 10:52:01 UTC
cd: Started to think about a solution.
Comment 20 carsten.driesner 2006-12-19 09:55:38 UTC
cd: Issue will be part of the CWS oointroaboutbrand
Comment 21 carsten.driesner 2007-01-08 11:52:31 UTC
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.
Comment 22 carsten.driesner 2007-02-05 09:18:44 UTC
cd: Changed due date of CWS oointroaboutbrand.
Comment 23 carsten.driesner 2007-03-20 11:20:02 UTC
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.
Comment 24 carsten.driesner 2007-03-20 15:06:38 UTC
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.
Comment 25 kendy 2007-03-20 15:27:44 UTC
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 :-)
Comment 26 mmeeks 2007-03-20 16:29:17 UTC
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 ? ]
Comment 27 kendy 2007-03-20 16:42:36 UTC
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.
Comment 28 carsten.driesner 2007-03-20 16:48:04 UTC
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!
Comment 29 mmeeks 2007-03-20 16:48:47 UTC
ah perfect :-) I'll shut up & go bother someone else. Thanks :-)
Comment 30 carsten.driesner 2007-03-29 10:47:16 UTC
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.
Comment 31 carsten.driesner 2007-03-29 10:47:51 UTC
cd: Fixed.
Comment 32 carsten.driesner 2007-04-02 08:04:50 UTC
cd->kendy: Please verify our changes and afterwards send the issue back to me.
Comment 33 kendy 2007-04-02 13:53:01 UTC
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
Comment 34 kendy 2007-04-02 13:54:54 UTC
Reassign back to Carsten.
Comment 35 kendy 2007-04-02 14:18:35 UTC
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.
Comment 36 hjs 2007-04-02 14:34:50 UTC
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

Comment 37 hjs 2007-04-02 15:37:18 UTC
fixed variable names. touched desktop, sfx2 and config_office
Comment 38 carsten.driesner 2007-04-03 13:05:20 UTC
cd->kendy: Ause fixed your provided issues. We couldn't reproduce your mp issue. 
Comment 39 carsten.driesner 2007-04-03 13:08:03 UTC
cd->kendy: Please verify our changes again.
Comment 40 carsten.driesner 2007-04-11 14:08:42 UTC
cd->kendy: PING! Please verify the changes in this CWS. We want to integrate
this enhancement as soon as possible in OOo 2.3.
Comment 41 kendy 2007-06-06 15:53:20 UTC
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.
Comment 42 kendy 2007-06-07 09:16:36 UTC
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...]
Comment 43 thorsten.ziehm 2009-07-20 14:52:37 UTC
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