home *** CD-ROM | disk | FTP | other *** search
Wrap
Received: from sloth.swcp.com (sloth.swcp.com [198.59.115.25]) by nacm.com (8.6.10/8.6.9) with ESMTP id XAA26771 for <executor@nacm.com>; Tue, 1 Aug 1995 23:28:06 -0700 Received: from iclone.UUCP (uucp@localhost) by sloth.swcp.com (8.6.9/8.6.9) with UUCP id AAA11351; Wed, 2 Aug 1995 00:28:05 -0600 Received: from beaut.ardi.com by mailhost with smtp (nextstep Smail3.1.29.0 #11) id m0sdXEH-000YbnC; Wed, 2 Aug 95 00:24 MDT Received: by beaut.ardi.com (linux Smail3.1.28.1 #5) id m0sdXEH-00005nC; Wed, 2 Aug 95 00:24 MDT Message-Id: <m0sdXEH-00005nC@beaut.ardi.com> Date: Wed, 2 Aug 95 00:24 MDT From: ctm@ardi.com (Clifford Thomas Matthews) To: jnh@kzin.cen.ufl.edu (Jordan Hazen) Cc: executor@nacm.com Subject: Re: E/Linux 1.99o: problems w/Browser & Option key In-Reply-To: <m0sd3pT-00080rC@mandrake.cen.ufl.edu> References: <m0sd3pT-00080rC@mandrake.cen.ufl.edu> Sender: owner-paper@nacm.com Precedence: bulk >>>>> "Jordan" == Jordan Hazen <jnh@kzin.cen.ufl.edu> writes: Jordan> 1) Most desktop-state information is lost between Jordan> successive invokations of the "Go" Browser shell. Open Jordan> windows (except for those displaying the root directory of Jordan> a disk volume from the hot-band) don't stay open between Jordan> sessions, and any changes made to the "hotband" get Jordan> erased. This happens both when running a Mac app. then Jordan> returning to the Browser, and when I quit and re-start Jordan> Executor itself. It doesn't seem to be a permissions Jordan> problem-- the whole /usr/local/lib/executor tree is owned Jordan> by my user ID, and I've even tried running Executor as Jordan> root. Also, everything worked fine under 1.99m; it's only Jordan> when I upgraded to 1.99o that this glitch showed up. hmmm... I think you're seeing a bug that's been in there from day one. We've had a hard time tracking it down because it seems to come and go. However, this bug is now a very high priority and should be fixed relatively soon. Jordan> 2) The Browser completely hangs when opening certain Jordan> folders (always on the same ones)... I think all the Jordan> folders that cause this are missing resource fork "%_____" Jordan> entries, but this isn't a sufficient condition-- many such Jordan> folders work fine. I don't believe anyone else has reported this problem. If you can narrow down what's causing the trouble, it would help us immensely. If anyone else on this list has trouble with the Browser hanging under Executor/Linux when specific folders are opened, please let me know. Could it be related to symlinks or mount-point crossings? Jordan> 2) The Alt-Shift-1 info panel says the Mac "Option" key Jordan> maps to the right-hand Alt (AltGr), but I can't get it to Jordan> work, regardless of how this key is set up in XF86Config Jordan> (tried RightAlt = Meta, which makes it another Jordan> Apple/Squiggle; when RightAlt = Compose, the only other Jordan> common setting, it has no effect at all inside Executor). X is so configurable, I'm not sure whether we're doing something incredibly non-standard over here or not. Here are some code fragments for how we handle the option mapping. Perhaps this will help answer the problem. #define X_TO_MAC_STATE(x_state) \ ( (x_state & ShiftMask ? shiftKey : 0) \ | (x_state & LockMask ? alphaLock : 0) \ | (x_state & ControlMask ? ControlKey : 0) \ | (x_state & Mod1Mask ? cmdKey : 0) \ | (x_state & Mod5Mask ? optionKey : 0) \ | (x_state & Button1Mask ? btnState : 0)) ... switch (keysym) { case XK_Shift_L: case XK_Shift_R: modifier = shiftKey; break; case XK_Control_L: case XK_Control_R: modifier = ControlKey; break; case XK_Caps_Lock: modifier = alphaLock; break; /* ### XK_Shift_Lock */ case XK_Meta_L: case XK_Meta_R: modifier = cmdKey; break; case XK_Alt_L: case XK_Alt_R: modifier = optionKey; break; default: return FALSE; } This suggests to me that in one place we expect the right option button to produce Modifier5, and in another place we're looking specifically for the alt key. Jordan> 3) Desk Accessories can't be added to the Apple menu; not Jordan> even the old HFS_Xfer shows up, though it's in the System Jordan> Folder. Am I missing something here? Placing it in Fonts Jordan> & DAs doesn't work either. This is broken. What you can currently do is drag a Font or DA to the hot-band, *and then run some other program*. After that, the Font/DA will be properly installed, although you won't be able to de-install it. This too will be fixed before 2.0 comes out, although the reason it hasn't yet been fixed is a little different than other delays. We'll soon be supporting more of System 7 and we haven't yet decided whether or not it makes sense to alter our Font/DA installing capability to be more System 7ish. Jordan> 4) Executor often hangs on startup after trying to access Jordan> my SCSI CD-ROM drive if an audio CD player program Jordan> (Workman, etc.) is active. The executor process goes into Jordan> "D" state (uninterruptible sleep-- makes it impossible to Jordan> kill, even with signal 9) and subsequent instances also Jordan> block trying to probe the CD drive. These 'dead' Jordan> processes go away when try to mount any CD (even an audio Jordan> disk) from another window. This could just be a problem Jordan> with my kernel and its interactions with the drive, rather Jordan> than with Executor itself. Still, is there any way to Jordan> override the CD drive scan every time it starts? (aside Jordan> from hiding/renaming the /dev entries?) This also stops Jordan> any music disk that might be playing, kinda annoying... This too is being looked at. If anyone is a Linux Guru and knows what we can do with /dev/cdrom to see whether there's a music disk in it already spinning, feel free to send me e-mail. Jordan> That's all I can think of for now :-). Thanks in advance Jordan> for any help. I have to say I'm *very* pleased with this Jordan> product, even given the current rough spots. Thanks for the criticism and thanks for the praise as well. The problems you've pointed out are all pretty high on our TODO list, but not quite as high as a NEXTSTEP port or getting some of the incredibly heinous DOS extender bugs worked out. --Cliff ctm@ardi.com