chlor-develop — Chlor development

[chlor-develop] Chlor 0.0.5

[Chlor d. l. <chl...@li...>]

Hello,

i just released 0.0.5. Even though it does not contain earth shaking  
development, the last release 0.0.4 was in May 2006. That's far too  
much time past for an open source project.

Even though i am not satisfied about the shape of SVG import/export  
and import in general i think i will focus now on the gui and on the  
shape of the core classes soley. Everything else will follow  
naturally if the gui is usable.

Rgds,
Lenny

[chlor-develop] Chlor Blog

[Chlor d. l. <chl...@li...>]

Hi list,

i turned the Chlor homepage to a Chlor blog (http:// 
chlor.blogspot.com/).
I think the development mailinglist is not the right place to post  
thoughts and progresses. Everyone is invited.

Bye,
Lenny

[chlor-develop] Chlor's Doxygen Documentation is now online

[<chl...@li...>]

http://chlor.sourceforge.net/doxygen/annotated.html

[chlor-develop] Release early, release often

[<chl...@li...>]

Hi gang,

the currrent Chlor version was released 4 months ago. That's why i  
released 0.0.4 today.

Bye,
Lenny

[chlor-develop] Chlor Gimp export now functional

[<chl...@li...>]

I am very happy to announce that Chlor can now export directly to the  
Gimp format (XCF):
http://sourceforge.net/project/screenshots.php?group_id=133124

Looking at the Seashore code helped _a_lot_. I mentioned Mark Pazolli  
as copyright co-owner in the export code even though i did not copy 1:1.

I think being able to export from a vector format to a pixel format  
without losing the layers is very important. One step closer for  
Seashore/Chlor becoming a team like Photoshop/Illustrator. ;)

Bye,
Lenny

Re: [chlor-develop] Re: [Chlor-commits] SF.net SVN: chlor: [360] trunk/src

[<chl...@li...>]

Hi,

if I remember correctly, the responder-chain looks like this: View ->  
Controller -> Tool. Thus, mouseDragged: of ChlorMainView gets called  
and passes the event on via the call of its super-method.

Regards,
	Florian

