I want to load a collection of images and show them in the GUI like an instagram or something like that, How can I reach this?
Which widget should I use?
I've tried creating a ViewHolder in the GUI but I don't know how should I assign it the image to display.
Using a view-holder is a good start. The view holder operates on a View object. This object needs to be a subclass of View and you store the instance in your application model in an instance variable. The accessor of that instance variable needs to be used in the UIPainter, so that the ViewHolder knows how to access its view.
Now in that View subclass you need to implement #displayOn:, which gets a GraphicsContext as parameter. That GraphicsContext has a clippingRect, which you should make use of in order to determine which image to draw. To draw the images you typically send #displayOn: to the image, but there's probably also a #displayOn:at: method available.
You may also want to tell that view holder that it has scroll bars.
In general it would be also a good idea to have a look at the GUIDevGuide.pdf in the doc folder of your VisualWorks installation. It'll describe the ViewHolder and its usage step by step.
Related
I'm building a share extension for my iOS app and I can't use the default SLComposeServiceViewController, so I created (in the storyboard) a basic UIViewController and embedded in a navigation controller. I get to present it, dismiss it etc but it's always full screen. I would like to make it look more like a dialog.
I have tried using self.preferredContentSize on my view controller, tried Use Preferred Explicit Size on the navigation controller in Interface Builder, but it doesn't work.
This can be done easily and directly using the storyboard but is not immediately obvious. There is no need for multiple view controllers.
Create your own view controller class inheriting from UIViewController.
In the MainInterface.storyboard change the class of the view controller to your new class
In the storyboard you can simply draw your UI - but here is the trick. You need to understand that the storyboard view will fill the screen and by default the view has already been created with a clear background. You simply need to create a view inside of the main view. You can set auto layout constraints to size this view and position it (e.g. centered horizontally and vertically). You can also use size classes to cause this inner view to fill the screen on compact layouts. Connect the controls from the inner view to your view controller in the usual way by control-dragging
In you custom view controller you can refer to self.extensionContext to read and complete the share action. Refer to the code in the template ShareViewExtension
Ok I spent a long time trying to figure this out. For whatever reason you can't set the view size like you can with the action extension. It will always go full screen (even on iPad). So a way around this is to make multiple view controllers. Make the first view controller hidden so the user doesn't notice that there is a full screen view controller present (And yes, in a share extension the first hidden view controller actually hides completely so the user doesn't even know it was presented). Then present your actual view controller using the hidden view controller. This way you can present it any way you like and set the size etc.
In my case I actually made my hidden view controller have a UIEffectView so I can have a nice blur animation in the background and then present my actual view controller over it.
Here is a picture:
I’ve been reading through several books on Mac development, but cannot find the information I’m looking for.
The books all describe how to make floating windows or panes, but never mention how to make them all in one window. A simplified example of what I’m looking to create is shown below:
Basically, there will be three windows; A selector window with radio buttons to choose which NSDocument is currently being used, a window underneath that with buttons that show different windows to the right that allow viewing and manipulation of certain data.
For a example, each NSDocument may have a color value that can be set in the window shown by clicking view A, and some text strings that can be set in the window shown by clicking view B.
So the questions are:
Is it appropriate to use a single NSDocument sub-class for each Doc #1 and Doc #2?
Which classes should I use to set up the application as shown? NSWindowController? NSWindow? NSPanel?
I’m only looking for guidance on what to read up on, so any pointers are appreciated.
EDIT:
To clarify this further, I want to have a table view where the buttons are (View A & B), and by clicking them they will cause the other window/view to change it's contents.
It's like the split view in the iPad settings application, there is a table view on the left, and when it's pressed the right side changes.
The radio buttons are there only to illustrate that I want more than one Document. I'm guessing I need more than one to handle this? Or perhaps I should place them all in a single NSDocument? Somehow that doesn't seem right.
To achieve what you want you need one window (NSWindow), one window controller and various views each with their own view controller. There are several ways you could set this up, all depending on your requirements:
You'd have at least 3 views (instances of NSView): one for the selection of the document class, one for the view selection and one for the content. Each view is controlled by a view controller (instance of NSViewController). Additionally you can opt to wrap the views in split views (NSSplitView) so your user can resize the real estate available to each view.
You have one window with a window controller. If you choose a Document based app template in Xcode, Xcode will generate a subclass of NSDocument which you can use as your window controller (or choose to use Core Data and Xcode will generate a subclass of NSPersistentDocument with all bells and whistles you need to access Core Data for document persistency).
So to come back to your questions:
1: Yes, but depending on your requirements. If Doc #1 is a completely different thing than Doc #2 than you might need to re-evaluate. For example Doc #1 might have completely different persistent requirements than #2.
2: There's no single scenario here, but one that worked for me: Take the project template for a document based app (with or without Core Data). Use the generated subclass of NSDocument (or NSPersistentDocument) as your window controller. Use NSView to implement the views in your window where each view is managed by its own controller, which is an instance of NSViewController.
I know this is an old question, but a way to do it how you want would be to use: ContainerViews and set their embed segue to be the view controllers you want.
Imagine an application that has a number of buttons it is displaying to the user. This application wants to allow the user to move the buttons around on the screen, customizing the display, and then save this configuration for later use. That is, when the app is closed and relaunched, it will come back up with the same configuration.
I would like to create a nib file with the "factory default" button layout, but then create a new nib file storing the new UI after the user has configured it just the way they like it. How does one do this?
Thanks!
Have a look at
NSData * viewData = [NSKeyedArchiver archivedDataWithRootObject:yourView];
NSView * yourView =[NSKeyedUnarchiver unarchiveObjectWithData:viewData];
This will do what you want. With all subviews, properties etc.
you really don't create a new nib.
for one, you can't expect the user to have the devtools installed. so you need to implement these dynamic parts programmatically.
perhaps export a dictionary with colors, positions, etc. for the mutable properties; then apply those properties to those objects (so it's quite like a simple layer over a nib's xml representation).
if you are not currently using tags to identify your nib's objects, that may be an easy way to identify objects in your exported dictionary.
good luck
I searched everywhere and can't seem to find a way to do this.
I am currently making a simple application to help our user configure image metadata for another application.
I present the list of image to be configured in an IKImageBrowserView. The user selects an image. which is then displayed in another view and adds stuff to it.
I'd like to be able to update the IKImageBrowserView thumbnail "live", as the user manipulates the image. I am able to take a "screenshot" of the view on which he is working but can't for the life of me find a way to update this single IKImageBrowserView item without having to call reloadData.
Is there a way to update a single image in an IKImageBrowserView without calling reloadData?
Thanks!
Look at the -imageVersion method. This will cause the cache for that item to be invalidated. There also appears to be a private -reloadCellDataAtIndex: method that might be of interest. Updating the image's version and calling -reloadData should be sufficient though.
I have an instance of NSImageView. I have told InterfaceBuilder to allow the user to paste or drag an image into this view. This works. However, I don't see a way in the NSImageView or related documentation to get notified when this actually happens. I was expecting a delegate or some such, but I have been unable to find it. Any ideas?
This is what Cocoa Bindings does best.
Instead of talking to the view, simply have a property whose value is an image, and bind the image view's image binding to it; then, when you want to change the image in the image view yourself, all you have to do is set the value of the property, and the image view will notice the change.
The user pasting or dragging into the image view is essentially the same thing, partly in reverse: The paste or drop will change the value of the image view, which will then set the value of your property, which will cause anything else bound to it to notice the change and pick up the new value as before.
Aside from ripping out your existing send-explicit-messages-to-views code, this will require almost no code work: The only code you need is for your property. You'll hook up the Binding in IB.
See the Key-Value Coding Programming Guide and the Cocoa Bindings Programming Topics.
As for me the better way to override function
-(void)paste:(id)sender
But only if you have it in NSView based class which has NSResponder as parent