Re: [OT] FileMerge as a vacuum
Re: [OT] FileMerge as a vacuum
- Subject: Re: [OT] FileMerge as a vacuum
- From: Laurence Harris <email@hidden>
- Date: Mon, 19 Feb 2007 12:35:24 -0500
On Feb 19, 2007, at 10:05 AM, James Larcombe wrote:
Laurence Harris wrote:
I just used FileMerge 2.2.1 to compare two HTML files. It
sucks because:
- It says there's only one difference even though there are
dozens of differences. The one line it says is different is
not.
Alas, FileMerge only works correctly with Unix line endings.
This can be inconvenient, but as soon as I realised what was
going on, I checked out a fresh repository from CVS with the
required line endings, and have had no problems since. You
should be able to do the same thing with your source control
system.
I don't use a source control system. Now, once you regain your
equilibrium, try to understand that I've never really encountered a
problem where using one would have helped, but I have avoided the
numerous small problems I've seen people who do use one discuss from
time to time. Furthermore, I often want to diff two files that
wouldn't be in a source control system even if I used one.
But beyond that, I have no intention of doing something like what you
describe to get a tool to work correctly unless I have no other
alternative. I don't just develop for the Mac, I *use* a Mac, and I
chose to be a Mac users years ago in part because it was smarter
about this kind of stuff. That's one of the reasons Mac are
considered easy to use. Good Mac software is smarter than this and
Apple should have long ago supplied us with a tool that's smart
enough to handle traditional Mac line-endings.
I don't have a problem with Apple deciding to build Mac OS X on top
of Unix, but I have a big problem with them suddenly deciding that
all Mac developers should adopt a Unix user's mentality that Terminal
is awesome, command line is great, paths are da bomb, man is the
ultimate documentation, and nothing could make us happier than
working with kludgy tools full of hidden features and that haven't
changed significantly in 20 or 30 years.
I don't have a great memory, but I remember well when a Mac developer
was a Mac user who used Mac software to develop software for the Mac
instead of being a Unix programmer who wrote software that runs on a
Mac. Frankly, I think it would be healthier for the platform if we
went back a little closer to the old way by having well-designed Mac
software for developing. I'm not denying the power of Unix tools, but
not everyone can be good at the Unix way of thinking, and in fact,
many of the those who are best at thinking about things the Mac way
will not be good at thinking about things the Unix way.
Do we (the Mac developer community) really want to exclude people who
have a good sense of what Mac software should be simply because they
can't think like programmers with years of experience on a command-
line driven, 30-year-old operating system? For goodness sakes I sure
hope not, and yet that's exactly what we're doing. Sure, let the Unix
folks have all the geeky tools they want, but let's also have tools
that make Mac software development accessible to people who don't
quite think that way. Let's have tools that get high school and
college kids excited about writing Mac software instead of tools that
are frustrating, and involve a steep learning curve because they are
anything but intuitive.
Apple needs to realize that they're pretty much the only source of
Mac development tools these days. It's no longer the case that Apple
can supply a bunch of kludgy tools because people who want something
more can buy CW or Resorcerer or The Debugger or Spotlight (I'd pay
real money for a Mac OS X version of Spotlight -- best tool I ever
used). No one as far as I know is selling alternatives to Xcode,
Interface Builder, FileMerge, and so on, so it falls on Apple to make
these tools the best they can for Mac developers. Xcode seems to be
coming along -- albeit slowly, but Interface Builder is an
embarrassment (at least on the Carbon side), and tools like FileMerge
are clearly not good software in the Mac style. I don't want tools
that require me to change all my line-endings or write scripts or use
Terminal to get them to do something as simple as diff two text files
correctly.
- The names of the commands in that menu are misleading.
They have names like "Choose left" even though they don't
actually "choose" anything.
They do - they choose the changes from one file or the other
to put into the merge file. Drag the splitter bar at the bottom
of the window up to see (and even edit) the merge file.
I saw that, but I still think there is a better verb than "choose"
for this. You're choosing which one to use, so perhaps "Use" would be
more appropriate since FileMerge actually uses your choice. "Choose"
makes me think of "select."
- There's an empty space separating the two panes at the top
from the text at the bottom. It's 40 pixels high. Looks like
a big waste of space to me.
Dragging the splitter bar up may change matters.
Nope.
There is still
a bit of a gap between the splitter and the combo box above the
merge file, but it's not a big deal.
I never saw a combo box and I had the splitter at the bottom, the
top, and everywhere in between. I never saw anything but a 40-pixel
high blank bar with a splitter dot at the top.
Granted, certain aspects of the UI of FileMerge leave a lot to
be desired. Quirks aside, it works well.
I believe you. I just also believe we shouldn't be stuck using tools
with a lot of quirks. ;-) Mac users see "quirks" as the result of
poor design. Mac developers should see them the same way, and so
should Apple.
Larry
_______________________________________________
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