[Gnustep-cvs] GNUstep Testfarm Results
Test results for GNUstep as of Wed Jul 13 06:34:12 EDT 2005 If a particular system failed compilation, the logs for that system will be placed at ftp://ftp.gnustep.org/pub/testfarm If you would like to add your machine to this list, set up a cron job (make sure you set up your PATH and other environment variables correctly) to run the Startup/scripts/test-gnustep script (see the script comments for more info). Success Compile i386-unknown-netbsdelf2.0.2 Wed Jul 13 03:58:23 CEST 2005 Success Compile powerpc-apple-darwin7.9.0 Wed Jul 13 03:23:51 MDT 2005 Success Compile sparc-sun-solaris2.7 Wed Jul 13 02:08:32 EDT 2005
[Gnustep-cvs] gnustep/dev-apps/Gorm ChangeLog GormCore/GormCl...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Gregory John Casamento <[EMAIL PROTECTED]> 05/07/13 12:58:04 Modified files: dev-apps/Gorm : ChangeLog dev-apps/Gorm/GormCore: GormClassEditor.m Log message: Corrected problem selecting NSObject. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/ChangeLog.diff?tr1=1.707&tr2=1.708&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/GormCore/GormClassEditor.m.diff?tr1=1.16&tr2=1.17&r1=text&r2=text
[Gnustep-cvs] gnustep/core/base ChangeLog Source/NSBundle.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Nicola Pero <[EMAIL PROTECTED]> 05/07/13 14:51:57 Modified files: core/base : ChangeLog core/base/Source: NSBundle.m Log message: Disabled versioning support for framework on Mingw (win32) CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/ChangeLog.diff?tr1=1.2562&tr2=1.2563&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Source/NSBundle.m.diff?tr1=1.143&tr2=1.144&r1=text&r2=text
[Gnustep-cvs] gnustep/core/make ChangeLog target.make
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Nicola Pero <[EMAIL PROTECTED]> 05/07/13 14:56:18 Modified files: core/make : ChangeLog target.make Log message: Added commands to build list of class names in a framework on Mingw (win32) CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/ChangeLog.diff?tr1=1.1154&tr2=1.1155&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/target.make.diff?tr1=1.169&tr2=1.170&r1=text&r2=text
[Gnustep-cvs] gnustep/core/make/Instance library.make
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Nicola Pero <[EMAIL PROTECTED]> 05/07/13 14:57:00 Modified files: core/make/Instance: library.make Log message: Fixed typo in comment CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/Instance/library.make.diff?tr1=1.31&tr2=1.32&r1=text&r2=text
Re: GUI/back changes in CVS
Fred Kiefer wrote: > Fred Kiefer wrote: >>What I was planning to do was add a simple (and of course slow) pattern >>drawing mechanism for the gsc classes and perhaps overwrite this with a >>faster one for the xlib backend. [snip] > [colour_pattern compositeToPoint: NSMakePoint(x, y) >operation: NSCompositeSourceOver]; I think this should be -drawToPoint:fromRect:operation:fraction: in order to handle transformations correctly; would have to check the PLRM to be sure about pattern semantics, though. [snip] > All of this works fine. Of course EOFill is currently not supported, but > simple to do (would require a call to DPSeoclip instead of DPSclip). And > the clipping is what stops me from merging this code into CVS. As I need > to change the clipping, and restore it afterwards, I could either > implement this separately for each backend and not share any code or > implement that clipPath method, used in the current implementation, for > all backends. As this method is also not that easy, I could fake it by > storing the current clip path in another slot of the GState (and keep > the EO state within this path, as we need that as well when reseting the > old clip). But perhaps somebody out there has a better idea for this? PSgsave/PSgrestore are the only portable methods for saving and restoring the clipping path, and I'd suggest using those. The current clipping path is the intersection of all paths passed to PSclip/PSeoclip (since the path was last reset, etc.; also, note that the filling rule merely specifies how the path to be intersected with the clipping path should be interpreted, the clipping path doesn't have any such property), so for a backend to be able to return the clipping path as an actual path, it would have to be able to compute arbitrary bezier curve intersections, and that's a nasty problem. - Alexander Malmberg ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/back changes in CVS
Hi Alexander, thank you for that feedback and more important: Great to have you back here! Your comment on PSGsave and PSGrestore is correct. The problem here is that we only know in the GState that we are going to draw a pattern image, while the PSGsave and PSGrestore operations should be applied on the context level. Not sure, if we should decorate every fill operation with a save/restore combination. You are propably correct about the drawToPoint call. Its just that this fails on xlib sometimes that I didn't want to use that method, Cheers Fred Alexander Malmberg wrote: > Fred Kiefer wrote: >>Fred Kiefer wrote: >>>What I was planning to do was add a simple (and of course slow) pattern >>>drawing mechanism for the gsc classes and perhaps overwrite this with a >>>faster one for the xlib backend. > [snip] >>[colour_pattern compositeToPoint: NSMakePoint(x, y) >> operation: NSCompositeSourceOver]; > > I think this should be -drawToPoint:fromRect:operation:fraction: in > order to handle transformations correctly; would have to check the PLRM > to be sure about pattern semantics, though. > > [snip] >>All of this works fine. Of course EOFill is currently not supported, but >>simple to do (would require a call to DPSeoclip instead of DPSclip). And >>the clipping is what stops me from merging this code into CVS. As I need >>to change the clipping, and restore it afterwards, I could either >>implement this separately for each backend and not share any code or >>implement that clipPath method, used in the current implementation, for >>all backends. As this method is also not that easy, I could fake it by >>storing the current clip path in another slot of the GState (and keep >>the EO state within this path, as we need that as well when reseting the >>old clip). But perhaps somebody out there has a better idea for this? > > PSgsave/PSgrestore are the only portable methods for saving and > restoring the clipping path, and I'd suggest using those. The current > clipping path is the intersection of all paths passed to PSclip/PSeoclip > (since the path was last reset, etc.; also, note that the filling rule > merely specifies how the path to be intersected with the clipping path > should be interpreted, the clipping path doesn't have any such > property), so for a backend to be able to return the clipping path as an > actual path, it would have to be able to compute arbitrary bezier curve > intersections, and that's a nasty problem. > > - Alexander Malmberg > > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [patch #3268] Run Loops with WaitForMultipleObjects in Mingw
What is the status of this patch now?? I was reading the patch log on savana, and I have checked out the mingw-runloop branch from CVS. From my perspective as a windows user, it looks very good. I am now trying to merge this into the 1.10.3 code, so I can try it out. Is all that needs done is that some windows user like me says "works for me" then it will be merged to trunk? If so I will get right on testing it as best I can. - Original Message - From: "Luis Cabellos" <[EMAIL PROTECTED]> To: Sent: Friday, August 06, 2004 10:21 AM Subject: [patch #3268] Run Loops with WaitForMultipleObjects in Mingw Past weeks I had working in a Fix for [bug #7952] and now it is. For mingw32 I have change the select(...) call in -[pollUntil: milliseconds within: contexts] method with a call to win32 function MsgWaitForMultipleObjects(...). Also in classes that use AddEvent, instead of use a file descriptor now use a win32 Handle. I had refactoring the NSRunLoop.m file to put out some classes and had different version (the old, and de new of win32). All this changes affect only the mingw32 version of GNUstep, everything else remains equal. With the patch also I had attached a README file with a detailed explain of the changes. And that's is all. Luis Cabellos | Tragnarion Studios ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/dev-apps/Gorm ChangeLog Palettes/2Contr...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Gregory John Casamento <[EMAIL PROTECTED]> 05/07/14 02:48:07 Modified files: dev-apps/Gorm : ChangeLog dev-apps/Gorm/Palettes/2Controls: GormButtonEditor.m Log message: Corrected bug#13756. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/ChangeLog.diff?tr1=1.708&tr2=1.709&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/Palettes/2Controls/GormButtonEditor.m.diff?tr1=1.7&tr2=1.8&r1=text&r2=text
[Gnustep-cvs] gnustep/dev-apps/Gorm ChangeLog GormCore/GormIn...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Gregory John Casamento <[EMAIL PROTECTED]> 05/07/14 04:01:33 Modified files: dev-apps/Gorm : ChangeLog dev-apps/Gorm/GormCore: GormInspectorsManager.m dev-apps/Gorm/Palettes/3Containers/GormNSTableColumnInspector.gorm: objects.gorm Log message: Removed old code, correction for crash. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/ChangeLog.diff?tr1=1.709&tr2=1.710&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/GormCore/GormInspectorsManager.m.diff?tr1=1.9&tr2=1.10&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/Palettes/3Containers/GormNSTableColumnInspector.gorm/objects.gorm.diff?tr1=1.8&tr2=1.9&r1=text&r2=text
Re: [patch #3268] Run Loops with WaitForMultipleObjects in Mingw
On 2005-07-13 22:15:47 +0100 Jeremy Bettis <[EMAIL PROTECTED]> wrote: What is the status of this patch now? See the patch log on savannah ... quick summary ... done. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
