Re: [Gnustep-cvs] r32990 - in /libs/gui/trunk: ChangeLog Tests/gui/NSView/NSView_frame_bounds.m
On 06.05.2011 03:01, Eric Wasylishen wrote: Author: ericwa Date: Fri May 6 03:01:21 2011 New Revision: 32990 URL: http://svn.gna.org/viewcvs/gnustep?rev=32990&view=rev Log: * Tests/gui/NSView/NSView_frame_bounds.m: Add some more tests of setBoundsSize:. They are currently failing (but pass on OS X). Modified: libs/gui/trunk/ChangeLog libs/gui/trunk/Tests/gui/NSView/NSView_frame_bounds.m Great tests! Thank you for adding them and for fixing the copy/paste bug you made in convertPoint:toView: I think that the last remaining tests here a due to this comment in NSView setBoundsSize: (or rather the following test): // This may seem strange, but Cocoa only adjusts the bounds, when there // is no rotation I don't really remember why I came up with this but I am pretty sure there was a reason for that at the time. We must have had a test case that showed on Cocoa this stupid behaviour. Maybe Apple fixed their framework in the meantime, or there still is a special case that needs to be taken care of. I will check with my private test code to see what the original argument was here. And if I find something, I will make it part of the official test code. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: installing on Cygwin
On Sat, May 7, 2011 at 00:22, Truls Becken wrote: > > NTFS can do this on its own, without any cygwin hacks. On Vista and 7 > you have full support for symlinks, while on XP you have NTFS junction > points. > > http://en.wikipedia.org/wiki/NTFS_symbolic_link > I'd find it more tasteful to use Cygwin and ln -s, but no matter what is used, the idea is to have a symlink. -- Ivan Vučica i...@vucica.net ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Image size, DPI (was Re: Gorm is broken)
Le 7 mai 2011 à 23:53, Eric Wasylishen a écrit : > On 2011-05-07, at 6:26 AM, Riccardo Mottola wrote: > >>> Yes. However, the value 72 dpi is important in GNUstep/Cocoa because 1 >>> point in the window's base coordinate system = 1 pixel, and a point is 1/72 >>> inch. (even though it's an arbitrary number in some sense because no modern >>> desktop screens are really as low resolution as 72 PDI). >>> >>> So drawing an image with 1 pixel = 1 pixel means treating the image as if >>> it is 72 DPI, which is what the code did before my patch, i.e. it set the >>> dimensions in points to the dimensions in pixels. >>> >>> I just checked on Cocoa and it ignores the dpi of PNG's and assumes them to >>> be 72dpi, however it reads and uses the dpi of TIFF's exactly as GNUstep >>> does now. In addition, Cocoa supports multi-image TIFF's, something I would >>> like to add support for to GNUstep. This means we can provide high-res >>> versions of the default artwork which are only used when a scale factor> 1 >>> is set. >>> >> I took Terminal's icon and UI elements and explicitly set them to 72dpi. The >> Icon seems to draw quite well, the UI icons in the preferences (the cursor >> buttons) seem to be slightly blurred, as if drawing was scaled by a factor >> close to 1, but not being 1. >> > I finally figured this out, as well as the blurry button icons in NSSavePanel. > > These happened when I committed r32895, where I reimplemented the > -composite... methods in NSImage on top of the -drawIn... methods. A side > effect of this is that drawing images with -compositeToPoint: no longer > automatically pixel-aligns them, so if you composite an image at (0.5, 0.5), > it will appear blurred. This behaviour matches Cocoa though. > > (I found another small difference between Cocoa and GNUstep - autoresizing in > Cocoa seems to pixel aligns view frame origins, whereas in GNUstep it can > give view frames fractional origins. This didn't cause problems in the past > since we were rounding image locations in the backend. GNUstep is still more > lenient than Cocoa - for example if you put a NSImageView or an NSButton with > a frame origin at (0.5, 0.5) in Cocoa the image will appear blurred. I have a > test app that shows off various cases which I'll add to GSTest when I get a > chance.) It's great you figured that out. I have observed that pixel alignement where not the same between GNUstep and Cocoa in some cases, but I was clueless about it. Cheers, Quentin. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Fwd: [fhs-discuss] Call for Participation: FHS Relaunch
Is this of relevance for GNUstep? https://lists.linux-foundation.org/pipermail/fhs-discuss/2011-May/01.html regards, lars ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r32990 - in /libs/gui/trunk: ChangeLog Tests/gui/NSView/NSView_frame_bounds.m
On 2011-05-09, at 2:18 AM, Fred Kiefer wrote: > On 06.05.2011 03:01, Eric Wasylishen wrote: >> Author: ericwa >> Date: Fri May 6 03:01:21 2011 >> New Revision: 32990 >> >> URL: http://svn.gna.org/viewcvs/gnustep?rev=32990&view=rev >> Log: >> * Tests/gui/NSView/NSView_frame_bounds.m: Add some more tests >> of setBoundsSize:. They are currently failing (but pass on >> OS X). >> >> Modified: >> libs/gui/trunk/ChangeLog >> libs/gui/trunk/Tests/gui/NSView/NSView_frame_bounds.m > > Great tests! Thank you for adding them and for fixing the copy/paste bug you > made in convertPoint:toView: > No problem. :-) > I think that the last remaining tests here a due to this comment in NSView > setBoundsSize: (or rather the following test): > > // This may seem strange, but Cocoa only adjusts the bounds, when there > // is no rotation > > I don't really remember why I came up with this but I am pretty sure there > was a reason for that at the time. We must have had a test case that showed > on Cocoa this stupid behaviour. Maybe Apple fixed their framework in the > meantime, or there still is a special case that needs to be taken care of. I > will check with my private test code to see what the original argument was > here. And if I find something, I will make it part of the official test code. Cool. Also, when calling -setBoundsSize:, if the ratio between bounds size and frame size changes we need to update the origin of the _bounds rect. The tests I added should check for that. btw, I found these problems when playing with the "Wrap to Page" mode in TextEdit (10.6), which shows your document as multiple pages and adds a zoom level control. There's a copy on my github account with a GNUmakefile: https://github.com/ericwa/TextEdit Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Image size, DPI (was Re: Gorm is broken)
On 2011-05-08, at 12:47 AM, Fred Kiefer wrote: > > Original-Nachricht >> Datum: Sun, 08 May 2011 01:32:58 +0200 >> Von: Riccardo Mottola >> An: Eric Wasylishen >> CC: Developer GNUstep >> Betreff: Re: Image size, DPI (was Re: Gorm is broken) > >> Hi, >>> On a related note, I think the Cairo backend also rounds the coordinates >> of path points - shouldn't we get rid of that as well? >>> >> I think that perhaps we should. But it is a delicate issue. Try >> Graphos:play with it drawing boxes and lines especially, check our >> various backends and check cocoa. Try different line widths. My >> impression is that on cairo everything is always blurred :) Xlib of >> course never since it has no anti-aliasing. But Cocoa isn't as "bad" as >> cairo, it usually looks fine for integer line widths. > > If I remember correctly the code here tries to avoid bluring for lines that > the programmer would expect to be exactly horizontal or vertical oriented. > This is the standard approach used by all cairo applications I know of. We > should add a lot of tests before we change this. Ok. I agreed it should be well tested if changed. Based on a quick check, however, cairo's and Cocoa's default behaviour are exactly the same , i.e. the examples here: http://www.cairographics.org/FAQ/#sharp_lines produce the same results on Cocoa, so it doesn't appear that cocoa does any rounding below the level of NSView implementations. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Image size, DPI (was Re: Gorm is broken)
On 09.05.2011 22:01, Eric Wasylishen wrote: On 2011-05-08, at 12:47 AM, Fred Kiefer wrote: Original-Nachricht Datum: Sun, 08 May 2011 01:32:58 +0200 Von: Riccardo Mottola An: Eric Wasylishen CC: Developer GNUstep Betreff: Re: Image size, DPI (was Re: Gorm is broken) Hi, On a related note, I think the Cairo backend also rounds the coordinates of path points - shouldn't we get rid of that as well? I think that perhaps we should. But it is a delicate issue. Try Graphos:play with it drawing boxes and lines especially, check our various backends and check cocoa. Try different line widths. My impression is that on cairo everything is always blurred :) Xlib of course never since it has no anti-aliasing. But Cocoa isn't as "bad" as cairo, it usually looks fine for integer line widths. If I remember correctly the code here tries to avoid bluring for lines that the programmer would expect to be exactly horizontal or vertical oriented. This is the standard approach used by all cairo applications I know of. We should add a lot of tests before we change this. Ok. I agreed it should be well tested if changed. Based on a quick check, however, cairo's and Cocoa's default behaviour are exactly the same , i.e. the examples here: http://www.cairographics.org/FAQ/#sharp_lines produce the same results on Cocoa, so it doesn't appear that cocoa does any rounding below the level of NSView implementations. Are you saying that Cocoa basic drawing operations have the same blur effect for horizontal single pixel lines? Does this affect only the CoreGraphics functions or also the NSBezierPath methods? And what about the still supported PS functions? If this is the case we need to move the half pixel correction up one level into gui. I remember that before that correction was added use interface elements with the cairo backend looked less sharp. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
