On Wed, Dec 21, 2011 at 10:05, Banlu Kemiyatorn
<address@hidden> wrote:
What is this _reasonable_ compatible implementation you are talking about on this specific case, technically? The only point that was if not almost valid was that users may want to repeatly set colors for a cell during editing when the cell itself is not even visible, rather set it only once when text did end editing.
I sincerely hope my comments are not the primary cause for two contributors announcing they are dropping out.
Isn't this sort of thing easily correctable in a project with source code availability? If you are unhappy with this particular behavior, just change it. If you are unhappy with upstream implementation and you don't want to maintain your own fork, you can do subclassing, you can do method swizzling. You can do a lot without the upstream losing one of the coolest things about it: compatibility with a major platform.
I love the fact that I can mess with GNUstep's innards if I want to. I also love the fact that I can write tons of code for GNUstep and easily get it to run on another big platform, without worrying about details which may not be liked by developers.
I don't really like how NSTableView is used. I don't really like how NSOutlineView is used. However, I feel the solution is not in changing them, but in adding functionality to them, or adding GNUstep-specific additional classes which implement different ideas one may have about how table view's methods should be named, how they should be used and how they should work.
If one dislikes how NSTextField works, why not write a GNUstep-specific replacement instead of making the existing text field behave different, even if the original behavior seems less-than-ideal?
And yes, I do agree that the behavior we're discussing here has surprised me extremely, and not in a good way. It does make sense now that I understand why it occurs, but I still feel that the solution is in adding behavior, not in changing behavior.
--
Ivan Vučica -
address@hidden