Re: CuteHMI in kdereview

[M .]

 Hi,

Kevin Funk wrote:

I think you're beating a dead horse here. The ship has sailed.


I am aware all of that Don't get me wrong. I don't want to turn the tide
and convince you to use Qbs instead of CMake. I'm just pointing out: maybe
take a look at this nuclear-powered ship prototype, even tho' it hadn't
left the docks. Have been asked about Qbs, so I explained my point of view.
No reason to be concerned :P

You'll be missing out on quite a bit of tooling which is implemented in
KDE's Extra CMake Modules framework:
https://github.com/KDE/extra-cmake-modules
  (part of that is all the translation handling)
It may be hard to accomplish with CMake.

Yeah, I have been looking at ECM. It's all well done etc, but what I meant
by "components" are components like QML components. I've been using CMake
in my projects for many years, so I can compare the two. I'm not a Qbs
fanboy. CMake has its pros and advantages, but its language lacks
constructs like structures/classes/records, inheritance etc (don't want to
start another offtopic here, but I think we can all agree that CMake
language is a bit limited and its syntax is quaint...).

Then, I have deliberately written **something like** Qbs (not just Qbs). I
mentioned Qbs has some issues (I didn't want to elaborate, to not make an
offtopic, but here we are...), most important of which is that it isn't
built on top of QQmlEngine and it's not QML, but merely a QML dialect.
Imagine a proper QML-based build system, into which you could import
standard QML extensions. Integrity is something we're missing nowadays.
Still Qbs product definition files are clean and unmatched in terms of
readability, thus I think it paves the way for next-gen build system, which
will eventually replace CMake.

I hope Qbs controversy is clarified now

Regards,
Michal

sob., 15 lut 2020 o 14:11 Kevin Funk  napisał(a):

> On Thursday, 13 February 2020 11:00:27 CET Michal Policht wrote:
> > Yeah, I neglected translations a bit... I am going to implement adequate
> > Qbs module for extracting translations.
>
> Heya,
>
> > When it comes to Qbs, it's not dead. Community has taken over the
> > project, there's active development and recent version was released just
> > 44 days ago.
> >
> > We migrated from QMake to Qbs, when it was still supported by Qt Company
> > and promoted as official build system for Qt 6. Thus we assumed Qbs is
> > the future. We've found that Qbs has some issues (like every software),
> > but in overal it's very capable and powerful piece of software. It also
> > provides much faster builds on Windows. I wish more people would give it
> > a try before burying the project, to at least see the potential. With
> > something like Qbs we could create a build framework with reusable
> > components, so that each KDE subproject could benefit from it and become
> > naturally integrated.
>
> I think you're beating a dead horse here. The ship has sailed.
>
> You'll be missing out on quite a bit of tooling which is implemented in
> KDE's
> Extra CMake Modules framework:
>   https://github.com/KDE/extra-cmake-modules
>   (part of that is all the translation handling)
>
> There's also no support for building QBS projects on KDE's CI:
>   https://build.kde.org
>
> > It may be hard to accomplish with CMake.
>
> What exactly? I mean it's all there already.
>
> > Regards,
>
> PS: Qt's CMake-based build system just got merged into qtbase dev branch a
> few
> days ago.
>
> Regards,
> Kevin
>
>
> > Michal
> >
> > > El dilluns, 3 de febrer de 2020, a les 17:57:24 CET, Michal Policht va
> escriure:
> > >> Hello there,
> > >>
> > >> CuteHMI (https://cutehmi.kde.org/) has been moved to kdereview.
> > >
> > > It has no Messages.sh for translation extraction.
> > >
> > > Any particular reason you're using a dead build system none of our
> > > projects uses?
> > >
> > > Cheers,
> > >
> > >   Albert
> > >>
> > >> CuteHMI is meant to be a set of tools and components that help one to
> > >> create QML-based HMI/SCADA software.
> > >>
> > >> The project has been started few years ago, because I couldn't find
> any
> > >> open-source, QML-based HMI/SCADA framework I could put my things into.
> > >>
> > >> Regards
> > >>
> > >> Michal Policht
>
>
> --
> Kevin Funk | kf...@kde.org | http://kfunk.org

Fish: ssh key pass-phrase prompt use wrong encoding

[Alexis M.]

While wanting to put files to a remote host using the fish protocol, it 
prompted as expected the passphrase for the ssh key I use.


MY pass-phrase actually contains non ASCII characters encoded as utf8, 
but the dialog box seems to expect a latin1 string.


Test to reproduce the error:
Precondition: remote account password or ssh key passphrase is ètr

Test 1:
 - Use fish to access a remote server using for example Dolphin
 - A dialog prompt for the password (or passphrase of the key)
 - Put ètr in the password field and confirm
 - The password is refused and fish ask again for the password


Test 2:
 - Use fish to access a remote server using for example Dolphin
 - A dialog prompt for the password (or passphrase of the key)
 - Put ètr in the password field and confirm
 - The password is accepted and fish show files of the remote server

The password is read as Unicode UTF-16 (using QString), then kio_fish 
convert it to latin1 and send it to ssh.


When putting ètr in the password prompt, the è character is sent to 
ssh as byte 0xE8. ssh read 0xE8 and compare it to the pass-phrase which 
is encoded in utf8, and so fail because è in UTF-8 is encoded as bytes 
0xC3 0xA8.


When putting ètr, è is sent to ssh as bytes 0xC3 0xA8. ssh read 
these two bytes and compare them to the passphrase and these bytes match 
to the the UTF-8 character è so ssh can use key on go on.


In my case, I created the key using command line, and my system use 
UTF-8, so the passphrase I entered is encoded as UTF-8. ssh does not 
seems to do any character conversion, so the expect encoding is the one 
used at passphrase creation.



I posted a bug report about that:
https://bugs.kde.org/show_bug.cgi?id=332428

After more investigation, it seems that other text strings (username, 
account password, hostname) may be read by ssh as UTF-8 strings too. In 
comment 2 in the bug report, I say that ssh is started with LANG=C 
LC_ALL=C, but it's not the case (I confused ssh arguments with the 
command executed on the remote host when ssh start).


To be sure I checked the environment variables of the ssh spawned by 
kio_fish, and there is LANG=fr_FR.UTF-8.


So as I first thought, username, hostname and password (in case of login 
with password authentication) may also be read as UTF-8 strings by ssh 
but fish send them as latin1 strings.


This issue seems to not be so easy to handle, so can someone confirm 
expected encodings and if username, hostname, password and pass-phrase 
should indeed be send using the local encoding (ie: use toLocal8Bits) 
instead of latin1 (toLatin1).


Cheers,
  Alexis