Closed
Bug 29838
Opened 24 years ago
Closed 14 years ago
.xpi component for Composer wanted (make installing composer optional)
Categories
(SeaMonkey :: Composer, enhancement)
SeaMonkey
Composer
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: ssu0262, Unassigned)
References
Details
(Keywords: helpwanted)
Attachments
(1 file)
7.12 KB,
text/plain
|
Details |
basically, the Netscape installer currently has Navigator, Mail&News, SpellChecker, etc... Marketing has requested that there also be a Composer component. This would require that the Composer code be pulled out of having the Navigator (standalone component) require Composer. I don't know what (if any) dependencies are currently in place, but I just wanted it to be though of. Packages-win would need to be updated to deliver the new composer set of files too. There's already a bug filed against the installer to deal with installing this new .xpi file (http://bugzilla.mozilla.org/show_bug.cgi?id=19139).
Comment 1•24 years ago
|
||
ssu--what is the deadline for this? When do you need it? M15? M16? reassign to cmanske; M16 for now (until I get more feedback from ssu)
Assignee: brade → cmanske
Target Milestone: M16
Comment 2•24 years ago
|
||
Kathy: Could you please take on this task?
Sorry for the late response Kathy, but I wasn't sure about the deadline myself until now. We need it by M16 because I still need to write up the .xpi installer for this once your part is done.
also the trickiest thing is to make sure we can install nav only and everything still works. we had a lot of problem with aim component when navigator's xul overlay file references missing links and causes crashes.
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 5•24 years ago
|
||
reassign to me for the moment
Assignee: cmanske → beppe
Status: ASSIGNED → NEW
Comment 6•24 years ago
|
||
there are numerous portions of the Editor code that is required by Nav only, there needs to be a firm understanding as to what the requirements are for only functionality. This probably will not happen by M16 code freeze, but we can at elast find out what the requirements are for functionality and get it started. Cc'ing Eric to see what the Nav only requirements are.
Comment 7•24 years ago
|
||
talked with Cathleen about this and we decided that having a separate option for Composer didn't make sense for now. So, we are just going to leave Composer in for now.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Comment 9•24 years ago
|
||
I am reopening this bug because we need to do this for the next release.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Comment 10•24 years ago
|
||
Composer will require gecko and more, so the install will be pretty much the same as asking to install the browser only
Comment 11•24 years ago
|
||
I thought we had the ability to say that components depend on other components. If that's true, can't the composer component depend on the browser component and only contain the stuff that's unique to composer? I'm going to reopen 19139 since this bug was reopened.
Comment 12•24 years ago
|
||
Comment 13•24 years ago
|
||
In my opinion this is more about being able to remove composer from the menus, etc, than any specific issues of Nav->Editor dependencies and how much space is going to be saved. I'd say that's what's important to users.
Comment 14•24 years ago
|
||
well, actually there are size constraints when looking at this from an embedding perspective, that aside there are other issues as to what should really get installed with a Nav only install request, now that we have the plaintext editor code broken out, a nav only install could just use that portion of the editor. the need for full HTML edit support is not required (at least I don't see a reeason for that). There will probably need to be other restructering for this to happen as well. As for a Composer only install, we would still need to install the browser for rendering purposes, we could suppress the install of mail/news Assigning to sfraser -- Simon I just wanted you to take a look at the discussion, add your thoughts and opinions and then reassign to the appropriate person
Assignee: beppe → sfraser
Status: REOPENED → NEW
Target Milestone: M16 → mozilla0.9.1
Comment 15•24 years ago
|
||
> As for a Composer only install, we would still need to install the
> browser for rendering purposes, we could suppress the install of mail/news
Why would you need to install the Browser? Layout engine yes, but why do you
need the browser?
Sure, you'd lose the "Browse" feature, but that's like complaining that the
"Edit Page" or "Send Page" features don't work in browser only installs. It's
up to the user, and Mozilla should probably eventually support external browser,
mailer and editor anyway if someone wants to go in that direction.
Comment 16•23 years ago
|
||
It would be nice to be able to just install Nav + Mail/News without Composer. If the code isn't ready for this behind the scenes, maybe for now Mozilla could just not install the Composer menu items.
Comment 17•23 years ago
|
||
*** Bug 73902 has been marked as a duplicate of this bug. ***
Comment 18•23 years ago
|
||
*** Bug 74323 has been marked as a duplicate of this bug. ***
Comment 19•23 years ago
|
||
*** Bug 19139 has been marked as a duplicate of this bug. ***
Comment 20•23 years ago
|
||
Is this a marketing requirement?
Status: NEW → ASSIGNED
OS: Windows NT → All
Hardware: PC → All
Target Milestone: mozilla0.9.1 → mozilla1.0
Comment 21•23 years ago
|
||
What, exactly, is this bug describing? Pulling Composer stuff out so that it's an optional add-on to the basic browser is one thing (e.g. the current mail and IM zippies), and creating a Composer-only installer product is something else entirely (much more like "shrimp").
Comment 22•23 years ago
|
||
They just want composer to be an optional install.
Comment 23•23 years ago
|
||
If some of the code has to be there for <textarea>'s and such, that's understandable, but Composer, the application, should be seperate. There is obviously some Composer only stuff, like the menus, and the 4 differant views, that aren't needed for Navigator. Perhaps composer could be split to a common package, and the app package, the common being required for the browser. Other reasons to remove: Many users have no intention of using it to edit pages, and these users that edit the raw HTML are the ones most likely to be offended by Mozilla being bloated with apps they don't want. Less disk space/download time for users not opting to install the composer app parts. I constantly hit eaither CTRL-E (bad) or CTRL-Q (worse) when trying to CTRL-W to close a window. This at least eliminates one case. I think there's a seperate bug on the CTRL-Q/W issue.
Comment 24•23 years ago
|
||
*** Bug 92808 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Summary: .xpi component for Netscape Composer wanted. → .xpi component for Composer wanted (make instaling composer optional)
Comment 25•23 years ago
|
||
*** Bug 98925 has been marked as a duplicate of this bug. ***
Comment 26•23 years ago
|
||
*** Bug 44869 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Summary: .xpi component for Composer wanted (make instaling composer optional) → .xpi component for Composer wanted (make installing composer optional)
Comment 28•23 years ago
|
||
Moving to component Editor:Composer
Assignee: kin → syd
Component: Editor: Core → Editor: Composer
Comment 29•23 years ago
|
||
Any progress here? Just noticed 4.x can be browser-only, so adding 4xp.
Keywords: 4xp
Comment 30•23 years ago
|
||
I've never seen a 4.x version without Composer. Without Mail, yes, but not without composer.
Keywords: 4xp
Comment 31•23 years ago
|
||
I am writing this under Linux running Navigator 4.77. No composer of any type in sight over here. It does not appear in the Window menu, I do not have "Edit in Composer" in my context menus. Unless you prove me wrong, this is the beast in question... --> Readding 4xp keyword
Keywords: 4xp
Comment 32•23 years ago
|
||
I was wrong about the "ratbert" configuration, it didn't include composer. I still fail to see how this fits the 4xp criteria or how that designation helps your case. Whatever, I won't remove it again.
Severity: normal → enhancement
Comment 33•23 years ago
|
||
It fits that criterion if you consider this an enhancement bug about a feature that was present in 4.x. You are right, it is stretching the definition a little. I think we should leave it there as an indicator for a 4.x feature parity bug.
Comment 34•23 years ago
|
||
Can the prefs be removed as well? Overheard some talk about pref perf (sec), and noticed currently mailnews prefs are (er... what's the word) 'alive' (about:config shows them) in a mozilla install lacking mailnews itself.
Comment 35•23 years ago
|
||
Originally the messenger prefs were only delivered with messenger (that's why they're in their own file) but that caused profile migration problems. Still, it may be worth revisiting that issue.
Comment 36•23 years ago
|
||
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Comment 37•23 years ago
|
||
*** Bug 117207 has been marked as a duplicate of this bug. ***
Comment 38•23 years ago
|
||
*** Bug 118540 has been marked as a duplicate of this bug. ***
Comment 39•22 years ago
|
||
Hasn't this been implemented by now? I seem to remember having a composer.xpi component installed with the other components.
Comment 40•22 years ago
|
||
No. At least, it's not in 'custom' install.
Comment 41•22 years ago
|
||
*** Bug 143004 has been marked as a duplicate of this bug. ***
Comment 42•22 years ago
|
||
Does this bug also cover the UI issue or can a bug be filed to just remove all Composer-related UI components? I'm less concerned with having the code for Composed installed. What I would like to be rid of is the UI components that lets a user fire up Composer. A "Browser-Only" install should not include the Composer component. Let me know if I need to file a separate bug for that. Navigator Standalone 4.08 did not include Composer or Mail/News. Many of us used it as the base for creating kiosk apps. It would be nice if Mozilla supported that as part of the installation process.
Comment 43•22 years ago
|
||
*** Bug 154035 has been marked as a duplicate of this bug. ***
Comment 44•22 years ago
|
||
*** Bug 161497 has been marked as a duplicate of this bug. ***
Comment 45•22 years ago
|
||
*** Bug 163266 has been marked as a duplicate of this bug. ***
Comment 46•22 years ago
|
||
If this bug ever gets fixed and checked in: a. I don't know if the View Source window is tied into Composer but if it is, seperate those two because I use the View Source Window a lot and bundle it with Navigator instead. b. whenever you right-click an .html file in Windows and select edit, View Source window in Mozilla (the one with the code highlighting) should open instead of Notepad in a non-Composer installation.
Comment 47•22 years ago
|
||
Can we at least get Composer removed?!? I'm cramped for space on this laptop of mine. *YES* there are legitimate reasons why I want it gone. I don't want it hidden, I want to recover the disk space and inodes that Composer is taking up. Lets hope this doesn't become like the Wicked Witch of the West.
Comment 48•22 years ago
|
||
Does the recent embeding work for plain text only editor, and the new composer .xpt help this bug along at all? Can the current .XPT be added to custom install selection? (And possibly excluded from "Navigator only" install)
Keywords: helpwanted
Comment 51•20 years ago
|
||
*** Bug 244130 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Browser → Seamonkey
Updated•16 years ago
|
Assignee: composer → nobody
Priority: P3 → --
QA Contact: sujay → composer
Target Milestone: Future → ---
Comment 52•15 years ago
|
||
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
Comment 53•15 years ago
|
||
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
Comment 54•15 years ago
|
||
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
Comment 55•15 years ago
|
||
Since we now have several stable releases of Phoenix/Firebird/Firefox now, and that the suite (Netscape/Mozilla/Seamonkey) is on the wayside, I suggest moving this bug from UNCONFIRMED to CLOSED/INVALID.
Comment 56•15 years ago
|
||
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
Comment 57•15 years ago
|
||
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
Comment 58•15 years ago
|
||
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
Comment 59•15 years ago
|
||
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
Comment 60•15 years ago
|
||
I still think this would be nice, but given the dependencies for mail/news, and the general lack of interest in composer, it's probably not going to happen.
Comment 61•15 years ago
|
||
"[...] given the dependencies for mail/news, and the general lack of interest in composer [...]" I would like to see it become optional too. I know there is talk of backporting kompozer to seamonkey as a replacement for composer but perhaps only the portions that are not required by mailnews can be optional namely its UI. At the very least allow to disable calls to composer UI including the component-bar and menu items in preferences. It may still be there internally but we wont have to see it.
Comment 62•14 years ago
|
||
I think it's best to just admit publically that we will not do this. Just like MailNews, Composer is an integral part of the suite and we don't have the resources to work out the details of making those parts of the UI optional that are not used in MailNews (and the backend is even used in the browser, so it can't be optional anyhow). Because of that, this is WONTFIX.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago → 14 years ago
Resolution: --- → WONTFIX
Comment 63•14 years ago
|
||
Ever confirmed: true
Comment 64•11 years ago
|
||
Upon looking at this bug again. Since the split into comm-central and mozilla-central it is entirely possible to make this happen at least from a build system perspective. The UI bits live in comm-central/editor/ui and the backend was dragged into mozilla-central by Mozilla for backend parts to be used by Firefox. Likewise mailnews though last year had it's broken build option removed it is not at all required by composer or navigator to function. But composer both backend and front end bits are required by mailnews. In any event this bug has been open for 13 years and after all this time and these changes in the structure of the entire codebase structure a few times over that this is not being seriously considered. WONTFIX, perhaps. RESOLVED? Not by a long shot.
You need to log in
before you can comment on or make changes to this bug.
Description
•