Thread: [cotvnc-devel] AutoReconnect working
Project superseded by http://chicken.sourceforge.net/
Brought to you by:
smeger
From: Sean K. <ka...@ge...> - 2005-06-26 06:52:00
|
Hi all. 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. 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). Does this make sense? If so, I have to figure out how to set the second slider (wakeup timeout) to 0 and inactive if the reconnect slider is 0. And an easy way to explain this. Alternatively, I'm full of it. Either you want reconnection on a closed connection, or you don't. 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. :-) Sean |
From: Jason H. <sm...@ge...> - 2005-07-01 08:14:16
|
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 defaults. 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 seconds. For consistency, these preferences should be accessed through + [PrefController sharedController]. 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. :) Jason |
From: Jared M. <jmc...@df...> - 2005-07-22 16:19:06
|
I've been running into the auto-reconnect feature a lot today. It appears that we may have problems connecting to the newest development version of TightVNC on Windows (which is expected to become the final release with no changes). That problem is showing me that we may have some other problems with auto-reconnect, namely that the user is not told why the initial failure occurred. This may make it harder for us to track problems talking to different servers (and some users might not even really understand that there is a fixable iddue). In this case, I don't know if the problem is an encoding error or something else without dropping into the code. Jared |
From: Jared M. <jmc...@df...> - 2005-07-23 19:13:39
|
Have you guys seen this tool: http://www.blue-tec.com/locsuite/manager.php I haven't had a chance to fully look at it yet, but it might be useful in the localization process since we have to use such a distributed localization method. It may also make it easier for people to create new localizations (not to mention update existing ones). Jared |
From: Jason H. <sm...@ge...> - 2005-07-24 04:27:26
|
This looks very nice. I've been using my own hacked-up version of nibTranslate, but it's rather buggy (even after my hacking), so I'm definitely open to using something better. Checking it out... Jason On Jul 23, 2005, at 12:09 PM, Jared McIntyre wrote: > Have you guys seen this tool: > > http://www.blue-tec.com/locsuite/manager.php > > I haven't had a chance to fully look at it yet, but it might be > useful in the localization process since we have to use such a > distributed localization method. It may also make it easier for > people to create new localizations (not to mention update existing > ones). > > Jared > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > cotvnc-devel mailing list > cot...@li... > https://lists.sourceforge.net/lists/listinfo/cotvnc-devel > > > |
From: Jared M. <jmc...@df...> - 2005-07-24 23:18:56
|
I commented about this in my AutoReconnect Working email yesterday, but haven't heard anything yet. There appears to be some serious issues with communicating with the latest release candidate of TightVNC even with the CVS code. Has anyone else tried this? Because of the auto-reconnect code, I'm having issues figuring what is causing the disconnected (no longer brings up the error box). Is there a log somewhere that shows the reasons for the disconnect? Jared |
From: Jason H. <sm...@ge...> - 2005-08-10 01:12:08
|
I finally got around to trying this. I had a hell of a time getting Chicken to connect - it was just hanging at the Connect dialog. Turns out I didn't have the Windows Firewall set to allow the new version of TightVNC access. Once I got the firewall settings correct, I didn't have any problems. Except that TightVNC is dog-ass slow compared to RealVNC. :) Jason On Jul 24, 2005, at 4:18 PM, Jared McIntyre wrote: > I commented about this in my AutoReconnect Working email yesterday, > but haven't heard anything yet. There appears to be some serious > issues with communicating with the latest release candidate of > TightVNC even with the CVS code. Has anyone else tried this? > Because of the auto-reconnect code, I'm having issues figuring what > is causing the disconnected (no longer brings up the error box). > Is there a log somewhere that shows the reasons for the disconnect? > > Jared > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > cotvnc-devel mailing list > cot...@li... > https://lists.sourceforge.net/lists/listinfo/cotvnc-devel > > > |
From: Jason H. <sm...@ge...> - 2005-08-10 06:50:34
|
Okay, I got TightVNC to bump my connection off using the DFMirage hook thing. Whenever I log in or log out of my Windows user account, it was terminating my connection. I made a slight change to Chicken so that it logs the reason the connection was killed to the Console before auto-reconnecting. Other than that, connections with the Tight server seemed to work, but performance was serious crap. Connecting on a LAN, I was seeing lags of up to 10 seconds. Watching the remote cursor follow the path that the local cursor had traversed 10 seconds earlier was fun for a moment, very tedious thereafter. I can see why you were so eager to do some event voodoo. I also noticed that the longer I kept the connection open, the more latency I saw. A minute was about the limit of my tolerance. Now, I DON'T see any of these issues when connecting to a RealVNC server on the same Windows box. Does the Tight server just suck, or are we doing something wrong that Real can handle and that Tight can't? Connecting to RealVNC feels nearly as fast as being physically present at the Windows box. I'm gonna put UltraVNC on that Windows box and play against it a bit. If things are okay with Ultra, I'll conclude that Tight just sucks. Jason On Aug 9, 2005, at 4:24 PM, Jared McIntyre wrote: > I was using the DFMirage hook display driver. I don't know if the > issue is related (don't have time to check without it). > > Jared > > > |
From: Jared M. <jmc...@df...> - 2005-08-10 16:56:19
|
Okay, sounds good. I didn't realize the server had such nasty performance issues. I'll have to change servers on that machine. Where are we logging to? Is there a file somewhere? Speaking of events. Has anyone else played with the code in my view? I've been using it almost exclusively, and I'm pretty happy with it. It even seems to speed up connections to fast servers. What do others things about it? Jared On Tue, 9 Aug 2005 23:50:19 -0700 Jason Harris <sm...@ge...> wrote: > Okay, I got TightVNC to bump my connection off using the DFMirage hook thing. Whenever I log in or log out of my >Windows user account, it was terminating my connection. > > I made a slight change to Chicken so that it logs the reason the connection was killed to the Console before >auto-reconnecting. > > Other than that, connections with the Tight server seemed to work, but performance was serious crap. Connecting on >a LAN, I was seeing lags of up to 10 seconds. Watching the remote cursor follow the path that the local cursor had >traversed 10 seconds earlier was fun for a moment, very tedious thereafter. I can see why you were so eager to do >some event voodoo. > > I also noticed that the longer I kept the connection open, the more latency I saw. A minute was about the limit of >my tolerance. > > Now, I DON'T see any of these issues when connecting to a RealVNC server on the same Windows box. Does the Tight >server just suck, or are we doing something wrong that Real can handle and that Tight can't? Connecting to RealVNC >feels nearly as fast as being physically present at the Windows box. > > I'm gonna put UltraVNC on that Windows box and play against it a bit. If things are okay with Ultra, I'll conclude >that Tight just sucks. > > Jason > > > On Aug 9, 2005, at 4:24 PM, Jared McIntyre wrote: > >> I was using the DFMirage hook display driver. I don't know if the >> issue is related (don't have time to check without it). >> >> Jared >> >> >> > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > cotvnc-devel mailing list > cot...@li... > https://lists.sourceforge.net/lists/listinfo/cotvnc-devel |