Re: NSLayoutManager vs BBEdit (Was Re: Carbon vs Cocoa arguments)
Re: NSLayoutManager vs BBEdit (Was Re: Carbon vs Cocoa arguments)
- Subject: Re: NSLayoutManager vs BBEdit (Was Re: Carbon vs Cocoa arguments)
- From: email@hidden
- Date: Tue, 29 Oct 2002 20:19:06 -0800
At 1:16 PM +0200 10/19/02, Dietmar Planitzer wrote:
>
> From: email@hidden
>
>
>
> Nobody wants the delay, they either want it on or off.
>
>
>
> As for starting a new drag I either click then drag or just drag
>
>from outside
>
> the selection.
>
>
>
> The delay is stupid.
>
>
I want the delay.
>
>
I've never liked how the traditional text dnd implementations worked because
>
it broke consistency between applications.
>
>
Before the introduction of text dnd, you could easily change the current
>
text selection with the mouse. I.e. you could click inside an existing text
>
selection and immediately start to drag the mouse in order to define the new
>
selection. But then some third party developer decided that it would be a
>
"good" idea to randomly break this behavior and overload it with different
>
behavior.
>
>
Since then we have two kinds of applications which interpret the same user
>
gesture in different ways:
>
>
Apps with text dnd. Clicking and dragging starts a drag operation.
>
>
Apps without text dnd. Clicking and dragging starts a text selection
>
operation.
>
>
Cocoa's delay makes it possible to support both gestures at the same time
>
without breaking the traditional way of handling text selection via the
>
mouse.
Are you saying you use drag+drop text or not? I have yet to find
anybody who actually likes drag+drop text and also the delay, usually
if they like drag+drop text the delay just gets in the way.
I find that the delay makes drag+drop text absolutely useless. The
whole point of drag+drop text is it's faster and easier than
cut/copy+paste.
As for consistency I would have all apps implement drag+drop text
without delay. I don't see how the delay makes things more consistent
unless you're trying to make it more consistent with non-Mac apps.
>
One thing that is missing in Cocoa though, is a clear feedback indicator.
>
Like others already said, the cursor should change to the handcursor once
>
the delay has passed by.
>
>
I personally wouldn't mind a user preference which would allow anyone to set
>
the delay to his personal preference. However, while this pref would work
>
with Cocoa apps, Carbon developers would have to add special code to their
>
apps in order to handle the pref.
I would replace the delay gesture with a contextual menu. This would
be consistent with the delay gesture in other apps.
>
Now to your original questions:
>
>
You should be able to change the selection behavior by overriding the
>
-selectionRangeForProposedRange:granularity: method in an NSTextView
>
subclass and returnig an adjusted selection range.
>
>
Changing the text dnd behavior is propably harder. My wild guest would be
>
that you might have luck calling the
>
-dragSelecetionWithEvent:offset:slideBack: method instandly from the
>
mouseDown: method if the current mouse position is inside the current
>
selection range.
>
>
Note that both of these problems are presentation problems. Thats why you
>
should look at NSTextView and its superclass NSText in order to find
>
solutions to them.
Sigh, so is it going to be possible to alter the behavior of
NSLayoutManager or will I have to write a replacement from scratch?
The mechanisms don't appear to be exposed in the public API.
>
>
However, my personal opinion about this stuff is that you shouldn't do it.
>
Because even if you don't like Cocoa's text behavior its still better to
>
leave it as it is because at least all Cocoa's app are consistent to each
>
other.
Considering I mostly use Carbon apps, building Cocoa apps which
behave like Mac apps would make them more consistent.
>
IMHO, the one thing that is worse than app behavior that I don't like is,
>
apps which come with their one set of rules just like it is sadly too common
>
on X Windows.
>
>
>
Regards,
>
>
Dietmar Planitzer
I'll try follow the Mac conventions, not the NeXT ones.
_______________________________________________
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.