Sounds like great work, Sean!
> OK, I have autoreconnect doing what I want. Before I checking that
> which I can checkin (I still can't figure out how to check-in the
> modified NIB files -- Is there a reason we aren't using tarball NIBs?
> Or the CVS checkin script that handles this?), I thought I'd ask
> people's opinion of something.
If I recall correctly, when I first put Chicken on SourceForge, the
cvswrapper scripts weren't working properly on OS X. So now we're
stuck with the directory-based nibs.
I check them in via Terminal. I just cd to the appropriate directory
and do "cvs ci <whatever>". I installed some weird plug-in back in
the Project Builder days that let me use cvs from within PB, and I've
never been able to get it to work in Xcode as a result. At least, I
assume that that's why it's never worked for me. :)
I'm most definitely not a cvs guru...
> I originally just wanted a reconnect-after-wakeup. But I kinda had to
> do it in two stages: Enabled reconnect, and then only enable reconnect
> after sleep. So right now I have two sliders for the reconnect timers:
> How long a connection must be connection before autoreconnection will
> happen (0, the default, means it won't autoreconnect), and how long
> after we wake up to *disable* reconnection (0, the default, means we
> ignore wakeup as a reconnection trigger).
There's a problem here, unfortunately. I'm a giant fan of Apple's
"keep the interface drop dead simple" philosophy, and that means not
exposing UI for things that have reasonable defaults that are
unlikely to be changed.
Here's how this should work: If an existing connection drops for any
reason (server goes down, client went to sleep, whatever), Chicken
should attempt a reconnect automatically. If the reconnect succeeds,
the user shouldn't need to know that anything even happened. If it
didn't, the user should be told that the connection dropped. If the
connection drops within some short timespan of a successful
reconnect, the server is flakey and we should allow the connection to
drop and tell the user what happened.
I like the idea of using preferences settings for all of this, but I
don't like the idea of exposing those settings in the user
interface. The default settings are reasonable ones in 99% of all
cases, so we don't need to clutter our interface with them. That
other 1% can use "defaults write" or edit the plist to change the
And I think there should be just two preferences key - a boolean that
says whether we autoreconnect a dropped connection or not, and the
length of time that a connection must exist before we can attempt an
auto-reconnect. I suggest default values for these of "YES" and 5.0
For consistency, these preferences should be accessed through +
I'm sorry that you did the interface work unnecessarily, hope you're
not sore about it.
> I'll go figure out window positioning next, and if I don't hear
> anything by then, I'll just submit the changes as I have 'em. :-)
Did we ever decide on how window positioning should work? I think
"center all windows" is fine. I think "remember window position
based on server unless server screen size has changed or we don't
know the server, and then center the window" is better.
But as I said before, I'm lazy, so I'd probably just center 'em all. :)