Closed Bug 29838 Opened 24 years ago Closed 14 years ago

.xpi component for Composer wanted (make installing composer optional)

Categories

(SeaMonkey :: Composer, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: ssu0262, Unassigned)

References

Details

(Keywords: helpwanted)

Attachments

(1 file)

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).
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
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.
Status: NEW → ASSIGNED
reassign to me for the moment
Assignee: cmanske → beppe
Status: ASSIGNED → NEW
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.
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
verified in 5/1 build.
Status: RESOLVED → VERIFIED
I am reopening this bug because we need to do this for the next release.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Composer will require gecko and more, so the install will be pretty much the 
same as asking to install the browser only
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.
Attached file Dependancy discussion. —
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.
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
> 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.
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.
*** Bug 73902 has been marked as a duplicate of this bug. ***
*** Bug 74323 has been marked as a duplicate of this bug. ***
*** Bug 19139 has been marked as a duplicate of this bug. ***
Is this a marketing requirement?
Status: NEW → ASSIGNED
OS: Windows NT → All
Hardware: PC → All
Target Milestone: mozilla0.9.1 → mozilla1.0
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").
They just want composer to be an optional install.
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.
*** Bug 92808 has been marked as a duplicate of this bug. ***
Summary: .xpi component for Netscape Composer wanted. → .xpi component for Composer wanted (make instaling composer optional)
*** Bug 98925 has been marked as a duplicate of this bug. ***
*** Bug 44869 has been marked as a duplicate of this bug. ***
Summary: .xpi component for Composer wanted (make instaling composer optional) → .xpi component for Composer wanted (make installing composer optional)
-> editor owners
Assignee: sfraser → kin
Status: ASSIGNED → NEW
Moving to component Editor:Composer
Assignee: kin → syd
Component: Editor: Core → Editor: Composer
Any progress here? Just noticed 4.x can be browser-only, so adding 4xp.
Keywords: 4xp
I've never seen a 4.x version without Composer. Without Mail, yes, but not
without composer.
Keywords: 4xp
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
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
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.
Status: NEW → ASSIGNED
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.
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.
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
*** Bug 117207 has been marked as a duplicate of this bug. ***
*** Bug 118540 has been marked as a duplicate of this bug. ***
Hasn't this been implemented by now?  I seem to remember having a composer.xpi
component installed with the other components.
No. At least, it's not in 'custom' install.
*** Bug 143004 has been marked as a duplicate of this bug. ***
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.
*** Bug 154035 has been marked as a duplicate of this bug. ***
*** Bug 161497 has been marked as a duplicate of this bug. ***
*** Bug 163266 has been marked as a duplicate of this bug. ***
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.
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.
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)
reassign to new account
Assignee: syd → composer
Status: ASSIGNED → NEW
retargeting
Target Milestone: mozilla1.0.1 → Future
Keywords: helpwanted
*** Bug 244130 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Assignee: composer → nobody
Priority: P3 → --
QA Contact: sujay → composer
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
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.
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
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.
"[...] 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.
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 ago14 years ago
Resolution: --- → WONTFIX
Ever confirmed: true
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.

Attachment

General

Creator:
Created:
Updated:
Size: