Help required to test with QtQuick Controls 2

[Daniel Shahaf]

Johnny Jazeix wrote on Wed, Apr 27, 2022 at 21:52:02 +0200:
> Hi,
> 
> thanks for testing!
> 
> Le mer. 27 avr. 2022 à 21:31, Daniel Shahaf <danielsh at apache.org> a écrit :
> 
> > Daniel Shahaf wrote on Wed, Apr 27, 2022 at 18:10:02 +0000:
> > > Johnny Jazeix wrote on Sat, Apr 23, 2022 at 17:25:37 +0200:
> > > > Due to deprecation of QtQuick.Controls 1 in previous versions of Qt
> > and the
> > > > fact that it will be removed in Qt 6, I've started to update the code
> > to
> > > > use QtQuick.Controls 2 (
> > > > https://invent.kde.org/education/gcompris/-/merge_requests/108).
> > > > Ideally, it should be transparent for the users.
> > >
> > > Found a few bugs, but I don't know whether they're new in this version
> > > or not.
> > >
> > > Environment is the Android 64b apk below (reports itself as v2.4) on
> > > Android 11.  It's a friend's device and I'm reporting this on their
> > > behalf.
> > >
> > > 0. Bugs https://bugs.kde.org/show_bug.cgi?id=446848 "Gcompris say
> > > alphabet letter names instead of actual letter sound" and
> > > https://bugs.kde.org/show_bug.cgi?id=428863 "The letter sounds should be
> > > the phonemes, not the letter names" seem to be duplicates of each other.
> > >
> > > 1. Hebrew translation of the help of one activity had some lines start
> > > with a solitary ק, as though it were a bullet point.  I can't find that
> > > in the po files though (in either trunk or branches/stable), and
> > > unfortunately I didn't make a note of what activity it was.  I think it
> > > might have been "Mirror the given image".
> >
> >
> We use html tags (<ul><li></li></ul>) for the keyboard controls in the Help
> which add a bullet point.

*nod* I saw that before I posted :)

> Sometimes there is only one item in the list. I haven't found the ק.

Thanks for looking.

> > Aside: I tried to open that activity in a self-compiled 2.4 (the
> > release, not the packages from this thread) on Linux, and got a brief
> > screen flash (I think that was the screen greying out and showing the
> > "two arrows in a circle" graphic briefly) followed by colorful
> > 7-pointed-stars on the activity's tile.  On subsequent tries I got only
> > the colorful stars without the screen flash.  On stderr I got this:
> >
> > qrc:/gcompris/src/activities/path_encoding/PathEncoding.qml:12:1: Type
> > GridPath unavailable
> > qrc:/gcompris/src/activities/path_encoding/GridPath.qml:99:9: Type MapView
> > unavailable
> > qrc:/gcompris/src/activities/path_encoding/MapView.qml:9:1: module
> > "QtQml.Models" is not installed
> >
> > So, two issues:
> >
> > 1. The activity doesn't start.  (Probably missing dependency or
> > something?  Should I install
> > /usr/lib/x86_64-linux-gnu/qt6/qml/QtQml/Models/libmodelsplugin.so
> > from my OS packages?)
> >
> >
> Yes, this is a missing package. I don't know which one exactly but when I
> tested on Ubuntu 20.04, I installed:
> g++ cmake git libssl-dev   qml-module-qtquick-controls2
> qtdeclarative5-private-dev qtbase5-private-dev
> qtquickcontrols2-5-private-dev libqt5svg5-dev qml-module-qtmultimedia
> qml-module-qtgraphicaleffects qt5-qmake qtcreator qtdeclarative5-dev
> qtdeclarative5-dev qtmultimedia5-dev qtquickcontrols2-5-dev qttools5-dev
> qttools5-dev-tools libqt5multimedia5-plugins qml-module-qtsensors
> libqt5quickparticles5 qml-module-qtquick2 qml-module-qtquick-particles2
> libqt5sensors5-dev libqt5sensors5

Thanks.  I'm on Debian, so this ought to be close enough.  I'll look
further into this.

> > 2. There's no error message about that.  I'd have expected an on-screen
> > message.
> >
> >
> It's an internal qml error due to a missing dependency. I'll take a look to
> find on how to show it on screen but it should not happen to end users so
> it's not on the top of my list :).
> 

Sure.

> > ----
> >
> > Also, with the same self-compiled 2.4 on Linux, in the settings screen,
> > the "Localized voices" label looks like an unclickable checkbox, because
> > the "X" / "V" graphic is to its right.  That makes sense in LTR
> > languages, but for RTL languages, where the "X" / "V" graphic of
> > checkboxes is placed to the _right_ of the checkbox's text, the
> > placement is misleading.
> >
> >
> I've created https://phabricator.kde.org/T15482 to write all the
> inconsistencies we have for RTL language, can you take a look and add other
> issues?

I have an issue with the identity.k.o registration; I'll follow up on
that separately.  In the meantime, one more issue:

- In Hebrew at least, the "About" screen aligns the first paragraph to
  the right (correctly) but the following paragraphs to the left
  (incorrectly).  The order of letters and words is correct, but it's
  the left margin that aligns rather than the right one.  Reversed
  example:

	    Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Ut
	purus elit, vestibulum ut, placerat ac, adipiscing vitae, felis.
	Curabitur dictum gravida mauris.  Nam arcu libero, nonummy eget,
	                            consectetuer id, vulputate a, magna.

> For example, the authors in the help are written: "<name <email.com" where
> we expect "name <email>". What is the correct form in Hebrew for this?

Good question.  I suppose it should render as "name <email>", but in
logical order, i.e., with name on the right.

The po file writes the angle brackets as U+003C first and U+003E second,
following rfc822's syntax as much as possible.  However, these two
characters get mirrored in RTL contexts:

[[[
% unicode 003c
U+003C LESS-THAN SIGN
UTF-8: 3c UTF-16BE: 003c Decimal: < Octal: \074
<
Category: Sm (Symbol, Math); East Asian width: Na (narrow)
Unicode block: 0000..007F; Basic Latin
Bidi: ON (Other Neutrals)

Character is mirrored
]]]

This would be why in your example you get two "<" marks.  The one
between "name" and "email" [in byte order] is a U+003C rendered
mirrored, because it's preceded by an RTL character; the one after
"email" [again in byte order] is a U+003E rendered normally, because
it's preceded by an LTR character.

I'm not sure how best to fix this.  Normally I'd consider explicit
Unicode directionality characters (the po file already uses literal
U+200E, for instance), but this is a pseudo rfc822 context, and I'm not
sure whether email clients would DTRT with embedded directionality
characters, should the line be copy-pasted into them (e.g., by
a translator).  Perhaps we could sidestep the problem entirely by using
<a href="mailto:…">[translator's name in Hebrew]</a> tags?  Or by moving
the email addresses to a po comment; they _already_ aren't rendered (as
of v2.4 on Linux).

Cheers,

Daniel

[1] https://en.wikipedia.org/wiki/Bidirectional_text#Table_of_possible_BiDi_character_types

> Cheers,
> 
> Johnny
> 
> 
> > Cheers,
> >
> > Daniel
> >