On Feb 20, 2006, at 10:48 AM, Joseph J. Strout wrote:
At 10:27 AM -0600 2/20/06, Adam Ernst wrote:
Because I think the current non-native toolbars don't provide a
good user experience. The search field is a nightmare, with
disappearing text and inconsistent behavior
I haven't seen disappearing text; how do you reproduce that?
What's inconsistent about the behavior?
It's a verified bug; see anjdtktr. Reported it about 7 months ago.
There's also gdnprdei, which is appearance-related.
text editing seems not quite right
How so?
jukorywk (Ellipsis, autocomplete, etc. is selectable)
tpnalcsi (Text "jiggles" on Windows; reported by a RS engineer)
wswfwrpv (Doesn't support option-arrow, option-delete)
nupxiung (Doesn't support Copy)
dyqoxdnp (Strange flashes, selection changes)
dragging to reorder items and customizing the toolbar looks wrong
and "fake".
That depends on what you're used to, I suppose. True, the
customization dialog is not the standard OS X one, but it's pretty
similar to what's commonly used on Windows and Linux. In a cross-
platform product, each feature has to be carefully chosen in a way
that will work well for all users; you can't expect your favorite
OS to win every time there is disagreement among platforms.
Well, I obviously disagree. There's no reason that the appropriate
APIs can't be used to provide for native toolbars on all platforms
(apart from the work required). Windowing APIs are all native, so why
can't the toolbar be the same?
This is a case where, in my opinion, the standard OS X GUI isn't as
clear or efficient as one more like what Windows and Linux use.
Perhaps reasonable people can disagree about this; I certainly stick
to my argument that visually dragging is much more intuitive than two
listboxes.
But in any case, "efficiency" is not an excuse to adopt a nonstandard
UI. If that was the case, I'd like to see column-browser file dialogs
implemented for Windows--since they're certainly much more efficient
and clearer than the standard dialog!
And yes, I've reported the appropriate issues in the feedback system.
That's good; if they are bugs, they should be fixed. But sweeping
generalities like:
Custom toolbars just don't cut it on Mac OS X.
suggest to me simple prejudice rather than actual problems. Not
that prejudices aren't important too; you just can't expect
everyone to share the same ones you have.
I don't think it's a prejuidice. If it was, I would reject any
attempt at custom implementations. I don't mind the framework's
custom ListBox or the IDE's custom canvas-based code editor. I don't
*want* to import NIBs from Interface Builder; I'll stick to the
custom window editor, however kludgy it may occasionally be.
I accept all these custom implementations, since they feel and act
relatively native. But the toolbars just seem too "fake" to me, and
it restricts my ability to comfortably use them. The bug reports I
listed above should give you an idea why.
Adam
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
