|
Sulk posted:If I want to create a method which opens a Terminal-based program (i.e. Python), what is the best way to do so? I can open it explicitly with the following: I'm not sure I understand your question so I apologize if this is unhelpful. I'll give a bit of background behind these two classes, and then address what I think is the issue you're having. NSWorkspace is basically "start another app as if the user did it". So if you open /usr/bin/python using NSWorkspace, it's exactly as if the user went to /usr/bin in Finder (cmd-shift-g if you want to try it) and double-clicked python. (I believe the mechanism at work here is called 'launch services' if you're interested in what decides what happens when opening a file this way.) NSTask is basically "start another app in the background". So you can start the Python interpreter in the background, with no window, in an NSTask. You can communicate with it over pipes connected to the NSTask's standard in, standard out, and standard error. If you do not create your own pipe and set it as the task's standard out (and ditto for standard error and standard in), it'll share your app's standard in, standard out, and standard error. This might be what you mean when you say that NSTask kills NSLog; NSLog outputs to stderr. (This is all a pretty thin layer over basic Unix stuff, so if you're unfamiliar with pipes and stdin/stdout/stderr it's worth looking up.) As you can see, these two classes have nothing to do with each other. If you launch another program using NSWorkspace, you'll have to use NSWorkspace to kill it (e.g. by sending it -runningApplications and finding the one you want). Note that this is probably a lovely user experience. If you launch another program using NSTask, you'll send that task instance the -terminate message when you're done with it. Which one you use depends on whether you want the user to interact with it directly (NSWorkspace) or whether you want just your app to interact with it (NSTask). (That said, if you start an app using NSTask, it'll have a window. Try code:
|
#
?
Nov 14, 2011 08:44
|
|
|
|
| # ? May 15, 2024 11:32 |
|
|
I'm appreciating any help. Basically, I know it's a "huge" project as far as my skills go, but I wanted to see if I could make a very basic editor of sorts. The best situation would be to either have a section at the bottom of the screen running code, or to open it in a separate window running Python (I'm using Python in part because it's built-in and easy to access). I'm not certain if you can use NSWorkspace to call a Terminal with arguments, though.
double sulk fucked around with this message at 09:40 on Nov 14, 2011 |
|
#
?
Nov 14, 2011 09:04
|
|
|
I have a mixed objective-c/html5/javascript issue if anyone cares to check out. I wanted to view an html file with a canvas element and javascript in a UIWebView, which I have done, but can't seem to get any touch interaction to occur with body.onmousedown = function (event). I pulled an example from http://html5demos.com/canvas-grad (see source) and changed onmousemove to onmousedown. The file by itself works on my computer in Safari but not on the iPad simulator. I can see it in the simulator, but touching it does nothing. Inside the UIWebView, I checked to see if other sites worked to see if touches were being ignored entirely, but it that wasn't the case. Just in case, I'll paste what I have inside my viewDidLoad for my UIWebView: code:LP0 ON FIRE fucked around with this message at 22:10 on Nov 14, 2011 |
|
#
?
Nov 14, 2011 21:49
|
|
|
I've been banging my head against the wall on a silly problem. Google isn't much help. I'm trying to create a Mac OSX application that is full screen on two separate displays (a view on each, a window on each, whatever). No matter what I try, I cannot get a second window/view to exist on the second monitor. I've tried too many different methods to list. Some of them display the new window as a tiny window on top of the main window, some of them do nothing at all. Nothing appears on the second monitor no matter what. I've been grabbing the second monitor's screen from [NSScreen screens] (finding the one that's not equal to [NSScreen mainScreen]) and either using something that takes a screen as an argument [NSWindow initWithContentRect .... screen:] or just a rect (using [[[NSScreen screens] objectAtIndex:secondScreenIndex] frame]) What's the correct way to do this? I'd eventually like to mess around with the various full screen kiosk options, but I can't even get a normal window to display at this point. edit: I may have figured it out. [NSScreen mainScreen] seems to be pretty unpredictable. It's changing to the second screen after I open the first window on [NSScreen mainScreen]  . It works fine if I use [screens objectAtIndex:i] edit2: OK, this makes no sense to me at all. I found a typo in my code where I specified mainScreen for the new window's rect and secondScreen for its screen. Changing them to be consistent causes the window to not display at all. What the hell is going on? secondScreenWindow = [[NSWindow alloc] initWithContentRect:[mainScreen frame] styleMask:NSBorderlessWindowMask backing:NSBackingStoreBuffered defer:NO screen:secondScreen]; ManicJason fucked around with this message at 02:40 on Nov 15, 2011 |
|
#
?
Nov 15, 2011 01:52
|
|
|
Sulk posted:I'm appreciating any help. Basically, I know it's a "huge" project as far as my skills go, but I wanted to see if I could make a very basic editor of sorts. The best situation would be to either have a section at the bottom of the screen running code, or to open it in a separate window running Python (I'm using Python in part because it's built-in and easy to access). I'm not certain if you can use NSWorkspace to call a Terminal with arguments, though. I think it's a very doable project for you. First step: hook up an NSTextView to a Python REPL's standard error and standard output using NSTask, and hook up an NSTextField to the same task's standard input. The goal is basically to replicate the Terminal: you type Python code in the text field, and when you hit return it shows up in the text view with the results of running the code below it.
|
|
#
?
Nov 15, 2011 03:21
|
|
|
LP0 ON FIRE posted:I have a mixed objective-c/html5/javascript issue if anyone cares to check out. I wanted to view an html file with a canvas element and javascript in a UIWebView, which I have done, but can't seem to get any touch interaction to occur with body.onmousedown = function (event). I pulled an example from http://html5demos.com/canvas-grad (see source) and changed onmousemove to onmousedown. The file by itself works on my computer in Safari but not on the iPad simulator. I can see it in the simulator, but touching it does nothing. Hit up the Safari Web Content Guide for some info on events in iOS. I'm guessing that your onmousemove event isn't firing. You can try to make it work, or look into handling the touch events.
|
|
#
?
Nov 15, 2011 03:25
|
|
|
ManicJason posted:edit: I may have figured it out. [NSScreen mainScreen] seems to be pretty unpredictable. It's changing to the second screen after I open the first window on [NSScreen mainScreen] Not unpredictable at all! NSScreen Class Reference posted:mainScreen (Don't worry, you're far from the first to get this wrong!) As for putting different windows on different screens, you have two choices as I understand it. The first screen returned by +[NSScreen screens] has a lower left origin of (0, 0), and other screens are arranged around this first screen (which has the menu bar) according to the user's settings in Displays.prefpane; in this case, you'd take into account the origin of the screen you care about when placing your window. Your other choice is to use the NSWindow initializer that takes a screen, in which case your NSWindow's frame is relative to the lower left of the screen you pass in. So if you have two screens arranged and sized this code:code:
|
|
#
?
Nov 15, 2011 03:49
|
|
|
pokeyman posted:I think it's a very doable project for you. Pretty much giving up on it for now because I don't understand any of this. MVC just kills me and I don't really get the language as well as I'd like to believe. Oh well.
|
|
#
?
Nov 15, 2011 06:10
|
|
|
pokeyman posted:Not unpredictable at all! The last line in my post got it working, but I still don't quite understand its behavior: secondScreenWindow = [[NSWindow alloc] initWithContentRect:[[[NSScreen screens] objectAtIndex:0] frame] styleMask:NSBorderlessWindowMask backing:NSBackingStoreBuffered defer:NO screen:[[NSScreen screens] objectAtIndex:1]; Notice the mismatched indices between the rect and the screen. If I set them both to 1, as I thought I should, the window does not appear. I had a thought after taking a break tonight and re-reading the docs: is it that screen 1's rect value is relative to the overall desktop origin (so its origin is 1920,0) but interpreted to be the coordinate relative to its screen's origin in this method, where it should be 0,0? Matching them both at 1 in this case would mean the window is being drawn exactly off-screen where a third monitor would be. If not, I'm still lost, but happy I at least got the code to work. In the end, I'm worrying way too much about doing the "right thing" and getting coordinates/screens procedurally when the truth is that this is going to be two 1920x1080 screens in the exact same setup every time.
|
|
#
?
Nov 15, 2011 06:41
|
|
|
ManicJason posted:I had a thought after taking a break tonight and re-reading the docs: is it that screen 1's rect value is relative to the overall desktop origin (so its origin is 1920,0) but interpreted to be the coordinate relative to its screen's origin in this method, where it should be 0,0? Matching them both at 1 in this case would mean the window is being drawn exactly off-screen where a third monitor would be.. This is it exactly.
|
|
#
?
Nov 15, 2011 06:43
|
|
|
Sulk posted:Pretty much giving up on it for now because I don't understand any of this. MVC just kills me and I don't really get the language as well as I'd like to believe. Oh well. Hit me up on PMs if you want, I'll wager you're closer than you think.
|
|
#
?
Nov 15, 2011 06:46
|
|
|
Well, at least it makes sense now. I can't say the same for the rest of Cocoa. I've been doing some Mac desktop development lately after a decent amount of iOS experience. I've been absolutely shocked by how much harder and less intuitive everything for the desktop is. All of the UI elements are named the same things, and none of them behave the same. I wasted an embarrassing amount of time last week trying to implement a read-only NSTextView (first trying to use setStringValue which is apparently a no-no, then futzing around with the NSTextContainer). I ended up giving up and writing my own class to handle a stack of NSTextFields on top of each other to handle multi-line output 
|
|
#
?
Nov 15, 2011 06:55
|
|
|
ManicJason posted:Well, at least it makes sense now. I can't say the same for the rest of Cocoa. Remember that the desktop version of Cocoa has grown out of the ancient NeXTSTEP days (hence the NS*!) so there are a lot of anachronistic design choices made in those classes. The big one that comes to mind for me is the distinction between "views", which are "heavyweight", versus "cells", which are "lightweight" and recyclable. Cocoa Touch on iOS basically takes Cocoa's concepts and implements them in a sane, modern way. I'd love at some point to see UIKit ported over to the desktop, throw in a couple classes specifically for desktop widgets that don't exist on the phone, and then deprecate AppKit, but that's probably insane.
|
|
#
?
Nov 15, 2011 13:10
|
|
|
FYI, they changed the name of the CS193p class *again*, so if anyone is looking for the latest iOS5-centric CS193p to follow along with, it's here: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=473757255
|
|
#
?
Nov 15, 2011 13:48
|
|
|
Martytoof posted:FYI, they changed the name of the CS193p class *again*, so if anyone is looking for the latest iOS5-centric CS193p to follow along with, it's here: Thanks! God why didn't I get this excited for classes when I was actually in school...
|
|
#
?
Nov 15, 2011 14:35
|
|
|
Kekekela posted:Thanks! God why didn't I get this excited for classes when I was actually in school... Probably the same reason I didn't. Beer and college girls.
|
|
#
?
Nov 15, 2011 14:48
|
|
|
pokeyman posted:Hit up the Safari Web Content Guide for some info on events in iOS. I'm guessing that your onmousemove event isn't firing. You can try to make it work, or look into handling the touch events. I understand why onmousemove wouldn't fire with a touch device, and that's why I changed it to onmousedown. Thanks for the link, I'll check it out! edit: Someone found the answer for me on stackoverflow. I had to use canvas.onmousedown instead of body.onmousedown. edit 2: Actually, learning about the iOS touch events for Javascript really made a huge difference. I didn't suspect they made anything for this, and was kind of strange to see at first. I also had to capture what touch I wanted to get the coordinates from. Pretty nifty to see it in the Javascript. code:LP0 ON FIRE fucked around with this message at 20:21 on Nov 17, 2011 |
|
#
?
Nov 15, 2011 16:59
|
|
|
Flobbster posted:Remember that the desktop version of Cocoa has grown out of the ancient NeXTSTEP days (hence the NS*!) so there are a lot of anachronistic design choices made in those classes. The big one that comes to mind for me is the distinction between "views", which are "heavyweight", versus "cells", which are "lightweight" and recyclable. Yeah, I'm aware of the history. It definitely makes sense. Learning iOS first before moving to desktop is basically going back in UI time and has been pretty frustrating thus far.
|
|
#
?
Nov 15, 2011 18:07
|
|
|
I've been wanting to tinker with game development for iOS and eventually android. Since they use different programming languages and SDKs is it better to learn Objective C and Java separately and write the apps in the native language or is a cross compiler sufficient?
|
|
#
?
Nov 17, 2011 02:33
|
|
|
If you're only tinkering, I recommend sticking to one platform so you can focus on game development rather than the differences of the platforms.
|
|
#
?
Nov 17, 2011 02:38
|
|
|
wolffenstein posted:If you're only tinkering, I recommend sticking to one platform so you can focus on game development rather than the differences of the platforms. If I planned to move to both platforms is it still better to take the time to learn each one or is it not worth the trouble? Right now it's just a hobby but if it could grow into something profitable I'd be open to that too.
|
|
#
?
Nov 17, 2011 03:18
|
|
|
Binary posted:If I planned to move to both platforms is it still better to take the time to learn each one or is it not worth the trouble? Right now it's just a hobby but if it could grow into something profitable I'd be open to that too. i'd learn the native language for whichever platform you're starting with (I'd recommend iOS over android, the more standardized devices will free you up from a lot of bs you won't want to deal with while you're learning the ropes). Picking up new languages isn't very hard once you've got some development experience (familiarizing yourself with all of the common libraries is more of an issue than actually learning the language from my experience) and I'd be pretty leery of cross-compiler stuff obscuring platform specific details that you're better off knowing and having direct control over. (and also/therefore pumping out an inferior finished product)
|
|
#
?
Nov 17, 2011 03:26
|
|
|
Kekekela posted:i'd learn the native language for whichever platform you're starting with (I'd recommend iOS over android, the more standardized devices will free you up from a lot of bs you won't want to deal with while you're learning the ropes). Picking up new languages isn't very hard once you've got some development experience (familiarizing yourself with all of the common libraries is more of an issue than actually learning the language from my experience) and I'd be pretty leery of cross-compiler stuff obscuring platform specific details that you're better off knowing and having direct control over. (and also/therefore pumping out an inferior finished product) Cool, that's about what I expected to hear. I take it that if you want to get serious with it you should avoid cross compiling then. How hard would it be to port a program already written in Objective C to Java (or vice versa)? I have experience with C and java already.
|
|
#
?
Nov 17, 2011 03:44
|
|
|
Keep in mind that you can't reuse any code between the two. You can reuse whatever assets you have (art, data) but you're starting from scratch on the code when you start porting. So it won't be hard, because you'll already have a working example of your app. But you're more than doubling your testing load as long as you keep the two versions, so it's quite a bit more non-coding work once you've finished the port.
|
|
#
?
Nov 17, 2011 07:05
|
|
|
With a game I'm working on I'm not positive how much NSMutableArray's I'll have in the end. I'm trying to keep it simple, and performance is key. I just wanted to get some advice on how vital it is to use initWithCapacity. Is it something that could really give you a lot of overhead in the end, knowing how long these arrays should be? I know it sounds very elementary, but why would someone do this, unless they're using some ancient computer? Maybe I just don't understand the reasoning behind it. LP0 ON FIRE fucked around with this message at 22:30 on Nov 17, 2011 |
|
#
?
Nov 17, 2011 19:58
|
|
|
I haven't looked too closely at NSMutableArray, but a typical implementation would start with a buffer of 4 entries and re-allocate a new array with double the size each time you exceed the capacity. If your array ends up with 1025 elements, it'll end up using as much space as a 2048 element array, write 2045 elements, and perform allocations for 4092 elements worth of space. That can add up to a pretty huge amount of overhead if you're doing the operation enough times. That said, it's pretty easy to go back and change later, so you're probably better off not worrying about it right now and then doing something when your profiler tells you there's actually a problem to solve.
|
|
#
?
Nov 17, 2011 21:24
|
|
|
If the performance of your data structure is really important, you should see whether you can get away with writing it in Objective-C++ and using an STL data structure instead of NSArray. NSArray has something of a jack-of-all-trades design which is not primarily tuned for efficiency, and if nothing else, doing a message send for every access adds up pretty quickly.
|
|
#
?
Nov 17, 2011 22:10
|
|
|
rjmccall posted:If the performance of your data structure is really important, you should see whether you can get away with writing it in Objective-C++ and using an STL data structure instead of NSArray. NSArray has something of a jack-of-all-trades design which is not primarily tuned for efficiency, and if nothing else, doing a message send for every access adds up pretty quickly. Objective C++ is an abomination, you could just use CoreFoundation arrays if you care about message send overhead. That way you get the added bonus of toll-free bridging.
|
|
#
?
Nov 17, 2011 22:37
|
|
|
Sewer Adventure posted:C++ is an abomination, Fixed that for you. C++ has to be the most obtuse way to add object-oriented concepts to C, with a healthy dose of "why support X in the language when we can just have 15 libraries that implement it differently!".
|
|
#
?
Nov 17, 2011 22:58
|
|
|
Sewer Adventure posted:Objective C++ is an abomination, you could just use CoreFoundation arrays if you care about message send overhead. I'm not trying to start a holy war about languages here. There are plenty of good reasons to use NSArrays, and most programs are not going to be noticeably limited by their performance. If you find that you are, though, moving to CFArray is not a significant change. CFArrays have the same not-particularly-optimal internal structure as NSArrays, and turning a message-send into a call is an improvement but not a major one. They also both force you to use ObjC/CF objects as the elements of your array, which is either totally fine or a major boxing/unboxing overhead, depending on what you're doing. Sewer Adventure posted:That way you get the added bonus of toll-free bridging. Toll-free bridging is not a bonus? I mean, don't get me wrong, it's a good thing that NSArrays and CFArrays are interchangeable, but it's not like it's some crazy feature that makes CFArray totally awesome. It's just the absence of what was previously a serious interoperability problem. If you don't need interoperability, and you're comfortable with C++ (which it's okay not to be!), and the performance matters, std::vector really is a significant upgrade.
|
|
#
?
Nov 17, 2011 23:25
|
|
|
Is this an acceptable way to share data between view controllers? It seems to be working, but I am curious whether it is good style and whether it will pass muster in the review process.code:I had originally planned to alloc a model object in one view controller and then send a reference to the other view controller. But then I ended up drag-n-dropping my navigation stuff on a storyboard instead of building and pushing the next view controller.
|
|
#
?
Nov 18, 2011 01:04
|
|
|
rjmccall posted:I'm not trying to start a holy war about languages here. There are plenty of good reasons to use NSArrays, and most programs are not going to be noticeably limited by their performance. If you find that you are, though, moving to CFArray is not a significant change. CFArrays have the same not-particularly-optimal internal structure as NSArrays, and turning a message-send into a call is an improvement but not a major one. They also both force you to use ObjC/CF objects as the elements of your array, which is either totally fine or a major boxing/unboxing overhead, depending on what you're doing. quote:Toll-free bridging is not a bonus? I mean, don't get me wrong, it's a good thing that NSArrays and CFArrays are interchangeable, but it's not like it's some crazy feature that makes CFArray totally awesome. It's just the absence of what was previously a serious interoperability problem. It's something you don't get from C++ arrays. You would have to write a bunch of code to convert your C++ arrays if you wanted to use them with UITableViews, for example, and you'd have to deal with the memory management yourself rather than rely on ARC. quote:If you don't need interoperability, and you're comfortable with C++ (which it's okay not to be!), and the performance matters, std::vector really is a significant upgrade. The performance of ObjC structures is perfectly fine, and there's absolutely no reason you would need anything else. I think the fact that none of the standard iOS apps (all of which perform great) use ObjC++ is a testament to this.
|
|
#
?
Nov 18, 2011 01:11
|
|
|
Cylon Dinner Party posted:Is this an acceptable way to share data between view controllers? *shoves globals into app delegate* You're the only one who can say whether that's acceptable :-)
|
|
#
?
Nov 18, 2011 01:55
|
|
|
Sewer Adventure posted:The performance of ObjC structures is perfectly fine, and there's absolutely no reason you would need anything else. I think the fact that none of the standard iOS apps (all of which perform great) use ObjC++ is a testament to this. This projection is astounding.
|
|
#
?
Nov 18, 2011 01:56
|
|
|
I think you should not worry about it for now, and instead try and make your code clear and comprehensible and functional. Then later on in the project when you want to increase the performance, run a profiler and optimize the bottlenecks. From my personal experience I regret pre-optimizing, it just hasn't been worth it.
|
|
#
?
Nov 18, 2011 02:33
|
|
|
pokeyman posted:Keep in mind that you can't reuse any code between the two. You can reuse whatever assets you have (art, data) but you're starting from scratch on the code when you start porting. Right, but this is still the best way to do it rather than mess with cross compiling right? I'm starting to learn about Objective C, just want to make sure I'm not wasting time.
|
|
#
?
Nov 18, 2011 03:11
|
|
|
Sewer Adventure posted:Well the reason you cited was "message send overhead". "NSArray has something of a jack-of-all-trades design which is not primarily tuned for efficiency, and if nothing else, doing a message send for every access adds up pretty quickly." There's a lot of other overhead in NSArray; none of it is huge, but it all contributes. For example, all array accesses are bounds-checked and mutable arrays are actually deques. Will doing bounds checks or using a deque where you could have used a vector completely kill the performance of your application? Obviously not. Does it have an impact? Yes. Sewer Adventure posted:It's something you don't get from C++ arrays. You would have to write a bunch of code to convert your C++ arrays if you wanted to use them with UITableViews, for example I don't know why it would be more difficult to implement UITableViewDataSource in terms of a C++ vector than in terms of an NSArray. But yes, I did say that using a vector would really only be appropriate if you didn't need to pass it off as an NSArray*/CFArrayRef. Sewer Adventure posted:and you'd have to deal with the memory management yourself rather than rely on ARC. ARC should work just fine in Objective-C++. For optimal efficiency, you'd want to use C++11 and libc++ (because __strong objects can be efficiently moved), but it certainly works even in '03 or with libstdc++. Sewer Adventure posted:The performance of ObjC structures is perfectly fine, and there's absolutely no reason you would need anything else. I think the fact that none of the standard iOS apps (all of which perform great) use ObjC++ is a testament to this. ...which standard iOS apps are you referring to here? Because Safari/WebKit/UIWebView is a mix of ObjC++ and pure C++, and without breaking confidentiality I can tell you that I see a *lot* of ObjC++ code in the wild. And again, I will point out that I really don't think that container performance is going to be a noticeable overhead for the vast majority of code. The only place I can imagine it really mattering is if using an NSArray forces you to unnecessarily box up a ton of objects.
|
|
#
?
Nov 18, 2011 04:00
|
|
|
rjmccall posted:
Webkit is legacy code (KHTML) that had been written in C++ from the beginning. So I am referring to everything other than WebKit. Sewer Adventure fucked around with this message at 04:27 on Nov 18, 2011 |
|
#
?
Nov 18, 2011 04:06
|
|
|
Binary posted:Right, but this is still the best way to do it rather than mess with cross compiling right? I'm starting to learn about Objective C, just want to make sure I'm not wasting time. I honestly can't answer that question for you. If I was doing it myself, I'd do two native apps, but I've done no non-iOS apps so I have zero relevant experience.
|
|
#
?
Nov 18, 2011 04:08
|
|
|
|
| # ? May 15, 2024 11:32 |
|
|
Sewer Adventure posted:Webkit is legacy code (KHTML) that had been written in C++ from the beginning. Everyone I know that works on WebKit, including a lot of its technical leadership, would laugh you out of the room for suggesting that their use of C++ is simply a legacy holdover and that they'd be happier if it were written exclusively in Objective-C. Defining WebKit out of your sample is silly, because WebKit is one of only a few standard apps that both (1) actually has to work with large amounts of data and (2) cares about the speed of access to them. Stocks could hold its monitored ticker symbols in a linked list and do O(n^3) work on every UI refresh and it would be hardly one user in a million who ever even noticed a slowdown. The size of a typical address book is dwarfed by the number of DOM nodes on google.com. Mail is the only real competitor here, and Mail has serious performance problems with large mailboxes, although I doubt that has anything to do with NSArray. Again, I am not disputing and never did dispute that the Objective-C containers are perfectly fine for the vast majority of code. Their performance is sub-optimal but not indecently so, and even if they were unspeakably terrible, most code in the world has no serious performance constraints and only runs into problems due to poor choices at levels far above the choice of container implementation.
|
|
#
?
Nov 18, 2011 06:25
|
|