Re: Unimplemented AppKit classes

[Jeff Teunissen]

Alexander Perez wrote:

> I don't know if anyone has done this before, and I hope someone else
> finds this information useful. As of 1/21/2003 (assuming the docs at
> http://www.gnustep.org/resources/documentation/gui/Gui.html are up to
> date, which they very well may not be...), the following classes exist
> in Apple's AppKit but not in GNUStep:

> *NSDrawer

Personally, I hope this *isn't* implemented.

> *NSStatusBar (looks useful)
> *NSStatusItem (used in conjunction with NSStatusBar)

Silly.

> *NSGlyphInfo
> *NSSimpleHorizontalTypesetter
> *NSTypesetter (perform line layout (word wrapping, hyphenation, & line
>         breaking in vertical or horizontal rectangles))

Possibly implemented, if so it's in Alex's New Text System(tm) which isn't
in the main-line tree at this time.

> *NSNibConnector (should use the following instead of this directly)
> *NSNibControlConnector (manages an action in IB..why not PB/Ren. as
> well?)
> *NSNibOutletConnector (ditto, see above)

Why? Actions and outlets work properly already. Oh, and s/PB/Gorm/

> *NSOpenGLContext (All OpenGL calls are rendered into an NSOpenGLContext.
> *NSOpenGLPixelFormat (must specify this to use above...)
> *NSOpenGLView
> *NSOutlineView (this would be really useful if implemented)
> *NSSound (I seem to remember seeing some traffic on this)

Already implemented.

> *NSPDFImageRep (renders an image from a PDF format data stream)

Not likely, particularly any time soon.

> *NSMovie (QuickTime movie wrapper, quite proprietary)
> *NSMovieView (again, QT movie wrapper, also quite proprietary)

Not likely, for that very reason.

> *NSQuickDrawView (apple proprietary stuff...lets you use Carbon
> QuickDraw functions inside an NSView.)

Simply not gonna happen.

> *NSStepper (this would *really* be useful...looks pretty simple too)
> *NSStepperCell (used in conjunction with above)

If not implemented, nobody ever got around to it.

> *NSToolBar (we *really* need a fully-functional implimentation of this)
> *NSToolBarItem (also needs to be implimented, see above)

Why?

> *NSURLAdditions

Not a class, it's a category on NSURL.

> Is anyone working on an implimentation of any of the above classes for
> GNUStep's AppKit? [...] IMO, having working applications for the
> environment is what the ultimate objective is. People in the mac
> community use these classes, so why shouldn't we if they're terribly
> useful?

Some are useful, some aren't. Some are downright nasty.

Also, "we" may or may not want "Mac applications" running on GNUstep. Mac
users have very different expectations from those of non-Mac users.

For example:

Consider an app designed by Mac people that has been ported to Windows,
and a Windows app that has been ported to Mac OS. Windows ports do not
please Mac users, or vice versa. This is because a good port of an
application doesn't just transport the code of a program, it translates
the *philosophy* of the program to fit in with the native system. It's
almost a rewrite.

If you built, say, Alex's Terminal app on an OS X box, you're not now
running an OS X application -- you're running a GNUstep application on OS
X. In the same way, if you were able to get and build Safari on a GNUstep
system running under Linux, it's still a Mac app that happens to be
running on an OS other than Apple's. So its metaphors will be different,
the location of the "widgets" won't be what we would expect them to be,
and so on.

<DIV class="rant">
This is one reason that X is often considered so dreadful to new users --
there are dozens of different toolkits, each of which looks (and more
importantly, acts) different, each with their own different idea of the
Right Thing to Do(tm). And the apps do the same thing -- even within a
single toolkit, there are dozens or hundreds of different ideas on what's
the best way to design a user interface.

At this point, we have the chance to put together a comprehensive and
/internally-consistent/ system. You don't get that by bringing in stuff
from far-flung locations, you get it by deciding what the defining
principles of the user experience should be, and make those principles
pervasive.

The point of *step was to be like Unix, only more so...and I mean that the
way I said it. *step is more Unix-like than Unix *itself* is! It's a very
natural extension of the philosophy behind Unix...a desktop system based
on those founding principles.

The GUI was designed from the ground up to be simple and clean. It was
simpler than the original Mac GUI, but at the same time it was(and
remains) more powerful!

The Mac was designed to be a work-oriented system -- something to help you
get useful work done without getting in the way. NeXT's GUI went even
further in that direction, while the Mac OS (including OS X) and almost
every other GUI operating environment has backtracked from that.
</DIV>

-- 
| Jeff Teunissen  -=-  Pres., Dusk To Dawn Computing  -=-  deek @ d2dc.net
| GPG: 1024D/9840105A   7102 808A 7733 C2F3 097B  161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project        http://www.quakeforge.net/
| Specializing in Debian GNU/Linux              http://www.d2dc.net/~deek/