Thread: [cotvnc-devel] What version of the RFB spec do we officially support?
Project superseded by http://chicken.sourceforge.net/
Brought to you by:
smeger
From: Sean K. <ka...@ge...> - 2005-04-06 00:40:27
|
On the VNC mailing list, an issue came up about CotVNC not supporting RealVNC's Enterprise version (the added features, anyway). Jonathan Gillaspie said that the next version of OSXvnc would support the RFB protocol spec V3.8. Thoughts? Sean |
From: Jason H. <sm...@ge...> - 2005-04-06 03:57:30
|
I think we're at 3.6 but I don't remember exactly. I'd like to support the most current - there's no reason not to. Jason On Apr 5, 2005, at 5:37 PM, Sean Kamath wrote: > > On the VNC mailing list, an issue came up about CotVNC not supporting > RealVNC's Enterprise version (the added features, anyway). > > Jonathan Gillaspie said that the next version of OSXvnc would support > the RFB protocol spec V3.8. > > Thoughts? > > Sean > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > cotvnc-devel mailing list > cot...@li... > https://lists.sourceforge.net/lists/listinfo/cotvnc-devel > > |
From: Jonathan G. <jon...@re...> - 2005-04-06 14:55:26
|
Hey guys, I have modifications to CotVNC to bring it up to 3.8 as far as the authentication protocol goes. I still don't think that this is sufficient to make our VNC's compatible with Real's Enterprise Edition because they also have some undocumented encryption and other authentication going on. Also it appears that 3.8 defines some additional explanation for how various keys should be passed and how Caps lock, Num lock, and shift-tab should work - I haven't done anything along those lines with Chicken, you guys might want to read that latest spec. Anyhow, I don't know if you want to add me as a developer and I can check in my mods or if you would prefer that I just send the patches in...please let me know. -- Jonathan Gillaspie jon...@re... Redstone Software, Inc. -- Makers of Eggplant, Platform-Independent Automation Software -- http://www.redstonesoftware.com On Apr 5, 2005, at 9:57 PM, Jason Harris wrote: > I think we're at 3.6 but I don't remember exactly. I'd like to > support the most current - there's no reason not to. > > Jason > > > On Apr 5, 2005, at 5:37 PM, Sean Kamath wrote: > >> >> On the VNC mailing list, an issue came up about CotVNC not supporting >> RealVNC's Enterprise version (the added features, anyway). >> >> Jonathan Gillaspie said that the next version of OSXvnc would support >> the RFB protocol spec V3.8. >> >> Thoughts? >> >> Sean >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> cotvnc-devel mailing list >> cot...@li... >> https://lists.sourceforge.net/lists/listinfo/cotvnc-devel >> >> > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > cotvnc-devel mailing list > cot...@li... > https://lists.sourceforge.net/lists/listinfo/cotvnc-devel |
From: Jason H. <sm...@ge...> - 2005-04-06 18:46:09
|
Hi Jonathan, Thanks for the patches! I've added you as a developer, so go ahead and check them in if you'd like, or submit them as patches and I'll do the checkin if you'd prefer. Can you explain what end-user effects the patches will have, so I can update the version history and the documentation? Jason On Apr 6, 2005, at 7:55 AM, Jonathan Gillaspie wrote: > > Hey guys, I have modifications to CotVNC to bring it up to 3.8 as far > as the authentication protocol goes. I still don't think that this is > sufficient to make our VNC's compatible with Real's Enterprise Edition > because they also have some undocumented encryption and other > authentication going on. > > Also it appears that 3.8 defines some additional explanation for how > various keys should be passed and how Caps lock, Num lock, and > shift-tab should work - I haven't done anything along those lines with > Chicken, you guys might want to read that latest spec. > > Anyhow, I don't know if you want to add me as a developer and I can > check in my mods or if you would prefer that I just send the patches > in...please let me know. > > -- > Jonathan Gillaspie > jon...@re... > Redstone Software, Inc. > -- Makers of Eggplant, Platform-Independent Automation Software > -- http://www.redstonesoftware.com > > On Apr 5, 2005, at 9:57 PM, Jason Harris wrote: > >> I think we're at 3.6 but I don't remember exactly. I'd like to >> support the most current - there's no reason not to. >> >> Jason >> >> >> On Apr 5, 2005, at 5:37 PM, Sean Kamath wrote: >> >>> >>> On the VNC mailing list, an issue came up about CotVNC not supporting >>> RealVNC's Enterprise version (the added features, anyway). >>> >>> Jonathan Gillaspie said that the next version of OSXvnc would support >>> the RFB protocol spec V3.8. >>> >>> Thoughts? >>> >>> Sean >>> >>> >>> ------------------------------------------------------- >>> SF email is sponsored by - The IT Product Guide >>> Read honest & candid reviews on hundreds of IT Products from real >>> users. >>> Discover which products truly live up to the hype. Start reading now. >>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>> _______________________________________________ >>> cotvnc-devel mailing list >>> cot...@li... >>> https://lists.sourceforge.net/lists/listinfo/cotvnc-devel >>> >>> >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> cotvnc-devel mailing list >> cot...@li... >> https://lists.sourceforge.net/lists/listinfo/cotvnc-devel > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > cotvnc-devel mailing list > cot...@li... > https://lists.sourceforge.net/lists/listinfo/cotvnc-devel > > |
From: Jonathan G. <jon...@re...> - 2005-04-06 18:53:05
|
Darn little if anything, it really just changes to allow for the server and client to have a better "authentication dialogue", it allows for an extensible step in the middle where the server can offer multiple ways to log-in. Hopefully soon OSXvnc might allow users to use their own login to the OSXvnc machine rather than the "VNC Password" thing, this all ties in of course with getting a spec for it (or making one ourselves) but the 3.8 protocol fits this model better. The only really visible effect that I can think of will be that the server can give it's own message as to why authentication failed, ie if the password file is found but is unreadable or something peculiar like that. -- Jonathan Gillaspie jon...@re... Redstone Software, Inc. -- Makers of Eggplant, Platform-Independent Automation Software -- http://www.redstonesoftware.com On Apr 6, 2005, at 12:45 PM, Jason Harris wrote: > Hi Jonathan, > > Thanks for the patches! I've added you as a developer, so go ahead > and check them in if you'd like, or submit them as patches and I'll do > the checkin if you'd prefer. > > Can you explain what end-user effects the patches will have, so I can > update the version history and the documentation? > > Jason > > > On Apr 6, 2005, at 7:55 AM, Jonathan Gillaspie wrote: > >> >> Hey guys, I have modifications to CotVNC to bring it up to 3.8 as far >> as the authentication protocol goes. I still don't think that this >> is sufficient to make our VNC's compatible with Real's Enterprise >> Edition because they also have some undocumented encryption and other >> authentication going on. >> >> Also it appears that 3.8 defines some additional explanation for how >> various keys should be passed and how Caps lock, Num lock, and >> shift-tab should work - I haven't done anything along those lines >> with Chicken, you guys might want to read that latest spec. >> >> Anyhow, I don't know if you want to add me as a developer and I can >> check in my mods or if you would prefer that I just send the patches >> in...please let me know. >> >> -- >> Jonathan Gillaspie >> jon...@re... >> Redstone Software, Inc. >> -- Makers of Eggplant, Platform-Independent Automation Software >> -- http://www.redstonesoftware.com >> >> On Apr 5, 2005, at 9:57 PM, Jason Harris wrote: >> >>> I think we're at 3.6 but I don't remember exactly. I'd like to >>> support the most current - there's no reason not to. >>> >>> Jason >>> >>> >>> On Apr 5, 2005, at 5:37 PM, Sean Kamath wrote: >>> >>>> >>>> On the VNC mailing list, an issue came up about CotVNC not >>>> supporting >>>> RealVNC's Enterprise version (the added features, anyway). >>>> >>>> Jonathan Gillaspie said that the next version of OSXvnc would >>>> support >>>> the RFB protocol spec V3.8. >>>> >>>> Thoughts? >>>> >>>> Sean >>>> >>>> >>>> ------------------------------------------------------- >>>> SF email is sponsored by - The IT Product Guide >>>> Read honest & candid reviews on hundreds of IT Products from real >>>> users. >>>> Discover which products truly live up to the hype. Start reading >>>> now. >>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>>> _______________________________________________ >>>> cotvnc-devel mailing list >>>> cot...@li... >>>> https://lists.sourceforge.net/lists/listinfo/cotvnc-devel >>>> >>>> >>> >>> >>> >>> ------------------------------------------------------- >>> SF email is sponsored by - The IT Product Guide >>> Read honest & candid reviews on hundreds of IT Products from real >>> users. >>> Discover which products truly live up to the hype. Start reading now. >>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>> _______________________________________________ >>> cotvnc-devel mailing list >>> cot...@li... >>> https://lists.sourceforge.net/lists/listinfo/cotvnc-devel >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> cotvnc-devel mailing list >> cot...@li... >> https://lists.sourceforge.net/lists/listinfo/cotvnc-devel >> >> > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > cotvnc-devel mailing list > cot...@li... > https://lists.sourceforge.net/lists/listinfo/cotvnc-devel |
From: Jason H. <sm...@ge...> - 2005-04-06 18:57:58
|
On Apr 6, 2005, at 11:53 AM, Jonathan Gillaspie wrote: > The only really visible effect that I can think of will be that the > server can give it's own message as to why authentication failed, ie > if the password file is found but is unreadable or something peculiar > like that. Does your patch present this message to the user if authentication fails? If it does, we should probably wrap it in a "The server said..." dialog. Jason |
From: Jonathan G. <jon...@re...> - 2005-04-06 19:01:19
|
I'm not in front of the code at the moment, I think I was able to report any string using some existing code, I'll make sure the message is clear as to the origin of the error string, using what you suggested here if I haven't already put something in. -- Jonathan On Apr 6, 2005, at 12:57 PM, Jason Harris wrote: > On Apr 6, 2005, at 11:53 AM, Jonathan Gillaspie wrote: > >> The only really visible effect that I can think of will be that the >> server can give it's own message as to why authentication failed, ie >> if the password file is found but is unreadable or something peculiar >> like that. > > Does your patch present this message to the user if authentication > fails? If it does, we should probably wrap it in a "The server > said..." dialog. > > Jason > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > cotvnc-devel mailing list > cot...@li... > https://lists.sourceforge.net/lists/listinfo/cotvnc-devel |
From: Jonathan G. <jon...@re...> - 2005-04-06 17:29:28
|
> Well I suppose the main one would be able to connect to servers that > support (expect) a username/password combination and be able to > specify the username. As to other features, it's a while since I > looked at what's on offer in the commercial product, but I do recall > thinking that some of them would be useful to us. > > I'm now using CotVNC version 2.0b2 which is much better than the > previous version, and with the ARD VNC server which seems pretty > solid, things are working reasonably well now. > > As for things that don't make sense, instead of "Windows > Authentication for OSXvnc" think "Mac/Netinfo/<whatever it's called > this week> Authentication for OSXvnc". The current version of the RFB specification doesn't seem to document how to do RealVNC's Enterprise Edition encryption/authentication. I'm not certain if this is an intentional omission to keep their Enterprise solution proprietary or if they are just busy and haven't had the opportunity to update the spec accordingly. I would be happy to get an answer from Wez or someone else at RealVNC on this question? If they are going to keep that proprietary then I'm disappointed but I guess we'll all have to respect RealVNC's decision to separate that from the open standard that they started. I would love to begin offering OSXvnc with a Mac authentication protocol that works in conjunction with the Windows Authentication protocol used in RealVNC's Enterprise Edition. I'm also sure that Chicken of the VNC would like be able to connect to RealVNC's Windows Enterprise Edition servers, this will all happen much easier if we have a consistent documented protocol, this is the biggest barrier to seeing these feature incorporated into VNCs for other OS's. -- Jonathan Gillaspie jon...@re... Redstone Software, Inc. -- Makers of Eggplant, Platform-Independent Automation Software -- http://www.redstonesoftware.com |
From: Jason H. <sm...@ge...> - 2005-04-06 18:47:49
|
On Apr 6, 2005, at 10:29 AM, Jonathan Gillaspie wrote: > I would love to begin offering OSXvnc with a Mac authentication > protocol that works in conjunction with the Windows Authentication > protocol used in RealVNC's Enterprise Edition. I'm also sure that > Chicken of the VNC would like be able to connect to RealVNC's Windows > Enterprise Edition servers, this will all happen much easier if we > have a consistent documented protocol, this is the biggest barrier to > seeing these feature incorporated into VNCs for other OS's. Agree. If we get a spec, we'll implement it in Chicken. Jason |
From: Jared M. <jmc...@df...> - 2005-04-07 00:46:04
|
Since it sounds like there is some activity again, are we looking at another release soon? There are some nice improvements in there, even if it isn't finished. The addition of rfb rendezvous support is pretty important since that is what OSXVnc now supports. I also rather like the saving of rendezvous server settings. Is there anything holding up another beta? Jared |
From: Jason H. <sm...@ge...> - 2005-04-07 03:37:44
|
Oddly enough, I was thinking the same thing today. :) Let's take a look at our outstanding bugs and see where we're at. I know that we have some pretty serious issues with current versions of the various Windows servers. We should fix these before another release. I think we also still have a colorshift issue against non-Windows little-endian servers. And our character pasting is badly borked, which I need to fix since I broke it. I'll try to go through our bugs tomorrow and compile a list of "must-fixes" before a b3 release. Jason On Apr 6, 2005, at 5:45 PM, Jared McIntyre wrote: > Since it sounds like there is some activity again, are we looking at > another release soon? There are some nice improvements in there, even > if it isn't finished. The addition of rfb rendezvous support is > pretty important since that is what OSXVnc now supports. I also > rather like the saving of rendezvous server settings. > > Is there anything holding up another beta? > > Jared > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > cotvnc-devel mailing list > cot...@li... > https://lists.sourceforge.net/lists/listinfo/cotvnc-devel > > |
From: Jared M. <jmc...@df...> - 2005-04-07 03:49:10
|
I just checked in code so that the servers display in alphabetical order. This handles the inevitable select next when return is pressed conflict in NSTableView. This should make several people happy, and the thing looks a bit more professional now. As a side note, please work with this before we release b3. I don't know of any issues, but I had to do some pretty major refactor to how the tree is populated, so I may have missed something. Jason, there is at least one bug/enhancement request relating to this that will be able to go away when we release. Jared |
From: Jason H. <sm...@ge...> - 2005-04-07 04:07:59
|
Sweet! This one has been driving me nuts. Now we just need type-to-select. :) Jason On Apr 6, 2005, at 8:49 PM, Jared McIntyre wrote: > I just checked in code so that the servers display in alphabetical > order. This handles the inevitable select next when return is pressed > conflict in NSTableView. This should make several people happy, and > the thing looks a bit more professional now. As a side note, please > work with this before we release b3. I don't know of any issues, but > I had to do some pretty major refactor to how the tree is populated, > so I may have missed something. > > Jason, there is at least one bug/enhancement request relating to this > that will be able to go away when we release. > > Jared > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > cotvnc-devel mailing list > cot...@li... > https://lists.sourceforge.net/lists/listinfo/cotvnc-devel > > |
From: Jared M. <jmc...@df...> - 2005-04-07 05:54:31
|
I've checked in another thing that I have had mostly done for a long time, but only got around to finishing it this evening: url handling. Chicken now handles urls of type vnc:// and rfb://. The implementation uses the existing server sub dialog and is an example of how we can use that dialog as a simple server opener in addition to its regular role as an embedded component in the larger server open dialog (with the list of servers). Its nice to finally use something for what I designed it to do over a year ago 8-). By the way, this is done through adding applescript events, so we are now technically apple scriptable as well. We may want to think about what other apple script events we should implement, and whether there are any Automator components that would be useful to people. Jared |
From: Jason H. <sm...@ge...> - 2005-04-07 12:28:31
|
Very nice, this mostly solves the document issues I referred to yesterday. The main thing I wanted was a way to have double-clickable-to-launch items. Questions: Do we properly handle urls that specify the port? Do we handle urls that have the password embedded (I think we should). Hmmm, on further thought, maybe this doesn't solve the issues I wanted to solve by subclassing NSDocument. I see that creating a vnc:// URL in Safari and dragging it to the desktop creates an "inetloc" file. Double-clicking it doesn't launch Chicken, or do anything for that matter. I don't care whether our document file is an inetloc file or a .vnc file or whatever, as long as we have one. Using something custom would be nice in that we can give it a custom icon, but that's it. My goals for this are to be able to do the following: - Open a connection via an URL (done). If we have a password in Keychain, there should be no confirmation step. - Open a connection by double-clicking an icon. If we have a password in Keychain, there should be no confirmation step. - Save a connection to an icon by dragging out of our connections window. - Save a connection to an icon by dragging the connection window's proxy icon. - Save a connection to an icon by using a Save Connection menu item. Make sense to everyone? The "inetloc" file that Safari creates is in an undocumented (but easy-to-figure-out) format. It uses the oldskewl Carbon resource manager to store its data. I personally find this icky, but using it is definitely an option. But I'd prefer to use a format that lets us store server metadata, such as the desired profile and fullscreen setting. I think we should just use plist dictionaries as a document format. Easy and human-readable. Sorry if this email is unclear, I'm a bit scattered today. Jason On Apr 6, 2005, at 10:54 PM, Jared McIntyre wrote: > I've checked in another thing that I have had mostly done for a long > time, but only got around to finishing it this evening: url handling. > Chicken now handles urls of type vnc:// and rfb://. The > implementation uses the existing server sub dialog and is an example > of how we can use that dialog as a simple server opener in addition to > its regular role as an embedded component in the larger server open > dialog (with the list of servers). Its nice to finally use something > for what I designed it to do over a year ago 8-). > > By the way, this is done through adding applescript events, so we are > now technically apple scriptable as well. We may want to think about > what other apple script events we should implement, and whether there > are any Automator components that would be useful to people. > > Jared > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > cotvnc-devel mailing list > cot...@li... > https://lists.sourceforge.net/lists/listinfo/cotvnc-devel > > |
From: Jared M. <jmc...@df...> - 2005-04-07 15:04:24
|
The URL handling uses NSURL and uses its port and password properties, so that should work. We are treating the port the same way we treat it everywhere else (i.e. not particularly well). On the subject of files, I think it makes sense to use the inetloc files if we can ever figure out what the proper way to deal with that is. I've seen code on how to process and write them, but I still have unanswered questions. The big one is, multiple applications use inetloc, so it doesn't make sense to register as the primary reader of that file, there must be some other system for handling that, perhaps similar to how you register as a URL handler. Jared >Very nice, this mostly solves the document issues I referred to >yesterday. The main thing I wanted was a way to have >double-clickable-to-launch items. > >Questions: Do we properly handle urls that specify the port? Do we >handle urls that have the password embedded (I think we should). > >Hmmm, on further thought, maybe this doesn't solve the issues I >wanted to solve by subclassing NSDocument. I see that creating a >vnc:// URL in Safari and dragging it to the desktop creates an >"inetloc" file. Double-clicking it doesn't launch Chicken, or do >anything for that matter. I don't care whether our document file is >an inetloc file or a .vnc file or whatever, as long as we have one. >Using something custom would be nice in that we can give it a custom >icon, but that's it. > >My goals for this are to be able to do the following: >- Open a connection via an URL (done). If we have a password in >Keychain, there should be no confirmation step. >- Open a connection by double-clicking an icon. If we have a >password in Keychain, there should be no confirmation step. >- Save a connection to an icon by dragging out of our connections window. >- Save a connection to an icon by dragging the connection window's proxy icon. >- Save a connection to an icon by using a Save Connection menu item. > >Make sense to everyone? > >The "inetloc" file that Safari creates is in an undocumented (but >easy-to-figure-out) format. It uses the oldskewl Carbon resource >manager to store its data. I personally find this icky, but using >it is definitely an option. But I'd prefer to use a format that >lets us store server metadata, such as the desired profile and >fullscreen setting. > >I think we should just use plist dictionaries as a document format. >Easy and human-readable. > >Sorry if this email is unclear, I'm a bit scattered today. > >Jason |
From: Jared M. <jmc...@df...> - 2005-04-07 00:56:51
|
Does anyone else get errors like the following when loading Chicken into XCode: File: /SourceCache/DevToolsBase/DevToolsBase-387/pbxcore/Target.subproj/PBXTargetBuildContext.m Line: 1019 Object: <PBXTargetBuildContext:0x05a4ac20> Method: _recomputeHeadermap -_recomputeHeadermap called from -createDependencyGraphIfNeeded Jared |
From: Jason H. <sm...@ge...> - 2005-04-07 04:05:39
|
No, I haven't seen this. I checked in Chicken's project file today =20 after using it in XCode 1.5. Is that what you're using? Jason On Apr 6, 2005, at 5:57 PM, Jared McIntyre wrote: > Does anyone else get errors like the following when loading Chicken =20= > into XCode: > > File:=A0=A0 =20 > /SourceCache/DevToolsBase/DevToolsBase-387/pbxcore/Target.subproj/=20 > PBXTargetBuildContext.m > Line:=A0 1019 > Object:=A0=A0=A0=A0 <PBXTargetBuildContext:0x05a4ac20> > Method:=A0=A0=A0=A0=A0=A0 _recomputeHeadermap > > -_recomputeHeadermap called from -createDependencyGraphIfNeeded > > Jared |
From: Jason H. <sm...@ge...> - 2005-04-07 12:54:59
|
I just tried this and it worked fine. I'm using the XCode that comes with Tiger 425. Jason On Apr 6, 2005, at 9:17 PM, Jared McIntyre wrote: >> No, I haven't seen this. I checked in Chicken's project file today >> after using it in XCode 1.5. Is that what you're using? >> >> Jason > > At the moment, yes. However, it completely flips out using the 2.0 > betas. I may just have some installation problems. > > Jared > > |
From: Jonathan G. <jon...@re...> - 2005-04-19 19:33:56
Attachments:
FadingChicken.pdf
|
Ok all, I've checked in the 3.8 protocol enhancements. I tested the build here and it worked with RealVNC 4 and with my forthcoming OSXvnc server that are 3.8. Feel free to review and let me know if anything is amiss. In testing I noticed something when connecting to my local display, maybe it's intentional but the screen image doesn't seem to be coming across perfectly, see attached screen shot to see how each "copy" is faded. Just thought I would point it out, it's not a big deal but if someone is doing color precise work it could be slightly bothersome. -- Jonathan Gillaspie http://www.redstonesoftware.com Redstone Software Inc. -- Makers of Platform Independent Automation Software |
From: Jason H. <sm...@ge...> - 2005-04-20 07:33:06
|
Good catch! I'll tackle this when I revamp the imaging model next month. No point before then. Thanks for the check-in! Jason On Apr 19, 2005, at 12:33 PM, Jonathan Gillaspie wrote: > Ok all, I've checked in the 3.8 protocol enhancements. I tested the > build here and it worked with RealVNC 4 and with my forthcoming OSXvnc > server that are 3.8. Feel free to review and let me know if anything > is amiss. > > In testing I noticed something when connecting to my local display, > maybe it's intentional but the screen image doesn't seem to be coming > across perfectly, see attached screen shot to see how each "copy" is > faded. Just thought I would point it out, it's not a big deal but if > someone is doing color precise work it could be slightly bothersome. > > -- > Jonathan Gillaspie > http://www.redstonesoftware.com > Redstone Software Inc. -- Makers of Platform Independent Automation > Software > > <FadingChicken.pdf> > > > > On Apr 6, 2005, at 12:57 PM, Jason Harris wrote: > >> On Apr 6, 2005, at 11:53 AM, Jonathan Gillaspie wrote: >> >>> The only really visible effect that I can think of will be that the >>> server can give it's own message as to why authentication failed, ie >>> if the password file is found but is unreadable or something >>> peculiar like that. >> >> Does your patch present this message to the user if authentication >> fails? If it does, we should probably wrap it in a "The server >> said..." dialog. >> >> Jason >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> cotvnc-devel mailing list >> cot...@li... >> https://lists.sourceforge.net/lists/listinfo/cotvnc-devel |
From: Jared M. <jmc...@df...> - 2005-04-07 00:51:02
|
I was thinking about our perennial GUI problem, where sometimes you just want to connect to a server, and you don't want to create a new server, but we make you anyway. It strikes me we can use the add the "new" concept to our existing usage of "open." With file based apps, new represents the creation of a new document, you aren't necessarily even going to save this document. Open, is always going to open an existing document. So, a "new" menu item could bring up the server dialog sans server list and include a checkbox to remember the server or "add to bookmarks" or something. Thoughts? Also, I think I've mentally worked out the issue caused by creating a server dialog that isn't attached to anything to free its memory (as happens during the currently turned off URL handler). Hopefully I'll have some time to get this in place along with a sort order for the server list. Jared |
From: Jason H. <sm...@ge...> - 2005-04-07 04:04:10
|
This paradigm actually works well with something I want to do, which is to switch to using NSDocument as a base for our connections. That makes it nice and easy to save servers and connect by double-clicking 'em. For our connection dialog, we could use something akin to Safari's bookmarks idea. A single window that can change its contents. For example, "New" gives our existing server form. "Open" gives our existing list of servers. Single-clicking a server opens the connection if we already know the password, or populates the "New" form and focuses the password text field if not. So, for example, we might implement this by giving our window an Open tab and a Bookmarks tab. Menu commands could show the window with either of the tabs focused, and we could add a pref that the user could set to determine what shows up when Chicken is initially launched. Jason On Apr 6, 2005, at 5:50 PM, Jared McIntyre wrote: > I was thinking about our perennial GUI problem, where sometimes you > just want to connect to a server, and you don't want to create a new > server, but we make you anyway. It strikes me we can use the add the > "new" concept to our existing usage of "open." With file based apps, > new represents the creation of a new document, you aren't necessarily > even going to save this document. Open, is always going to open an > existing document. So, a "new" menu item could bring up the server > dialog sans server list and include a checkbox to remember the server > or "add to bookmarks" or something. Thoughts? > > Also, I think I've mentally worked out the issue caused by creating a > server dialog that isn't attached to anything to free its memory (as > happens during the currently turned off URL handler). Hopefully I'll > have some time to get this in place along with a sort order for the > server list. > > Jared > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > cotvnc-devel mailing list > cot...@li... > https://lists.sourceforge.net/lists/listinfo/cotvnc-devel > > |
From: Jason H. <sm...@ge...> - 2005-04-08 00:32:04
|
On Apr 7, 2005, at 8:04 AM, Jared McIntyre wrote: > The URL handling uses NSURL and uses its port and password properties, > so that should work. We are treating the port the same way we treat > it everywhere else (i.e. not particularly well). Do we pass along the password if it's present and open the connection without any further user intervention? > On the subject of files, I think it makes sense to use the inetloc > files if we can ever figure out what the proper way to deal with that > is. I've seen code on how to process and write them, but I still have > unanswered questions. The big one is, multiple applications use > inetloc, so it doesn't make sense to register as the primary reader of > that file, there must be some other system for handling that, perhaps > similar to how you register as a URL handler. Writing the inetloc files isn't much of a deal, although the idea of putting nasty Resource Manager code in our pretty Cocoa app pains me. But I much, much prefer using a double-clickable representation that is bound directly to Chicken, and that can store additional data like desired profile and whether the connection should open fullscreen. This is why I was thinking about using NSDocument. We get all of that functionality for free if we use NSDocument, and there aren't any real downsides. We also have the benefit that we can link the URL handler directly to the document, making the applescript stuff you implemented become automatic. Jason |
From: Jared M. <jmc...@df...> - 2005-04-08 01:21:07
|
>On Apr 7, 2005, at 8:04 AM, Jared McIntyre wrote: > >>The URL handling uses NSURL and uses its port and password >>properties, so that should work. We are treating the port the same >>way we treat it everywhere else (i.e. not particularly well). > >Do we pass along the password if it's present and open the >connection without any further user intervention? It will still present you with the dialog (today anyway). We can fiddle around with this however we want. I also need to get around to developing a checkbox to have the server remembered. But I need to think through the bast way to place this in the framework. >>On the subject of files, I think it makes sense to use the inetloc >>files if we can ever figure out what the proper way to deal with >>that is. I've seen code on how to process and write them, but I >>still have unanswered questions. The big one is, multiple >>applications use inetloc, so it doesn't make sense to register as >>the primary reader of that file, there must be some other system >>for handling that, perhaps similar to how you register as a URL >>handler. > >Writing the inetloc files isn't much of a deal, although the idea of >putting nasty Resource Manager code in our pretty Cocoa app pains >me. But I much, much prefer using a double-clickable representation >that is bound directly to Chicken, and that can store additional >data like desired profile and whether the connection should open >fullscreen. > >This is why I was thinking about using NSDocument. We get all of >that functionality for free if we use NSDocument, and there aren't >any real downsides. We also have the benefit that we can link the >URL handler directly to the document, making the applescript stuff >you implemented become automatic. We can certainly create our own document (it seems to me that NSDocument might have unnecessary overhead versus a simple serialization method), but it strikes me we should try to support at least reading inetloc files since that is what all the web browsers create anyway. Jared |