Originally, I wanted to ask how to create user interfaces with cocoa programmatically, i.e. without using interface builder. But it seems that someone else has already asked this question and the answers didn't help me.
So I'll ask a different question, that I hope will indirectly help me answer the previous question. Here it is:
(QUESTION_START)
How do I create an Objective C class that is equivalent in functionality with the BoxLayout class in Java? (Just click the link, the image on that page says everything you need to know about BoxLayout.)
(QUESTION_END)
Any help in the right direction will be appreciated!
There are a few sub tasks that are connected with the question, e.g.
"How do I ask a user interface element (e.g. a button) how large it wants to be" (before it has been drawn to the screen). To draw it on the screen you have to already know its size, don't you? Obviously, the interface builder application has figured out a way to do this.
I know that many Cocoa developers think it's a stupid idea to even try what I want to do. Let me tell you: I know the reasoning behind that opinion. Right now, laying out controls without interface builder sucks, because there is nothing that comes even close to a layout manager in cocoa. But if you think my question is stupid, please DONT answer. The whole internet is full of explanations why you would never want to create UIs with code in cocoa.
Thanks!
Answering your first question is kind of difficult and fairly involved, so I'm going to dive into your subquestion first:
How do I ask a user interface element (e.g. a button) how large it wants to be?
When you create a UI element, you tell it how big it should be (as well as where it should be) via its initWithFrame: constructor; or you can set its frame later via its setFrame: method. It will then draw itself into that space. You can get an element's frame via its frame method.
With that in mind, a BoxLayout class would, hypothetically, be a controller of some sort in which you could add UI elements, and then the BoxLayout controller would arrange them in a grid (or whatever) on an NSView of some sort.
I know you weren't looking for answers that questions motives, but given the complexity of a BoxLayout class vs. laying out the interface in IB, it seems relevant to ask why you want to do this.
Related
In a project I am working with in Swift, I have a huge form that needs to be filled out. I found the best way to present the form was by combining many table views in a Modal Popover that takes over 75%ish of the screen. Using animation and a custom build Array of ViewControllers, I created something very similar to a Navigation Stack that never kept any views in it if they were data intensive by keeping them at the top or second to the top of the stack. It would push them onto the left or right side of the modal, all being done with a simple one liner outside of the Container Controller. Is this implementation bad to use for any reason? I feel like I might have bypassed a natural way of making this work without realizing it was an option.
My skills in Swift have been skyrocketing since I left my college in December, but I don't work directly with anyone more knowledgeable than me in Swift. This makes some of the more complex questions hard to answer without intense amounts of research. (which I am not opposed to if I can find an answer) I am expected to provide a quality working product in the end though, so I need to be assured that I am not making any mistakes that are at the backbone of my project.
According to the Document-Based Applications Guide, there should be a DocumentController, a Document, and a WindowController. What I am having trouble with is learning to judge where a given responsibility ought to fall.
My Document represents a todo list. A given todo list is read into memory by my Document, and it is displayed by the WindowController. The number of todos that can fit in the window at any time is determined by the size of the window, so when I need to display todos my WindowController asks my Document for enough todos to fill the visible list.
If I want to I can search through my todos using regular expressions (I know, fancy right) and the matches are returned as the top results. In this case I'm less clear on where the responsibilities lie. The Document deals with saving and loading a todo list, but above I have asked it to also deal with returning small parts of the list to the WindowController. Should the matching logic go in the Document then? Or should this stay in the WindowController since it has nothing to do with saving and loading data (the order of todos after a search is never saved to disk)? These are the sorts of questions I find myself asking (myself). When I look back on a project like this one, I notice places where my judgement calls seem at odds with each other. Sometimes I'll spend an hour just moving one bit of logic around between the two... trying to imagine which design makes more sense.
Clearly I need help.
My example is of a very particular situation, but I am not interested in the particular solution. I am interested in knowing in more general terms what the responsibilities of these three classes ought to be. I read the guide and I've googled around a bit, but I still can't seem to get a handle on it.
This question was helpful, but I am still confused.
Thanks!
My instinct in this case would be to put the logic in the window controller. The search functionality is not affecting the actual model, and I think of NSDocument as more of a "model-controller".
NSWindowController is a better fit for managing the details of the UI (a "UI-controller"), and essentially you are just controlling the view of the model with your search bar.
Yes, I know that we have NSViewController as well but sometimes that's just additional complexity for the sake of it. Much of the time, NSWindowController is just fine.
I'm relatively new to Cocoa and I would like to implement the ability to add or delete items from a pop-up menu in the same way that the OS X System Preferences/Network Location pop-up works. Selecting the 'Edit Locations...' option rolls down a window that provides the ability to add to, or delete from the existing Location list. My interest in doing things this way is as much about conforming to the relevant Human Interface Guidelines as having a way to dynamically change the menu content. (I have no real problem with the 'background' coding side of things, it's the user interface that's my primary issue at this stage.)
Is this a standard IB View?
On the surface, I can't see anything appropriate, but maybe that's just my inexperience. I'm assuming that, because this is not an uncommon sort of requirement, the task should be pretty straightforward and that Apple, or someone, would even have a relevant code sample to show how to define such a window.
Can anyone point me in the right direction?
Sorry for the late answer. I found this tutorial: http://cocoadevcentral.com/articles/000014.php
I'm new to Objective-C, Cocoa, Xcode and Interface Builder. I've got some C background in the past, as well as a fair amount of RealBASIC experience.
I'm working through Mark and LaMarche's iPhone 3 Dev book and I'm really just sort of stunned about how tedious some things are. Maybe someone can shed some light on this for me. My question really is, why does the process for seemingly simple actions involve such a complicated number of steps? Is there a benefit to the complexity which I'll come to love later? Or is it just a brute fact that is unavoidable?
For example, in RealBASIC, if I want a slider's value displayed in a text box, I simply add:
myTextBox.text = mySlider.value
to the slider's Changed event. I can program this in well under 1 minute.
In Xcode/Interface Builder, I have to physically type a declaration for both the text box and the slider, then type a property/outlet declaration for each as well, then create a method declaration and implementation for the ValueChanged even, then set up a (relatively) complicated typecast of the slider's integer value into an NSString using initWithFormat. I then have to return to Interface Builder to link up the controls with the control and method outlets I typed in. I don't see how this can be done in much less than 10 minutes. Maybe 5.
So, what's the benefit of this? Why doesn't Interface Builder automatically create, or at least suggest, control declarations and #property statements, as well as method declarations and implementations? Why can't double-clicking a slider in IB offer you a list of events and offer to automatically insert a skeleton method into your .h and .m file? And why does IB even have to be a separate application?
I'm willing to accept that some of this is my unfamiliarity with all things Xcode, but is this really as efficient as the development environment can be?
My apologies if this is a dead-horse, flame-bait topic with opposing sides on full aggro. If so, please just say "yes, that it is" and move on.
Thanks,
-Rob
A lot of the reasons behind the way IB works will become more clear as you get used to the MVC paradigm.
Once you start using Cocoa Bindings, which update your model when the UI changes and vice versa, you should see an enormous productivity improvement.
I too used to think that Xcode and Interface Builder were unnecessarily complicated, until I worked through a book on both (specifically, Beginning iPhone Development: Exploring the iPhone SDK).
If you're serious about working with Xcode and Interface Builder and are as confused as I was when I started, I highly recommend picking up a book like the one I used. Granted, that was for iPhone development, but I think there is another book by the same publisher (or author) that is straight Mac programming.
Once you work through it and understand what is going on behind the scenes it starts to make a lot more sense. In some ways I prefer IB to things like Expression Blend or XAML for WPF programming in .NET.
Give a book a try and see if it helps :-)
Good luck!
I'm trying to create a very simple selection list widget based on NSOutlineView. However, I'm having a hard time figuring out how to display an icon and a label right next to it, which is really the expected behavior in all the mainstream implementations of that kind of widget out there (iTunes, mail, Finder,...).
So far I am just binding two separate cells, but then when I'm expanding the tree, the icon cell grows larger and a gap appears between the icon and its accompanying label. I know I can probably overcome this problem by extending NSCell and provide a custom class, but as what I'm trying to achieve is really the standard thing, I can't be resigned to accept that there isn't a simpler solution.
Candide
Sadly, there isn't a 'text and icon' cell that you can just use, fresh out of the box as you would like. However, when I was working on a project, I found that Apple released some sample code that implements this, since it is such a common idiom.
This can be found here, specifically ImageAndTextCell.h/m
It can help teach you about UI customization by reading through this example, but scratching that, just dropping the ImageAndTextCell straight into your project should do just fine.
You need to create ImageAndTextcell to combine text and icon..
you can create ImageAndTextcell like this Sample Project