I spent a decent chunk of time last year building up a somewhat large Cocoa application (a telling synecdoche of how ambitious the app is: it integrates libevent with the Cocoa loop and involved writing a whole new evented Redis-backed HTTPS cache in ObjC).
But unfortunately, I got to the UI part of this project ("UI part", heh) thinking "this is going to be so much easier than webdev, look at all these tools!, and that was a crushing disappointment; getting anything reasonable on the screen has been intensely painful, and is if anything much harder than CSS3+JQ is on modern web apps.
I'm thrilled to hear that at least to some extent, it isn't just me, and making a good-looking Cocoa app (especially your first) is just very hard.
The "no layouting engine" issue mentioned in the article applies to Cocoa Touch in the same way as it does to Cocoa, with the added wrinkle that if you want to support autorotation, this bites you even harder. Yes, there's the "struts & springs" system, but it's very limited - no equivalent to 'min-width' or 'max-width', and yeah I can't believe I'm citing CSS as a good example. It also doesn't help at all if you need to change the relative placement due to autorotation, or if you need to adjust positioning depending on content.
Styling is another issue - most UI elements can't even have custom colours. (this will improve with iOS 5, but not until iOS4 compatibility is no longer an issue) The default button looks awful. You have to come up with your own table view cells for pretty much anything but the most bare bones of lists.
In the end, I actually built my own fully fledged layouting system, which is content sensitive, has a fairly flexible elasticity system and supports a "flow" layouting mode which is somewhat similar to the way display:inline-block; HTML elements are laid out (but with grow-to-fit). I also built styleable versions of some of the views. If only I wanted to be in the business of building iOS apps, I'd be extremely well prepared at this stage. :-)
My recent foray into Cocoa on the Mac actually has been easier, but that's probably because you can get away with using the default widget styles. Apart from table cells anyway.
HTML+CSS being easier and more expressive than Win32 didn't hurt either. Shared codebase!
I haven't written any apps in Android yet but I've been studying their UI docs and it's clear that their UI kit was informed by the web. If you squint at their code samples they don't look all that different from HTML5 apps: layout in markup, wireup event handlers, go.
XCode Interface Builder baffles me still. It's really garbage compared to Visual Studio, IMO. Really a shame.
For power users, look elsewhere.
I think it's a very simplified view of source control and badly needs to be iterated to appeal to power users.
That said, I'd recommend it for novices to source control.
I don't know why people are trashing this app. It's not exactly hard to use the command line if you don't like this app.
Using a GUI on git is just a convenience, and probably most useful for new git users.
This sounds like a wrong design decision. I wish nobody could log into my github account using anything but my SSH keys.
This is also true of my AWS account: my ec2 instances are protected by SSH keypairs, but if anyone gets my AWS password, he has full control over everything.
I'm not a security expert, but SSH keys feel way safer than passwords, especially with all those recents article showing how easy it can be to bruteforce passwords.
And if you use ssh-agent, I'm pretty sure it doesn't even send your private key; SSH creates a challenge that your key is used to compute, so even someone eavesdropping with a keylogger on the server won't be able to sniff your password.
If someone steals/owns your personal machine it's actually much easier to gain access to SSH Keys than find your username/password (since an alarming number of people use passwordless ssh keys).
Aside from that though — SSH Keys are probably the biggest barrier to people being able to use and contribute with GitHub.
The barrier to entry of writing software doesn't need to be zero. If a person is going to write code, they should also learn some of the basic tools of the trade.
Then I'll amend gregschlom's comment to further say I wish passwordless ssh keys did not exist.
Although I agree that SSH keypairs feel more secure than a username/password, it would make setting up a new machine for development a lot easier than generating a new SSH keypair and adding it to my GitHub (or any other git server) account.
That seems like the best compromise of security and easy of use to me.
http://speedbird.wordpress.com/2010/06/25/what-apple-needs-t...
Nailed it. Great article. Apple's hardware is as beautiful as ever but their software UI seems to have gone right of the rails. I wish Google's wasn't aping that dumb page curl effect in their own books app.
From the book:
"His buildings are austere, logical, perfect, each a single thought in stone. He believes that buildings, like men, have souls, and that no part of a building should in any way betray its soul. No building should borrow its parts from others or apologize for its own shape. No building should present a false front."
And another quote:
"The buildings in these drawings are like none ever built on earth. They seem severe and simple at first glance, but closer observation reveals the strict tension of thought and method, a cold, beautiful logic behind each wall and pillar. Every building seems to have a soul."
I hope Apple turns down the woodgrain knob and cranks up the cold, beautiful, and logical knob in their future designs.
It's still the sort of thing where you want to check out, change the project, and check back in quick to avoid conflicts. I can imagine it getting worse with far-distance branches though.
It's not too different from a makefile, except you'll get a better error message when you muck up your makefile.
> Unfortunately for everyone involved, every OS X application that’s showed up over the years gave up and tried to turn CLI commands into buttons.
It's my understanding that for a really long time there was no linkable library for interacting with Git. So unless these devs wanted to first write said library they were pretty much left with putting buttons on the CLI.
You might say "Well they should have written one, then!" but that is quite a risky capital expense on a piece of software that could easily flop. GitHub did it (with Summer of Code's help), but they have umpteen uses of such a library even if nobody uses GitHub for Mac.
> It blows my mind that no one tried to do anything special. Git (and its DVCS cousins like Mercurial & Bazaar) provide an amazing platform to build next generation clients — and it’s like the entire OS X ecosystem left their imagination at home.
I dunno, I think GitX (especially its forks) does some pretty special things, including making it dead simple to stage/unstage/discard single lines of files.
Cocoa is probably the framework best suited for incorporating web views, and tons of apps do this: Mail.app, iTunes, Aperture, Colloquy, etc. etc. Use the right tool for the right job, if you have something that is going to have a lot of flow-based layout, then by all means use WebView.
It's kind of like refusing to use an NSTextView, then complaining about having to lay out text yourself.
What about conflict resolution? That's one of the hairiest, least-user-friendly scenarios in my experience.
Though, I think the difficulty of making a complex GUI in Cocoa shines in the OS X world. It's a lot harder to make a working UI, so you want to get the design right the first time, so you don't have to go back and re-do.
They're document-oriented, rather than project oriented (or if you present git repository as bundle, you lose nifty per-document presentation).
iCloud may force creation of versions (commits?)
There's no branching. There's lots of locking and exclusive access.
This is getting a lot better in Lion. If you browse the WWDC 2011 videos, look for Session 103 "Cocoa Autolayout".
I hope that means they plan to build a git GUI client for Windows, the poor bastard child of git support.
Apple wouldn't be able to politely ask people not to blog about their stuff.
Branching projects is hard in XCode? Zip up the project files and back up the revision... in I don't know, a source code repository? LOL!
None of the re-writing is required in Xcode for your app. Design the app, then make it in Xcode. If you have to make revisions to the design of your app, go back to designing it. Most of the code can be re-used, but clearly you haven't finished designing the app yet...
Interesting take on the initial experience. But instead of casting about for blame, it might be better to ask why your processes are going wrong.
