I have been trying to create a simple swipe transition. However buttons seem immune to any CAAnimation that crops.
I am trying to get it so that a bar moves across the screen and as it goes over the button it removes the part it has just gone over.
I have tried bounds.width, size.x and many other key-value paths to achieve the affect but I haven't got what I wanted. It just relocates the text which always remains entirely visible
I have also tried changing the UIButton to a UIImage but the text does not seem to print on a UIImage.
I tried using masks too but I have heard they should be used as infrequently as possible as they consume the phones resources. I didn't really get very far with this either anyway as I hadn't used them much before.
I also tried placing it in a container view and then change the dimensions of that but again all of the text remained entirely visible.
I know I could have a view hide the button but I am trying to reveal the view behind as the bar swipes.
Does anyone have any suggestions of how to achieve a swipe transition on a UIButton?
Help would be much appreciated.
Thanks
I think what you're looking for really is a mask. See the tutorial here:
http://iosdevelopertips.com/cocoa/how-to-mask-an-image.html
What I'd do in your situation is create a custom UIButton class, and add a mask as in the tutorial, then animate the position of the mask. Slide the mask of, nothing shows. Slide it on, part shows until the whole thing is visible.
Edit: I haven't really heard anything about hogging resources, especially since it appears to be simple core graphics.
Related
Context
I have a window with a fullSizeContentView and a transparent titlebar and hidden titlebar.
I don’t even want the titlebar, but I had to enable it to get rounded corners on the NSWindow.
Problem
An NSTextView, when placed near the top edge, doesn’t react to any clicks. It doesn‘t let me select any text, and doesn’t let me click links I added via NSAttributedString.
This issue disappears when I disable the titlebar altogether.
Any Help would be greatly appreciated. Thanks!
Big Context
I’m trying to implement little “in-app notifications” that show peripheral status updates. I considered using NSAlert but I don’t want to prevent the user from interacting with the rest of the interface while the notifications are showing, so I decided to implement it myself.
The notifications are little, non-movable windows without a titlebar. They are basically just grey rectangles with rounded corners and a shadow that draw inside the main application window and contain one or a few lines of text. The first line of text is almost entirely behind the invisible titlebar which is why I’m having issues.
The only thing I need the notifications to do besides display text is link to webpages that contain more info about a notification’s message.
I feel like I might be approaching this wrong. If you have any suggestions or ideas on how to solve the problem, I’m eager to hear them. Thanks!
I finally figured it out!
I nailed it down to the contentInsets of the NSScrollView. (which your are for some reason forced to have around your NSTextView when creating it in Interface Builder)
The contentInsets were automatically being set to account for the invisible titlebar, even though the docs say that NSScrollView - automaticallyAdjustsContentInsets (which is set to YES by default and which I assume was causing this) doesn't do automatic insets for transparent titlebars.
After programmatically setting the scrollView's contentInsets to 0, everything works great!
In Objective C, you can set your scrollView's contentInsets to 0 like this:
NSScrollView *scrollView = (NSScrollView *)self.textView.superview.superview;
scrollView.automaticallyAdjustsContentInsets = NO; // Doesn't remove insets // Probably calling this too late
scrollView.contentInsets = NSEdgeInsetsMake(0, 0, 0, 0);
Here's a working example.
Hope this helps!
Although I know of a solution to this problem, I am interested if someone can explain this solution to me. I also wanted to get this out there because I could not find any mention of this problem online, and it took me several hours over several days to track down. I have an NSTableView behaving strangely regarding redraws and its selection. The problem looks like this:
Table contents fades in, instead of appearing instantly upon it's appearance on screen. When scrolling through the contents, the newly appearing rows also fade in. When you make a selection (single or multiple), and scroll it off screen, then make another selection (that should replace, not add-to first selection), the first selection does not get cleared properly. If you scroll back to it, it is still there, in addition to your new selection. This is a display-update problem, not selection problem - i.e. your new selection is valid, it is just displayed wrong.
I tracked this through the NSArrayController I was binding to, the underlying Array, sorting, all the connections, and settings, etc., but all that has nothing to do with it.
What solved the problem was:
In the View Effects (right-most) Inspector, uncheck "Core Animation Layer" for the Window's main view.
Can anyone explain what is happening here, and perhaps improve upon the solution ?
It looks like Core Animation and NSTableView aren't getting along so well. The "fading" effect is a by-product of the way core animation works. When you have core animation in one view, it is also enabled in all of that view's subviews.
I don't recommend using core animation on the Mac unless absolutely necessary, because some interface elements (NSTextView and NSTableView, for example) aren't compatible with it. iOS has much better support for table views and such using core animation, mainly because it was designed with core animation in mind.
I know that some more simple UI elements are compatible (NSTextField and NSButton, for example).
If you absolutely need core animation in the rest of the window, put all the other views in a subview of the content view, while leaving the table view directly in the content view. You can then enable Core Animation in the other view.
Commenters, feel free to add to the list of what is and isn't compatible.
Hey guys, I've just migrated my image selector from NSCollectionView to IKImageBrowserView. I've got almost everything set up the way I want it, except for the selection ring. I don't like the greyed out background that IKImageBrowserView defaults to, and I wanted to do a yellow stroke around the edge of my selected image to indicate it's selection (like in iPhoto). Is is possible to override the draw state of IKImageBrowserCell? I haven't been able to find any way to do it yet. It doesn't have the simple drawRect methods that I'm used to. Any help would be appreciated. I'm assuming I have to use CALayers?
I overrode - (CALayer *)layerForType:(NSString *)type and tried just as a test, setting the layer corner radius to 0, but it didn't seem to change anything. The method is being called because if I throw a breakpoint in it, it stops there. However, even if I return nil from that method, it still draws the images like usual.
Thanks!
That is the right method for customizing the IKImageBrowserCell.
Using CALayers and configuring different attributes, you can control many facets of how the images are presented.,
A layer of type = IKImageBrowserCellSelectionLayer is what you will want to change to have the display behave and present as you wish.
Here's a link to Apple's sample code project that will get you started
I am trying to create a view for a kind of brainstorming application like, for example, OmniGraffle, with elements that contain textviews and can be dragged around. (Also, the should be connectable with arrows, but that is not (yet) the problem)
I did my homework and searched via google and read books about cocoa, but there seems to be no similar example around.
Since I am also new to cocoa, I’m a bit helpless here.
The thing I am sure of is, that I need a custom view in which I can create my elements - what I tried until now to do that is:
First, I searched for the syntax to add subwindows to a window to create my elements. Subwindows, I imagined, would automatically be movable and come to front and so on.
The problem: As the experienced Cocoa-programmers of you probably are not surprised, I was stunned to find nothing about anything like that - this seems to be something, that is just not intended in Cocoa?!
Then I thought about creating subviews that contain a custom view for the title bar drawing (where the user can click to drag the element) and a NSTextView.
Problems:
I read, that it is not so clever to create dozens of subviews in a window because that would be very slow (or would that be not so bad in this case because all the subviews would be instances of always the same class?).
Also I can’t find out how to load a subview from a nib- or xib-file. Would I need a viewController? Or would that make the dozens-of-instances-problem even worse?
And Apple tells you not to overlap subviews (okay, that would be not so important, but I really wonder how the guys at OmniGroup made OmniGraffle...)
Because of that, I now wanted to do the title-bar-drawing in the surrounding custom view and create the textview programmatically (as I understand, a text-“view“ ist not really a view and takes its functionality from NSCell to reduce all the effort with the views?).
Problems:
Even that failed because I was not able to create a textview that doesn’t fill the complete window (the initWithFrame: of the [[NSScrollView alloc] initWithFrame: aRect] just seems to be ignored or do I get that wrong?).
Also, there should be some buttons on each element in the final application. I imagine that would be easier to accomplish with a subview from a nib-file for each element?
Well, now that nothing works and the more I read, the more problems seem to occur, I am pretty confused and frustrated.
How could I realize such a program? Could someone please push me in the right direction?
I created a class for the draggable elements where I save position, size and text in instance variables. In my view, every new element instance is added to an array (for now, this works without a controller). The array is used to draw all the elements in a loop in drawRect:. For the text of the element I just use a NSTextFieldCell which is set to the saved text from every element in the same loop.
That way it is also possible to overlap the elements.
Unfortunately this is hard for me to test myself because I have yet to get a Magic Mouse of my own, but I've been told by my testers who do have a magic mouse that momentum scrolling isn't working in my app. I've not subclassed NSScrollView, but scrollview's document view is all custom. I have not overridden scrollWheel: anywhere, either, and yet momentum apparently just isn't working. I'm not even sure where to begin. I thought it'd just send scrollWheel events and things would take care of themselves. (Scrolling with a wheel or on the MBP trackpad works as expected.) Obviously I must somehow be doing something that's stopping it, but I don't even know where to begin. Thoughts?
I figured this out awhile ago and the problem was that on scroll, I was doing a lot of fancy view manipulation somewhat like how on the iPhone the UITableView adds and removes views as they scroll on and off screen. This worked great for performance - but the more I got into OSX programming, the more I realized this was wrong for OSX (but the right idea of iPhone).
Anyway, what's really going on, it seems, is that when you do something like a wheel scroll, the scroll event is sent to the view that's under the mouse cursor and then it ripples down the responders/views until it gets somewhere that handles it. Normally this isn't a problem, but with momentum scrolling the OS is really just sending ever smaller scrollWheel events to the view that was under the cursor at the time the momentum started. That means if the view is removed during the course of scrolling (because it scrolls off screen or something), it breaks the chain and the momentum stops because the view that's still getting the scrollWheel messages is no longer in the view hierarchy.
The "simple" fix is to not remove the view that got the last scrollWheel event - even if it's off screen. The better fix (and the one I went with) is to not try to use NSViews like they are UIViews and instead just draw the content using drawRect. :) Not only is that about a billion times faster, it Just Works(tm) with momentum scrolling because it's how OSX expects things to be done.
Repeat after me: OSX is not iPhoneOS.. :P
Odd scrolling behavior can occur when you don't set the Line Scroll and Page Scroll properties of the NSScrollView itself.
Beyond that, you're quite simply going to have to get a Magic Mouse - easily said or not :-) - to test this yourself or post the entire code of your custom view as well as the xib containing it. There's no way others can offer you more than guesses (like the above) without it.