Hi,

I just discover this add-on for Eclipse. Every time you use the mouse to do something, it pops up (without interrupting your workflow) and lists the keyboard shortcut you could have used to accomplish that same task you just did with the mouse.

That's an excellent way to learn shortcuts - which ultimately should make you work faster (at least that is normally true for developers).

I wouldn't even know where to start with such a add-on for Lazarus IDE, but I just thought I would mention it - in case somebody wants to take up the challenge.

:-)

Regards,
Graeme

I would be extremely thankful if anyone had the time to at least start on this. One of my main complains with Lazarus/FPC is that it is IDE centric. The IDE is not that bad, but it is kind of hard to integrate into my normal desktop (a tiling window manager).

Cheers,
R0b0t1

Would you mind explaining what you mean with IDE centric ?

You can code in notepad++ or "joe" - something which I still do frequently for small things ?

Michael.

Graeme Geldenhuys wrote

That's an excellent way to learn shortcuts - which ultimately should make you work faster (at least that is normally true for developers).

off-topic

http://dl.acm.org/citation.cfm?id=1978942.1979351&coll=DL&dl=GUIDE&CFID=231586142&CFTOKEN=80641087

http://facweb.cs.depaul.edu/sjost/csc423/examples/anova/efficiency.pdf

These studies show that the most efficient is toolbar; second, keyboard shortcuts; third, second level menu option. With the objection that shortcuts needs a lot of practice to be better than menu.

Time ago I read that interviews to developers after tests show consistently that shortcuts are faster, and clock consistently shows that mouse is faster. The theory that explains this cognitive dissonance is that while using shortcuts your brain works in the program and in remembering shortcuts, but with mouse, you brains stops working to do visual action. The feeling is that with shortcut your brain is always humming, but with mouse you feel you have a lot of interruptions. But the fact is that the time you spend thinking the combinations and typing it is longer than moving the mouse.

Conclusion: Good toolbars and a few well known shortcuts.

Santiago A. wrote

These studies show that the most efficient is toolbar; second, keyboard shortcuts; third, second level menu option. With the objection that shortcuts needs a lot of practice to be better than menu.

Maybe for other programs, but for programming IDE's the rules tend to be slightly different - they are not "normal" programs, and the user of an IDE mostly have there hands on the keyboard. My personal experience is that I absolutely fly when doing editing actions, searching, debugging etc with only the keyboard. Using the mouse will slow me down considerably. I primarily use 3 different editors. I made it my mission to know their shortcuts well, and when possible configure them that the same action as the same shortcut in all three editors - that makes my life a bit easier.

Saying that, designing a UI in Lazarus or Delphi is obviously faster with a mouse. ;-) But I also know of layout managers in Java where visual designers are not needed, and you can knock-up a well designed and scalable UI in no time using only code (eg: MiG Layout).

Back to Lazarus - there are some dialogs that totally annoying me because they were not designed with keyboard users in mind. ie: Wrong default actions, or no default actions, wrong default focus item, incorrect tab order etc. The "Source -> Enclose in IFDEF" dialog comes to mind. The Package windows too. Some of these I have tweaked locally to suite my needs better - that goodness for open source projects. Hell, you can't even configure/customise shortcuts in Delphi IDE!!!

Regards,
Graeme

Santiago A. wrote

These studies show that the most efficient is toolbar; second, keyboard shortcuts; third, second level menu option. With the objection that shortcuts needs a lot of practice to be better than menu.

How well did those studies account for potentially incomparable workflows? I think I agree with what I think to be their conclusion - if you have two similar workflows, graphical navigation may be faster, because it is easier to guide thought with.

But what if I can skip all of the intermediate steps and go straight to the action? Lots of CLI interfaces especially are domain specific languages, and the actions can be encoded into key combinations.

The things in the last paragraph especially are what I do not like. It may be that taking inspiration from either Visual Studio or JetBrains IDEs would be a good idea.

I am willing to help, but not very familiar with the Lazarus codebase.

Cheers,
R0b0t1

Graeme Geldenhuys wrote

Back to Lazarus - there are some dialogs that totally annoying me because they were not designed with keyboard users in mind. ie: Wrong default actions, or no default actions, wrong default focus item, incorrect tab order etc.

I am quite sure patches that fix these issues will be applied.

The "Source -> Enclose in IFDEF" dialog comes to mind.

I don't see a problem here. Can you be specific?

The Package windows too.

This one is better to be used with mouse. Honestly, I don't know how you want to redesign it to be usable with the keyboard.

Ondrej

Santiago A. wrote

Time ago I read that interviews to developers after tests show consistently that shortcuts are faster, and clock consistently shows that mouse is faster.

