Re: plea! (was Re: Two enhancement requests)
Re: plea! (was Re: Two enhancement requests)
- Subject: Re: plea! (was Re: Two enhancement requests)
- From: Scott Tooker <email@hidden>
- Date: Sun, 8 May 2005 23:35:49 -0700
On May 8, 2005, at 10:33 PM, Roy Lovejoy wrote:
On May 8, 2005, at 9:56 PM, Chris Espinosa wrote:
On May 8, 2005, at 9:44 PM, Larry Gerndt wrote:
1. Syntax Coloring - Be able to syntax-color both system-defined
API's (Carbon and Cocoa) and user-defined symbols (functions,
classnames, and methods).
2. Editor - Be able to special-click to select subwords.
Larry, thanks for the support.
Enhancement of syntax coloring is oft-requested, probably the most
requested enhancement.
This is not an XCode bash by any means.. This is simply a plea to
make the transition to XCode a pleasurable experience, and not one
filled with depression & regret...
You guys do know that you would gain 100% mindshare if you offered
as complete a "virtual codewarrior" as you could.. (alternate UI/
window grouping/key binding etc)
See below but we actually do both of these :)
Some of us have lived & breathed by metrowerks IDE, since we lived
& breathed by Think C before it.. (and Think Pascal.. and TML
Pascal...)
despite all the way-cool _engineering_ features in XCode, and the
hand-glove fit of IB/Cocoa/XCode, to a majority of Codewarrior
folk, XCode just feels... 'wrong' to a "project thinking" developer..
I find these comments ironic since we modeled our current groups &
files hierarchy on the CodeWarrior model (i.e. you can have groups
that are totally divorced from the file system and organize your
sources with them). However, we've also gone beyond the basic groups
and files models to provide other features like folder references
(the ability to have an item that refers to a folder), smart groups,
filtering in the detail view, variant groups to organize localized
files, etc.
hard to put a precise finger on it, but my vague, 'from the hip
assessment' is that XCode feels more like Visual Studio, than it
does any mac program on the market..
key bindings are an obviously good, high traffic step, though when
I selected those, very few actual binding analogs were changed (see
other posting).. I had to hand-enter all my beloved, decade-old,
muscle memory strokes..
Please file a bug if you'd like to see certain keybindings added to
the CodeWarrior set. I spent some time going through the current
versions of CodeWarrior looking for key equivalents to use, but then
again, it's been a while since I've been using CodeWarrior on a daily
basis.
the whole concept of 'project manager' in XCode may be much more
'powerful' or 'liberating', but again, to me, it screams 'thinly
veiled make file'.. In Codewarrior I had infinite control on how I
group my source files, association by function, etc.. (Hiding third
party source completely). Please tell me I'm missing something,
because now, all the sources are grouped into ONE "Sources"
hierarchy??? I have to sift through all the third party stuff next
to my source??
I'm a bit confused here. While it's true that many of the project
templates have a 'Sources' group, it's just an arbitrary group, the
hierarchy of files and groups under the project icon can be organized
however you like.
If you are talking about the 'Compile Sources' build phase under a
target, that is not so much an arbitrary group as a collection of the
files that are compiled when building the target (similar to the
'Link Order' list in CodeWarrior).
another quick anecdote is that I've just started a contract where
the folks are pretty fresh with XCode themselves.. I couldn't
figure out why their nibs weren't in their final build, as they
were in (what I considered to be) the 'project'..
turns out they were in the "Nib file group", but not in their
"Bundle Resource" build phase..
this thoroughly confused this veteran mac developer (circa 1984),
as it begs the obvious question, why would a nib be *in* a project
but not be "IN" a project..
(okay, i can see some low-traffic possibilities, but i would think
by _default_ they would be..)
Hmm, the majority of the time, when you add a file to the project, it
gets added to a target too.
We provide the ability to have files just in the project without
being in a target to provide more flexibility to the user (i.e. no
need for "dummy" targets when adding notes or documentation to a
project), it also makes it easier to temporarily remove files from a
target.
I don't know if Codewarrior 'coddled' the developer, or just had
it's defaults magically set up to do what the developer wanted 95%
of the time, (so it just _seemed_ to always do the right thing the
first time), and left the 5% to be later edited by hand. (as
opposed to what feels like XCode not doing anything by default, and
leaving 100% to be hand tweaked).
it _seems_ like XCode is powerful enough and flexible enough to
present the project information in a myriad of ways..
i'm just asking for a little bit of 'emulated' sanity for us
metrowerks expatriots, "on the side", "as an alternate", etc.. once
we understand the infinite power, THEN let us flip to the 'native'
mode...
Well, to be honest, this is kind of the point of the CodeWarrior
keybindings set and the "Condensed" workspace mode.
there was a _reason_ why folks used metrowerks (and think c) over
MPW all those years... :-)
Yes, and people have used CodeWarrior for a lot longer than Xcode has
been around.
One thing I've noticed working on Xcode (and Project Builder before
that) for the past five years is that sometimes you like how
something works because that's how it always was, even if the
behavior wasn't optimal (this isn't a slam against CodeWarrior, there
are some aspects of Xcode that suffer from the same "that's how it's
always been" syndrome).
As we improve Xcode, we are trying to find the balance between making
things familiar and making things work the "right" way. Part of this
is providing ways to make the experience easier for those coming from
CodeWarrior or other environments. However, the other part is making
sure that Xcode provides the best workflow possible, and if that
means doing things differently from other IDEs (when it matters),
then that's what we'll do. And I'm sure we will hear from our
developers about it, for good or bad :)
To sum up, we are always interested in feedback about how to make
Xcode a better product and more accessible and familiar to
developers. However, we aren't interested in replicating any given
IDE's UI/workflow as an end in itself. After all if Xcode works just
like "X", why not just use "X"?
Scott
_______________________________________________
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
_______________________________________________
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