This is indeed the case. I hope there's a dupe for this bug, otherwise it's a bit embarrassing that it's only being reported now...

(In reply to Eyal Rozenberg from comment #1)
> This is indeed the case. I hope there's a dupe for this bug, otherwise it's
> a bit embarrassing that it's only being reported now...

Do you reproduce it with older versions of LibreOffice?

(In reply to Xisco Faulí from comment #2)
> Do you reproduce it with older versions of LibreOffice?

Reproduced with :

Version: 6.1.0.3
Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1
CPU threads: 4; OS: Linux 4.9; UI render: default; VCL: gtk2; 
Locale: he-IL (en_IL); Calc: group threaded

Thanks, Anyway, let's put it back to UNCONFIRMED until a third person confirms it...

I confirm that pressing Ctrl+Shift seems to do nothing whatsoever in Impress, whether it be the left or right pair, and whether the direction is RTL or LTR to start with.

Version: 6.1.3.2
Build ID: 1:6.1.3-1
CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; 
Locale: en-US (en_IL.UTF-8); Calc: group threaded

Bug still manifests with:

Version: 6.3.2.2
Build ID: 1:6.3.2-1
CPU threads: 4; OS: Linux 5.2; UI render: default; VCL: gtk3; 
Locale: he-IL (en_IL); UI-Language: en-US

Bug still manifests with:

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 250e4886d85a7e131da76f181b3fa7be02d1a76d
CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3
Locale: en-IL (en_IL); UI: en-US

So, this is a UI inconsistency between the different LO apps. And - I doubt it would be difficult to fix. Is there a valid reason why this is the case, or is it just an oversight?

Hard-coded key combination implemented in Writer sw/source/uibase/docvw/edtwin.cxx

        case CommandEventId::ModKeyChange :
        {
            const CommandModKeyData* pCommandData = rCEvt.GetModKeyData();
            if (!pCommandData->IsDown() && pCommandData->IsMod1() && !pCommandData->IsMod2())
            {
                sal_uInt16 nSlot = 0;
                if(pCommandData->IsLeftShift() && !pCommandData->IsRightShift())
                    nSlot = SID_ATTR_PARA_LEFT_TO_RIGHT;
                else if(!pCommandData->IsLeftShift() && pCommandData->IsRightShift())
                    nSlot = SID_ATTR_PARA_RIGHT_TO_LEFT;
                if(nSlot && SW_MOD()->GetCTLOptions().IsCTLFontEnabled())
                    GetView().GetViewFrame()->GetDispatcher()->Execute(nSlot);
            }
        }

Not sure where this should go in Draw/Impress. But potentially an easy hack.

So, this potential easy hack is a high-visibility bug for Impress.

Also, all text editors on Linux DE's (and Windows as well), including MS Office, respect Ctrl+LShift / RShift for direction switch. And so does Writer. So, this issue is a definite bug, not an enhancement.

Wait, is this really a bug? 
There is no omission as the control has been available as UNO for some time, and both function as a toolbox control toggle, and both assert on sd Text boxes (Draw and Impress).

.uno:ParaLeftToRight and .uno:ParaRightToLeft
"Left-To-Right"           "Right-To-Left"

In writer they are assigned
<Ctrl><Shift>+A -- is assigned to paragraph Left-to-Right
<Ctrl><Shift>+D -- is assigned to paragraph Right-to-Left

But they are simply not assigned in Draw/Impress; but can be done trivially from Tools -> Customize.

As to assigning <Ctrl><l-Shift> and <Ctrl><r-Shift> no LibreOffice (or OOo era) shortcuts currently distinguish between Right and Left keys; e.g. l-alt/r-alt, l-shift/r-shift or l-ctrl/r-ctrl.

IIRC, for the Unicode toggle we briefly tried differentiating l-Alt/ r-Alt, bcz of conflicts with r-Alt and its overloading as <AltGr> but had to back that out.

So, actually two questions here:

1) to pick a set of shortcuts cross module <Ctrl><Shift>+A / D as now in sw, or 

2) agree to expand the complexity of the keyboard mappings to be able to implement l-Shift/r-Shift usage cross platform, and then for which specific keycaps/names?

