Hi Fred,
I just had the attached discussion on [EMAIL PROTECTED] about an
NSTableView incompatibility issue between MacOS 10.2/GNUstep and MacOSX
10.5. After thinking this over for a while I feel that we should
consider to adopt the new behaviour in GNUstep. It's different but it
has a real (may be even important) advantage.
If we indeed adopt that we should at least allow the user to choose one
of the two behaviours with a user default.
Regards,
Andreas
we are in the process of migrating our software from MacOSX 10.2 and
GNUstep to MacOSX 10.5 and figured out a bunch of weird issues
[modifications to AppKit we dislike to say the least, or that we
don't understand yet] that prevent our apps from working properly.
Our apps build NSTableViews programmatically (based on a property
list) and sets the columns to editable or not using [tableColumn
setEditable:flag]. All our tableviews also get
[tableView setDoubleAction:@selector(performDoubleActions)];
[tableView setTarget:self];
The behaviour we expect and are used to since the old OPENSTEP days
(the same on MacOSX 10.2 and GNUstep) is that a doubleclick in an
editable column starts editing the cell, a doubleclick on a
non-editable column invokes the doubleaction of the tableview. On
MacoSX 10.5 the action is always invoked, no cell is editable anymore
whether setEditable:YES was invoked or not. :-(
That's probably not correct. Initiating an edit has changed on 10.5
though. You have to single click the cell in the selected row to edit,
rather than double click. This means you first have to select the row,
then wait at least the double-click time, and then click again.
I checked that and can confirm this behaviour. However, editing the
cell is started only whit a short-single-click on the cell. Editing is
not started when it takes me more than half a second to release the
mouse button again!?
So it works like changing a file name in Finder.
I personally also feel this is annoying, but it's something we'll have
to get used to, as it's now the reality.
On the other hand, this allows you to have both an editable cell and a
double click action for the same cell.
I see the ratio. Thanks for the explanation. I would prefer to be able
to modify this (switch back to old) behaviour in System Preferences
though. :-(
The new approach has the above mentioned advantage but is simply less
efficient. :-(
Is this supposed to be a feature? If so I don't understand the
reasoning. Or am I missing anything.
Yes for both questions.
We commented out the line that sets the action for now. Now the
columns that got a setEditable:YES are editable. However, one has to
do a direct hit on the text to start editing. If one doubleclicks
slightly to the right of the text (but still within the cell) editing
is not started anymore. This is pretty annoying!! :-(
I also think that the need to click on the text is annoying behavior.
I'm not sure if it's a bug though, but I truly fail to see any reason
for this (AOT single-click editing I described above). Especially for
still empty cells it makes it really hard to edit. I do believe this
is cause for a bug report (or at least an enhancement request).
For empty cells I see the old behaviour. You can click anywhere within
the cell and editing gets started!
When I remove the doubleaction from the tableview I get the old
behaviour back (doubleclick on a cell starts editing). I slowly get the
idea ...
Please tell me that I am doing things wrong and that these
incompatibilities can be overcome with a few #ifdefs! I can't believe
what I see...
So it's not an incompatibility you're seeing. Everything you could do
in the past you can still do now. And in fact you can do more. It just
works differently.
Yes, in the past one could not have a doubleaction on a tableview with
all cells being editable (at least on cell had to be non-editable and
the user had to doubleclick on that to invoke the doubleaction). The
new approach allows to have a doubleclickable tableview with all cells
being editable.
You can't simply revert back to the old editing behavior, it would
require you to override several methods in NSTableView, like
mouseDown:. It's very tricky to do that correctly. Moreover, this is
now the standard behavior, so better be consistent. So I advice you to
get used to it.
It's actually an incompatibility issue for us since some users are
working on Macs, others (most) are working on Sun Rays
(GNUstep/Solaris). But that's our problem and Apple couldn't care less.
:-)
It might make sense for GNUstep to adopt the new behaviour. Anyway,
thanks for the helpful discussion. My faith in Apple just returned. :-)
Regards,
Andreas
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
