[Upstream] Redo and Undo should follow gnome scheme

Set as affecting the One Hundred Papercuts project too, because in my opinion this is a small inconsistency issue which should be fixed in ubuntu, and it won't be fixed upstream. With the replacement of OpenOffice with LibreOffice, this will still remain an issue, only it will appear in the libreoffice(Ubuntu) package. If libreOffice becomes the default in Natty, it would be nice to have this small "personalization" in it :).

Hmmm, i know many applications that do this, not just OO.o, is this really necessary?

I think itás worth a discussion. Most of the apps included in the default install are Gnome apps, having the Gnome keyboard (Ctrl+S for Save, Ctrl+Z for Undo, Ctrl+O for Open, Ctrl+N for new) shortcuts. There are only a few exceptions. OO.o is one of them. Why do not make them consistent?
One of the main reason for the introduction of the indicators was the lack of consistency in the old notification area as a usability issue. Doesn't this apply to the shortcut keys too?
Different shortcuts for the same actions in different applications mean behavioral inconsistencies. It happened to me too, that I pressed Ctrl+Y and nothing happened (I am used to the Ctrl+Z and Ctrl+Y too). It took me some time to realize that the Gnome shortcut for Redo is Ctrl+Shift+Z in that particular application.
I am not saying that the keyboard shortcuts should all follow the gnome scheme, but only that they should follow the same scheme for the most common actions (New, Open, Save, Undo, Redo, Cut, Copy, Paste, Help).
Does this make sense?

It is certainly worth discussing. It's annoying to be honest having to learn different shortcuts for different apps. Especially when we have control over what shortcuts the apps have!

I don't mind if its Gnome or some other scheme, but Gnome would seem the sensible choice as a fair chunk of Ubuntu is based on Gnome and it would be the easiest scheme to adopt. I don't think there is much point discussing relative merits of different schemes.

Robert Roth your suggestion does indeed make sense!

I don't personally believe this is a valid papercut as OpenOffice is pretty much a lame duck at this stage, and fixing the bug in OOo will not fix it in LibreOffice since the code has already been forked. I personally believe it would be better to forget about fixing OpenOffice bugs at this time since it diverts valuable development resources away from other projects and onto something that is not on the long term roadmap for pretty much anyone.

LibreOffice will appear in Lauchpad soon enough, and Mark Shuttlework has already said he would like to include it in Ubuntu. Besides, the Document Foundation are gearing up for some serious development, and we may even see this bug being fixed before in the 1.0 release.

I would like to mark this as invalid both in openoffice and papercuts. What do people think?

I agree with that. It'd be better to fix it in LibreOffice.

Note: LibreOffice does have a project on launchpad, called df-libreoffice.

TDF is indeed working on the project, but maybe if we really want this fixed, we should send them a note about this as a feature request, and see if it's possible, and if not, make an U-specific patch. This would be good because it's still not clear when they'll have a release, and they won't do anything for us in the freeze period, and the fix most probably won't make it into Natty if we ask them after the release (which could be included in Natty)

So the questions are:
1) Is the fact that LibreOffice will be the default in Natty, already 'official'?
2) Do people agree that for consistency, the default office productivity suite should have the same redo shortcut as other applications?

I agree with marking it as invalid in OO.o, but it depends on the feedback on the second question whether it should be marked invalid in the Papercuts Project or not. Depending on the first question this bug should be set as affecting the LibreOffice (ubuntu) package (which still doesn't exist in LP).

I don't care if the shortcut gets changed in OO.o or LibreOffice, as long as the default office suite that is in Ubuntu follows the schema that the rest of the desktop uses.

I've submitted a bug report upstream so the developers are now aware of the situation. I agree that this should be invalidated as an OOo bug but confirmed as a papercut as the issue is that the default productivity suite, regardless of what it is, should adhere to the standard Gnome keyboard scheme.

The upstream devs have reviewed this bug and don't think it would be a great idea for them to maintain different versions for different desktop environments, so Redo will remain mapped to CTRL+Y at their end.

I propose that, when LibreOffice is being packaged for Ubuntu, that the Redo command be manually remapped, and that any reference in the application or documentation to the keyboard shortcut should be amended to reflect the new mapping.

We did patch something similar for F11 and fullscreen, in OO.o.

Ideally, it would be good if upstream made the change in the Linux/Gnome version.
It's more important to be consistent within a desktop than across desktops.

The Ctrl+Y shortcut should also be retained because this is a standard shortcut for users crossing over from windows.

Both Ctrl+Y and Ctrl+Shift+z should perform the same action.

[This is an automated message.]
There are no new official OpenOffice.org releases in Ubuntu packaging anymore => Won't Fix

If the problem persists, please mark this bug as "also affects project Libreoffice" or "also affects distribution Libreoffice (Ubuntu)" if that has not happened already.

Please leave references to upstream OpenOffice.org bugs in place to allow cross pollination.

Status changed to 'Confirmed' because the bug affects multiple users.

Fix released with upstream 4.1.0, thus in saucy which has 4.1.2

Closing as all other bug tasks showing "Fix Released"