gnustep-dev
[Top][All Lists]
Advanced

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

Re: [Gnustep-cvs] r29106 - in /libs/gui/trunk: ChangeLog Source/NSColorW


From: Quentin Mathé
Subject: Re: [Gnustep-cvs] r29106 - in /libs/gui/trunk: ChangeLog Source/NSColorWell.m
Date: Fri, 11 Dec 2009 00:53:22 +0100

Hi Eric, Fred,

Le 10 déc. 2009 à 10:26, Eric Wasylishen a écrit :

Here's the new diff.

The one thing I'm not sure about is the best way to communicate to the
GSThemeDrawing method how the color well should be drawn. Potentially
a theme could want to draw the "currently-being-pressed" and "active
color well" states differently. Right now I use isHighlighted /
setHighlighted: on the NSColorWell's NSCell, but I don't think that's
right.

Why not simply turn the mouse down point variable into an ivar?
It looks like the code would be more readable by splitting it accross - mouseDown, -mouseDragged and -mouseUp:. This way AppKit handles the dispatch by itself rather than faking it with the switch which looks more 'noisy' (braces, nesting, the default case and the - nextEventMatchingMask: call). I only took a quick look at the code, so may be it isn't that easy.

On Wed, Dec 9, 2009 at 4:35 PM, Eric Wasylishen <address@hidden> wrote:
Hi Fred,

On 2009-12-09, at 3:24 PM, Fred Kiefer wrote:

Hans Baier schrieb:
Author: hansfbaier
Date: Tue Dec  8 08:55:39 2009
New Revision: 29106

URL: http://svn.gna.org/viewcvs/gnustep?rev=29106&view=rev
Log:
* Source/NSColorWell.m (-mouseDragged:, -mouseDown:): Applied patch from Eric Wasylishen to activate it on click inside the colored rectangle (same behavior as in OS X)

Modified:
   libs/gui/trunk/ChangeLog
   libs/gui/trunk/Source/NSColorWell.m

I like this patch in general, what I dislike is the global variable that
gets used for the last mouse down position. Looking at the code I am
very sure that this wont lead to any side effects, still it is the wrong
way to code this. I would prefer that we come up with a better
implementation for this feature.

I have observed that in various places we use global variables for dragging state, why not use ivars everywhere? Even if we have twenty table views in an application, I doubt it is going to make any difference in term of memory usage.

Although it's probably a minor point when you consider all the necessary changes… To store this state in ivars make possible to support multiple drag and drop sessions at the same time (e.g. with a multi-pointer desktop environment). For example, it would be impossible with the current code to have one pointer doing drop validation in a table view, and another pointer doing the same in a second table view, since both shares the same dragging state with static variables.

Cheers,
Quentin.







reply via email to

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