I'm using E4, where all views and editors are parts and can be stacked on top of each other. However, I'm using the compatibility layer (aka the lesser evil). Still, stacking is possible, I can manually put views on top of editors and vice versa.
The question is now: How to configure the perspective, so that editors and views are stacked on default?
I tried to implement the IPerspectiveFactory:
final IFolderLayout mainFolder = layout.createFolder("main", IPageLayout.RIGHT, 0.95f, layout.getEditorArea()); //$NON-NLS-1$
mainFolder.addPlaceholder("*"); //$NON-NLS-1$
But there is no constant IPageLayout.STACK, and the above snippet does not work either.
I tried to configure the extension point, but could not figure out how to add placeholders. Also, it seems it does not work with the intro view.
So how do I stack views and editors programmatically?
Related
I've watched the WWDC 2014 session (#608 "Best practices for building sprite kit games") a couple of times and I just want to clarify the purpose behind using .sks files. Am I supposed to put separate assets into each .sks file? Here's a little bit of background into what I'm doing. I'm creating a Mac app that will text piano students to play chords using a MIDI keyboard. Chords will appear on the screen and they'll play them one by one and get a score. Here's a mockup of what the app may look like. Side note: for those that may know music, we're using the numeric version of chords instead of explicit names like Cm, etc.
Would I have a separate .sks file for each element of the UI. For instance, one for the green timer bar, one for the piano keys, etc. The example that they use in the video is a pretty simple one. I am subclassing SKSpriteNode for the timer and on-screen piano so how would I handle the resources for those. They are not static objects and they will change either over time (timer) or due to user input (keyboard)
I really want to organize my project using best practices. Please help. Thanks in advance.
Sks files are serialized SKScene objects. The intent is to provide something like interface builder for constructing SKScene scenes visually. The common use case is to layout complex backgrounds or levels and define starting positions. You would only have one file per scene in many cases. However you can use the sks files to organize and serialize conceptual components of a scene, as demonstrated in versions of the Apple Adventure sample code released since the sks format and scene editor were introduced with Xcode 6
In the screenshot above, you could organize the project into sections that are fairly generic and reusable, like the keyboard for one file and the hud atop the scene for another file. However, you could put them all in one file, then duplicate the file for variations on a theme.
I am attempting my first Cocoa Application after developing for iOS for the past few years. I have been "googling" around for awhile now but I guess I am not using the correct terminology to find what I am looking for.
In many applications OSX applications I see this little dot (or sometimes no dot at all like in XCode) which allows you to grab "an invisble" line? Which will resize two or three windows at a time while they are all bound together. How is this done? I'd like to implement it in my current app I am building. I have attached an image to clarify what I am talking about.
Thanks in advance
These are not windows. These are subviews of an NSSplitView
It's an NSSplitView. The line is the divider and can have 3 different styles:
NSSplitViewDividerStyleThick = 1,
NSSplitViewDividerStyleThin = 2,
NSSplitViewDividerStylePaneSplitter = 3,
(the style in the images of your question are the Pane Splitter style).
The content views can be easily added using Interface Builder, or programmatically using the [NSView addSubview:] method (NSSplitView derives from NSView).
You will want to control the splitter behaviour via its delegate (NSSplitViewDelegate).
Also note that the image in your question appears to show a split view within another split view, which is a fairly common way of laying out views.
I have a question regarding NSMenuItems.
What I'm trying to do is replicate a java GUI using native OS X components, therefore the language I am using is Cocoa. What I am trying to do is to get every menu item to have an image and then, beside it, some text.
I have already done some research into it and my first port of call (as always it seems lol) was the apple docs which had this handy example which illustrates how to embed views inside menuitems:
https://developer.apple.com/library/mac/#samplecode/MenuItemView/Listings/MyWindowController_m.html#//apple_ref/doc/uid/DTS10004136-MyWindowController_m-DontLinkElementID_8
Being relatively new to cocoa, I was thinking I would have to override one of the drawing methods from NSMenuItem. Not really sure though.
Another idea that I was toying with was creating a custom view that held a image and some text.
Any other ideas/validation or discussion would be most appreciated.
Thanks all!
Oh and the GUI creation is being done by hand no interface builder.
Okay, so I now have menu items with icons beside them. For anyone who is interested here it is ( i've not done a leak analysis on it or anything).
First things first, put all of the images you want into the "Resources" folder (thats what its called in xcode 3.1.4).
Now, for example, after we have all the images, we want to use images called "eraser.png" and "eraser_on.png" and I want to attach these to the 3rd menu item. In order to achieve this we do the following :
The code below will get the menu item at position 3 in the menu
NSMenuItem *item = [ nameOfPopUpButton itemAtIndex:2];
The code below will set the image for the menu item to be "eraser.png"
[ item setImage: [ NSImage imageNamed:#"eraser"] ];
That's you set the image for the menu item (which will be on the left hand side of the text aka before the text).
If you want different images for the different states, eg when the user presses it, use this method (not tested myself but its sounds sensible :D and the function is straight out the api)
[item setOnStateImage: [ NSImage imageNamed:#"eraser_on" ] ]
You can however leave it nil or not set it at all and it will go the default color
Hope this helps someone.
Pieced this together from: https://developer.apple.com/library/mac/#samplecode/MenuMadness/Listings/Controller_m.html#//apple_ref/doc/uid/DTS40008870-Controller_m-DontLinkElementID_4
Thanks :)
If you need to do this you have the right idea in creating a view with image and label subviews.
BUT: don't do this. Creating a "native" application is not primarily about your choice of language (which is Objective-C, btw, not Cocoa; the latter is a collection of development frameworks implemented in Objective-C). It's about conforming to the platform.
On OS X (and iOS), more than probably any other platform, consistency in UI design is paramount. Users know when an application looks strange, and having icons next to each menu item (something I certainly have seen in Java apps) is definitely strange and unnatural on OS X. Users will be irritated at best, confused at worst.
So my advice is to either follow the Human Interface Guidelines (and save yourself a lot of work as a nice side effect) or just stick with your existing Java application.
If you want to provide quick iconic access to common functions, the recommended approach on OS X is to use a toolbar.
I am learning cocoa, and I am creating an application that will require similiar layout to the screenshot below (this seems like a very common layout approach).
What kind of controls/architecture would this type of Cocoa application be?
I'm still in my early stages of learning/reading, and I know of document based applications only so far, but this type of layout doesn't seem to look like a document based app since it doesn't really require multiple windows opened.
If it isn't document, is there a name for other design patters or layouts?
From what I now so far, I would describe this like:
I would be grateful if someone could give me a detailed overview of the high level design for an app like this i.e. things like: # of panels, views used, controls, controllers etc?
Also, a few quick sub-questions:
what kind of menu controls are those in the left pane, then expand and display sub elements?
When preferences windows are displayed, what is that effect called that makes it display in an animated way (like the address book does), where it is a small window that expands to its correct size in an animated fashion.
You are right that this is probably not a document based application, as they open documents in new windows by default.
To layout the window like that, there’d be an NSSplitView that contains the 3 panes. Each pane may optionally contain a view loaded from an NSViewController, which can help keep the code modularised, but it depends on what you’re trying to do if this is appropriate.
The left pane would be an NSOutlineView (a NSTableView subclass), the middle an NSTableView, but I’m not sure exactly how the right-hand side view would be created (lots of custom NSViews and other things, possibly WebView)
That popover options window is possibly a NSPopover (which contains an NSViewController), but that’s only compatible with OS X 10.7, so may also be totally custom for backwards compatibility and easier customisation.
Also note this is a fairly complicated example you’ve given, with lots of custom controls that are probably harder to create than they look:
To get the outline views on the left to have unread counts and icons (from memory) is not built into AppKit, so was all custom created. To do things like that, you’ll need a solid understanding of NSCell vs NSView, and ideally also know about Core Animation layer backed views, and what to use for different aspects.
The window has a taller-than usual title bar. This means the developer probably had to do some crazy stuff to get it to work, if not create the whole window from scratch.
That’s just the start. There’s lots of really nice design in there that’s custom and done from scratch.
Designing Mac apps can be hard sometimes. AppKit is pretty old (back from the NEXT days), and has lots of legacy stuck in it. UIKit on iOS on the other hand is quite nice – Apple clearly learned from their past and made things much better.
I’ve hardly touched on the controllers and model behind all that. There’s lots of different ways you could do it. For persistence, you could use CoreData, sqlite, NSKeyedArchived, just to name a few. Brent Simmons (past developer of another RSS reader, NetNewsWire) wrote some interesting blog posts about that:
http://inessential.com/2010/02/26/on_switching_away_from_core_data
http://inessential.com/2011/09/22/core_data_revisited
The way you design your model & controllers really depends on the specific problem. Cocoa really forces you to stick to MVC though – if you don’t, things are guaranteed to end up messy.
I hope that all helps! I’m really only just learning myself too.
Apple refers to this type of application design as Single-window, library- (or “shoebox”) style and gives a number of recommendations for this design choice in the docs.
(see Mac App Programming Guide)
I'm designing a simple Cocoa app. This is basically my second Cocoa app (despite being good at CocoaTouch), so I'm looking for an in-depth pros/cons analysis of 2 possible solutions for a window flipping problem.
What I'm trying to make is an utility app that sits in the menu bar and has its preferences o its “flip” side, Dashboard-style. It would flip from http://cl.ly/1G2M3J2c142Z0V3K0R2e to http://cl.ly/021z2v2h232x310z1g2q and back.
There are multiple questions on SO about the implementation of this effect:
Core Animation window flip effect
Widget "flip" behavior in Core Animation/Cocoa
Flipping a Window in Cocoa
I've looked at the example code there. Besides neither of them being as smooth as Dashboard widgets (but I'm yet to get to “making it smooth” part), they also share another trait -- they all flip between two different windows.
Now, coming from iOS, the way I started implementing it is to have a single window, but swap between two NSViews.
So what are the pros and cons of these two approaches, and why did multiple unrelated Cocoa developers pick the first one?
Have two NSWindow's, and flip between them (hiding one and showing the other halfway through the flip).
Have a single NSWindow, but two NSView's, and switch the views halfway through the flip.
Is it more convenient to have things separated into different windows in Cocoa? Is it because you can use NSWindowController to manage their lifecycle? Are people just used to using windows because pre-Core Animation you couldn't give views a CA layer? Any other reason/convenience I am missing?
To the future generations: I believe people did it this way because they often flip between windows with different sizes, and then it's just less hassle to have them separate.
Also if you are looking for a good implementation, these guys nailed it: https://github.com/mizage/Flip-Animation