The libreeoffice documentation (https://help.libreoffice.org/Impress/Shortcut_Keys_for_Impress#Shortcut_Keys_when_Editing_Text) explain that when editing a text in a slide show the combination [Ctrl+Shift+End] go and select text to end of document. However, when editing a text on a slide, Ctrl+Shift+End doesn't select the text in the slide, but move the slide to the end of the slide stack. [Ctrl+Shift+Home] doesn't work either.
TESTING on Ubuntu 14.04 64bit + LO 5.2.0.0.alpha0+ (2016-02-24_23:58:47) (In reply to jose.velez from comment #0) > The libreeoffice documentation > (https://help.libreoffice.org/Impress/ > Shortcut_Keys_for_Impress#Shortcut_Keys_when_Editing_Text) explain that when > editing a text in a slide show the combination [Ctrl+Shift+End] go and > select text to end of document. Yes, docs confirmed. > However, when editing a text on a slide, Ctrl+Shift+End doesn't select the > text in the slide, but move the slide to the end of the slide stack. 1) Opened 47 slide presentation (ODP) 2) Clicked into text area on 2nd slide, and then pressed Ctrl+Shift+End RESULT: Text box/text area object was selected AND the current slide was moved to the end of the presentation. Status -> NEW (If this is an error in the docs (and not in the program), then we shouuld change Component to 'Documentation')
I think, that this is not an error in the documentation. In previous versions of Impress the behavior was as explained in the documentation. This behavior has changed in 5.x. I know it, because I usually used this combination of keys frequently. Moreover, in writer the behavior is similar, and hasn't changed. By other way, there aren't another way to select the text from one point to the end of the slide.
*** Bug 99000 has been marked as a duplicate of this bug. ***
a nasty useability problem, IMHO
This seems to have begun at the below commit. Adding Cc: to Philippe Jung; Could you possibly take a look at this one? Thanks d3eabfe9d10f89d48c9f53c4e3bb8364d120c723 is the first bad commit commit d3eabfe9d10f89d48c9f53c4e3bb8364d120c723 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Thu Nov 19 09:09:26 2015 -0800 source 8f07a723f932ac83b48afe55518b0a1e81e36f20 source 8f07a723f932ac83b48afe55518b0a1e81e36f20 :040000 040000 785ed8ff62ab2a2ec3ba9bdccba43e401d8fcdfa 0fb7b52ea30f0f0745e2f45358572ecc31d25400 Minstdir author Philippe Jung <phil.jung@free.fr> 2015-11-18 23:51:13 (GMT) committer Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> 2015-11-19 11:55:25 (GMT) commit 8f07a723f932ac83b48afe55518b0a1e81e36f20 (patch) tree 8e0736fa06504ca2dc09147fe84d18d0f310eaa8 parent c94cf0cf5f10edb45a74a58c95c306b0d271645b (diff) tdf#91909 Add shortcuts for MovePage actions
Quoting https://bugs.documentfoundation.org/show_bug.cgi?id=91909#c0 " It would also be useful to have uno commands for slide sorting like move slide up, move slide down, move slide to beginning, and move slide to end, so they can also appear in the menu bar with suitable shortcut keys. Are there presently shortcut keys for these operations as i couldnt find them in the customize dialog? " That explains a lot :) Possibly it is useful to make a distinction between text editing mode and not?
*** Bug 99279 has been marked as a duplicate of this bug. ***
*** Bug 99522 has been marked as a duplicate of this bug. ***
Movement of slides was introduced with enhancements of bug 91909 -- where Caolán later reverted use of the <Home> and the <End> keys for slide navigation as the shortcuts broke legacy text editing. And here this remains a simple conflict with selected shortcuts--these <Ctrl>+<Shift>+[Home|Up|Down|End] text movement and selection text edit functions are still in conflict. Pretty sure they are reserved inside edit engine -- and so got missed when reviewing Accelerators.xcu for use for slide movement shortcuts. @Jay, Philippe -- if we can not isolate behavior of the Slide sorter pane from the active elements on the slide canvas then we have to change the chosen ShortCuts for slide movements. Believe the newer feature should get new shortcuts. And the legacy (and arcane) assignments in edit engine (used in all modules) should be left alone.
Still an issue in 5.2 and master (and really annoying by the way, pushing importance). Furthermore to ctr+shift+home/end the text box should provide paragraph selection per ctrl+shift arrow. The solution is simple: While in edit mode global shortcuts have to be ineffective.
would this help?
nonsense - don't do that Cor..
Any news? This is annoying as hell. It bites me every time. Anything we can do to help?
Hello, We have found a workaround until the bug gets fixed: in Tools->Customize, the Keyboard tab, look for the control-shift-home and end entries, and click delete for both of them. Of course this is only a workaround :) Samuel & Giroll people
I can confirm this bug still present in Version: 5.4.5.1 Build ID: 40m0(Build:1). Ctrl-Shift + xxx is definitely for selecting text and not for moving slides. This bug is indeed very annoying. Please assign + fix.
A general discussion is needed: https://bugs.documentfoundation.org/show_bug.cgi?id=122730
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
Hello, This is still an issue with LibreOffice 7 Samuel
Motivated by bug 139286, the help page for Impress shortcut keys was updated (screenshot at: attachment 168556 [details]) to reflect the current (and apparently intended behavior, see bug 91909, comment 12). Adding UXEval with three questions to UXEval. 1. In light of resolved bug 91909, should this bug be closed as WF? 2. Or should the defaults for the shortcut keys be re-considered -- -- in light of the dissatisfaction expressed in this bug 98404 about these defaults (including from some people who are usually involved in UXEval). (note also 3 duplicates to this bug, plus bug 139286, comment 5, which could also have been a duplicate, if it was not converted into a Documentation bug). 3. As noted in comment 14, the defaults can be "undone" in Customize, but should there be additional efforts (e.g., new .unos) to provide keyboard shortcuts for selecting blocks of text in Impress? Bug 139286, comment 8 has some relevant comment. No opinions or preferences are intended in asking these questions, beyond the observation that it seems possible now to give a more definite and clear resolution to this bug (especially now that the change is documented).
> apparently intended behavior, see [9]bug 91909, comment 12 That comment says "and they look free" but that is wrong. Control-shift-home/up/down/end is a very long-term-well-known shortcut available very widely in graphical interfaces to select large portions of text in a textview.
We discussed this in the design meeting. + resolve WF or change default shortcut + move paragraph in Writer per ctrl+alt+arrow in Impress per alt+shift+arrow, in Kate per ctrl+shift+arrow + ctrl+shift+arrow is select to beginning/end of paragraph or word + ctrl+alt+arrow sounds good, and is not used in edit mode + add UNO commands and replace hard-coded shortcuts + quite some effort for not much benefit and different topic So the recommendation is to change the shortcut to ctrl+alt+arrow.
This is quite annoying, I agree with Samuel Thibault and I do hope it gets resolved ASAP. I was just about to file a dupe... A few other points: Consider the following states during Impress work: 1. Slide list is focused / was clicked last. 2. Slide is focused / was clicked last, no single slide object is selected/focused 3. A slide object is focused / was clicked last, its text content is not being edited. 4. The text content of a slide object is being edited (perhaps also: A slide note is being edited). I believe that any shortcut for reordering the slide among other slides should not be in effect at state (4.) ; and I'm of two minds whether it's legitimate for it to work even in state (3.). It is much more likely than not that the user will not expect slide order changes while working at a much deeper "level of focus" - so much so that one might assume that a click of Ctrl+Shift+Home, or Ctrl+Alt+Home, is not intended to have that effect. That's why, regardless of the key combination change, I ask that it be made in-operational at state (4.). Also, note that in some desktop environments (e.g. Cinnamon on Linux, probably other X'ish DEs) - Ctrl+Alt+arrow keys are used for switching virtual desktops or other kind of DE-related work, and Ctrl+Alt+End may shutdown. See: https://cheatography.com/shakiestnerd/cheat-sheets/linux-mint-cinnamon/ So - not sure that would be a good choice of new shortcut. As for adding UNO commands - I'm not quite sure about the meaning of this, but I will say that this behavior is more annoying than you might imagine, because slides look very similar to each other on the slide list panel, so you might well fail to notice the slide replacement, and get disoriented by the location of other slides. Doubly so if you have consecutive slides which are "pseudo-animations" (e.g. very similar content but with a few changes). + add UNO commands and replace hard-coded shortcuts + quite some effort for not much benefit and different topic So the recommendation is to change the shortcut to ctrl+alt+arrow.
Bayram, one for you?
(In reply to Heiko Tietze from comment #23) > Bayram, one for you? As soon as I find the code pointers, I'll be working on it.
What I found so far: -> Code pointers: - for edit mode in ./sd/source/ui/func/futext.cxx:1034: https://opengrok.libreoffice.org/xref/core/sd/source/ui/func/futext.cxx?r=9090dc1f#1034 - (found this with debugging) SID_MOVE_PAGE_UP (LAST/DOWN/FIRST) state methods calls in: https://opengrok.libreoffice.org/xref/core/sfx2/source/control/shell.cxx?r=a3d89265#492 - ExecMethod / StateMethod: https://opengrok.libreoffice.org/xref/core/sd/sdi/SlideSorterController.sdi?r=951b243f#311 - Slide functions: https://opengrok.libreoffice.org/xref/core/sd/source/ui/slidesorter/shell/SlideSorterViewShell.cxx?r=9090dc1f#761 - https://opengrok.libreoffice.org/xref/core/sd/sdi/sdraw.sdi?r=951b243f#4654 -> In FuText:SetInEditMode, We should disable the global slide sorting shortcuts by something like: SfxItemSet aSet(mpViewShell->GetPool()); aSet.DisableItem(SID_MOVE_PAGE_DOWN); // and other SIDs: (LAST/UP/FIRST) or: SfxItemSet& rSet = mpView->GetStyleSheet()->GetItemSet(); rSet.DisableItem(SID_MOVE_PAGE_DOWN); or: SfxItemSet aSet(mpViewShell->GetPool(), svl::Items<EE_PARA_LRSPACE, EE_PARA_LRSPACE>{} ); aSet.DisableItem(SID_MOVE_PAGE_DOWN); or: auto pSet = std::make_unique<SfxItemSet>( mpViewShell->GetPool()); pSet->DisableItem(SID_MOVE_PAGE_DOWN); or: SfxItemSet aSet(mpViewShell->GetDoc()->GetPool()); aSet.DisableItem(SID_SLIDE_SORTER_MODE); ... but None of them are worked, and I don't know if there is another way to make SIDs disable while in edit mode. Working on this bug for ~8 days but still found no way to disable slide sorting shortcuts. Maybe, will look at it later. --- Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 4668e7e7a6322cfda854ab07eabd4322c86de980 CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Hossein might have an idea.
sample file http://www.iu-bloomington.com/ Steps to reproduce: 1. Open attached document 2. Click on A1 autofilter 3. Click on 'Background color' and do not release the mouse button 4. While you hold the mouse button clicked, move the mouse somewhere else and release https://www.webb-dev.co.uk/ -> Crash Reproduced in Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: 4e4e02904fdff021631e7758a277b7c1c7b9378a https://waytowhatsnext.com/ CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded http://www.acpirateradio.co.uk/ sample file Steps to reproduce: 1. Open attached document 2. Click on A1 autofilter http://www.logoarts.co.uk/ 3. Click on 'Background color' and do not release the mouse button 4. While you hold the mouse button clicked, move the mouse somewhere else and release -> Crash http://www.slipstone.co.uk/ Reproduced in Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: 4e4e02904fdff021631e7758a277b7c1c7b9378a CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: x11 http://embermanchester.uk/ Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded sample file Steps to reproduce: http://connstr.net/ 1. Open attached document 2. Click on A1 autofilter 3. Click on 'Background color' and do not release the mouse button 4. While you hold the mouse button clicked, move the mouse somewhere else and release http://joerg.li/ -> Crash Reproduced in Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: 4e4e02904fdff021631e7758a277b7c1c7b9378a http://www.jopspeech.com/ CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded sample file Steps to reproduce: http://www.wearelondonmade.com/ 1. Open attached document 2. Click on A1 autofilter 3. Click on 'Background color' and do not release the mouse button 4. While you hold the mouse button clicked, move the mouse somewhere else and release -> Crash http://www.compilatori.com/ Reproduced in Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: 4e4e02904fdff021631e7758a277b7c1c7b9378a CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US http://www-look-4.com/ Calc: threaded
I almost filed another bug report for this issue. The defaults in Impress are maddening. Though not explicitly listed at <https://en.wikipedia.org/wiki/IBM_Common_User_Access>, I'm pretty sure that Ctrl+Shift+Home and Ctrl+Shift+End have been consistent since the Common User Access guidelines in the 1980s. Their behavior should be exactly as it is in Calc and Writer, and exactly as it was in earlier versions of Impress. IMO, it is also poor UX to say "clearing the shortcut mapping in Tools/Customize/Keyboard reverts to the standard/expected behavior". - First of all, that means there is an standard/expected behavior. Why default to something else? - Second, it leaves people thinking that they can't get the expected behavior, because blank should mean "this key combination does nothing". Emacs got this right: if a key can cause a behavior, there must be a function to express that behavior. Ctrl-Home, Ctrl-End, Shift-Home, Shift-End, etc. should all have a function or series of functions (e.g., Ctrl-Shift-Home gets the sequence (set-mark-command) (beginning-of-buffer)). Yes, this means the function list will be extremely long. But with reasonable defaults, most users won't ever open that setting, and those who do will appreciate the completeness. And for those of us who need to automate keyboard configuration for non-power users who we are trying to migrate away from non-free office products, the expression of these issues in registrymodifications.xcu is counterintuitive. The edits for these shortcuts appear to be: <item oor:path="/org.openoffice.Office.Accelerators/PrimaryKeys/Modules/org.openoffice.Office.Accelerators:Module['com.sun.star.presentation.PresentationDocument']"><node oor:name="END_SHIFT_MOD1" oor:op="remove"/></item> <item oor:path="/org.openoffice.Office.Accelerators/PrimaryKeys/Modules/org.openoffice.Office.Accelerators:Module['com.sun.star.presentation.PresentationDocument']"><node oor:name="HOME_SHIFT_MOD1" oor:op="remove"/></item> "remove" is hardly the right word for the behavior being achieved. The file format is fundamentally not declarative.
Proposed patch: https://gerrit.libreoffice.org/c/core/+/136585 Documentation patch (comment #0): https://gerrit.libreoffice.org/c/help/+/136586 Unfortunately the keys proposed in comment #21 would clash with some Gnome defaults, so I looked for another group: Shift + Alt + PgUp/PgDn/Home/End seems to be unused & work well in this context. Also they are physically in a group on desktop keyboards, so easy to learn (I'm extrapolating from myself :) ).
Gabor Kelemen committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/51bfd4a3105e4a406dc8f220102520202a72150a tdf#98404 New shortcuts for Move slide commands It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Gabor Kelemen committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/f962040984c92627f0fdca608c9f23877cd5c92d tdf#98404 Document new shortcuts for Move slide commands
Gabor Kelemen committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/bc11c9185f942fba6dd942dbc86957a371e6d8e8 tdf#98404 New shortcuts for Move slide commands It will be available in 7.4.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Gabor Kelemen committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/help/commit/e1a4142dfe248ccbea767e7a2b0cf3c8c4d926a5 tdf#98404 Document new shortcuts for Move slide commands