> Hi Flo,
>
> sorry, i justed quickly browsed your changes and did not spot the  
> activate/deactivate stuff. It seemed to me that the relevant stuff  
> was only implemented in the ChlorMainView. Don't drink and code.
>
> Hm... we handle mouseDragged: in CGrabHandTool somehow that  
> ChlorMainView's isn't called at all?
>
> Bye,
> Lenny
>
>> Hi,
>>
>> I would very much like to do so, but unfortunately don't get what  
>> you're heading for. NSView does not provide any means to switch  
>> autoscrolling on and off, therefore I added this functionality to  
>> ChlorMainView. GrabHandTool switches then between autoscrolling  
>> and non-autoscrolling in the activate: and deactivate: methods.  
>> What else should be moved into these methods?
>>
>> Thanks for your patience,
>> 	Flo
>>
>> Am 09.04.2006 um 19:26 schrieb chlor-develop- 
>> ad...@li...:
>>
>>> Hi Flo,
>>>
>>> could you please modify your change? This solution is  
>>> unecessarily ugly. Please move this code to activate: and  
>>> deactiveate: in CGrabHandTool like it proposed it.
>>>
>>> Thanks for your effort,
>>> Lenny
>>>
>>> Am 09.04.2006 um 12:32 schrieb chlor-commits- 
>>> ad...@li...:
>>>
>>>> Revision: 360
>>>> Author:   floi
>>>> Date:     2006-04-09 03:31:54 -0700 (Sun, 09 Apr 2006)
>>>> ViewCVS:  http://svn.sourceforge.net/chlor/?rev=360&view=rev
>>>>
>>>> Log Message:
>>>> -----------
>>>> Made autoscrolling mode dependent in ChlorMainView.
>>>> This facility is now used by GrabHandTool to switch it off  
>>>> during its operation.
>>>>
>>>> Modified Paths:
>>>> --------------
>>>>     trunk/src/ChlorMainView.h
>>>>     trunk/src/ChlorMainView.m
>>>>     trunk/src/tools/CGrabHandTool.m
>>>>     trunk/src/tools/CTool.h
>>>> Modified: trunk/src/ChlorMainView.h
>>>> ===================================================================
>>>> --- trunk/src/ChlorMainView.h	2006-04-08 15:46:13 UTC (rev 359)
>>>> +++ trunk/src/ChlorMainView.h	2006-04-09 10:31:54 UTC (rev 360)
>>>> @@ -38,10 +38,16 @@
>>>>  	 * The selection renderer.
>>>>  	 */
>>>>  	CSelectionRenderer* m_selectionRenderer;
>>>> +	
>>>> +	/**
>>>> +	 * The autoscoll mode.
>>>> +	 */
>>>> +	BOOL shouldAutoscroll;
>>>>  }
>>>>
>>>>  //- (NSSize) contentSize;
>>>>  - (void) setMainViewController: (ChlorMainController*)  
>>>> theController;
>>>>  - (ChlorMainController*) mainController;
>>>> +- (void) setAutoscrollMode: (BOOL) mode;
>>>>
>>>>  @end
>>>>
>>>> Modified: trunk/src/ChlorMainView.m
>>>> ===================================================================
>>>> --- trunk/src/ChlorMainView.m	2006-04-08 15:46:13 UTC (rev 359)
>>>> +++ trunk/src/ChlorMainView.m	2006-04-09 10:31:54 UTC (rev 360)
>>>> @@ -34,6 +34,7 @@
>>>>  	{
>>>>  		m_renderer = [[CRenderer alloc] init];
>>>>  		m_selectionRenderer = [[CSelectionRenderer alloc] init];
>>>> +		[self setAutoscrollMode: YES];
>>>>  	}
>>>>
>>>>  	return self;
>>>> @@ -92,11 +93,20 @@
>>>>  	return YES;
>>>>  }
>>>>
>>>> +- (void) setAutoscrollMode: (BOOL) mode
>>>> +{
>>>> +	// Sets the autoscroll mode.
>>>> +	shouldAutoscroll = mode;
>>>> +}
>>>> +
>>>> +
>>>>  - (void) mouseDragged: (NSEvent*) theEvent
>>>>  {
>>>>  	// Scroll the view accordingly if the mouse is dragged
>>>>  	// outside the visible area.
>>>> -	[self autoscroll: theEvent];
>>>> +	if( shouldAutoscroll ) {
>>>> +		[self autoscroll: theEvent];
>>>> +	}
>>>>
>>>>  	[super mouseDragged: theEvent];
>>>>  }
>>>>
>>>> Modified: trunk/src/tools/CGrabHandTool.m
>>>> ===================================================================
>>>> --- trunk/src/tools/CGrabHandTool.m	2006-04-08 15:46:13 UTC (rev  
>>>> 359)
>>>> +++ trunk/src/tools/CGrabHandTool.m	2006-04-09 10:31:54 UTC (rev  
>>>> 360)
>>>> @@ -58,4 +58,18 @@
>>>>  	[[m_view superview] scrollPoint: newPosition];
>>>>  }
>>>>
>>>> +- (void) activate
>>>> +{
>>>> +	// Autoscrolling interfers with our scrolling activities - we  
>>>> switch it
>>>> +	// therefore off.
>>>> +	[m_view setAutoscrollMode: NO];
>>>> +}
>>>> +
>>>> +- (void) deactivate
>>>> +{
>>>> +	// We're done, so we can switch autoscrolling back on again.
>>>> +	[m_view setAutoscrollMode: YES];
>>>> +}
>>>> +
>>>> +
>>>>  @end
>>>>
>>>> Modified: trunk/src/tools/CTool.h
>>>> ===================================================================
>>>> --- trunk/src/tools/CTool.h	2006-04-08 15:46:13 UTC (rev 359)
>>>> +++ trunk/src/tools/CTool.h	2006-04-09 10:31:54 UTC (rev 360)
>>>> @@ -18,8 +18,9 @@
>>>>   */
>>>>
>>>>  #import <Cocoa/Cocoa.h>
>>>> +
>>>> +#import "ChlorMainView.h"
>>>>  @class ChlorDocument;
>>>> -@class ChlorMainView;
>>>>
>>>>  @interface CTool : NSResponder
>>>>  {
>>>>
>>>>
>>>> This was sent by the SourceForge.net collaborative development  
>>>> platform, the world's largest Open Source development site.
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by xPML, a groundbreaking  
>>>> scripting language
>>>> that extends applications into web and mobile media. Attend the  
>>>> live webcast
>>>> and join the prime developer group breaking into this new coding  
>>>> territory!
>>>> http://sel.as-us.falkag.net/sel? 
>>>> cmd=lnk&kid=110944&bid=241720&dat=121642
>>>> _______________________________________________
>>>> Chlor-commits mailing list
>>>> Chl...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/chlor-commits
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by xPML, a groundbreaking  
>>> scripting language
>>> that extends applications into web and mobile media. Attend the  
>>> live webcast
>>> and join the prime developer group breaking into this new coding  
>>> territory!
>>> http://sel.as-us.falkag.net/sel? 
>>> cmd=lnk&kid=110944&bid=241720&dat=121642
>>> _______________________________________________
>>> chlor-develop mailing list
>>> chl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/chlor-develop
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
>> language
>> that extends applications into web and mobile media. Attend the  
>> live webcast
>> and join the prime developer group breaking into this new coding  
>> territory!
>> http://sel.as-us.falkag.net/sel? 
>> cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> chlor-develop mailing list
>> chl...@li...
>> https://lists.sourceforge.net/lists/listinfo/chlor-develop
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> chlor-develop mailing list
> chl...@li...
> https://lists.sourceforge.net/lists/listinfo/chlor-develop
>

Re: [chlor-develop] Re: [Chlor-commits] SF.net SVN: chlor: [360] trunk/src

[<chl...@li...>]

Hi Flo,

sorry, i justed quickly browsed your changes and did not spot the  
activate/deactivate stuff. It seemed to me that the relevant stuff  
was only implemented in the ChlorMainView. Don't drink and code.

Hm... we handle mouseDragged: in CGrabHandTool somehow that  
ChlorMainView's isn't called at all?

Bye,
Lenny

> Hi,
>
> I would very much like to do so, but unfortunately don't get what  
> you're heading for. NSView does not provide any means to switch  
> autoscrolling on and off, therefore I added this functionality to  
> ChlorMainView. GrabHandTool switches then between autoscrolling and  
> non-autoscrolling in the activate: and deactivate: methods. What  
> else should be moved into these methods?
>
> Thanks for your patience,
> 	Flo
>
> Am 09.04.2006 um 19:26 schrieb chlor-develop- 
> ad...@li...:
>
>> Hi Flo,
>>
>> could you please modify your change? This solution is unecessarily  
>> ugly. Please move this code to activate: and deactiveate: in  
>> CGrabHandTool like it proposed it.
>>
>> Thanks for your effort,
>> Lenny
>>
>> Am 09.04.2006 um 12:32 schrieb chlor-commits- 
>> ad...@li...:
>>
>>> Revision: 360
>>> Author:   floi
>>> Date:     2006-04-09 03:31:54 -0700 (Sun, 09 Apr 2006)
>>> ViewCVS:  http://svn.sourceforge.net/chlor/?rev=360&view=rev
>>>
>>> Log Message:
>>> -----------
>>> Made autoscrolling mode dependent in ChlorMainView.
>>> This facility is now used by GrabHandTool to switch it off during  
>>> its operation.
>>>
>>> Modified Paths:
>>> --------------
>>>     trunk/src/ChlorMainView.h
>>>     trunk/src/ChlorMainView.m
>>>     trunk/src/tools/CGrabHandTool.m
>>>     trunk/src/tools/CTool.h
>>> Modified: trunk/src/ChlorMainView.h
>>> ===================================================================
>>> --- trunk/src/ChlorMainView.h	2006-04-08 15:46:13 UTC (rev 359)
>>> +++ trunk/src/ChlorMainView.h	2006-04-09 10:31:54 UTC (rev 360)
>>> @@ -38,10 +38,16 @@
>>>  	 * The selection renderer.
>>>  	 */
>>>  	CSelectionRenderer* m_selectionRenderer;
>>> +	
>>> +	/**
>>> +	 * The autoscoll mode.
>>> +	 */
>>> +	BOOL shouldAutoscroll;
>>>  }
>>>
>>>  //- (NSSize) contentSize;
>>>  - (void) setMainViewController: (ChlorMainController*)  
>>> theController;
>>>  - (ChlorMainController*) mainController;
>>> +- (void) setAutoscrollMode: (BOOL) mode;
>>>
>>>  @end
>>>
>>> Modified: trunk/src/ChlorMainView.m
>>> ===================================================================
>>> --- trunk/src/ChlorMainView.m	2006-04-08 15:46:13 UTC (rev 359)
>>> +++ trunk/src/ChlorMainView.m	2006-04-09 10:31:54 UTC (rev 360)
>>> @@ -34,6 +34,7 @@
>>>  	{
>>>  		m_renderer = [[CRenderer alloc] init];
>>>  		m_selectionRenderer = [[CSelectionRenderer alloc] init];
>>> +		[self setAutoscrollMode: YES];
>>>  	}
>>>
>>>  	return self;
>>> @@ -92,11 +93,20 @@
>>>  	return YES;
>>>  }
>>>
>>> +- (void) setAutoscrollMode: (BOOL) mode
>>> +{
>>> +	// Sets the autoscroll mode.
>>> +	shouldAutoscroll = mode;
>>> +}
>>> +
>>> +
>>>  - (void) mouseDragged: (NSEvent*) theEvent
>>>  {
>>>  	// Scroll the view accordingly if the mouse is dragged
>>>  	// outside the visible area.
>>> -	[self autoscroll: theEvent];
>>> +	if( shouldAutoscroll ) {
>>> +		[self autoscroll: theEvent];
>>> +	}
>>>
>>>  	[super mouseDragged: theEvent];
>>>  }
>>>
>>> Modified: trunk/src/tools/CGrabHandTool.m
>>> ===================================================================
>>> --- trunk/src/tools/CGrabHandTool.m	2006-04-08 15:46:13 UTC (rev  
>>> 359)
>>> +++ trunk/src/tools/CGrabHandTool.m	2006-04-09 10:31:54 UTC (rev  
>>> 360)
>>> @@ -58,4 +58,18 @@
>>>  	[[m_view superview] scrollPoint: newPosition];
>>>  }
>>>
>>> +- (void) activate
>>> +{
>>> +	// Autoscrolling interfers with our scrolling activities - we  
>>> switch it
>>> +	// therefore off.
>>> +	[m_view setAutoscrollMode: NO];
>>> +}
>>> +
>>> +- (void) deactivate
>>> +{
>>> +	// We're done, so we can switch autoscrolling back on again.
>>> +	[m_view setAutoscrollMode: YES];
>>> +}
>>> +
>>> +
>>>  @end
>>>
>>> Modified: trunk/src/tools/CTool.h
>>> ===================================================================
>>> --- trunk/src/tools/CTool.h	2006-04-08 15:46:13 UTC (rev 359)
>>> +++ trunk/src/tools/CTool.h	2006-04-09 10:31:54 UTC (rev 360)
>>> @@ -18,8 +18,9 @@
>>>   */
>>>
>>>  #import <Cocoa/Cocoa.h>
>>> +
>>> +#import "ChlorMainView.h"
>>>  @class ChlorDocument;
>>> -@class ChlorMainView;
>>>
>>>  @interface CTool : NSResponder
>>>  {
>>>
>>>
>>> This was sent by the SourceForge.net collaborative development  
>>> platform, the world's largest Open Source development site.
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by xPML, a groundbreaking  
>>> scripting language
>>> that extends applications into web and mobile media. Attend the  
>>> live webcast
>>> and join the prime developer group breaking into this new coding  
>>> territory!
>>> http://sel.as-us.falkag.net/sel? 
>>> cmd=lnk&kid=110944&bid=241720&dat=121642
>>> _______________________________________________
>>> Chlor-commits mailing list
>>> Chl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/chlor-commits
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
>> language
>> that extends applications into web and mobile media. Attend the  
>> live webcast
>> and join the prime developer group breaking into this new coding  
>> territory!
>> http://sel.as-us.falkag.net/sel? 
>> cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> chlor-develop mailing list
>> chl...@li...
>> https://lists.sourceforge.net/lists/listinfo/chlor-develop
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> chlor-develop mailing list
> chl...@li...
> https://lists.sourceforge.net/lists/listinfo/chlor-develop

Re: [chlor-develop] Re: [Chlor-commits] SF.net SVN: chlor: [360] trunk/src

[<chl...@li...>]

Hi,

I would very much like to do so, but unfortunately don't get what  
you're heading for. NSView does not provide any means to switch  
autoscrolling on and off, therefore I added this functionality to  
ChlorMainView. GrabHandTool switches then between autoscrolling and  
non-autoscrolling in the activate: and deactivate: methods. What else  
should be moved into these methods?

Thanks for your patience,
	Flo

Am 09.04.2006 um 19:26 schrieb chlor-develop- 
ad...@li...:

> Hi Flo,
>
> could you please modify your change? This solution is unecessarily  
> ugly. Please move this code to activate: and deactiveate: in  
> CGrabHandTool like it proposed it.
>
> Thanks for your effort,
> Lenny
>
> Am 09.04.2006 um 12:32 schrieb chlor-commits- 
> ad...@li...:
>
>> Revision: 360
>> Author:   floi
>> Date:     2006-04-09 03:31:54 -0700 (Sun, 09 Apr 2006)
>> ViewCVS:  http://svn.sourceforge.net/chlor/?rev=360&view=rev
>>
>> Log Message:
>> -----------
>> Made autoscrolling mode dependent in ChlorMainView.
>> This facility is now used by GrabHandTool to switch it off during  
>> its operation.
>>
>> Modified Paths:
>> --------------
>>     trunk/src/ChlorMainView.h
>>     trunk/src/ChlorMainView.m
>>     trunk/src/tools/CGrabHandTool.m
>>     trunk/src/tools/CTool.h
>> Modified: trunk/src/ChlorMainView.h
>> ===================================================================
>> --- trunk/src/ChlorMainView.h	2006-04-08 15:46:13 UTC (rev 359)
>> +++ trunk/src/ChlorMainView.h	2006-04-09 10:31:54 UTC (rev 360)
>> @@ -38,10 +38,16 @@
>>  	 * The selection renderer.
>>  	 */
>>  	CSelectionRenderer* m_selectionRenderer;
>> +	
>> +	/**
>> +	 * The autoscoll mode.
>> +	 */
>> +	BOOL shouldAutoscroll;
>>  }
>>
>>  //- (NSSize) contentSize;
>>  - (void) setMainViewController: (ChlorMainController*)  
>> theController;
>>  - (ChlorMainController*) mainController;
>> +- (void) setAutoscrollMode: (BOOL) mode;
>>
>>  @end
>>
>> Modified: trunk/src/ChlorMainView.m
>> ===================================================================
>> --- trunk/src/ChlorMainView.m	2006-04-08 15:46:13 UTC (rev 359)
>> +++ trunk/src/ChlorMainView.m	2006-04-09 10:31:54 UTC (rev 360)
>> @@ -34,6 +34,7 @@
>>  	{
>>  		m_renderer = [[CRenderer alloc] init];
>>  		m_selectionRenderer = [[CSelectionRenderer alloc] init];
>> +		[self setAutoscrollMode: YES];
>>  	}
>>
>>  	return self;
>> @@ -92,11 +93,20 @@
>>  	return YES;
>>  }
>>
>> +- (void) setAutoscrollMode: (BOOL) mode
>> +{
>> +	// Sets the autoscroll mode.
>> +	shouldAutoscroll = mode;
>> +}
>> +
>> +
>>  - (void) mouseDragged: (NSEvent*) theEvent
>>  {
>>  	// Scroll the view accordingly if the mouse is dragged
>>  	// outside the visible area.
>> -	[self autoscroll: theEvent];
>> +	if( shouldAutoscroll ) {
>> +		[self autoscroll: theEvent];
>> +	}
>>
>>  	[super mouseDragged: theEvent];
>>  }
>>
>> Modified: trunk/src/tools/CGrabHandTool.m
>> ===================================================================
>> --- trunk/src/tools/CGrabHandTool.m	2006-04-08 15:46:13 UTC (rev 359)
>> +++ trunk/src/tools/CGrabHandTool.m	2006-04-09 10:31:54 UTC (rev 360)
>> @@ -58,4 +58,18 @@
>>  	[[m_view superview] scrollPoint: newPosition];
>>  }
>>
>> +- (void) activate
>> +{
>> +	// Autoscrolling interfers with our scrolling activities - we  
>> switch it
>> +	// therefore off.
>> +	[m_view setAutoscrollMode: NO];
>> +}
>> +
>> +- (void) deactivate
>> +{
>> +	// We're done, so we can switch autoscrolling back on again.
>> +	[m_view setAutoscrollMode: YES];
>> +}
>> +
>> +
>>  @end
>>
>> Modified: trunk/src/tools/CTool.h
>> ===================================================================
>> --- trunk/src/tools/CTool.h	2006-04-08 15:46:13 UTC (rev 359)
>> +++ trunk/src/tools/CTool.h	2006-04-09 10:31:54 UTC (rev 360)
>> @@ -18,8 +18,9 @@
>>   */
>>
>>  #import <Cocoa/Cocoa.h>
>> +
>> +#import "ChlorMainView.h"
>>  @class ChlorDocument;
>> -@class ChlorMainView;
>>
>>  @interface CTool : NSResponder
>>  {
>>
>>
>> This was sent by the SourceForge.net collaborative development  
>> platform, the world's largest Open Source development site.
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
>> language
>> that extends applications into web and mobile media. Attend the  
>> live webcast
>> and join the prime developer group breaking into this new coding  
>> territory!
>> http://sel.as-us.falkag.net/sel? 
>> cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Chlor-commits mailing list
>> Chl...@li...
>> https://lists.sourceforge.net/lists/listinfo/chlor-commits
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> chlor-develop mailing list
> chl...@li...
> https://lists.sourceforge.net/lists/listinfo/chlor-develop
>

[chlor-develop] Re: [Chlor-commits] SF.net SVN: chlor: [360] trunk/src

[<chl...@li...>]

Hi Flo,

could you please modify your change? This solution is unecessarily  
ugly. Please move this code to activate: and deactiveate: in  
CGrabHandTool like it proposed it.

Thanks for your effort,
Lenny

Am 09.04.2006 um 12:32 schrieb chlor-commits- 
ad...@li...:

> Revision: 360
> Author:   floi
> Date:     2006-04-09 03:31:54 -0700 (Sun, 09 Apr 2006)
> ViewCVS:  http://svn.sourceforge.net/chlor/?rev=360&view=rev
>
> Log Message:
> -----------
> Made autoscrolling mode dependent in ChlorMainView.
> This facility is now used by GrabHandTool to switch it off during  
> its operation.
>
> Modified Paths:
> --------------
>     trunk/src/ChlorMainView.h
>     trunk/src/ChlorMainView.m
>     trunk/src/tools/CGrabHandTool.m
>     trunk/src/tools/CTool.h
> Modified: trunk/src/ChlorMainView.h
> ===================================================================
> --- trunk/src/ChlorMainView.h	2006-04-08 15:46:13 UTC (rev 359)
> +++ trunk/src/ChlorMainView.h	2006-04-09 10:31:54 UTC (rev 360)
> @@ -38,10 +38,16 @@
>  	 * The selection renderer.
>  	 */
>  	CSelectionRenderer* m_selectionRenderer;
> +	
> +	/**
> +	 * The autoscoll mode.
> +	 */
> +	BOOL shouldAutoscroll;
>  }
>
>  //- (NSSize) contentSize;
>  - (void) setMainViewController: (ChlorMainController*) theController;
>  - (ChlorMainController*) mainController;
> +- (void) setAutoscrollMode: (BOOL) mode;
>
>  @end
>
> Modified: trunk/src/ChlorMainView.m
> ===================================================================
> --- trunk/src/ChlorMainView.m	2006-04-08 15:46:13 UTC (rev 359)
> +++ trunk/src/ChlorMainView.m	2006-04-09 10:31:54 UTC (rev 360)
> @@ -34,6 +34,7 @@
>  	{
>  		m_renderer = [[CRenderer alloc] init];
>  		m_selectionRenderer = [[CSelectionRenderer alloc] init];
> +		[self setAutoscrollMode: YES];
>  	}
>
>  	return self;
> @@ -92,11 +93,20 @@
>  	return YES;
>  }
>
> +- (void) setAutoscrollMode: (BOOL) mode
> +{
> +	// Sets the autoscroll mode.
> +	shouldAutoscroll = mode;
> +}
> +
> +
>  - (void) mouseDragged: (NSEvent*) theEvent
>  {
>  	// Scroll the view accordingly if the mouse is dragged
>  	// outside the visible area.
> -	[self autoscroll: theEvent];
> +	if( shouldAutoscroll ) {
> +		[self autoscroll: theEvent];
> +	}
>
>  	[super mouseDragged: theEvent];
>  }
>
> Modified: trunk/src/tools/CGrabHandTool.m
> ===================================================================
> --- trunk/src/tools/CGrabHandTool.m	2006-04-08 15:46:13 UTC (rev 359)
> +++ trunk/src/tools/CGrabHandTool.m	2006-04-09 10:31:54 UTC (rev 360)
> @@ -58,4 +58,18 @@
>  	[[m_view superview] scrollPoint: newPosition];
>  }
>
> +- (void) activate
> +{
> +	// Autoscrolling interfers with our scrolling activities - we  
> switch it
> +	// therefore off.
> +	[m_view setAutoscrollMode: NO];
> +}
> +
> +- (void) deactivate
> +{
> +	// We're done, so we can switch autoscrolling back on again.
> +	[m_view setAutoscrollMode: YES];
> +}
> +
> +
>  @end
>
> Modified: trunk/src/tools/CTool.h
> ===================================================================
> --- trunk/src/tools/CTool.h	2006-04-08 15:46:13 UTC (rev 359)
> +++ trunk/src/tools/CTool.h	2006-04-09 10:31:54 UTC (rev 360)
> @@ -18,8 +18,9 @@
>   */
>
>  #import <Cocoa/Cocoa.h>
> +
> +#import "ChlorMainView.h"
>  @class ChlorDocument;
> -@class ChlorMainView;
>
>  @interface CTool : NSResponder
>  {
>
>
> This was sent by the SourceForge.net collaborative development  
> platform, the world's largest Open Source development site.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Chlor-commits mailing list
> Chl...@li...
> https://lists.sourceforge.net/lists/listinfo/chlor-commits

Re: [chlor-develop] GrabHandTool and autoscrolling

[<chl...@li...>]

> Autoscrolling happens via the mouseDragged method of ChlorMainView  
> by an unconditional call of [self autoscroll: theEvent]. We can  
> make that conditional, but then ChlorMainView would be stateful  
> (i.e. autoscrolling could be switched on and off).

Is this a problem? Autoscrolling is enable to allow the active tool  
behave proberly when one drag the mouse "outside" of the view. If  
this is not wanted we should disable this for the grabhand. We can do  
this in CGrabhandTool's activate:/deactivate: methods. Or am i  
missing something?

Bye,
Lenny

Re: [chlor-develop] Delete-Operation and Z-Ordering

[<chl...@li...>]

Am 06.04.2006 um 23:05 schrieb chlor-develop- 
ad...@li...:

> Alas, using the add operation as the inverse of the remove  
> operation on a mutable array isn't correct, as we would loose the z- 
> ordering during drawing (e.g. removing the first drawn object,  
> hitting undo and adding it at the end of the array makes it the  
> last object being drawn and thus the topmost, right?).

i think insertObject:atIndex: is the way to go?

> Okay, how in general should we go for z-ordering? Shall we use the  
> array position within CLayer implicitly as the z-order? Shall the z- 
> order work across layers? Shall every CObject carry its own z-order  
> then as a third coordinate?

The CObjects shouldn't be bothered with that. The according visitor  
could and should handle this. If it is asked to "delete" objects it  
should do the following:
1) go and find the CGroup which is owning the objects to delete
2) For each to object/group find out the index needed to readd it
3) Keep track of the to be removed objects (don't destroy the  
objects, just remove them form the groups)
4) Register the according undo operation with the objects from step  
3) and the indices from step 2)

