Accessing function definitions Radar (Re: Accessing function definitions)
Accessing function definitions Radar (Re: Accessing function definitions)
- Subject: Accessing function definitions Radar (Re: Accessing function definitions)
- From: Laurence Harris <email@hidden>
- Date: Fri, 27 Oct 2006 10:43:44 -0400
I'm trying to write up an enhancement request for this and I want to
request the best possible enhancement if I'm going to take the time
to do it. After thinking about it, frankly I think what CE does is
the best approach. In CW, Option-double-clicking either takes you to
a function definition if there's only one implementation, or opens a
window with a simple list of functions of the form
ClassName::FunctionName listed alphabetically. If I want a menu of
all of them I open a contextual menu and one of the submenus lists
all of them.
I find this far superior to what Xcode does because it gives me
simple control over which I want -- menu or list -- independent of
the number of instances of the symbol. Isn't that what we really
want? Why force me to use one interface if there are less than X
implementations and another if there are more than X, even if I get
to choose X? I might want to see a list for 10 one time and a menu
for 50 the next.
Other problems with the current Xcode approach:
- Opening a menu in response to a double click (even with the Command
key pressed) is not standard behavior. Menus should only open in
response to pressing a mouse button.
- The contextual menu Xcode displays when I open a CM for a selected
function name (or by clicking anywhere is a source file) makes no
sense to me. Most of the items in it have nothing to do with the
current text selection (or *any* text selection). Contextual menus
should be *contextual*. This menu is not contextual in the least. It
contains the same commands no matter where I click or if any text is
selected or not, and only one item disables if no text is selected
(Search in Spotlight). Jump to Definition, for example, is always
there and always enabled. It just doesn't do anything if you choose
it without a symbol currently selected. This prompts the following
questions:
- Who writes this stuff?
- Who designs this stuff?
- Has he ever written a Mac application prior to joining the Xcode team?
- Has he ever used a Mac before joining the Xcode team?
I'm sorry if that seems harsh, but while non-standard behaviors
occasionally make sense, Xcode has too many behaviors that just seem
like the programmer who wrote them didn't know how Mac software is
supposed to work. I for one don't like to spend my time filing Radars
that basically say "Standard Mac behavior is blah. Please implement
it." I filed several of those for Interface Builder and now it looks
like it's Xcode's turn.
Hey, maybe they should hire a bunch of developers from another
platform to write Mac development tools! Oh wait, I think they
already did that, and it shows.
Larry
On Oct 26, 2006, at 8:11 PM, Greg Guerin wrote:
Laurence Harris wrote:
I agree. What's the official name of that popup so they'll know
what I'm
talking about when I write it up?
I'm not sure of its name. It might be "method popup", but I could
be wrong.
The unambiguous approach is to describe the steps that make it
appear, then
say:
Observed results: No more than 20 items can ever appear in the menu.
followed by:
Expected results: The ability to configure more than 20 items.
and proceed to describe how limiting a 20-item menu is on today's
large
screens. I think some of these limitations are just the result of
J Random
Developer having only a small screen (or only a large one).
Well, no one's offered a way to change it so far. ;-)
I know. I'm hoping that by filing a bug/feature request on it, an
engineer
will look at the source and see a defaults value that's already
being used,
then tell you a magic command:
defaults write ...
which you then share with the world, to much acclaim and paeans of
gratitude.
I wouldn't be a bit surprised if that value dates back to Project
Builder's NeXT days and no one's ever bothered to change it.
It'd surprise me. It's just the kind of thing a seasoned nextstep
developer would get from an NSDefaults, because hard-wiring it at
20 seems
too much like an 800x600 POV (or a latent bug).
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden