<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
	<id>tag:old.nabble.com,2006:forum-1882</id>
	<title>Nabble - GNUstep - Dev</title>
	<updated>2009-12-14T06:05:08Z</updated>
	<link rel="self" type="application/atom+xml" href="http://old.nabble.com/GNUstep---Dev-f1882.xml" />
	<link rel="alternate" type="text/html" href="http://old.nabble.com/GNUstep---Dev-f1882.html" />
	<subtitle type="html"></subtitle>
	
<entry>
	<id>tag:old.nabble.com,2006:post-26778565</id>
	<title>Re: [PATCH] NSBitmapImageRep colorAtX:y: flipped coordinates</title>
	<published>2009-12-14T06:05:08Z</published>
	<updated>2009-12-14T06:05:08Z</updated>
	<author>
		<name>Fred Kiefer</name>
	</author>
	<content type="html">Eric Wasylishen schrieb:
&lt;br&gt;&amp;gt; Hey,
&lt;br&gt;&amp;gt; On OS X, the methods in NSBitmapImageRep for accessing and setting
&lt;br&gt;&amp;gt; pixels use &amp;quot;flipped&amp;quot; coordinates - i.e. [colorAtX:0 y:0] is the
&lt;br&gt;&amp;gt; top-left pixel, whereas on GNUstep that returns the bottom-left pixel.
&lt;br&gt;&amp;gt; This patch corrects GNUstep to match OS X, and changes the only place
&lt;br&gt;&amp;gt; where these methods are used.
&lt;br&gt;&amp;gt; -Eric
&lt;br&gt;&lt;br&gt;Thank you!
&lt;br&gt;&lt;br&gt;I commited this and the other patches you sent.
&lt;br&gt;Fred
&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26778565&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-PATCH--NSBitmapImageRep-colorAtX%3Ay%3A-flipped-coordinates-tp26762506p26778565.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26762506</id>
	<title>[PATCH] NSBitmapImageRep colorAtX:y: flipped coordinates</title>
	<published>2009-12-12T16:33:53Z</published>
	<updated>2009-12-12T16:33:53Z</updated>
	<author>
		<name>Eric Wasylishen-2</name>
	</author>
	<content type="html">Hey,
