[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Proposal to fix NSCell issue

From: Quentin Mathé
Subject: Re: [PATCH] Proposal to fix NSCell issue
Date: Thu, 1 Apr 2004 15:38:30 +0200

Le 1 avr. 04, à 09:18, Markus Hitter a écrit :

Am 01.04.2004 um 03:03 schrieb Quentin Mathé:

... but this is impossible to implement without large modifications on NSMatrix for example

That's strange since all these classes support clicking by the user already.

This is not in relation with the problem. See below

At worst you whould have to sythesize an MouseDown event.

Then Alex and me have thought it would better to deprecate NSCell -performClick: method in favor of a more NSCellish method like performClickWithFrame:inView: which follows the NSCell philosophy like drawInteriorWithFrame:inView:.

In opposite to some drawing, a mouse click is and always will be related to a single pixel/coordinate. So, which frame whould you pass in there?

For the coordinate, NSButtons/NSControls don't make a difference _where_ they are clicked. So, this information is obsolete.

The view you want it obviously the topmost view at this coordinate. No need to pass it in, either. It's always the receiver's view, btw.

I think you doesn't understand in detail how NSCell works and is related to NSControl/NSView...
Short answer :
when you send the -performClick message to the cell, the cell doesn't know the frame where it should draw itself (only the view which contains it know that) and doesn't know the view which contains it (the cell can even be shared between multiple views)… Now you should understand more clearly the problem I think. The problem is with NSCell (subclasses included) -performClick: method, not with NSControl -performClick: method which has no issue (because a control knows its frame and its container (here a superview) unlike a cell).

I still think also that -performClick in NSCell (like Apple) or in NSButtonCell (like OpenStep spec.) is a design error.

As you probably agree, a method to simulate a mouse click is very convenient if you want to do something programmatically what the user could do with his mouse as well.

This is the reason why we want to add -performClickWithFrame:inView: for NSCell and keep -performClick: for NSControl.

Here I reassert this is the reason to deprecate it in favor of performClickWithFrame:inView:

Hmm. Incomatibilities just because other methods in these classes take additional arguments as well?

No, once again, it's just because it's needed.


Quentin Mathé

reply via email to

[Prev in Thread] Current Thread [Next in Thread]