Re: shorcut automatization
On Wed, Feb 12, 2003 at 12:54:46PM +1000, Allan Rae wrote: On Tue, 11 Feb 2003, John Levon wrote: On Tue, Feb 11, 2003 at 11:59:28AM +0100, Lars Gullik Bj?nnes wrote: | I have never been able to use that interface, and it buys us precisely | nothing, and costs a lot. Poor John, failed at Emacs but rules with vi. When are you vi guys going to get your acts together and put a vi-style command interface or are you quietly admitting defeat here also. :P Hey, that was the first thing that John and I agreed on! Seriously, what could be better than a hybrid that used vi editing but with lyx as a display engine, and lyx-like math/environment commands to avoid worring about the longer latex writing? As it is, I try to use real editing commands fairly often in lyx :) But the vim license and lyx license status are utterly incompatible, so it would have to be done as a script and a patch leaving people to download and compile it all themselves :( hawk -- Richard E. Hawkins, Asst. Prof. of Economics/\ ASCII ribbon campaign [EMAIL PROTECTED] Smeal 178 (814) 375-4700 \ / against HTML mail These opinions will not be those of Xand postings. Penn State until it pays my retainer. / \
Re: shorcut automatization
On Wed, Feb 12, 2003 at 12:31:18PM -0500, Dr. Richard E. Hawkins wrote: Poor John, failed at Emacs but rules with vi. When are you vi guys going to get your acts together and put a vi-style command interface or are you quietly admitting defeat here also. :P Hey, that was the first thing that John and I agreed on! That's a bad sign. SCNR, Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: shorcut automatization
On Wed, Feb 12, 2003 at 12:54:46PM +1000, Allan Rae wrote: > On Tue, 11 Feb 2003, John Levon wrote: > > On Tue, Feb 11, 2003 at 11:59:28AM +0100, Lars Gullik Bj?nnes wrote: > > > | I have never been able to use that interface, and it buys us precisely > > > | nothing, and costs a lot. > Poor John, failed at Emacs but rules with vi. When are you vi guys > going to get your acts together and put a vi-style command interface > or are you quietly admitting defeat here also. :P Hey, that was the first thing that John and I agreed on! Seriously, what could be better than a hybrid that used vi editing but with lyx as a display engine, and lyx-like math/environment commands to avoid worring about the longer latex writing? As it is, I try to use real editing commands fairly often in lyx :) But the vim license and lyx license status are utterly incompatible, so it would have to be done as a script and a patch leaving people to download and compile it all themselves :( hawk -- Richard E. Hawkins, Asst. Prof. of Economics/"\ ASCII ribbon campaign [EMAIL PROTECTED] Smeal 178 (814) 375-4700 \ / against HTML mail These opinions will not be those of Xand postings. Penn State until it pays my retainer. / \
Re: shorcut automatization
On Wed, Feb 12, 2003 at 12:31:18PM -0500, Dr. Richard E. Hawkins wrote: > > Poor John, failed at Emacs but rules with vi. When are you vi guys > > going to get your acts together and put a vi-style command interface > > or are you quietly admitting defeat here also. :P > > Hey, that was the first thing that John and I agreed on! That's a bad sign. SCNR, Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: shorcut automatization
John Levon wrote: Doesn't sound like a good idea to me. It would make use of second word impossible, careful ordering so that more common options are preferred, etc. But rethinking again: I don't think this as a problem, but as a feature. (Also, it should be trivial to set the policy to prefer first letter, then first letter on the second word if it exist, then second letter and so on) Making shorcuts consistent would accelerate user interaction. In fact, I find a PITA every cleverness in choosing shorcuts. In the Layout-Document-Layout dialog tab (Qt frontend) we have for instance Options|t without any reason for not using O. Or Page style|s when P would be much more intuitive. And Float placement|p, same thing. At least we should decide a shorcut policy for manually placing them. And once the policy is decided, I would find strange if it cannot be automatized. If you want my opinion, I think shorcuts are useful when they are on the first letter. With some effort I can use if they are on the first letter of the second word, but if I have to find the underlined letter in the middle then I better tab out or click with the mouse. And it's indifferent (at least for me) if they follow some meaning of the action: you have to look at the dialog to use them. It's a problem for translation, but I do not think this is a solution. I'm not sure neither if this is the solution. But I don't think it's only a problem for translations. Alfredo (Back pretending to think)
Re: shorcut automatization
Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | If we did this, then lyx could quite conceivably become a daemon process | communicating via the lyxserver with an external process which --- quite | conceivably --- could be our frontend dialogs with a main() routine. Then we would use bsd sockets (tcp) or local sockets (unix)... and then a lyx daemon could run and serve a xfroms gui and a qt gui at the same time... On deamon, one machine :-) _but_ I am not completely sure that I like the idea. Sure. However, the necessary first step of passing dialog information between the frontend and the core only as an LFUN, string pair is a good idea I think. Especially if we can use the same inset's read, write functions to do this as are used when loading up a document. Clearly, passing an inset*, as now, is nasty, nasty, nasty. Moreover, it may not be too much work ;-) The necessary second step of an improved lyxserver is also a fun project. When that is in place, there is nothing stopping an external app calling itself a LyX frontend, even if it's not the way that LyX itself chooses to do things. -- Angus
Re: shorcut automatization
Lars Gullik Bjønnes wrote: Have I said that I really do not like the dialogs at all? I'd prefere an application completely without dialogs... Dialogs are indeed overused in most applications. I would love to see lyx do search replace emacs style. I.e. use the minibuffer instead of some popup the user have to move out of the way _and_ eventually close. The same applies to any other dialog small enough for the minibuffer, or that can be divided up sanely. Parameters for floats and other insets could be part of the expanded inset instead of a popup dialog. That could get big fast, so perhaps tabs or two levels of expansion is in order. The preamble could be a collapsable inset (very much like a ERT inset) but anchored at the beginning. But please don't see this as a new paradigm or absolute rule - lots of bad software appear when people try applying good ideas _everywhere_, even where they don't fit. I see no problem having preferences in a popup dialog - it is not something done every day and it certainly don't belong anywhere inside the document. Helge Hafting
Re: shorcut automatization
On Tue, Feb 11, 2003 at 03:14:30PM +1000, Allan Rae wrote: Menues, toolbar(s) and a minibuffer. The minute the minibuffer becomes necessary, the game is over, collect your shoes, and go home ... Rendering some configuration pages in a buffer -- like (x)emacs' customization settings. I have never been able to use that interface, and it buys us precisely nothing, and costs a lot. john
Re: shorcut automatization
On Tue, Feb 11, 2003 at 04:17:23PM +0900, Rob Lahaye wrote: Context-sensitive right-mouse-click menu popups. Yes, we do want this. Would something like this be feasible? In Xforms, Qt and/or Gnome? Yes regards john
Re: shorcut automatization
On Tue, Feb 11, 2003 at 11:50:55AM +0100, Helge Hafting wrote: I would love to see lyx do search replace emacs style. I.e. use the minibuffer instead of some popup the user have to move out of the way _and_ eventually close. This would be nice indeed, but it must be a complementary interface not the only way. Parameters for floats and other insets could be part of the expanded inset instead of a popup dialog. That could get big fast, so perhaps tabs or two levels of expansion is in order. sounds like a bad idea to me. The preamble could be a collapsable inset (very much like a ERT inset) but anchored at the beginning. Not sure about this. regards john
Re: shorcut automatization
John Levon [EMAIL PROTECTED] writes: | On Tue, Feb 11, 2003 at 03:14:30PM +1000, Allan Rae wrote: | | Menues, toolbar(s) and a minibuffer. | | The minute the minibuffer becomes necessary, the game is over, collect | your shoes, and go home ... Because you rather want a popup? | Rendering some configuration pages in a buffer -- like (x)emacs' | customization settings. | | I have never been able to use that interface, and it buys us precisely | nothing, and costs a lot. Gets rid of the popup/dialog clutter. -- Lgb
Re: shorcut automatization
On Tue, Feb 11, 2003 at 09:08:25AM +0100, Alfredo Braunstein wrote: Making shorcuts consistent would accelerate user interaction. In fact, I find a PITA every cleverness in choosing shorcuts. In the Layout-Document-Layout dialog tab (Qt frontend) we have for instance Options|t without any reason for not using O. Or Page style|s when P would be much more intuitive. And Float placement|p, same thing. This doesn't sound like cleverness to me, but silly choices. If you want my opinion, I think shorcuts are useful when they are on the first letter. That's fine for the default first choice, the tricky part is when the first letter is not available. And it's indifferent (at least for me) if they follow some meaning of the action: you have to look at the dialog to use them. If you do it often, it's likely slightly easier to remember if it's a meaningful mnemonic. regards john
Re: shorcut automatization
On Tue, Feb 11, 2003 at 11:59:28AM +0100, Lars Gullik Bj?nnes wrote: | The minute the minibuffer becomes necessary, the game is over, collect | your shoes, and go home ... Because you rather want a popup? I want default usable interfaces that do not require book-learnin' Suitable visual display and feedback is an important rationale for the existence of dialogs. I'd love to see how you do match whole words in the minibuffer. | I have never been able to use that interface, and it buys us precisely | nothing, and costs a lot. Gets rid of the popup/dialog clutter. By replacing it with some clutter on the buffer instead, which : 1) is non-standard 2) cannot use the frontend's architecture 3) requires more code I don't know about you, but I do not fancy coding all the stuff like tab navigation etc. by hand. john
Re: shorcut automatization
John Levon [EMAIL PROTECTED] writes: | On Tue, Feb 11, 2003 at 11:59:28AM +0100, Lars Gullik Bj?nnes wrote: | | | The minute the minibuffer becomes necessary, the game is over, collect | | your shoes, and go home ... | | Because you rather want a popup? | | I want default usable interfaces that do not require book-learnin' | | Suitable visual display and feedback is an important rationale for the | existence of dialogs. | | I'd love to see how you do match whole words in the minibuffer. think incremental search. | 1) is non-standard standard!?! -- Lgb
Re: shorcut automatization
John Levon wrote: On Tue, Feb 11, 2003 at 09:08:25AM +0100, Alfredo Braunstein wrote: Making shorcuts consistent would accelerate user interaction. In fact, I find a PITA every cleverness in choosing shorcuts. In the Layout-Document-Layout dialog tab (Qt frontend) we have for instance Options|t without any reason for not using O. Or Page style|s when P would be much more intuitive. And Float placement|p, same thing. This doesn't sound like cleverness to me, but silly choices. That's my point. Non-standard choices are bad, so let's automatize the thing. Or at least make it in a standard way. That's fine for the default first choice, the tricky part is when the first letter is not available. What I'm saying is that they are not useful at all (for me) if they are not on the first say, two, letters of any word. If you do it often, it's likely slightly easier to remember if it's a meaningful mnemonic. Maybe you are right. An example not in the first letter? (without using run-together words please) Regards, Alfredo
Re: shorcut automatization
On Tue, Feb 11, 2003 at 12:15:31PM +0100, Lars Gullik Bj?nnes wrote: | I'd love to see how you do match whole words in the minibuffer. think incremental search. And how do you do case-insensitive ? john
Re: shorcut automatization
John Levon wrote: On Tue, Feb 11, 2003 at 12:15:31PM +0100, Lars Gullik Bj?nnes wrote: | I'd love to see how you do match whole words in the minibuffer. think incremental search. And how do you do case-insensitive ? It strikes me that you're playing the rôle of Luddite here ;-) If people want it and are willing to code it, why not let 'em? -- Angus
Re: shorcut automatization
On Tue, Feb 11, 2003 at 11:44:39AM +, Angus Leeming wrote: It strikes me that you're playing the rôle of Luddite here ;-) If people want it and are willing to code it, why not let 'em? In context, we are talking about replacing the find dialog. I have no problem with such additional functionality, in fact I'd welcome it, and likely use it myself. But replacing: no. regards john
Re: shorcut automatization
On Tue, 11 Feb 2003, Alfredo Braunstein wrote: John Levon wrote: Maybe you are right. An example not in the first letter? (without using run-together words please) The insert menu is full of examples of shortcuts that does not correspond to the first letters: Insert-Float a Insert-List TOC O Insert-Include file d Insert-Insert file e /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: shorcut automatization
John Levon [EMAIL PROTECTED] writes: | On Tue, Feb 11, 2003 at 12:15:31PM +0100, Lars Gullik Bj?nnes wrote: | | | I'd love to see how you do match whole words in the minibuffer. | | think incremental search. | | And how do you do case-insensitive ? lowercase only - insensitive mixed case/upper case - sensitive just like emacs. -- Lgb
Re: shorcut automatization
On Tue, Feb 11, 2003 at 01:33:49PM +0100, Lars Gullik Bj?nnes wrote: | And how do you do case-insensitive ? lowercase only - insensitive mixed case/upper case - sensitive which has an obvious failure mode. john
Re: shorcut automatization
On Tue, Feb 11, 2003 at 11:03:23AM +, John Levon wrote: | The minute the minibuffer becomes necessary, the game is over, collect | your shoes, and go home ... Because you rather want a popup? I want default usable interfaces that do not require book-learnin' I've never seen a search-and-replace dialog that would qualify as more usable than a minibuffer based approach with a decent history. I did require some learning, though... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: shorcut automatization
On Tue, Feb 11, 2003 at 01:41:34PM +0100, Andre Poenitz wrote: I want default usable interfaces that do not require book-learnin' I've never seen a search-and-replace dialog that would qualify as more usable than a minibuffer based approach with a decent history. I did require some learning, though... The point is that the occassional or new user gets to use the dialog, which is (hopefully) obvious to use. As a user gets more experienced, or starts using search more heavily, the more efficient interface is there for them. Efficiency is not exactly equal to usability. Rather, efficiency is (an important part) of the whole package regards, john
Re: shorcut automatization
John Levon [EMAIL PROTECTED] writes: | On Tue, Feb 11, 2003 at 01:33:49PM +0100, Lars Gullik Bj?nnes wrote: | | | And how do you do case-insensitive ? | | lowercase only - insensitive | mixed case/upper case - sensitive | | which has an obvious failure mode. which does not matter. You have tried the functionality, yes? Does it work or not? -- Lgb
Re: shorcut automatization
On Tue, Feb 11, 2003 at 11:39:46AM +, John Levon wrote: On Tue, Feb 11, 2003 at 12:15:31PM +0100, Lars Gullik Bj?nnes wrote: | I'd love to see how you do match whole words in the minibuffer. think incremental search. And how do you do case-insensitive ? By prepending \c. I doubt you click faster than I type that. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: shorcut automatization
John == John Levon [EMAIL PROTECTED] writes: John On Tue, Feb 11, 2003 at 01:41:34PM +0100, Andre Poenitz wrote: I want default usable interfaces that do not require book-learnin' I've never seen a search-and-replace dialog that would qualify as more usable than a minibuffer based approach with a decent history. I did require some learning, though... John The point is that the occassional or new user gets to use the John dialog, which is (hopefully) obvious to use. As a user gets more John experienced, or starts using search more heavily, the more John efficient interface is there for them. John Efficiency is not exactly equal to usability. Rather, efficiency John is (an important part) of the whole package Agreed. Getting rid of dialogs is a stupid move, IMO. JMarc
Re: shorcut automatization
On Tue, Feb 11, 2003 at 01:46:49PM +0100, Lars Gullik Bj?nnes wrote: | which has an obvious failure mode. which does not matter. You have tried the functionality, yes? Yes. Does it work or not? It has an obvious failure mode, as above. john
Re: shorcut automatization
On Tue, Feb 11, 2003 at 02:02:48PM +0100, Andre Poenitz wrote: And how do you do case-insensitive ? By prepending \c. I doubt you click faster than I type that. I'm not sure how many times I can say that efficiency is not the be all and end all of a usable interface john
Re: shorcut automatization
John Levon [EMAIL PROTECTED] writes: | On Tue, Feb 11, 2003 at 01:46:49PM +0100, Lars Gullik Bj?nnes wrote: | | | which has an obvious failure mode. | | which does not matter. | | You have tried the functionality, yes? | | Yes. | | Does it work or not? | | It has an obvious failure mode, as above. which does not matter! -- Lgb
Re: shorcut automatization
On Tue, Feb 11, 2003 at 02:40:40PM +0100, Lars Gullik Bj?nnes wrote: | It has an obvious failure mode, as above. which does not matter! says who ! john
Re: shorcut automatization
Christian Ridderström wrote: On Tue, 11 Feb 2003, Alfredo Braunstein wrote: John Levon wrote: Maybe you are right. An example not in the first letter? (without using run-together words please) The insert menu is full of examples of shortcuts that does not correspond to the first letters: Insert-Float a Insert-List TOC O Insert-Include file d Insert-Insert file e /Christian I know. The question was if there are examples of 'natural' letter which aren't the first one. Are those of your example particularly better than choosing the first 'unused' one? Alfredo
Re: shorcut automatization
On Tue, Feb 11, 2003 at 12:43:58PM +, John Levon wrote: On Tue, Feb 11, 2003 at 01:41:34PM +0100, Andre Poenitz wrote: I want default usable interfaces that do not require book-learnin' I've never seen a search-and-replace dialog that would qualify as more usable than a minibuffer based approach with a decent history. I did require some learning, though... The point is that the occassional or new user gets to use the dialog, which is (hopefully) obvious to use. As a user gets more experienced, or starts using search more heavily, the more efficient interface is there for them. Yes! (Oh, dear; I'm agreeing with John again :) This is the Mac/Windows difference. Any idiot can sit down and use either (ok, today's windows; not older ones). Mac tends to have other and more efficient ways of doing things as you get experience--oddly, these stem from early MS products for mac, the company which has been systematically forcing everyone to stay in beginner mode. I'm not going to be able to sit someone down in front of LyX and convince them to try it if I have to do a minibuffer instead of a dialog search (unless it's someone accustomed to either emacs or a real editor to start with :). You keep people who ar able to find more efficient ways of doing things (which go into finger memory). Lyx has three major advantages that I see over latex at the moment: 1) You can see your complicated equations, and coherently edit them. 2) Less keystrokes than latex for the same effect (including auto-termination). 3) You can sit down at it with no training. The first is big for new and experienced users; the second keeps experienced users, and the third catches new users. hawk, who would still like the vi interface to lyx :) Efficiency is not exactly equal to usability. Rather, efficiency is (an important part) of the whole package regards, john -- Richard E. Hawkins, Asst. Prof. of Economics/\ ASCII ribbon campaign [EMAIL PROTECTED] Smeal 178 (814) 375-4700 \ / against HTML mail These opinions will not be those of Xand postings. Penn State until it pays my retainer. / \
Re: shorcut automatization
On Tue, Feb 11, 2003 at 09:08:25AM +0100, Alfredo Braunstein wrote: If you want my opinion, I think shorcuts are useful when they are on the first letter. With some effort I can use if they are on the first letter of the second word, but if I have to find the underlined letter in the middle then I better tab out or click with the mouse. M-c c i I have no idea why anyone would associate that with insert columnt, but after doing a bunch from the menu, I finally noticed it, and it sure helps. Intuitive ones are nice (and again I'll mention early ms software for mac; I was using commands I'd never heard of!), but available sure beats the rodent if you have to do it a lot . . . hawk
Re: shorcut automatization
On Tue, Feb 11, 2003 at 03:00:49PM +0100, Alfredo Braunstein wrote: Christian Ridderstr?m wrote: Insert-List TOC O etc I know. The question was if there are examples of 'natural' letter which aren't the first one. Are those of your example particularly better than choosing the first 'unused' one? absolutely. His stay put when someone adds a feature higher up the menu, or earlier in the alphabet. There afe few things worse than the commands in your application changing with each release (this is where MS started losing it in the mac market). hawk -- Richard E. Hawkins, Asst. Prof. of Economics/\ ASCII ribbon campaign [EMAIL PROTECTED] Smeal 178 (814) 375-4700 \ / against HTML mail These opinions will not be those of Xand postings. Penn State until it pays my retainer. / \
Re: shorcut automatization
Dr. Richard E. Hawkins wrote: On Tue, Feb 11, 2003 at 09:08:25AM +0100, Alfredo Braunstein wrote: M-c c i I have no idea why anyone would associate that with insert columnt, but after doing a bunch from the menu, I finally noticed it, and it sure helps. Intuitive ones are nice (and again I'll mention early ms software for mac; I was using commands I'd never heard of!), but available sure beats the rodent if you have to do it a lot . . . hawk But you have 'real' shorcuts for that, i.e. keyboard bindings of lfuns. I agree that bindings could be shown on the menu, though. Alfredo
Re: shorcut automatization
John Levon [EMAIL PROTECTED] writes: | On Tue, Feb 11, 2003 at 02:40:40PM +0100, Lars Gullik Bj?nnes wrote: | | | It has an obvious failure mode, as above. | | which does not matter! | | says who ! says me! -- Lgb
Re: shorcut automatization
John Levon wrote: On Tue, Feb 11, 2003 at 11:59:28AM +0100, Lars Gullik Bj?nnes wrote: | The minute the minibuffer becomes necessary, the game is over, collect | your shoes, and go home ... Because you rather want a popup? I want default usable interfaces that do not require book-learnin' Suitable visual display and feedback is an important rationale for the existence of dialogs. I'd love to see how you do match whole words in the minibuffer. Easy enough. Make it a two-line minibuffer. Don't even need to enlarge it - use the minibuffer area _and_ the status line below it and stuff the GUI elements from the search replace dialog there when doing a search. No learning required. They press a key / use the menu as usual, and get the search replace stuff. Only they get it at the bottom of the screen instead of in some stupid dialog that obscures half of the text they're going to search in. Everybody know how to move the dialog - and hates having to do it too. Helge Hafting
Re: shorcut automatization
John Levon wrote: On Tue, Feb 11, 2003 at 11:50:55AM +0100, Helge Hafting wrote: I would love to see lyx do search replace emacs style. I.e. use the minibuffer instead of some popup the user have to move out of the way _and_ eventually close. This would be nice indeed, but it must be a complementary interface not the only way. Why - if it offers the same functionality? The search dialog is small enough that its components can be squashed into the buffer area. Then there wouldn't be a need for a popup dialog because the dialog pops up inside the buffer area. Parameters for floats and other insets could be part of the expanded inset instead of a popup dialog. That could get big fast, so perhaps tabs or two levels of expansion is in order. sounds like a bad idea to me. I don't know if it'll be hard to code - I'm only thinking of the looks here. One can always dream. :-) Helge Hafting
Re: shorcut automatization
On Tue, Feb 11, 2003 at 03:53:22PM +0100, Lars Gullik Bj?nnes wrote: | says who ! says me! My 300 page SCSI manual disagrees with you when I'm looking for a mis-spelling as scsi instead of SCSI john
Re: shorcut automatization
John Levon [EMAIL PROTECTED] writes: | On Tue, Feb 11, 2003 at 03:53:22PM +0100, Lars Gullik Bj?nnes wrote: | | | says who ! | | says me! | | My 300 page SCSI manual disagrees with you when I'm looking for a | mis-spelling as scsi instead of SCSI Your SCSI manual does not have an opinion. -- Lgb
Re: shorcut automatization
On Tue, Feb 11, 2003 at 04:30:52PM +0100, Lars Gullik Bj?nnes wrote: | My 300 page SCSI manual disagrees with you when I'm looking for a | mis-spelling as scsi instead of SCSI Your SCSI manual does not have an opinion. You're just discriminating against it ! john
Re: shorcut automatization
John Levon [EMAIL PROTECTED] writes: | On Tue, Feb 11, 2003 at 03:53:22PM +0100, Lars Gullik Bj?nnes wrote: | | | says who ! | | says me! | | My 300 page SCSI manual disagrees with you when I'm looking for a | mis-spelling as scsi instead of SCSI C-s M-c incremental searchstring Alternatively set the case-fold-search variable to 'nil' and you will get a case sensitive search all the time. -- Lgb
Re: shorcut automatization
On Tue, 11 Feb 2003, Dr. Richard E. Hawkins wrote: On Tue, Feb 11, 2003 at 03:00:49PM +0100, Alfredo Braunstein wrote: Christian Ridderstr?m wrote: Insert-List TOC O etc I know. The question was if there are examples of 'natural' letter which aren't the first one. Are those of your example particularly better than choosing the first 'unused' one? To be honest, I misunderstood the question and thought the requested example was only for shortcuts that weren't associated with the first letter, i.e. nothing about natural. However, I'd say that Minipage p is an example of a natural shortcut, and perhaps also 'x' for export. But on the other hand, I really _hate_ having to remember 'a' for float... Actually, I liked your idea of systematically naming the shortcuts until I read hawk's point: His stay put when someone adds a feature higher up the menu, or earlier in the alphabet. There afe few things worse than the commands in your application changing with each release (this is where MS started losing it in the mac market). Can the user change this through the .bind-files (and also see the change in the menues)? (I looked in menus.bind and cua.bind but didn't find anything there) /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: shorcut automatization
On Tue, 11 Feb 2003, Alfredo Braunstein wrote: But you have 'real' shorcuts for that, i.e. keyboard bindings of lfuns. I agree that bindings could be shown on the menu, though. What's an lfun? I've seen this lots of times now ?lyx-function /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: shorcut automatization
Christian Ridderström wrote: On Tue, 11 Feb 2003, Alfredo Braunstein wrote: But you have 'real' shorcuts for that, i.e. keyboard bindings of lfuns. I agree that bindings could be shown on the menu, though. What's an lfun? I've seen this lots of times now ?lyx-function /Christian See src/commandtags.h. The lfun enums tell the dispatch methods what to do with a particular string. They are mapped to identifying strings in src/LyXAction.C so that you can type 'insert-citation foo' in the minibuffer and something happens. -- Angus
Re: shorcut automatization
On Tue, 11 Feb 2003, Angus Leeming wrote: Christian Ridderström wrote: On Tue, 11 Feb 2003, Alfredo Braunstein wrote: But you have 'real' shorcuts for that, i.e. keyboard bindings of lfuns. I agree that bindings could be shown on the menu, though. What's an lfun? I've seen this lots of times now ?lyx-function /Christian See src/commandtags.h. The lfun enums tell the dispatch methods what to do with a particular string. They are mapped to identifying strings in src/LyXAction.C so that you can type 'insert-citation foo' in the minibuffer and something happens. Thanks... since this was a bit above and beyound what a normal user would be intersted in, I just put the answer here: http://ev-en.org/wiki/moin.cgi/LyxDevelFAQ /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: shorcut automatization
On Tue, 11 Feb 2003, Alfredo Braunstein wrote: John Levon wrote: On Tue, Feb 11, 2003 at 09:08:25AM +0100, Alfredo Braunstein wrote: Making shorcuts consistent would accelerate user interaction. In fact, I find a PITA every cleverness in choosing shorcuts. In the Layout-Document-Layout dialog tab (Qt frontend) we have for instance Options|t without any reason for not using O. Or Page style|s when P would be much more intuitive. And Float placement|p, same thing. This doesn't sound like cleverness to me, but silly choices. That's my point. Non-standard choices are bad, so let's automatize the thing. Or at least make it in a standard way. I'm surprised that noone has mentioned the _existing_ shortcut creation tool which is included in the source tree at: development/tools/scgen.pl Such tools are good for initial creation of a dialog but as others have pointed out they are likely to change allocations once a dialog has been reordered (for tab ordering purposes) or extended. Allan. (ARRae)
Re: shorcut automatization
On Tue, 11 Feb 2003, John Levon wrote: On Tue, Feb 11, 2003 at 11:59:28AM +0100, Lars Gullik Bj?nnes wrote: [...] | I have never been able to use that interface, and it buys us precisely | nothing, and costs a lot. Poor John, failed at Emacs but rules with vi. When are you vi guys going to get your acts together and put a vi-style command interface or are you quietly admitting defeat here also. :P Gets rid of the popup/dialog clutter. By replacing it with some clutter on the buffer instead, which : 1) is non-standard 2) cannot use the frontend's architecture 3) requires more code I don't know about you, but I do not fancy coding all the stuff like tab navigation etc. by hand. Can't Qt create a dialog as part of a canvas? That is, can't you just put everything on a scrolling-canvas instead of a separate popup dialog box? (which all the Qt/KDE apps I remember using seem to always want to make modal) Then the only difference is the stuff that is covered up or blocked by silly dialogs -- in fact it seems that since Qt can float toolbars the same could effectively be done with dialogs -- the user can choose to pull them out of the workarea and decorate the rest of their screen with them if they want to (or vice versa). Allan. (ARRae)
Re: shorcut automatization
John Levon wrote: > Doesn't sound like a good idea to me. It would make use of second word > impossible, careful ordering so that more common options are preferred, > etc. But rethinking again: I don't think this as a problem, but as a feature. (Also, it should be trivial to set the policy to prefer first letter, then first letter on the second word if it exist, then second letter and so on) Making shorcuts consistent would accelerate user interaction. In fact, I find a PITA every cleverness in choosing shorcuts. In the Layout->Document->Layout dialog tab (Qt frontend) we have for instance "Options|t" without any reason for not using O. Or "Page style|s" when P would be much more intuitive. And "Float placement|p", same thing. At least we should decide a shorcut policy for manually placing them. And once the policy is decided, I would find strange if it cannot be automatized. If you want my opinion, I think shorcuts are useful when they are on the first letter. With some effort I can use if they are on the first letter of the second word, but if I have to find the underlined letter in the middle then I better tab out or click with the mouse. And it's indifferent (at least for me) if they follow some meaning of the action: you have to look at the dialog to use them. > It's a problem for translation, but I do not think this is a solution. I'm not sure neither if this is the solution. But I don't think it's only a problem for translations. Alfredo (Back pretending to think)
Re: shorcut automatization
Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > > | If we did this, then lyx could quite conceivably become a daemon process > | communicating via the lyxserver with an external process which --- quite > | conceivably --- could be our frontend dialogs with a main() routine. > > Then we would use bsd sockets (tcp) or local sockets (unix)... and > then a lyx daemon could run and serve a xfroms gui and a qt gui at the > same time... > > On deamon, one machine :-) > > _but_ I am not completely sure that I like the idea. Sure. However, the necessary first step of passing dialog information between the frontend and the core only as an LFUN, string pair is a good idea I think. Especially if we can use the same inset's read, write functions to do this as are used when loading up a document. Clearly, passing an inset*, as now, is nasty, nasty, nasty. Moreover, it may not be too much work ;-) The necessary second step of an improved lyxserver is also a fun project. When that is in place, there is nothing stopping an external app calling itself a LyX frontend, even if it's not the way that LyX itself chooses to do things. -- Angus
Re: shorcut automatization
Lars Gullik Bjønnes wrote: > Have I said that I really do not like the dialogs at all? > I'd prefere an application completely without dialogs... Dialogs are indeed overused in most applications. I would love to see lyx do search & replace emacs style. I.e. use the minibuffer instead of some popup the user have to move out of the way _and_ eventually close. The same applies to any other dialog small enough for the minibuffer, or that can be divided up sanely. Parameters for floats and other insets could be part of the expanded inset instead of a popup dialog. That could get big fast, so perhaps tabs or two levels of expansion is in order. The preamble could be a collapsable inset (very much like a ERT inset) but anchored at the beginning. But please don't see this as a new paradigm or absolute rule - lots of bad software appear when people try applying good ideas _everywhere_, even where they don't fit. I see no problem having "preferences" in a popup dialog - it is not something done every day and it certainly don't belong anywhere inside the document. Helge Hafting
Re: shorcut automatization
On Tue, Feb 11, 2003 at 03:14:30PM +1000, Allan Rae wrote: > Menues, toolbar(s) and a minibuffer. The minute the minibuffer becomes necessary, the game is over, collect your shoes, and go home ... > Rendering some configuration pages in a buffer -- like (x)emacs' > customization settings. I have never been able to use that interface, and it buys us precisely nothing, and costs a lot. john
Re: shorcut automatization
On Tue, Feb 11, 2003 at 04:17:23PM +0900, Rob Lahaye wrote: > Context-sensitive right-mouse-click menu popups. Yes, we do want this. > Would something like this be feasible? > In Xforms, Qt and/or Gnome? Yes regards john
Re: shorcut automatization
On Tue, Feb 11, 2003 at 11:50:55AM +0100, Helge Hafting wrote: > I would love to see lyx do search & replace emacs style. > I.e. use the minibuffer instead of some popup the > user have to move out of the way _and_ eventually close. This would be nice indeed, but it must be a complementary interface not the only way. > Parameters for floats and other insets could be part of > the expanded inset instead of a popup dialog. That could > get big fast, so perhaps tabs or two levels of expansion > is in order. sounds like a bad idea to me. > The preamble could be a collapsable inset (very much like > a ERT inset) but anchored at the beginning. Not sure about this. regards john
Re: shorcut automatization
John Levon <[EMAIL PROTECTED]> writes: | On Tue, Feb 11, 2003 at 03:14:30PM +1000, Allan Rae wrote: | | > Menues, toolbar(s) and a minibuffer. | | The minute the minibuffer becomes necessary, the game is over, collect | your shoes, and go home ... Because you rather want a popup? | > Rendering some configuration pages in a buffer -- like (x)emacs' | > customization settings. | | I have never been able to use that interface, and it buys us precisely | nothing, and costs a lot. Gets rid of the popup/dialog clutter. -- Lgb
Re: shorcut automatization
On Tue, Feb 11, 2003 at 09:08:25AM +0100, Alfredo Braunstein wrote: > Making shorcuts consistent would accelerate user interaction. In fact, I > find a PITA every cleverness in choosing shorcuts. In the > Layout->Document->Layout dialog tab (Qt frontend) we have for instance > "Options|t" without any reason for not using O. Or "Page style|s" when P > would be much more intuitive. And "Float placement|p", same thing. This doesn't sound like cleverness to me, but silly choices. > If you want my opinion, I think shorcuts are useful when they are on the > first letter. That's fine for the default first choice, the tricky part is when the first letter is not available. > And it's indifferent (at least for me) if they follow some meaning of the > action: you have to look at the dialog to use them. If you do it often, it's likely slightly easier to remember if it's a meaningful mnemonic. regards john
Re: shorcut automatization
On Tue, Feb 11, 2003 at 11:59:28AM +0100, Lars Gullik Bj?nnes wrote: > | The minute the minibuffer becomes necessary, the game is over, collect > | your shoes, and go home ... > > Because you rather want a popup? I want default usable interfaces that do not require book-learnin' Suitable visual display and feedback is an important rationale for the existence of dialogs. I'd love to see how you do "match whole words" in the minibuffer. > | I have never been able to use that interface, and it buys us precisely > | nothing, and costs a lot. > > Gets rid of the popup/dialog clutter. By replacing it with some clutter on the buffer instead, which : 1) is non-standard 2) cannot use the frontend's architecture 3) requires more code I don't know about you, but I do not fancy coding all the stuff like tab navigation etc. by hand. john
Re: shorcut automatization
John Levon <[EMAIL PROTECTED]> writes: | On Tue, Feb 11, 2003 at 11:59:28AM +0100, Lars Gullik Bj?nnes wrote: | | > | The minute the minibuffer becomes necessary, the game is over, collect | > | your shoes, and go home ... | > | > Because you rather want a popup? | | I want default usable interfaces that do not require book-learnin' | | Suitable visual display and feedback is an important rationale for the | existence of dialogs. | | I'd love to see how you do "match whole words" in the minibuffer. think incremental search. | 1) is non-standard standard!?! -- Lgb
Re: shorcut automatization
John Levon wrote: > On Tue, Feb 11, 2003 at 09:08:25AM +0100, Alfredo Braunstein wrote: > >> Making shorcuts consistent would accelerate user interaction. In fact, I >> find a PITA every cleverness in choosing shorcuts. In the >> Layout->Document->Layout dialog tab (Qt frontend) we have for instance >> "Options|t" without any reason for not using O. Or "Page style|s" when P >> would be much more intuitive. And "Float placement|p", same thing. > > This doesn't sound like cleverness to me, but silly choices. That's my point. Non-standard choices are bad, so let's automatize the thing. Or at least make it in a standard way. > That's fine for the default first choice, the tricky part is when the > first letter is not available. What I'm saying is that they are not useful at all (for me) if they are not on the first say, two, letters of any word. > If you do it often, it's likely slightly easier to remember if it's a > meaningful mnemonic. Maybe you are right. An example not in the first letter? (without using run-together words please) Regards, Alfredo
Re: shorcut automatization
On Tue, Feb 11, 2003 at 12:15:31PM +0100, Lars Gullik Bj?nnes wrote: > | I'd love to see how you do "match whole words" in the minibuffer. > > think incremental search. And how do you do case-insensitive ? john
Re: shorcut automatization
John Levon wrote: > On Tue, Feb 11, 2003 at 12:15:31PM +0100, Lars Gullik Bj?nnes wrote: > >> | I'd love to see how you do "match whole words" in the minibuffer. >> >> think incremental search. > > And how do you do case-insensitive ? It strikes me that you're playing the rôle of Luddite here ;-) If people want it and are willing to code it, why not let 'em? -- Angus
Re: shorcut automatization
On Tue, Feb 11, 2003 at 11:44:39AM +, Angus Leeming wrote: > It strikes me that you're playing the rôle of Luddite here ;-) If people > want it and are willing to code it, why not let 'em? In context, we are talking about replacing the find dialog. I have no problem with such additional functionality, in fact I'd welcome it, and likely use it myself. But replacing: no. regards john
Re: shorcut automatization
On Tue, 11 Feb 2003, Alfredo Braunstein wrote: > John Levon wrote: > > Maybe you are right. An example not in the first letter? (without using > run-together words please) > The insert menu is full of examples of shortcuts that does not correspond to the first letters: Insert->Float a Insert->List & TOC O Insert->Include file d Insert->Insert file e /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: shorcut automatization
John Levon <[EMAIL PROTECTED]> writes: | On Tue, Feb 11, 2003 at 12:15:31PM +0100, Lars Gullik Bj?nnes wrote: | | > | I'd love to see how you do "match whole words" in the minibuffer. | > | > think incremental search. | | And how do you do case-insensitive ? lowercase only -> insensitive mixed case/upper case -> sensitive just like emacs. -- Lgb
Re: shorcut automatization
On Tue, Feb 11, 2003 at 01:33:49PM +0100, Lars Gullik Bj?nnes wrote: > | And how do you do case-insensitive ? > > lowercase only -> insensitive > mixed case/upper case -> sensitive which has an obvious failure mode. john
Re: shorcut automatization
On Tue, Feb 11, 2003 at 11:03:23AM +, John Levon wrote: > > | The minute the minibuffer becomes necessary, the game is over, collect > > | your shoes, and go home ... > > > > Because you rather want a popup? > > I want default usable interfaces that do not require book-learnin' I've never seen a search-and-replace dialog that would qualify as "more usable" than a minibuffer based approach with a decent history. I did require some learning, though... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: shorcut automatization
On Tue, Feb 11, 2003 at 01:41:34PM +0100, Andre Poenitz wrote: > > I want default usable interfaces that do not require book-learnin' > > I've never seen a search-and-replace dialog that would qualify as "more > usable" than a minibuffer based approach with a decent history. > > I did require some learning, though... The point is that the occassional or new user gets to use the dialog, which is (hopefully) obvious to use. As a user gets more experienced, or starts using search more heavily, the more efficient interface is there for them. Efficiency is not exactly equal to usability. Rather, efficiency is (an important part) of the whole package regards, john
Re: shorcut automatization
John Levon <[EMAIL PROTECTED]> writes: | On Tue, Feb 11, 2003 at 01:33:49PM +0100, Lars Gullik Bj?nnes wrote: | | > | And how do you do case-insensitive ? | > | > lowercase only -> insensitive | > mixed case/upper case -> sensitive | | which has an obvious failure mode. which does not matter. You have tried the functionality, yes? Does it work or not? -- Lgb
Re: shorcut automatization
On Tue, Feb 11, 2003 at 11:39:46AM +, John Levon wrote: > On Tue, Feb 11, 2003 at 12:15:31PM +0100, Lars Gullik Bj?nnes wrote: > > > | I'd love to see how you do "match whole words" in the minibuffer. > > > > think incremental search. > > And how do you do case-insensitive ? By prepending \c. I doubt you click faster than I type that. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: shorcut automatization
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> On Tue, Feb 11, 2003 at 01:41:34PM +0100, Andre Poenitz wrote: >> > I want default usable interfaces that do not require >> book-learnin' >> >> I've never seen a search-and-replace dialog that would qualify as >> "more usable" than a minibuffer based approach with a decent >> history. >> >> I did require some learning, though... John> The point is that the occassional or new user gets to use the John> dialog, which is (hopefully) obvious to use. As a user gets more John> experienced, or starts using search more heavily, the more John> efficient interface is there for them. John> Efficiency is not exactly equal to usability. Rather, efficiency John> is (an important part) of the whole package Agreed. Getting rid of dialogs is a stupid move, IMO. JMarc
Re: shorcut automatization
On Tue, Feb 11, 2003 at 01:46:49PM +0100, Lars Gullik Bj?nnes wrote: > | which has an obvious failure mode. > > which does not matter. > > You have tried the functionality, yes? Yes. > Does it work or not? It has an obvious failure mode, as above. john
Re: shorcut automatization
On Tue, Feb 11, 2003 at 02:02:48PM +0100, Andre Poenitz wrote: > > And how do you do case-insensitive ? > > By prepending \c. > > I doubt you click faster than I type that. I'm not sure how many times I can say that efficiency is not the be all and end all of a usable interface john
Re: shorcut automatization
John Levon <[EMAIL PROTECTED]> writes: | On Tue, Feb 11, 2003 at 01:46:49PM +0100, Lars Gullik Bj?nnes wrote: | | > | which has an obvious failure mode. | > | > which does not matter. | > | > You have tried the functionality, yes? | | Yes. | | > Does it work or not? | | It has an obvious failure mode, as above. which does not matter! -- Lgb
Re: shorcut automatization
On Tue, Feb 11, 2003 at 02:40:40PM +0100, Lars Gullik Bj?nnes wrote: > | It has an obvious failure mode, as above. > > which does not matter! says who ! john
Re: shorcut automatization
Christian Ridderström wrote: > On Tue, 11 Feb 2003, Alfredo Braunstein wrote: > >> John Levon wrote: >> >> Maybe you are right. An example not in the first letter? (without using >> run-together words please) >> > The insert menu is full of examples of shortcuts that does not correspond > to the first letters: > > Insert->Float >a > > Insert->List & TOC > O > > Insert->Include file > d > > Insert->Insert file >e > > /Christian > I know. The question was if there are examples of 'natural' letter which aren't the first one. Are those of your example particularly better than choosing the first 'unused' one? Alfredo
Re: shorcut automatization
On Tue, Feb 11, 2003 at 12:43:58PM +, John Levon wrote: > On Tue, Feb 11, 2003 at 01:41:34PM +0100, Andre Poenitz wrote: > > > I want default usable interfaces that do not require book-learnin' > > I've never seen a search-and-replace dialog that would qualify as "more > > usable" than a minibuffer based approach with a decent history. > > I did require some learning, though... > The point is that the occassional or new user gets to use the dialog, > which is (hopefully) obvious to use. As a user gets more experienced, or > starts using search more heavily, the more efficient interface is there > for them. Yes! (Oh, dear; I'm agreeing with John again :) This is the Mac/Windows difference. Any idiot can sit down and use either (ok, today's windows; not older ones). Mac tends to have other and more efficient ways of doing things as you get experience--oddly, these stem from early MS products for mac, the company which has been systematically forcing everyone to stay in beginner mode. I'm not going to be able to sit someone down in front of LyX and convince them to try it if I have to do a minibuffer instead of a dialog search (unless it's someone accustomed to either emacs or a real editor to start with :). You keep people who ar able to find more efficient ways of doing things (which go into finger memory). Lyx has three major advantages that I see over latex at the moment: 1) You can see your complicated equations, and coherently edit them. 2) Less keystrokes than latex for the same effect (including auto-termination). 3) You can sit down at it with no training. The first is big for new and experienced users; the second keeps experienced users, and the third catches new users. hawk, who would still like the vi interface to lyx :) > Efficiency is not exactly equal to usability. Rather, efficiency is (an > important part) of the whole package > > regards, > john -- Richard E. Hawkins, Asst. Prof. of Economics/"\ ASCII ribbon campaign [EMAIL PROTECTED] Smeal 178 (814) 375-4700 \ / against HTML mail These opinions will not be those of Xand postings. Penn State until it pays my retainer. / \
Re: shorcut automatization
On Tue, Feb 11, 2003 at 09:08:25AM +0100, Alfredo Braunstein wrote: > If you want my opinion, I think shorcuts are useful when they are on the > first letter. With some effort I can use if they are on the first letter of > the second word, but if I have to find the underlined letter in the middle > then I better tab out or click with the mouse. M-c c i I have no idea why anyone would associate that with "insert columnt," but after doing a bunch from the menu, I finally noticed it, and it sure helps. Intuitive ones are nice (and again I'll mention early ms software for mac; I was using commands I'd never heard of!), but "available" sure beats the rodent if you have to do it a lot . . . hawk
Re: shorcut automatization
On Tue, Feb 11, 2003 at 03:00:49PM +0100, Alfredo Braunstein wrote: > Christian Ridderstr?m wrote: > > Insert->List & TOC > > O > I know. The question was if there are examples of 'natural' letter which > aren't the first one. Are those of your example particularly better than > choosing the first 'unused' one? absolutely. His stay put when someone adds a feature higher up the menu, or earlier in the alphabet. There afe few things worse than the commands in your application changing with each release (this is where MS started losing it in the mac market). hawk -- Richard E. Hawkins, Asst. Prof. of Economics/"\ ASCII ribbon campaign [EMAIL PROTECTED] Smeal 178 (814) 375-4700 \ / against HTML mail These opinions will not be those of Xand postings. Penn State until it pays my retainer. / \
Re: shorcut automatization
Dr. Richard E. Hawkins wrote: > On Tue, Feb 11, 2003 at 09:08:25AM +0100, Alfredo Braunstein wrote: > > M-c c i > > I have no idea why anyone would associate that with "insert columnt," > but after doing a bunch from the menu, I finally noticed it, and it sure > helps. Intuitive ones are nice (and again I'll mention early ms > software for mac; I was using commands I'd never heard of!), but > "available" sure beats the rodent if you have to do it a lot . . . > > hawk But you have 'real' shorcuts for that, i.e. keyboard bindings of lfuns. I agree that bindings could be shown on the menu, though. Alfredo
Re: shorcut automatization
John Levon <[EMAIL PROTECTED]> writes: | On Tue, Feb 11, 2003 at 02:40:40PM +0100, Lars Gullik Bj?nnes wrote: | | > | It has an obvious failure mode, as above. | > | > which does not matter! | | says who ! says me! -- Lgb
Re: shorcut automatization
John Levon wrote: > > On Tue, Feb 11, 2003 at 11:59:28AM +0100, Lars Gullik Bj?nnes wrote: > > > | The minute the minibuffer becomes necessary, the game is over, collect > > | your shoes, and go home ... > > > > Because you rather want a popup? > > I want default usable interfaces that do not require book-learnin' > > Suitable visual display and feedback is an important rationale for the > existence of dialogs. > > I'd love to see how you do "match whole words" in the minibuffer. Easy enough. Make it a two-line minibuffer. Don't even need to enlarge it - use the minibuffer area _and_ the status line below it and stuff the GUI elements from the search & replace dialog there when doing a search. No learning required. They press a key / use the menu as usual, and get the search & replace stuff. Only they get it at the bottom of the screen instead of in some stupid dialog that obscures half of the text they're going to search in. Everybody know how to move the dialog - and hates having to do it too. Helge Hafting
Re: shorcut automatization
John Levon wrote: > > On Tue, Feb 11, 2003 at 11:50:55AM +0100, Helge Hafting wrote: > > > I would love to see lyx do search & replace emacs style. > > I.e. use the minibuffer instead of some popup the > > user have to move out of the way _and_ eventually close. > > This would be nice indeed, but it must be a complementary interface not > the only way. Why - if it offers the same functionality? The search dialog is small enough that its components can be squashed into the buffer area. Then there wouldn't be a need for a popup dialog because the dialog pops up inside the buffer area. > > > Parameters for floats and other insets could be part of > > the expanded inset instead of a popup dialog. That could > > get big fast, so perhaps tabs or two levels of expansion > > is in order. > > sounds like a bad idea to me. I don't know if it'll be hard to code - I'm only thinking of the looks here. One can always dream. :-) Helge Hafting
Re: shorcut automatization
On Tue, Feb 11, 2003 at 03:53:22PM +0100, Lars Gullik Bj?nnes wrote: > | says who ! > > says me! My 300 page SCSI manual disagrees with you when I'm looking for a mis-spelling as "scsi" instead of "SCSI" john
Re: shorcut automatization
John Levon <[EMAIL PROTECTED]> writes: | On Tue, Feb 11, 2003 at 03:53:22PM +0100, Lars Gullik Bj?nnes wrote: | | > | says who ! | > | > says me! | | My 300 page SCSI manual disagrees with you when I'm looking for a | mis-spelling as "scsi" instead of "SCSI" Your SCSI manual does not have an opinion. -- Lgb
Re: shorcut automatization
On Tue, Feb 11, 2003 at 04:30:52PM +0100, Lars Gullik Bj?nnes wrote: > | My 300 page SCSI manual disagrees with you when I'm looking for a > | mis-spelling as "scsi" instead of "SCSI" > > Your SCSI manual does not have an opinion. You're just discriminating against it ! john
Re: shorcut automatization
John Levon <[EMAIL PROTECTED]> writes: | On Tue, Feb 11, 2003 at 03:53:22PM +0100, Lars Gullik Bj?nnes wrote: | | > | says who ! | > | > says me! | | My 300 page SCSI manual disagrees with you when I'm looking for a | mis-spelling as "scsi" instead of "SCSI" C-s M-c Alternatively set the case-fold-search variable to 'nil' and you will get a case sensitive search all the time. -- Lgb
Re: shorcut automatization
On Tue, 11 Feb 2003, Dr. Richard E. Hawkins wrote: > On Tue, Feb 11, 2003 at 03:00:49PM +0100, Alfredo Braunstein wrote: > > Christian Ridderstr?m wrote: > > > > Insert->List & TOC > > > O > > > > > I know. The question was if there are examples of 'natural' letter which > > aren't the first one. Are those of your example particularly better than > > choosing the first 'unused' one? To be honest, I misunderstood the question and thought the requested example was only for shortcuts that weren't associated with the first letter, i.e. nothing about "natural". However, I'd say that Minipage p is an example of a natural shortcut, and perhaps also 'x' for export. But on the other hand, I really _hate_ having to remember 'a' for float... Actually, I liked your idea of systematically naming the shortcuts until I read "hawk's" point: > His stay put when someone adds a feature higher up the menu, or earlier > in the alphabet. There afe few things worse than the commands in your > application changing with each release (this is where MS started losing > it in the mac market). Can the user change this through the .bind-files (and also see the change in the menues)? (I looked in menus.bind and cua.bind but didn't find anything there) /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: shorcut automatization
On Tue, 11 Feb 2003, Alfredo Braunstein wrote: > But you have 'real' shorcuts for that, i.e. keyboard bindings of lfuns. > I agree that bindings could be shown on the menu, though. What's an lfun? I've seen this lots of times now ?lyx-function /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: shorcut automatization
Christian Ridderström wrote: > On Tue, 11 Feb 2003, Alfredo Braunstein wrote: > >> But you have 'real' shorcuts for that, i.e. keyboard bindings of lfuns. >> I agree that bindings could be shown on the menu, though. > > What's an lfun? I've seen this lots of times now > ?lyx-function > > /Christian > See src/commandtags.h. The lfun enums tell the dispatch methods what to do with a particular string. They are mapped to identifying strings in src/LyXAction.C so that you can type 'insert-citation foo' in the minibuffer and something happens. -- Angus
Re: shorcut automatization
On Tue, 11 Feb 2003, Angus Leeming wrote: > Christian Ridderström wrote: > > > On Tue, 11 Feb 2003, Alfredo Braunstein wrote: > > > >> But you have 'real' shorcuts for that, i.e. keyboard bindings of lfuns. > >> I agree that bindings could be shown on the menu, though. > > > > What's an lfun? I've seen this lots of times now > > ?lyx-function > > > > /Christian > > > > See src/commandtags.h. The lfun enums tell the dispatch methods what to do > with a particular string. They are mapped to identifying strings in > src/LyXAction.C so that you can type 'insert-citation foo' in the > minibuffer and something happens. Thanks... since this was a bit above and beyound what a normal user would be intersted in, I just put the answer here: http://ev-en.org/wiki/moin.cgi/LyxDevelFAQ /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: shorcut automatization
On Tue, 11 Feb 2003, Alfredo Braunstein wrote: > John Levon wrote: > > > On Tue, Feb 11, 2003 at 09:08:25AM +0100, Alfredo Braunstein wrote: > > > >> Making shorcuts consistent would accelerate user interaction. In fact, I > >> find a PITA every cleverness in choosing shorcuts. In the > >> Layout->Document->Layout dialog tab (Qt frontend) we have for instance > >> "Options|t" without any reason for not using O. Or "Page style|s" when P > >> would be much more intuitive. And "Float placement|p", same thing. > > > > This doesn't sound like cleverness to me, but silly choices. > > That's my point. Non-standard choices are bad, so let's automatize the > thing. Or at least make it in a standard way. I'm surprised that noone has mentioned the _existing_ shortcut creation tool which is included in the source tree at: development/tools/scgen.pl Such tools are good for initial creation of a dialog but as others have pointed out they are likely to change allocations once a dialog has been reordered (for tab ordering purposes) or extended. Allan. (ARRae)
Re: shorcut automatization
On Tue, 11 Feb 2003, John Levon wrote: > On Tue, Feb 11, 2003 at 11:59:28AM +0100, Lars Gullik Bj?nnes wrote: [...] > > | I have never been able to use that interface, and it buys us precisely > > | nothing, and costs a lot. Poor John, failed at Emacs but rules with vi. When are you vi guys going to get your acts together and put a vi-style command interface or are you quietly admitting defeat here also. :P > > Gets rid of the popup/dialog clutter. > > By replacing it with some clutter on the buffer instead, which : > > 1) is non-standard > 2) cannot use the frontend's architecture > 3) requires more code > > I don't know about you, but I do not fancy coding all the stuff like tab > navigation etc. by hand. Can't Qt create a "dialog" as part of a canvas? That is, can't you just put everything on a scrolling-canvas instead of a separate popup dialog box? (which all the Qt/KDE apps I remember using seem to always want to make modal) Then the only difference is the stuff that is covered up or blocked by silly dialogs -- in fact it seems that since Qt can float toolbars the same could effectively be done with dialogs -- the user can choose to pull them out of the workarea and decorate the rest of their screen with them if they want to (or vice versa). Allan. (ARRae)
shorcut automatization
I'm wondering... Maybe it's a stupid idea, but it seems to me that it would not be so difficult to set up a pair of shell scripts to automatically assign unique shorcuts to ui elements (menus, dialogs, etc). Like taking the first unused letter of the word. Not so flexible, but consistent. That way, we would be able to drop shorcuts from translatable strings, with two benefits: 1) Greater merging of strings from different frontends (MUCH easier to translate) 2) The comodity for translator to not to care about repeating shortcuts (it's not so easy to identify all string on a dialog while translating). Does that makes some sense? I'm not sure. We would need some kind of dialog identificator in the string maybe. For instance, how hard is to identify strings from different dialogs? Are them in different files? Bye, Alfredo
Re: shorcut automatization
On Mon, Feb 10, 2003 at 05:40:53PM +0100, Alfredo Braunstein wrote: not be so difficult to set up a pair of shell scripts to automatically assign unique shorcuts to ui elements (menus, dialogs, etc). Like taking Doesn't sound like a good idea to me. It would make use of second word impossible, careful ordering so that more common options are preferred, etc. It's a problem for translation, but I do not think this is a solution. regards john
Re: shorcut automatization
John Levon wrote: Doesn't sound like a good idea to me. It would make use of second word impossible, careful ordering so that more common options are preferred, etc. I see. You are right. Alfredo
Re: shorcut automatization
Alfredo Braunstein [EMAIL PROTECTED] writes: | I'm wondering... Maybe it's a stupid idea, but it seems to me that it would | not be so difficult to set up a pair of shell scripts to automatically | assign unique shorcuts to ui elements (menus, dialogs, etc). Like taking | the first unused letter of the word. Not so flexible, but | consistent. What I'd rather do is to remove most of the shortcuts from dialogs, and have the user use tab to move around. Not everything needs a shortcut. -- Lgb
Re: shorcut automatization
On Mon, Feb 10, 2003 at 07:40:06PM +0100, Lars Gullik Bj?nnes wrote: What I'd rather do is to remove most of the shortcuts from dialogs, and have the user use tab to move around. Bad idea. Some of our dialog are too complex to allow this to work efficiently. Whilst simplifying the dialogs is a useful goal, there is a limit to how much can be done. regards john
Re: shorcut automatization
John Levon [EMAIL PROTECTED] writes: | On Mon, Feb 10, 2003 at 07:40:06PM +0100, Lars Gullik Bj?nnes wrote: | | What I'd rather do is to remove most of the shortcuts from dialogs, | and have the user use tab to move around. | | Bad idea. Some of our dialog are too complex to allow this to work | efficiently. Whilst simplifying the dialogs is a useful goal, there is a | limit to how much can be done. So the solution is to have shortcuts for everything? I don't buy it. -- Lgb
Re: shorcut automatization
On Mon, Feb 10, 2003 at 08:07:29PM +0100, Lars Gullik Bj?nnes wrote: So the solution is to have shortcuts for everything? No, the primary solution is to simplify the dialogs. But we should *not* slow the user down, just because translations are a PITA. btw, Document-Layout in Qt has fucked up tab ordering. I should fix that... john
Re: shorcut automatization
On Mon, Feb 10, 2003 at 07:40:06PM +0100, Lars Gullik Bj?nnes wrote: Alfredo Braunstein [EMAIL PROTECTED] writes: | I'm wondering... Maybe it's a stupid idea, but it seems to me that it would | not be so difficult to set up a pair of shell scripts to automatically | assign unique shorcuts to ui elements (menus, dialogs, etc). Like taking | the first unused letter of the word. Not so flexible, but | consistent. What I'd rather do is to remove most of the shortcuts from dialogs, and have the user use tab to move around. Not everything needs a shortcut. ??? Heresy! You are talking about extra keystrokes, and forcing poeple to watch the dialog. Also, the sequence of keystrokes will change as the dialogs change. ack! Evil! hawk, keystroke whore -- Richard E. Hawkins, Asst. Prof. of Economics/\ ASCII ribbon campaign [EMAIL PROTECTED] Smeal 178 (814) 375-4700 \ / against HTML mail These opinions will not be those of Xand postings. Penn State until it pays my retainer. / \
