Re: Frameworks refernce online...
Re: Frameworks refernce online...
- Subject: Re: Frameworks refernce online...
- From: James Duncan Davidson <email@hidden>
- Date: Fri, 23 Aug 2002 07:16:47 -0700
On Thursday, Aug 22, 2002, at 13:39 US/Pacific, Andy Lee wrote:
I don't agree that one approach is inherently better. As programmers,
our browsing needs change throughout a project -- heck, throughout the
day. With AppKiDo you have a choice -- browser or flat list. With a
click or two, you can hide either, neither, or both. (You may not
have noticed, but you *can* hide and unhide the browser.)
Yeah. I noticed. :) I noticed so well that I hide it and missed totally
the protocol listings there which made me make a later erroneous remark
about "no protocol support' Doh!
Given that you are into more than one way to browsing things, you
should consider putting the protocols on the side bar.
AppKiDo's browser lets you go to a class's superclass with one click.
In Cocoa Browser, if you're looking at a class's instance methods and
want to see its superclass's instance methods, you have to go to the
current class's top-level doc, click on the "Inherits from:" link,
then drill back down to "Instance Methods." In AppKiDo, this whole
operation is reduced to one click. You can efficiently search for
methods up and down the hierarchy.
That's true. I have found myself doing that song and dance.
Cocoa Browser provides *no* way, efficient or otherwise, to see all
the subclasses of a class. Sometimes this can be useful for a newbie
(or even an oldbie who's exploring).
True enough. I trying to imagine the UI that would do what I like about
Cocoa Browser, and what you are describing. Nothing is coming to mind
yet though. It seems that you want to be able to go both ways on that.
2) The Find button on the drawer looks inviting, but only works with
a complete class name.
Not true. It does a prefix search. So "nstabl <return>" lists all
the classes (*and* protocols) associated with tables, because they
happen to have that prefix. Likewise, "nstext <return>" lists classes
and protocols associated with text views.
Ah. Prefix search huh? Substring search would be better in this case. I
guess I don't *think* NS* when I'm searching for stuff even though I
see those letters all the time. Plus it would be handy to find all the
String related things by doing a search on just "String"
If I want to see all classes with "Control" in it because I'm not
sure which control to use, it doesn't work.
This particular example is not a good one. No subclass of NSControl
has "Control" in its name.
<snork> Ok, I'm guilty of just throwing that example out without trying
it. :) But you knew what I meant. :)
I think a more likely case is, you want to see all classes with "Cell"
in the name.
Yep.
You might be wondering what kind of cell you should use for a
particular purpose. This is something I've wondered on different
occasions -- and it's why you can see a list of all the NSCell classes
with one click in AppKiDo's drawer. I figured that would be a common
need, and the browser doesn't quite help enough, because the NSCell
subclasses go three levels down.
The UI there probably won't scale with too many special cases like
that. :) If you do much more, you might want to use a pull down instead
of radio buttons.
More generally, I *might* improve AppKiDo's Find function to accept
wildcard characters so you can do something like "NS*Cell <return>".
But no promises.
Wildcards aren't needed as much as substring matches.
3) No Function or Types reference. They've said it's coming, but.
Until it's there, I can't use it much at all as that's where I spent
a lot of time looking for documentation.
Agreed, Functions ought to be in there, and it's my bad for putting it
off so long (over a month already).
If I were to try to defend the current state of the app, I might say
AppKiDo is designed to do one thing well -- browse classes and
protocols, period. That's where most of *my* doc needs lie. For the
rest, there's MTLibrarian -- and of course, Cocoa Browser.
I *totally* understand the value of "Scratch your own itch". A few of
my own itch scratches went a long way over in the Java world--and I'm a
big believer in it. If any comment I make doesn't work for you, well,
you *should* disregard it. After all, you're making something for
yourself first and foremost--and giving it away to boot. If it doesn't
do something that I want to, and I'm not paying you, then the onus is
on me to either do nothing about it or go write one of my own. :)
4) No Java reference. Objective-C only.
Right, no argument there -- Cocoa Browser is the place to go for Java
docs.
My gut feeling, without having thought through the details, is that a
Cocoa doc browser specialized for the Java classes should be
*slightly* different than an Objective-C one. But anyway, I'm not
going there in the near future.
The Apple docu is in the same format--but then you don't get a
comprehensive view of it in Java's own class hierarchy.
6) No way reference on Protocols, Classes only right now. Lots of
functionality is buried in those Protocols.
Excuse me, there are protocol docs. They start at the top level of
the hierarchy browser.
Yep. Like I said, I had hidden the browser because it didn't work for
me and totally missed them. Interesting stumble I did there, no? :)
(By the way, while making sure that there wasn't protocol docs, I
clicked on NSString in the AppKit list and got the Foundation
NSString docs...)
Aha! Another difference between Cocoa Browser and AppKiDo. The fact
is, NSString is *both* an AppKit class *and* a Foundation class.
More accurately a Foundation class that has three additional methods
added via a category defined in NSStringDrawing.h. The NSString
Additions documentation
(file:///System/Library/Frameworks/AppKit.framework/Versions/C/
Resources/English.lproj/Documentation/Reference/ObjC_classic/Classes/
NSStringAdditions.html) shows up in Cocoa Browser in the AppKit section
(as a class).
So yes, NSString needs to appear in both, but by clicking on NSString
in AppKiDo, I get a merged doc (took me a second to figure out that it
was merging things--looking for drawAtPoint: I came to the realization
that it was a merged doc). Useful, except for when I'm wanting to
program to Foundation only and not AppKit, I don't see that those
methods are *added* only as part of AppKit.
Thinking about it more--it's hard to figure out a decent way of
handling Categories. You *do* want the documentation merged, but it's
important to make sure that you know that a particular method is only
avail in AppKit. At least I end up building enough Foundation only
things for it to matter to me I guess. Not that I'm likely to
accidentally use a drawAtPoint: method when writing a server, but... :)
I think AppKiDo complements other tools, which is why I usually
recommend MTLibrarian as well. I also recommend Cocoa Browser if you
need Java documentation or docs for things AppKiDo doesn't cover.
As always, use whatever works for you. I get paid the same either way.
Yep. Like I said, "scratch you own itch" is the golden rule of this
sort of thing--at least until you start trying to make money at it. :)
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.