Updates from July, 2009

  • Subversion Client Issues

    mike 7:17 am on July 13, 2009 | 7 Permalink
    Tags: gui, ,

    I use subversion, and won’t switch to something newer for a while, so it’s worth looking at how to polish that old hammer. I’m used to using the command line svn, or emacs. But recently I decided to try out a few of the nice GUI clients that are around, including Versions, ZigVersion and Cornerstone.

    Of these, the only one that’s polished enough to lure me away from emacs and seems to support my favorite mode of working is Cornerstone, and it still gets it a little wrong.

    I like to write log comments while looking at (and scrolling through) the diffs for the files I’m committing. This means I want a text field for writing log comments on the same screen as the diffs, that isn’t modal, and doesn’t stop me from moving around between multiple diffs.

    As far as I could tell, I couldn’t get the comment field and the diff display shown together in Versions, and while I could in ZigVersion, that app had a subpar diff display and lacked polish overall, missing key shortcuts where I’d expect them, for instance. Cornerstone almost lets me do what I want, but it displays the comment field in a modal sheet, so I have to cancel to change which diff I’m looking at.

    This is easy in emacs, but I like a nicer diff GUI. Am I just missing something? This feels like a natural workflow, so it seems strange that no clients support it well.

     
  • iCal's Text Field Jumble

    mike 2:38 pm on November 2, 2008 | 0 Permalink
    Tags: , , ,

    I’ve written here before about text fields, particularly the problem of having a good-looking ‘display’ mode and a separate ‘edit’ mode for data you don’t edit so often, like in AddressBook.

    The most recent version of iCal decided that events are write-once-read-many as well. You now have to use cmd-E to get into edit mode, while cmd-I just gives you a small display mode.

    I’m mostly OK with that, although I find I edit events about as often as I look at their info windows – after editing I usually just deal with alarms, not the events themselves. The casual glance at the time and title is always enough – I think either you’re looking at the time and title or you’re editing. I don’t see the appeal in the new ‘info-only’ mode (if it’s actually new – it seems new.)

    However, the change does highlight the jumble of editable text fields and text-like fields in the edit window:

    The “Add Attendees” link and the “None” placeholder for url act the same – you click on them, and enter text. One’s a link and one’s mute gray text. Why? For my part, I think the gray text is too understated, and the link is too garish.

    There are other differences: you can tab to the “url” field, but you can’t tab to “attendees”… until you add one, then you can. Once you click on either of them, the url field pops up a plain white raised NSTextField, but the attendees field is sunken and translucent, apparently an NSTokenField?

    Both of the blue links could also be buttons. I’m still not completely sold on replacing buttons with links, but I can understand the trend. I think a small plus-sign button would be fine for “Add File”, though, and “Attendees” ought to be a text field. Why force the user to use the mouse when adding data to an event?

    All in all, I think the “Add Attendees” link/field is pretty strange. I’m curious if I missing a precedent somewhere.

     
  • PyObjC notes

    mike 11:07 am on February 1, 2008 | 0 Permalink

    I’ve been hacking around with PyObjC, the Python-ObjC/Cocoa bridge recently, and it’s quickly becoming my favorite way to write Cocoa apps. It’s really natural to mix Python idioms with Cocoa objects.

    The latest version of PyObjC is 2.0, it’s installed by default on OS X 10.5, and XCode now includes templates for starting a PyObjC project. There’s even code autocomplete in XCode for PyObjC and IB integration, so aside from some smart-indenting issues, writing PyObjC in XCode is almost as natural as writing in ObjC.

    I thought I’d post a few nice shortcuts and tips here.


    You can use tuples for NSRect/Range/Point, for instance, this -

    r = NSInsetRect(((0, 0) ,
                     (100, 100)),
                    10, 10)
    

    creates this NSRect -

    NSRect origin=<nspoint x=10.0
                           y=10.0>
           size=<nssize width=80.0
                       height=80.0>>
    


    Passing python arrays as NSArray instances (and dictionaries as NSDictionaries) works great, but sometimes you need to pass a C array. The Python ‘array’ module handles that nicely:

    import array
    g = NSGradient.alloc().
       initWithColors_locations_colorSpace_(
        [NSColor.whiteColor(),
         NSColor.blackColor()], <br/>
        array.array('f', [0.0, 1.0]),
        NSColorSpace.deviceRGBColorSpace())
    


    ObjC selectors are just python strings in PyObjC.

    defNC.addObserver_selector_name_object_(self,
      'windowDidResize:',
      NSWindowDidResizeNotification,
      self)
    # or
    self.performSelectorOnMainThread_withObject_waitUntilDone_('doIt:', None, False)
    # or
    if o.respondsToSelector_("fun:"): return o.fun_(a)
    


    Finally, something that comes in handy when working with KVC, the ‘_’ method now defined on NSObjects in PyObjC:

    o = <some ObjC object>
    print o._.myKey
    o._.myKey = 44
    # is equivalent to:
    print o.valueForKey_('myKey')
    o.setValue_forKey_(44, 'myKey')
    


    That last example is straight from the NEWS page, where lots of other useful info can be found.

     
  • The editing pass

    mike 12:41 am on October 9, 2007 | 14 Permalink

    Anything worth writing is worth re-writing. This applies to code as well as prose.

    I give paper sections and important emails a while to sit after I write them, and they always benefit from another look with fresh eyes. I think that doing this with code is worth thinking about.

    Once you get a piece of code to the point where you believe it works – it’s passing its tests – go back over it and edit it. That is, go back and edit it for clarity, flow, and style. Just as if it were an essay.

    This is particularly important for tests. If a test fails, it should tell a clear story that explains exactly what failed, and what it was expecting.

    Things to consider editing out are vague variable or function names, and non-idiomatic shortcuts. Control flow can get tangled when working out a solution. Make it obvious. One-liners often don’t tell the full story. When you come back to a piece of code, you know the chase. It’s the first loose thread of a bug, a failed test, or an occurrence of a symbol you need to refactor. What you need is the story around it, and solid code will fill that in.

    You can learn this by sharing your code or by waiting a while and reading it over again. It’s easier said than done – I don’t always do it, but I do know: an editing pass can do you good.

    Something to think about: would a professional code editor help or hurt in the long run?

     
  • NSLocalizedString can set errno

    mike 10:27 am on July 10, 2007 | 2 Permalink

    This is a short one, but it might help someone with debugging someday.

    A while back, we had some code that was checking errno, then using the NSLocalizedString macro to get a localized error message, but it checked errno again later. Only the app isn’t localized yet. There’s no Localizable.strings file, so when NSBundle -localizedStringForKey gets called, even though it fails gracefully, it still ends up setting errno to “ENOENT”, or “file not found”.

    So the lesson is – in case you’re seeing weird behavior where errno is changing after you check it, make sure you’re not using any system calls that might set it.

     
  • Mac programming collaborative bookmarks?

    mike 2:54 pm on February 7, 2007 | 9 Permalink

    I usually like the link selection I get from the Joel Reddit, which usually has good software-related essays at the top. It seems to avoid links to uninformed rants about consumer electronics or industry politics, for which I have no use.

    I’d like a social links site for software professionals on the Mac – does one exist?

    Or am I missing the point of these sites, and there’s a feature in each of them to get only the links I want?

    I’m curious – how do you get your mac-related links?

    Update: From the comments and some emails, I heard three main ways. A few people just rely on the feeds they check regularly, trusting that if something’s interesting enough, eventually someone they read will post about it. This was basically my strategy.

    A few other people plugged Scott Stevenson’s Cocoablogs.com, which I remember seeing a while back but overlooked when I wrote this post. He’s doing a good job of collecting interesting links and highlighting blogs you might want to check out – keep an eye on that site. To paraphrase Scott, he wants cocoablogs to be the ‘anti-digg’, a site where you can guarantee someone actually read the article before they recommend it to you. I’d say that’s a good idea – I don’t have patience for mob voting.

    Finally, another suggestion was to follow the ‘cocoa’ tag on del.icio.us, something else I should have thought of – this is nice and social like digg and reddit, but it seems less likely that someone will tag an article they haven’t read, so I think it’s a stronger vote.

    Thanks, everyone, for the suggestions!

     
  • Leopard Tech Talk, Jan 19: LA

    admin 3:10 pm on January 9, 2007 | 4 Permalink

    I couldn’t make it to WWDC last year, I’m not at Macworld this week, but I will be making it up to LA on the 19th for the Leopard Tech Talk, to catch up. I’ll probably be there the day before, owing to traffic and an inability to wake up early.

    If any area mac devs are meeting up around then, drop me a note.

    I wonder if we’ll know anything by then about developing for the iPhone.

     
  • Leopard Developer Technologies

    admin 6:36 pm on December 12, 2006 | 0 Permalink

    If you’re like me and don’t have a Leopard Preview, and if you haven’t seen the Leopard Developer Application Technologies Overview, you should take a look. There’s some pretty interesting stuff coming down the pipe. I like the Calendar store, which lets any application work with the iCal calendar info in much the same way as AddressBook.framework opens up the Address Book. Maybe we’ll see some enterprising developer add support for travel time in calendar display?

    I also like the Applescript Bridge – an idea whose time came YEARS ago. It’s buried under the section titled “Picking Up the Pace of Cocoa Application Development”. What a major simplification!

    I like that a lot of the new advances in Leopard seem to involve making it easier for apps to work together and share data. My data should belong to me, not to the application I first entered it in. This is as much a usability issue as it is a data safety, vendor lock-in and openness issue.

     
  • AutoFill: BibDesk and DC-HTML

    mike 7:55 pm on August 28, 2006 | 2 Permalink

    For my first contribution to BibDesk in a while, I’ve added the ability to read Dublin Core metadata when it is encoded in HTML META tags on a web page.

    What this means is that when using the “New Publications from Web” feature, some sites you browse to will have the publication’s information filled in for you, so you don’t have to type anything at all. The Eprints.org open archive software does this, so check out their list of archives for examples to test it out on.

    It’ll be in the next version, which isn’t scheduled yet, so if you’d like to try it out sooner, see the nightly builds page and heed its warnings.

    If you publish web sites with one-page-per-pubcation and want info about embedding DC terms in your meta tags, see the Dublin Core recommendation.

    If you want to support AutoFill for a site that doesn’t have one page per publication, or would like to provide more metadata, I suggest waiting for the citation microformat. Feel free to ask why…

    Update: I made a 12-second movie of how it works – BibDesk, EPrints and Dublin Core

     
  • TextStructure screencast

    mike 2:54 am on August 19, 2006 | 0 Permalink

    In case you had no idea what I was talking about in the last post, I’ve put together a hasty screencast with no script, no soundtrack, and no editing.

    In the video you can see a few things:

    • 0:00: I have found a way to show you the palm trees on my street without showing you the rest of my street. Lucky you!
    • 0:08: After I press control-z (not my final choice for a keystroke), we get a nice little display of sections in your file. Right now I have it set up to show me ObjC methods.
    • 0:13: It shows you where you are.
    • 0:16: … and where you’ve been.
    • 0:18: you can jump around by clicking on the section header list.
    • 0:30: you can search through the contents and it shows which sections match.
    • 0:38: you can also choose from a list of other ways to slice your text – described by a bunch of regexps in a file you can tweak without recompiling the plugin.
    • 0:49: I use Snapz Pro X and Quicksilver, which you know because I also tried to use iMovie HD and couldn’t find the “Don’t make my imported movies look like crap” option, so I just uploaded the original movie with no funny titles. Bummer.

    Also, the leverage-discuss mailing list is up now, if you want to ask how to use it.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
esc
cancel