I want to stress that this post is because Chicken of the VNC official binaries are flawed in my opinion, I am not associated with the project nor is the person who coded this build. This was compiled as a Universal Binary of the software but it hasn't been tested on any PPC Mac's as of yet. I do have a PPC build from when I had a powerbook but this one was compiled on my Macbook Pro c2d. Since there is no official universal binary (although you can just re-compile that last build from them) I thought this might be helpful to share here.
What is this?
This is a modified build of Chicken of the VNC that doesn't set the default value at 5900 for the port while displaying 0. Instead the code was rewritten to allow you to type in any port and it will honor the actual number you give it. So if you want to connect to a server at 17000 then you just type 17000 into the port box now. Also the 0 does still play nicely as port 5900 because that was an easier fix for him than trying to force the program to make new connections display 5900 instead of 0.
Why bother doing this?
The developers of Chicken of the VNC decided to let you add or subtract from 0 to get the port you want. So if you setup a VNC client on port 17000 you would have to subtract 5900 from 17000 and use 11100 in the place of the standard 0. I remotely use computers all the time through VNC and after complaining about this to my good friend Dave Stricker he took an hour or two of his time to fix the problem for me.
I am hosting the downloads and since you have no reason to trust me I am also including the source code in a separate download.
Chicken of the VNC Modified Application
Chicken of the VNC Modified source code with builds intact
Nothing in the credits of the software has been changed, aside from functionality this is the same looking application as we know and love.
I'm confused. The publicly released Chicken of the VNC 2.0b4, released on January 18, 2006, is a universal binary. And the previous public version, 2.0b3, released on August 22, 2005, includes the ability to specify a port number by appending :port to the host name. Like "myhost.com:17000".
Well the universal binary aspect may have been compromised by my friend having compiled the first build of this on a PPC powerbook last year when 2.0b4 came out. I was using that build on my new macbook pro up until a couple days ago when getting around to finding his old source and recompiling it.
In any case the official build does not work as you say, if you put in port 17000 in the display box then it subtracts 5900 from the 17000 as I say.
To be fair I just evaluated your post more in depth by returning to my Macbook Pro. You are right that by typing in a domain followed by a :port you can connect to any server. My question then is what in the world is the display there for? doesn't it make more sense to just modify that to say port and have users type in a port there?
Maybe I am just missing something.
The VNC specification talks about "display numbers", generally zero through nine. These correspond to ports 5900-5909. There's a lot of existing documentation on various platforms referring to these numbers, hence our support for them.
Well thats interesting but from my limited knowledge on the vnc specifications it seems like an extremely useless feature, port adjustment would accomplish the same thing... why not just have the port box there? In any case it's really your software, thank you for making it because its extremely useful. Now that I have been educated about the colon working correctly in the address field I may discontinue using the build in this thread, although I hope in the future you would consider removing the display option from the standard gui (maybe drop it into preferences as an optional display) as it probably confuses more people than just I.
My 2p's worth..
I use cotvnc quite a lot (thank you very very much!) and I must say the Display thing can be pretty confusing. As this software is aimed more at the techie than the casual user I think dialling in the actual port number would be more logical, especially if you're dealing with several 'clients', as you can 'see' the port used immediately, rather than having to translate the Display number into the port number.
Keep up the good work though.
While I basically agree with everything said about display numbers being confusing, I'm not comfortable getting rid of them because a lot of VNC servers are configured using display numbers as the default mechanism for running multiple VNC servers. See, for example, this documentation from RealVNC:
and search for "snoopy:0".
Basically, there's tons of documentation outside of the OS X world that talks about display numbers, and it would be very odd of Chicken not to support them.
Smeger I know I approached this whole separate build kinda rough. I really didn't think of this project as active (again sorry if I am being rough) because its been over a year since it's been updated. This still doesn't support encrypted VNC enterprise servers (criticism aside it also doesn't appear to have any bugs in its current incarnation).
At this time, having been shown the software is UB and that it supports ports I can only say that the software should swap out the display box for a port box. Or it should have a port box added so users who aren't sure what display is will not even bother messing with it. As a PC to Mac convert who is a couple years into using a Mac now I wouldn't have ever discovered the true functionality of display had I not posted this.
My reasoning is pretty well founded, within a day of posting this on your site, Digg and two forums I had nearly 2,000 people download my build. I know as the official project you could easily garner more interest than some geek who just wanted to make available software more usable to the general public.
I feel this should be my last post, I am not able to contribute anything further to the discussion unless changes to the softwares interface are actually being entertained.
Again, while I personally agree with you that the "display" notation is confusing, it doesn't change the fact that it's a notation that is used in tons of other places and other servers, and, as pointed out on the Ars thread, specifically in x-windows incarnations.
Maybe the default text in Chicken for a new connection should be "localhost:5900" instead of "localhost".
In any case, I'm glad that you began this thread because I wouldn't have known about the denial of service attack below otherwise:
Oh wow, sorry about this, I went to my server logs to verify the download statistics for that last post and just finished going through them. I got a few referrals from ArsTechnica meaning that more of the traditional tech media is picking up on my release as being a valid fix for the two problems you have already explained aren't even problems.
Hopefully this just blows over, but if I see another post to correct them I will forward them to this topic.
What amazes me is that this whole endeavor was apparently undertaken without even discussing the issue with the maintainers of this project. The first step should have been to initiate a discussion about the features (perceived as "bugs") involved, asking why each one did what it did. In UI design you want users to have access to features that are commonly used (and it seems that the display field falls into this realm for many users). Instead of removing a feature like that because it can be confusing to the users who don't use it, the confusion can usually be gotten around by better labeling, use of tooltips, repositioning the field, and so on.
But regardless of all that, you shouldn't (1) assume that the feature was a bug and would not/could not be fixed by the current project maintainers, and you definitely shouldn't (2) assume the project is dead. If you or your friend who coded the build had tried to get in touch with the maintainers, and then not had a response for a long time, that's different. But now you've made a mountain out of a molehill, created an unnecessary build, split the user base into two forks, etc. More communication on this board (and through messages to the maintainers) would be advisable, if there are any other features/fixes you'd like to see folded into the project.
"But now you've made a mountain out of a molehill, created an unnecessary build, split the user base into two forks, etc"
I know this is a reply to a really old thread but what the hell, someone was really in the wrong here.
Hey, slow down there pilgrim. Either you believe in Open Source or you don't. This user did absolutely nothing wrong. Contacting the maintainer maybe polite but it is NOT mandatory. He felt and itch and scratched it. If the original author didn't want anyone posting different builds then he A) mostly importantly should have used a different license and B) should have posted some sort of update within the last few years that was highly visible to let users know that bug fixes were welcome. It has now been 2 years since any updates. Still think a fork is a bad idea? Thank God that the source is open and that someone else can step in and pick up where the original author left off.
Again if you don't want to see derivative builds of software you should stick to closed source software.
Log in to post a comment.