> So you want MDI? :-)
>..
> 9) is a request for using a different UI paradigm (something akin to MDI.)
Not necessarily "MDI" per se, but definately some way of having multiple
"client windows" within the
single application window. MDI implies the ability to
zoom/unzoom/minimise/move/tile/cascade these client windows, which isn't
necessarily required. For example, a simple scheme could have the
Navigator-mode UI looking exactly like it does now except for some buttons
(or menu items or tabs or whataver) to switch between different browser
client windows, new ones being opened (on top of the previous one) when the
user holds the CTRL key when entering a URI or clicking a link.
Remember I said that this operation would be *optional*. If a particular
application (eg. Navigator) only wants one main client window (hardcoded) or
allows the user to configure this option, then it operates exactly as
presently. Hence there is no UI paradigm shift, so the current stage of the
project is irrelevant (noting that, for practical considerations, I always
assumed that there's be no chance of merging with trunk code until after
1.0, if at all).
> 5) is a function of how the application developer develops their
> application. You can write it to integrate with the user's
I don't think that is true (please correct me otherwise - you obviously know
much more than I at this stage). With what I described, I could go to
Mozilla installation and copy a single JAR file into some "applications"
subdirectory. This would contain the chrome, skin and application code (in
terms of some XPCOM servers) of the application. Just by doing this a new
icon would appear on the Mozilla's bottom status bar (next to the current
Nav/Communicator/Comper/etc). If the user clicked this, whatever "app" was
currently running (eg. Navigator) would disappear (but remains there in the
background) and the new one would appear. By "appear" I mean that its client
window(s) appear where the browser window was, and
menus/toolbars/sidebars/etc loose any Navigator settings and gain those of
the new app. If the user wants to go back to the previous app (eg. by
clicking the Navigator status-bar icon) then the new app is made invisible
and tha Navigator UI is restored?
If I was a teacher and I wanted my pupils to have browser functionality but
nothing else, I'd just set my computers to delete Mozilla\Applications\*.jar
(except for Navigator.jar) on bootup (of course the kids would have
Jabber.Jar on diskette!). And so on.
Are you saying Mozilla can do all of this now? I was betting that the
infrastructure was there (seperate applications, chromes, skins, XPIs, XPCOM
typelibs/libs, etc) but some further generalising would have to be done.
I'd like to stress again that nothing I'm suggesting would necessarily stop
Mozilla from working exactly as it does now (that would be up to the
application writer, depending on what they want for their application) but
some different options would be available for applications which wanted to
use them (eg. "MDI").
Does that clarify anything? If you just don't like the ideas then that's
perfectly fine - I won't argue except where I'm not sure that I've got what
I'm proposing across clearly enough.
Cheers,
Chris
"Gervase Markham" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > Thanks - will do. In the meanwhile, how then do I add Komodo to my
> > separate Mozilla installation, so it appears within it in the bottom
left of
> > the lower panel as an "seperate app" along with Communicator/Composer,
> > etc (instead of being something which has to be run separately within
> > its own Mozilla installation). Is it just a case of merging something
into
> > one installed-chrome.txt from the other, and copying the necessary
> > chrome files?
>
> I have no experience with Komodo, but I assume that the developers
> designed it to be a separate app with its own install of Mozilla (which,
> given how quickly Mozilla is changing at the moment, is a very sensible
> move.) I would suspect, however, that the code changes required to make it
> use the "installed Mozilla" may not be enormous.
>
> > I know (two "instances" being two main app windows within the same
process),
> > thats why I used the quotes. I just mean a top level application window,
> > which looks like to separate application copies to the user (its the
latter
> > which is important here).
>
> So you want MDI? :-)
>
> > > Do you think this is a coincidence? Mozilla has for a long time been
an
> > > application platform (albeit an unfinished one.) Almost all of what
you
> > > suggest has been thought of and is planned.
> >
> > No, I'm not that slow. What you say is exactly what I thought,
suggested
> > and said. But I haven't yet found any clues (eg. doc/code snippets)
about
> > support or plans for 5) and I've asked the newsgroups about 9) to
> > the reply "its not something which is planned or regularly asked for".
These
> > are the main points of my suggestion, really. If you know of any URIs
> > covering plans/existing support in this area then I'd be grateful if you
> > could
> > post them.
>
> 5) is a function of how the application developer develops their
> application. You can write it to integrate with the user's
> currently-installed browser, or just install it as a separate application
> altogether. It's not something we have control over.
>
> 9) is a request for using a different UI paradigm (something akin to MDI.)
> There's no reason why this UI style can't be built on top of the Mozilla
> framework, but I think the chances of the current Mozilla applications
> switching over to it at this late stage are probably quite slim. If you
> wanted to build a Mozilla platform that had applications that used this UI
> paradigm, that could certainly be done - and you could then install other
> apps into it.
>
> The point here is not that Mozilla needs changing or improving to do 9),
> it's just that no-one has done it yet and (IMVVHO) it's unlikely to be
> taken on board the main distribution - merely because a complete UI
> paradigm rearrange would be very disruptive, and you'd need a big
> usability improvement to justify it.
>
> Does that make sense?
>
> Gerv
