Closed
Bug 285696
(suite-rebranding)
Opened 19 years ago
Closed 19 years ago
Check in code for rebranding Mozilla for milestone releases
Categories
(SeaMonkey :: General, defect)
SeaMonkey
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: WeirdAl, Assigned: kairo)
References
Details
Attachments
(5 files, 3 obsolete files)
23.55 KB,
patch
|
kairo
:
review+
kairo
:
superreview+
|
Details | Diff | Splinter Review |
2.50 KB,
patch
|
kairo
:
review+
neil
:
superreview+
|
Details | Diff | Splinter Review |
5.16 KB,
patch
|
Biesinger
:
review+
neil
:
superreview+
asa
:
approval1.8b2+
|
Details | Diff | Splinter Review |
5.46 KB,
patch
|
Biesinger
:
review+
neil
:
superreview+
asa
:
approval1.8b2+
|
Details | Diff | Splinter Review |
223.26 KB,
patch
|
neil
:
review+
neil
:
superreview+
benjamin
:
approval1.8b3+
|
Details | Diff | Splinter Review |
Per the community agreement with the Mozilla Foundation, we (the community) will be required to rebrand the Mozilla Application Suite for every release we make. We first need to identify all the places where such branding takes place (splash screen, brand.dtd/properties, etc.). After that (and once we have a confirmed name), we should start work (preferably through the wiki so as to avoid extra bug attachments) on the various pieces of art. Similarly, we should start writing patches so that the rebranding can be turned on by adding a single option to standard .mozconfig files (either a ./seamonkey/config/.mozconfig like file or a --enable-brand=seamonkey, or something like that).
Reporter | ||
Updated•19 years ago
|
Assignee: kairo → general
Reporter | ||
Updated•19 years ago
|
Assignee: general → kairo
Comment 1•19 years ago
|
||
well, given that mf really has no interest in trunk seamonkey, why not just change the branding stuff directly, without a configure option?
Assignee | ||
Comment 2•19 years ago
|
||
Correct. If we don't need some trademark rules similar to what Firefox and Thunderbird have, we don't need all those compiling switches, we just can check in our new branding strings and artwork and be done with it. In any case, this bug will cover whatever we have to do to get our new branding in, either along with those build system things or not. We'll see that when the name and trademark stories clear up.
Assignee | ||
Updated•19 years ago
|
Alias: suite-rebranding
Comment 3•19 years ago
|
||
As expected, changing brand.dtd and .properties does not suffice. (Note: given how it is used, it seems ok to change vendorShortName to "Seamonkey" as well) NSS hardcodes "Mozilla": /security/nss/lib/ckfw/builtins/certdata.c, line 591 -- { (void *)"Mozilla Builtin Roots", (PRUint32)22 } that should probably be changed to "mozilla.org" or something Installer hardcodes Mozilla in various places So do environment variables, but we can probably ignore that, I think /xpfe/bootstrap/nsAppRunner.cpp, line 154 -- #define MOZ_APP_NAME "mozilla" and other places in this file will need to be patched There'll be other things too... this is just what I saw at first sight.
Asa, would it be reasonable to release future 1.8 betas under the community branding?
Assignee | ||
Comment 5•19 years ago
|
||
*** Bug 286065 has been marked as a duplicate of this bug. ***
Comment 6•19 years ago
|
||
Reminder: Please remember to keep out the Godzilla-like images and/or wording from this SeaMonkey build as to avoid the intellectual property information (trademark) conflict and licensing issues as we had in the past.
Assignee | ||
Comment 7•19 years ago
|
||
We should look into help as well when rebranding. Ideally, we have a correct patch for bug 232794 landed before, but else we need to s/Mozilla/whatever there.
Comment 8•19 years ago
|
||
(In reply to comment #7) > We should look into help as well when rebranding. Ideally, we have a correct > patch for bug 232794 landed before, but else we need to s/Mozilla/whatever there. "Mozilla" shouldn't be a problem to change without the patch, it's already an entity (&brandShortName;). Of course we will then end up with "xxx mail & Newsgroups" etc.
Assignee | ||
Comment 9•19 years ago
|
||
Reminder for myself: check MailNews start page (including remove of standalone tip), look through (X)HTML files living in locale/
Assignee | ||
Comment 10•19 years ago
|
||
I've started preparing a patch but I'll wait for legal clearance on the name before posting it. Some notes about things that I still have not in my patch: We should also update the release notes URL in those two files: mozilla/xpfe/global/resources/locale/en-US/region.dtd mozilla/xpfe/global/resources/locale/en-US/builtinURLs.rdf and the default startup page in mozilla/xpfe/browser/resources/locale/en-US/region.properties I've not yet touched those files noted in comments here: mozilla/security/nss/lib/ckfw/builtins/certdata.c Installer (can someone tell me file names here?) locale (X)HTML files
Assignee | ||
Comment 11•19 years ago
|
||
Locale files that still contain a harcdoded "Mozilla"-Reference that should be changed (no paths given at the moment, I'm retriveing data from L10n tool): HtmlForm.properties (DefaultFormSubject) filter.properties (cannotEnableFilter) messenger.properties (filterFolderTruncateFailed)
Assignee | ||
Comment 12•19 years ago
|
||
additionally, I found those: communicator/search/default.htm help/mozillahelp.rdf help/help-toc.rdf help/help-index1.rdf (?) ...and I still trusted the help XHTML files to have only hits because of the copyright line...
Assignee | ||
Comment 13•19 years ago
|
||
As I can't give you the patch yet, here's a list of files I'm touching right now: mozilla/configure.in mozilla/editor/ui/locales/en-US/chrome/region/region.properties mozilla/extensions/help/resources/locale/en-US/mozillahelp.rdf mozilla/extensions/help/resources/locale/en-US/help-toc.rdf mozilla/mailnews/base/search/resources/locale/en-US/filter.properties mozilla/mailnews/base/resources/content/start.xhtml mozilla/mailnews/base/resources/locale/en-US/messenger.properties mozilla/mailnews/base/resources/locale/en-US/region.properties mozilla/mailnews/base/resources/locale/en-US/start.dtd mozilla/profile/defaults/bookmarks.html mozilla/xpfe/bootstrap/nsAppRunner.cpp mozilla/xpfe/bootstrap/version.txt mozilla/xpfe/bootstrap/browser-prefs.js mozilla/xpfe/bootstrap/Makefile.in mozilla/xpfe/browser/resources/locale/en-US/region.properties mozilla/xpfe/communicator/resources/locale/en-US/brand.dtd mozilla/xpfe/communicator/resources/locale/en-US/brand.properties mozilla/xpfe/components/search/resources/locale/en-US/default.htm mozilla/xpfe/global/resources/content/version.dtd mozilla/xpfe/global/Makefile.in mozilla/xpfe/global/resources/content/about.xhtml What I haven't checked yet: Installer (can someone tell me file names here?) I haven't touched start page or release notes, see comment #10 I included a fix for the UA string though, so bug 286057 also gets fixed. What I won't touch: mozilla/security/nss/lib/ckfw/builtins/certdata.c HtmlForm.properties (see bug 287695) I also won't reach into Venkman, ChatZilla or Calendar (yet), though I've filed bugs for their hardcoded strings. If you wonder, inspector has no hardcoded "Mozilla" in the files I checked. Woo-hoo!
Comment 14•19 years ago
|
||
It's been some time since I was in that area of the code, but I can give you a partial list of Installer files. There may be additional ones. mozilla/xpinstall/packages-static-win mozilla/xpinstall/packages-unix mozilla/xpinstall/packages-win mozilla/xpinstall/packager/build/cfgs/mozilla.pl mozilla/xpinstall/packager/build/scripts/makecfgini.pl mozilla/xpinstall/packager/build/scripts/makeuninstallini.pl mozilla/xpinstall/packager/build/win/mozilla/defaults_info.ini mozilla/xpinstall/packager/unix/makecfgini.pl mozilla/xpinstall/packager/win_gre/config.it mozilla/xpinstall/packager/win_gre/makecfgini.pl mozilla/xpinstall/packager/win_gre/makeuninstallini.pl mozilla/xpinstall/packager/win_gre/uninstall.it mozilla/xpinstall/packager/windows/defaults_info.ini mozilla/xpinstall/packager/windows/makeall.pl mozilla/xpinstall/packager/windows/makecfgini.pl mozilla/xpinstall/packager/windows/makeuninstallini.pl mozilla/xpinstall/wizard/windows/builder/build.pl mozilla/xpinstall/wizard/windows/builder/build_gre.pl mozilla/xpinstall/wizard/windows/builder/build_mfcembed.pl mozilla/xpinstall/wizard/windows/builder/build_static.pl
Comment 15•19 years ago
|
||
Does it make sense to start looking at replacing the Netscape stuff at the same time?
Assignee | ||
Comment 16•19 years ago
|
||
(In reply to comment #15) > Does it make sense to start looking at replacing the Netscape stuff at the same > time? If you find Netscape stuff that has to be replaced, maybe... I doubt there's any left though (and referring to e.g Netscape 4.x migration is OK, just to remind you)...
Assignee | ||
Updated•19 years ago
|
Flags: blocking-seamonkey1.0a+
Comment 17•19 years ago
|
||
The following files might need some work too: /xpfe/bootstrap/nsNativeAppSupportBeOS.cpp /xpfe/bootstrap/nsNativeAppSupportOS2.cpp /xpfe/bootstrap/nsNativeAppSupportWin.cpp
Assignee | ||
Comment 18•19 years ago
|
||
OK, I got a first stage of the patch for you. This doesn't contain any real branding change, but lots of stuff that makes the real rebranding easier. And yes, it contains two small other things: - Remove the "advertising" for Thunderbird from mailnews start page - use correct URL for branding bundle in about.xhtml
Attachment #178797 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #178797 -
Flags: review?(cbiesinger)
Comment 19•19 years ago
|
||
Comment on attachment 178797 [details] [diff] [review] patch stage 1: clean up some stuff and use MOZ_APP_* more often +cannotEnableFilter=This filter was probably created by future version of this software. You cannot enable this filter because we don't know how to apply it. hm, ok. maybe the real name would be better here... mozilla/xpfe/bootstrap/mozilla.man.in +Print \fB/usr/bin/@MOZ_APP_NAME@-bin\fR version. this is still wrong if $prefix != /usr... stuff below uses @bindir@, why not use it here too? Please don't check that GARBAGE line in xpfe/bootstrap/Makefile.in in with this patch. I would prefer if rules.mk or somesuch handled it automatically. nsAppRunner.cpp: + printf("%s %s, Copyright (c) 2003-2005 mozilla.org", MOZ_APP_DISPLAYNAME, MOZ_APP_VERSION); might be nice to also output the gecko version mozilla/xpfe/bootstrap/macbuild/Contents/Info.plist.in please get a mac person to review these changes, esp. CFBundleIdentifier Now that about.xhtml no longer lives in /locale/, version.dtd can probably go away; unless we want it for other reasons as well r=biesi with at least the manpage change and removal of the GARBAGE line, and review of Info.plist by a mac person
Attachment #178797 -
Flags: review?(cbiesinger) → review+
Comment 20•19 years ago
|
||
Comment on attachment 178797 [details] [diff] [review] patch stage 1: clean up some stuff and use MOZ_APP_* more often Please fix up the grammar of cannotEnableFilter to say "by a future version". Are those DEFINES supposed to be on separate lines? Would you mind changing the bug reporting address to https: please? You don't have to use %s to embed string contents in printf format strings, you could use "literal" LITERAL concatenation (although I don't know what other modules do). Feel free to fix up the broken build id code. Do we want to display the Gecko version in about: ? Former Suite users might want to know ;-)
Attachment #178797 -
Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
Comment 21•19 years ago
|
||
(In reply to comment #20) > Do we want to display the Gecko version in about: ? Former Suite users might > want to know ;-) Isn't the Gecko version the "rv" part of the Browser line? The "rv" part is there in both Mozilla and Firefox: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050319 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Will the "rv" part be removed in the new suite? I guessed that the browser line would just be something like Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/YYYYMMDD SomeSecretName/1.0 (i.e. with the only change being that the name and version number are added at the end of the line) The browser line is included on the about: page, so would it really be necessary to mention the Gecko version elsewhere too?
Comment 22•19 years ago
|
||
r=sfraser on the mac parts of the patch.
Assignee | ||
Comment 23•19 years ago
|
||
(In reply to comment #19) > hm, ok. maybe the real name would be better here... For one thing, this is a rarely shown text (only when we change the filter interface and an older version tries to use it again), for the other, if we would be correct there, we'd need to list all possible product names that thise future version can have, and I decided extending it to even "SeaMonkey/Thunderbird/Mozilla/Netscape" would look very strange to a user. > mozilla/xpfe/bootstrap/mozilla.man.in > +Print \fB/usr/bin/@MOZ_APP_NAME@-bin\fR version. > > this is still wrong if $prefix != /usr... stuff below uses @bindir@, why not > use it here too? I think the stuff below might be wrong in case of prefix things as well, but I updated it to use the same path for @MOZ_APP_NAME@-bin as below. good catch :) > Please don't check that GARBAGE line in xpfe/bootstrap/Makefile.in in with this > patch. I would prefer if rules.mk or somesuch handled it automatically. OK, I'll exclude it for now and talk to bsmedberg if we really need it. > nsAppRunner.cpp: > + printf("%s %s, Copyright (c) 2003-2005 mozilla.org", MOZ_APP_DISPLAYNAME, > MOZ_APP_VERSION); > > might be nice to also output the gecko version We can probably add that later, if wanted. It should be easy. > mozilla/xpfe/bootstrap/macbuild/Contents/Info.plist.in > > please get a mac person to review these changes, esp. CFBundleIdentifier OK, I hope to find one... > Now that about.xhtml no longer lives in /locale/, version.dtd can probably go > away; unless we want it for other reasons as well Hmm, good idea, I'll look into that in stage 2 (so that I can do some testing before it lands) (In reply to comment #20) > Please fix up the grammar of cannotEnableFilter to say "by a future version". Done. > Are those DEFINES supposed to be on separate lines? Should I better only write the "DEFINES +=" once and use \ at the line endings to concatenate them all at once? I think I can't stick them into one line anyways without breaking the 80-character barrier... > Would you mind changing the bug reporting address to https: please? Sure. Done. > You don't have to use %s to embed string contents in printf format strings, you > could use "literal" LITERAL concatenation (although I don't know what other > modules do). Well, I just used the style of nsAppRunner.cpp - as I'm not really experienced with C++ (yet), I'd gladly use any other style if someone shows me how to do it ;-) > Feel free to fix up the broken build id code. Sure. Where? How? Well, perhaps I might really look into this later, when all that rebranding stuff is done... :) > Do we want to display the Gecko version in about: ? Former Suite users might > want to know ;-) Well, we display the full UA string, which contains the Gecko version. Is that enough? Should we make it more visible? In which way?
Assignee | ||
Comment 24•19 years ago
|
||
OK, this is the stage 1 patch with the review nits fixed. I still need input if it builds OK on windows and mac before I check it in though (linux was tested by me and doron).
Assignee | ||
Updated•19 years ago
|
Attachment #178797 -
Attachment is obsolete: true
Attachment #178870 -
Flags: superreview+
Attachment #178870 -
Flags: review+
Comment 25•19 years ago
|
||
(In reply to comment #23) > we'd need to list all possible product names that thise > future version can have, and I decided extending it to even > "SeaMonkey/Thunderbird/Mozilla/Netscape" would look very strange to a user. Well, just using brandShortName should be ok, and is what I meant... But that may be hardish to implement. > > You don't have to use %s to embed string contents in printf format strings, you > > could use "literal" LITERAL concatenation (although I don't know what other > > modules do). neil: I'm realizing that apprunner seems to already use %s for HELP_SPACER_n, which is also a #define...
Reporter | ||
Comment 26•19 years ago
|
||
(In reply to comment #24) > OK, this is the stage 1 patch with the review nits fixed. > I still need input if it builds OK on windows and mac before I check it in > though (linux was tested by me and doron). Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050328 It compiles just fine.
Comment 27•19 years ago
|
||
(In reply to comment #24) >I still need input if it builds OK on windows It built under mingw using make -s -C objdir/mailnews realchrome && make -s -C objdir/xpfe/bootstrap libs && make -s -C objdir/xpfe/global realchrome
Comment 28•19 years ago
|
||
works fine on windows xp, msvc.net. mozilla -version and help/about mozilla look right.
Comment 29•19 years ago
|
||
Comment on attachment 178870 [details] [diff] [review] patch stage 1, review nits fixed (checked in) applied this patch to 2005-03-28 CVS code and it builds and runs fine on Mac OS X.
Assignee | ||
Comment 30•19 years ago
|
||
Comment on attachment 178870 [details] [diff] [review] patch stage 1, review nits fixed (checked in) OK, stage 1 is checked in, let's move forward!
Attachment #178870 -
Attachment description: patch stage 1, review nits fixed → patch stage 1, review nits fixed (checked in)
Assignee | ||
Updated•19 years ago
|
Status: NEW → ASSIGNED
Comment 31•19 years ago
|
||
Shouldn't https://bugzilla.mozilla.org/show_bug.cgi?id=244672 (and possibly also https://bugzilla.mozilla.org/show_bug.cgi?id=243575) be added to the list of bugs this depends on?
Assignee | ||
Comment 32•19 years ago
|
||
The name of our application does not affect bug 243575, our rebranding is independent from that one. Bug 244672 is a good point and would be nice to have in that effort, but we won't block the alpha for it (same with a bunch of other dependencies though)...
Depends on: 244672
Comment 33•19 years ago
|
||
As discussed with Kairo earlier today, this patch fixes the manual page found in mozilla/xpfe/bootstrap that was broken by the stage 1 patch - basically some variables weren't being replaced, and the paths were wrong so we've set them to the default unix installation paths for now.
Attachment #179393 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #179393 -
Flags: review?(kairo)
Assignee | ||
Comment 34•19 years ago
|
||
Comment on attachment 179393 [details] [diff] [review] Fix Man Page r- via IRC. We should better use the configured prefix (mozappdir) that we install to with "make install". That way some distro can use standard configure options and get a correct man file (I hope).
Attachment #179393 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #179393 -
Flags: review?(kairo)
Attachment #179393 -
Flags: review-
Comment 35•19 years ago
|
||
Revised patch to use mozappdir.
Attachment #179393 -
Attachment is obsolete: true
Attachment #179410 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #179410 -
Flags: review?(kairo)
Assignee | ||
Comment 36•19 years ago
|
||
Comment on attachment 179410 [details] [diff] [review] Revised fix for Man Page Yes, looks good to me this way.
Attachment #179410 -
Flags: review?(kairo) → review+
Comment 37•19 years ago
|
||
Comment on attachment 179410 [details] [diff] [review] Revised fix for Man Page Sorry folks, I got this wrong again, make install installs the wrapper script into bindir & the executable into mozappdir. New patch coming.
Attachment #179410 -
Attachment is obsolete: true
Attachment #179410 -
Flags: superreview?(neil.parkwaycc.co.uk)
Comment 38•19 years ago
|
||
Ok, this one matches where things go when we do a make install.
Attachment #179417 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #179417 -
Flags: review?(kairo)
Assignee | ||
Comment 39•19 years ago
|
||
Comment on attachment 179417 [details] [diff] [review] Revised fixed for man page 2 (checked in) OK, this seems to be where builds really go to for "make install" (and I guess that's what most distributors do to create their packages)
Attachment #179417 -
Flags: review?(kairo) → review+
Updated•19 years ago
|
Attachment #179417 -
Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
Assignee | ||
Comment 40•19 years ago
|
||
Comment on attachment 179417 [details] [diff] [review] Revised fixed for man page 2 (checked in) Manpage fix checked in.
Attachment #179417 -
Attachment description: Revised fixed for man page 2 → Revised fixed for man page 2 (checked in)
Assignee | ||
Comment 41•19 years ago
|
||
Looking through the recently checked in patch for bug 274928 and applying that approach to our stuff, I realised we have to get rid of the \"$(MOZ_APP_NAME)\" trickery in bootstrap's Makefile.in and instead use NS_STRINGIFY() in the .cpp, just like dbaron did there, so we can stuff those strings into the UA without problems (see bug 286057). This patch does exactly that.
Assignee | ||
Updated•19 years ago
|
Attachment #180057 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #180057 -
Flags: review?(cbiesinger)
Assignee | ||
Comment 42•19 years ago
|
||
As biesi has requested it in his review nits for stage 1, and we still have to wait for a complete solution, I hacked up the removal of version.dtd and preprocessing of about.xhtml instead.
Assignee | ||
Updated•19 years ago
|
Attachment #180058 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #180058 -
Flags: review?(cbiesinger)
Updated•19 years ago
|
Attachment #180057 -
Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
Updated•19 years ago
|
Attachment #180058 -
Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
Updated•19 years ago
|
Attachment #180057 -
Flags: review?(cbiesinger) → review+
Updated•19 years ago
|
Attachment #180058 -
Flags: review?(cbiesinger) → review+
Comment 43•19 years ago
|
||
How does MOZ_APP_DISPLAYNAME work with different forms of the name in different languages? For example, assume the following two MOZ_APP_DISPLAYNAMEs: Mozilla: Swedish genitive = Mozillas (i.e. an 's' is added) Firefox: Swedish genitive = Firefox' (i.e. an apostrophe is added) More complex modifications are likely to be needed in languages with more forms of names.
Assignee | ||
Comment 44•19 years ago
|
||
Comment on attachment 180057 [details] [diff] [review] stage 1, additional fix 1: remove quoting trickery in bootstrap (checked in) requesting approval: seamonkey-only fix so that we can use the new vendor additions for UA
Attachment #180057 -
Flags: approval1.8b2?
Assignee | ||
Comment 45•19 years ago
|
||
Comment on attachment 180058 [details] [diff] [review] stage 1, additional fix 2: remove version.dtd (checked in) requesting approval: seamonkey-only cleanup of about page code
Attachment #180058 -
Flags: approval1.8b2?
Assignee | ||
Comment 46•19 years ago
|
||
(In reply to comment #43) > How does MOZ_APP_DISPLAYNAME work with different forms of the name in different > languages? For example, assume the following two MOZ_APP_DISPLAYNAMEs: MOZ_APP_DISPLAYNAME is set at build time and is not localizable, nor are practially all strings it's used in (help text of the mozilla binary etc). All localizable content is supposed to use chrome's branding stuff.
Comment 47•19 years ago
|
||
Comment on attachment 180057 [details] [diff] [review] stage 1, additional fix 1: remove quoting trickery in bootstrap (checked in) a=asa
Attachment #180057 -
Flags: approval1.8b2? → approval1.8b2+
Comment 48•19 years ago
|
||
Comment on attachment 180058 [details] [diff] [review] stage 1, additional fix 2: remove version.dtd (checked in) a=asa
Attachment #180058 -
Flags: approval1.8b2? → approval1.8b2+
Assignee | ||
Updated•19 years ago
|
Attachment #180057 -
Attachment description: stage 1, additional fix 1: remove quoting trickery in bootstrap → stage 1, additional fix 1: remove quoting trickery in bootstrap (checked in)
Assignee | ||
Comment 49•19 years ago
|
||
Comment on attachment 180058 [details] [diff] [review] stage 1, additional fix 2: remove version.dtd (checked in) Both additional fixes for stage 1 checked in. I hope we'll get clearance on the name soon so I can get to stage 2 a.k.a. "the real thing" :)
Attachment #180058 -
Attachment description: stage 1, additional fix 2: remove version.dtd → stage 1, additional fix 2: remove version.dtd (checked in)
Comment 50•19 years ago
|
||
Once you guys have your rebranding worked out, we'll work on getting you onto UMO.
Blocks: 288371
Comment 51•19 years ago
|
||
I don't see a bug about the splash screen? That needs to be rebranded, right? (And perhaps change color to fit the new logo whatever that may be.)
Assignee | ||
Comment 52•19 years ago
|
||
(In reply to comment #51) > I don't see a bug about the splash screen? That needs to be rebranded, right? > (And perhaps change color to fit the new logo whatever that may be.) Artwork will be resolved after the alpha release, we'll take user submissions for a logo, and the final splash screen will be created after we have such a logo. We'll use some very primitve placeholder artwork for the alpha for the time being, as we can't do a logo contest or something like that when we have no publicly announced name yet.
Anything we need to do about this NetCenter junk? http://lxr.mozilla.org/seamonkey/search?string=netcenter
Assignee | ||
Comment 54•19 years ago
|
||
OK, this is the real thing now. Please DON'T shout out loud about it for now (_no_ blog entries, board threads or similar stuff yet), we're preparing an official announcement for going public with the name, and we want that to hit the news, not some random bugzilla report and patch. So, consider this patch unofficial as long as there's no announcement about a new suite project with a new name out there. Regarding the artwork: Most of the patch size is the splash.xpm image, and the patch mentions quite some "binary" image files that will all have that temporary placeholder artwork contributed by Chris Thomas. This WON'T be our official artwork for 1.0, we'll open a channel for artwork/logo submissions soon after going public.
Attachment #187687 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #187687 -
Flags: review?(neil.parkwaycc.co.uk)
Updated•19 years ago
|
Attachment #187687 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #187687 -
Flags: superreview+
Attachment #187687 -
Flags: review?(neil.parkwaycc.co.uk)
Attachment #187687 -
Flags: review+
Assignee | ||
Comment 55•19 years ago
|
||
Comment on attachment 187687 [details] [diff] [review] stage 2: do the real rebranding requesting approval: suite-only change to rebrand trunk to use the new "SeaMonkey" name throughout the product.
Attachment #187687 -
Flags: approval1.8b3?
Comment 56•19 years ago
|
||
Comment on attachment 187687 [details] [diff] [review] stage 2: do the real rebranding a=bsmedberg
Attachment #187687 -
Flags: approval1.8b3? → approval1.8b3+
Assignee | ||
Comment 57•19 years ago
|
||
OK, we're ready to go code/patch-wise, but Chase is overloaded currently (no time before the july 4 holiday) and can't do the infrastructure stuff atm. We have to coordinate bugs 292268,285696,288199,289846,298901 to make it all happen at once and make the transition as smooth as possible, so we'll push out the whole thing a few days (this is all SeaMonkey-only so we don't have to care about aviary 1.1a2 too much), I hope it'll be ASAP - still need to schedule an impact date/time with Chase though. Additionally, we'll have to wait a few days as well to get MoFo reviews on the announcement which should go public in a tight timeframe around the happening of those changes. Please be warned it's coming up but patient at the same time.
Assignee | ||
Comment 58•19 years ago
|
||
OK, stage 2 has landed and this bug should be fixed. :) Note that Chase is working on resolving the tinderbox problems and infrastructure changes with us right at this moment, and we're still waiting on a review and OK for our announcement from Mozilla Foundation people (we're talking about our realtion to them in there, so they need to sanction it). Please wait just a bit longer until that's all done (trees green, builds appearing at new places, announcement and new project page up at http://www.mozilla.org/projects/seamonkey/ ) before shouting the message out publicly. It should hopefully be a matter of hours to days until we're set up completely. Thanks for your patience and we hope to have a good future with that new, rebranded product!
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 59•19 years ago
|
||
Any idea why this made Tp on btek go up from 835ms to 905ms?
Comment 60•19 years ago
|
||
I bet the new throbber is a lot slower to animate. Could someone please test that by backing out the new throbber and seeing what btek does?
Comment 61•19 years ago
|
||
throbber changes backed out
Comment 62•19 years ago
|
||
Well, that doesn't seem to have been it... what else could have changed?
Comment 63•19 years ago
|
||
throbber changes relanded...
Assignee | ||
Comment 64•19 years ago
|
||
(In reply to comment #60) > I bet the new throbber is a lot slower to animate. Interestingly, the new placeholder throbber is even smaller in size than the old one (which doesn't have to affect Tp directly). What makes me wonder is that luna has no Tp changes at all. Anyways, could we take discussion about the btek Tp problem and about Z changes (which I'd like to have investigated as well) to a new bug?
Comment 65•19 years ago
|
||
I have to note... what I tried was classic throbber, but it looks like tbox may actually be testing modern. someone should try backing out modern throbber.
Comment 66•19 years ago
|
||
I'm fine with a new bug if it's marked blocker. An 8% Tp regression is pretty unacceptable...
(In reply to comment #65) > I have to note... what I tried was classic throbber, but it looks like tbox may > actually be testing modern. someone should try backing out modern throbber. I backed it out.
Assignee | ||
Comment 68•19 years ago
|
||
Modern throbbers are back in, they also had no effect. I filed bug 299624 for the btek Tp increase, and bug 299627 on the codesize increase.
Comment 69•19 years ago
|
||
This checkin affected the about:logo image for Camino. Please to be fixing ASAP.
Comment 70•19 years ago
|
||
yeah, what on earth is going on here?
Assignee | ||
Comment 71•19 years ago
|
||
(In reply to comment #69) > This checkin affected the about:logo image for Camino. Please to be fixing ASAP. Filed as bug 299897
No longer blocks: 299897
Assignee | ||
Updated•19 years ago
|
Comment 72•19 years ago
|
||
What about bug #271745. Something we need to do about it??
You need to log in
before you can comment on or make changes to this bug.
Description
•