Closed Bug 14969 Opened 25 years ago Closed 15 years ago

TweakUI like Package to attract audiences that like to customize

Categories

(SeaMonkey :: Preferences, enhancement)

Product:
SeaMonkey
Component:
Preferences
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: CodeMachine, Unassigned)

Details

(Keywords: helpwanted)

We've heard people asking for both expert and beginner chrome to be shipped with Moz/NN5. I think it'd be great if we shipped even more than that, ie: Beginner - Very few things in the window. Power User - Few more things. Web Developer - Interested in buttons to help previewing/debugging pages, eg bug #11140. ? Are there any other groups that it would be useful to target?
Summary: Multiple chromes targetted to audiences. → [RFE] Multiple chromes targetted to audiences.
Marking RFE
Another possible chrome would be "kiosk" chrome. This would be designed for kiosks, and would not include a lot of stuff. Whether there would be a kiosk mode for the mailer (public e-mail account), I don't know. You might still need more controls for kiosk mode of course. For this to work, you might well want a way to differentiate between kiosk and administrator chrome on the command line (or by running a different program for Mac people).
This would also have an installer issue - the installer should ask which chromes to install, and which should be the default.
Target Milestone: M14
Move to M20.
Move to "Future" milestone.
Target Milestone: M20 → Future
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy
Assignee: don → vishy
leger is no longer @netscape.com changing qa contact to default for this component
QA Contact: leger → doronr
Component: Browser-General → Themes
moving to themes component
I don't think that themes are really the way to do this ... you'd need a Modern Novice, Modern Expert, Classic Novice, etc. Aren't "packages" the word we now use for this sort of thing? When I filed this I had an idea of what chrome was that was different from what it is known as now (and was probably never the same).
yes this is probably wontfix. packages can behave like tweakui or other things
Actually this can be done using userChrome.css and userContent.css (http://www.mozilla.org/unix/customizing.html). All we would need to do is hack a few different user*.css with the different desired modes.. then at startup (or dinamically, i'm pretty sure we can do that), we can chose which stylesheet to use. This could also be used to hack a full-screen mode (I've done that on my build, but I haven't figured out the dynamic switching of stylesheets yet). Please note that two bugs (around 68000) have been opened for full-screen and kiosk modes.
> yes this is probably wontfix. packages can behave like tweakui or other things Then this is asking for the package to act like this.
That's fair. marking helpwanted since i'm sure vishy won't do this. I'd suggest specing this in a news group. However as I haven't had time to read them it probably isn't in my best interest. *sigh*
Keywords: helpwanted
Summary: [RFE] Multiple chromes targetted to audiences. → [RFE] TweakUI like Package to attract audiences that like to customize
Setting Component to preference and assigning to nobody@mozilla.org
Assignee: vishy → nobody
Component: Themes → Preferences
QA Contact: doronr → sairuh
This will get fixed by bug 110090.
Depends on: 110090
No longer depends on: 110090
adding self to cc list
Summary: [RFE] TweakUI like Package to attract audiences that like to customize → TweakUI like Package to attract audiences that like to customize
I don't think that this got fixed by bug 110090. True, it is now possible to edit any pref in Mozilla, but what I imagined this RFE should do is something like this: - make a package that will be a part of the default Mozilla download, but not installed by default - when installed, the package would add "Advanced Preferences..." right below "Preferences..." in the Edit menu - the "Advanced Preferences..." would open a dialog similar to the normal Preferences, just with a different set of preferences and categories - more advanced/unusual things, also probably more of them than there are in the normal Preferences. Alternatively, the package would just add more categories to the normal Preferences dialog, and perhaps a few Advanced buttons in existing pref categories. Or do I misunderstand the intent of this bug?
QA Contact: sairuh → nobody
Product: Browser → Seamonkey
Priority: P3 → --
QA Contact: nobody → prefs
Target Milestone: Future → ---
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
WONTFIX. This sounds like excellent Extension fodder, like FasterFox.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.