Why aren't these completely seperated into a dll or something and called by
both program independantly? Granted I don't know the underlying codebase on
which they are written, but still, it seems kind of muddled the way its
currently done. If it is efficient however, then I humbly beg foregiveness
in this season of peace on earth and goodwill toward all men (and women :o)
I know it would be hard to simply "hide" composer during the install, via
the UI as its part of the chrome, and you'd need two sets of the same chrome
(unless its there is an ifdef type condition check in XUL) with minor tweaks
for the composer links in the composer-crippled version, and anyone that
wrote custom chrome would have to do the same, and then you get into how to
trigger one or the other, and what-if you install the composer option later.
I guess it could be a simply user registry trigger, but still thats
redundant with the duped chrome.
If you did seperate the <textarea> and other text inputs on web pages (which
as you say totals a couple KB) into a commonly called dll or whatever, how
much of composer actually is left size-wise? Removing the chrome, image
files, css, js files that are specific to composer?
MJ
----- Original Message -----
From: "Ian Hickson" <[EMAIL PROTECTED]>
To: "Mike Jaques" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, December 23, 2000 2:48 PM
Subject: Re: Why not a standalone browser?
> On Sat, 23 Dec 2000, Mike Jaques wrote:
> >
> > A better question, why not?
> >
> > Call me a purist, but the main part of a program shouldn't rely on a
> > sub-part.
>
> So the web browser shouldn't rely on the network code? or the XML parser?
> or the CSS renderer?
>
>
> > Removing the dependancy _should_ realize a savings in download size
> > once its incorporated into the dynamic NS installer that downloads
> > only components to be installed.
>
> We need to have the code which does an editor for <textarea> and <input
> type="text"> input boxes. If you don't use the editor we wrote for
> Composer, that means we have to write an entirely new editor -- which is
> redundant, why write two totally separate editors?
>
> If you agree that <textarea> and other text inputs on web pages and in the
> chrome should share the same code, then the difference between including
> the UI part of Composer and leaving it out is a few kilobytes (a few XML
> files, a few CSS files, and a few JS files -- namely, the editor's XUL).
>
>
> > Just because in the past the editor has always been part of the
> > program does not mean that idea cannot be rethought. I just don't
> > think that many people use the editor much anymore and it should be
> > seperated. If people wanna give it a shot, it'll always be there.
>
> But then we'd have to write two editors, one for Composer and one for
> everywhere else that edits text (text input fields, mail compose window,
> etc). That is redundant and means we'd have twice as many editor bugs.
>
> --
> Ian Hickson )\ _. - ._.) fL
> Netscape, Standards Compliance QA /. `- ' ( `--'
> +1 650 937 6593 `- , ) - > ) \
> irc.mozilla.org:Hixie _________________________ (.' \) (.' -' __________
>
