CALayer resizing puzzle
Hi to all, I'm trying to write a (at that time) simple GIS-like application based on Cocoa. For each cartographic layer, I use a CALayer object, which is nice to control things like opacity in real-time. However, I'm facing a challenge: when the user move the mouse, the drawing must move accordingly, feeling in white spaces that appear when updating the position property. However, to feel in those spaces, the app must be able to draw on it, thus the layer shall be resizable in every four direction, including left and below, while maintaining the existing drawing unchanged. I've tried to move the anchor point around and modify bounds or frame, but to no avail: or I get no extension, or I have a transitory motion corresponding to a bound property change (is there a way to disable the implied CASimpleAnimation?). So, put briefly, is there a way to extend a CALayer in whatever direction while keeping its content unmoving? Thanks! Vincent___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CALayer resizing puzzle
Hi Scott, > this specific example of course assumes that you’re using the iphone. But, > the technique should be sound for what you’re trying to do. > > The technique is applicable to use a pool of multiple views to contain > smaller amounts of the content. the advantage is that you can render or fetch > the content that is visible (or could be next) only when required. As you > show new content relocate the views, create the layers (which you could do in > the reusable pool) and the set the content. Then move the no longer visible > layers back to the pool, clearing the content to save space. Ok, this is an already common scheme to render bitmap images: you prefetch surrounding areas in background and so you can scroll to them quite fluidly when needed, discarding useless tiles and creating new ones on the fly. I'll try to do that to render vector data, even if it's a lot of work. I'll have to dig into threads and all that stuff. Yet, at the same time, I'm baffled by the fact that I have not found how to resize a CALayer the way an NSView resizes. If what I found out is right, when you resize a layer, the scale is automatically adjusted. Does that mean that the content property is altered not only when you set it explicitly, but also when you draw on the layer via [DrawLayer: inContext:]? To answer to Douglas, the code is very simple. Imagine a NSView with a backing layer and a sublayer. When the user clicks and drag the mouse, I simply update the position property of the sublayer by the amount of pixels the mouse moved since last event. This way, the drawing moves along with the mouse, but the origin also. To be more specific, here it is: // Move coordinates of layer int dx = dragMousePosition.x - intermediateMousePosition.x; int dy = dragMousePosition.y - intermediateMousePosition.y; CGPoint pt = [backgroundLayer position]; pt.x += dx; pt.y += dy; [backgroundLayer setPosition:pt]; intermediateMousePosition = dragMousePosition; The CGPoint variable intermediateMousePosition gets initialized at the MouseDown event, and dragMousePosition is the current position of the mouse. Thanks a lot for your help, Vincent___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CALayer resizing puzzle
Douglas, > Have you checked the values of dx and dy in the debugger? Shouldn't those > variables be declared as CGFloats as opposed to int? That's correct, but it does not matter since the int is automatically converted to float/double. Actually this part of code works like a charm. You click, the image moves all right. Then you let go the mouse button, and nothings happens since I have explicitly removed any layer layout constraints (the layer is shifted and remains where you "left" it). But you're right, I've not yet looked at the autoresizingMask. Maybe I should do that, I'll keep you posted – privately, since I think this is out of scope now, and I've another puzzling question to ask. Cheers and thanks a lot for your help, Vincent ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
KVO and object release timing (for a NSCollectionView)
Hi again,
in my project, I have a managed object A, that has a relationship to an other
managed object B, itself in relation with a third object C (which happens to be
a CALayer, therefore is not part of Core Data): A -> B -> C.
The object A I register in a NSArrayController, whose content is linked to a
NSCollectionView. The NSView I use to visually represent the NSArrayController
contents includes a slider that observes a parameter of C (more specifically,
opacity) through KVO.
So far, so good.
I have a NSButton in C to remove from the array controller the A object it
represents. However, each time I click on that button, I first get a warning
telling me that I remove an observed object before releasing the observer, and
then the program crash, albeit:
- I've set the relation option between A and B to leave B alone when A is
deallocated;
- I keep a temporary pointer on A and release C before A is removed from the
array controller.
NSArrayController controller;
id A, B, C
(void)removeA:(id)sender {
id tmp = [A retain];
[controller removeObject:A];
[[[A getB] getC] release];
[[A getB] release];
[tmp release];
}
It seems the object in the NSCollectionView persists some time after A is
removed from the array. Of course, I could twist the action and redirect it
somehow to the slider so it would unregister (which would mean somehow
subclassing it) and then pass a message the remove message to A. Is there any
simpler solution ?
I hope this is not too obscure.
Thanks,
Vincent___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: CALayer resizing puzzle
David, > Yes it is. The contents property is generally used to represent bitmapped > content of a layer, which in the case of a plain CALayer means that anything > drawn via -drawInContext: or -drawLayer:inContext: will be accessible via the > contents property. Thanks for that answer. I would dare a further request for enlightenment ;) Does it mean that: 1. by defining a suitable ContentsRect, I can get a clipped area of a CALayer just by accessing layer.contents? 2. that I can copy this clipped area into an area the same size on another layer defined by another ContentsRect? More specifically, if I do that: layer1.contentsRect = CGRectMake(100, 100, 50, 50); layer2.contentsRect = CGRectMake(0, 0, 50, 50); layer2.contents = layer1.contents; does it copy the bitmap contained in layer1 rectangle (100, 100, 50, 50) into layer2 rectangle (0, 0, 50, 50)? Thanks ans cheers from Paris, Vincent___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CALayer resizing puzzle
Le 22 janv. 2010 à 19:41, David Duncan a écrit : > This will set layer1 and layer2 to use the same contents, and have them use > different parts of that bitmap. > > However your contentsRect is being set incorrectly. The contentsRect is a > rectangle in a unit coordinate system, which means that the coordinates range > from 0 to 1. Assuming your contents are 200x200, then the proper > contentsRects would be CGRectMake(0.5, 0.5, 0.25, 0.25) and CGRectMake(0.0, > 0.0, 0.25, 0.25). Ok, thanks a lot. I'll tinker with my code and try to find further answers. Have a great week-end Vincent___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: KVO and object release timing (for a NSCollectionView)
Hi Corbin,
>> I have a NSButton in C to remove from the array controller the A object it
>> represents. However, each time I click on that button, I first get a warning
>> telling me that I remove an observed object before releasing the observer,
>> and then the program crash,
>
> If you have a crash, it is always best to post the crash report.
Well, I wrote a workaround, so I can't give you a crash report anymore.
The crash happens in the KVO unregistering routine.
The problem is that when the represented object is removed from the array
controller, the corresponding NSView is not immediately released. Instead,
there is an implied CAAnimation (or something similar) that makes the NSView
slowly fade away. Net result is that the NSView survives some tenths of a
second after the represented object is released, and the KVO unregistering
crashes.
The (very dirty) workaround is this: instead of immediately release the
represented object, retain it, target it for delayed deletion, and then remove
it from the array; the real deletion is triggered in the dealloc routine of the
corresponding NSView (or subclass thereof) :
// Highly heterodox
- (void)dealloc {
[super dealloc];
NSApp delegate] appController] layerManager] removeTargetedCALayer];
}
I had to write it this way, instead of the more orthodox :
- (void)dealloc {
NSApp delegate] appController] layerManager] removeTargetedCALayer];
[super dealloc];
}
because the KVO removal takes place in the [super dealloc] routine…
Great WE,
Vincent___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Better Way to Add an Entity to an ArrayController
Le 23 janv. 2010 à 21:43, cocoa-dev a écrit : > I have a core data app with a model where there is a one-to-many relationship > between CD and Track (CD has an NSSet called tracks). The tracks are shown > in an NSTableView and the content set is managed by an NSArrayController. To > manually add a track the user presses the add button which runs the "add:" > selector of the arrayController. Right now, to programmatically add a track > I do: > > [arrayController performSelector:@selector(add:) withObject:nil > afterDelay:0.0]; > Why just do not use [arrayController insertObject:newTrack atOffset:0]? > Track *newTrack = [[Track alloc] init]; If Track is somehow a subclass of NSManagedObject, then it's not the right way to create it. You should use: NSEntityDescription * newTrackDesc = [NSEntityDescription entityForName:@"Track" inManagedObjectContext:moc]; Track * newTrack = [[Track alloc] initWithEntity:newTrackDesc insertIntoManagedObjectContext:moc]; where "moc" is a pointer to your managed object context. V. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Weird exception
Dobre dien, privet, poka!
Le 24 janv. 2010 à 08:38, Alexander Bokovikov a écrit :
> On 24.01.2010, at 1:12, Kyle Sluder wrote:
>> You should turn on zombies and run your app in the debugger on 10.4.
>
> Could you please describe it more particularly, as it's not clear for me what
> should I do exactly. Should I transfer all my sources into 10.4 OS? Or should
> I use Terminal to run gdb then launch my app? And how to turn zombies on?
Under XCode, you select 'run with performance tool' -> 'zombies'.
This will launch your app with the 'zombie instrument' attached, that will
signal you if you app tries to message a released entity.
> @implementation NSString (MissingMethods)
> -(BOOL) boolValue {
> return strcmp([self UTF8String], "true") == 0;
> }
> @end
>
> and I don't see any exceptions now. Doesn't it mean the problem is fixed?
What you've done is like putting a band aid over a broken bone. It might cease
bleeding, but you won't go very far anyway.
Dosvedania!
Vincent___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Allow only root/admin users to execute the cocoa app
Le 24 janv. 2010 à 10:19, Arun a écrit : > Hi All, > > I want to allow my cocoa app to be only launched by root/admin users. > How can i achieve this? That's Unix, not Cocoa. Either set you app to owner root (chown -R root.wheel myapp) and then chmod to 744 (chmod -R 700 myapp), so that nobody but root can execute it, or you can check the user id with getuid at an early stage of your program (the superuser uid is 0). Type 'man getuid' in Terminal. Vincent___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Allow only root/admin users to execute the cocoa app (PS)
Le 24 janv. 2010 à 10:19, Arun a écrit : > Hi All, > > I want to allow my cocoa app to be only launched by root/admin users. > How can i achieve this? Ah, I forgot. If you want also the admin users to launch your app, the owner should be root:admin and permissions should be 774 or you should test for getgid instead of getuid inside your app. V.___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Allow only root/admin users to execute the cocoa app
Le 24 janv. 2010 à 22:31, Todd Heberlein a écrit : >> I want to allow my cocoa app to be only launched by root/admin users. >> How can i achieve this? > > As I think has already been mentioned, the UNIX approach is to set the > application's owner as root and then make it only executable by the owner. > However, Apple largely discourages programmers from developing Cocoa apps > that will be run with root privileges. I know that, but, up to this point, I have failed to find any reasonable reason ;) that could justify this point of view, especially since it is always possible to drop root privileges at whatever point, just like postfix or named do. I don't see why being root is permissible for CLI apps and not for GUI ones. Cheers Vincent___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Allow only root/admin users to execute the cocoa app
Le 25 janv. 2010 à 10:43, Jean-Daniel Dupas a écrit : > So unless you think you know better than Apple what you're doing, never run > an GUI application with privileges. Gwynne's anwser give you some reasons why > this is bad. Je ne dis rien de tel ;) Look at the text: the security measure does not concern executing AppKit as root, it concerns applications having a setuid or setgid bit set. This is plain right. It does not, however, concern Application launched by the superuser, either as root or su/sudo. I never meant I know things better than Apple: I understand the reasons, I don't say they are pointless - in fact I agree with most of them. I just wonder why, since I know at least two or three Unix/BSD/X11 applications that run under superuser privileges, and this has never raised a strong protest amidst security addicts. But I know MacOS is not Unix :) Pas de quoi s'énerver ! ;) Ciao, Vincent ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Allow only root/admin users to execute the cocoa app
Le 25 janv. 2010 à 11:56, Uli Kusterer a écrit : > At WWDC I was told that Apple don't test AppKit against root (or at least, > not much). Since the idea is to limit the time applications run as root for > security reasons, there is no high priority find and fix such issues in > AppKit. This means Apple can focus more of its developers on hardening the > command-line part against root exploits. > > There have been issues like this in the past. For example, for a while, > loginwindow used to load QuickTime components, which would then get loaded as > root. A harmless application installing a QuickTime component could then > cause the OS to crash at login time, as root. > > So, whatever your or my or Gwynne's personal opinion, Mac OS X has been > designed under the assumption that no GUI app will be run as root (only a few > tasks like loginwindow). If you do so anyway, you're tearing a hole in > Apple's security policy and endangering your users' Macs. Okay, I didn't meant to be rude, arrogant or whatever. I just tried to understand. But I'm perfectly aware that when you develop for a given platform, you implicitly agree to abide by its philosophy. I've not been confronted to this problem up to now, so I came up with the solution I adopted before in a pure Unix/X11 environment. Hopefully, if ever I have to face it, I'll remember what you told me. Tchüß! Vincent___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
CALayer maybe silly question
Hi again, the silly question is this: is it possible to redraw a CALayer in background? More specifically, I've written a delegate method drawLayer:inContext: that creates a thread that does the drawing then returns. Net result, when I do that, is void. The screen is blank, I think because nothing in drawn when the image is composited. So, is there a way to make the drawing appear when the thread has accomplished its job? I tried to put a [[layer superlayer] setNeedsDisplay] at the end of the threaded routine, the drawing appears but vanishes at once. Any clue? Thanks Vincent ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CALayer maybe silly question
David, Le 25 janv. 2010 à 21:39, David Duncan a écrit : > If you want to draw to a layer on a separate thread, you need to run the > runloop on that thread, as Core Animation is pretty highly dependent on the > run loop operating. If you call -setNeedsDisplay on a thread where you never > run the runloop, then it is likely that the layer's -display method will not > be called until the thread terminates, which is likely your issue. Okay, thanks for your help. I'll need to alter completely the way the drawing routine works. At that point, I had a thread per call to DrawLayer:inContext:. Now I'll have to setup a real thread and proceed the drawings one after the other… :) Thanks again for your valuable input. Vincent___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CALayer maybe silly question
David, Le 25 janv. 2010 à 21:39, David Duncan a écrit : > If you want to draw to a layer on a separate thread, you need to run the > runloop on that thread, as Core Animation is pretty highly dependent on the > run loop operating. If you call -setNeedsDisplay on a thread where you never > run the runloop, then it is likely that the layer's -display method will not > be called until the thread terminates, which is likely your issue. I've done that (I had to swallow all the doc, that was a headache ;)), but to no avail. Let's say I have a ScrollLayer with 9 underlying tiles (CALayer). Each tile has a delegate to provide contents via DrawLayer:inContext:. At init time, these delegates create a linked object that spawns a thread that runs its run loop (I end up therefore with 9 threads). When DrawLayer:inContext: is called, the delegates initializes the CGContextRef variable and sends a message to the run loop of the corresponding thread, starting the refresh code. I set NSLog so I know the drawing function is called. At best, I get a transitory partial display that vanishes at once. At worse, it crashes in aa_render (), called by CGStrokePath – I had to put a global lock to avoid this. If I understand the docs correctly – despite not being a native English speaker – there is one graphic context per thread, so, instead of passing the CGContextRef to the drawing thread, which obviously crashes unless a lock is set, shall I spawn a new thread that will create the CAScrollLayer and its sublayers? If yes, is there somehow a way to refresh the tiles concurrently? Somehow, I think that one cannot return immediately from DrawLayer:InContext: and refresh the layer in background. Everything has to be in place since the recaching takes place immediately after. Is that correct? Thanks, Vincent___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CALayer maybe silly question
David, Le 28 janv. 2010 à 00:09, David Duncan a écrit : > Are you calling -drawLayer:inContext: yourself? if you are, don't do that - > just call -setNeedsDisplay on the layer, it will do the right thing. Yes, that exactly what I do: I have set up a custom loop event, that I trigger each time I need to recache the content, and the handler of that custom event calls -setNeedsDisplay, but in the context of the tile thread. > But at the same time, you could probably simplify this a lot by creating > CGImages with your content and then assign those images as the contents of > your layers from the main thread. This is almost certainly likely to be > simpler and less error prone (as well as allowing for a cleaner handoff of > content). The problem is one of smoothness. One of the layers I want to display has more than 1,500,000 points. If I try to display it on the main thread, I get the wheel, because everything above 100,000 points (CGArcs) takes a few seconds to be rendered (the whole 1,500,000 set is redrawn in about 20 seconds, and that includes decoding PostGIS HexEWKT geometry format). The goal was to delegate display to secondary threads so that I can keep scrolling and interacting even while refreshing large datasets like the one I cited. But of course, for raster tile display, I shall abide by your advice. Thanks a lot for your ongoing help and support, Vincent___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Size of Core Animation Layer
Le 28 janv. 2010 à 08:43, K.Darcy Otto a écrit : > NSRect rect = NSRectFromCGRect([hitLayer frame]); > float width = rect.size.width; > > That is, it returns a width, but not the width in the current window > coordinates. Any ideas? Thanks. What do you mean by "not the width in the current window coordinates"? By definition, a width is coordinate independent, as long as your underlying metric space remains the same (thanks to Einstein). Vincent ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSlider
Le 28 janv. 2010 à 18:05, David Blanton a écrit : > I cannot discern a method that tracks the knob on and NSSlider. > > Is it possible to track an NSSlider? Binds "value" to some KVC variable of your tracking object, no? Vincent___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSlider
> On Jan 28, 2010, at 9:05 AM, David Blanton wrote: > >> I cannot discern a method that tracks the knob on and NSSlider. > > Check the "continuous" checkbox in IB (or set the object property of the same > name) and your target will get called while the user drags, as soon as the > position changes. Do not forget there are some pitfalls. For example, I bound a slider to the alpha value of a CALayer. I had to subclass it, because there is no way I found (except a custom NSValueTransformer) to get the slider return a float value from [0,1] instead of integers. Vincent___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSlider
Le 28 janv. 2010 à 19:30, mmalc Crawford a écrit : > > On Jan 28, 2010, at 9:42 am, vincent habchi wrote: > >>> Check the "continuous" checkbox in IB (or set the object property of the >>> same name) and your target will get called while the user drags, as soon as >>> the position changes. >> >> Do not forget there are some pitfalls. For example, I bound a slider to the >> alpha value of a CALayer. I had to subclass it, because there is no way I >> found (except a custom NSValueTransformer) to get the slider return a float >> value from [0,1] instead of integers. >> > A trivial test setting the limits of a slider's value to 0 and 1 and binding > its 'value' to an object controller shows that the slider happily sends float > values between 0 and 1... Geez. I got a binary behavior when I tested it: 0 except at the rightmost position. I'll try again. Thanks for the hint. Vincent___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CALayer maybe silly question
David, > You can create the images on a secondary thread, then pass them back to the > main thread for assignment. The heavy operation is the drawing, not the > uploading of drawn content. You may also want to consider culling some of > that data before you draw it. You're right. Up to that point, I'm quite satisfied with generating the contents directly out of the delegate, but, in a sense, your approach is more unified, since the same layer could then display either vector (drawn out of the database) or raster contents. Also, there is no possibility to make the drawing be continuous? At that point, the tiles pop out of the void when the drawing is over. No way to make the drawing dynamic? Thanks, Vincent ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Fuzzy Focus Ring
Le 28 janv. 2010 à 19:51, Charles Jenkins a écrit : > Considering that the knob will probably be oddly shaped, how do I get the > system to draw the focus ring? Is the system focus ring something you can > just add to any graphic? No, but maybe you can back the drawing of your control by a small CALayer, and then specify some kind of background colored shadow when it becomes the active responder? If it works, you gain extra control on border width, color and blur. Vincent___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CALayer maybe silly question
Le 28 janv. 2010 à 21:37, David Duncan a écrit : > On Jan 28, 2010, at 12:29 PM, vincent habchi wrote: > >> You're right. Up to that point, I'm quite satisfied with generating the >> contents directly out of the delegate, but, in a sense, your approach is >> more unified, since the same layer could then display either vector (drawn >> out of the database) or raster contents. > > The content you are drawing is raster content, it doesn't matter that you are > using -drawLayer:inContext: or assigning an image to the contents field, in > either case you are getting raster content. Of course. But then, admitting I do indeed draw offscreen and then load contents in the CALayer, on what object shall I draw? A CGLayer? Something else? > If you mean to see the drawing as it progresses, you will need to manage that > yourself. You would likely want to completely overhaul your rendering process > to do it however, as using a small fixed number of tiles would make this very > slow as you would end up needing to respecify content you've already > specified (basically draw-upload-draw-upload). The trick would obviously be drawing offscreen and then fire a timer each second or so to upload content until the full drawing is done. Why not? Have a very nice day, our is over. Cheers Vincent___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Returning a nil float?
Le 30 janv. 2010 à 16:11, Chunk 1978 a écrit : > thanks. NAN seems to be the simplest solution. At the same time, if your float is supposed to lie in the range [x, y], returning any float outside this range (and not necessarily a NAN) can mean whatever you want. Vincent___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