(In reply to V Stuart Foote from comment #13)
> Wait, is this really a bug? 

Yes.

> There is no omission as the control has been available as UNO for some time,
> and both function as a toolbox control toggle, and both assert on sd Text
> boxes (Draw and Impress).

The control works fine from the toolbar.

> In writer they are assigned
> <Ctrl><Shift>+A -- is assigned to paragraph Left-to-Right
> <Ctrl><Shift>+D -- is assigned to paragraph Right-to-Left

Are they? I've never noticed. And nobody would use that, because Ctrl+Shift+A is very inconvenient, and more importantly - because that's not what we're used to from everywhere else. We use Ctrl+LShift and Ctrl+RShift.

> But they are simply not assigned in Draw/Impress; but can be done trivially
> from Tools -> Customize.

I'm talking about the defaults here.


> As to assigning <Ctrl><l-Shift> and <Ctrl><r-Shift> no LibreOffice (or OOo
> era) shortcuts currently distinguish between Right and Left keys; e.g.
> l-alt/r-alt, l-shift/r-shift or l-ctrl/r-ctrl.

Well, Writer distinguishes between Ctrl+RShift and Ctrl+LShift fine, so...

(In reply to Eyal Rozenberg from comment #14)
> Well, Writer distinguishes between Ctrl+RShift and Ctrl+LShift fine, so...

Does it really? AFAICS, MSO has RTL vs. LTR only in the options and not on the paragraph level. Sure, I can expose the commands, eg. at the quick access bar, but ctrl+lshift does nothing for me.

Word does however provide the l/r-shift combination. And I'm in favor to either hard-code this for sd as well or to even make it customizable.

(In reply to Heiko Tietze from comment #15)
> > Well, Writer distinguishes between Ctrl+RShift and Ctrl+LShift fine, so...
> 
> Does it really?

Yes, it does. But - I'm on Linux, so let me change the bug to say so, I haven't checked on Windows yet.

> AFAICS, MSO has RTL vs. LTR only in the options and not on
> the paragraph level. 

I'm not sure what you mean.

> Sure, I can expose the commands, eg. at the quick access bar

This bug is about the keyboard... (also, I don't know what the quick access bar is.)

> but ctrl+lshift does nothing for me.

Well, that's a bug I think, because that's worked since forever. Also works for Shai, who confirmed this bug.

> Word does however provide the l/r-shift combination. And I'm in favor to
> either hard-code this for sd as well or to even make it customizable.

sd?

Anyway, I suggest doing it the same as in Writer: If it's hard-coded there, hard-code it in Impress.

(In reply to Eyal Rozenberg from comment #16)
> I'm not sure what you mean.

Was talking about Microsoft Office (MSO). 

Anyway, using Ctrl+Shift+Arrow selects the word and I'm a bit concerned if users start the action with ctrl+shift but interrupt and get surprised about what happens. OTOH it never occurred to me in Writer. And harmonizing the shortcuts make sense so +1 to use ctrl+l/rshift for text boxes in Impress/Draw.

(In reply to Heiko Tietze from comment #17)
> Anyway, using Ctrl+Shift+Arrow selects the word and I'm a bit concerned if
> users start the action with ctrl+shift but interrupt and get surprised about
> what happens.

Oh, that's fine, we're used to this from other applications (not just Writer).

> OTOH it never occurred to me in Writer. And harmonizing the
> shortcuts make sense so +1 to use ctrl+l/rshift for text boxes in
> Impress/Draw.

Right.

This is not an enhancement. People editing RTL content, and mixed RTL-LTR content, have to switch paragraph directions quite often, and the fact that the keyboard shortcuts for this don't work is simply a bug. It's not just a nice-to-have feature, it's how applications with RTL support work - and Impress doesn't.

This is also a high-"visibility" bug: People using Impress experience it right away when they start working, and immediately get the feeling of "Oh, this app is going to be problematic".

I've changed the severity to "normal", but I ask you (Heiko, Stuart, Xisco or Hussein) to consider increasing it to major.