I need to make a custom tooltip view for all views of my project. This tooltip view has a specific shape (pentagon), font, font color and background color. Also it should has a typically delay, like the system tooltip, when mouse enter and mouse exit from view. Which is the best way for do this?
Thanks for the answers
I need to make a custom tooltip view for all views of my project.
For all views? Most applications have a lot of views that the user isn't even aware of — views used to contain groups of controls and such. So it'd be strange to offer tool tips for every view. Tool tips are usually used with interface components that actually do something, and their purpose is to tell the user what that something is. That's why you see that NSControl has methods for managing tool tips, but NSView doesn't.
Which is the best way for do this?
First, decide whether you really mean that you want tool tips for every view, or if you actually just want the same kind of tool tips that Cocoa already offers, but drawn differently. If the latter, then you could subclass each type of control you use and override draw(withExpansionFrame:in:) to draw the kind of tool tips you want.
If you really want tool tips for every view, you might do better to implement your own system. One approach might be to have some object in your app monitor mouse moved events. You can start a timer to track elapsed time after each mouse moved event, with each new event invalidating the old timer and starting a new one. If the timer expires, it can add a view displaying your pentagonal "tool tip" view to the window near the mouse.
Related
I'm wondering what the best way is to do a split NSToolbarItem like Xcode does. I've read the documentation, but can't figure out a way to do this. Any ideas?
It's a custom control. Basically it's a custom NSView, drawing a background the same as a button/popup, draws the "selection" on both sides, handles mouse events and displays one of two menus based on which side was clicked. It's not difficult, but it's not a trivial amount of code to whip up and share either. Just look at any examples of making any kind of clickable custom view and you'll be on your way.
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaViewsGuide/SubclassingNSView/SubclassingNSView.html
I got an app that allows users to add content to a canvas. I would like to be able to offer the user an ability to move, rotate, resize, reflect this content. Currently I'm doing this with gestures, but would like to know if there is some sort of open-source widget that draws a box around the view and adds 4 buttons to do these functions:
rotate 90 degrees
rotate freely
resize
delete
Can anyone think of an open source framework that I can add to my project to create controls like the ones displayed?
I can probably build this by hand, but debugging gesture recognizers and view rotation is not the most fun thing, so I'm looking for something more polished.
Thank you!
Here's a link to an open source control on cocoa controls that looks like something you could use: TDResizerView.
"TDResizerView is used to resize and rotate an imageview with single finger"
Sounds like a good place to start from, even if you need to modify it.
I've never used this particular control though, so take my word for what it's worth.
edit: Also keep in mind that on iOS, users generally expect gestures. Forcing them to use the handles instead of pinching or rotating may be bad for your user experience, depending on why you want the handles instead.
All you ios architects out there, please help me choose architecture/technology for the following iphone/ipad app.
The app itself is a financial app, but we want more of a game look-and-feel of the app, so we probably don't want to use the builtin looks of the cocoa widgets. The elements on the screen will probably be some kind of blob-shaped images.
The app will essentially have five "blob"-shaped areas, spread out evenly across the screen. One of the blobs will be centered and larger than the other ones. Within each blob there will be clickable areas which will pop up "details" and menu-action blobs. These blobs are also graphics objects and must not take over the whole screen. The blobs should animate nicely when popping up. The graphics elements will have a couple of lines of text, which are generated, so the overlaying text itself cannot be part of the static background-image.
The main user interaction will be swiping within the center blob, displaying summaries of the items that are conceptually contained within the blobs underlying data store. Now and then, the user will drag and drop the item to one of the other blobs. While dragging, the item should be traced by a line and when dropping on the other blob, the item should be animated to look like it's being "sucked into" the blob.
Now, what kind of technique would you suggest for this app? Is Cocoa suitable in this scenario? Should I use a game framework like Cocos2D? All kinds of suggestions including example code snippets are most welcome.
I realize that this question might not be as straightforward and to the point as questions generally are on SO, but I hope your answers will come to use by more people than me. Thanks!
EDIT (MY SOLUTION):
I eventually ended up doing everything in UIKit, which was a lot easier than I expected.
Briefly described I used UIButtons with Custom style and an image background, which gave me full control over the visual appearance of the "items". I also found it very useful to manipulate the underlying CALayer of many of my other UIViews. It is often easier than drawing things from scratch using Core Graphics programming.
Another thing that was useful were the UIGestureRecognizer:s. I found them useful for both handling "real" gestures like swiping, longpress etc, but also for handling normal "tap" for UIView classes that aren't subclasses of UIControl. Two examples are UIImage, UILabel and UIView itself. That way I could handle taps for these simple classes. I could for example use a normal UIView, modify it's CALayer to change the look of it completely and still handle taps. Using this technique, I didn't have to subclass any views at all in my app.
The animations were pretty easy too, even though I had to use a non-public method to use "suck" animation, so my app will never pass App Store moderation. It was just a prototype anyway so I don't care.
When this app will be for real, I will probably implement it in HTML5/JavaScript wrapped by Phonegap. The reason for this is mainly reuse of existing mobile web services and also for code reuse across platforms. It will probably also be easier to hook into the existing security solution when using a webapp.
Cocos2d is great if you need to move elements around really fast as it is a layer on top of OpenGLES. I think from what you have said the UIKit will be fine, you get nice animation support, you can do some nice things with UIScrollViews to handle moving elements around etc.
If you need more detailed graphics support and lots of moving elements, particle effects etc then by all means go for Cocos2D but be aware that in Cocos2d the application works more on a scheduled update method, i.e. you get notified every 1/60th of a second to move stuff draw stuff etc, whereas with normal UIKit approach it is more event drive, i.e. I click a button and show a view etc.
I want to create a bar chart diagram. I already have a diagram component, I just need to adapt it to a bar chart. When touching one of the bars, the value shold pop up in small view.
As I can see there are several different strategies that can be applied here. What I want to know is which strategy should I use? Any of these or perhaps there are other better ideas?:
Bar is a UIButton.
Bar is a touch enabled UIImage.
Bar is a UIView.
Bar is just painted graphics and I have to transcode the touched coordinates and make some calculations in order to know what bar was touched. I don't don't believe in this strategy but perhaps there are reasons to rethink this that you can provide for me...
I assume that a UILable is the way to present the data associated with the bar?
Thanks in advance for your advice!
In my humble opinion, and having written many bar charts (and other charts)... #4 is actually the correct choice for performance and my personal preference. Creating the virtual graph in memory to map touches to bars is not difficult at all, as you are simply storing rectangles in arrays and checking to see if points are inside that rect.
CGRectContainsPoint(CGRect, CGPoint);
Now, having said that, if you want to introduce animations in to your chart, which is pretty cool stuff... then I could create a UIView composed of several UIViews (one for each bar, or bar segment), this way you can animate each bar individually without writing your own animation loop.
just my two cents.
my thoughts are that #2 and #3 are kind of the same since you'd display an image using a UIImageView. UIButton is a pretty thin layer on UIView that makes the event handling easy, but it might do things visually you don't want (or maybe you do?). Either way, it's so easy to try these variations I'd just play with it. I can't see a specific reason for #4 unless your overall strategy drives you in this direction, like maybe you start doing some drawing that is rich/complex enough that you have too many views being created.
AFA the popup display, it really depends what you mean by "pop up". Like once it pops up, do you need a way to dismiss that popup?
Have you checked out Core Plot? It is an active and powerful library that is pretty flexible and should meet all your needs.
You know that in a lot of Mac/iPhone applications (such as your Finder), when you are dragging a icon around, all other icons will be "repelled away" from your mouse and leave space for the icon you are dragging.
I am wondering if that's a built-in Cocoa function (in layout constraints etc?). If not, is there any library, or documents on how to implement it?
If you want to get it more-or-less for free, use an NSCollectionView.
If NSCollectionView doesn't fit your needs, it's fairly easy to implement it using NSAnimation. Basically, the way that NSToolbar or NSCollectionView does it (for example), is to figure out where the icon you're dragging would land if you let it go, and it sends the other icons to their new locations using Core Animation to move them smoothly.