Re: Some small proposals

[Nicola Pero]

> I would like to add a small extension to the NSCell protocol. In
> addition to the performClick: method I would like to have a
> performClickWithFrame:inView: as on NSPopupButtonCell. This would be
> used to implement the performClick: method. Subclasses that would
> overwrite performClick: now will overwrite this new method and at places
> where we need to change the frame before the highlight is drawn (eg the
> NSComboBoxCell) we just implement performClick and change the frame we
> hand on. 
> This change would not be needed if the NSComboBox would use a
> NSPopupButtonCell instead of a NSButtonCell, but I think that this
> change is an improvement that will be of general use. And it wont break
> OpenStep compatibility, as for this the new method is just an
> implementation detail.

yes - I had a look - interesting stuff - perhaps
highlightWithFrame:inView: actually already does what you want ?

The comment in NSComboBoxCell says that we can't use performClick: of the
NSButtonCell because the controlview's bounds are not the ones we want -
but I see also another more serious reason - performClick: on the button
cell would highlight the button cell, wait 1/10 second, then unhighlight
the button cell, then send the button cell action.  As far as I
understand, in the combo box cell we need to do something different - we
want to highlight the buttoncell, then pop up the window with the list,
track the mouse etc, and only at the end of all this unhighlight the
button cell.  This can't be done using performClick: of the buttoncell,
because that highlights and unhighlights the button cell automatically and
sequentially.

In general, my opinion is that if you need to highlight the cell in a
different frame than the control view's, that is probably because you are
implementing something `customized' and `complicated', and so you are
going to want to control when and how to highlight/unhighlight by using
highlightWithFrame:inView: and similiar. (the functionality in
performClick: is trivial anyway).

so, I wouldn't add performClickWithFrame:withView: even if I agree with
you that it wouldn't make too much of a difference as it would be an
internal method.


> The other thing is rather a question. In the specification of NSMenu and
> NSComboBox it is defined that check if an item is included should return
> -1 if it is not there. In other places of the framework the value
> NSNotFound is used instead. Should we stick to the specification here or
> try to be more consistent by using NSNotFound everywhere?

Well - yours is a very good point - but we have this problem that people
using Apple want/will want to port their applications to/from Apple's
libraries, so we need to try being compatible if possible, otherwise they
complain.  Replacing -1 with NSNotFound will raise protests :-)

Probably the idea there was that NSNotFound is for search results not
finding anything, while to mean that nothing hasn't been selected -1 is
used.  The difference is very thin and vague, and I personally agree with
you that it would be cleaner to have a single marker to indicate `missing'
or `not found' or `not existing' or `not selected', but because of the
compatibility issues, I'd prefer if we used -1/NSNotFound as in the doc.