Bye,
Lenny

Re: [chlor-develop] GrabHandTool and autoscrolling

[<chl...@li...>]

Hi,

>> just updated the GrabHandTool to make it behave a bit better.  
>> However, when moving outside the drawing area, autoscroll routine  
>> of ChlorMainView kicks in and results into a "bumpy" appearance.
>
> Noticed that, thanks. It behaves much better now.
>
>> Anyhow, I'm guessing that it would help if we could turn off  
>> autoscrolling when the GrabHandTool is active. However, I neither  
>> want to make ChlorMainView aware of the active tool, nor make it  
>> stateful - any better proposals?
>
> If autoscroll is really the problem, why not unset/set it in  
> CGrabhandTool's activate:/deactivate: methods (see CTool)? Or what  
> do you mean with "stateful"?

Autoscrolling happens via the mouseDragged method of ChlorMainView by  
an unconditional call of [self autoscroll: theEvent]. We can make  
that conditional, but then ChlorMainView would be stateful (i.e.  
autoscrolling could be switched on and off).

BTW, I just noticed something that the GrabHandTool behaves also  
interesting when the window is being moved around ...

Regrads,
	Florian

[chlor-develop] Delete-Operation and Z-Ordering

[<chl...@li...>]

Hi,

I was quickly thinking on implementing the delete operation and the  
consequences of making this operation undo-able.

