Converting an NSComboBox to and NSTextField Easily - cocoa

I have an NSComboBox and I was wondering if there is an easy way to convert it to an ordinary NSTextField? Considering NSCombBox is a subclass of NSTextField, I would think there is an easy way to turn this on/off but I can't figure it out.

They are two separate controls. You'll just have to swap one out for the other. If you're looking to do this in Interface Builder at design time, it's mind-numbingly simple. If you're looking to do this in code, it's not overly difficult (especially if you already have both controls created and configured somewhere in your XIB, like an off-screen view).
It might help to describe what you're trying to accomplish (ie, why you want to swap the controls). It's difficult to give a succinct answer without more information about your goals.

Related

Embedding NSStackView as NSTableCellView in NSTableView

I'm currently working on a prototype for a todo type app. I have a table which contains the user tasks. What I want to do is only present the user with pertinent task information. But to edit additional information, they would click on a disclosure button to expand the cell.
I was thinking of two possible ways to handle this:
Expanding NSTableViewCell
Using an NSStackView as the contents of each cell
If using the NSTableViewCell, I would probably have two NSViews to represent the cell (top part and lower part).
If using the NSStackView, I'd have an easy means of encapsulating the parts.
I suppose another method could also be just building it entirely with NSStackView.
The more difficult aspect of this seems to be related to the actual expansion/collapse of the cell.
I understand this could be deemed the type of question that's asking for an opinion. I've never built a MacOS app. So I'm looking for some guidance as to the best method to approach the problem versus spinning my wheels on approaches that are destined to not be productive.
Thanks!
In the end, it looks like the best thing to do is use an NSTableCellView with two NSViews for the top and bottom half. I had the case of this as well as the NSStackView working. But in the end, I found that using NSStackView to collapse or expand requires a call to make noteHeightOfRows work anyways.
So it would initially seem that it's not worth the effort of expanding it unless I have a more complicated cell where say I wanted a top, middle, and bottom, where the middle could expand and contract. While I would still need to use noteHeightOfRows, it would allow for it.
However, there is one benefit of using the NSStackView. The animation is much smoother for the collapse. I've found the NSTableCellView method with a top and bottom NSView shows signs of "tearing" as it collapses. This is what appears in the bottom edge, while horizontal, jitters. This is particularly apparent if you either spam the button or if the cell is selected because the bottom of the outline can sometimes grow in height.
I also found that when using NSAnimationContext to help make it look a little smoother, I'd see strange behavior. Like the hide would happen at the wrong time (even though it was in the completionHandler. I think the root cause of that are what becomes overlapping animations.

Changing the cursor in an NSTextView

I'm hoping this will be a relatively easy thing to do.
I am writing a Mac app that will be (mostly) a giant NSTextView. I would like to override the default text position cursor to a unique color/shape cursor. I don't have a lot of Quartz or general drawing experience but that's something I can look into more on my own.
What I'm primarily looking for is advice on the best way to implement this. Is it going to be a matter of overriding the drawRect function, calling the super, and then implementing my own draw code?
How would I find the appropriate location to draw that cursor? Is it contained within the drawRect's passed rect?
Essentially, you'll have to subclass the NSTextView and override some methods. The obvious one is
-(void)drawInsertionPointInRect:(NSRect)aRect color:(NSColor *)aColor turnedOn:(BOOL)flag
but that doesn't seem to entirely take care of it. Apparently, you also have to override a private method:
-(void)_drawInsertionPointInRect:(NSRect)arg1 color:(NSColor *)color
Look here for someone who's already trying to do this:
http://www.cocoadev.com/index.pl?CustomInsertionPoint

HTML-like view in Cocoa?