&lt;br&gt;On OS X, the methods in NSBitmapImageRep for accessing and setting
&lt;br&gt;pixels use &amp;quot;flipped&amp;quot; coordinates - i.e. [colorAtX:0 y:0] is the
&lt;br&gt;top-left pixel, whereas on GNUstep that returns the bottom-left pixel.
&lt;br&gt;This patch corrects GNUstep to match OS X, and changes the only place
&lt;br&gt;where these methods are used.
&lt;br&gt;-Eric
&lt;br&gt;&lt;br /&gt;&lt;tt&gt;[BitmapCoordinates.patch]&lt;/tt&gt;&lt;br /&gt;&lt;hr align=&quot;left&quot; width=&quot;300&quot; /&gt;&lt;tt&gt;Index: Source/NSBitmapImageRep.m
&lt;br&gt;===================================================================
&lt;br&gt;--- Source/NSBitmapImageRep.m	(revision 29117)
&lt;br&gt;+++ Source/NSBitmapImageRep.m	(working copy)
&lt;br&gt;@@ -756,6 +756,10 @@
&lt;br&gt;&amp;nbsp; &amp;nbsp;return value &amp; ((1&amp;lt;&amp;lt;bit_width)-1);
&lt;br&gt;&amp;nbsp;}
&lt;br&gt;&amp;nbsp;
&lt;br&gt;+/**
&lt;br&gt;+ * Returns the values of the components of pixel (x,y), where (0,0) is the 
&lt;br&gt;+ * top-left pixel in the image, by storing them in the array pixelData.
&lt;br&gt;+ */
&lt;br&gt;&amp;nbsp;- (void) getPixel: (unsigned int[])pixelData atX: (int)x y: (int)y
&lt;br&gt;&amp;nbsp;{
&lt;br&gt;&amp;nbsp; &amp;nbsp;int i;
&lt;br&gt;@@ -768,9 +772,7 @@
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;return;
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp;}
&lt;br&gt;&amp;nbsp;
&lt;br&gt;- &amp;nbsp;// FIXME: The y value is taken from the bottom of the image. 
&lt;br&gt;- &amp;nbsp;// Not sure if this is correct.
&lt;br&gt;- &amp;nbsp;line_offset = _bytesPerRow * (_pixelsHigh - 1 - y);
&lt;br&gt;+ &amp;nbsp;line_offset = _bytesPerRow * y;
&lt;br&gt;&amp;nbsp; &amp;nbsp;if (_isPlanar)
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp;{
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;if (_bitsPerSample == 8)
&lt;br&gt;@@ -847,6 +849,10 @@
&lt;br&gt;&amp;nbsp; &amp;nbsp;base[byte2] = (value &amp; 255) | (base[byte2] ^ (all &amp; 255));
&lt;br&gt;&amp;nbsp;}
&lt;br&gt;&amp;nbsp;
&lt;br&gt;+/**
&lt;br&gt;+ * Sets the components of pixel (x,y), where (0,0) is the top-left pixel in
&lt;br&gt;+ * the image, to the given array of pixel components. 
&lt;br&gt;+ */
&lt;br&gt;&amp;nbsp;- (void) setPixel: (unsigned int[])pixelData atX: (int)x y: (int)y
&lt;br&gt;&amp;nbsp;{
&lt;br&gt;&amp;nbsp; &amp;nbsp;int i;
&lt;br&gt;@@ -865,9 +871,7 @@
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;[self bitmapData];
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp;}
&lt;br&gt;&amp;nbsp;
&lt;br&gt;- &amp;nbsp;// FIXME: The y value is taken from the bottom of the image. 
&lt;br&gt;- &amp;nbsp;// Not sure if this is correct.
&lt;br&gt;- &amp;nbsp;line_offset = _bytesPerRow * (_pixelsHigh - 1 - y);
&lt;br&gt;+ &amp;nbsp;line_offset = _bytesPerRow * y;
&lt;br&gt;&amp;nbsp; &amp;nbsp;if(_isPlanar)
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp;{
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;if (_bitsPerSample == 8)
&lt;br&gt;@@ -911,6 +915,10 @@
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp;}
&lt;br&gt;&amp;nbsp;}
&lt;br&gt;&amp;nbsp;
&lt;br&gt;+/**
&lt;br&gt;+ * Returns an NSColor object representing the color of the pixel (x,y), where
&lt;br&gt;+ * (0,0) is the top-left pixel in the image.
&lt;br&gt;+ */
&lt;br&gt;&amp;nbsp;- (NSColor*) colorAtX: (int)x y: (int)y
&lt;br&gt;&amp;nbsp;{
&lt;br&gt;&amp;nbsp;	unsigned int pixelData[5];
&lt;br&gt;@@ -1159,6 +1167,10 @@
&lt;br&gt;&amp;nbsp;	return nil;
&lt;br&gt;&amp;nbsp;}
&lt;br&gt;&amp;nbsp;
&lt;br&gt;+/**
&lt;br&gt;+ * Sets the color of pixel (x,y), where (0,0) is the top-left pixel in the
&lt;br&gt;+ * image.
&lt;br&gt;+ */
&lt;br&gt;&amp;nbsp;- (void) setColor: (NSColor*)color atX: (int)x y: (int)y
&lt;br&gt;&amp;nbsp;{
&lt;br&gt;&amp;nbsp;	unsigned int pixelData[5];
&lt;br&gt;Index: Source/GSThemeTools.m
&lt;br&gt;===================================================================
&lt;br&gt;--- Source/GSThemeTools.m	(revision 29117)
&lt;br&gt;+++ Source/GSThemeTools.m	(working copy)
&lt;br&gt;@@ -791,7 +791,7 @@
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp; &amp;nbsp;for (i = 0; i &amp;lt; s.width; i++)
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp;{
&lt;br&gt;- &amp;nbsp; &amp;nbsp; &amp;nbsp;NSColor	*pixelColor = [rep colorAtX: i y: s.height - 1];
&lt;br&gt;+ &amp;nbsp; &amp;nbsp; &amp;nbsp;NSColor	*pixelColor = [rep colorAtX: i y: 0];
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;[pixelColor getRed: &amp;r green: &amp;g blue: &amp;b alpha: &amp;a];
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;if (a &amp;gt; 0 &amp;&amp; x1 == -1)
&lt;br&gt;Index: ChangeLog
&lt;br&gt;===================================================================
&lt;br&gt;--- ChangeLog	(revision 29117)
&lt;br&gt;+++ ChangeLog	(working copy)
&lt;br&gt;@@ -1,3 +1,11 @@
&lt;br&gt;+2009-12-12 Eric Wasylishen &amp;lt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26762506&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;ewasylishen@...&lt;/a&gt;&amp;gt;
&lt;br&gt;+
&lt;br&gt;+	* Source/NSBitmapImageRep.m:
&lt;br&gt;+	* Source/GSThemeTools.m: 
&lt;br&gt;+	Change the colorAtX:y: and related methods in NSBitmapImageRep
&lt;br&gt;+	to use flipped coordinates, matching OS X. colorAtX:0 y:0 now 
&lt;br&gt;+	returns the top-left pixel instead of the bottom left.
&lt;br&gt;+
&lt;br&gt;&amp;nbsp;2009-12-12 Fred Kiefer &amp;lt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26762506&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;FredKiefer@...&lt;/a&gt;&amp;gt;
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp;	* Source/NSApplication (-setWindowsMenu:): Only add windows that 
&lt;br&gt;&lt;/tt&gt;&lt;hr align=&quot;left&quot; width=&quot;300&quot; /&gt;&lt;br /&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26762506&amp;i=2&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-PATCH--NSBitmapImageRep-colorAtX%3Ay%3A-flipped-coordinates-tp26762506p26762506.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26753760</id>
	<title>[PATCH] Tile-drawing fixes</title>
	<published>2009-12-11T16:45:45Z</published>
	<updated>2009-12-11T16:45:45Z</updated>
	<author>
		<name>Eric Wasylishen-2</name>
	</author>
	<content type="html">Hi,
&lt;br&gt;I'm working on converting the Étoilé Camaelon themes to GNUstep themes, and found some bugs in the tile drawing code in the process.
&lt;br&gt;&lt;br&gt;The first patch fixes some rect calculations in GSThemeTools.m: initWithNinePatchImage: and scaleFillRect:. The second patch, for back, turns on the CAIRO_EXTEND_PAD option for the Cairo pattern used to draw images. Without this, the edges of image become soft when scaled up, so you end up seeing 'seams' between tiles.
&lt;br&gt;&lt;br&gt;Here's a screenshot of a test tile I made applied to NSButton, with my patches: &lt;a href=&quot;http://stashbox.org/732039/gnustep-tiles-fixed.png&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://stashbox.org/732039/gnustep-tiles-fixed.png&lt;/a&gt;&lt;br&gt;The art and xlib backends also produce correct output.
&lt;br&gt;&lt;br&gt;Regards,
&lt;br&gt;Eric
&lt;br&gt;&lt;br&gt;&lt;br /&gt; &lt;br /&gt;&lt;br&gt;&lt;br /&gt; &lt;br /&gt;&lt;br&gt;&lt;br&gt;&lt;br /&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26753760&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;&lt;div class=&quot;small&quot;&gt;&lt;br/&gt;&lt;img src=&quot;http://old.nabble.com/images/icon_attachment.gif&quot; &gt; &lt;strong&gt;GSThemeTools.patch&lt;/strong&gt; (3K) &lt;a href=&quot;http://old.nabble.com/attachment/26753760/0/GSThemeTools.patch&quot; target=&quot;_top&quot;&gt;Download Attachment&lt;/a&gt;&lt;br/&gt;&lt;img src=&quot;http://old.nabble.com/images/icon_attachment.gif&quot; &gt; &lt;strong&gt;CairoImageScaling.patch&lt;/strong&gt; (1K) &lt;a href=&quot;http://old.nabble.com/attachment/26753760/1/CairoImageScaling.patch&quot; target=&quot;_top&quot;&gt;Download Attachment&lt;/a&gt;&lt;/div&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-PATCH--Tile-drawing-fixes-tp26753760p26753760.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26746596</id>
	<title>Re: [Gnustep-cvs] r29106 - in /libs/gui/trunk: ChangeLog Source/NSColorWell.m</title>
	<published>2009-12-11T07:24:19Z</published>
	<updated>2009-12-11T07:24:19Z</updated>
	<author>
		<name>Richard Frith-Macdonald-2</name>
	</author>
	<content type="html">&lt;br&gt;On 10 Dec 2009, at 09:26, Eric Wasylishen wrote:
&lt;br&gt;&lt;br&gt;&amp;gt; Here's the new diff.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; The one thing I'm not sure about is the best way to communicate to the
&lt;br&gt;&amp;gt; GSThemeDrawing method how the color well should be drawn. Potentially
&lt;br&gt;&amp;gt; a theme could want to draw the &amp;quot;currently-being-pressed&amp;quot; and &amp;quot;active
&lt;br&gt;&amp;gt; color well&amp;quot; states differently. Right now I use isHighlighted /
&lt;br&gt;&amp;gt; setHighlighted: on the NSColorWell's NSCell, but I don't think that's
&lt;br&gt;&amp;gt; right.
&lt;br&gt;&lt;br&gt;The GSTheme code defines normal, highlighted, and selected states for controls generally, so it sounds like what you are doing is reasonable ...
&lt;br&gt;a 'currently being pressed' colorwell might be 'highlighted', and an active colorwell might be 'selected'.
&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26746596&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Re%3A--Gnustep-cvs--r29106---in--libs-gui-trunk%3A-ChangeLog%09Source-NSColorWell.m-tp26718865p26746596.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26736595</id>
	<title>Re: [Gnustep-cvs] r29106 - in /libs/gui/trunk: ChangeLog Source/NSColorWell.m</title>
	<published>2009-12-10T15:53:22Z</published>
	<updated>2009-12-10T15:53:22Z</updated>
	<author>
		<name>Quentin Mathé-2</name>
	</author>
	<content type="html">Hi Eric, Fred,
&lt;br&gt;&lt;br&gt;Le 10 déc. 2009 à 10:26, Eric Wasylishen a écrit :
&lt;br&gt;&lt;br&gt;&amp;gt; Here's the new diff.
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; The one thing I'm not sure about is the best way to communicate to the
&lt;br&gt;&amp;gt; GSThemeDrawing method how the color well should be drawn. Potentially
&lt;br&gt;&amp;gt; a theme could want to draw the &amp;quot;currently-being-pressed&amp;quot; and &amp;quot;active
&lt;br&gt;&amp;gt; color well&amp;quot; states differently. Right now I use isHighlighted /
&lt;br&gt;&amp;gt; setHighlighted: on the NSColorWell's NSCell, but I don't think that's
&lt;br&gt;&amp;gt; right.
&lt;br&gt;&lt;br&gt;Why not simply turn the mouse down point variable into an ivar?
&lt;br&gt;It looks like the code would be more readable by splitting it accross - 
&lt;br&gt;mouseDown, -mouseDragged and -mouseUp:. This way AppKit handles the &amp;nbsp;
&lt;br&gt;dispatch by itself rather than faking it with the switch which looks &amp;nbsp;
&lt;br&gt;more 'noisy' (braces, nesting, the default case and the - 
&lt;br&gt;nextEventMatchingMask: call). I only took &amp;nbsp;a quick look at the code, &amp;nbsp;
&lt;br&gt;so may be it isn't that easy.
&lt;br&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; On Wed, Dec 9, 2009 at 4:35 PM, Eric Wasylishen &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;lt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26736595&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;ewasylishen@...&lt;/a&gt;&amp;gt; wrote:
&lt;br&gt;&amp;gt;&amp;gt; Hi Fred,
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; On 2009-12-09, at 3:24 PM, Fred Kiefer wrote:
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; Hans Baier schrieb:
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; Author: hansfbaier
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; Date: Tue Dec &amp;nbsp;8 08:55:39 2009
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; New Revision: 29106
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; URL: &lt;a href=&quot;http://svn.gna.org/viewcvs/gnustep?rev=29106&amp;view=rev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://svn.gna.org/viewcvs/gnustep?rev=29106&amp;view=rev&lt;/a&gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; Log:
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; * Source/NSColorWell.m (-mouseDragged:, -mouseDown:): Applied &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; patch from Eric Wasylishen to activate it on click inside the &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; colored rectangle (same behavior as in OS X)
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; Modified:
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; &amp;nbsp; &amp;nbsp;libs/gui/trunk/ChangeLog
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; &amp;nbsp; &amp;nbsp;libs/gui/trunk/Source/NSColorWell.m
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; I like this patch in general, what I dislike is the global &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; variable that
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; gets used for the last mouse down position. Looking at the code I am
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; very sure that this wont lead to any side effects, still it is the &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; wrong
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; way to code this. I would prefer that we come up with a better
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; implementation for this feature.
&lt;/div&gt;&lt;br&gt;I have observed that in various places we use global variables for &amp;nbsp;
&lt;br&gt;dragging state, why not use ivars everywhere? Even if we have &amp;nbsp;twenty &amp;nbsp;
&lt;br&gt;table views in an application, I doubt it is going to make any &amp;nbsp;
&lt;br&gt;difference in term of memory usage.
&lt;br&gt;&lt;br&gt;Although it's probably a minor point when you consider all the &amp;nbsp;
&lt;br&gt;necessary changes… To store this state in ivars make possible to &amp;nbsp;
&lt;br&gt;support multiple drag and drop sessions at the same time (e.g. with a &amp;nbsp;
&lt;br&gt;multi-pointer desktop environment). For example, it would be &amp;nbsp;
&lt;br&gt;impossible with the current code to have one pointer doing drop &amp;nbsp;
&lt;br&gt;validation in a table view, and another pointer doing the same in a &amp;nbsp;
&lt;br&gt;second table view, since both shares the same dragging state with &amp;nbsp;
&lt;br&gt;static variables.
&lt;br&gt;&lt;br&gt;Cheers,
&lt;br&gt;Quentin.
&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26736595&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Re%3A--Gnustep-cvs--r29106---in--libs-gui-trunk%3A-ChangeLog%09Source-NSColorWell.m-tp26718865p26736595.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26734358</id>
	<title>Re: NSTableColumn Archiving</title>
	<published>2009-12-10T12:54:58Z</published>
	<updated>2009-12-10T12:54:58Z</updated>
	<author>
		<name>Gregory Casamento</name>
	</author>
	<content type="html">Just bump the version, if you change the archiving code. &amp;nbsp;It should be fine.
&lt;br&gt;&lt;br&gt;On Wed, Dec 9, 2009 at 5:44 PM, Fred Kiefer &amp;lt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26734358&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;fredkiefer@...&lt;/a&gt;&amp;gt; wrote:
&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; Quentin Mathé schrieb:
&lt;br&gt;&amp;gt;&amp;gt; As explained in my previous mail, I updated NSTableColumn with the
&lt;br&gt;&amp;gt;&amp;gt; latest Mac OS X additions.
&lt;br&gt;&amp;gt;&amp;gt; However I'm unsure how to precisely update the archiving code and I
&lt;br&gt;&amp;gt;&amp;gt; don't want to break Gorm… Apple has the following keys in the xib
&lt;br&gt;&amp;gt;&amp;gt; format: NSResizingMask (int), NSHeaderToolTip (string), NSHidden (BOOL),
&lt;br&gt;&amp;gt;&amp;gt; NSSortDescriptorPrototype (object).
&lt;br&gt;&amp;gt;&amp;gt; Can somebody update the archiving the code or tell me what should I do
&lt;br&gt;&amp;gt;&amp;gt; in details?
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; I have a look into this, as soon as I have a bit more time at hand. In
&lt;br&gt;&amp;gt; general you don't have to worry much about backwards compatibility with
&lt;br&gt;&amp;gt; keyed encoding. This is one of the god things about this format.
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; Fred
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; _______________________________________________
&lt;br&gt;&amp;gt; Gnustep-dev mailing list
&lt;br&gt;&amp;gt; &lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26734358&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&amp;gt; &lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;&amp;gt;
&lt;/div&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;-- 
&lt;br&gt;Gregory Casamento
&lt;br&gt;Open Logic Corporation, Principal Consultant
&lt;br&gt;## GNUstep Chief Maintainer
&lt;br&gt;yahoo/skype: greg_casamento, aol: gjcasa
&lt;br&gt;(240)274-9630 (Cell), (301)362-9640 (Home)
&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26734358&amp;i=2&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/NSTableColumn-Archiving-tp26698682p26734358.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26724234</id>
	<title>Re: [Gnustep-cvs] r29106 - in /libs/gui/trunk: ChangeLog  Source/NSColorWell.m</title>
	<published>2009-12-10T01:26:18Z</published>
	<updated>2009-12-10T01:26:18Z</updated>
	<author>
		<name>Eric Wasylishen-2</name>
	</author>
	<content type="html">Here's the new diff.
&lt;br&gt;&lt;br&gt;The one thing I'm not sure about is the best way to communicate to the
&lt;br&gt;GSThemeDrawing method how the color well should be drawn. Potentially
&lt;br&gt;a theme could want to draw the &amp;quot;currently-being-pressed&amp;quot; and &amp;quot;active
&lt;br&gt;color well&amp;quot; states differently. Right now I use isHighlighted /
&lt;br&gt;setHighlighted: on the NSColorWell's NSCell, but I don't think that's
&lt;br&gt;right.
&lt;br&gt;&lt;br&gt;-Eric
&lt;br&gt;&lt;br&gt;On Wed, Dec 9, 2009 at 4:35 PM, Eric Wasylishen &amp;lt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26724234&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;ewasylishen@...&lt;/a&gt;&amp;gt; wrote:
&lt;div class='shrinkable-quote'&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; Hi Fred,
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; On 2009-12-09, at 3:24 PM, Fred Kiefer wrote:
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; Hans Baier schrieb:
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; Author: hansfbaier
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; Date: Tue Dec  8 08:55:39 2009
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; New Revision: 29106
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; URL: &lt;a href=&quot;http://svn.gna.org/viewcvs/gnustep?rev=29106&amp;view=rev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://svn.gna.org/viewcvs/gnustep?rev=29106&amp;view=rev&lt;/a&gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; Log:
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; * 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)
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; Modified:
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;    libs/gui/trunk/ChangeLog
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;    libs/gui/trunk/Source/NSColorWell.m
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; I like this patch in general, what I dislike is the global variable that
&lt;br&gt;&amp;gt;&amp;gt; gets used for the last mouse down position. Looking at the code I am
&lt;br&gt;&amp;gt;&amp;gt; very sure that this wont lead to any side effects, still it is the wrong
&lt;br&gt;&amp;gt;&amp;gt; way to code this. I would prefer that we come up with a better
&lt;br&gt;&amp;gt;&amp;gt; implementation for this feature.
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; I agree, the global variable is ugly. I did some more investigation
&lt;br&gt;&amp;gt; yesterday, and decided it would be best to use a mouse-tracking loop
&lt;br&gt;&amp;gt; in mouseDown and eliminate the global variable. OS X appears to
&lt;br&gt;&amp;gt; do this as well.
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; I'm working on a new patch which fixes a bunch of little interaction
&lt;br&gt;&amp;gt; details related to NSColorWell and NSColorPanel:
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt;  - activation of the well should really happen on mouseUp, not mouseDown
&lt;br&gt;&amp;gt;  - non-bordered NSColorWells shouldn't be able to be activated by clicking
&lt;br&gt;&amp;gt;  - non-bordered NSColorWells should start a drag operation upon mouseDown
&lt;br&gt;&amp;gt;  - disabled NSColorWells shouldn't accept colours being dropped on them
&lt;br&gt;&amp;gt;  - dropping a colour on the well inside the NSColorPanel should
&lt;br&gt;&amp;gt;   also update the active NSColorWell
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; I just want to do a bit more testing, and I'll post the patch later tonight :-)
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; Regards,
&lt;br&gt;&amp;gt; Eric
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt;
&lt;/div&gt;&lt;/div&gt;&lt;br /&gt;&lt;tt&gt;[ColorWell2.diff]&lt;/tt&gt;&lt;br /&gt;&lt;hr align=&quot;left&quot; width=&quot;300&quot; /&gt;&lt;tt&gt;Index: Source/NSColorWell.m
&lt;br&gt;===================================================================
&lt;br&gt;--- Source/NSColorWell.m	(revision 29108)
&lt;br&gt;+++ Source/NSColorWell.m	(working copy)
&lt;br&gt;@@ -46,8 +46,6 @@
&lt;br&gt;&amp;nbsp;static NSString *GSColorWellDidBecomeExclusiveNotification =
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;@&amp;quot;GSColorWellDidBecomeExclusiveNotification&amp;quot;;
&lt;br&gt;&amp;nbsp;
&lt;br&gt;-static NSPoint _lastMouseDownPoint;
&lt;br&gt;-
&lt;br&gt;&amp;nbsp;@implementation NSColorWell
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp;/*
&lt;br&gt;@@ -102,6 +100,7 @@
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; object: nil];
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp; &amp;nbsp;_is_active = YES;
&lt;br&gt;+ &amp;nbsp;[[self cell] setHighlighted: YES];
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp; &amp;nbsp;[colorPanel setColor: _the_color];
&lt;br&gt;&amp;nbsp; &amp;nbsp;[colorPanel orderFront: self];
&lt;br&gt;@@ -124,6 +123,7 @@
&lt;br&gt;&amp;nbsp;- (void) deactivate
&lt;br&gt;&amp;nbsp;{
&lt;br&gt;&amp;nbsp; &amp;nbsp;_is_active = NO;
&lt;br&gt;+ &amp;nbsp;[[self cell] setHighlighted: NO];
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp; &amp;nbsp;[[NSNotificationCenter defaultCenter] removeObserver: self];
&lt;br&gt;&amp;nbsp;
&lt;br&gt;@@ -147,6 +147,10 @@
&lt;br&gt;&amp;nbsp; &amp;nbsp;NSDragOperation sourceDragMask;
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; 
&lt;br&gt;&amp;nbsp; &amp;nbsp;NSDebugLLog(@&amp;quot;NSColorWell&amp;quot;, @&amp;quot;%@: draggingEntered&amp;quot;, self);
&lt;br&gt;+
&lt;br&gt;+ &amp;nbsp;if ([self isEnabled] == NO)
&lt;br&gt;+ &amp;nbsp; &amp;nbsp;return NSDragOperationNone;
&lt;br&gt;+ 
&lt;br&gt;&amp;nbsp; &amp;nbsp;sourceDragMask = [sender draggingSourceOperationMask];
&lt;br&gt;&amp;nbsp; &amp;nbsp;pb = [sender draggingPasteboard];
&lt;br&gt;&amp;nbsp; 
&lt;br&gt;@@ -285,39 +289,89 @@
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp;- (void) mouseDown: (NSEvent *)theEvent
&lt;br&gt;&amp;nbsp;{
&lt;br&gt;+ &amp;nbsp;BOOL done;
&lt;br&gt;+ &amp;nbsp;BOOL inside;
&lt;br&gt;+ &amp;nbsp;BOOL startedInWell;
&lt;br&gt;+ &amp;nbsp;NSPoint point;
&lt;br&gt;+
&lt;br&gt;&amp;nbsp; &amp;nbsp;//
&lt;br&gt;&amp;nbsp; &amp;nbsp;// OPENSTEP 4.2 and OSX behavior indicates that the colorwell doesn't
&lt;br&gt;&amp;nbsp; &amp;nbsp;// work when the widget is marked as disabled.
&lt;br&gt;&amp;nbsp; &amp;nbsp;//
&lt;br&gt;- &amp;nbsp;if ([self isEnabled])
&lt;br&gt;+ &amp;nbsp;if ([self isEnabled] == NO)
&lt;br&gt;+ &amp;nbsp; &amp;nbsp;return;
&lt;br&gt;+
&lt;br&gt;+ &amp;nbsp;//
&lt;br&gt;+ &amp;nbsp;// Unbordered color wells start a drag immediately upon mouse down
&lt;br&gt;+ &amp;nbsp;//
&lt;br&gt;+ &amp;nbsp;if ([self isBordered] == NO)
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp;{
&lt;br&gt;- &amp;nbsp; &amp;nbsp; &amp;nbsp;_lastMouseDownPoint = 
&lt;br&gt;- &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; [self convertPoint: [theEvent locationInWindow]
&lt;br&gt;- &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; fromView: nil];
&lt;br&gt;+ &amp;nbsp; &amp;nbsp; &amp;nbsp;[NSColorPanel dragColor: _the_color
&lt;br&gt;+		 &amp;nbsp; &amp;nbsp;withEvent: theEvent
&lt;br&gt;+		 &amp;nbsp; &amp;nbsp;fromView: self];
&lt;br&gt;+ &amp;nbsp; &amp;nbsp; &amp;nbsp;return;
&lt;br&gt;+ &amp;nbsp; &amp;nbsp;}
&lt;br&gt;&amp;nbsp;
&lt;br&gt;- &amp;nbsp; &amp;nbsp; &amp;nbsp;if (_is_active == NO)
&lt;br&gt;+ &amp;nbsp;point = [self convertPoint: [theEvent locationInWindow]
&lt;br&gt;+		 &amp;nbsp; &amp;nbsp;fromView: nil];
&lt;br&gt;+ &amp;nbsp;startedInWell = [self mouse: point inRect: _wellRect];
&lt;br&gt;+
&lt;br&gt;+ &amp;nbsp;[[self cell] setHighlighted: ![self isActive]];
&lt;br&gt;+ &amp;nbsp;[self setNeedsDisplay: YES];
&lt;br&gt;+
&lt;br&gt;+ &amp;nbsp;done = NO;
&lt;br&gt;+ &amp;nbsp;while (!done)
&lt;br&gt;+ &amp;nbsp; &amp;nbsp;{
&lt;br&gt;+ &amp;nbsp; &amp;nbsp; &amp;nbsp;theEvent = [[self window] nextEventMatchingMask: 
&lt;br&gt;+		NSLeftMouseUpMask | NSLeftMouseDraggedMask];
&lt;br&gt;+ &amp;nbsp; &amp;nbsp; &amp;nbsp;point = [self convertPoint: [theEvent locationInWindow]
&lt;br&gt;+		 &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;fromView: nil];
&lt;br&gt;+ &amp;nbsp; &amp;nbsp; &amp;nbsp;inside = [self mouse: point inRect: [self bounds]];
&lt;br&gt;+
&lt;br&gt;+ &amp;nbsp; &amp;nbsp; &amp;nbsp;switch ([theEvent type])
&lt;br&gt;&amp;nbsp;	{
&lt;br&gt;-	 &amp;nbsp;[self activate: YES];
&lt;br&gt;+	case NSLeftMouseDragged:
&lt;br&gt;+	 &amp;nbsp;if (startedInWell)
&lt;br&gt;+	 &amp;nbsp; &amp;nbsp;{
&lt;br&gt;+	 &amp;nbsp; &amp;nbsp; &amp;nbsp;[[self cell] setHighlighted: [self isActive]];
&lt;br&gt;+	 &amp;nbsp; &amp;nbsp; &amp;nbsp;[self setNeedsDisplay: YES];
&lt;br&gt;+
&lt;br&gt;+	 &amp;nbsp; &amp;nbsp; &amp;nbsp;[NSColorPanel dragColor: _the_color
&lt;br&gt;+			 &amp;nbsp; &amp;nbsp;withEvent: theEvent
&lt;br&gt;+			 &amp;nbsp; &amp;nbsp; fromView: self];
&lt;br&gt;+	 &amp;nbsp; &amp;nbsp; &amp;nbsp;done = YES;
&lt;br&gt;+	 &amp;nbsp; &amp;nbsp;} 
&lt;br&gt;+	 &amp;nbsp;else 
&lt;br&gt;+	 &amp;nbsp; &amp;nbsp;{
&lt;br&gt;+	 &amp;nbsp; &amp;nbsp; &amp;nbsp;[[self cell] setHighlighted: inside ^ [self isActive]];
&lt;br&gt;+	 &amp;nbsp; &amp;nbsp; &amp;nbsp;[self setNeedsDisplay: YES];
&lt;br&gt;+	 &amp;nbsp; &amp;nbsp;}
&lt;br&gt;+	 &amp;nbsp;break;
&lt;br&gt;+	case NSLeftMouseUp:
&lt;br&gt;+	 &amp;nbsp;if (inside)
&lt;br&gt;+	 &amp;nbsp; &amp;nbsp;{
&lt;br&gt;+	 &amp;nbsp; &amp;nbsp; &amp;nbsp;if (_is_active == NO)
&lt;br&gt;+		{
&lt;br&gt;+		 &amp;nbsp;[self activate: YES];
&lt;br&gt;+		}
&lt;br&gt;+	 &amp;nbsp; &amp;nbsp; &amp;nbsp;else
&lt;br&gt;+		{
&lt;br&gt;+		 &amp;nbsp;[self deactivate];
&lt;br&gt;+		}
&lt;br&gt;+	 &amp;nbsp; &amp;nbsp;} 
&lt;br&gt;+	 &amp;nbsp;else 
&lt;br&gt;+	 &amp;nbsp; &amp;nbsp;{
&lt;br&gt;+	 &amp;nbsp; &amp;nbsp; &amp;nbsp;[[self cell] setHighlighted: [self isActive]];
&lt;br&gt;+	 &amp;nbsp; &amp;nbsp; &amp;nbsp;[self setNeedsDisplay: YES];
&lt;br&gt;+	 &amp;nbsp; &amp;nbsp;}
&lt;br&gt;+	 &amp;nbsp;done = YES;
&lt;br&gt;+	 &amp;nbsp;break;
&lt;br&gt;+	default:
&lt;br&gt;+	 &amp;nbsp;break;
&lt;br&gt;&amp;nbsp;	}
&lt;br&gt;- &amp;nbsp; &amp;nbsp; &amp;nbsp;else
&lt;br&gt;-	{
&lt;br&gt;-	 &amp;nbsp;[self deactivate];
&lt;br&gt;-	}
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp;}
&lt;br&gt;&amp;nbsp;}
&lt;br&gt;&amp;nbsp;
&lt;br&gt;-- (void) mouseDragged: (NSEvent *)theEvent
&lt;br&gt;-{
&lt;br&gt;- &amp;nbsp;if ([self isEnabled])
&lt;br&gt;- &amp;nbsp; &amp;nbsp;{
&lt;br&gt;- &amp;nbsp; &amp;nbsp; &amp;nbsp;if ([self mouse: _lastMouseDownPoint inRect: _wellRect])
&lt;br&gt;- &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;{
&lt;br&gt;- &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;[NSColorPanel dragColor: _the_color
&lt;br&gt;-			withEvent: theEvent
&lt;br&gt;-			fromView: self];
&lt;br&gt;- &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;}
&lt;br&gt;- &amp;nbsp; &amp;nbsp;}
&lt;br&gt;-}
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp;- (BOOL) performDragOperation: (id &amp;lt;NSDraggingInfo&amp;gt;)sender
&lt;br&gt;&amp;nbsp;{
&lt;br&gt;Index: Source/GSThemeDrawing.m
&lt;br&gt;===================================================================
&lt;br&gt;--- Source/GSThemeDrawing.m	(revision 29108)
&lt;br&gt;+++ Source/GSThemeDrawing.m	(working copy)
&lt;br&gt;@@ -728,7 +728,7 @@
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;/*
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; * Fill in control color.
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; */
&lt;br&gt;- &amp;nbsp; &amp;nbsp; &amp;nbsp;if ([well isActive])
&lt;br&gt;+ &amp;nbsp; &amp;nbsp; &amp;nbsp;if ([[well cell] isHighlighted])
&lt;br&gt;&amp;nbsp;	{
&lt;br&gt;&amp;nbsp;	 &amp;nbsp;[[NSColor selectedControlColor] set];
&lt;br&gt;&amp;nbsp;	}
&lt;br&gt;Index: Source/NSColorPanel.m
&lt;br&gt;===================================================================
&lt;br&gt;--- Source/NSColorPanel.m	(revision 29108)
&lt;br&gt;+++ Source/NSColorPanel.m	(working copy)
&lt;br&gt;@@ -356,7 +356,7 @@
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp;- (void) _updatePicker: (id) sender
&lt;br&gt;&amp;nbsp;{
&lt;br&gt;- &amp;nbsp;[_currentPicker setColor: [_colorWell color]];
&lt;br&gt;+ &amp;nbsp;[self setColor: [_colorWell color]];
&lt;br&gt;&amp;nbsp;}
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp;- (void) _bottomWellAction: (id) sender
&lt;br&gt;&lt;/tt&gt;&lt;hr align=&quot;left&quot; width=&quot;300&quot; /&gt;&lt;br /&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26724234&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Re%3A--Gnustep-cvs--r29106---in--libs-gui-trunk%3A-ChangeLog%09Source-NSColorWell.m-tp26718865p26724234.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26719664</id>
	<title>Re: [Gnustep-cvs] r29106 - in /libs/gui/trunk: ChangeLog Source/NSColorWell.m</title>
	<published>2009-12-09T15:35:28Z</published>
	<updated>2009-12-09T15:35:28Z</updated>
	<author>
		<name>Eric Wasylishen-2</name>
	</author>
	<content type="html">Hi Fred,
&lt;br&gt;&lt;br&gt;On 2009-12-09, at 3:24 PM, Fred Kiefer wrote:
&lt;br&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; Hans Baier schrieb:
&lt;br&gt;&amp;gt;&amp;gt; Author: hansfbaier
&lt;br&gt;&amp;gt;&amp;gt; Date: Tue Dec &amp;nbsp;8 08:55:39 2009
&lt;br&gt;&amp;gt;&amp;gt; New Revision: 29106
&lt;br&gt;&amp;gt;&amp;gt; 
&lt;br&gt;&amp;gt;&amp;gt; URL: &lt;a href=&quot;http://svn.gna.org/viewcvs/gnustep?rev=29106&amp;view=rev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://svn.gna.org/viewcvs/gnustep?rev=29106&amp;view=rev&lt;/a&gt;&lt;br&gt;&amp;gt;&amp;gt; Log:
&lt;br&gt;&amp;gt;&amp;gt; * 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)
&lt;br&gt;&amp;gt;&amp;gt; 
&lt;br&gt;&amp;gt;&amp;gt; Modified:
&lt;br&gt;&amp;gt;&amp;gt; &amp;nbsp; &amp;nbsp;libs/gui/trunk/ChangeLog
&lt;br&gt;&amp;gt;&amp;gt; &amp;nbsp; &amp;nbsp;libs/gui/trunk/Source/NSColorWell.m
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; I like this patch in general, what I dislike is the global variable that
&lt;br&gt;&amp;gt; gets used for the last mouse down position. Looking at the code I am
&lt;br&gt;&amp;gt; very sure that this wont lead to any side effects, still it is the wrong
&lt;br&gt;&amp;gt; way to code this. I would prefer that we come up with a better
&lt;br&gt;&amp;gt; implementation for this feature.
&lt;br&gt;&amp;gt; 
&lt;/div&gt;&lt;br&gt;&lt;br&gt;I agree, the global variable is ugly. I did some more investigation
&lt;br&gt;yesterday, and decided it would be best to use a mouse-tracking loop
&lt;br&gt;in mouseDown and eliminate the global variable. OS X appears to 
&lt;br&gt;do this as well.
&lt;br&gt;&lt;br&gt;I'm working on a new patch which fixes a bunch of little interaction 
&lt;br&gt;details related to NSColorWell and NSColorPanel:
&lt;br&gt;&lt;br&gt;&amp;nbsp;- activation of the well should really happen on mouseUp, not mouseDown
&lt;br&gt;&amp;nbsp;- non-bordered NSColorWells shouldn't be able to be activated by clicking
&lt;br&gt;&amp;nbsp;- non-bordered NSColorWells should start a drag operation upon mouseDown
&lt;br&gt;&amp;nbsp;- disabled NSColorWells shouldn't accept colours being dropped on them
&lt;br&gt;&amp;nbsp;- dropping a colour on the well inside the NSColorPanel should
&lt;br&gt;&amp;nbsp; &amp;nbsp;also update the active NSColorWell
&lt;br&gt;&lt;br&gt;I just want to do a bit more testing, and I'll post the patch later tonight :-)
&lt;br&gt;&lt;br&gt;Regards,
&lt;br&gt;Eric
&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26719664&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Re%3A--Gnustep-cvs--r29106---in--libs-gui-trunk%3A-ChangeLog%09Source-NSColorWell.m-tp26718865p26719664.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26719103</id>
	<title>Re: NSTableColumn Archiving</title>
	<published>2009-12-09T14:44:01Z</published>
	<updated>2009-12-09T14:44:01Z</updated>
	<author>
		<name>Fred Kiefer</name>
	</author>
	<content type="html">Quentin Mathé schrieb:
&lt;br&gt;&amp;gt; As explained in my previous mail, I updated NSTableColumn with the
&lt;br&gt;&amp;gt; latest Mac OS X additions.
&lt;br&gt;&amp;gt; However I'm unsure how to precisely update the archiving code and I
&lt;br&gt;&amp;gt; don't want to break Gorm… Apple has the following keys in the xib
&lt;br&gt;&amp;gt; format: NSResizingMask (int), NSHeaderToolTip (string), NSHidden (BOOL),
&lt;br&gt;&amp;gt; NSSortDescriptorPrototype (object).
&lt;br&gt;&amp;gt; Can somebody update the archiving the code or tell me what should I do
&lt;br&gt;&amp;gt; in details?
&lt;br&gt;&lt;br&gt;I have a look into this, as soon as I have a bit more time at hand. In
&lt;br&gt;general you don't have to worry much about backwards compatibility with
&lt;br&gt;keyed encoding. This is one of the god things about this format.
&lt;br&gt;&lt;br&gt;Fred
&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26719103&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/NSTableColumn-Archiving-tp26698682p26719103.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26718865</id>
	<title>Re: [Gnustep-cvs] r29106 - in /libs/gui/trunk: ChangeLog	Source/NSColorWell.m</title>
	<published>2009-12-09T14:24:07Z</published>
	<updated>2009-12-09T14:24:07Z</updated>
	<author>
		<name>Fred Kiefer</name>
	</author>
	<content type="html">Hans Baier schrieb:
&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; Author: hansfbaier
&lt;br&gt;&amp;gt; Date: Tue Dec &amp;nbsp;8 08:55:39 2009
&lt;br&gt;&amp;gt; New Revision: 29106
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; URL: &lt;a href=&quot;http://svn.gna.org/viewcvs/gnustep?rev=29106&amp;view=rev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://svn.gna.org/viewcvs/gnustep?rev=29106&amp;view=rev&lt;/a&gt;&lt;br&gt;&amp;gt; Log:
&lt;br&gt;&amp;gt; * 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)
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; Modified:
&lt;br&gt;&amp;gt; &amp;nbsp; &amp;nbsp; libs/gui/trunk/ChangeLog
&lt;br&gt;&amp;gt; &amp;nbsp; &amp;nbsp; libs/gui/trunk/Source/NSColorWell.m
&lt;/div&gt;&lt;br&gt;I like this patch in general, what I dislike is the global variable that
&lt;br&gt;gets used for the last mouse down position. Looking at the code I am
&lt;br&gt;very sure that this wont lead to any side effects, still it is the wrong
&lt;br&gt;way to code this. I would prefer that we come up with a better
&lt;br&gt;implementation for this feature.
&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26718865&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Re%3A--Gnustep-cvs--r29106---in--libs-gui-trunk%3A-ChangeLog%09Source-NSColorWell.m-tp26718865p26718865.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26698968</id>
	<title>Re: ABI / ivars policy</title>
	<published>2009-12-08T10:16:41Z</published>
	<updated>2009-12-08T10:16:41Z</updated>
	<author>
		<name>David Chisnall</name>
	</author>
	<content type="html">On 8 Dec 2009, at 17:33, Quentin Mathé wrote:
&lt;br&gt;&lt;br&gt;&amp;gt; Is there now an official policy that explains how we handle ivar &amp;nbsp;
&lt;br&gt;&amp;gt; addition/removal? Is it still ok to put them in the header?
&lt;br&gt;&lt;br&gt;If we're going to recommend the new runtime for the next release, then &amp;nbsp;
&lt;br&gt;it is not such a problem. &amp;nbsp;Code compiled with -fobjc-nonfragile-abi &amp;nbsp;
&lt;br&gt;will not notice when ivars are added. &amp;nbsp;Code compiled without will &amp;nbsp;
&lt;br&gt;abort at load time if it contains a class that subclasses the class &amp;nbsp;
&lt;br&gt;that you've added an ivar to or removed one from (unless you've both &amp;nbsp;
&lt;br&gt;added and removed ivars and the class size remains constant but the &amp;nbsp;
&lt;br&gt;layout changes, then subclasses which access public / protected ivars &amp;nbsp;
&lt;br&gt;may have problems).
&lt;br&gt;&lt;br&gt;Either way, make sure that you note ABI changes in NEWS :-)
&lt;br&gt;&lt;br&gt;David
&lt;br&gt;&lt;br&gt;-- Sent from my Difference Engine
&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26698968&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/ABI---ivars-policy-tp26697857p26698968.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26698926</id>
	<title>Re: [Gnustep-cvs] r29082 - in /libs/gui/trunk: ChangeLog  Headers/AppKit/NSOutlineView.h Source/NSOutlineView.m</title>
	<published>2009-12-08T10:08:36Z</published>
	<updated>2009-12-08T10:08:36Z</updated>
	<author>
		<name>Quentin Mathé-2</name>
	</author>
	<content type="html">On Fri, Dec 4, 2009 at 4:49 PM, Quentin Mathé &lt;span dir=&quot;ltr&quot;&gt;&amp;lt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26698926&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;qmathe@...&lt;/a&gt;&amp;gt;&lt;/span&gt; wrote:&lt;div&gt;&lt;br&gt;&lt;div class=&quot;gmail_quote&quot;&gt;&lt;blockquote class=&quot;gmail_quote&quot; style=&quot;margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;&quot;&gt;
Le 30 nov. 2009 à 20:52, Richard Frith-Macdonald a écrit :&lt;br&gt;
&lt;br&gt;
I have been working on simplifying/documenting the new code a bit more and correcting some small issues, I&amp;#39;ll commit my changes soon.&lt;/blockquote&gt;&lt;div&gt;&lt;br&gt;&lt;/div&gt;&lt;div&gt;My changes are committed. Drag and drop works very well in my tests now. I also updated GSTest outline view bundle to make possible to test some border cases (empty parent and horizontal insertion level with more than two choices).&lt;/div&gt;
&lt;div&gt;The flickering with the green square cursor and the arrow cursor is the main visual issue that remains. iirc the problem exists with every drag and drop session.&lt;/div&gt;&lt;div&gt;&lt;br&gt;&lt;/div&gt;&lt;div&gt;We could probably increase the code sharing with NSTableView. For example the drawing code. I think it would be nice to have the drop indicator themable. Drop on and drop above cases are probably enough. I doubt it is useful to support theming the &amp;#39;drop on root&amp;#39; case in a distinct manner.&lt;/div&gt;
&lt;div&gt;&lt;br&gt;&lt;/div&gt;&lt;div&gt;Quentin.&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;
&lt;br /&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26698926&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Re%3A--Gnustep-cvs--r29082---in--libs-gui-trunk%3A-ChangeLog-Headers-AppKit-NSOutlineView.h-Source-NSOutlineView.m-tp26567782p26698926.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26698682</id>
	<title>NSTableColumn Archiving</title>
	<published>2009-12-08T09:46:25Z</published>
	<updated>2009-12-08T09:46:25Z</updated>
	<author>
		<name>Quentin Mathé-2</name>
	</author>
	<content type="html">Hi,
&lt;br&gt;&lt;br&gt;As explained in my previous mail, I updated NSTableColumn with the &amp;nbsp;
&lt;br&gt;latest Mac OS X additions.
&lt;br&gt;However I'm unsure how to precisely update the archiving code and I &amp;nbsp;
&lt;br&gt;don't want to break Gorm… Apple has the following keys in the xib &amp;nbsp;
&lt;br&gt;format: NSResizingMask (int), NSHeaderToolTip (string), NSHidden &amp;nbsp;
&lt;br&gt;(BOOL), NSSortDescriptorPrototype (object).
&lt;br&gt;Can somebody update the archiving the code or tell me what should I do &amp;nbsp;
&lt;br&gt;in details?
&lt;br&gt;&lt;br&gt;Cheers,
&lt;br&gt;Quentin.
&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26698682&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/NSTableColumn-Archiving-tp26698682p26698682.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26697857</id>
	<title>ABI / ivars policy</title>
	<published>2009-12-08T09:33:10Z</published>
	<updated>2009-12-08T09:33:10Z</updated>
	<author>
		<name>Quentin Mathé-2</name>
	</author>
	<content type="html">Hi,
&lt;br&gt;&lt;br&gt;Is there now an official policy that explains how we handle ivar &amp;nbsp;
&lt;br&gt;addition/removal? Is it still ok to put them in the header?
&lt;br&gt;I remember to have read a lengthy discussion on this topic few months &amp;nbsp;
&lt;br&gt;ago, and I just added some ivars to NSTableColumn, so I was wondering &amp;nbsp;
&lt;br&gt;whether what I did was correct or not.
&lt;br&gt;&lt;br&gt;Cheers,
&lt;br&gt;Quentin.
&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26697857&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/ABI---ivars-policy-tp26697857p26697857.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26674367</id>
	<title>Re: Segfault in pbxbuild</title>
	<published>2009-12-07T00:56:26Z</published>
	<updated>2009-12-07T00:56:26Z</updated>
	<author>
		<name>hansfbaier</name>
	</author>
	<content type="html">&lt;br&gt;&lt;br&gt;2009/12/3 SPUeNTRUP - Kai Henningsen &amp;lt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26674367&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Kai.Henningsen@...&lt;/a&gt;&amp;gt;:
&lt;div class='shrinkable-quote'&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; (gdb) where
&lt;br&gt;&amp;gt; #0  objc_msg_lookup (receiver=0x8490bb0, op=0xf76cfb68) at /opt/Cross/Work/i686-ubuntu-linux-gnu/BUILD/gcc-4.3.3/libobjc/sendmsg.c:224
&lt;br&gt;&amp;gt; #1  0xf74811ca in -[NSArrayEnumerator dealloc] (self=0x84915b0, _cmd=0xf76f5f40) at NSArray.m:1951
&lt;br&gt;&amp;gt; #2  0xf7514912 in -[NSObject release] (self=0x84915b0, _cmd=0xf76d0690) at NSObject.m:1949
&lt;br&gt;&amp;gt; #3  0xf7482189 in -[NSAutoreleasePool emptyPool] (self=0x83f96e0, _cmd=0xf76d06f8) at NSAutoreleasePool.m:404
&lt;br&gt;&amp;gt; #4  0xf7481fae in -[NSAutoreleasePool dealloc] (self=0x83f96e0, _cmd=0xf76d06f0) at NSAutoreleasePool.m:323
&lt;br&gt;&amp;gt; #5  0xf7481f63 in -[NSAutoreleasePool release] (self=0x83f96e0, _cmd=0x805eb18) at NSAutoreleasePool.m:316
&lt;br&gt;&amp;gt; #6  0x08057427 in main (argc=-143869376, argv=0x84a8258, env=0x62) at main.m:239
&lt;br&gt;&amp;gt; (gdb) p *receiver
&lt;br&gt;&amp;gt; $3 = {class_pointer = 0xdeadface}
&lt;br&gt;&amp;gt; (gdb)
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; Looks like a double release?
&lt;/div&gt;&lt;/div&gt;I am aware of that. Anyone knows how to find out which one
&lt;br&gt;since the crash has something to do with the autorelease pool?
&lt;br&gt;&lt;br&gt;Hans&lt;br /&gt; &lt;br /&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26674367&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;&lt;div class=&quot;small&quot;&gt;&lt;br/&gt;&lt;img src=&quot;http://old.nabble.com/images/icon_attachment.gif&quot; &gt; &lt;strong&gt;signature.asc&lt;/strong&gt; (279 bytes) &lt;a href=&quot;http://old.nabble.com/attachment/26674367/0/signature.asc&quot; target=&quot;_top&quot;&gt;Download Attachment&lt;/a&gt;&lt;/div&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Segfault-in-pbxbuild-tp26643605p26674367.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26669569</id>
	<title>[PATCH] NSColorWell activation on click</title>
	<published>2009-12-06T13:59:53Z</published>
	<updated>2009-12-06T13:59:53Z</updated>
	<author>
		<name>Eric Wasylishen-2</name>
	</author>
	<content type="html">Hi,