Alas, using the add operation as the inverse of the remove operation  
on a mutable array isn't correct, as we would loose the z-ordering  
during drawing (e.g. removing the first drawn object, hitting undo  
and adding it at the end of the array makes it the last object being  
drawn and thus the topmost, right?).

Okay, how in general should we go for z-ordering? Shall we use the  
array position within CLayer implicitly as the z-order? Shall the z- 
order work across layers? Shall every CObject carry its own z-order  
then as a third coordinate?

Any opinions for this sort-of-requirements-elicitation?

Regards,
	Florian

Re: [chlor-develop] GrabHandTool and autoscrolling

[<chl...@li...>]

Hi,

> just updated the GrabHandTool to make it behave a bit better.  
> However, when moving outside the drawing area, autoscroll routine  
> of ChlorMainView kicks in and results into a "bumpy" appearance.

Noticed that, thanks. It behaves much better now.

> Anyhow, I'm guessing that it would help if we could turn off  
> autoscrolling when the GrabHandTool is active. However, I neither  
> want to make ChlorMainView aware of the active tool, nor make it  
> stateful - any better proposals?

If autoscroll is really the problem, why not unset/set it in  
CGrabhandTool's activate:/deactivate: methods (see CTool)? Or what do  
you mean with "stateful"?

Bye,
Lenny

