gnustep-dev
[Top][All Lists]
Advanced

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

Fwd: Old question on NSCell


From: Quentin Mathé
Subject: Fwd: Old question on NSCell
Date: Wed, 3 Mar 2004 20:03:20 +0100

Here is a mail for Fred Kiefer…

Hi Fred, when I send this mail to your mail address, I obtain a distribution notification which states the mail cannot be distributed (distribution delay expired).

Quentin.

Début du message réexpédié :

De: Quentin Mathé <address@hidden>
Date: 3 mars 2004 11:50:02 GMT+01:00
À: Fred Kiefer <address@hidden>
Objet: Rép : Old question on NSCell

Le 1 mars 04, à 20:22, Fred Kiefer a écrit :

Quentin Mathé wrote:

Did you make any progress on this? It really would be helpful as this would allow us to simplify the code in all NSCell subclasses.
What I have done with NSButtonCell is just to add a margin for the text when the button is non bordered (in order to have better default look) and removed variants for the dotted rect.

Sorry again, I thought, that you would still remember this old issue, which has nothing to do with your recent changes. We did exchange a mail on this, before you help me with the binary encoding.

Well I'm not able to remember such mails exchange, sorry ;-)

The question was, if the cell frame passed into drawInteriorWithFrame:inView: is the same as the one passed into drawWithFrame:inView: or if the border has been stripped off already. Currently GNUstep has to find out about the border again in the interior method, which I see as a waste of time and effort. So I would expect Cocoa and OpenStep to already pass on the shrinked frame, but I don't have any prove for it. As far as I remember, you were thinking about writing a subclass of NSCell to test this, but than again, I may be totally off here. My memory is getting worse (but not as bad as my spelling).

I have just written this NSCell subclass, precisely NSButtonCell subclass. And I must contradict you on your supposition… drawWithFrame:withView and drawInteriorWithFrame:inView use both the same rect for the first parameter. To quote the Apple documentation, drawWithFrame:withView and drawInteriorWithFrame:inView use not the same rect for the first parameter, when the cell is a text cell or other special cases not mentioned.

The GNUstep code for button is bad currently, because we draw the backgound in drawInteriorWithFrame:inView:, and logically the background is part of the border/bezel, then it should be drawn by drawWithFrame:inView as stated by Apple documentation. drawInteriorWithFrame:inView: is there only to draw the content (text, image etc.).

---

Apple doc :

- (void)drawInteriorWithFrame:(NSRect)cellFrame inView:(NSView *)controlView Draws the “inside” of the receiver—including the image or text within the receiver’s frame in controlView (usually the cell’s NSControl) but excluding the border. cellFrame is the frame of the NSCell or, in some cases, a portion of it. Text-type NSCells display their contents in a rectangle slightly inset from cellFrame using a global NSText object. Image-type NSCells display their contents centered within cellFrame. If the proper attributes are set, it also displays the dotted-line rectangle to indicate first responder and highlights the cell. This method is invoked from NSControl’s drawCellInside: to visually update what the NSCell displays when its contents change. This drawing is minimal and becomes more complex in objects such as NSButtonCell and NSSliderCell.

Subclasses often override this method to provide more sophisticated drawing of cell contents. Because drawWithFrame:inView: invokes drawInteriorWithFrame:inView: after it draws the NSCell’s border, don’t invoke drawWithFrame:inView: in your override implementation.

---

bye,
Quentin.

--
Quentin Mathé
address@hidden




reply via email to

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