Bug 30559 - Ctrl-D does not start the Selection list
Summary: Ctrl-D does not start the Selection list
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other Linux (All)
: medium normal
Assignee: Kohei Yoshida
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-02 05:07 UTC by Cor Nouws
Modified: 2012-05-04 02:55 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Cor Nouws 2010-10-02 05:07:31 UTC
In Calc, normally Ctrl-D starts the selection list.
This does not work in the Beta.
Comment 1 Kohei Yoshida 2010-10-03 08:50:28 UTC
This stems from the fact that in go-oo Ctrl-D is bound to Edit - Fill - Down.  Obviously we need a reasonable resolution for this.  Do you have any good idea to solve this?
Comment 2 Cor Nouws 2010-10-03 12:33:34 UTC
hi Kohei - nice meeting you here!

  "Ctrl-D is bound to Edit - Fill - Down"
That is what I expected (I knew that from Excel and was oh so positive surprised learning OOo's behaviour...) but it does not work in the Beta.

  "A good idea to solve this"  ... an extra option :-\ ?!

  Maybe an excel-mode. 
At least some things could be combined in an extension.
But an extra node under Tools> Options> LibreOffice-Calc solely dedicated to this kind of settings, is an idea too.

  What do you think?
Comment 3 Michael Meeks 2010-10-04 02:54:48 UTC
Weeelll ;-) extra options are usually the poor mans way of solving defaults problems, and only push the problem further away: what is the default for the defaults IMHO.

So - if there are real people, used to pressing ctrl-d hundreds of times per day - then we should add an option: "[ ] Use legacy OpenOffice.org input behaviour" or something.

Cor - is this annoying enough that it is worth expending 4+ developer hours, and dozens of translator hours to fix ?

If so - kohei - can we add that ? presumably it would help people migrate, and no doubt there are a few other keybindings / options that might fall under this umbrella.

Ultimately, I would like the focus to be on familiarity and making OO.o very easy to transition to for existing Office suite users.
Comment 4 Cor Nouws 2010-10-04 03:05:50 UTC
thanks Michael.
This is a good case to think about our policy wrt new functions, fluent migration, ...

where shall we have it? I prefer on a list.
Comment 5 Cor Nouws 2010-10-04 04:02:56 UTC
PS there are 'mails pending' on this subject from Christoph, Sophie, André, ..
Comment 6 Kohei Yoshida 2010-10-05 16:30:21 UTC
Let me grab this bug for the time being.

I'm still thinking of a clever way to resolve this.  It's easy to programmatically assign key bindings, so the trickiest part will be the UI bit i.e. where to add what.

Let me look into this.
Comment 7 Cor Nouws 2010-10-08 06:44:29 UTC
I am serious with my idea about combining Excel-things. That means that I am willing to help investigating / gathering stuff and so on.

For the other discussion: I will find me a place.

  - - -

Pls Note: Ctrl-D also starts lists that can be added with the function Data-Validation.
So ... thanks a lot if you look at this, Kohei!
Comment 8 Kohei Yoshida 2010-10-11 10:21:29 UTC
I'm leaning toward having an extra options page under LibreOffice Calc in the Options dialog, tentatively named "Key Bindings", where you can reset key bindings to different set of key bindings.
Comment 9 Kohei Yoshida 2010-10-11 10:27:03 UTC
Of course, the easiest way (for the developer) is to just set the legacy key bindings and export it from the Keyboard customize dialog.  Then give that to those users who prefer the old OOo key bindings. :-)

This way, no modification in the code base is needed at all. ;-)
Comment 10 Cor Nouws 2010-10-11 10:38:26 UTC
  "extra options page under LibreOffice Calc "
Something as Options|OOoWriter|Compatibility for paragraph indents etc ;-)

Besides that page, a possible choise is an extension, where all kind of bindings/settings are bundeld. But that of course is less user-friendly.
Comment 11 Kohei Yoshida 2010-10-11 10:51:46 UTC
Something like that, yes.  But I'd like to reserve the word "Compatibility" for application behaviors rather than key bindings.  Writer's compatibility option page appears to handle more of behavioral compatibility than default key bindings.
Comment 12 Kohei Yoshida 2010-10-11 10:55:37 UTC
Having said that, we could also combine the key binding compatibility with application behavior compatibility in a single place.  I don't know which approach is better, to be honest.
Comment 13 Cor Nouws 2010-10-11 10:58:07 UTC
At the moment I am not sure that the compatibillity 'issues' will be limited to key-bindings only ;-)
Are you?
Never mind: changing the name of an option page - is necessary - is't the hardest thing.
Comment 14 Kohei Yoshida 2010-10-11 11:14:20 UTC
(In reply to comment #13)
> At the moment I am not sure that the compatibillity 'issues' will be limited to
> key-bindings only ;-)
> Are you?

Right now, we are dealing with only the key binding compat, but we may extend that to other compat issues, the most likely one being the formula calculation compatibility.

> Never mind: changing the name of an option page - is necessary - is't the
> hardest thing.

Yeah, let's just call it "Compatibility" for now.  If we need to change this in the future we'll deal with that when that happens.
Comment 15 Cor Nouws 2010-10-11 11:16:26 UTC
Right - agree.

As said: I am willing to collect items that could be candidate for such options.
But don't hold your breath for that. I mean: have to do it in between normal business which is quite hectic with all comm-stuff.
And it is some work to collect and discuss, decide. 
So your pragmatic solution, that leaves room for possible future extension, definitely is the way to go.
Comment 16 Kohei Yoshida 2010-10-15 19:13:38 UTC
This is now fixed.  Please refer to my blog post to see what to expect from this feature:

http://kohei.us/2010/10/15/key-binding-compatibility-options-take-2/
Comment 17 sophie 2010-11-01 10:34:40 UTC
Verified in the 10_10_28_Cedric.rpm build - Closing - Sophie
Comment 18 Cor Nouws 2010-11-06 14:14:56 UTC
thanks Kohei!
Cor
Comment 19 Roman Eisele 2012-05-04 02:55:01 UTC
This is a Calc issue, therefore changed the 'Component' field appropriately.