[chlor-develop] GrabHandTool and autoscrolling

[<chl...@li...>]

Hi group,

just updated the GrabHandTool to make it behave a bit better.  
However, when moving outside the drawing area, autoscroll routine of  
ChlorMainView kicks in and results into a "bumpy" appearance.

Try also to move the window around a bit, when the GrabHandTool is  
active - the behavior is also a bit strange.

Anyhow, I'm guessing that it would help if we could turn off  
autoscrolling when the GrabHandTool is active. However, I neither  
want to make ChlorMainView aware of the active tool, nor make it  
stateful - any better proposals?

Kind regards,
	Florian

Re: [chlor-develop] CSegment

[<chl...@li...>]

> This is the common performance-memory dilemma. As a bounding box is  
> often cheap to calculate, it's not always the best solution to keep  
> a cached boundary box. We should be able to make a choice per class  
> basis, this should not be fixed for all classes by using a base class.

I don't know how expensive exact bounding boxes are for (cubic)  
beziers to calculate. I'd say not too cheap. I don't know what you  
mean be base class. The bounding box stuff is only defined by a  
protocol.

> NSNotification,...). I don't have a problem leaving the objects  
> mutable, but in very controlled manner. Each object should be able  
> to keep its state consistent whatever changes are made. This is the  
> only way to keep the application in a consistent state as we move  
> on and the application grows.