learning Cocoa can be pretty tough for web developers. Some things are so simple in HTML, and I have no idea, how to do this in Cocoa.
Let me just show you an image here, to show you what I have on my mind.
So it's kinda like a blog. Each post has variable length, so it can take up some space. Also, you're able to scroll through posts.
I was thinking about using NSTableView or NSCollectionView, but since I don't know much about Cocoa, I'm asking you for advice.
Also please do link any related articles.
Updates
So here are some things that I discovered.
I could make a subclass of NSCell and use it in Table View. I can use it, I can put there a string, something like this:
http://pastie.org/1140412
(please take a look at this code, I'm wondering if I should use awakeFromNib/setDataCell combination)
But string is not enough. I need a NSTextView. The problem is, it doesn't have method like drawInRect: withAttributes:. So I don't know how to draw it into that cell. I guess I'm missing some basics here, so I'm just gonna study some Cocoa views now.
Any ideas are welcome.
You want to use a NSTableView. And I will recommend to take a look/glance at NSTableView, NSTableViewDelegate and NSTableViewDataSource docs:
http://developer.apple.com/mac/library/documentation/cocoa/reference/ApplicationKit/Classes/NSTableView_Class/Reference/Reference.html
http://developer.apple.com/mac/library/documentation/cocoa/reference/NSTableViewDelegate_Protocol/Reference/Reference.html#//apple_ref/doc/uid/TP40008622
http://developer.apple.com/mac/library/documentation/cocoa/reference/ApplicationKit/Protocols/NSTableDataSource_Protocol/Reference/Reference.html#//apple_ref/doc/uid/TP40004178
You choose the object you want to be your datasource depending on the data you have.
The delegate is the object that helps you to so some settings, like rows, groups, cells, etc.
There are useful methods of NSTableViewDelegate you want to implement like – tableView:heightOfRow:
and just google NSTableView tutorial or something, there are many good examples ;)
You could just use a WebView and write it in HTML.
Look at http://mattgemmell.com/source for an example: the Skinnable App one.

How to imitate the workflow view of Automator?

I’m starting to develop my first full-blown Cocoa application containing a view which I would like to behave (and look) similar to Automator’s AMWorkflowView.
The basic features I’d like to achieve:
Positioning of subviews
Display of subviews in expanded / collapsed states
Multiple selection
Drag and drop
In order to get accustomed to Cocoa, I started with a custom NSView which mainly served as a container for the custom subviews and handled their positioning and multiple selection.
The subviews are also subclasses of NSView, and contain a variable amount of views themselves, like buttons, labels and popup menus, and therefore can have different heights.
This worked quite well, but before going on, I want to make sure to have everything neat and tidy according to the MVC pattern.
I suspect that there already is a class in Cocoa that facilitates the implementation of a view container, like maybe NSCollectionView.
It seems that there is no (easy) way to display differently sized views in an NSCollectionView, though. Should I continue implementing my custom NSView (probably using an NSArrayController for selection and sorting support), or are there better ways to go?
Any help is much appreciated
Unfortunately the answer is you'll have to roll your own. NSCollectionView does not allow for variable-sized items (which also rules out expanded/collapsed states).
For a limited number of items, you can accomplish this rather easily (you just need a container view that arranges the subviews properly when asked to layout, then you need to make sure you re-layout when things change). For many subviews, however, you'll need to take care to be as efficient as possible. This can start with laying out as little as possible (only those "after" the resized view, for example) and get as complex as caching a visual representation of a prototype view, drawing the cached images (fast!) for all but the view being edited, and only using/positioning a "real" view for the view being edited.
Drag and drop works the same as it always has, but none of the above accounts for the pretty animation NSCollectionView gives you. :-) It's fast and beautifully-animated precisely because all the subviews are uniform (so the layout calculations are fast and simple). Once you add irregular sizes, the problem becomes significantly more complicated.
The bottom line: If you need variably-sized views, NSCollectionView will not work and you'll need to roll your own or find someone else's shared code, but performance and beautiful animation will not be easy.

Lego-Style Cocoa Workflow Application

I currently have to develop a system very similar to MIT's Scratch's UI. In case you don't know it, here a screenshot: http://kidconfidence.com/blogs/wp-content/uploads/2007/10/scratch1.png
Basically you have bricks in the library on the left you can drop into the window on the right side. The problem I have is that I'm new to Cocoa and not sure what would be the best way to accomplish that.
Because you can nest these bricks sometimes and other times stick them together I wonder if there is something that would help implementing that. I recognize this is not a very common interface that there are probably no implementations of that around, but maybe there are helpers for parts of this.
Regards,
Armin
Edit: switching to desktop
There are no standard cocoa controls that you could leverage for the building blocks. You will probably want to subclass NSControl to make your standard brick object.
The list on the left could be an NSTableView. The main work area can be an NSScrollView.
You probably want to use your own brick hierarchy independent of the view hierarchy because of the freeform dragging.

Resources