gnustep-dev
[Top][All Lists]
Advanced

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

Re: Changes to NSControl


From: Fred Kiefer
Subject: Re: Changes to NSControl
Date: Wed, 08 Jan 2003 14:01:40 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020903

Nicola Pero wrote:
> I wrote a small text on Mac OS X, and found that on Mac OS X,
> -setString: and -replaceCharactersInRange:withString: work well no
> matter if the textview is not editable or not.
>
> I think this is a better behaviour, and that GNUstep is wrong. :-)
>
> If you want to fix that bug, I think this is the way. :-)

Great that you now have an MacOSX system running, this allows for those
quick checks. Maybe I should get one of them too?

And the solution that Next/Apple did choose looks better as well, but it
will require a big change in the code of NSTextView. The peoblem is that
all the methods that implement user interaction will have to check for
the return value of [shouldChangeTextInRange:replacementString:], wheras
the internal methods wont. And we will have to decide which ones are
internal!
I did a check in NSTextView, where this method gets called. And I would
suggest to treat all the action methods (ChangeFont: and the like)
should use it while for example setFont:range: wont use it.
This requires to remove the call from:
replaceCharacterRange:withString:
setFont:range:
setTextColor:range:
setalignment:range:
replaceRange:withAttributedString:
setAtrributes:range:

This is the easy part. The next step is to make sure that all the user
interface methods that did rely on those methods now call the check
methods themselves. This list is harder to find and some entries might
be disputable:

insertText:
transpose:
ChangeColor:
alignCenter:
alignLeft:
alignRight
alignJustified:
readSelectionFromPasteboard:type:

I am not that sure with the pasteboard method. The checks could also be
done in all the separate paste methods to allow for a programatical way
to paste, but I will implement it that way, as this is less task.
Nicola, could you please check the behaviour of this method on MacOSX?

>> Perhaps the same is also needed while setting up the field editor,
>> as some of this methods also check if the NSTextView is editable?
>
>
> See above, the behaviour we want is that the NSTextView prevents the
> user from editing it if it's not editable, but still allows the basic
>  -setText:, -setString:, -replaceCharactersInRange:withString: etc
> methods to be used programmatically.

Ok, this should be resolved then as well.

>> One of the strange things on NSControl I noticed is, that in the
>> method mouseDown: the action mask of the cell is changed before
>> calling the tracking code. Now this is the only place where the
>> action mask is used at all, so resetting it looks pointless to me.
>> I would like to just drop this code, that was probably a workaround
>> for a problem now long gone.
>
>
> Hmmm.
>
> The action mask of the cell is used whenever the method
> trackMouse:inRect:ofView:untilMouseUp: is called, which happens often
> in the gui.
>
> The code in NSControl.m currently sends the action periodically, if
> continuous, then if the mouse went up in the cell, highlights the
> cell, the sends the action again.
>
> I suspect the action mask is changed to get this result (sending the
> action after highlighting the cell, not before).
>
> I'm not sure what's best without further investigations. :-/
>
> Maybe the action mask of the cell should be checked, and if
> NSLeftMouseUpMask is set, that specific flag in the mask would be
> temporarily removed, and manually restored later, and the action
> would be manually sent after highlighting the cell.  Other flags in
> the mask would not be touched, and used as they are.  The action
> would not be sent when mouse up, unless the NSLeftMouseUpMask flag is
> set in the mask.
>
> Not sure.

Could you do that investigation? I have already set up my mind that the
code is not needed and this mind is hard to change.

>> The second oddity is the way NSControl implements the field editor
>>  methods. They are basically empty, although the documentation
>> describes them in detail. Instead we have them implemented on the
>> subclasses NSTextField, NSMatrix and NSTableView. I would suggest
>> to move those implementations up to NSControl. The drawback of this
>> is, that we also need the _text_object ivar in NSControl, which
>> will never be used by some of the subclasses, but this is a minor
>> price we have to pay.
>
>
> Ahm - I suppose you can use [self currentEditor] in NSControl to get
> the current editor without knowing where it's stored in the subclass.

Yes, but the problem is with abortEditing which must unset this ivar, that is why we will have to move the ivar up to NSControl. The methodes I want to move are currentEditor, abortEditing and validateEditing. Perhaps there are a few more methods where we could offer some basic implementation in NSControl that would than be called from all the subclasses, but currently the text view delegate methods look very different.

> I'm happy with you factoring code in the editing methods ... but
> please be very careful when touching those damned editing methods.
> They are very delicate and fragile -- just moving a single apparently
> innocent command around usually breaks the whole thing. :-)
>
> Probably we will factor out safely and clearly only part (or a few)
> of the editing methods.  If done very carefully and prudently, that
> would be quite nice!

Ok, I will do that after the current change and I will be very carefull (not sure about the prudence). This surely wont be the end of all this editing questions, even now I already have two more: - Shouldn't the selection be adopted each time we call one of the text changing methods, so that the selection is still a valid range? - Even after my (now obsolete) change to NSCell the selection of a non editable text field did not work correctly. What happend was that the first mouse click make the text field first responder, causing it to select the text and thereby starting the editor and than NSWindow did forward the mouse click to the text field and thereby to the editor, which did result in the setting of the selection to a single point. My idea was than to redefine acceptsFirstMouse: to only return YES if the text field is editable. But this value gets ignored by NSWindow if the window is already key, which somehow was always the case for me. Another fact that I don't understand. Could anybody shed some light into this problem?

Cheers
Fred






reply via email to

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