Agreed. We should find a compromise between data exposing and an  
excessive API. We're not too far away from that.

Bye,
Lenny

Re: [chlor-develop] CSegment

[<chl...@li...>]

>> and consistent. A bounding box at node or segment level is  
>> absolutely not needed.
>
> I cannot agree. You need segment bounding boxes for intersection  
> tests. Have a look at CPath's containsX: Y: for example. Not to  
> mention Segment-segment intersections finding.

This is the common performance-memory dilemma. As a bounding box is  
often cheap to calculate, it's not always the best solution to keep a  
cached boundary box. We should be able to make a choice per class  
basis, this should not be fixed for all classes by using a base class.

>
>> In the third option, it is possible to change the content of a  
>> node or segment through moveTo or other methods. The parent path  
>> object listens on changes and changes its state accordingly. This  
>> complicates things heavily as each child node or segment needs to  
>> keep a reference to its parent.
>
> No, that's how it works currently without parent keeping, just by  
> means of NSNotification.
>
> I am quite satifised with the current shape of things. What we  
> should remove is exposing low level data structes like  
> NSMutableArrays. This includes making CPoint and CSegment read/only.
>
Exposing implementation details is asking for troubles. Not only do  
you make it hard to change afterwards, it makes it impossible to keep  
an object consistent at all times. You end up doing checks all over  
the place, while the checks belong to the object. This has nothing to  
do with choices, this is good or bad design.
The choice to make is to make objects mutable or immutable. If the  
objects are mutable, the parent needs to be notified (parent keeping,  
observer pattern or NSNotification,...). I don't have a problem  
leaving the objects mutable, but in very controlled manner. Each  
object should be able to keep its state consistent whatever changes  
are made. This is the only way to keep the application in a  
consistent state as we move on and the application grows.

