Ctrl-A Select all text in active textarea. Ctrl-B Make the selected text <B>bold</B> if applicable. Ctrl-C Copy selected text. Ctrl-D -- available -- Ctrl-E -- available -- Ctrl-F Find, as in search the active textarea if applicable. Ctrl-G -- available -- Ctrl-H -- available -- Ctrl-I Makes selected text <I>italic </I> ( DanielHarris, 5/5/98, see <A HREF="http://www.jos.org/wiki/view/main/DanItalics">DanItalics</a> ) Ctrl-J -- available -- Ctrl-K Cut the rest of the line ( MarkusPeter, 5 Dec 97 ) Ctrl-L -- available -- Ctrl-M Mark selected item, object, etc. if applicable. Ctrl-N New document, item, object, etc. if applicable. Ctrl-O Open object, item, etc. Also display the "Open File" window (if applicable). Ctrl-P Open up the printer setup window to print current window. Ctrl-Q Quit [the application]. Or prompt to shutdown JOS if no applications are open. Ctrl-R Refresh view if applicable. (see F5) Otherwise, Redo last action (see Ctrl-Y) Ctrl-S Save object, item, file, etc. Works like Save As if its a new document. (see Alt-S for Save As) Ctrl-T -- available -- Ctrl-U Underline selected text (if applicable). Otherwise Undo last action (see Ctrl-Z). Ctrl-V Paste text, object, item, etc. which was last copied. Ctrl-W Hears a new idea: Ctrl-W might cycle through all stages of a window: minimize, maximize, window-ize (in between). Ctrl-X Cut selected text, object, file, item, etc. Ctrl-Y Redo last action (opposite of Undo). Ctrl-Z Undo last action.
Well that's just my preliminary ideas. We haven't even gotten into the function keys, the alt combos, the ctrl-alt combos, or the ctrl-number and alt-number possibilities!
Keep in mind the keys in the center of the keyboard are usually not the easiest to reach for Ctrl/Alt combinations...
-- MasonZhwiti (12/5/97)
Hmmm. In my opinion, it would be wise to have some sort of StandardShortCutsManager. For example lots of people prefer Emacs' ShortCuts (including me) while others are familiar with Windows' ShortCuts. We should not force users to get familiar with another set of shortcuts. A central manager for the shortcuts would allow to assign a standard set of shortcuts to EVERY program. Coding-Wise this will cause some problems though, as programmers tend to include fixed short cuts in their programs or their own management. Maybe the "Written for JOS" label for applications is not such a bad idea anyway.
-- Markus Peter ( 5 Dec 97)
This sounds like a GREAT idea. We'd need a way of determining if the application supports JOS or not. We could either define a base class for JOSApp or an interface, or both. --BillRehm (971205)
I think we should be real careful about "written for JOS" things... IMO this is exactly what we're trying to avoid with JOS. If everyone starts writing programs for JOS, then we've strayed away from the promise of Java and a Java operating system. We want to encourage people to write good pure Java programs that run on all platforms. Now, if there are things we can do to make them run faster, more efficiently, etc. on our OS that's great. But to entice programmers to write special things for our platform sounds very, well... Microsoftish.
I do like the idea of the ShortCutsManager, in that people should have as much choice about their environment as possible. However, Emacs is not so much an operating system as it is a complex program. I understand Emacs is similar to an operating system in that it can run programs, act as a shell, text editor, and a whole lot more. But the StandardShortCuts I am proposing are more of a guideline for the programs written for inclusion in JOS.
When someone writes a full-fledged text editor in Java, I would fully hope that they allow the user a choice between different editing environments: our StandardShortCuts, Emacs, Brilliant, etc...
-- MasonZhwiti (12/5/97)
A clarification. I fully expect applications "written for JOS" to be able to run on any platform with a VM. Think of it as an application toolkit. We provide the class libraries needed to allow an end user to interact with a ShortCutManager and programs that user our ShortCut classes will be able to load the user's instance of the ShortCut class (in this instance). This is not pulling a Microsoft, IMHO. Anybody who wants to can include this functionality in their programs by using our freely available classes. It's not tied to the JOS platform, it's tied to the JOS Application Architecture (that might be a bit grandiose). --BillRehm (971205)
See TradGuiTaskWidget for the whole rant, but this can be solved with objects. If you want better shortcut key support than is in Java (they support it now!) then you can call methods that will be in a class designated as the ShortCutDaemon (or whatever). There won't be any one such object, but an interface to implement, and so we will be able to easily provide a few popular key binding sets (MS, Emacs, etc) with the system. Implementing your own won't be too terribly difficult for anyone hackish enough to want to, or... we could have a class attached to a config dialog which builds up a ShortCutDaemon custom for you, and lets you use it instead. (Come to think of it, it'd all be in the same config dialog, and quite unknown to a user who didn't want to know) Now all we need is to hack out the interface for that, and for the system's configuration...
My list of shortcuts above was intended to be the standard, i.e. JOS, shortcuts to go with the JOS Look&Feel that will no doubt come about soon. Of course those proposed shortcuts are entirely open to debate. They draw mostly from windows shortcuts, but if there are others that "make more sense" we should consider using them.
-- MasonZhwiti
OK, but than please remove the non-intuitive state-dependent shortcuts like:
Ctrl-R Refresh view if applicable. (see F5) Otherwise, Redo last action (see Ctrl-Y)
This is a bad thing, confusing a not neccessary... A standard shortcut key must always do the same thing. -- JeroenVanGelderen
I agree with JeroenVanGelderen, With the exception that I think Ctrl-Q should both exit an application and be able to exit JOS. --DanielHarris, 9 May 98
I'm worried about implementation details of such a system. I can think of many ways to do this. Here's a simple way which might be appropriate:
Have a class org.jos.package.ShortCutKey, and an interface org.jos.package.application, and put in it a method like shortcutKeyPressed(ShortCutKey sck); This simple implementation would allow us to define exactly what being "written for JOS" means, as well as allow us to develop ShortCutKeyManagers or whatever we want, and allow these to handle users' preferences. --MichaelFried
The only part of keyboard shortcuts that can be JOS-specific is the system ones (task switching, context menus, etc). Java applications will have their own shortcut support (in jdk 1.1 and up) and the most we could do with them is to remap the keys in the OS (maybe in the Shell). This would be optional to users/admins of course. It does not seem prudent to force programmers to implement specific interfaces to get functionality already available to them in pure java.
Of course we know, that there are already shortcuts available in Java... The point is, that system wide shortcuts, where applicable, are very convenient for users... So I see no problem, if we offer our own sort of optional shortcut support. These classes can be 100% pure anyway and could therefore be ported to other platforms together with the applications which use them. Such a sort of shortcut manager could server on JOS for a system wide user preferrence, and on other platforms as an application specific shortcut chooser... MarkusPeter
back to TGUIG: TraditionalGUIGroup
| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|