Closed Bug 144488 Opened 23 years ago Closed 23 years ago

Move "Get New Themes..." link somewhere besides XulPlanet.com

Categories

(SeaMonkey :: Themes, defect)

Product:
SeaMonkey
Component:
Themes
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: aaron, Assigned: shliang)

References

Details

Attachments

(1 file)

region.properties, region.dtd update to use our spiffy new theme url redirector
1.28 KB, patch
timeless
: review+
tor
: superreview+
endico
: approval+
Details | Diff | Splinter Review
It's official. I went 20GB over my bandwidth limit last month. The server XulPlanet is running on just can't handle the 60GB+ required to maintain all the mozilla theme traffic (and I can only guess how much more it will take after 1.0). I am moving all the mozilla themes on XulPlanet over to http://www.deskmod.com/?show=showcat&cat_name=mozilla. We need to either move the get new themes link to point there or make a theme sites list on mozilla.org like we've been talking about doing for so long (see bug 120985). I hereby volunteer to maintain that page if we need someone to do it. In any case, we need to get it not pointing to XulPlanet by RC3.
CC ASA
*** Bug 145227 has been marked as a duplicate of this bug. ***
Severity: normal → blocker
Keywords: mozilla1.0
As pointed out in my shiny new dupe (bug 145227), Gerv suggests http://mozilla.org/start/1.0/skins/ - which can then be pointed wherever is suitable without rebuilding the application.
A themes site on mozdev.org would probably make the most sense - but I doubt we have time to set one up before 1.0. We should go for the mozilla.org redirect idea. We also need to get skin authors to submit their skins to deskmod ASAP - can someone please post in .ui, .xul and n.p.b.f.skins? Gerv
Deskmod doesn't know what to do with jar files. I think the skins page should be hosted on mozilla.org instead. I am willing to help maintain it if we host it internally. Hosting it with folks who have nothing to do with Mozilla just doesn't make sense to me.
mm... Make a Mozilla Skin Site, something like SkinMoz, SkinZilla, MozSkin, ThemeMoz Or ThemeMozSkinZilla!
Not knowing about deskmod.com, I asked David Boswell and Josua Lerner from mozdev.org if they could cope with a million CNet/ZDnet 'early adopters' slashdotting them for skins. (300k/skin x 3 skins x 1M users = um, quite a lot.) They say yes, they should have no problem, as Joshua is putting in a pile of mirror sites in preparation for 1.0. So is there someone who wants to set up a themes project on mozdev? Someone who cares a lot about skins themselves? Presumably a really hyped skin developer. Or, if Aaron is still up for it (as per comment 0: "I hereby volunteer to maintain that page if we need someone to do it") ... I'll drop a note on n.p.m.ui and n.p.dev.skins too.
I Have a project (Aphrodite) on Mozdev so I'm familiar with thier setup. I can do the inital site setup and some of the site maintance, but I'll need some vols to help maintain the site. Mozdev sites are maintained via CVS making maintance fairly easy.
Mozdev has approved the themes project. The URL is http://themes.mozdev.org/index.html Right now all that's up are the default templetes. I'm at work right now, so it'll be tonight before I get a chance to start loading content.
If for whatever reason that doesn't work out, we at DeskMod can create a type of co-brand. We have done similar for WinAmp (http://winamp.deskmod.com) and Sonique (http://sonique.deskmod.com). Traffic shouldn't be a problem, as we have plenty of space for transfer. Just let me know what's good for you, and in the interim, what we can do to help :)
An Idea, We link Mozilla to http://mozilla.org/start/1.0/skins/ and make that page a list of sites where Mozilla themes are avaible. That way we don't get locked into just one site (We don't need a repeat of x.themes.org), and users will have a choice of sites to download themes from. Since the load will be spread among more than one site people who can't afford the bandwidth for the "only" site will be able to host themes. Choice is good.
Blocks: 143200
I'm for http://mozilla.deskmod.com/ - has fine design (mozdev is a pure disaster in this area) etc. Or at least a mozilla.org page where people can choose where they get their skins (we can do later setup a site and miror them in the whole world).
Link to a Mozilla.org page. Make that page redirect to Mozdev (or wherever). That way, if the redirection ever has to be changed, we can change it.
http://mozilla.deskmod.com/ is a design disaster ! We must have own categories for each Milestone or the User will download old Themes. Currently you have all Themes in the same list (NS6.x/0.9.4 Theme above a Rc2 Theme) and one Theme has only a Theme version number and no Mozilla Milstone :-(
I just created a Mozilla 0.x category at http://www.deskmod.com/? show=showcat&cat_name=mozilla0 and made http://www.deskmod.com/? show=showcat&cat_name=mozilla for Mozilla 1.0 skins. I also moved the 0.x skin to the new category.
We should go with the way suggested in comment 11. This will, in the long term, be the best way. We could then link to Netscape 7's theme park once that is available, to Mozilla @ DeskMod, to themes.mozdev.org, and so on, at once, without having to mess with Mozilla's Get New Themes code any time again. A hard-coded link to DeskMod is a bad idea because DeskMod is not a Mozilla site. I (I guess we all) appreciate your help, Mike, but what we need is more of a *Mozilla*-related site, which your site isn't by design. A hard-coded link to Netscape's theme park is neither possible at the moment nor a good idea - it will make us more dependant of one distributor.
per John's idea in comment 11, I have checked in http://mozilla.org/themes/mozilla1.0/ it links to both deskmod.com and mozdev. It will show up on the web site in a bit. hmm. i should make the links open in a new window though otherwise that dialog sized window will be too tiny.
BTW mozilla.deskmod.com has setted text/plain for .jar files. Clicking on download theme link is displaying ZIP file in browser window.
How about, instead of http://mozilla.org/themes/mozilla1.0/ , use http://mozilla.org/themes/ instead, and have that page sniff which version of the browser you have and then redirect to .9/, 1.0/, 2.0/ etc. That way it never has to change later on. :-)
Comment #19 is probably the best solution. One thing we should consider: not all users will let Mozilla tell webservers about the client (see UABAR on mozdev ...). So there should be a page for every supported version of Mozilla as in Comment #17 with one common themes-mainpage like in Comment #19. This themes-mainpage could automatically redirect to the "right page", if it can figure (sniff) it out. Otherwise the user will have the choice loading the "right page" manually. The make things easier the themes-subpages could be templated and automatically be created on request. BTW: Is there an attribute in HTML to tell the browser to open a link in a new tab? Would this be at least possible with JavaScript?
> BTW: Is there an attribute in HTML to tell the browser to open a link in a new > tab? No. HTML is not for functionality. XHTML1.1 doesn't allow links opened in new windows either any more (e.g., target was removed entirely). > Would this be at least possible with JavaScript? Not at the moment, and hopefully never as this is a proprietary feature. Solution for this case would be not to use HTML, but to use XUL or something else.
Having different urls for each mozilla version would be a lot easier for users since there would be no problems with browser sniffing. However that would be a lot more work to maintain correctly so i now agree with comment 19, except that the top level themes directory should be reserved for possible future theme related content. I've now created a generic 'download a theme' document at http://mozilla.org/themes/download/ which is a copy of the files in the themes/mozilla1.0 directory.
Regarding Comment #18, I just reset the MIME type for .jar files
Browser sniffing sounds like a good idea. Yet, it shouldn't be impossible to download a 1.0 theme with, for example, an 0.9.9 browser. System administrators will need that kind of capability. Of course, we should make finding themes for different browser versions difficult so novice users won't be tripped up.
Attachment #84441 - Flags: review+
Comment on attachment 84441 [details] [diff] [review] region.properties, region.dtd update to use our spiffy new theme url redirector a=chofmann,jesup,scc
Attachment #84441 - Flags: approval+
let the record show the patch has been committed to the 1.0 branch.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Shouldn't this be checked in on the trunk too?
Download a new theme still opens into the tiny preferences window with 1.0 v.2002052906 and there is no way to 'go back' (alt left arrow does not work, no navigation buttons, no right click menu). Once I'm in the "Download A Mozilla Theme" I'm stuck until I close the preferences window. Going on to mozdev or, even worse, deskmod, results in a tiny window crammed full of stuff. I hope someone is still working to get the theme pages we go to to fit into the tiny window or open into the Navigator window instead of the preferences panel.
This fix still hasn't landed on the trunk.
If this hasn't landed on the trunk yet, it's 'fixed1.0.0', not 'RESOLVED FIXED'. Reopening.
Status: RESOLVED → REOPENED
Keywords: fixed1.0.0
Resolution: FIXED → ---
Somebody land this on the trunk...
Attachment #84441 - Flags: superreview+
Comment on attachment 84441 [details] [diff] [review] region.properties, region.dtd update to use our spiffy new theme url redirector sr=tor
Comment on attachment 84441 [details] [diff] [review] region.properties, region.dtd update to use our spiffy new theme url redirector sr=tor
*** Bug 151100 has been marked as a duplicate of this bug. ***
Checking in region.dtd; /cvsroot/mozilla/xpfe/global/resources/locale/en-US/region.dtd,v <-- region.dtd new revision: 1.10; previous revision: 1.9 done Checking in region.properties; /cvsroot/mozilla/xpfe/global/resources/locale/en-US/region.properties,v <-- region.properties new revision: 1.9; previous revision: 1.8 done
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Verified on all platforms (netscape trunk build: 2002-11-15-08-TRUNK) and netscape branch build (2002-11-14-09-10)
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: