From: Heimo C. <ha...@re...> - 2003-01-12 01:34:04
|
As Frank Neumann wrote: > Also, though GTK programs let you dynamically change the shortcut key > assignments by pointing at a menu item and pressing the key you want to > correspond to it,... Ahh - is there ? Couldn't there be a script to make this ? (Kind of "load your own hotkey list" which could be invoked automatically before running Sweep ?) I'd sign up to number of the other points raised too - the ergonomy ("handling" I would call it) has not yet been too much in focus (though Conrad is very open to relevant suggestions and does his best; for instance, the selection of the sample files directory now carried along to a next session, and with "load file" in general.) I made my own (long) list of such suggestions and sent it to Conrad earlier. But maybe it's meaningful to post such to this list too: it could be helpful for Conrad as well as all interested to discuss what preferences there are. For instance, I do not know if my dearest wish for "bookmarks" (or anchors, in a wavfile, to navigate in-between and to use as editing points, or even as marker points of earlier editing) is an isolated, exotic idea or a worthwhile feature for others' editing habits. // Heimo Claasen // <hammer at revobild dot net> // Brussels 2003-01-11 |
From: Heimo C. <ha...@re...> - 2003-01-12 23:43:56
|
Andre Pang wrote: > I'd recommend against changing the standard shortcut keys, since > that can make every single copy of Sweep different. I beg to differ - I didn't recommend any change for Sweep's key settings in general and for anyone else but wondered about the possibilities to change these for one's own preferences (via some script or config file). More important, there _is_ no "standard". At most, what Conrad decides to use is creating a setup for Sweep (and for nothing else). With some of the key uses, he said once, he took some inspiration form a seemingly well distributed Windows editor (which I don't know). But basically it's depending on his insight, intuition, and preferences - others might have others. What there is not yet (and couldn't be established yet, logically) is a systematic approach based on, for instance, most commonly used keypresses: which depends on - probably even very different - practices in working with the program. -- "Most used" functions, for instance, appropriately would have a one-keypress definition: but again, it may widely differ what is in fact used mostly by one or the other user. -- I would strongly doubt the assumption, that there would be a high number of cases where one installation of Sweep on one unit would be used by many different people; I'd rather suppose the one-user situation would be most common. -- Differences of keyboard layout _is_ an issue, though; and what makes good sense for use on the IBM/US keyboard can be a pain with the French "azerty" (and vice versa). This _could_ be avoided by describing those keys by their _scancode_ instead of a char symbol but evidently this is not highly practical.(*) All this speaks, IMHO, for some possibility to configure the keypresses individually. Although this may not be of a high priority at the moment; but as there seems to be some means to do it via the GTK enviroment (as mentioned by Frank Neumann) I just wondered if this couldn't be used indeed for creating one's personal preferences list. What is of a higher priority in ergonomic aspects, and was mentioned in the same "wich list", is a better feedback for the selection tool: as it is, I find it quite erratic to use, even inside one activated window (not to speack of the surprises when changing active windows.) Just my 2 EUROcents. // Heimo Claasen // <hammer at revobild dot net> // Brussels 2003-01-12 (*) BTW, is there any utility, like I'm used to in DOS, to easily get the scancodes from a keyboard ? For instance, I have four "German" DIN kbds here where the ">" sign is at four different places, <g>. More generally, every symbol in the caps row of the uppermost char keys of keyboards is a no-no for use as a "standard". |
From: Andre P. <oz...@al...> - 2003-01-13 07:10:23
|
On Mon, Jan 13, 2003 at 03:31:02AM +0000, Heimo Claasen wrote: > I beg to differ - I didn't recommend any change for Sweep's key > settings in general and for anyone else but wondered about the > possibilities to change these for one's own preferences (via > some script or config file). Sorry, what I meant was that we should not allow users to pick their own key settings, and force them to use one single keyboard layout. This is the exact opposite of what you're suggesting above :). I'd recommend this for the simple reason of consistency: moving from one PC with Sweep to another PC with Sweep guarantees the same accelerator keys on both PCs. I can't think of a single Windows or Macintosh sound editing program which allows you to customise its key bindings, and I don't feel like those programs limit my editing capabilities because the accelerator keys have been chosen with care; there's nothing I want which makes me think "I wish this key was different" or "I wish this feature had a key for it". In other words, if some menu options or features would greatly benefit from accelerator keys, let's talk about them here so that Conrad can define an accelerator key for it which then benefits _all_ users, not just a single person. Chances are, if _you_ want a particular key, somebody else out there wants it -- and they don't _know_ they want it. When they see a new release of Sweep with such a key binding, they may think "Hey, this is cool! I didn't even know I wanted this!". That's the philosophy behind my suggestion -- benefit all users and keep a consistent, standardised keyboard layout. > More important, there _is_ no "standard". At most, what Conrad > decides to use is creating a setup for Sweep (and for nothing > else). With some of the key uses, he said once, he took some > inspiration form a seemingly well distributed Windows editor > (which I don't know). But basically it's depending on his > insight, intuition, and preferences - others might have others. I understand your point, but those others (including users) can be wrong. The gtk+2 toolkit took out the capability to change accelerator keys in the menu precisely for this reason: they saw the value of consistency and decided it was better to be consistent and standardised than to be completely customisable. -- #ozone/algorithm <oz...@al...> - trust.in.love.to.save |
From: Conrad P. <co...@ve...> - 2003-01-13 17:18:30
|
Hi guys, it seems the main problem Heimo has identified is that some of the keybindings are awkward or impossible with different keyboard layouts; ie. everyone in France will have the same problems with the plus key, or whatever. this is especially a problem with the tracker-style use of the QWERTY keys -- in Germany, on a QWERTZ keyboard, C1 is swapped with A2, which is just silly. so, as a first step, what I'd be quite keen to do is localise the keybindings, ie. change the default set of keybindings based on locale. Conrad. On Mon, Jan 13, 2003 at 06:08:03PM +1100, Andre Pang wrote: > On Mon, Jan 13, 2003 at 03:31:02AM +0000, Heimo Claasen wrote: > > > I beg to differ - I didn't recommend any change for Sweep's key > > settings in general and for anyone else but wondered about the > > possibilities to change these for one's own preferences (via > > some script or config file). > > Sorry, what I meant was that we should not allow users to pick > their own key settings, and force them to use one single keyboard > layout. This is the exact opposite of what you're suggesting > above :). I'd recommend this for the simple reason of > consistency: moving from one PC with Sweep to another PC with > Sweep guarantees the same accelerator keys on both PCs. > > I can't think of a single Windows or Macintosh sound editing > program which allows you to customise its key bindings, and > I don't feel like those programs limit my editing capabilities > because the accelerator keys have been chosen with care; there's > nothing I want which makes me think "I wish this key was > different" or "I wish this feature had a key for it". > > In other words, if some menu options or features would greatly > benefit from accelerator keys, let's talk about them here so that > Conrad can define an accelerator key for it which then benefits > _all_ users, not just a single person. Chances are, if _you_ > want a particular key, somebody else out there wants it -- and > they don't _know_ they want it. When they see a new release of > Sweep with such a key binding, they may think "Hey, this is cool! > I didn't even know I wanted this!". That's the philosophy behind > my suggestion -- benefit all users and keep a consistent, > standardised keyboard layout. > > > More important, there _is_ no "standard". At most, what Conrad > > decides to use is creating a setup for Sweep (and for nothing > > else). With some of the key uses, he said once, he took some > > inspiration form a seemingly well distributed Windows editor > > (which I don't know). But basically it's depending on his > > insight, intuition, and preferences - others might have others. > > I understand your point, but those others (including users) can > be wrong. The gtk+2 toolkit took out the capability to change > accelerator keys in the menu precisely for this reason: they saw > the value of consistency and decided it was better to be > consistent and standardised than to be completely customisable. > > > -- > #ozone/algorithm <oz...@al...> - trust.in.love.to.save > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > sweep-devel mailing list > swe...@li... > https://lists.sourceforge.net/lists/listinfo/sweep-devel |
From: Frank N. <bea...@we...> - 2003-01-14 23:34:28
|
Hi, Conrad Parker <co...@ve...> wrote: > it seems the main problem Heimo has identified is that some of the > keybindings are awkward or impossible with different keyboard layouts; > ie. everyone in France will have the same problems with the plus key, > or whatever. > > this is especially a problem with the tracker-style use of the QWERTY > keys -- in Germany, on a QWERTZ keyboard, C1 is swapped with A2, which > is just silly. Correct. I have had this problem with other audio software before. In some cases it was easy to fix (e.g. vkeybd for ALSA), other make it more difficult. > so, as a first step, what I'd be quite keen to do is localise the > keybindings, ie. change the default set of keybindings based on > locale. Ok, that's a start. If you need input about e.g. the german keymap layout, feel free to ask. Though, IIRC, the "xkeycaps" program will also nicely show you all kinds of international keyboard layouts. Greetings, Frank |
From: Conrad P. <co...@ve...> - 2003-01-15 11:25:19
|
On Wed, Jan 15, 2003 at 12:03:00AM +0100, Frank Neumann wrote: > > > so, as a first step, what I'd be quite keen to do is localise the > > keybindings, ie. change the default set of keybindings based on > > locale. > > Ok, that's a start. If you need input about e.g. the german keymap layout, > feel free to ask. Though, IIRC, the "xkeycaps" program will also nicely > show you all kinds of international keyboard layouts. > cool, thanks for the tip on xkeycaps, that's a nifty program and seems to give quite enough info on layout next, does anyone know how to find out what keyboard is currently being used? I assume its listed in the X server somewhere, but getting it out of gtk would be nice ... Conrad. |
From: Frank N. <bea...@we...> - 2003-01-14 23:34:27
|
Hi, Heimo Claasen <ha...@re...> wrote: [discussion deleted - I pretty much agree with Heimo's statements here] > (*) BTW, is there any utility, like I'm used to in DOS, to easily get > the scancodes from a keyboard ? There is an old tool, low-level, but still useful, part of every XFree distribution. It's called "xev". When started, it opens a small window. Move your mouse pointer into this window, and you'll see lots of events fly by the stdout of the xterm from which you started it. Now press and release some key (don't move the mouse or press any modifiers - they also immediately create events). You should then see "KeyPress event", followed by "KeyRelease event". In both output blocks you'll see a "keycode=.. (keysym=..)", and the keycode is perhaps what you want. This can also be used in "xmodmap" invocations to remap certain keys. (Don't mix this up with the keycodes that "showkey" gives you when you start that program from a console - they differ). Greetings, Frank |
From: Heimo C. <ha...@re...> - 2003-01-14 23:48:40
|
Having the (or some) keybindings linked to the locales would indeed be a good first step; though it's not the solution yet - just for an example: I use a "German (nodeadkey)" keyboard with the "English(US)" language set-up of my "system".<g> A thorough rethink about the keybindings could well be worth while. As Sweep is not yet molded in reinforced concrete for all eternity, there is a chance to do away with some *nixish idiosyncracies too - for instance, why use shifted keys for often done functions when a one-key press is available and appropriate ? (Take the use of [CTRL]-[c], which is widely used for break-out - at least psychologically not the best choice for the frequent "copy" task.) Mind that more and more "modern" kbd.s even come with one [CTRL] and [ALT] key only. Then, some of the "core keys" of keyboards which do _not_ dance around with those many variations of kbd layouts, could and should be used for the most frequent tasks. These are basically the old Telex/ASCII definitions - but one has to watch for many exceptions, a close look at the ISO-disigns for the larger language groups does help already: While the changed key placings (of [q] and [a] between German/French layout, or [z] and [y] between English-US and the rest of the world) are a matter of getting used, all punctuation signs - [;][:][!] and even the [.] and [,] - and certainly those like [/],[\], and all brackets - are moved around on those layouts and often demand shifting. And while [+] and [-] are fairly safe, the [=] and [*] can be unpleasant to use. Rather consistent are the various arrow keys, incl. [home]/[end]. <besides> Happens I know a bit of this misery (and the confusion between key symbols, placings, and scancocdes) from endless discussions and program adjustement of text editors in a multilingual environment. I'm convinced that Andre would be up in arms if Conrad used some of the French frequently used keys for shortcuts to main tasks.</besides> As there is no doc/manual/overview yet, I made my own list of used keybindings; and find the logic and physio-logic not highly convincing. I join it with some comments below. (Note that this was done with Sweep 0.5.4, some more tags have been added in the meantime.) I really think the best solution to the thorny issue is a little "engine" (like there is in a number of apps, even with the Midnight Commander) which lists the functions/actions available and prompts for pressing the key(s) to bind with it. Alternatively and for a time being, a simple configuration list (take that of the Lynx pure text config file as pattern) could do as well. And whoever wants to jump between systems can easily carry this little file around to, for consistency's sake.<g> // Heimo Claasen // <hammer at revobild dot net> // Brussels 2003-01-14 Listing Sweep (0.5.4) keybindings --------------------------------- Note that some commentary even relate to functionality, -hc [CONTROL] key = "^" (caret); only unshifte letters used (printed as caps here for clearer reading); "..." = no shortcut defined yet TASK / ACTION Present Proposed Commentary KEYBINDUNG ============= ======= ====== =================================== FILE: New file ^N ^O Open file ^O O Save file ^S S Save as.. ... ^S Close (file) ^W X Quit (program) ^Q ^X PLAYBACK: Config.audio device (menu) TRANSPORT(menu): Go to file start ^Home Go to file end ^End Go to window start Home Go to window end End Skip back "Prior" (? does this mean "PgDn" key ?) Skip forward "Next" (? does this mean "PgUp" key ?) (Other navigation keys) Pause [ENTER] (I'd prefer either [ENTER]/"Return" or [SPACE] Pause inside selection [SP]ace (consistently for "stop/pause" and "continue Continue [SP] (play" toggle, regardless of if the cursor is Play sample ^[SP] (in a region/selection or not. Stop playback ... (?!) (Then, [CTRL]-[ENTER] would get the cursor to (only w/mouse on button) (a mouse/pointer position, and ^[SP] could (remain with the present action "play sample", move cursor frame left [Left] (and [BackSpace] / ^[BS] or like could move mv. curs. 1 frame rght [Right] (cursor to next left/right region limit or (other "bookmark". Present framewise move of (cursor/play with Left/Right arrow key is (appropriate then. VIEW Center / 0 Zoom in = + [Up] arrow (These do that too, and that Zoom out - - [Down] arrow (would be enough; then the ("good" [+] and [-] keys could (be used meaningful to some (related task, like the next 2: Zoom all ^1 ^[PgDn] 1 : 1 ... ^[PgUp] Zoom to selection ... (is shortkey needed ? but there should well (be a key to "move window to selection" or (alternatively, place left limit of region (at start/center window. SELECT NEW: select SELECT ... T (There _MUST_ be a key shortcut to chose ==== select SCRUB ... Y (between the TOOLs, "select" and "scrub" !!! (That could be a TOGGLE too, with just one (key, and _clear_ reaction in the top bar of (the respective active vindow at the buttons! Invert ^I I Sel. all ^A A None (deselect) SH-^-A Z (THREE keys is really a no-no ! shift left < L (The bracket problem... shift right > R EDIT Undo ^Z U Redo ^R ...? (shortcut needed ?) Delete ... DEL Cut ^X D Copy ^C C Paste ^V INS Paste as new ^E ^INS Clear ... ...? (shortcut needed ?) Crop ... ^DEL (as I understand it: delete empty start/ (tail REM: [DEL]ete and [INS]ert keys, as well as their CTRL-shifted ones, are always there and have scancodes - VERY practical to use! PROCESS Echo SH-E E Normalize SH-N N Reverse SH-F V Select by energy ... G (?) (shortcut needed ? SANPLE Duplicate ^D P ---------- General intention is to substitute mouse/pointer movements by _easily_ accessible (and memorised...) keys: just one for more often used, and CTRL-shifted for _related_, more seldom used or more "dangerous" tasks. (There are lots of "easy" keys still left free left with the proposed settings, yet the number of shifted ones is quite reduced.) (The SHIFT-shifted are abandoned, for consistency: using CTRL-shifting avoids confusion between upper/lower case.) Mouse movement should be linked foremost to marking/selecting (or scrubbing), and a selected pointer position should not be lost/disturbed by moving it to select buttons. (Mouse "dragging" for selection does not work well yet presently; and must be unambigous. A better visible - colour change ? - indication of the active tool button in top row of window would help too: _And_ the mouse/pointer must not be moved away from its position to select the tool ! Therefore proposed key shortcut for this above.) Mouse/pointer functions: -- Left click: set (book-)mark, limit -- on set mark/limit: erase mark/limit -- Left button hold, move: mark region (both directions) from starting point on. -- Central button (or left+right) click: bring cursor to mouse position - same as ^[ENTER] -- Left Double-Click: select region between marks where pointer is (or from mark to start/end of file respectively) - same as proposed shortcut "select ponted region. -- Left double-click on marked region: deselect - same as Deselect shortkey. |
From: Andre P. <oz...@al...> - 2003-01-15 08:15:02
|
On Wed, Jan 15, 2003 at 01:35:53AM +0000, Heimo Claasen wrote: > (Take the use of [CTRL]-[c], which is widely used for break-out > - at least psychologically not the best choice for the frequent > "copy" task.) Ctrl-C is the best choice for the copy task, because it can be assigned consistently on all programs -- including text editors. Users won't be happy if pressing C in their text editor copies text instead of inserting a 'C' character :). Likewise, they won't be happy if different applications use different keys (C vs Ctrl-C vs Alt-C vs whatever) to copy. Sweep should follow the gtk+ standards and use Ctrl-C to copy. > I'm convinced that Andre would be up in arms if Conrad used some of > the French frequently used keys for shortcuts to main tasks.</besides> I wouldn't be up in arms at all, as long as that behaviour is consistent with the other keys in a French localisation of GNOME. For all I know, Cut/Copy/Paste in France might be Ctrl-T/Ctrl-C/Ctrl-P; if it is, then Sweep should follow that standard and do the same. > TASK / ACTION Present Proposed Commentary > KEYBINDUNG > ============= ======= ====== =================================== > FILE: > New file ^N ^O > Open file ^O O > Save file ^S S > Save as.. ... ^S > Close (file) ^W X > Quit (program) ^Q ^X What on _earth_ is a new user going to think when they look at Sweep and see that "New file" is Ctrl-O, which is _completely_ ignorant that in every single other gtk+ application, "New file" is Ctrl-N? Not only that, it's mapped to the key which normally serves the "Open" function. Now we've got key overloading for a basic, fundamental operation. Hooray! Sorry, I'm going to spit the dummy on this one. Do you have any idea how long it'll take for users to adjust to this "better" keyboard layout, or any idea how many users won't bother to use Sweep simply because they'll look at that and think "What?!"? Are you so arrogant to think that users are better served by your "better" keybindings even though it's completely different to the standardised keys? Ctrl-N should make a new document. Fullstop! No argument! Ctrl-X should _always_ cut. Ctrl-C should _always_ copy. Ctrl-Z should _always_ undo. Always! By your reasoning, we'll just make the user learn one completely different (but "better") set of keybindings just so she can use Sweep, at the mere cost of forcing them to do a mental task switch whenever she switches to using Sweep from every single other gtk+ application. You're saying to the user "Sorry, you're going to have to unlearn all those conventional key shortcuts that you learnt from using every single other gtk+ application you've encountered, and instead learn our special set of key combinations. But _trust us_, it's _better_ for you this way!" If you applied this reasoning to every program that was important to them, they'd have to learn a completely different set of keys for every single one of them. Their productivity goes down the drain. Programs which diverge from such conventions are not only unfriendly to the user, they look unprofessional and amateur. Users don't use programs which look unprofessional. Sorry to flame, but I'd rather say all of this now so that I say something constructive, rather than keep quiet and let Sweep join the other 99% of Linux audio applications which suck because the developers have ignored anything and everything to do with usability. End of rant. Flame away. -- #ozone/algorithm <oz...@al...> - trust.in.love.to.save |
From: Patrick S. <psh...@bo...> - 2003-01-15 10:21:04
|
I agree that sweep should stay consistent with bindings like ctrl+c ctrl+z ctrl+x ctrl+o ctrl+q ctrl+s = - . Most apps use these for exactly the same ops. If you are looking for more versatility in keymapping then take a look at protux. It is designed with a completely different paradigm and might provide you with a more friendly env to work in. Also regarding the use of single keys for tasks. Sweep has a nifty feature which will adjust the pitch of the file depending on which key you press. Try it out. It's kind of handy for live work. It also means that pretty much all of the previously mentioned single stroke keybindings cannot be applied. On the subject of features I would like to have a cue in/out. I find this invaluable for setting loops while djing and having it in sweep would make it that much more useful. Essentially two buttons. One for loop start and one for loop end. loop start: press always equals start loop end: 1st press = end 2nd press = release end (turn off loop) If there is a selection, pressing in will release the end point which requires setting it again with the loop end button. Pressing loop end never resets the start. I have tried doing this with the mouse but it is not precise enough. Essentially it is just a way of setting the start/end of a selection while the transport is rolling. -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== Being on stage with the band in front of crowds shouting, "Get off! No! We want normal music!", I think that was more like acting than anything I've ever done. Goldie, 8 Nov, 2002 The Scotsman |
From: Pete R. <pd...@pd...> - 2003-01-15 11:39:02
|
On Wed, Jan 15, 2003 at 07:13:59PM +1100, Andre Pang wrote: > On Wed, Jan 15, 2003 at 01:35:53AM +0000, Heimo Claasen wrote: <snip> Well said mate. I was wondering if there was some other, French, Andre on the list, but I guess not. :) Anyway, Conrad's no fool and I'm confident that he is very knowlegable (and concerned about) usability and has shown that he is interested in making sweep's "motor memory" keyset usable under different keyboard layouts. I just hope that for sweep's sake Heimo hasn't put him off this idea. Pete |
From: Conrad P. <co...@ve...> - 2003-01-15 13:02:37
|
Hi Heimo, thanks for the constructive comments. I'm not totally against totally customizable keybindings, but by default I want sweep to be as useful as possible. This means: 1. adhering to the appropriate human interface guidelines; ---------------------------------------------------------- ie. using standard keybindings where possible on a platform. This could be selectable, eg. if someone is mostly using KDE apps then behave like KDE apps do. 2. using locale-specific keybindings where available. ----------------------------------------------------- If the French keybinding for "new file" is different to the English one, and you're running in French, use the French keybinding. Similarly for keys which are used for their location, eg. matched brackets, +/-, tracker keys etc. Keybindings should vary appropriately. 3. behaving similarly to popular existing software. --------------------------------------------------- The existing keybindings in Sweep are largely modelled after those in Sound Forge, a popular editor on Windows. This is great for people who are used to Sound Forge -- one user even commented that they sat down at Sweep and "just touched it, and everything worked". This is important because expert users develop motor memory for common tasks (ie. the finger movements required happen sub-consciously). If we expect people to migrate from other programs to Sweep, we'd better accomodate their motor memory or they will find it cumbersome. The flip-side to this is that if you're not an expert user of program X with similar keybindings, it's just as hard to migrate to Sweep as it would have been to migrate to X. Now, this could also be selectable; there are plenty of other sound editors in the world that people are used to. But for now we're talking about defaults. Sweep should simply adapt the most useful keybindings that are common to other software; but there is no need to mimic rarely-used shortcuts. Well, although much of the navigation is similar to Sound Forge, the core transport controls (play, play sel, stop, pause, and toggling looping) are slightly different but roughly similar, simply because Sound Forge's way of handling these is a little bizarre (it uses playback modes, we just have set keys). I'll gladly take suggestions for modifying the default keybindings based on people's experiences with what works well in other software. What's most important here are the really common keys, the stuff that sticks in motor memory: navigation, transport, marking, and the most basic edits. But these keys shouldn't override those of points 1 and 2 above, or point 4 ... 4. allowing room for new styles of working ------------------------------------------ Even after all that above, remember that the aim here is to provide a fresh way of dealing with audio files -- hence the emphasis on scrubbing, and the mix of live performance and editing controls, simply because the stuff that's useful live (fast navigation, variable speed playback) is also useful for getting around a file while editing it. So, if people might just possibly use Sweep a little differently to how they use other software, make the new way easy. Hence the use of most of the keyboard for changing playback rate. What the heck is that doing in an editor? it's making the editor useful for testing out instrument samples. Hence the use of the Meta or Multi (Windows) key as a scrubbing shortcut, to reduce strain on your index finger and to allow more free movement of the mousing hand. Ok, so although making keybindings fully customizable would solve the immediate problem (ie. Heimo could work how he wants to), this would hardly solve the real issue of providing the most useful behaviour possible -- there are probably plenty of other people who would benefit from Heimo's preferred keybindings because their environment is in French, or because they're on a different platform, or whatever. It'd be nice to be able to customize by saying "this is my keyboard type, this is the desktop I'm used to, this is my favourite fish". But forcing every user with a non-US keyboard layout to remap the zoom keys manually is silly, and pretty rude. Sweep should be able to work that stuff out automatically, and behave as usefully as possible in every other way. So, before doing anything related to making keybindings totally customizable (which I'm not totally against), I first want to make the default behaviour as smart as it can be. I want the people who care about this to complain, criticise, and offer suggestions, as Heimo has done. Conrad. |
From: Heimo C. <ha...@re...> - 2003-01-18 20:34:47
|
Yes, yes, mea culpa - I completely forgot about this: > Sweep has a nifty feature which will adjust the pitch of the file > depending on which key you press. As far as I can find out, this concerns the upper row of the characters keys (thus, from [Q] to [] via [Z], <g>.), four steps leftward and four steps rightward. Though from a handling point of view, and if I would use that pitch-changing feature often, Iwouldprefer to place it on the _lowest_ row of char-symbol keys (i.e., [Y] to [,] - <bg again>.) And there's one utmost important hotkey - at least for my needs - and which I found onla after Conrad's hin to look at the "showroom window" of Sweep, and there farthest down - [CTRL] + [mouse_dragging] to have several regions marked in a file. Thus, first thing to do is to simply establish a complete inventory at all, and have a concise list of all keybindings indeed useable. Someone volutary to comply my list ? (Then, with some commentary, couldn't this serve already as a short guide on how to use/handle Sweep ? Which is dearly lacking yet.) Some even more personal/subjective remarks: Iwouldn't want tu "put off" Conrad from anything; and if someone is happy with the keybinding arrangement as it is, that's not my business either to force him/her to change. However, firstly, among the three-four GUI progs on the Linux box I use here, there's not one single one which would have even some of the most basic shortkeys like one of the other. Secondly, it happens that I don't touch one or the other of these progs for a while or even (GASP!) the whole machine (real, practical life is sometimes intervening to keep me offscreen, <sigh>.) Result of this is that I have forgotten half of the keybindings, and certainly all the more rarely used, in the meantime. With far too much mouseclicking in consequence -- a concise list to look up or even print out would be helpful to fresh up what there is of "motoric memory". That latter indeed is a salient argument. But then, where is the "consistency" when [CTRL]-[C] almost everywhere is used for break-out, but not in Sweep ? Or, [SHIFT]-[CTRL]-[A] (to unmark all regions selected) could hardly be called a "standard" for this not-so-seldom used task; and ergonomically it's plain nonsense. Though I know that there are people around who wouldn't be happy without a three-keypress approach to delete a last latter typed wrongly - for my part, I prefer to use [backspace] right away; and I would really dislike someone who'd try to force me to use [ESC], [CTRL]-[space]-[x] instead. To sum up: what I uttered as a wish to Conrad - to give the freedom to change one or the other of the keybindings - would _not_ imply that Conrad would fix, for everyone and all eternity, any other pattern as the one he uses and proposes. Though some of those arguing for a (pseudo-)"standard" do precisely that latter. (BTW, Andre, I wouldn't consider arguing about this as "flame", and sure wouldn't take your posts for that. There is a serious and fargoing difference on the approach to how to handle the 'puter linked with it; and that the *nix-world carries along some of these elements, the absence of which helped to make Windblow$ the success it is, makes it a relevant issue, me thinks.) // Heimo Claasen //<revobild at revobild dot net>// Brussels 2003-01-18 |
From: Frank N. <bea...@we...> - 2003-01-19 16:22:18
|
Hi list, Heimo Claasen <ha...@re...> wrote: [..] > That latter indeed is a salient argument. But then, where is the > "consistency" when [CTRL]-[C] almost everywhere is used for break-out, > but not in Sweep ? Or, [SHIFT]-[CTRL]-[A] (to unmark all regions > selected) could hardly be called a "standard" for this not-so-seldom > used task; and ergonomically it's plain nonsense. Though I know that > there are people around who wouldn't be happy without a three-keypress > approach to delete a last latter typed wrongly - for my part, I prefer > to use [backspace] right away; and I would really dislike someone > who'd try to force me to use [ESC], [CTRL]-[space]-[x] instead. I have a hard time following these statements - maybe you are mixing up GUI and non-GUI programs here. - Ctrl-C is to send SIGINTR to shell-based programs which will then (usually) gracefully exit. I still have to see a GUI-based program that uses Ctrl-C to stop something. Usually you would use e.g. the Escape or space key for that. - On the other hand, especially the Ctrl-C (Copy), Ctrl-V (Paste) and Ctrl-X (Cut) key combinations have been pretty much "standard" for a few years now (even in the Linux world). Examples are e.g. The Gimp, Abiword, most Gtk/Gnome based programs, most probably also most KDE-based programs (I don't use KDE, but I am quite sure they use this, too). Yes, this probably comes from the Windows (or Mac?) world, but it's so much in common use nowadays that I do consider this as a standard. I think even some of the ancient text editors I used on my Amiga back around ~ 88 used these. Oh, and of course the Mac also had those for a long time, though not with the "Ctrl" key introducer, but the "Apple command" key instead. Using Ctrl-A for "select all" is also handled this way by Gimp, Abiword and probably quite a few more applications. Ctrl-Shift-A for "Unselect All" is also used like that in Gimp (and again, there might be more apps that use it), and I think it's logical - though, it's by far not as common as the Cut/Copy/Paste combo. As for "correct the last incorrectly typed letter", Ctrl-Z is used as Undo in a LOT of apps. And, of course the "Delete" or "Backspace" key does not "undo" anything you typed - that's a different operation with different semantics. Also, I would not be able to guess upfront what function pressing "Delete" or "Backspace" in a wav editor would have. It might be given some function, but I don't know of any function that is common known standard for these keys in this application class. Greetings, Frank PS: I believe there is a Gtk User Interface Style Guide on the Internet that should list the recommended functions and their keyboard shortcuts. I should be able to locate it for you if you are interested. |
From: Heimo C. <ha...@re...> - 2003-01-21 01:56:10
|
Frank - perhaps I didn't express this well: what I meant with that "consitency" argument was the "motoric" concistency - independent of console, GUI, or this or that application -, not that of different program groups' (inter-)consistency. [ESC] has been the traditional "graceful" escape or exist with "all sorts of" things; and so has been [CTRL]-[C] (or [CTRL]-[BREAK] the scancode of which is often translates to the same) for a forced exit or break. And sure I find it meaningful to have, for instance in a Gtk-using environment, a common set of keybindings. This may be helpful exactly for someone not too familar with an application. However, this does not say much about if the specific choices for keybindings in a specific application would be the ergonomically most appropriate ones. And then, it could be allowed to reflect if a highly specialised application like Sweep could perhaps gain from an ergonomically adapted change for at least some of those "general" settings. Shoes get comfortable only after having walked them in (and changed their form thusly). For instance, I do not want my text editor on [ENTER] to "cut _and_ go to newline", I want it "go to newline (only)". Its default setting is the former - and quite a lot of people seem to like it this way - but I'm allowed to change it to my preference. That's all what I wanted to say (and to suggest; but not to prescribe). // Heimo Claasen // <hammer at revobild dot net> // Brussels 2003-01-20 The WebPlace of ReRead - and much to read ==> http://www.revobild.net |
From: Heimo C. <ha...@re...> - 2003-02-08 20:44:00
|
FWIW, newest KDE is announced (on Mandrake distros) with allowing "creating and using shortcut keys". ("Creating" would mean changing too, if I guess right, <g>.) // Heimo Claasen // <hammer at revobild dot net> // Brussels 2003-02-08 |
From: Andre P. <oz...@al...> - 2003-01-12 04:08:07
|
On Sun, Jan 12, 2003 at 03:33:29AM +0000, Heimo Claasen wrote: > As Frank Neumann wrote: > > Also, though GTK programs let you dynamically change the shortcut key > > assignments by pointing at a menu item and pressing the key you want to > > correspond to it,... > > Ahh - is there ? Couldn't there be a script to make this ? (Kind of > "load your own hotkey list" which could be invoked automatically before > running Sweep ?) I'd recommend against changing the standard shortcut keys, since that can make every single copy of Sweep different. You don't want to move from one computer to the next and find that pressing 'Q' suddenly quits the program instead of what you expect ... If the current shortcut key isn't adequate (or there isn't a shortcut key for the function you want), discuss it here -- then it can be added to all future versions of Sweep consistently if it's useful. > I'd sign up to number of the other points raised too - the ergonomy > ("handling" I would call it) has not yet been too much in focus (though On the contrary, I think Sweep's "handling" (usability) is what seperates it from every single other UNIX sound editor. Sound is a very hard thing to manipulate, and a good sound editing program is all about giving you easy, fast ways to do the things you want to do. Conrad definitely understands this, and I think he strongly regards any features related to making Sweep easier to use. > I made my own (long) list of such suggestions and sent it to Conrad > earlier. But maybe it's meaningful to post such to this list too: > it could be helpful for Conrad as well as all interested to discuss > what preferences there are. Post it here: open-source is all about community feedback and more than one pair of eyeballs to look at suggestions :). Maybe you'll get only a response from Conrad, but maybe also one other person can jump in and suggest something really insightful which makes the original suggestion 200% better. -- #ozone/algorithm <oz...@al...> - trust.in.love.to.save |