27446 - Unix needs a startup splash screen

Status: VERIFIED FIXED

(SeaMonkey :: General, defect, P3)

Description

[Chris McAfee]

Unix needs a startup splash screen.

Comment 1

[Stuart Parmenter]

...

Comment 2

[Joseph Elwell]

*** Bug 27674 has been marked as a duplicate of this bug. ***

Comment 3

[Peter Trudelle]

Mass move of all M20 bugs to M30.

Comment 4

[Peter Trudelle]

Mass-moving all M20-M30 XPToolkit bugs to Future

Comment 5

[David Krause]

What's the status of this?  Is this a preference that needs to get changed or
does this need to be implemented?

Comment 6

[Stephen Walker]

*** Bug 69598 has been marked as a duplicate of this bug. ***

Comment 7

[Doron Rosenberg (IBM)]

qa is me

Comment 8

[André Dahlqvist]

Could someone describe the plan for adding this?

Comment 9

[Robert Kaiser]

Hmm, we have a splash.xpm in Mozilla packs, and ./mozilla -help is giving us
info about the -splash option.
But where is the actual splash screen? Would be nice to really _see_ it somewhere...

Comment 10

[timeless]

the file name has to match the binary (so mozilla.xpm i think), however someone 
complained that even that placement (as sibling to binary w/ matching name)  
wasn't working.

Comment 11

[Robert Kaiser]

Hmm, I now copied splash.xpm to mozilla.xpm and mozilla-bin.xpm - both don't work.
I was starting trunk gcc295 nightly 2001-04-17-09 with "./mozilla -splash" from
KDE 2.1.1 a console running xfree86 4.0.3 on a linux/2.4.3 system.

Comment 12

[Marko Macek]

I always thought that no splash screen was actually a feature ;)

Comment 13

[yiming chung]

add cc:

Comment 14

[R.K.Aa.]

*** Bug 95407 has been marked as a duplicate of this bug. ***

Comment 15

[Greg K.]

I'm starting an effort to formalize an effort to revise the parts of Mozilla's
appearance outside themes, such as the icon suite, the installer, the splash
screen, and the Profile Manager dialog.

I've started a web page with some initial ideas and bug links at
[http://greg.tcp.com/mozilla/ui/Outside/introduction.html]. I welcome any and
all comments on it.

Comment 16

[Brian Ryner (not reading)]

Attachment: patch to xpfe/bootstrap

Comment 17

[Brian Ryner (not reading)]

Attachment: New file: xpfe/bootstrap/gtk/Makefile.in

Comment 18

[Brian Ryner (not reading)]

Attachment: New file: xpfe/bootstrap/gtk/nsNativeAppSupportGtk.cpp

This was moved from xpfe/bootstrap/.

Comment 19

[Brian Ryner (not reading)]

Attachment: patch to xpfe/bootstrap v1.1

This fixes the mismatched free() and PR_smprintf_free() calls.

Comment 20

[Brian Ryner (not reading)]

Attachment: patch to xpfe/bootstrap v1.2

One more time... this avoids the unnecessary strdup() when MOZ_TOOLKIT is not
set.

Comment 21

[Brian Ryner (not reading)]

Ok, it turns out that reading in splash.xpm at runtime is pretty expensive.  We
can make the splash screen loading about twice as fast by compiling the xpm into
the nativeapp_gtk library.  I'll post new files tomorrow.

Comment 22

[Brian Ryner (not reading)]

Attachment: patch to xpfe/bootstrap v2.0

Changes from last patch:
 - works with static builds
 - xpm is compiled in
 - implement nsINativeAppSupport and use that interface instead of
nsISplashScreen

Also, fixing a couple of warnings in nsNativeAppSupportBase

Comment 23

[Brian Ryner (not reading)]

Attachment: New file: xpfe/bootstrap/gtk/Makefile.in

Comment 24

[Brian Ryner (not reading)]

Attachment: New file: xpfe/bootstrap/gtk/nsNativeAppSupportGtk.cpp

One other note: I don't intend to check in the printf in the patch to
nsAppRunner.cpp

Comment 25

[Brian Ryner (not reading)]

Attachment: patch to mozilla/Makefile.in

Comment 26

[James Henstridge]

Just thought I would say that putting the splash screen code in a separate
shared library seems like unnecessary bloat.  As the mozilla binary is already
linking against gtk, it seems a bit pointless to separate it out into a separate
library to avoid a dependency.

How useful is it to have mozilla-bin independent of the toolkit?  Isn't the
ability to compile mozilla executables for the different platforms enough?

(also, removing the extra dlopen should make the splash screen display a little
quicker).

Comment 27

[timeless]

> As the mozilla binary is already linking against gtk,
it wasn't supposed to do that.  I build against Qt and Xlib.
> it seems a bit pointless to separate it out into a separate library to avoid 
a dependency.
A dependency against a toolkit that I don't want to use?

> How useful is it to have mozilla-bin independent of the toolkit?
for one it meant that I had antialiasing many months ago because the Qt port 
got it for free from Qt2.3.x. For another building against xlib saves on size 
(no gtk/qt libraries at all) 
>  Isn't the ability to compile mozilla executables for the different platforms 
enough?
according to legend, Pavlov made the decission that it was not.

But enough of this, let's not torture bryner further in this bug.

Comment 28

[Brian Ryner (not reading)]

Attachment: patch that doesn't use extra library

Comment 29

[André Dahlqvist]

I tested attachment 59368 [details] [diff] [review] and -splash works just fine for me. I guess we don't
want it showing by default like win32?

Comment 30

[Stuart Parmenter]

Comment on attachment 59368 [details] [diff] [review]
patch that doesn't use extra library

r=pavlov  is the xpm already in the tree?

Comment 31

[Christopher Blizzard (:blizzard)]

Comment on attachment 59368 [details] [diff] [review]
patch that doesn't use extra library

sr=blizzard

Comment 32

[Brian Ryner (not reading)]

over to me

Comment 33

[Brian Ryner (not reading)]

checked in.

Comment 34

[André Dahlqvist]

I see a splash screen with 2001-12-18-16 on Linux when I pass the -splash
command line argument. I'm resolving this one fixed since nobody answered my
question on weather it should be displayed by default or not like on Win32.

Comment 35

[Grey Hodge (jX)]

Ok, I'm not on *nix, but it looks like even _checking_ to see if there is a
splash.xpm has been pulled. now, I can see wanting to build it in for speed, but
checking to see if the user has a custom splash should only eat an extra 10-20ms
MAX. Plus the fact that the splash.xpm is still being distributed (according to
someone who uses it in Linux) eating an extra 204k of DL time. Wouldn't it be
rather a nice extra to just _check_ for a splash.xpm? On Win32 it does, and just
uses the built in splash is a mozilla.bmp is not present.

Comment 36

[Iuri Fiedoruk]

I'm using Linux and REALLY want to mozilla chekcs my splash.xpm instead using
the default.
I tryied changing splash.xpm, and noticed it didn't changes :(
SO I vote for a PLUS: enabling user-custom splash.

Comment 37

[Chris McAfee]

this bug is done, we have a splash screen.
For defaults, custom stuff, file new bugs please.

Comment 38

[Grey Hodge (jX)]

Bug 116375 is to carry on the new feature aspect of this.

Comment 39

[andrelourenco]

with linux and 0.9.7 -splash doesn't work for me

Comment 40

[James Brents]

Apparantly it wont work on 0.9.7 release, but the same build ID (2001122108)
from the nightly worked just fine using -splash.