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.
Related
I'm experimenting with NSCollectionView after doing some practicing with UICollectionView for iOS. I'm planning to write an app which central part is a flexible grid view on that cards can be dragged around freely and I want to start with a OSX version first before tackling a iOS version.
The UICollectionView seemed like a good choice for my purpose so far (with a custom UICollectionViewLayout anyway) but now that I'm getting to know NSCollectionView for Cocoa on OSX this class seems rather meagre since there doesn't seem to be a comparable NSCollectionViewLayout class and in-depth info or tutorials on the web seem really sparsely seeded.
So is the NSCollectionView class actually a recommended choice at all for what I need? Or could anyone recommend me a better approach to get started going the right way with this?
(What I need is a performant, scrollable view with rows and columns onto that sub views can be dragged and dropped around freely.)
I agree, not recommended.
NSCollectionView performance is bad.
NSArrayController is an enigma also.
That said, there was a old example of someone rolling their own,
which is good sample code to peruse.
... google "TigerCollectionView".
Your going to run into issues with every user interaction... drag, drop, insert, deferred layout, reload, etc.
Better to roll your own using arrays of dictionaries, so you can see whats going on.
Is it possible to have like a main menu based on a let's say a DialogViewController, and navigate to a OpenGL-ES based iPhoneOSGameView ?
Yes. You can even add multiple OpenGL ES views as subviews of a standard UIView.
Though you ask about iPhoneOSGameView specifically, I recommend considering GLKView available as of iOS 5. This provides some of the same features as the iPhoneOSGameView as well as some of the generated boilerplate around animation and CADisplayLink. It would also give you the option of creating the view in the Interface Builder, should you desire. Finally, it is provided by Apple to fill a similar role and, arguably, would be more aligned with future development.
I have done the reverse. In fact, MonoGame supports opening iPhoneOSGameView as the main view and displaying standard modal view controllers over top of it. This functionality is in the GamerServices section of XNA.
I think you should create a simple example, print a solid color in the game view and try presenting it over top of a standard controller.
I would think it would work fine.
I want to know how can I create custom widgets/controls in Cocoa.
Not a full tutorial, but some guidance on what to start looking into. I'm confused by custom views, Core Animation, etc. I feel lost.
I see a lot of cool looking controls, like in Reeder App, or Sparrow etc. For example:
The left side is a collapsable menu that includes animations etc. How can I achieve something similar? I thought of using a WebView + HTML + JavaScript, but that doesn't seem like a very optimized solution.
Controls are views, so if custom views confuse you, you'll need to get that figured out before moving on to custom controls. Although you should really read the entire View Programming Guide, the section called Creating a Custom View will get you started on creating your own views. Try creating a simple view that draws a circle, for example, or the time.
When you've got views figured out, move on to custom controls. Most controls work about the same way. The user touches them, and the control responds by: a) tracking the user's input, b) changing its value, c) sending its action message to its target, and d) giving the user some feedback by redrawing itself. To get started, first make sure that you know how to use controls. Reading Control and Cell Programming Topics should help, and the section titled Subclassing NSControl covers (obviously) creating your own subclasses.
The example you provided is pretty clearly Apple's Mail.app. The view on the left side of the window might be an instance of NSOutlineView, or it might be a custom class. Either way, NSOutlineView would be a good starting point if you want to duplicate that functionality. NSOutlineView is a subclass of NSTableView, which in turn is a subclass of NSControl, which in turn is a subclass of NSView. Read Outline View Programming Topics for help getting started -- tables and outlines are extremely useful, but also more complicated to use than basic controls like buttons and text fields.
I know it's only a part of the UI, but I've recently coded something similar to the sidebar. If you look though the source-code it may give you some help on learning how to use custom controls and cells.
You can check it out on Github:
https://github.com/iluuu1994/ITSidebar
I am new to Cocoa development and I am trying to create UI layouts using what I consider to be the "standard" layout that is shared by apps like iTunes, iCal, iPhoto, Billings, 1Password, Numbers, Delicious Library, etcetera. This typical layout can be described as follows:
A "Library" panel on the left side of the screen, usually meant for discovering hierarchies. This panel usually covers about a fourth of the horizontal space.
A "Main" panel to the right of the Library panel on which most of the UI interactions take place. This takes the remaining horizontal space and is where we find things like the monthly calendar view in iCal, or the tile of album art and playlists in iTunes.
Some "Utility" panel on the bottom-left corner of the screen, usually for things like additional options.
Is there a documented pattern that will show best practices on how to "wire" the View and Controller classes for these types of layouts? For instances, how many ViewControllers to use, whether or not using an NSDocument-based approach makes sense, some common pitfalls, etcetera? This layout is so prevalent, that I am surprised that there doesn't seem to be any good reference on it.
Update:
I forgot to mention that I have access to the Apple Developer site, and while I can find the library reference for the different classes in Cocoa, I cannot seem to find a good reference for how to bring it all together in the layout I describe.
Books like Aaron Hillegass' and others out there are great to learn the basics on Cocoa and creating simple interfaces (a few controls laid out on an view connected to an NSDocument), but not so great at guiding you to the UI layout I describe.
Thanks.
The hierarchical view on the left is called a Source View and you would normally create this with the NSOutlineView class.
Have a look at Apple's SourceView sample code. It implements a source view very similar to the one in the Finder and elsewhere and should give you a big head start.
The range of applications you mentioned is so wide that it is impossible to give a direct answer.
In general, the item you call a Library is usually an NSOutlineView (for hierarchies) or an NSTableView.
The main panel really depends on the actions contained within, same for the utility panel.
My suggestion is to read Apple's Human Interface Guidelines for OS X. This will give you the best overview of how to do things. Other than that, the actual implementations are too dependent on the individual program.
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.