Existing users, 
User Name FredericoR
Member Since 2000-11-22
Total number of Feedback Posts: 22
Total number of comments: 2
Last 10 Feedback Posts by FredericoR [ Search for All ]
KeyCue 1.0fc1 (Mac OS X)
Dan Frakes: I think you've misunderstood which missing keystrokes I'm trying to say should be reported. It is not those of Services, or user-defined keystrokes for every other app or global additions, or those that are not available in this app at this time; I'm after the "hidden" keystrokes (read: those keystrokes within an app that are not listed in the Menus). E.G., Adobe GoLive, amongst many others, used to use 'Command-Comma' (before Apple made it the default for app prefs) to change focus from the link text on a page to the Link Inspector. This incredibly handy shortcut is not listed in the menu bars. Nor can one alter it in Panther's Keyboard prefs, because it is not a Menubar item. Nor can one (easily) learn this keystroke even exists unless one bought the retail package version of GoLive, and the keystroke cheat sheet is not missing from the package (something that happened to an entire shipment of EDU versions we once received). Let's face it; even users who have the manual and documented lists of keystrokes per app are just plain lazy; they fail to study such lists,a nd they lose or misplace the cheat sheets. They waste time -- tons of time -- mousing around and getting CPS for want of knowing the correct keystroke. My point is that if KeyCue, or another such app, could scan within an app and find and report all those "hidden" keystrokes, it would be phenomenal. If it also had the ability to compare those keystrokes with user-defined preferences, so much the better. As I said, I would pay *way* more than the current asking price if it could let me file away all the app cheat sheets I have littering my desk, and I know of lots and lots of people, primarily digital artists who end up wasting tons of time mousing around instead of *learning* those cheat sheets, who would gladly pay, too. BTW, I'm not sure if you were aware of an existing feature in KeyCue that "grays out" those keystrokes that are currently unavailable to the focussed window; I don't see much difference between that ability and the ability to "gray out" any hidden, user-defined, or global prefs, too. Am I asking for a lot? Maybe. Too much? I hope not. If the KeyCue developers can't do it, perhaps a competitor will read this thread and see the, IMO, golden opportunity they're missing. Cheers [alert admin]
Read Comments (1) | More Info
Tuesday, May 18 2004 @ 12:29 AM PDT
KeyCue 1.0b2 (Mac OS X)
Ergonis, I'm Serious as a Heart Attack --
-- How Much More Serious Should I Be? a)1. I'm not convinced it will take a miracle to generate dynamic keystroke reports. The info has to be in the app somewhere. That KeyCue (nor anyone else, admittedly) has figured it out yet, is beside the point. If it's impossible, it just reinforces the minimal value of an app like this. Not valueless, just not invaluable. a)2. I never said KeyCue maintains lists. A reply from the developer (you?) indicated that would be the only way he could think of to list keystrokes other than those in the Menubar. I was stating that this was an ineffective way (though better than nothing) way to deal with ever-changing apps. b) 1. You must not be very experienced as a Mac shareware developer, or you are very naive if you think that everyone with a problem with your app -- especially a beta release -- will bother to give you the time of day, let alone a bug report, let alone *still* another try at the same app that 'bugged' them. Thousands of people download a single app, and thousands of people launch it once, and throw it away or forget to ever open it again. A user has to be *terribly* motivated to use your solution to his incessant problems/concerns/needs to be bothered to report a bug that gets in his way. The few left that are interested in a new, bug-free version, almost invariably think that someone else surely reported that bug alreaedy, so why bother? Your expectation and desire to see bug reports is natural and commendable; it's just not practical. BTW, I *WAS* terribly motivated to use your app, and purchase around 100 licenses for my firm and my teaching lab -- until you told me that you didn't believe you could make it truly useful as an education tool for complex applications. b) 2. I did send you a bug report in my reply to your reply about my desire to see hidden shortcuts. Sorry you apparently didn't get it. I would *never* post a bug allegation/suspicion on VT (unless it was deadly) without first trying to work through it with the developer -- this does not include repeatable, unquestionable bugs and conflicts. Since I did not get a reply on the bug, I went ahead and posted -- with reasonable caveats, mind you -- my experience, just in case others were seeing similar behavior and had not connected any dots. Good Luck, and Cheers [alert admin]
Friday, May 07 2004 @ 12:59 AM PDT
KeyCue 1.0b2 (Mac OS X)
Interesting concept, but it falls desperately short of the mark in that it only displays shortcuts already listed in the Menubar. It fails to present a *COMPLETE* list of available shortcuts; i.e., the ones only found in manuals or by word of mouth, thus that are hardest to remember, and, therefore, learn. It would be worth the asking price three times over if it could scan an application (as opposed to maintaining premade lists) and locate all the "hidden" keystrokes. On an aside, and I can't confirm 100% it's related, *BUT*, after trying this app and allowing the machine to go to sleep, I lost total control of cursor movement upon wake. Unplugging/plugging USB mouse, trackball, trackpad, tablet, et al, had no effect; the devices were recognized by ASP but no amount of logging out/in, restarting processes via Terminal, etc., would resolve the issue; all other devices on the same USB bus worked fine. A Restart was required. Thank God for Universal Keyboard Access. All was fine until the machine went to sleep again, and upon wake, cursor control lost again. Discovered that KeyCue was set to launch on Login. Restarted, disabled (deleted) KeyCue, and the problem has not returned. As I said, I can't be certain beyond doubt that KeyCue is involved, but I've never seen that problem before (where a dead mouse/bad cable was not involved), and it was repeatable for two iterations where KeyCue was active and has not returned since it was removed. You be the judge. [alert admin]
Post a comment | More Info | 2 of 4 users found this helpful
Tuesday, May 04 2004 @ 08:43 AM PDT
Safari Extender 1.0 (Mac OS X)
Why do so many people always crap all over developers who try to provide tools to those who like to skin a cat differently, or even skin a different cat? (PETA replies not required) I've been sorely missing CM commands such as even just the basic back/forward ever since I switched to Safari. Yes, I'm also a serious keystroke hound, and, yes, I really, really hate the mouse, but sometimes when I'm surfing with just a trackball or simple two-button mouse, and especially a touchpad on a PowerBook, I can't stand mousing all over to use buttons, nor can I relax as easily if I have to stay in control of the keyboard. A CM for basic and advanced commands is just what the doctor ordered. Thanks, Ricardo. Now, if someone will just add back in my Command-Click-Hold-Drag-page function (the Mickey Mouse hand to scroll a page), ala IE5, I'll be complete. [alert admin]
Post a comment | More Info | 2 of 2 users found this helpful
Wednesday, February 25 2004 @ 11:48 AM PST
ChangeDesktop 2.4.2 (Mac OS X)
I've been using 2.4.1 until today, when I switched to 2.4.2 to get right with Panther. Both the prior version and the new version worked fine under Panther until I Restarted. Now I get an incurable error under any user account, including a virgin account and root, where nothing other than a stock Panther set of features is running, in any version of CD: "Could not open "/Volumes/utilities/OS X Extras/ChangeDesktop/ChangeDesktop 2.4.2/ChangeDesktop.app/Contents/Resources/ChangeDesktopDaemon.app". Error: -10827." Any ideas? Cheers Frederico [alert admin]
Post a comment | More Info | 0 of 1 users found this helpful
Tuesday, October 28 2003 @ 11:53 PM PST
SwapSwapVM 0.9.9b9 (Mac OS X)
Hi, the latest internal build (to be released shortly) addresses that issue. Sorry you had problems. Please read the Read Me and report bugs directly to the developer to receive faster response and access to internal builds for testing your specific issues. [alert admin]
Monday, August 11 2003 @ 02:33 PM PDT
SafariNoBrush 1.22 (Mac OS X)
For those of you seeing the 'can't copy 'xxx' file' error, it is due to a permissions problem with the application; i.e., if the Safari installation is owned by 'system', and not the current user (admin or otherwise), SafariNoBrush will return the aforementioned error. The solution is to login as root and rerun the application, or, or, simply duplicate the Safari Application and run SFNB on it, or, not as safe, change the permissions using Get Info for the folder Safari->Contents->English.lproj and its entire enclosed contents. I do not advise the latter. The difference in experience for those who are successful, and not logged in as root appears to be the difference between dowloading the standalone installer and using Software Update; SU sets ownershipt to root (system), while the standalone seems to set ownership to the user (or at least allows others to Read & Write). HTH -- Frederico [alert admin]
Read Comments (2) | More Info | 1 of 1 users found this helpful
Tuesday, June 24 2003 @ 07:25 PM PDT
SwapSwapVM 0.9.8b12 (Mac OS X)
you used an earlier beta version; many error handlers improved since; it's only "kludgy" to the degree of its earlier dialog interface and predicting every possible user variable -- that's what beta testing is for! Next time try reporting your errors to us so we can work them out before you give us a negative rating for BETA software, please! Dangerous? Only if you don't follow the instructions and heed the error warnings! The fact that you got error warnings proves its NOT dangerous! -- Regards, SQ [alert admin]
Post a comment | More Info | 1 of 1 users found this helpful
Wednesday, February 12 2003 @ 11:41 PM PST
Pop-Up Zapper 2.0 (Mac OS X)
until Ricardo can respond:Greetings, While I appreciate some of the new functions in v2.0, so far, this install has been flakey as heck, to the point of being unusable. 1) Getting it to activate is a thorough hit and miss proposition; the only sure way to get it to actually work is to fully logout, login, launch PUZ first, then IE, then you have to open an actually blank (not a new window that defaults to a home page) window to get PUZ to "see" that IE is now running. And, yes, I fully understand how I'm supposed to get it running; it just plain doesn't work as advertised, even if the menu says it's on. 2) Regardless of the hoops one jumps through above, (as noted on the website under known issues), the yellow/gold 'X' never goes away, and the PUZ Status window never acknowledges IE as active (whether it is or isn't). This makes verifying the true active state nearly impossible, save for going to a known popup-generating site and seeing what happens. 3) As if all of that isn't bad enough, this version, unlike 1.x versions, frequently confuses the parent window for the popup window, and kills the wrong one. This is demonstrated frequently and repeatedly at GistTV.com. 4) Further still, if you have 'Alert on Exceptions' enabled in the Java prefs (something developers require), PUZ will either not work at all; kill the parent window; and/or send the JavaScript error window into an endless loop (that would not otherwise be generated more than once on a page that has an actual error). (cont.) [alert admin]
Tuesday, December 17 2002 @ 06:51 PM PST
Pop-Up Zapper 2.0 (Mac OS X)
depressing, PUZ frequently confuses 'Open in New Window' requests (Command-Click) as popups, and kills the newly opening window; usually it is never seen; apparently PUZ is making good on its promise to make "undesirable" windows invisible before death; PUZ-oriented death is indicated by the selected sound option being made active. Subsequent Command-Clicks on the same link will now fail repeatedly, until one Command-Clicks on another link to "clear the logjam"; which may or may not work; if successful, one may be able to return to the desired link and now a Command-Click will actually open the previously "dead" link in a new window as desired. 6) Clicking on Toolbar Favorites has always been flakey in IE 5.x (many users complain that instead of activating the link, it acts like a Control-Click and gives the menu), but now with PUZ 2.0, many Toolbar Favorites clicks simply are ignored, or may behave as in (5) above. The final nail in the coffin for this release is that a Command-Click on a Toolbar Favorite Folder simply *will not* open that folder in a new window; requiring one to Control-Click and use the menu selection instead. Lots of bugs to fix here before this can be tolerated full time; let me know if there's some feedback I can provide; the only possibly relevant issues I can suggest right off are that I run multiple monitors (6), and also use numerous GUI enhancers, such as Keyboard Maestro, FruitMenu, WindowShadeX and others that "listen" for keystrokes. Cheers Frederico [alert admin]
Tuesday, December 17 2002 @ 06:51 PM PST
Last 10 Comments by FredericoR [ Search for All ]
Hi, the latest internal build (to be released shortly) addresses that issue. Sorry you had problems. Please read the Read Me and report bugs directly to the developer to receive faster response and access to internal builds for testing your specific issues.
Original feedback item : Read More
Monday, August 11 2003 @ 02:31 PM PDT
I didn't meant to imply that the permissions problems were with Safari, but with SafariNoBrush's inability to apply changes due to its lack of authorization, or, rather, its apparent oversight in predicting it as a problem. Thanks for the comment and opportunity to clarify.
Original feedback item : Read More
Thursday, June 26 2003 @ 10:49 PM PDT
