Re: gui changes.

[mirko . viviani]

You wrote:

> Read the doc for NSCell -setShowsFirstResponder:
> 
> "Sets whether the receiver displays a dotted-line outline when it
> assumes first responder status."
> 
> That's a heap of rubbish.  A cell is *not* a responder, and so it can
> *never* assume first responder status.  The fact that a cell is not a

It seems to me a documentation bug.

> ugly meaningless design, because when you have a control with more
> than one cell (which btw should be considered the norm), then if the
> control assumes first responder status, all cells draw a dotted
> outline, while when the control resigns first responder, all cells do
> not draw their dotted outline any longer.

It's the 'control' that decides which cell has to be displayed with a dotted
outline. The NSMatrix has more than one cell and when is it the first responder
only one cell at a time has the dotted outline.

> I think you figured out this problem by yourself when implementing
> NSBrowserCell - you had to fight with the meaningless superclass
> implementation and force in by hacking a different behaviour.  We
> can't leave that code that way.

I don't understand where is the problem. Not all the cells display the
dotted outline in the same way. If the browsercell uses the superclass
implementation I have to switch off his dotted outline implementation.

> The correct totally natural and obvious design is - 
> 
> a cell should have a state variable which determines whether it draws
> a dotted outline or not.  This variable can be set/read by using
> something like -setDrawsDottedOutline:, -drawsDottedOutline.

This is the behaviour of -setShowsFirstResponder: and -showsFirstResponder

> The cell
> takes *no* decision whatsoever about responders; it just implements
> the code to draw the dotted outline, and that code can be turned on

In the -NSCell drawInterior... it does not check anymore if the control
cell is the first responder... this is a 'bug' that I have to commit.

> a control manages its cells responding to user actions, and according
> to user action and to what happens in the window, decides which cells
> should draw the dotted outline and which should not.

In fact this is the task of the control and how I've implemented but it
isn't implemented in the NSControl but in every of its subclasses that
want to use the dotted outline 'feature'.

> It would make sense to have the method -setShowsFirstResponder: in the
> *control*.  That would determine whether the control draws the dotted
> outline [ask the cells to draw the dotted outline] around its cells
> when needed, or if this would be disabled.

This could be implemented only to disable the dotted outline feature.

> I'm wondering - could someone make some experiments and tell us
> exactly how the Apple stuff work ?

This is exactly what my OS 4.2 system does. (apart for the matrix that seems
to me a bit bugged)

> I agree to keep these
> methods in gnustep for source compatibility with apple - but we must
> deprecate them and ban them - because they are design bugs.

I can't say that they are design bugs.

> I suggest using setDrawsDottedOutline: drawsDottedOutline in our
> implementation.  I suggest implementing setShowsFirstResponder: in the
> control.  And finally, to attempt some sort of portability, we

What you want to to is basically change the method name -setShowsFirstResponder
to -setDrawsDottedOutline: and this does not look reasonable to me.

> Well, the other thing is - some people don't want the dotted outline
> never.  We need to add a user default so it can be turned totally off.

This is the same thing I wanted to do when I switched from NS to OS
but on NS you can't change the responder with the tab apart for an NXForm
or similar things and you are forced to use the mouse.

The dotted line is necessary to follow the 'cursor' on a matrix (of switch
buttons) or to control the selection with shift/control keys. (todo)

---
Bye,
     Mirko  <address@hidden>   (NeXTmail, MIME)
                    <address@hidden>