Raptor layout engine
Ben Haller
I've been on vacation, so sorry for the late response. But
there's one thing in Chris' message that I'd like to nip in the bud.
[I'm cc'ing you, Becky, in case you have anything to add. This
thread originated in the group which is porting Mozilla to Rhapsody].
Chris McAfee wrote:
> I would suggest we create a simple hierarchy with
> a single HTMLView class as a goal, and we take a look
> at raptor and see if it's going to hold us up or not.
You should consider *all* class and symbol names that start with
"HTML" (and "_HTML") to be reserved by Apple. DR2 contains a private
framework called HTML.framework which defines quite a few things
with these sorts of names. In fact, HTMLView is taken, as is
HTMLTextView, HTMLFrameView, HTMLFramesetView, and practically every
other useful symbol you could think of. This framework is used by
TextEdit, MailViewer, HelpViewer, WebObjects Builder, and other
internal Apple clients to render HTML. It is *not* a full browser
framework, and probably never will be, and it is *not* a public
framework (i.e. the APIs, etc. are internal only), and there's a good
chance it never will be. So it is not in any way in competition
with the effort being done by this group -- I can't overemphasize
that. All I want to do is point out the potential naming conflict.
Even if you don't link against against HTML.framework, I believe
there is still a danger (although someone more experienced with how
linking and such works may correct me), because AppKit may bring in
the HTML framework at times which you are not necessarily in control
of. I'd recommend that you just avoid the conflict by not using
names starting with HTML or _HTML.
- Ben Haller
WebObjects Builder
Apple Computer, Inc.
P.S. This is in no way an official Apple position, a legal
statement, or anything else. I have no idea what Apple's public
position on all this is, if they even have one. These are solely my
opinions.
Wilfredo Sanchez
>> I would suggest we create a simple hierarchy with
>> a single HTMLView class as a goal, and we take a look
>> at raptor and see if it's going to hold us up or not.
>
> You should consider *all* class and symbol names that start with
>"HTML" (and "_HTML") to be reserved by Apple. DR2 contains a private
>framework called HTML.framework which defines quite a few things
>with these sorts of names.
Well, I think we screwed that up internally; we should have made those
NSHTMLView, etc, to avoid this sort of thing, and perhaps we can fix that
before making it public, should we ever do that. I believe we can avoid
these conflicts in any case so long as we don't directly use the HTML
framework. I don't think Mozilla will ever want to do this; I considered
that option, and that code isn't really of any use to this effort.
In any case, anyone making a framework should try to similarly avoid
namespace problems by using a prefix. "Moz" is probably a good one: if we
want to add a yellow framework around the Moz layout code (I think we
do), we should stick with names like MozHTMLView and the like. We noticed
earlier that netscape uses the "NS" prefix in the back end C++ code,
which may be a nuisance, but I don't think that's going to be a problem.
-Fred
---
Wilfredo Sanchez - wsan...@apple.com - 408.974-5174
Apple Computer, Inc. - Rhapsody Core Operating Systems Group
2 Infinite Loop, Mail Stop 302-4K, Cupertino, CA 95014
Ben Haller
> > You should consider *all* class and symbol names that start with
> >"HTML" (and "_HTML") to be reserved by Apple. DR2 contains a private
> >framework called HTML.framework which defines quite a few things
> >with these sorts of names.
>
> Well, I think we screwed that up internally; we should have made those
> NSHTMLView, etc, to avoid this sort of thing, and perhaps we can
fix that
> before making it public, should we ever do that. I believe we can avoid
> these conflicts in any case so long as we don't directly use the HTML
> framework. I don't think Mozilla will ever want to do this; I
considered
> that option, and that code isn't really of any use to this effort.
I believe the "NSHTML" prefix was considered by AppKit and
rejected in favor of "HTML". I don't know the details. But I do
know it was a decision that was considered and made, not just a
historical accident (and much code was changed to use the new naming
convention) so I doubt that it will change.
I was trying to warn that AppKit might link in the HTML framework
even if Mozilla doesn't. For example, if you use an NSTextView (and
people have been talking about using the text system for rendering)
that might create a dependancy on the HTML framework. As I said, the
wisest thing is just to avoid the naming conflict so that it can't
possibly become an issue.
I'm agree that the HTML framework is not useful to this effort.
> In any case, anyone making a framework should try to similarly avoid
> namespace problems by using a prefix. "Moz" is probably a good
one: if we
> want to add a yellow framework around the Moz layout code (I think we
> do), we should stick with names like MozHTMLView and the like. We
noticed
> earlier that netscape uses the "NS" prefix in the back end C++ code,
> which may be a nuisance, but I don't think that's going to be a problem.
Sounds like a good idea.
-B.
Chris McAfee
Wilfredo Sanchez wrote:
>
> > [HTMLView class]
>
> In any case, anyone making a framework should try to similarly avoid
> namespace problems by using a prefix. "Moz" is probably a good one: if we
> want to add a yellow framework around the Moz layout code (I think we
> do), we should stick with names like MozHTMLView and the like. We noticed
> earlier that netscape uses the "NS" prefix in the back end C++ code,
> which may be a nuisance, but I don't think that's going to be a problem.
>
We also need to scope names to the front-end, Mozilla's
pretty big so "Moz" only protects us from the native frameworks.
For the XFE we used "XFE_" prefix, that worked out great.
RhapFE_
RFE_
are two that come to mind.
-Chris
mca...@netscape.com
Unix Communicator
Becky Willrich
I've only a couple things to add to Ben's comments - First, he's right
that "HTML" (and therefore "_HTML") is now a reserved prefix, along with
"NS" and "EO" and a few others - see AppKit's DR2 release notes for
details. Perhaps we should have used "NSHTML", but it's too late now....
Also, as Ben notes, the AppKit dynamically loads the HTML framework upon
demand, so it's not enough to not link your application against the HTML
framework; if you use AppKit, there's always the danger that AppKit will
bring those symbols in at run time. Secondly, I think it's premature to
make any kind of judgment on whether the HTML framework will become public,
although it certainly won't happen for the Premier Release.
Regards,
Becky Willrich
Jamie Zawinski
Chris McAfee wrote:
>
> We also need to scope names to the front-end, Mozilla's
> pretty big so "Moz" only protects us from the native frameworks.
> For the XFE we used "XFE_" prefix, that worked out great.
>
> RhapFE_
> RFE_
>
> are two that come to mind.
Excuse me, my knee is jerking again.
Please spell it out. Identifiers can be long. Abbreviations are ok,
but contractions are lame. I'm ok with "MR" or "MRFE" or "MozillaRFE"
or "MozillaRhapsody" but "Moz" and "Rhap" make me want to hurl.
--
Jamie Zawinski http://people.netscape.com/jwz/ about:jwz
Glenn Carnagey
At 01:47 PM 5/18/98 -0700, you wrote:
>Chris McAfee wrote:
>>
>> We also need to scope names to the front-end, Mozilla's
>> pretty big so "Moz" only protects us from the native frameworks.
>> For the XFE we used "XFE_" prefix, that worked out great.
>>
>> RhapFE_
>> RFE_
>>
>> are two that come to mind.
>
>Excuse me, my knee is jerking again.
>
>Please spell it out. Identifiers can be long. Abbreviations are ok,
>but contractions are lame. I'm ok with "MR" or "MRFE" or "MozillaRFE"
>or "MozillaRhapsody" but "Moz" and "Rhap" make me want to hurl.
Considering the analogies of MacFE and WinFE, as well as hur(t)ling
contractions, perhaps just RhapsodyFE would do it.
_____________________________________
Glenn Carnagey
Webmaster, Chicago Sun-Times
401 N. Wabash, Rm. 513
gl...@suntimes.com, www.suntimes.com
312.321.2603, fax 312.321.2849
_____________________________________
Frank McPherson
On Mon, 18 May 1998, Glenn Carnagey wrote:
> Considering the analogies of MacFE and WinFE, as well as hur(t)ling
> contractions, perhaps just RhapsodyFE would do it.
Or since the API set is arguably more important than the OS it's
implemented on, and since the front end may in fact be portable to other
platforms supporting the OpenStep APIs, perhaps YellowFE would be a good
choice.
--
Frank McPherson PGP public key available
Chris McAfee
Frank McPherson wrote:
>
> On Mon, 18 May 1998, Glenn Carnagey wrote:
> > Considering the analogies of MacFE and WinFE, as well as hur(t)ling
> > contractions, perhaps just RhapsodyFE would do it.
>
> Or since the API set is arguably more important than the OS it's
> implemented on, and since the front end may in fact be portable to other
> platforms supporting the OpenStep APIs, perhaps YellowFE would be a good
> choice.
>
Ok, spell it out: RhapsodyFE or YellowFE as we need it.
Here's how to check out raptor on Unix:
setenv MOZ_SRC `pwd`
setenv STANDALONE_IMAGE_LIB 1
cvs co mozilla/nglayout.mk
cvs co mozilla/config
cd mozilla
gmake -f nglayout.mk pull_all
gmake -f nglayout.mk real_all
The layout people just renamed raptor to nglayout,
they're talking about it in
news://news.mozilla.org/netscape.public.mozilla.layout
I haven't taken a good enough look at this to have
an opinion yet; most of the core raptor people
are sitting in front of windows boxes though, you've been warned.
-Chris
mca...@netscape.com
Unix Communicator