Live data from Hacker News

Designing GitHub for Mac

warpspire.com

11–20 of 80 posts

Re: Designing GitHub for Mac

#11
Without going into whether I agree with his assertions on Cocoa, if it seemed so much easier to do with web technologies, why didn't he just do it with web technologies?

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.

Re: Designing GitHub for Mac

#12
post #4

What a f'ing fantastic article. Thank you so much for writing this. 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 goi…

I'm not a web guy by any stretch of the imagination, as you well know, but I find doing webdev really easy compared to any GUI library out there. If I can say "ok, this is only going to work in embedded Webkit/Chrome/whatever", I can whip up something that's pretty and functional in no time at all. When faced with the same task in GTK/Qt/Wx/whatever, I fail miserably. I've done a good bit of both, but I doubt I'll ever go back to making desktop apps -- I can always embed a webserver into whatever I'm building, and do the UI that way...

Re: Designing GitHub for Mac

#13
> Eventually, I (well, many of us) decided that better native clients (OSX, Windows, Linux, Eclipse, Visual Studio, etc) was the best way to grow GitHub.

I hope that means they plan to build a git GUI client for Windows, the poor bastard child of git support.

Re: Designing GitHub for Mac

#14
post #2

Has anyone been using this client, is it worth using as far as GUI's go?

I'm curious to hear from people who don't know - and don't want to learn - git on the command line. If this gets those uses checking their work into repositories, it will be a net win for version control.

Re: Designing GitHub for Mac

#15
post #2

Has anyone been using this client, is it worth using as far as GUI's go?

I've been using it. I like it a lot, but I can't figure out how to "git add ." in it!

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.

Re: Designing GitHub for Mac

#17
He makes great points about MacRuby. I started tooling around with it for an app a few months ago, and though it was a great interface, it didn't make working in Cocoa any easier, and I still had to learn a lot of weird technology choices in Cocoa.

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.

Re: Designing GitHub for Mac

#18
post #4

What a f'ing fantastic article. Thank you so much for writing this. 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 goi…

I had the same experience with my first Cocoa Touch/UIKit project. The GUI stuff far eclipsed the rest of the app in terms of development effort, which I did not expect. This hadn't been the case with previous GUI stuff I'd done (Windows apps, game UIs and the web), and took me completely by surprise.

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.

Re: Designing GitHub for Mac

#19
post #4

What a f'ing fantastic article. Thank you so much for writing this. 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 goi…

I had the same experience with my first Cocoa Touch/UIKit project. The GUI stuff far eclipsed the rest of the app in terms of development effort, which I did not expect. This hadn't been the case with previous GUI stuff I'd done (Windows apps, game UIs and the web), and took me completely by surprise. The "no layouting engine" issue mentioned in the article applies to Cocoa Touch in the same way as it does to Cocoa,…

Any interest in either open sourcing said layout system or perhaps even selling it to those of us who struggle with these sort of problems (a la Sensible TableView)?

Re: Designing GitHub for Mac

#20
Great article for sure, but I take issue with these bits:

> 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.

Post reply on HN