Thread: [cotvnc-devel] Key Equivalents, GEN_2_GUI, and Chicken 2.0 Status
Project superseded by http://chicken.sourceforge.net/
Brought to you by:
smeger
From: Jason H. <sm...@ge...> - 2004-04-13 03:22:32
Attachments:
smime.p7s
|
Hey Chickeners! I've checked my key equivalents module into the GEN_2_GUI. As far as=20 I'm concerned at this point, we should just go ahead and make GEN_2_GUI=20= the main branch and start prepping for a release of Chicken 2.0 once=20 the Rendezvous stuff is done. In other words, we'll drop OS X 10.1=20 support and if the hue and cry is loud as a result, we can back-port=20 some of our fixes into a maintenance release for those still running=20 10.1. Here's the current status as I know it: =95 We're now compatible with all servers except for OSXVnc 1.32 using=20= Tight encoding. =95 The new login panel seems stable and is a great improvement, but=20 Rendezvous support isn't yet present. It should save its prefs in=20 com.geekspiff.cotvnc.plist with everything else, though. =95 Key equivalents are now present and end-user-customizable. They can=20= be specified for three different scenarios: a connection window is=20 frontmost, a full-screen connection is active, and a non-connection=20 window is frontmost. This fixes quite a few complaints, bugs and RFEs.=20= This is untested on non-US and non-Panther systems. =95 I've done some aesthetic work on prefs and menus. =95 Clarified the multiple "paste" commands that Chicken supported. =95 CLI invocation of Chicken is present, but needs some cleanup (bug=20 924320 and I haven't tested it with the new login panel) =95 Keychain support is present and spiffy. =95 According to the compiler, we're good to run on Jaguar, but I = haven't=20 actually tried it yet. =95 We've got some URL handler stuff present, but I haven't looked at it=20= at all and don't know what state it's in. =95 We've got a crasher that occurs when the server dies unexpectedly or=20= the connection is broken (bugs 932099, 692836) =95 We've got quite a few bugs regarding key mappings on non-US systems. =95 The build is moved to xCode and I've done some minor cleanup on the=20= project. I'm probably missing one or two things, but I think that this is the=20 important stuff. So, here's what I think are the actionable items for a 2.0 release: =95 Finish implementation of new login and server UI and test the living=20= hell out of it. =95 Work on keymapping issues on non-US systems. =95 QA testing on Panther & Jaguar. =95 Cleanup to CLI invocation stuff. =95 Find some solution or band-aid for the OSXVnc Tight encoding issue =95 Finish URL handler and test =95 Fix crasher mentioned above. =10I'd like to hear thoughts and opinions from you guys on all of this! Jason= |
From: Jared M. <jmc...@df...> - 2004-04-13 04:17:19
|
At 8:22 PM -0700 4/12/04, Jason Harris wrote: >Mime-Version: 1.0 (Apple Message framework v613) >Content-Type: multipart/signed; micalg=sha1; >boundary=Apple-Mail-3-440123362; >protocol="application/pkcs7-signature" > >Hey Chickeners! > >I've checked my key equivalents module into the GEN_2_GUI. As far >as I'm concerned at this point, we should just go ahead and make >GEN_2_GUI the main branch and start prepping for a release of >Chicken 2.0 once the Rendezvous stuff is done. In other words, >we'll drop OS X 10.1 support and if the hue and cry is loud as a >result, we can back-port some of our fixes into a maintenance >release for those still running 10.1. > >Here's the current status as I know it: > >* We're now compatible with all servers except for OSXVnc 1.32 using >Tight encoding. >* The new login panel seems stable and is a great improvement, but >Rendezvous support isn't yet present. It should save its prefs in >com.geekspiff.cotvnc.plist with everything else, though. >* Key equivalents are now present and end-user-customizable. They >can be specified for three different scenarios: a connection window >is frontmost, a full-screen connection is active, and a >non-connection window is frontmost. This fixes quite a few >complaints, bugs and RFEs. This is untested on non-US and >non-Panther systems. >* I've done some aesthetic work on prefs and menus. >* Clarified the multiple "paste" commands that Chicken supported. >* CLI invocation of Chicken is present, but needs some cleanup (bug >924320 and I haven't tested it with the new login panel) >* Keychain support is present and spiffy. >* According to the compiler, we're good to run on Jaguar, but I >haven't actually tried it yet. >* We've got some URL handler stuff present, but I haven't looked at >it at all and don't know what state it's in. >* We've got a crasher that occurs when the server dies unexpectedly >or the connection is broken (bugs 932099, 692836) >* We've got quite a few bugs regarding key mappings on non-US systems. >* The build is moved to xCode and I've done some minor cleanup on the project. > >I'm probably missing one or two things, but I think that this is the >important stuff. > >So, here's what I think are the actionable items for a 2.0 release: > >* Finish implementation of new login and server UI and test the >living hell out of it. >* Work on keymapping issues on non-US systems. >* QA testing on Panther & Jaguar. >* Cleanup to CLI invocation stuff. >* Find some solution or band-aid for the OSXVnc Tight encoding issue >* Finish URL handler and test >* Fix crasher mentioned above. > >I'd like to hear thoughts and opinions from you guys on all of this! > >Jason I have URL handler almost done, but haven't had the chance to finish it. I need to get that done, then I will go after Rendezvous. A couple of questions. You said you checked in an xCode version of the project, but is it native? Also, you mentioned saving to com.geekspiff.cotvnc.plist. Right now I'm saving the servers by serializing the objects. Is this a problem? Jared |
From: Jason H. <sm...@ge...> - 2004-04-13 06:45:38
Attachments:
smime.p7s
|
On Apr 12, 2004, at 9:25 PM, Jared McIntyre wrote: > I have URL handler almost done, but haven't had the chance to finish > it. I need to get that done, then I will go after Rendezvous. Sounds good! I didn't mean to imply any rush, just trying to get everything in order now that things are finally coming together. > A couple of questions. You said you checked in an xCode version of > the project, but is it native? Also, you mentioned saving to > com.geekspiff.cotvnc.plist. Right now I'm saving the servers by > serializing the objects. Is this a problem? Yes, it's native. Serializing the objects isn't a problem, but I'd prefer if you serialized to an NSData and used NSUserDefaults to store that data into the standard prefs instead of to a discrete file. Among other reasons, this allows business users to use per-machine or per-network settings if they feel the need to do so. Jason |
From: Jason H. <sm...@ge...> - 2004-04-14 05:39:58
Attachments:
smime.p7s
|
On Apr 13, 2004, at 8:31 PM, Jared McIntyre wrote: > I'm not sure what the difference will be. In both cases they are > saved to the users current preferences directory, they just have > different names. As I see your code, it's doing NSHomeDirectory() stringByAppendingPathComponent:RFB_PREFS_LOCATION Obviously, this will only work for the user's home directory, not for machine-wide prefs (/Library/Preferences) or network-wide prefs (/Network/Library/Preferences). It's also just aesthetically nasty to use two different files for one function - saving prefs. It's also brittle. The easy solution is to use archivedDataWithRootObject to get an NSData instance and then use the standard NSUserDefaults calls to save that to some key in our standard prefs file. NSData *data = [NSKeyedArchiver archivedDataWithRootObject: instance]; [[NSUserDefaults standardUserDefaults] setObject: data forKey: @"SavedServers"]; Also, when I do a clean checkout of GEN_2_GUI, I'm missing some of the new GUI files. I'm using the following to do a clean checkout - I'm not a CVS guru by any means, so if I'm doing something dumb, don't hesitate to tell me. :) cvs -z3 -d:ext:sm...@cv...:/cvsroot/cotvnc co -j GEN_2_GUI cotvnc I get ServerDisplay.nib now, but not ServerDataManager, and a few of the other newer files. Jason |
From: Jared M. <jmc...@df...> - 2004-04-15 01:28:57
|
>As I see your code, it's doing > NSHomeDirectory() stringByAppendingPathComponent:RFB_PREFS_LOCATION >Obviously, this will only work for the user's home directory, not >for machine-wide prefs (/Library/Preferences) or network-wide prefs >(/Network/Library/Preferences). > >It's also just aesthetically nasty to use two different files for >one function - saving prefs. It's also brittle. > >The easy solution is to use archivedDataWithRootObject to get an >NSData instance and then use the standard NSUserDefaults calls to >save that to some key in our standard prefs file. > >NSData *data = [NSKeyedArchiver archivedDataWithRootObject: instance]; >[[NSUserDefaults standardUserDefaults] setObject: data forKey: >@"SavedServers"]; > >Also, when I do a clean checkout of GEN_2_GUI, I'm missing some of >the new GUI files. I'm using the following to do a clean checkout - >I'm not a CVS guru by any means, so if I'm doing something dumb, >don't hesitate to tell me. :) >cvs -z3 -d:ext:sm...@cv...:/cvsroot/cotvnc co -j >GEN_2_GUI cotvnc > >I get ServerDisplay.nib now, but not ServerDataManager, and a few of >the other newer files. > >Jason Checked in the save change. The load code will still load from the original preferences, my version, and this new version. So, no one should loose anything. Also, I managed to break the add button in my last checking. That is now fixed. This reminds me, we need to place "Remove all warnings" on the list of things to do before release. Most of them are my fault, but with Obj-C, it is really easy to have have an ignored warning come back to haunt you. Jared |
From: Jared M. <jmc...@df...> - 2004-04-16 00:33:21
|
Apple's UI guide lines state that if you bring an application to the forefront, and there are no windows open, a default window should open. I think we should make the following changes: 1) If the Chickn is brought to the forefront and no windows are open, the login window should display 2) If a VNC connection is closed due to a disconnect (not a manual close), and no other windows will be open, the login window should be displayed This would be nice as you rarely want to bring Chicken forward and not open a connection, and the same goes for when a connection is disconnected. Thoughts, Jared |
From: Jonathan G. <jon...@re...> - 2004-04-17 02:40:22
|
FWIW, just my two cents... I think #1 is definitely a good idea. I wouldn't do #2 however - none of the other Apple programs behave that way and it sort of "wrests control" away from the user. If you want to conform to typical Apple behavior it would only be after that application loses focus and is brought BACK front that something comes up (see Text Edit or Terminal for examples). Although personally I find even this behavior seems to make more sense only for a document based application. -- Jonathan Gillaspie jon...@re... Redstone Software, Inc. -- Makers of Platform-Independent Automation Software -- http://www.redstonesoftware.com On Apr 15, 2004, at 6:31 PM, Jared McIntyre wrote: > Apple's UI guide lines state that if you bring an application to the > forefront, and there are no windows open, a default window should > open. I think we should make the following changes: > > 1) If the Chickn is brought to the forefront and no windows are open, > the login window should display > 2) If a VNC connection is closed due to a disconnect (not a manual > close), and no other windows will be open, the login window should be > displayed > > This would be nice as you rarely want to bring Chicken forward and not > open a connection, and the same goes for when a connection is > disconnected. > > Thoughts, > > Jared > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > cotvnc-devel mailing list > cot...@li... > https://lists.sourceforge.net/lists/listinfo/cotvnc-devel |
From: Jared M. <jmc...@df...> - 2004-04-13 04:24:39
|
Does anyone mind if I remove the .DS_Store files from the repository? They aren't necessary, and are kind of annoying. Jared |
From: Jason H. <sm...@ge...> - 2004-04-13 06:46:06
Attachments:
smime.p7s
|
> Does anyone mind if I remove the .DS_Store files from the repository? > They aren't necessary, and are kind of annoying. That'd be great. I always forget about 'em when checking in. Jason |
From: Jared M. <jmc...@df...> - 2004-04-13 05:05:03
|
I checked in the code I've been sitting on the last couple of days. Basically, it provides a reusable login dialog component that is hosted inside the main login dialig, but can be used by itself to present the login from a URL or some other login type that should be displayed without the server selection list. Right now, clicking a VNC URL will bring up one of these dialogs, but you can't connect (yet). Jared |
From: Jason H. <sm...@ge...> - 2004-04-13 06:49:01
Attachments:
smime.p7s
|
On Apr 12, 2004, at 10:13 PM, Jared McIntyre wrote: > I checked in the code I've been sitting on the last couple of days. > Basically, it provides a reusable login dialog component that is > hosted inside the main login dialig, but can be used by itself to > present the login from a URL or some other login type that should be > displayed without the server selection list. Right now, clicking a > VNC URL will bring up one of these dialogs, but you can't connect > (yet). Sounds great! But ServerDisplay.nib seems to be missing. Jason |
From: Jason H. <sm...@ge...> - 2004-04-30 06:27:49
Attachments:
smime.p7s
|
Hi Jared, > What do we need to complete before we can release an alpha or beta of > 2.0? It seems to me that we should consider doing this soon given how > long it has been since our last release and the number of items that > are being requested from us that are actually completed in CVS. I agree completely and was just thinking the same thing. We need to at least get a semi-public build out. I'd been waiting to see the CVS stuff get fixed, but I'd forgotten that SF's feature that emails me when CVS checkins occur is borked. :) So, I just did a fresh checkout of GEN_2_GUI and it looks like we're pretty much good for a test build, with the exception of the compilation warnings. Can you kill these, and then we'll go? I'm currently getting 15 warnings on a fresh compile, from ServerFromRendezvous, ServerDataController, and ServerBase. We can probably keep the ServerFromRendezvous warnings, since they serve the useful purpose of telling us that the class isn't implemented, but the other's should go. I also got a runtime error message relating to NSKeyedArchiver on first run, never repeated. Unfortunately, I reran right away and lost the message, so I'm not sure what it was. I'd like to get this stuff fixed and then rock. Jason |