Related
I started my career on Linux/Unix, and moved over to Windows and Visual Studio. XCode feels pretty alien to me. My feeling is that I'm not in control with XCode. It could be the case that I simply haven't understood how to use the IDE, I am new at developing for Apple OSs. One thing that kind of irks me, is that nobody seem to have found a clean way to compile for multiple platforms (iOS and Mac OS X), using the same sources. I've found two ways to "hack it", but the hacks sound fragile.
I've been pondering the idea of using simple make files instead of XCode (except for the occasional use of Interface Builder).
Is this a sane route to go? Has anyone done this? Are there any major drawbacks I need to be aware of before I take the leap, or should I just bite the bullet and wait for the enlightenment?
Use Xcode, use as many high-level tools as possible. The "loss of control" is replaced by more focus on the application, which IMHO is a great tradeoff.
It is kind of like the loss of control when I went from assembly code to "C", but it was worth it. We keep moving to higher level of abstraction and that allows us to accomplish more, focus on the big picture instead of the minor details.
You've just got to learn new ways of doing things. For example, in the situation you describe (building an OS X and iOS app with shared code), I'd put any shared code into a library/framework that is used by both projects, and create a workspace that contains all three projects.
The loss of control you speak of is offset by the fact that this can all be set up without knowing anything about compiler command-line options in around 10 minutes.
It's a different way of thinking, and it can be frustrating if you know how you would do it on a different platform, but there are advantages to both options. You may never have to think about the build process again!
Are there any GUIs for fossil?
I've been getting used to the idea of source control for solo projects, and having an interface for the commands in fossil would help.
Something simple that helps browse for files, or open + close. Google has turned up nothing except the web GUI that works within the projects themselves.
Now there IS a Fossil GUI.
At the moment it has really basic functionality, but it is free and open source:
http://code.google.com/p/jurassic-fossil/
There is a Windows GUI for fossil at http://repository.mobile-developers.de/cgi-bin/ikoch/sharpfossil
It is not yet complete, but usable and has some features fossil doesn't have.
I think you'll find the web interface, launched by the command "fossil ui" is the only user interface (graphical or otherwise) apart from a few command line commands.
What would a GUI have that couldn't be done via the web interface?
I discovered several new options for Fossil GUI recently:
Fuel - cross-platform GUI written on Qt;
QLFossil - Mac OS X helper for these, who uses Fossil.
Build-in web-interface become more usable on Windows. At the moment you can setup fossil to run on background, so you won't need type fossil ui in command line anytime you need to view history, or changes. By the way, web-interface now features a new eye-candy theme and side-by-side diffs.
There is now a GUI for Fossil on Mac, sort of... I have been working on a simple GUI which, while not a Finder plugin like Tortoise{CVS,SVN,GIT,...}, works together with Finder.
The project can be found at http://chiselapp.com/user/sti/repository/fossil-gui/home
Personally, the built-in fossil ui has been all the GUI I need for small projects.
After fossil new and fossil open, the only real interaction with a repository for a personal project is the occasional fossil changed and fossil extra to make sure I didn't change anything I didn't intend to change, and naturally fossil ci to check in those changes.
For browsing the repository fossil ui does everything I need. It is hard to beat the Timeline view, from which you can get to the files changed by that check in. There is also the Files view, from which you can see each file and inspect that file's timeline.
There is also a project in progress to write an introductory book for fossil. The current draft is well worth reading.
The ramdebugger TKL IDE has support for fossil built in, although the fact is a bit hidden on the changes changes page.
There is a built-in web interface.
If you have an open repository
i.e.
fossil open myProject.fossil
then run fossil with the ui command:
fossil ui
fossil will run a webserver providing gui access to the currently opened repository and it will start your browser pointing to http://localhost:8080 (or some previously unused port).
There are no platform ui clients for Fossil on Windows Explorer or Mac OS X Finder.
There are no IDE extensions for eclipse, netbeans, emacs or the Microsoft/Apple tool chains that I can find, but there is one for a TCL IDE:
RamDebugger has some support for GUI commit & add & update with Fossil. It is an IDE & debugger for TCL.
http://www.compassis.com/ramdebugger
http://www.compassis.com/c/ramdebugger/index
courtesy Ramon Ribó, fossil-users mailing list 1 July 2010
Sorry the answer is mostly 'no', but this response should change soon as fossil seems to be attracting a lot of attention.
I've always used emacs for small projects (and Visual Studio for large ones). I was wondering what the alternatives are for handling a directory structure within emacs, something like the solution explorer in VS. Thank you.
You should also have a look at eproject for something that's more lightweight while also allowing you do to some pretty cool stuff (like project-specific config settings, etc.)
ECB, the Emacs Code Browser, which is built on CEDET, if I am not mistaken, is one you should look at.
Myself, I've always found that I get by well enough using etags and ido-mode. You might also want to look at Speedbar (part of CEDET) as a halfway house between more minimalist solutions and ECB.
I don't use it myself, but it sounds like CEDET is what you are looking for:
Emacs already is a great environment for writing software, but there are additional areas that need improvement. Many new ideas for integrated environments have been developed in newer products, such as Microsoft's Visual environment, JBuilder, or Eclipse. CEDET is a project which implements several advanced features developers have come to expect from an Editor.
The Emacs wiki also has this page with some tips for IDE users.
See also: http://www.emacswiki.org/emacs/Icicles_-_Support_for_Projects.
I am developing an application for the Mac as a small team (me + another person) effort. We are located in different cities, and have started to see the need for solid source control management.
None of us have any experience with this, and both of us are relatively new to Cocoa/Obj-C/Xcode (but do have C knowledge).
Does anyone have any recommendations as to which SCM system to choose? I understand that a lot of people are using Subversion, which is also supported in Xcode 3.1. Does anyone have experience with using Subversion through Xcode? Or is it a better option to chose a stand alone GUI alternative, such as Versions?
Grateful for any input on this.
Gregor Tomasevic,
Sweden
Update/personal experiences:
Since this post, we have tried Versions and Cornerstone (both of which are SVN GUI-clients), as well as Xcodes built-in support for SVN. We were not particularly pleased with Versions, which seemed to have some problems with committing unversioned files/build files. The built-in SVN support in Xcode works quite well, although it probably has limitations that we have still not run into. Cornerstone is both simple to use and powerful, and does not seem to suffer from the problems we encountered with Versions.
So far, we have just tried committing, updating repo, checking out latest/previous versions of our files and worked some with file comparison. It might be a whole different ball game once you start working extensively with branching, an area which we have been told both these GUI clients might have some weaknesses in.
For what it's worth (and with only days of evaluation) Cornerstone seems to be a somewhat better alternative, although for simpler SCM, Xcode works well too.
Thanks for all the comments.
Xcode only supports Subversion, Perforce, and CVS. However, there are also distributed version control systems out there, such as Mercurial, Bazaar, and Git. These have no Mac-native GUIs, but you should still consider them. Personally, I love managing my projects in Mercurial repositories.
[Added 2011-03-10] Xcode 4 adds support for Git. Several of us have filed requests for Mercurial support; you should, too, if you want it.
There is a nice GUI frontend for Mercurial on Mac called MacHG: http://jasonfharris.com/machg/
It is free and very nice IMHO.
You can't really go wrong with using Subversion.
If, like me, you don't like Xcode's SVN integration too much you can always choose to use the command-line tools, or one of the several GUI apps like Versions, CornerStone or SvnX. Most of these tools work together pretty well, so you're not necessarily tied in to the tool you start out with.
I personally do most of my work with Versions, and use the command-line tools with the same working copies every once in a while.
If you're comfortable working with command-line tools exclusively until someone creates a good GUI app around it, git is a pretty viable option too.
disclosure: I'm one of the people who work on Versions, so I might be slightly biased ;)
Xcode's Subversion support is pretty good. 90% of the SVN activities I perform are easily doable from Xcode. For the other few things I just fire up Terminal.
There are a couple things in their SVN client implementation that are annoying:
The code that checks to see which local files have been modified seems to run on a background timer, and its pretty latent. Sometime it takes 5 minutes for Xcode to show a file as modified. The same thing is even more exaggerated w/r/t remote modifications.
Sometimes when you rename or delete a file that isn't under source control, a dialog will appear, asking "Do you wish to [rename/delete] this file in SVN as well?" And the options are "Yes" or "Cancel." You choose Yes out of desperation only to be presented with a well-deserved SVN error.
Overall, I'd recommend it.
Caveat: If you simply tell XCode to add a project to a repository by giving it the top-level dir, it WILL add the build directory to the repository, which of course is a terrible thing to do.
In order to get around this you have to move the build dir to another location so that XCode won't try to import it, or manually add the discrete folders of a project one by one.
Subversion is the traditional OS X source control solution, in Leopard it's supported in Xcode and OS X, not to mention the third party GUI apps (a few of which look very slick). Despite all of this though, a lot of the independent OS X developers have switched to Git over the past year or two. As a single developer I can tell you Git has turned out to be a very good solution for me, and along with Github it makes a great solution for a small team effort.
If you're interested in using Mercurial on OS X, try SourceTree, it's not free but it's competitively priced and has a very polished Mac OS feel. I've been using it for personal projects for the last few months on and off and find it intuitive and reasonably robust.
It's available through the Mac App Store and supports Git and Mercurial. They have a website at http://www.sourcetreeapp.com/ with more information.
If your going for subversion, I've heard good things said about Springloops. I code together with some friends too in a similar fashion and we use Github. Git is such a wonderful experience. I don't use any GUI for it since I'm much more efficient with a shell prompt. But of course, I'd welcome if Xcode had support for Git repos.
Mercurial (like git) is "distributed" and perhaps regarded as more modern and up-and-coming than svn (but less established). If you want to auto-checkin using mercurial, you can add the line:
hg commit -m "Xcode auto commit"
as part of a "Run Script" stage of the XCode build, as found in:
Project > New Build Phase > New Run Script BUild Phase
I use : https://bitbucket.org/hsivank/xcode4-with-mercurial/wiki/Home
I'd like to start experimenting with Cocoa and programming for Mac OSX. I'm not terribly concerned with Objective C syntax/constructs/bheaviors at this point, but more curious as to an efficient setup on in terms of an editor and/or IDE that will get me going quickly. Is there any IDE even remotely similar to Visual Studio (since that's where I've spent most of my time over the last 7 years) in terms of it's solution/project concept? Any other tools, tips, suggestions and/or resources to get up and experimenting quickly?
I'd like to avoid a lot of the intro stuff and get into things like "If you want to create an Mac desktop application, you can use Acme IDE and set up your project like this."
I was afraid Xcode was going to be the answer! :P I tried playing around with that -- literally just getting it off the DVD and just diving in with no idea what to expect (before I even knew that you used Objective C as the language). I figured, the wise guy that I am, that I could just sort of fumble around and get a simple app working ... wrong.
#Andrew - Thanks for the insight on those config settings. Based on my Xcode first impression, I think those may help.
I'd suggest you pick a fun little product and dive in. If you're looking for a book I'd suggest Cocoa Programming for Max OSX which is a very good introduction both to Objective-C and Cocoa.
XCode is pretty much the de facto IDE and free with OSX. It should be on your original install DVD. It's good but not as good as Visual Studio (sorry, it's really not).
As a long-time VS user I found the default XCode config a little odd and hard to adjust to, particularly the way a new floating window would open for every sourcefile. Some tweaks I found particularly helpful;
Settings/General -> All-In-One (unifies editor/debugger window)
Settings/General -> Open counterparts in same editor (single-window edit)
Settings/Debugging - "In Editor Debugger Controls"
Settings/Debugging - "Auto Clear Debug Console"
Settings/Key-binding - lots of binding to match VS (Ctrl+F5/Shift+F5,Shift+Home, Shift+End etc)
I find the debugger has some annoying issues such as breakpoints not correctly mapping to lines and exceptions aren't immediately trapped by the debugger. Nothing deal-breaking but a bit cumbersome.
I would recommend that you make use of the new property syntax that was introduced for Objective-C 2.0. They make for a heck of a lot less typing in many many places. They're limited to OSX 10.5 only though (yeah, language features are tied to OS versions which is a bit odd).
Also don't be fooled into downplaying the differences between C/C++ and Objective-C. They're very much related but ARE different languages. Try and start Objective-C without thinking about how you'd do X,Y,Z in C/C++. It'll make it a lot easier.
The first document to read and digest is the Mem management guide, understand this before moving on. This is a great guide to objective-c too. Infact the developer site at Apple is very good - but you would probably want to read the Hillegas book first.
In regards to Xcode vs Visual Studio - they are different. I wouldn't say one is better than the other - Windows developers come over from VS and expect it to be the same. This is just an arrogant attitude and please don't fall into this crowd. Having used VS since the AppStudio days and Xcode for a year or so now, both have strengths and weaknesses. Xcode is something that out of the box (and especially when coming from VS) doesn't seem that good, but once you start using and understanding it - it becomes very powerful.
Also, there are a lot more tools included with Xcode et al, such as Instruments and Shark that you simply can't get with VS, unless you open your wallet, and even then IMHO aren't as good.
Anyway, good luck. I still enjoy C#, but Objective-C/Cocoa somehow makes programming fun again once you get into it...
Don't bother digging up your OSX DVD as they've released a new version (3.1) of XCode since then.
First, you'll want to join Apple Developer Connection (it's free, and you need it to access their version of MSDN) - it uses your Apple ID so if you've ever had one for the itunes store etc, it's that same username/password
Once you've done that, click on downloads, then click on developer tools, to view this page, and go for the XCode 3.1 Developer DVD
One other suggestion: If you have feature or enhancement requests, or bugs that you've run into, be sure to file them at Apple's Bug Reporter. It's the best way for developers to communicate their needs to Apple, because every issue is tracked through the system.
You might try the demo of textmate and see how you like it for working with objective-c or any other type of text really. It will import xcode project settings so you can still compile and run from textmate rather than having to go back to xcode.
Xcode is the standard for editing source files, though you can use another editor in conjunction with the command line xcodebuild tool if you really want. I used Vim for all my Cocoa editing before finally giving in to Xcode. It's not the greatest IDE in the world, but it gets the job done, and the recent 3.x releases have had some nice improvements.
The real power tool of Cocoa development is Interface Builder. IB does not generate source code like many UI tools. Instead it manipulates real Cocoa views, controls, and objects which it then bundles into an archive (nib) that is loaded by your program at runtime. Most Cocoa programs use at least one nib file, and often many more.
No matter what IDE/editor combination you choose for hacking on source files, I recommend using IB where you can. Even if you're not a fan of other UI layout/generation tools, I suggest keeping an open mind, giving "the Cocoa way" a chance and at least learning what Interface Builder can do for your development process.
AFAIK, pretty much every OS X developer uses Xcode.
That, and Interface Builder for creating the GUIs.
FWIW, try to get hold of a copy of Hillegas's book, as it's a great introductory tutorial, and the reference Docs Apple provides really aren't. (They are generally very good reference docs, however).
Cocoa is huge. The hardest part of learning how to write apps on Mac is learning Cocoa. By the way. You do not need to know ObjC (though it helps tons). You can write Cocoa apps with Python or Ruby (right in the IDE).
I agree VS is a better IDE then Xcode. But if you throw in Interface Builder and all the other tools, I'm not so sure. Mac development is not about 1 giant IDE for everything. But VS is "kinder" on the developer then Xcode is.
Also if you want to do cross platform apps look at RealBasic. A fine tool (Basic though. But it runs on Linux too.) You'd be surprised how many Mac apps are written with RB.
I've heard the books currently out there are pretty out of date. The whole ecosystem seems to evolve very fast with dramatic changes made in every OS release.
He wrote a tutorial which pulls together some Apple documentation and other tutorials which should get you started. I think it covers the basics of using the IDE, writing simple apps, and then goes on to more advanced stuff.
I've been dabbling in Cocoa for the past couple years, and recently picked up Fritz Anderson's "Xcode 3 Unleashed." Highly recommended for getting into Xcode — especially with some of the big changes 3.0/Leopard brought.
Don't forget Hillegass' defacto Cocoa bible, "Cocoa Programming for Mac OS X - Third Edition."
#peter I don't know why you had trouble with getting a simple app working, right off the bat without doing anything your app gets a lot of benefits from the Cocoa framework. If you mean you were trying to do stuff like connect a button to an action and have it print a alert on screen or something like that then yes I could see where your going with it being difficult.
The problem for me starting with Cocoa many years back is that it was so different from anything else that it had a little bit of a learning curve. Whereas many other systems are compile time oriented Cocoa is very dynamic and runtime oriented. Once you get past learning how actions hook up to classes it just becomes a matter of learning how the Cocoa frameworks work.