Re: Leopard weirdness

FROM : Christiaan Hofman
DATE : Fri Jun 06 19:18:40 2008

On 6 Jun 2008, at 6:05 PM, Andreas Höschler wrote:

> Hi Christiaan,
>

>>> 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!?
>


I see that also. I don't think it's a serious problem, as you 
typically would click fast anyway. Probably it has to do with the time 
it checks for a double-click.

>> 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!
>


I seem to remember seeing tables where empty cells have a very small 
area to start editing. Though that may have been custom cells. But 
this sounds a bit inconsistent.

> 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.
>


Another change in behavior is tabbing. Previously tabbing would go 
through a column and would be circular. Now it will go through a row, 
and leave the table after the last column. I'm personally not sure if 
going through a row was a good choice (I would have liked to have a 
setting for that, as now I have to override it in some tableviews). 
But being able to leave the table using tab is an improvement IMO.

>> 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. :-)
>


That's not an incompatibility. When you implement it correctly, it 
will just work on both systems. It will just work differently on the 
different systems. On Leopard it will behave as I described, while on 
Tiger or GNUstep/Solaris it will behave as before. Without the need to 
have separate code paths or special overrides.

Christiaan

> 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
>