http://www.asktog.com/TOI/toi06KeyboardVMouse1.html

We’ve done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts:

* Test subjects consistently report that keyboarding is faster than mousing.
* The stopwatch consistently proves mousing is faster than keyboarding.

This contradiction between user-experience and reality apparently forms the basis for many user/developers’ belief that the keyboard is faster.

from
https://www.itworld.com/article/2826902/enterprise-software/7-days-using-only-keyboard-shortcuts--no-mouse--no-trackpad--no-problem-.html

"I watch numerous times a day as colleagues take their hands from the keyboard, reach for the mouse, and either (1) click in the next field of a form and recommence typing, or (2) click 'Submit.' It'd take a lot more than $50 mil worth of research to convince me that (1) tab and (2) enter are not faster. "

And a little more modern:

https://blog.codinghorror.com/revisiting-keyboard-vs-the-mouse-pt-1/

First, understand that this is a very old quote. In 1989 (apple quote), the current desktop operating systems were Windows 2.0, DOS 4.0, and Mac System 6. The "people new to the mouse"

-------
Well, this off- topic was a little tongue in tech in the cheek. Nevertheless, I don't think memorizing a lot of shortcuts is always superior to a toolbar click.

There are already many dialogs that work very well with keyboard users in mind. Excuse me blowing my own horn. ;-) The "Procedure List" dialog comes to mind. Default focus, default actions etc are all in place. For myself, that dialog is my primary way of navigating units.

I am willing to help, but not very familiar with the Lazarus codebase.

The issues I listed are all very minor things. Any programmer should be able to fix those. You do not require deep knowledge of Lazarus IDE internals.

Regards,
Graeme

@Graeme

The "Source -> Enclose in IFDEF" dialog comes to mind. The Package windows too. Some of these I have tweaked locally to suite my needs better

Pls, list issues [easy] with all IDE dialogs- i will try to fix em.

Speed is only one part of it. And yes, I believe I am faster with shortcuts. :-)

The other very important point is... while coding I want that flow of ideas to continue uninterrupted. The ideas and code should flow from by brain to the IDE. Leaving the keyboard and switching to the mouse (trackball in my case) breaks that flow.

Regards,
Graeme

Ondrej Pokorny wrote

> The "Source -> Enclose in IFDEF" dialog comes to mind. I don't see a problem here. Can you be specific?

I've just retested with Lazarus Trunk, and indeed it is keyboard friendly now. It definitely wasn't so before. Not sure when it got improved, but I'm very glad it is. I'll start using it again.

> The Package windows too. This one is better to be used with mouse. Honestly, I don't know how you want to redesign it to be usable with the keyboard.

The ability to quickly search and open a package (probably project dependies only) and then be able to quickly do actions like Build, Search for unit etc. And the ability to switch back to the main editor windows again.

Currently I can't tab between toolbar buttons, can't trigger the "More" dropdown. I can't even figure out how to tab between IDE windows (I can tab between ALL applications currently open, but not just Lazarus).

Regards,
Graeme

Yes, people have actually improved many dialog's UX. AlexeyT has been one of them.

For "Search for unit" there is a new feature in trunk: Menu -> File -> Open Unit. It lists all available units for current file that you can quickly open.

Maybe you can use it instead.

Unfortunately that's how the TToolBar works. No chance to change it. We'd need a new toolbar component that would accept focus for the tool buttons.

I can't even figure out how to tab between IDE windows (I can tab between ALL applications currently open, but not just Lazarus).

I don't know about other OS than Windows, but it is indeed not possible yet (on Windows). For now, you have to declare a shortcut to show/focus a specific IDE window.

But it should be easily possible to add support for this. E.g. take a look how the tabbing through recent editor files is done (Ctrl+~, Ctrl+Shift+~). A similar function could be easily adapted to tab through open IDE windows as well.

Ondrej

There is one way to do it more simply: add &-hotkeys to the buttons. E.g. the help button can be triggered with Alt+H (because the caption is &Help). Adding &-hotkeys to other buttons will allow to trigger them with a keyboard as well.

Ondrej

I was just going to suggest that, then read your second reply. :-)

My other suggestion was to simply place a TActionList on each Package windows. Then define all the actions with associated shortcuts. The Captions of each TAction doesn't need to contain the & symbol for a hotkey (though highly recommended). The defined TAction.Shortcut property works just fine without the & in the TAction.Caption. The for should then process those shortcuts as part of any keyboard event in the form. That's all part of the benefits in using actions.

Regards,
Graeme

Don't forget that every shortcut needs to be editable in Key Mappings in IDE options. The &-hotkeys don't.

Ondrej