I'm in the midst of porting a win32 app to cocoa. Wherever possible, I'm using IB, since... well its way easier in every way possible, obviously. One thing is the designer and the win32 dev set up all the button assets on a massive "sprite sheet" such you move around the viewport to determine button state. Similar to how yahoo does CSS sprites on their home page (http://d.yimg.com/a/i/ww/met/pa_icons/20100309/spr_apps_us.png)
Can IB be setup to handle this type sprite strip with the default buttons, or are we SOL on this one? I can certainly fire something up programmatically that would do this, but would like to incorporate as much of the default button behavior and selector hookup in IB.
Thoughts?
Josh
This isn't supported in IB because it is really not a Cocoa way of setting button images. I understand why you would use sprites in CSS but in a native program (on any platform) it seems really unnecessary and inefficient.
I honestly think it would be much less work for you to forget about using the sprites. Out of curiosity, are these buttons going to be for standard user interactions, or something more along the line of buttons for a game? If it is for standard user interactions (open file, change font, etc.) then I strongly recommend using the stock buttons as much as possible, although I understand that this might be out of your control. The reason is that the worst ported apps are usually the ones that try to keep visual fidelity with their Windows counterpart.
Related
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 have the core of an iPad app made up, its relatively simple. However I want to add support to portrait mode (currently works in landscape). Trouble is, its quite a customised, unique interface, made of different uiimages, labels, etc
So how when the user rotates the iPad, can I handle the movement of all these objects? Whats the best way to do it?
Thanks.
If you have designed the interface in interface builder, you can build up the relationships between GUI elements through the interface builder, and at a first shot, see what it does with the rotation. This MAY work for you, I know there are interfaces I have designed where this is NOT an option, and others where it works just fine.
Else, You may have to write all of the positioning code yourself. Probably the Best way to do this from my experiance is to use pre-processor directives to define your positions for all of your elements in each of the 2 orientations. This way you write the routines for manipulation and then your small tweaks that you may need to make after you let it run the first time can simply be numeric tweaks in your pre-processor directives file.
http://bynomial.com/blog/?p=85
http://the.ichibod.com/kiji/how-to-handle-device-rotation-for-uiviews-in-ios/
What I mean by this is, how much work would be involved in rewriting/extending default AppKit controls in a way that would allow for both a standard OS X appearance and custom appearance (loaded from image files) if the user so wishes? (Think of WinAmp or Windows Media Player.) Has anyone tried to bring this to the Mac?
I understand how to redraw an NSWindow or a button cell but that's all hard coded. I want something the user can add to themselves. What are my options?
Well, it would really involved redrawing all the custom components you'd need from scratch, whether in code, or using images. AppKit wasn't meant to be customized as it strictly follows Apple's Human Interface Guidelines; Apple wants to create one consistent UI metaphor across all native applications.
What that means in practice is that you're going to have to do a lot of custom drawing to theme your app. Using images makes things easier, but not by too much. If you want a custom button, you'll have to create a subclass of NSButton and NSButtonCell to load the images you want and draw (take a look at NSDrawThreePartImage() and NSDrawNinePartImage() for how to more easily draw resizable buttons). To theme NSWindow, you'll have to subclass NSThemeFrame, a semi-private class that draws the standard OS X window look.
Essentially, you'll just need to do a lot of subclassing to get the appearance you want. Is it possible? Absolutely. Is it recommended or easy to do? Not so much.
Of course, you have to ask if this is really necessary. The point of the HIG is to try to create one standard look across OS X. If not done expertly, a themed look can be tacky, and possibly even confusing for users who are used to the default OS X look. If you want to include UI theming, there usually needs to be a good reason for it (either to maintain cross-platform compatibility, but in that case, all HIG rules are out the window; or to achieve a specific look, a là game UI), but I really wouldn't recommend doing it, let alone letting users customize your UI themselves.
Yes this fully possible. But are you shure that you want to do this using AppKit? Maybe better use crossplatform solution like QT that support skinning through CSS?
Is there anyway, we can identify if the process has user interface? Anything which deals with drawing on screen.
I looked at this question, but it does not give proper answer. I am inside the process. Is there some api where i can query, or some technique?
EDIT: I am inside the process, I am doing code injection. I want to behave different for non gui apps than gui ones. I cannot use CFBundleGetValueForInfoDictionaryKey() or NSApplicationMain as I want to keep injection module light and thus I cannot link against these frameworks.
This depends heavily on what you mean by "has a graphical interface." Do you mean, "is displaying a window?" Or "has a dock icon?" Or "has access to the Aqua context such that it could display a window if it wanted to?" Or "is linked with AppKit?"
An app bundle that does not have a dock icon will have the Info.plist key LSUIElement set to "1". You can fetch this using CFBundleGetValueForInfoDictionaryKey() (or the NSBundle equivalent if you're in Objective-C). This does not mean the application has no GUI, but does mean it won't show up in the dock. Many LSUIElement apps have a status item UI.
You can also check that you actually have an Info.plist at all using CFBundleCopyBundleURL() or the like. If you don't have an Info.plist, then you're not going to be a "GUI-like" program in all likelihood. (Though again, it's possible to generate GUIs without this).
You can use weak linking to test for AppKit:
if (NSApplicationMain != NULL) {
// We're linked with AppKit
}
That's a fairly good indicator that you're going to have a UI. But it won't catch older Carbon apps.
Some more background on what you mean by "I am inside the process" would be helpful. I assume you're a framework and want to behave differently for GUI apps than for non-GUI apps?
To detect an application capable of drawing on the screen, I would check for whether CoreGraphics is linked. That'll only work for programs built since 10.3, but should be fairly accurate (I believe that old QuickDraw apps still link Core Graphics in 10.3+, but I don't have one handy to check). Probably the best way is to do a weak linking check against CGColorCreate() since it's been around for a long time and is unlikely to ever go away:
extern CGColorRef CGColorCreate(CGColorSpaceRef space, const CGFloat components[])
__attribute__((weak_import));
...
if (CGColorCreate != NULL) {
// Linked with CoreGraphics. Probably a GUI
Of course things can link with CoreGraphics and be capable of drawing on the screen, but never actually draw on the screen. They might link with CoreGraphics in order to do image processing. It might be more accurate by looking for ApplicationServices. You could test ApplicationServicesVersionNumber against NULL, but that's not documented.
This will not catch X apps, since they don't technically draw on the screen. They send commands to X11.app, which is a GUI. Do you consider /usr/X11/bin/xterm a GUI for this purpose? /usr/X11/bin/xeyes?
There is no particular flag I'm aware of in any app that says unambiguously "I draw on the screen." Drawing on the screen is not something you need to pre-declare. Apps that draw on the screen don't have to do so every time they run. Apps that are generally invisible might optionally or occasionally create a status item. It's hard to come up with a single description that includes GrowlHelperApp.app, Pages.app, and /usr/X11/bin/xeyes.