&lt;br&gt;Here is a patch which makes NSColorWell activate when you click in the
&lt;br&gt;coloured rectangle, matching OS X's behaviour. Dragging from the
&lt;br&gt;coloured area works the same as before.
&lt;br&gt;&lt;br&gt;The current behaviour, where clicking in the coloured rectangle starts
&lt;br&gt;and then immediately cancels a drag operation doesn't make sense to me
&lt;br&gt;(and there has been an inquiry sent to the mailing list from someone
&lt;br&gt;who thought colour wells were broken - they didn't realise you had to
&lt;br&gt;click on the border).
&lt;br&gt;&lt;br&gt;Regards,
&lt;br&gt;Eric
&lt;br&gt;&lt;br /&gt;&lt;tt&gt;[ColorWell.diff]&lt;/tt&gt;&lt;br /&gt;&lt;hr align=&quot;left&quot; width=&quot;300&quot; /&gt;&lt;tt&gt;Index: Source/NSColorWell.m
&lt;br&gt;===================================================================
&lt;br&gt;--- Source/NSColorWell.m	(revision 29096)
&lt;br&gt;+++ Source/NSColorWell.m	(working copy)
&lt;br&gt;@@ -46,6 +46,8 @@
&lt;br&gt;&amp;nbsp;static NSString *GSColorWellDidBecomeExclusiveNotification =
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;@&amp;quot;GSColorWellDidBecomeExclusiveNotification&amp;quot;;
&lt;br&gt;&amp;nbsp;
&lt;br&gt;+static NSPoint _lastMouseDownPoint;
&lt;br&gt;+
&lt;br&gt;&amp;nbsp;@implementation NSColorWell
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp;/*
&lt;br&gt;@@ -289,17 +291,12 @@
&lt;br&gt;&amp;nbsp; &amp;nbsp;//
&lt;br&gt;&amp;nbsp; &amp;nbsp;if ([self isEnabled])
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp;{
&lt;br&gt;- &amp;nbsp; &amp;nbsp; &amp;nbsp;NSPoint point = [self convertPoint: [theEvent locationInWindow]
&lt;br&gt;- &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;fromView: nil];
&lt;br&gt;+ &amp;nbsp; &amp;nbsp; &amp;nbsp;_lastMouseDownPoint = 
&lt;br&gt;+ &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; [self convertPoint: [theEvent locationInWindow]
&lt;br&gt;+ &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; fromView: nil];
&lt;br&gt;&amp;nbsp;
&lt;br&gt;- &amp;nbsp; &amp;nbsp; &amp;nbsp;if ([self mouse: point inRect: _wellRect])
&lt;br&gt;+ &amp;nbsp; &amp;nbsp; &amp;nbsp;if (_is_active == NO)
&lt;br&gt;&amp;nbsp;	{
&lt;br&gt;-	 &amp;nbsp;[NSColorPanel dragColor: _the_color
&lt;br&gt;-			withEvent: theEvent
&lt;br&gt;-			fromView: self];
&lt;br&gt;-	}
&lt;br&gt;- &amp;nbsp; &amp;nbsp; &amp;nbsp;else if (_is_active == NO)
&lt;br&gt;-	{
&lt;br&gt;&amp;nbsp;	 &amp;nbsp;[self activate: YES];
&lt;br&gt;&amp;nbsp;	}
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;else
&lt;br&gt;@@ -309,6 +306,19 @@
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp;}
&lt;br&gt;&amp;nbsp;}
&lt;br&gt;&amp;nbsp;
&lt;br&gt;+- (void) mouseDragged: (NSEvent *)theEvent
&lt;br&gt;+{
&lt;br&gt;+ &amp;nbsp;if ([self isEnabled])
&lt;br&gt;+ &amp;nbsp; &amp;nbsp;{
&lt;br&gt;+ &amp;nbsp; &amp;nbsp; &amp;nbsp;if ([self mouse: _lastMouseDownPoint inRect: _wellRect])
&lt;br&gt;+ &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;{
&lt;br&gt;+ &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;[NSColorPanel dragColor: _the_color
&lt;br&gt;+			withEvent: theEvent
&lt;br&gt;+			fromView: self];
&lt;br&gt;+ &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;}
&lt;br&gt;+ &amp;nbsp; &amp;nbsp;}
&lt;br&gt;+}
&lt;br&gt;+
&lt;br&gt;&amp;nbsp;- (BOOL) performDragOperation: (id &amp;lt;NSDraggingInfo&amp;gt;)sender
&lt;br&gt;&amp;nbsp;{
&lt;br&gt;&amp;nbsp; &amp;nbsp;NSPasteboard *pb = [sender draggingPasteboard];
&lt;br&gt;&lt;/tt&gt;&lt;hr align=&quot;left&quot; width=&quot;300&quot; /&gt;&lt;br /&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26669569&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-PATCH--NSColorWell-activation-on-click-tp26669569p26669569.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26655925</id>
	<title>Re: [flame] NEWS file is useless</title>
	<published>2009-12-05T05:58:16Z</published>
	<updated>2009-12-05T05:58:16Z</updated>
	<author>
		<name>Fred Kiefer</name>
	</author>
	<content type="html">I know that I am rather late to jump into this discussion, but I was
&lt;br&gt;away for a few weeks and only read through it now.
&lt;br&gt;&lt;br&gt;I strongly agree with Nicola's points here. I don't just write but also
&lt;br&gt;read the ChangeLog a lot. Before every substantial change I try to find
&lt;br&gt;the ChangeLog entry for the original code to understand why the code is
&lt;br&gt;the way it is now. This often helps to improve my own change. With the
&lt;br&gt;svn log I could find out about the comment for the specific file, but
&lt;br&gt;not what was going on around it. This is valuable information and we
&lt;br&gt;need to preserve it. And the next time we change our version control
&lt;br&gt;system we surely will be glad to have the old ChangeLog files to look up
&lt;br&gt;older comments.
&lt;br&gt;&lt;br&gt;Nicola Pero schrieb:
&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; Also, A ChangeLog is easy to search. When something breaks I grep in
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; the changelog. Old habits.
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; Why is:
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; cat ChangeLog | grep
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; easier than:
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; svn log | grep
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; Because using a ChangeLog doesn't require internet access, and it is
&lt;br&gt;&amp;gt; *much* faster. :-)
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; And for people who get a source tarball, they don't even need to have
&lt;br&gt;&amp;gt; subversion installed,
&lt;br&gt;&amp;gt; or know where the repository is located or how to access it.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; Anyway, it seems a long discussion on a minor point.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; I suggest we could simply manually copy the ChangeLog entry in the svn
&lt;br&gt;&amp;gt; commit message every time we do a commit.
&lt;br&gt;&amp;gt; Then the ChangeLog entry would be available also via svn log for people
&lt;br&gt;&amp;gt; who use svn logs instead of ChangeLogs
&lt;br&gt;&amp;gt; to track development.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; I guess this could be automated so a subversion hook would check that
&lt;br&gt;&amp;gt; every commit contains a ChangeLog entry,
&lt;br&gt;&amp;gt; and would automatically copy it into the subversion commit message. &amp;nbsp;As
&lt;br&gt;&amp;gt; hooks would slow down an already slow repository,
&lt;br&gt;&amp;gt; we could also simply agree to do it manually. &amp;nbsp;If someone gets it wrong
&lt;br&gt;&amp;gt; it will be immediately obvious by looking at the
&lt;br&gt;&amp;gt; svn logs and can be corrected.
&lt;/div&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26655925&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-flame--NEWS-file-is-useless-tp26520114p26655925.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26653588</id>
	<title>anybody working on gnustep on snow leo?</title>
	<published>2009-12-04T23:49:19Z</published>
	<updated>2009-12-04T23:49:19Z</updated>
	<author>
		<name>David Wetzel</name>
	</author>
	<content type="html">Hi guys,
&lt;br&gt;&lt;br&gt;has anybody gotten -base-additions to work on Mac OS snow leopard?
&lt;br&gt;&lt;br&gt;I could give temporary ssh access to a snow leo machine, if that would help.
&lt;br&gt;&lt;br&gt;Thanks!
&lt;br&gt;&lt;br&gt;David
&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26653588&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/anybody-working-on-gnustep-on-snow-leo--tp26653588p26653588.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26644508</id>
	<title>Re: [Gnustep-cvs] r29082 - in /libs/gui/trunk: ChangeLog Headers/AppKit/NSOutlineView.h Source/NSOutlineView.m</title>
	<published>2009-12-04T07:49:54Z</published>
	<updated>2009-12-04T07:49:54Z</updated>
	<author>
		<name>Quentin Mathé-2</name>
	</author>
	<content type="html">Le 30 nov. 2009 à 20:52, Richard Frith-Macdonald a écrit :
&lt;br&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; On 30 Nov 2009, at 00:00, Quentin Mathé wrote:
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; Since you are working on that, you might want to take a look at the &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; quick and dirty patch I attached to this bug report a while ago: &lt;a href=&quot;http://savannah.gnu.org/bugs/?18134&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://savannah.gnu.org/bugs/?18134&lt;/a&gt;&lt;br&gt;&amp;gt;&amp;gt; I don't know what is NSOutlineView current state. But the last time &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; I tried (one year ago) the drag and drop support was limited.
&lt;br&gt;&amp;gt;&amp;gt; The patch improves NSOutlineView to support dropping items at &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; arbitrary levels when rows are expanded (and not just at the level &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; 0). iirc It also changes NSOutlineView to correctly handle drop on &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; on a single row or on the whole view (as Mac OS X does when you are &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; dragging over an empty area).
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; I should have looked at bugzilla before I started! &amp;nbsp;I spent a large &amp;nbsp;
&lt;br&gt;&amp;gt; chunk of yesterday working on this and could probably have avoided a &amp;nbsp;
&lt;br&gt;&amp;gt; lot of that effort.
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; I found the original code hard to understand, and ended up rewriting &amp;nbsp;
&lt;br&gt;&amp;gt; to simplify (I hope) and adding quite a few comments.
&lt;/div&gt;&lt;br&gt;Yes, that's why I never cleaned the patch because I thought it would &amp;nbsp;
&lt;br&gt;be better to rewrite the whole method.
&lt;br&gt;The new code works pretty well in my tests. It's great to have drag &amp;nbsp;
&lt;br&gt;and drop really working in NSOutlineView :-)
&lt;br&gt;&lt;br&gt;&amp;gt; I also added auto-expand/collapse of items when you drag over &amp;nbsp;
&lt;br&gt;&amp;gt; them... not sure that behavior is quite right though.
&lt;br&gt;&lt;br&gt;Looks ok.
&lt;br&gt;&lt;br&gt;I have been working on simplifying/documenting the new code a bit more &amp;nbsp;
&lt;br&gt;and correcting some small issues, I'll commit my changes soon.
&lt;br&gt;&lt;br&gt;Quentin.
&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26644508&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Re%3A--Gnustep-cvs--r29082---in--libs-gui-trunk%3A-ChangeLog-Headers-AppKit-NSOutlineView.h-Source-NSOutlineView.m-tp26567782p26644508.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26643605</id>
	<title>Segfault in pbxbuild</title>
	<published>2009-12-02T10:15:57Z</published>
	<updated>2009-12-02T10:15:57Z</updated>
	<author>
		<name>SPUeNTRUP - Kai Henningsen-8</name>
	</author>
	<content type="html">&lt;br&gt;(gdb) where
&lt;br&gt;#0 &amp;nbsp;objc_msg_lookup (receiver=0x8490bb0, op=0xf76cfb68) at /opt/Cross/Work/i686-ubuntu-linux-gnu/BUILD/gcc-4.3.3/libobjc/sendmsg.c:224
&lt;br&gt;#1 &amp;nbsp;0xf74811ca in -[NSArrayEnumerator dealloc] (self=0x84915b0, _cmd=0xf76f5f40) at NSArray.m:1951
&lt;br&gt;#2 &amp;nbsp;0xf7514912 in -[NSObject release] (self=0x84915b0, _cmd=0xf76d0690) at NSObject.m:1949
&lt;br&gt;#3 &amp;nbsp;0xf7482189 in -[NSAutoreleasePool emptyPool] (self=0x83f96e0, _cmd=0xf76d06f8) at NSAutoreleasePool.m:404
&lt;br&gt;#4 &amp;nbsp;0xf7481fae in -[NSAutoreleasePool dealloc] (self=0x83f96e0, _cmd=0xf76d06f0) at NSAutoreleasePool.m:323
&lt;br&gt;#5 &amp;nbsp;0xf7481f63 in -[NSAutoreleasePool release] (self=0x83f96e0, _cmd=0x805eb18) at NSAutoreleasePool.m:316
&lt;br&gt;#6 &amp;nbsp;0x08057427 in main (argc=-143869376, argv=0x84a8258, env=0x62) at main.m:239
&lt;br&gt;(gdb) p *receiver
&lt;br&gt;$3 = {class_pointer = 0xdeadface}
&lt;br&gt;(gdb) 
&lt;br&gt;&lt;br&gt;Looks like a double release?
&lt;br&gt;&lt;br&gt;This happens with pbxbuild -g ProtocolBuffers.xcodeproj (from
&lt;br&gt;&lt;a href=&quot;http://metasyntactic.googlecode.com/files/ProtocolBuffers-2.2.0-Source.tar.gz&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://metasyntactic.googlecode.com/files/ProtocolBuffers-2.2.0-Source.tar.gz&lt;/a&gt;).
&lt;br&gt;&lt;br&gt;Newest pbxbuild from trunk.
&lt;br&gt;&lt;br&gt;Mit freundlichen Grüßen aus Münster /
&lt;br&gt;with kind regards - Kai Henningsen
&lt;br&gt;&lt;br&gt;-- 
&lt;br&gt;SPUeNTRUP Software
&lt;br&gt;An der Kleimannbrücke 52
&lt;br&gt;D-48157	Münster, Germany
&lt;br&gt;&lt;br&gt;Reg:	Münster Nr.29047
&lt;br&gt;&lt;br&gt;Fon:	+49 700 CALL CATS (=22552287)
&lt;br&gt;Fon:	+49 251 322 311 0
&lt;br&gt;Fax:	+49 251 322 311 99
&lt;br&gt;&lt;br&gt;Web:	&lt;a href=&quot;http://www.cats.ms&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.cats.ms&lt;/a&gt;&lt;br&gt;Mail:	&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26643605&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;support-kh-i@...&lt;/a&gt;
&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26643605&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Segfault-in-pbxbuild-tp26643605p26643605.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26581142</id>
	<title>Re: [Gnustep-cvs] r29082 - in /libs/gui/trunk: ChangeLog Headers/AppKit/NSOutlineView.h Source/NSOutlineView.m</title>
	<published>2009-11-30T11:52:11Z</published>
	<updated>2009-11-30T11:52:11Z</updated>
	<author>
		<name>Richard Frith-Macdonald-2</name>
	</author>
	<content type="html">&lt;br&gt;On 30 Nov 2009, at 00:00, Quentin Mathé wrote:
&lt;br&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; Hi Richard,
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; Le 29 nov. 2009 à 19:02, Richard Frith-Macdonald a écrit :
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt;&amp;gt; Author: rfm
&lt;br&gt;&amp;gt;&amp;gt; Date: Sun Nov 29 19:02:06 2009
&lt;br&gt;&amp;gt;&amp;gt; New Revision: 29082
&lt;br&gt;&amp;gt;&amp;gt; 
&lt;br&gt;&amp;gt;&amp;gt; URL: &lt;a href=&quot;http://svn.gna.org/viewcvs/gnustep?rev=29082&amp;view=rev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://svn.gna.org/viewcvs/gnustep?rev=29082&amp;view=rev&lt;/a&gt;&lt;br&gt;&amp;gt;&amp;gt; Log:
&lt;br&gt;&amp;gt;&amp;gt; First hack at expand/collapse as we drag over expandable items
&lt;br&gt;&amp;gt;&amp;gt; 
&lt;br&gt;&amp;gt;&amp;gt; 
&lt;br&gt;&amp;gt;&amp;gt; Modified:
&lt;br&gt;&amp;gt;&amp;gt; &amp;nbsp; libs/gui/trunk/ChangeLog
&lt;br&gt;&amp;gt;&amp;gt; &amp;nbsp; libs/gui/trunk/Headers/AppKit/NSOutlineView.h
&lt;br&gt;&amp;gt;&amp;gt; &amp;nbsp; libs/gui/trunk/Source/NSOutlineView.m
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; Since you are working on that, you might want to take a look at the quick and dirty patch I attached to this bug report a while ago: &lt;a href=&quot;http://savannah.gnu.org/bugs/?18134&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://savannah.gnu.org/bugs/?18134&lt;/a&gt;&lt;br&gt;&amp;gt; I don't know what is NSOutlineView current state. But the last time I tried (one year ago) the drag and drop support was limited.
&lt;br&gt;&amp;gt; The patch improves NSOutlineView to support dropping items at arbitrary levels when rows are expanded (and not just at the level 0). iirc It also changes NSOutlineView to correctly handle drop on on a single row or on the whole view (as Mac OS X does when you are dragging over an empty area).
&lt;/div&gt;&lt;br&gt;I should have looked at bugzilla before I started! &amp;nbsp;I spent a large chunk of yesterday working on this and could probably have avoided a lot of that effort.
&lt;br&gt;&lt;br&gt;I found the original code hard to understand, and ended up rewriting to simplify (I hope) and adding quite a few comments.
&lt;br&gt;&lt;br&gt;I also added auto-expand/collapse of items when you drag over them... not sure that behavior is quite right though.
&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26581142&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Re%3A--Gnustep-cvs--r29082---in--libs-gui-trunk%3A-ChangeLog-Headers-AppKit-NSOutlineView.h-Source-NSOutlineView.m-tp26567782p26581142.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26567782</id>
	<title>Re: [Gnustep-cvs] r29082 - in /libs/gui/trunk: ChangeLog Headers/AppKit/NSOutlineView.h Source/NSOutlineView.m</title>
	<published>2009-11-29T16:00:55Z</published>
	<updated>2009-11-29T16:00:55Z</updated>
	<author>
		<name>Quentin Mathé-2</name>
	</author>
	<content type="html">Hi Richard,
&lt;br&gt;&lt;br&gt;Le 29 nov. 2009 à 19:02, Richard Frith-Macdonald a écrit :
&lt;br&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; Author: rfm
&lt;br&gt;&amp;gt; Date: Sun Nov 29 19:02:06 2009
&lt;br&gt;&amp;gt; New Revision: 29082
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; URL: &lt;a href=&quot;http://svn.gna.org/viewcvs/gnustep?rev=29082&amp;view=rev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://svn.gna.org/viewcvs/gnustep?rev=29082&amp;view=rev&lt;/a&gt;&lt;br&gt;&amp;gt; Log:
&lt;br&gt;&amp;gt; First hack at expand/collapse as we drag over expandable items
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; Modified:
&lt;br&gt;&amp;gt; &amp;nbsp; &amp;nbsp;libs/gui/trunk/ChangeLog
&lt;br&gt;&amp;gt; &amp;nbsp; &amp;nbsp;libs/gui/trunk/Headers/AppKit/NSOutlineView.h
&lt;br&gt;&amp;gt; &amp;nbsp; &amp;nbsp;libs/gui/trunk/Source/NSOutlineView.m
&lt;/div&gt;&lt;br&gt;Since you are working on that, you might want to take a look at the &amp;nbsp;
&lt;br&gt;quick and dirty patch I attached to this bug report a while ago: &lt;a href=&quot;http://savannah.gnu.org/bugs/?18134&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://savannah.gnu.org/bugs/?18134&lt;/a&gt;&lt;br&gt;I don't know what is NSOutlineView current state. But the last time I &amp;nbsp;
&lt;br&gt;tried (one year ago) the drag and drop support was limited.
&lt;br&gt;The patch improves NSOutlineView to support dropping items at &amp;nbsp;
&lt;br&gt;arbitrary levels when rows are expanded (and not just at the level 0). &amp;nbsp;
&lt;br&gt;iirc It also changes NSOutlineView to correctly handle drop on on a &amp;nbsp;
&lt;br&gt;single row or on the whole view (as Mac OS X does when you are &amp;nbsp;
&lt;br&gt;dragging over an empty area).
&lt;br&gt;&lt;br&gt;Cheers,
&lt;br&gt;Quentin.
&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26567782&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Re%3A--Gnustep-cvs--r29082---in--libs-gui-trunk%3A-ChangeLog-Headers-AppKit-NSOutlineView.h-Source-NSOutlineView.m-tp26567782p26567782.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26547380</id>
	<title>Re: XML GNUstep defaults (was: [flame] NEWS file is useless)</title>
	<published>2009-11-27T12:24:25Z</published>
	<updated>2009-11-27T12:24:25Z</updated>
	<author>
		<name>Richard Frith-Macdonald-2</name>
	</author>
	<content type="html">&lt;br&gt;On 27 Nov 2009, at 20:05, Lars Sonchocky-Helldorf wrote:
&lt;br&gt;&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; Maybe we should file a bug with OS X on that by explaining them that they're writing invalid XML 1.0.
&lt;br&gt;&lt;br&gt;I did that some years ago. &amp;nbsp;Possibly they fixed it.
&lt;br&gt;&lt;br&gt;&amp;gt; A fix would be simple for Apple, I think there's nothing to stop them from fixing this. On what occasion does the ascii code 27 (escape) get written?
&lt;br&gt;&lt;br&gt;Well, it used to get written as the key for the autosaved location of the main menu in OPENSTEP and Rhapsody (possibly early OSX) before they completely removed the ability to use vertical menus, and I think it's cropped up in some text NIB files, but I don't have an example.
&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26547380&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-flame--NEWS-file-is-useless-tp26520114p26547380.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26547197</id>
	<title>Re: XML GNUstep defaults (was: [flame] NEWS file is useless)</title>
	<published>2009-11-27T12:05:01Z</published>
	<updated>2009-11-27T12:05:01Z</updated>
	<author>
		<name>Lars Sonchocky-Helldorf</name>
	</author>
	<content type="html">&lt;br&gt;Am 27.11.2009 um 20:36 schrieb Richard Frith-Macdonald:
&lt;br&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; On 27 Nov 2009, at 18:28, Lars Sonchocky-Helldorf wrote:
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; Am 27.11.2009 um 09:39 schrieb Richard Frith-Macdonald:
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; On 26 Nov 2009, at 17:35, Wolfgang Lux wrote:
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; Richard Frith-Macdonald wrote:
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; I think directly ~/GNUstep/Defaults/.GNUstepDefaults ?
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; That's XML for me now and it wasn't.
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; Oh, that's a hidden file for private use by the base &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; library ... kind of surprising that anyone would notice, and &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; certainly not something which should appear in news/release &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; notes as it's internal information.
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; Indeed, one shouldn't notice -- except that there was a bug in &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; NSPropertyList.m, which did use an incorrect translation for &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; ASCII control characters (it was using the old Java \Uxxxx &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; notation instead of numerical character encodings). Due to this &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; bug the position of menus was no longer persistent. I've just &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; committed a fix for this in svn and now torn-off menus will &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; reappear again the next time you start an app.
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; I partially reverted that ... the code to generate the escape &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; sequences was correct, the problem was a failure to parse them on &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; reading the result back.
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; The underlying issue is that certain characters are illegal in &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; XML, even when encoded using the &amp;#...; syntax!
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; The list of illegal characters includes ascii code 27 (escape), &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; yet OSX uses the escape character as the key for the top-level menu.
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; If you feed such data to a proper XML parser (such as libxml2), &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; it will abort parsing when it encounters the illegal character.
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; Isn't that a bug?
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; No ... it's what the XML spec says.
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; &lt;a href=&quot;http://www.w3.org/TR/xml11/#sec-xml11&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.w3.org/TR/xml11/#sec-xml11&lt;/a&gt;&amp;nbsp;says that &amp;quot;Finally, there is &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; considerable demand to define a standard representation of &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; arbitrary Unicode characters in XML documents. Therefore, XML 1.1 &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; allows the use of character references to the control characters &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; #x1 through #x1F, most of which are forbidden in XML 1.0. For &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; reasons of robustness, however, these characters still cannot be &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; used directly in documents.&amp;quot;
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; That's really interesting ... I didn't know that this was changed &amp;nbsp;
&lt;br&gt;&amp;gt; for XML 1.1
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; Or are xml-plists still based on XML 1.0?
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; Yes ... they pre-date XML 1.1.
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; Here's the header of a property list copied from my (snow-leopard) &amp;nbsp;
&lt;br&gt;&amp;gt; OSX system:
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;UTF-8&amp;quot;?&amp;gt;&amp;lt;!DOCTYPE plist PUBLIC &amp;quot;-// 
&lt;br&gt;&amp;gt; Apple//DTD PLIST 1.0//EN&amp;quot; &amp;quot;&lt;a href=&quot;http://www.apple.com/DTDs/&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.apple.com/DTDs/&lt;/a&gt;&amp;nbsp;
&lt;br&gt;&amp;gt; PropertyList-1.0.dtd&amp;quot;&amp;gt;&amp;lt;plist version=&amp;quot;1.0&amp;quot;&amp;gt;
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; If we assume that 'XML' property lists will never actually be &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; processed by real XML parsers, we don't need the additional &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; encoding.
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; One never knows, maybe at one day somebody wants to write some &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; sort of converter using XSLT. Locking out XML tools makes the &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; whole idea of using XML for plists somewhat pointless
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; Perhaps we can change to using XML 1.1 for our plists?
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; &amp;lt;rant&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; I think the old or &amp;quot;classic&amp;quot; format is much better readable and &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; less verbose - and nowadays after the XML hype people start using &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; JSON ( &lt;a href=&quot;http://en.wikipedia.org/wiki/JSON&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://en.wikipedia.org/wiki/JSON&lt;/a&gt;&amp;nbsp;) for formerly XMLish &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; purposes which is a lot like the classic plist format.
&lt;br&gt;&amp;gt;&amp;gt; &amp;lt;/rant&amp;gt;
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; Yes, the old plist is better in almost every way (addition of date, &amp;nbsp;
&lt;br&gt;&amp;gt; boolean, and numeric types were good extensions though).
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; I just tried an experiment on OSX.
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; I copied an existing OSX XML property list, edited it with vi, and &amp;nbsp;
&lt;br&gt;&amp;gt; set the xml version in the header to 1.1 rather than 1.0
&lt;br&gt;&amp;gt; I then opened it in the 'Property List Editor' application ... it &amp;nbsp;
&lt;br&gt;&amp;gt; opened perfectly well and I was able to make a small edit.
&lt;br&gt;&amp;gt; I then saved it ... the saved output has the '1.0' version header &amp;nbsp;
&lt;br&gt;&amp;gt; again.
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; So it looks like OSX can read XML 1.1 but still writes 1.0
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; If there's no problem with OSX reading it ... I see no real reason &amp;nbsp;
&lt;br&gt;&amp;gt; why we can't update our plist code to output XML version 1.1 rather &amp;nbsp;
&lt;br&gt;&amp;gt; than 1.0 ... the only worry then would be that older XML software, &amp;nbsp;
&lt;br&gt;&amp;gt; which didn't support version 1.1, &amp;nbsp;might have trouble with it. &amp;nbsp; 
&lt;br&gt;&amp;gt; That's probably acceptable.
&lt;br&gt;&amp;gt;
&lt;/div&gt;&lt;br&gt;Maybe we should file a bug with OS X on that by explaining them that &amp;nbsp;
&lt;br&gt;they're writing invalid XML 1.0. A fix would be simple for Apple, I &amp;nbsp;
&lt;br&gt;think there's nothing to stop them from fixing this. On what occasion &amp;nbsp;
&lt;br&gt;does the ascii code 27 (escape) get written? Where can I find such an &amp;nbsp;
&lt;br&gt;invalid XML?
&lt;br&gt;&lt;br&gt;What do you think?
&lt;br&gt;&lt;br&gt;&lt;br&gt;regards,
&lt;br&gt;&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; Lars
&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26547197&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-flame--NEWS-file-is-useless-tp26520114p26547197.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26546945</id>
	<title>Re: XML GNUstep defaults (was: [flame] NEWS file is useless)</title>
	<published>2009-11-27T11:36:10Z</published>
	<updated>2009-11-27T11:36:10Z</updated>
	<author>
		<name>Richard Frith-Macdonald-2</name>
	</author>
	<content type="html">&lt;br&gt;On 27 Nov 2009, at 18:28, Lars Sonchocky-Helldorf wrote:
&lt;br&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; Am 27.11.2009 um 09:39 schrieb Richard Frith-Macdonald:
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt;&amp;gt; 
&lt;br&gt;&amp;gt;&amp;gt; On 26 Nov 2009, at 17:35, Wolfgang Lux wrote:
&lt;br&gt;&amp;gt;&amp;gt; 
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; Richard Frith-Macdonald wrote:
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; 
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; I think directly ~/GNUstep/Defaults/.GNUstepDefaults ?
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; That's XML for me now and it wasn't.
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; 
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; Oh, that's a hidden file for private use by the base library ... kind of surprising that anyone would notice, and certainly not something which should appear in news/release notes as it's internal information.
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; 
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; Indeed, one shouldn't notice -- except that there was a bug in NSPropertyList.m, which did use an incorrect translation for ASCII control characters (it was using the old Java \Uxxxx notation instead of numerical character encodings). Due to this bug the position of menus was no longer persistent. I've just committed a fix for this in svn and now torn-off menus will reappear again the next time you start an app.
&lt;br&gt;&amp;gt;&amp;gt; 
&lt;br&gt;&amp;gt;&amp;gt; I partially reverted that ... the code to generate the escape sequences was correct, the problem was a failure to parse them on reading the result back.
&lt;br&gt;&amp;gt;&amp;gt; 
&lt;br&gt;&amp;gt;&amp;gt; The underlying issue is that certain characters are illegal in XML, even when encoded using the &amp;#...; syntax!
&lt;br&gt;&amp;gt;&amp;gt; The list of illegal characters includes ascii code 27 (escape), yet OSX uses the escape character as the key for the top-level menu.
&lt;br&gt;&amp;gt;&amp;gt; If you feed such data to a proper XML parser (such as libxml2), it will abort parsing when it encounters the illegal character.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; Isn't that a bug?
&lt;/div&gt;&lt;br&gt;No ... it's what the XML spec says.
&lt;br&gt;&lt;br&gt;&amp;gt; &lt;a href=&quot;http://www.w3.org/TR/xml11/#sec-xml11&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.w3.org/TR/xml11/#sec-xml11&lt;/a&gt;&amp;nbsp;says that &amp;quot;Finally, there is considerable demand to define a standard representation of arbitrary Unicode characters in XML documents. Therefore, XML 1.1 allows the use of character references to the control characters #x1 through #x1F, most of which are forbidden in XML 1.0. For reasons of robustness, however, these characters still cannot be used directly in documents.&amp;quot;
&lt;br&gt;&lt;br&gt;That's really interesting ... I didn't know that this was changed for XML 1.1
&lt;br&gt;&lt;br&gt;&amp;gt; Or are xml-plists still based on XML 1.0?
&lt;br&gt;&lt;br&gt;Yes ... they pre-date XML 1.1.
&lt;br&gt;&lt;br&gt;Here's the header of a property list copied from my (snow-leopard) OSX system:
&lt;br&gt;&lt;br&gt;&amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;UTF-8&amp;quot;?&amp;gt;&amp;lt;!DOCTYPE plist PUBLIC &amp;quot;-//Apple//DTD PLIST 1.0//EN&amp;quot; &amp;quot;&lt;a href=&quot;http://www.apple.com/DTDs/PropertyList-1.0.dtd&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.apple.com/DTDs/PropertyList-1.0.dtd&lt;/a&gt;&amp;quot;&amp;gt;&amp;lt;plist version=&amp;quot;1.0&amp;quot;&amp;gt;
&lt;br&gt;&lt;br&gt;&amp;gt;&amp;gt; If we assume that 'XML' property lists will never actually be processed by real XML parsers, we don't need the additional encoding.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; One never knows, maybe at one day somebody wants to write some sort of converter using XSLT. Locking out XML tools makes the whole idea of using XML for plists somewhat pointless
&lt;br&gt;&lt;br&gt;Perhaps we can change to using XML 1.1 for our plists?
&lt;br&gt;&lt;br&gt;&amp;gt; &amp;lt;rant&amp;gt;
&lt;br&gt;&amp;gt; I think the old or &amp;quot;classic&amp;quot; format is much better readable and less verbose - and nowadays after the XML hype people start using JSON ( &lt;a href=&quot;http://en.wikipedia.org/wiki/JSON&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://en.wikipedia.org/wiki/JSON&lt;/a&gt;&amp;nbsp;) for formerly XMLish purposes which is a lot like the classic plist format.
&lt;br&gt;&amp;gt; &amp;lt;/rant&amp;gt;
&lt;br&gt;&lt;br&gt;Yes, the old plist is better in almost every way (addition of date, boolean, and numeric types were good extensions though).
&lt;br&gt;&lt;br&gt;&lt;br&gt;I just tried an experiment on OSX.
&lt;br&gt;&lt;br&gt;I copied an existing OSX XML property list, edited it with vi, and set the xml version in the header to 1.1 rather than 1.0
&lt;br&gt;I then opened it in the 'Property List Editor' application ... it opened perfectly well and I was able to make a small edit.
&lt;br&gt;I then saved it ... the saved output has the '1.0' version header again.
&lt;br&gt;&lt;br&gt;So it looks like OSX can read XML 1.1 but still writes 1.0
&lt;br&gt;&lt;br&gt;If there's no problem with OSX reading it ... I see no real reason why we can't update our plist code to output XML version 1.1 rather than 1.0 ... the only worry then would be that older XML software, which didn't support version 1.1, &amp;nbsp;might have trouble with it. &amp;nbsp;That's probably acceptable.
&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26546945&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-flame--NEWS-file-is-useless-tp26520114p26546945.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26546205</id>
	<title>Re: XML GNUstep defaults (was: [flame] NEWS file is useless)</title>
	<published>2009-11-27T10:28:39Z</published>
	<updated>2009-11-27T10:28:39Z</updated>
	<author>
		<name>Lars Sonchocky-Helldorf</name>
	</author>
	<content type="html">&lt;br&gt;Am 27.11.2009 um 09:39 schrieb Richard Frith-Macdonald:
&lt;br&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; On 26 Nov 2009, at 17:35, Wolfgang Lux wrote:
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; Richard Frith-Macdonald wrote:
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; I think directly ~/GNUstep/Defaults/.GNUstepDefaults ?
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; That's XML for me now and it wasn't.
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; Oh, that's a hidden file for private use by the base library ... &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; kind of surprising that anyone would notice, and certainly not &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; something which should appear in news/release notes as it's &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; internal information.
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; Indeed, one shouldn't notice -- except that there was a bug in &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; NSPropertyList.m, which did use an incorrect translation for ASCII &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; control characters (it was using the old Java \Uxxxx notation &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; instead of numerical character encodings). Due to this bug the &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; position of menus was no longer persistent. I've just committed a &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; fix for this in svn and now torn-off menus will reappear again the &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; next time you start an app.
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; I partially reverted that ... the code to generate the escape &amp;nbsp;
&lt;br&gt;&amp;gt; sequences was correct, the problem was a failure to parse them on &amp;nbsp;
&lt;br&gt;&amp;gt; reading the result back.
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; The underlying issue is that certain characters are illegal in XML, &amp;nbsp;
&lt;br&gt;&amp;gt; even when encoded using the &amp;#...; syntax!
&lt;br&gt;&amp;gt; The list of illegal characters includes ascii code 27 (escape), yet &amp;nbsp;
&lt;br&gt;&amp;gt; OSX uses the escape character as the key for the top-level menu.
&lt;br&gt;&amp;gt; If you feed such data to a proper XML parser (such as libxml2), it &amp;nbsp;
&lt;br&gt;&amp;gt; will abort parsing when it encounters the illegal character.
&lt;/div&gt;&lt;br&gt;Isn't that a bug?
&lt;br&gt;&lt;br&gt;&lt;a href=&quot;http://www.w3.org/TR/xml11/#sec-xml11&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.w3.org/TR/xml11/#sec-xml11&lt;/a&gt;&amp;nbsp;says that &amp;quot;Finally, there is &amp;nbsp;
&lt;br&gt;considerable demand to define a standard representation of arbitrary &amp;nbsp;
&lt;br&gt;Unicode characters in XML documents. Therefore, XML 1.1 allows the &amp;nbsp;
&lt;br&gt;use of character references to the control characters #x1 through &amp;nbsp;
&lt;br&gt;#x1F, most of which are forbidden in XML 1.0. For reasons of &amp;nbsp;
&lt;br&gt;robustness, however, these characters still cannot be used directly &amp;nbsp;
&lt;br&gt;in documents.&amp;quot;
&lt;br&gt;&lt;br&gt;Or are xml-plists still based on XML 1.0?
&lt;br&gt;&lt;br&gt;&amp;gt; If we assume that 'XML' property lists will never actually be &amp;nbsp;
&lt;br&gt;&amp;gt; processed by real XML parsers, we don't need the additional encoding.
&lt;br&gt;&lt;br&gt;One never knows, maybe at one day somebody wants to write some sort &amp;nbsp;
&lt;br&gt;of converter using XSLT. Locking out XML tools makes the whole idea &amp;nbsp;
&lt;br&gt;of using XML for plists somewhat pointless
&lt;br&gt;&lt;br&gt;&amp;lt;rant&amp;gt;
&lt;br&gt;I think the old or &amp;quot;classic&amp;quot; format is much better readable and less &amp;nbsp;
&lt;br&gt;verbose - and nowadays after the XML hype people start using JSON &amp;nbsp;
&lt;br&gt;( &lt;a href=&quot;http://en.wikipedia.org/wiki/JSON&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://en.wikipedia.org/wiki/JSON&lt;/a&gt;&amp;nbsp;) for formerly XMLish purposes &amp;nbsp;
&lt;br&gt;which is a lot like the classic plist format.
&lt;br&gt;&amp;lt;/rant&amp;gt;
&lt;br&gt;&lt;br&gt;regards,
&lt;br&gt;&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; Lars
&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26546205&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-flame--NEWS-file-is-useless-tp26520114p26546205.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26545892</id>
	<title>Re: Notification centre and threads</title>
	<published>2009-11-27T09:59:11Z</published>
	<updated>2009-11-27T09:59:11Z</updated>
	<author>
		<name>Richard Frith-Macdonald-2</name>
	</author>
	<content type="html">&lt;br&gt;On 27 Nov 2009, at 17:43, Richard Frith-Macdonald wrote:
&lt;br&gt;&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; On 27 Nov 2009, at 17:22, David Chisnall wrote:
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt;&amp;gt; Hi,
&lt;br&gt;&amp;gt;&amp;gt; 
&lt;br&gt;&amp;gt;&amp;gt; I've noticed a couple of places in the GNUstep source where the NSNotificationCentre is cached the first time a class is created and then used by all instances. &amp;nbsp;With the documented behaviour for the notification centre on OS X, this will do undefined things when the instance is not in the same thread as the one where the notification centre was created. &amp;nbsp;Does GNUstep have some special logic for handling cross-thread notifications (and is this documented somewhere) or are all of these uses potential bugs?
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; I'm not sure ... I think NSNotificationCenter is thread-safe in GNUstep ... what problems would that cause?
&lt;br&gt;&lt;br&gt;I had a quick look at the current OSX documentation for the class, and I didn't see anything saying that it 'will do undefined things when the instance is not in the same thread as the one where the notification centre was created' ... what did I miss?
&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26545892&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Notification-centre-and-threads-tp26545487p26545892.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26545734</id>
	<title>Re: Notification centre and threads</title>
	<published>2009-11-27T09:43:01Z</published>
	<updated>2009-11-27T09:43:01Z</updated>
	<author>
		<name>Richard Frith-Macdonald-2</name>
	</author>
	<content type="html">&lt;br&gt;On 27 Nov 2009, at 17:22, David Chisnall wrote:
&lt;br&gt;&lt;br&gt;&amp;gt; Hi,
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; I've noticed a couple of places in the GNUstep source where the NSNotificationCentre is cached the first time a class is created and then used by all instances. &amp;nbsp;With the documented behaviour for the notification centre on OS X, this will do undefined things when the instance is not in the same thread as the one where the notification centre was created. &amp;nbsp;Does GNUstep have some special logic for handling cross-thread notifications (and is this documented somewhere) or are all of these uses potential bugs?
&lt;br&gt;&lt;br&gt;I'm not sure ... I think NSNotificationCenter is thread-safe in GNUstep ... what problems would that cause?
&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26545734&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Notification-centre-and-threads-tp26545487p26545734.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26545487</id>
	<title>Notification centre and threads</title>
	<published>2009-11-27T09:22:33Z</published>
	<updated>2009-11-27T09:22:33Z</updated>
	<author>
		<name>David Chisnall</name>
	</author>
	<content type="html">Hi,
&lt;br&gt;&lt;br&gt;I've noticed a couple of places in the GNUstep source where the &amp;nbsp;
&lt;br&gt;NSNotificationCentre is cached the first time a class is created and &amp;nbsp;
&lt;br&gt;then used by all instances. &amp;nbsp;With the documented behaviour for the &amp;nbsp;
&lt;br&gt;notification centre on OS X, this will do undefined things when the &amp;nbsp;
&lt;br&gt;instance is not in the same thread as the one where the notification &amp;nbsp;
&lt;br&gt;centre was created. &amp;nbsp;Does GNUstep have some special logic for handling &amp;nbsp;
&lt;br&gt;cross-thread notifications (and is this documented somewhere) or are &amp;nbsp;
&lt;br&gt;all of these uses potential bugs?
&lt;br&gt;&lt;br&gt;David
&lt;br&gt;-- Send from my Jacquard Loom
&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26545487&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Notification-centre-and-threads-tp26545487p26545487.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26542394</id>
	<title>Re: XML GNUstep defaults (was: [flame] NEWS file is useless)</title>
	<published>2009-11-27T05:26:06Z</published>
	<updated>2009-11-27T05:26:06Z</updated>
	<author>
		<name>David Chisnall</name>
	</author>
	<content type="html">On 27 Nov 2009, at 08:39, Richard Frith-Macdonald wrote:
&lt;br&gt;&lt;br&gt;&amp;gt; The question is, do we want to write illegal XML in property lists? &amp;nbsp; 
&lt;br&gt;&amp;gt; At the moment the code can write legal XML or illegal (OSX &amp;nbsp;
&lt;br&gt;&amp;gt; compatible) XML depending on the OSX compatibility defaults &amp;nbsp;
&lt;br&gt;&amp;gt; setting. &amp;nbsp;If we assume that 'XML' property lists will never actually &amp;nbsp;
&lt;br&gt;&amp;gt; be processed by real XML parsers, we don't need the additional &amp;nbsp;
&lt;br&gt;&amp;gt; encoding.
&lt;br&gt;&lt;br&gt;&lt;br&gt;I think the best bet would be to be compatible with other property &amp;nbsp;
&lt;br&gt;list parsers. &amp;nbsp;How does the NetBSD XML property list parser cope with &amp;nbsp;
&lt;br&gt;illegal characters? &amp;nbsp;Does WindowMaker support XML plists and, if so, &amp;nbsp;
&lt;br&gt;can it handle them?
&lt;br&gt;&lt;br&gt;David
&lt;br&gt;&lt;br&gt;-- Sent from my PDP-11
&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26542394&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-flame--NEWS-file-is-useless-tp26520114p26542394.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26539855</id>
	<title>Re: [flame] NEWS file is useless</title>
	<published>2009-11-27T01:31:03Z</published>
	<updated>2009-11-27T01:31:03Z</updated>
	<author>
		<name>Nicola Pero-4</name>
	</author>
	<content type="html">&lt;div class='shrinkable-quote'&gt;&amp;gt;&amp;gt; Also, A ChangeLog is easy to search. When something breaks I grep &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; in the changelog. Old habits.
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; Why is:
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; cat ChangeLog | grep
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; easier than:
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; svn log | grep
&lt;/div&gt;&lt;br&gt;Because using a ChangeLog doesn't require internet access, and it is &amp;nbsp;
&lt;br&gt;*much* faster. :-)
&lt;br&gt;&lt;br&gt;And for people who get a source tarball, they don't even need to have &amp;nbsp;
&lt;br&gt;subversion installed,
&lt;br&gt;or know where the repository is located or how to access it.
&lt;br&gt;&lt;br&gt;Anyway, it seems a long discussion on a minor point.
&lt;br&gt;&lt;br&gt;I suggest we could simply manually copy the ChangeLog entry in the svn &amp;nbsp;
&lt;br&gt;commit message every time we do a commit.
&lt;br&gt;Then the ChangeLog entry would be available also via svn log for &amp;nbsp;
&lt;br&gt;people who use svn logs instead of ChangeLogs
&lt;br&gt;to track development.
&lt;br&gt;&lt;br&gt;I guess this could be automated so a subversion hook would check that &amp;nbsp;
&lt;br&gt;every commit contains a ChangeLog entry,
&lt;br&gt;and would automatically copy it into the subversion commit message. &amp;nbsp; 
&lt;br&gt;As hooks would slow down an already slow repository,
&lt;br&gt;we could also simply agree to do it manually. &amp;nbsp;If someone gets it &amp;nbsp;
&lt;br&gt;wrong it will be immediately obvious by looking at the
&lt;br&gt;svn logs and can be corrected.
&lt;br&gt;&lt;br&gt;Thanks
&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26539855&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-flame--NEWS-file-is-useless-tp26520114p26539855.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26539324</id>
	<title>Re: XML GNUstep defaults (was: [flame] NEWS file is useless)</title>
	<published>2009-11-27T00:39:05Z</published>
	<updated>2009-11-27T00:39:05Z</updated>
	<author>
		<name>Richard Frith-Macdonald-2</name>
	</author>
	<content type="html">&lt;br&gt;On 26 Nov 2009, at 17:35, Wolfgang Lux wrote:
&lt;br&gt;&lt;br&gt;&amp;gt; Richard Frith-Macdonald wrote:
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; I think directly ~/GNUstep/Defaults/.GNUstepDefaults ?
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; That's XML for me now and it wasn't.
&lt;br&gt;&amp;gt;&amp;gt; 
&lt;br&gt;&amp;gt;&amp;gt; Oh, that's a hidden file for private use by the base library ... kind of surprising that anyone would notice, and certainly not something which should appear in news/release notes as it's internal information.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; Indeed, one shouldn't notice -- except that there was a bug in NSPropertyList.m, which did use an incorrect translation for ASCII control characters (it was using the old Java \Uxxxx notation instead of numerical character encodings). Due to this bug the position of menus was no longer persistent. I've just committed a fix for this in svn and now torn-off menus will reappear again the next time you start an app.
&lt;br&gt;&lt;br&gt;I partially reverted that ... the code to generate the escape sequences was correct, the problem was a failure to parse them on reading the result back.
&lt;br&gt;&lt;br&gt;The underlying issue is that certain characters are illegal in XML, even when encoded using the &amp;#...; syntax!
&lt;br&gt;The list of illegal characters includes ascii code 27 (escape), yet OSX uses the escape character as the key for the top-level menu.
&lt;br&gt;If you feed such data to a proper XML parser (such as libxml2), it will abort parsing when it encounters the illegal character.
&lt;br&gt;The OSX property list parser is not actually an XML parser .... it's really handling something which just looks a lot like XML.
&lt;br&gt;So the use of the \U... syntax was/is there to encode characters in property lists, hiding them from the XML parser ...
&lt;br&gt;then the property list parser needs to decode these sequences after the XML parser has done with them.
&lt;br&gt;&lt;br&gt;Now, we have a (rather immature) XML parser in base which is currently being trialled as a replacement for libxml2. &amp;nbsp;It treats all characters as legal and can therefore handle property lists containing illegal characters. &amp;nbsp;So perhaps we can remove the additional encoding of illegal characters.
&lt;br&gt;The question is, do we want to write illegal XML in property lists? &amp;nbsp;At the moment the code can write legal XML or illegal (OSX compatible) XML depending on the OSX compatibility defaults setting. &amp;nbsp;If we assume that 'XML' property lists will never actually be processed by real XML parsers, we don't need the additional encoding.
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26539324&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-flame--NEWS-file-is-useless-tp26520114p26539324.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26535933</id>
	<title>Re: [flame] NEWS file is useless</title>
	<published>2009-11-26T14:50:59Z</published>
	<updated>2009-11-26T14:50:59Z</updated>
	<author>
		<name>David Chisnall</name>
	</author>
	<content type="html">On 26 Nov 2009, at 22:15, Riccardo Mottola wrote:
&lt;br&gt;&lt;br&gt;&amp;gt; Not only in a ChangeLog I can write more than in a commit and I can &amp;nbsp;
&lt;br&gt;&amp;gt; group files and comment on sigle pieces of them, but it is an easy &amp;nbsp;
&lt;br&gt;&amp;gt; file I can check.
&lt;br&gt;&lt;br&gt;&lt;br&gt;Are you using a different svn to me? &amp;nbsp;When I do a commit, it pops up &amp;nbsp;
&lt;br&gt;$EDITOR (vim in my case, but apparently some people use the other one) &amp;nbsp;
&lt;br&gt;and I can type as much as I want into it. &amp;nbsp;I frequently put a couple &amp;nbsp;
&lt;br&gt;of paragraphs into commit logs.
&lt;br&gt;&lt;br&gt;&amp;gt; Also, one interesting point: can I correct a svn commit message?
&lt;br&gt;&lt;br&gt;Yes.
&lt;br&gt;&lt;br&gt;&amp;gt; It happens that I write wrong information or that I find a better &amp;nbsp;
&lt;br&gt;&amp;gt; way to explain it. With the ChangeLog it is easy... I commit a new &amp;nbsp;
&lt;br&gt;&amp;gt; improved version.
&lt;br&gt;&amp;gt; What would you do with svn?
&lt;br&gt;&lt;br&gt;svn propedit. &amp;nbsp;Commit messages are in svn properties and can be edited &amp;nbsp;
&lt;br&gt;just like any other properties.
&lt;br&gt;&lt;br&gt;You can edit the commit message and it remains associated with the &amp;nbsp;
&lt;br&gt;revision, so, for example people who use viewvc to browse the source &amp;nbsp;
&lt;br&gt;code can jump to the commit log. &amp;nbsp;If something has recently changed in &amp;nbsp;
&lt;br&gt;NSOutlineView, for example, then I go here:
&lt;br&gt;&lt;br&gt;&lt;a href=&quot;http://svn.gna.org/viewcvs/gnustep/libs/gui/trunk/Source/NSOutlineView.m?rev=29065&amp;dir_pagestart=150&amp;view=log&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://svn.gna.org/viewcvs/gnustep/libs/gui/trunk/Source/NSOutlineView.m?rev=29065&amp;dir_pagestart=150&amp;view=log&lt;/a&gt;&lt;br&gt;&lt;br&gt;I get the commit message for each change and can see the diff side by &amp;nbsp;
&lt;br&gt;side. &amp;nbsp;If the person who made the change put the message in the &amp;nbsp;
&lt;br&gt;ChangeLog instead, then I have to search in a separate file as well &amp;nbsp;
&lt;br&gt;for each change that touched the file. &amp;nbsp;In no possible way is that &amp;nbsp;
&lt;br&gt;easier.
&lt;br&gt;&lt;br&gt;&amp;gt; Also, A ChangeLog is easy to search. When something breaks I grep in &amp;nbsp;
&lt;br&gt;&amp;gt; the changelog. Old habits.
&lt;br&gt;&lt;br&gt;Why is:
&lt;br&gt;&lt;br&gt;cat ChangeLog | grep
&lt;br&gt;&lt;br&gt;easier than:
&lt;br&gt;&lt;br&gt;svn log | grep
&lt;br&gt;&lt;br&gt;Especially as the svn log line can be filtered to find the changes on &amp;nbsp;
&lt;br&gt;a specific file just by specifying the file on the command line.
&lt;br&gt;&lt;br&gt;David
&lt;br&gt;&lt;br&gt;-- Sent from my Cray X1
&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26535933&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-flame--NEWS-file-is-useless-tp26520114p26535933.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26535691</id>
	<title>Re: [flame] NEWS file is useless</title>
	<published>2009-11-26T14:24:51Z</published>
	<updated>2009-11-26T14:24:51Z</updated>
	<author>
		<name>Nicolas Roard</name>
	</author>
	<content type="html">On Thu, Nov 26, 2009 at 10:15 PM, Riccardo Mottola &amp;lt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26535691&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;multix@...&lt;/a&gt;&amp;gt; wrote:
&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; David Chisnall wrote:
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; On 25 Nov 2009, at 22:39, Richard Frith-Macdonald wrote:
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; There are actually three levels of change information ...
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; NEWS  ... just the headlines
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; ReleaseNotes ... some more detail
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; ChangeLog ... everything
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; Maybe you are right and we shouldn't bother with NEWS?  I'd be interested
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; to know what others think.
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; I'd be in favour of ditching NEWS and ChangeLog.
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; ChangeLog has less information, in a less useful format, than the svn logs
&lt;br&gt;&amp;gt;&amp;gt; and is a hold-over from CVS not storing repository-wide change information
&lt;br&gt;&amp;gt;&amp;gt; sensibly.  With svn log, you can get a log of change messages at any
&lt;br&gt;&amp;gt;&amp;gt; granularity that you like.  If anyone actually cares about ChangeLog then
&lt;br&gt;&amp;gt;&amp;gt; they can do 'svn log &amp;gt; ChangeLog' on their local machine.  Stuff in the svn
&lt;br&gt;&amp;gt;&amp;gt; log can be processed easily, and is easier for people to check than the
&lt;br&gt;&amp;gt;&amp;gt; ChangeLog, for example:
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; Well, I disagree.
&lt;br&gt;&amp;gt; The utility of NEWS is questionable, but ChangeLog should be preserved. Not
&lt;br&gt;&amp;gt; only in a ChangeLog I can write more than in a commit and I can group files
&lt;br&gt;&amp;gt; and comment on sigle pieces of them, but it is an easy file I can check.
&lt;br&gt;&amp;gt; Also, ChangeLog gets released, so it is available in the end-suer release
&lt;br&gt;&amp;gt; tarball.
&lt;/div&gt;&lt;br&gt;I think we should keep the ChangeLog file, but I really don't see the
&lt;br&gt;point in NOT generating it automatically. Nothing prevent you to write
&lt;br&gt;more detailed commits logs, and it really feels like duplication to me
&lt;br&gt;(and you can always forget to modify the ChangeLog...).
&lt;br&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; ReleaseNotes may contain comments about incompatibilities, deprecations of
&lt;br&gt;&amp;gt; methods, upgrade procedures...
&lt;br&gt;&amp;gt; NEWS is perhaps more geared towards notable end-user readable things like
&lt;br&gt;&amp;gt; new features, big fixes. It is perhaps more useful for an Application than
&lt;br&gt;&amp;gt; the library.
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; Riccardo
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; _______________________________________________
&lt;br&gt;&amp;gt; Gnustep-dev mailing list
&lt;br&gt;&amp;gt; &lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26535691&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&amp;gt; &lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;&amp;gt;
&lt;/div&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;-- 
&lt;br&gt;Nicolas Roard
&lt;br&gt;&amp;quot;I love deadlines. I like the whooshing sound
&lt;br&gt;they make as they fly by.&amp;quot; -- Douglas Adams
&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26535691&amp;i=2&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-flame--NEWS-file-is-useless-tp26520114p26535691.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26535694</id>
	<title>Re: [flame] NEWS file is useless</title>
	<published>2009-11-26T14:23:51Z</published>
	<updated>2009-11-26T14:23:51Z</updated>
	<author>
		<name>Riccardo Mottola-4</name>
	</author>
	<content type="html">Hi,
&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; By the way, presumably we'd still include the author of the change in 
&lt;br&gt;&amp;gt; the subversion commit message ?
&lt;br&gt;&amp;gt; Ie, we write a full ChangeLog entry including the author at the 
&lt;br&gt;&amp;gt; beginning ?
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; The reason is that when we receive patches, the committer is often 
&lt;br&gt;&amp;gt; *not* the author of the patch, only the reviewer.
&lt;br&gt;&amp;gt; With ChangeLog entries you can see who is the author of the patch, 
&lt;br&gt;&amp;gt; regardless of who did the actual commit.
&lt;br&gt;&amp;gt; (and occasionally, some changes simply have two or more authors - 
&lt;br&gt;&amp;gt; again in ChangeLogs you just list multiple
&lt;br&gt;&amp;gt; authors, while subversion logs can only record the committer)
&lt;/div&gt;Thumbs up, I missed this point. But I too, when I commit a fix, cite the 
&lt;br&gt;original author.
&lt;br&gt;&lt;br&gt;Riccardo
&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;Gnustep-dev mailing list
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26535694&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;Gnustep-dev@...&lt;/a&gt;
&lt;br&gt;&lt;a href=&quot;http://lists.gnu.org/mailman/listinfo/gnustep-dev&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.gnu.org/mailman/listinfo/gnustep-dev&lt;/a&gt;&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-flame--NEWS-file-is-useless-tp26520114p26535694.html" />
</entry>

</feed>