Kind regards,
Marc

Re: [chlor-develop] CSegment

[<chl...@li...>]

> and consistent. A bounding box at node or segment level is  
> absolutely not needed.

I cannot agree. You need segment bounding boxes for intersection  
tests. Have a look at CPath's containsX: Y: for example. Not to  
mention Segment-segment intersections finding.

> In the third option, it is possible to change the content of a node  
> or segment through moveTo or other methods. The parent path object  
> listens on changes and changes its state accordingly. This  
> complicates things heavily as each child node or segment needs to  
> keep a reference to its parent.

No, that's how it works currently without parent keeping, just by  
means of NSNotification.

I am quite satifised with the current shape of things. What we should  
remove is exposing low level data structes like NSMutableArrays. This  
includes making CPoint and CSegment read/only.

Bye,
Lenny

Re: [chlor-develop] Undefined symbols

[<chl...@li...>]

> SenTestCase and STComposeString. Any got an idea?

Classes using SenTestCase need to be added to the ChlorTest target,  
not to the chlor target.

Kind regards,
Marc

Re: [chlor-develop] CSegment

[<chl...@li...>]

>> Fair enough, I 'll add it back.
>
> Thanks.
>
>> out of sync with the object. We need to decide if we will prevent  
>> changing internal objects (change certain objects to immutable  
>> objects) or create the boundingbox always dynamically.
>> I prefer the first, a little overhead at first but when carefully  
>> constructed, the easiest to work with. Creating a bounding box  
>> everytime when needed, might be too
>
> I prefer the first as well.
>
>> A third possibility where a parent is notified everytime a child  
>> object is modified, adds too much complexity and can fail very  
>> easily.
>
> I don't see the contradiction here. If a visitor modifies a  
> segment, the parental path needs to be informed. The segment can do  
> that, like we currently have it. We just should prevent direct  
> access to the NSMutableArrays.

