In Calc, normally Ctrl-D starts the selection list.
This does not work in the Beta.
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?
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?
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.
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.
PS there are 'mails pending' on this subject from Christoph, Sophie, André, ..
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.
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!
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.
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. ;-)
"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.
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.
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.
At the moment I am not sure that the compatibillity 'issues' will be limited to key-bindings only ;-)
Never mind: changing the name of an option page - is necessary - is't the hardest thing.
(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.
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.
This is now fixed. Please refer to my blog post to see what to expect from this feature:
Verified in the 10_10_28_Cedric.rpm build - Closing - Sophie
This is a Calc issue, therefore changed the 'Component' field appropriately.