GitHub Issues client built w/ Cappuccino, Atlas, NativeHost and Node on Heroku(cappuccino.org)
cappuccino.org
GitHub Issues client built w/ Cappuccino, Atlas, NativeHost and Node on Heroku
http://cappuccino.org/discuss/2010/05/13/github-issues-cappuccino-app-desktop-and-web/
10 comments
You could do it with a plain old text editor afaics. It looks like a regular Cappuccino project. (edit: that is, if you only want to deploy it for the web. I don't know about building a desktop version)
Btw it does support labels, they're just not displayed in the list. If it showed labels in the list, supported filtering, and showed label colours I would use it for github issues 100% right now.
It's a really cool app but I'm more excited about it being open source.
Btw it does support labels, they're just not displayed in the list. If it showed labels in the list, supported filtering, and showed label colours I would use it for github issues 100% right now.
It's a really cool app but I'm more excited about it being open source.
Wow, it’s absolutely lovely. Feels like a desktop skin of GitHub.
Scrolling with the mouse wheel is painfully slow but everything else is awesome.
I think it's a cardinal sin for Cappuccino to replace native scrollbars and native scrolling. Maybe your UI gets to look a teeny bit more unified, but scrolling is almost as primitive an interaction as mousing. It is carefully tuned on every operating system and changing its behavior for one part of my screen always sets off my nerves. This non-native feeling is the sort of thing that Flash usually gets flak for.
Would you use a website if it messed with your mousing speed or your cursor? You would you grind your teeth. I feel similarly about non-native scrolling.
The only exception I will grant is for people developing fling scrolling for webapps on the iPhone and iPad, because that is carefully tuned to mimic one operating system on one kind of device. Anything for more general web browsers, however, can make no assumptions and should leave my scrolling alone.
Would you use a website if it messed with your mousing speed or your cursor? You would you grind your teeth. I feel similarly about non-native scrolling.
The only exception I will grant is for people developing fling scrolling for webapps on the iPhone and iPad, because that is carefully tuned to mimic one operating system on one kind of device. Anything for more general web browsers, however, can make no assumptions and should leave my scrolling alone.
There's a good article by Tolmasky addressing this here: http://www.alertdebugging.com/2009/11/04/mockingbird-cappucc...
Bottom line is that the scrolling is beautiful and works well, why would users not like it?
Bottom line is that the scrolling is beautiful and works well, why would users not like it?
I've already read it. The scrollbar itself is pretty, but you cannot exactly capture the precision of a mousewheel or in my case, a two-finger scroll event. For me, the two-finger scroll speed is disturbingly faster than other windows that scroll, which makes navigating Cappuccino apps unnatural compared to normal pages. For the git issue browser, where long lists and comment threads are everywhere, it distracts from my ability to use the app.
You won't be able emulate scrolling fully until there is a standard for mousewheel events that includes full X/Y delta information instead of uniform discrete steps. I haven't seen any plans for this in HTML5 or elsewhere. And at the end of the day, anything done via JavaScript events is just not going to match the reponsiveness of the browser scrolling the element natively; for such a fundamental operation, the cosmetic benefit of a reskinned scrollbar just does not outweigh the UI friction.
You won't be able emulate scrolling fully until there is a standard for mousewheel events that includes full X/Y delta information instead of uniform discrete steps. I haven't seen any plans for this in HTML5 or elsewhere. And at the end of the day, anything done via JavaScript events is just not going to match the reponsiveness of the browser scrolling the element natively; for such a fundamental operation, the cosmetic benefit of a reskinned scrollbar just does not outweigh the UI friction.
Actually, on the iPad there are these irritating white dividers between the scroller's head and it's body.
I actually found that the trackpad on my MacBook Pro scrolled much faster than usual.
For me it scrolls pretty fast. I am using Chrome on OS X. What browser are you using?
I'm guessing you guys at github didn't start out as Objective J developers... how was transitioning to the framework? Any lessons to share with us?
Oh, I thought that it was Cappuccino blogging about a Github client written by Github guys (I think because it uses the Github mascot in the UI) but now I see it was actually built by experienced Cappuccino guys. I think? I'm not sure anymore. So... I guess the question should be expanded to:
Hey anyone who has switched to Objective J (but not originally coming from Objective C background)... how was the transition for you? Any lessons to share with us?
Hey anyone who has switched to Objective J (but not originally coming from Objective C background)... how was the transition for you? Any lessons to share with us?
Hash signalling (history support) seems not to work?
can you be more specific?
Clicking the back and forward buttons in Chrome 5 beta doesn't work.
Wow, this is great. I have few questions, is the per-item url now part of Cappuccino or something custom for this app? With this in place would it be difficult to add back button support?
There's so much going on here my head hurts a little. :-)
That is the most buzzword compliant thing I will hear about today.
Would Atlas be required to make that change, or can it be done from a plain-ol' text editor?