In the first option, all changes are made through the Path instance.  
A node of the path is moved using a method of Path moveNode. Segments  
and nodes don't have any methods that can change their content. (no  
moveTo or wathever). Although this makes changing a path a bit more  
difficult, it helps to keep things simple and consistent. A bounding  
box at node or segment level is absolutely not needed.
In the third option, it is possible to change the content of a node  
or segment through moveTo or other methods. The parent path object  
listens on changes and changes its state accordingly. This  
complicates things heavily as each child node or segment needs to  
keep a reference to its parent.

Kind regards,
Marc

[chlor-develop] Undefined symbols

[<chl...@li...>]

SenTestCase and STComposeString. Any got an idea?

Lenny

Re: [chlor-develop] CSegment

[<chl...@li...>]

> change afterwards. We should be able to adapt the implementation of  
> objects easily while leaving the interface as is. Use inheritance  
> only for true inheritance (= implementation inheritance). To avoid  
> copy/paste use composition. In the case of the segment : it's not  
> because a segment contains nodes that it should be a container. In  
> fact the purpose of a segment is to represent a line or curve  
> segment, it's purpose is not to contain nodes. The kind of  
> container used by the segment

I agree. What i do not see yet is how you want to deal with bounding  
box stuff when you remove the CObject inheritance wihtout using copy/ 
paste.

Lenny

Re: [chlor-develop] CSegment

[<chl...@li...>]

> Fair enough, I 'll add it back.

Thanks.

> out of sync with the object. We need to decide if we will prevent  
> changing internal objects (change certain objects to immutable  
> objects) or create the boundingbox always dynamically.
> I prefer the first, a little overhead at first but when carefully  
> constructed, the easiest to work with. Creating a bounding box  
> everytime when needed, might be too

I prefer the first as well.

> A third possibility where a parent is notified everytime a child  
> object is modified, adds too much complexity and can fail very easily.

I don't see the contradiction here. If a visitor modifies a segment,  
the parental path needs to be informed. The segment can do that, like  
we currently have it. We just should prevent direct access to the  
NSMutableArrays.

Lenny

Re: [chlor-develop] Documentation

[<chl...@li...>]

> HeaderDoc comes along with the Developer Toolkit. Documentation can  
> be found here:
> ADC Home > Reference Library > Documentation > Tools > Darwin >  
> HeaderDoc User Guide

Actually it's no big differnce, but Doxygen seems more powerful to me  
and maybe more wide spread throughout the Open Source community. So  
i'd like to stick with that. Opinions?

Lenny

Re: [chlor-develop] CSegment

[<chl...@li...>]

chl...@li... wrote:

> Hi,
>
>>>> I moved CSegment to a separate file and refactored the class a  
>>>> bit.  I removed the inheritance on CGroup and replaced it by  
>>>> CObject for  the time being. The CGroup interface allowed any  
>>>> CObject to be  added to the CSegment, while only CNode objects  
>>>> should be allowed.  This easily leads to hidden bugs, which are  
>>>> hard to track down and  might stay hidden for a long time.
>>>
>>>
>>>
>>> I think we call isKindOfClass: everywhere to shut up warnings.   
>>> Anyway, why not.
>>
>>
>> This is exactly my point, an object should be able to keep itself  in 
>> a consistent state at all times. Runtime type verifications all  over 
>> the code not only clutter the code but cause much more trouble  than 
>> compile time type verifications. These refactorings will make  future 
>> modifications easier.
>
>
> I'm with you, using isKindOfClass: shows that your class hierarchy  
> offers room for improvement - but does this improvement always pay off?
> Anyhow, I'm wondering whether CSegment and CGroup should have a more  
> concrete parent than CObject or not. Both have an identical instance  
> variable, shouldn't that one, and the methods for manipulating it, be  
> moved to a common parent (probably named CContainer)?
>
There are plenty of container classes in the standard libraries (e.g. 
NSMutableArray) which serve the purpose well enough. Changing the code 
is a lot easier when you don't have this big inheritance trees. This big 
inheritance trees make development a little bit easier on first 
development, but make it very hard change afterwards. We should be able 
to adapt the implementation of objects easily while leaving the 
interface as is. Use inheritance only for true inheritance (= 
implementation inheritance). To avoid copy/paste use composition. In the 
case of the segment : it's not because a segment contains nodes that it 
should be a container. In fact the purpose of a segment is to represent 
a line or curve segment, it's purpose is not to contain nodes. The kind 
of container used by the segment can be changed overtime while leaving 
the interface as is. This kind of changements are local to the object 
and won't affect the rest of the applications. OO design is exactly this 
: the ability changing implementation details while leaving the 
interface as is.

Kind regards,
Marc