Which of the following Apple technologies would you like tutorials about?
By dgohara at Fri, Nov 3 2006 7:54am
Cocoa/Applescript
24% (236 votes)
Core Animation
11% (106 votes)
Spotlight Plugins
3% (25 votes)
Core Data
12% (112 votes)
Performance/64-bit Computing
19% (189 votes)
Xcode
29% (286 votes)
Other: Add comment below
2% (16 votes)
Total votes: 970
Comments
java
I'd love to see some stuff on crossplatform scientific programming with java (or others, suggestions?). It's great we love macs but scientists use many different platforms so it's important imho to be able to bring useful science tools to as many people as possible.
Importing a UNIX/Linux console program in Xcode to add a GUI
I'd love to see a tutorial on how to import in Xcode a project for UNIX/Linux console-based in order to add a GUI.
I have not very clear what I have to do to "convert" all my Makefiles and autoconf files to work within Xcode.
---
I'm not telling you that you should believe me. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one.
What type of import?
I think this is a good idea, and it has been on my list for a while. I have wrapped an X11 code in a Cocoa launcher before (www.scm.com), and could certainly explain how that is done.
But you seem to want something different. It seems you have a command line tool, and want to add a GUI app on top. There are different ways to do this:
1) Import the command line tool into Xcode, but have Xcode just run the standard make file to build the tool. Then write a GUI Cocoa app that simply starts up the command line tool as a sub-process.
2) Import the command line tool into Xcode and use the Xcode build system to create the command line tool. Write a GUI app to start this as a subprocess
3) As 2, but link the command line tool directly into the Cocoa app. No subprocess.
Do you have a preference?
Drew
---------------------------
Drew McCormack
http://www.macanics.net
http://www.macresearch.org
Applescript
Or use Xcode to build the GUI and link to the command line using the applescript command "Do shell script..."
Import case 1)
Case 1 is the perfect representation of my situation. I have a command line tool that normally I launch as a job in the GNU/Linux cluster, but I'd like to "reuse" the code and Makefiles and just add on top of it a GUI to "set up the command line arguments" and display the results as they are created.
---
I'm not telling you that you should believe me. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one.
I second that...
I am new to Xcode and I am trying to use it to build a Fortran application that is currently built with a Makefile.
I am going through the Beginning Xcode book by Wrox.
I have found a couple of things online somewhat related, but nothing yet that has worked for me.
The links below refer to a "GNU Make Target", but that is not listed in the version of Xcode I am using.
Here are the links I have found somewhat useful so far:
http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/preparing/chapter_3_section_4.html#//apple_ref/doc/uid/TP40002849-BBCJABGC
http://www.scorec.rpi.edu/~littld/xcode_makefile.html
Thank you,
Bryan
why is java is now a 2nd class citizen on os/x :-(
* graphics: no 3D!?
the posts on this mailist interest-digest-help@java3d.dev.java.net indicate that mac users are stuck with JOGL, which is a work-around for 'native' 3D in java - and it arrives on os/x a year after the rest of the world already recieves it! (even that is not confirmed: i grew too tired of waiting to check recent status).
the reason? according to the java3D guys (from sun), apple wont work with them!
how is it possible to deal with x-platform sciviz on mac when apple is always YEARS behind other platforms in support for thye FULL java spec?!
* cocoa: no more 'mocha'?
apple made a stealthy announcment that it was killing off java access to cocoa after tiger ... ie in the future (leopard), any /new/ additions to the (rich!) cocoa frameworks will only be accessible via ObjectiveC :-(
this seems shizophrenic on the part of apple: they had recently completed the major migration of their excellent application server (webobjects) from objectiveC onto java! ....
but now webobjects will be stranded (in javaland) without a (first-order) access to cocoa itself?
... and look how apple has let quicktimeforajava languish for a decade!
what kind of incoherent product architecture is that?!?!
CONSLUSION: it would be really great to have some hard-core analysis of whether there is any long term way to design java as a first-class citizen on os/x - or whether it is time to cut & run, and limit one's designs to the most rudimentary elements?
Java bridge
You make some interesting points. I have heard others complain about the fact that the Cocoa-Java bridge is deprecated, but I think Apple had pretty good reasons for it, namely, nobody used it. I can't think of any decent app that used Java and Cocoa. Maybe you can think of one (?)
One problem with Java-Cocoa is that you get the worst of both worlds: lousy and slow Cocoa apps, and platform-locked Java apps. There is no advantage to be gained. You are better off either deciding to build the best Cocoa app you can, using Obj-C, or building a cross-platform Java app with SWT or some other cross platform API.
I should also point out that Apple aren't against the idea of a Cocoa bridge per se. In fact, they are introducing one in Leopard (http://developer.apple.com/leopard/overview/apptech.html), which will initially support Ruby and Python. To me, this makes more sense, because these languages don't really have a native API for UI development. Java does, and that is one reason Cocoa-Java doesn't make sense. You get the feeling it was only introduced to begin with because Java was hot at the time, and Apple needed to lure developers.
Drew
---------------------------
Drew McCormack
http://www.macanics.net
http://www.macresearch.org
java is slow on Macs
I agree to the statement about the cocoa java bridge. This turns java apps to single platform apps.
Java is great on OS X and well integrated into the system. For scientists there is only one drawback: performance. If you have to process huge amounts of data - like us - you want the quickest platform you can get. Choosing Macs always meant being half as fast as on a comparable linux box. This is even more true for graphics intensive applications running with java.
This may have changed now with the intel processors (hopefully - I did not have the chance to try this myself because where I am we always have to fight hard for a mac).
This said, macs are really great as development platform for java and as an alround computing platform for scienstists in general.
I would like to see objective c tutorials, especially on the upcoming objective-c 2 and about integration of plain c and c++ into objective c.
I try to keep my apps as portable as possible (hence java), and also for obj-c development I try to stick to c and c++ as long as possible. But the integration into obj-c code is sometimes tricky.
Interfacing wxWidgets-2.8.0 and plplot-5.7.2 C++
I have installed the wxWidgets-2.8.0 and plplot-5.7.2 libraries on a G5 with OS X 10.4. Using Xcode 2.4.1, I can build wxWidgets applications that include OpenGL. I would like to interface PLplot with wxWidgets, so I can plot the results of multibody dynamics simulations. However, I don't know how to use Xcode to compile and link programs to the PLplot libraries. I know the PLplot libraires have been installed correctly, because the supplied test programs have compiled and executed correctly using the supplied make files. A tutorial explaining how to use Xcode to link to the PLplot libraries would be very useful.
wxWidgets supports the PLplot libraries, and there have been one or more interfaces developed in the past. For example, see wxPlot-plplot-5.5.1 at http://personales.unican.es/carreracg/web/wxplot.html and http://eaps3.iap.tuwien.ac.at/~smekal/wxplplot/ . Unfortunately these implementations were done in Windows and have little documentation.
GUI and Cmd Line Tool
Hi,
I'm new to Fortran but not with GUI (old C and ASM dev on Atari and on Mac). Using XCode and gfortran, actually i'm trying to transform a Cmd Line Tool in a real Mac App.
In fact this tool ask the user for many parameters, and I want them to be indicated through form and menu.
What I've done is :
1) take the fortran source, and compile it under XCode to see if it's correct. And it is! (yeah!)
2) Study the Tutorials about mixing C and Fortran (good, thanks you!)
Now I'm going to :
a) transform the Fortran code in order to put all the code in a sub routine in order to call it through C and pass parameter from C. In first step, these paramter would be static data
b) Build the GUI with Interface Builder and build the C code for that (for newbees, some pretty nice example are provided with XCode)
c) get the parameter from the GUI and give them to the fortran routine.
I suppose this is not so hard to do, except in case of Fortran "write" call as it's not possible to "print" directlty. In this case, building a "print GUI function" and do a search-replace in fortran code would be (maybe) a solution in order to have a correct display.
Maybe a tutorial for such a thing would be good?
Regards
Pierre-Louis
Re:GUI and Cmd Line Tool
I am not sure if this answers your question.
I think what you are saying is:
You have a command-line fortran tool. Now you have a (Cocoa?) GUI application whose only job is to pass on data to the command-line tool.
1. Like drc says below, you can try "Do shell script.." from AppleScript.
2. You would use NSTask. Here is an example:
NSTask example
3. I have had some success with creating an Applescript whose only command is "Do shell script...." and the Cocoa application uses NSTask to run this applescript. This is a very inefficient method. You might have better results with simply calling the command-line tool directly using NSTask.
4. Consider Pashua and Platypus.
Better yet, I'm starting a series...
Starting tomorrow (2007-04-11), I'm starting a tutorial series on wrapping command-line tools. It's a common request!
Can't promise I'll cover everything in the first week, but I'll certainly cover all of these.
-Geoff
Thanks
After covering the basics of wrapping a command-line tool, could you also address improving the performance of such an app when you get the chance? By performance, I mean reducing the time one sees the color spinning wheel.
E-mail me an example?
Could you e-mail me an example where you see a lot of "pizza of death" spinning? Typically this simply means that the thread for that app is busy. Not surprising if the command-line tool is processing a lot.
But if you have a particular example (something you've done with Platypus or whatever) which gives you a long spinning wheel, please let me know. I'll see if I can integrate it into the tutorials.
You can e-mail me by going to my user account (e.g., clicking "ghutchis" above) and using the contact form.
Spinning Beachball in Wrapped CMD Tools
I'm sure Geoff will cover this, but the beachball will not arise unless you explicitly block the UI thread. If you are using NSTask, and call waitUntilDone: or whatever the method is, you are making a synchronous call, and blocking the thread. Better to let the NSTask run in the background, and register for a notification that it is finished. The only problem with this is that it is a little more tricky to write/read input/output to/from the task. But it can be done, and I'm sure Geoff will show you how.
Drew
---------------------------
Drew McCormack
http://www.macanics.net
http://www.macresearch.org
Thanks for your offer
It is exactly what you and Drew were saying: I was not using a separate thread to handle the command-line tool's processing. Because this is a typical case, I won't bother you with that email :)