Re: [Development] Longstanding bug in Qt with Arabic language
Hi Muhammed, thanks for pointing this issue out. I will look into it and report back on QTBUG-93371 in the course of next week. Brgds Axel Von: Development im Auftrag von Muhammed Hanny Sabbagh via Development Gesendet: Freitag, 20. Januar 2023 08:21 An: Development Betreff: [Development] Longstanding bug in Qt with Arabic language Hello Qt developers. I want to ask about a longstanding bug in Qt, related to the Arabic language: https://bugreports.qt.io/browse/QTBUG-93371 The bug happens when accelerators are being used, which causes Arabic words to break and hence, the UI gets broken and non-usable in every Qt application. This happens on all Linux distributions. This bug isn't new, it has been reported since 2016 in Qt5: https://bugreports.qt.io/browse/QTBUG-54350 And I personally remember reporting it in Qt4 since 10 years ago (but sadly I don't have the link from my old account). So we are talking about decades of broken user interfaces for Arabic users with all Qt applications, in Q4 all the way up to Qt6. Is there anything we can do to help fix this issue or "accelerate" interest in it? :) I have tens of folks who would confirm this issue and its importance to the Qt team if you would like. This bug causes a very unfortunate user experience for Arabic users on the Linux desktop; because every Qt application they use has a broken UI. I wish I was able to help by providing code but sadly I don't know C or the structure of Qt, so all I can do is bring attention to it and/or help test any possible fixes or patches. It sounds this bug can be fixed only from someone who knows the internals of Qt, mainly the Qt dev team itself (thus why I post here). Thank you in advance for any possible help! Regards. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Longstanding bug in Qt with Arabic language
Hello Qt developers. I want to ask about a longstanding bug in Qt, related to the Arabic language: https://bugreports.qt.io/browse/QTBUG-93371 The bug happens when accelerators are being used, which causes Arabic words to break and hence, the UI gets broken and non-usable in every Qt application. This happens on all Linux distributions. This bug isn't new, it has been reported since 2016 in Qt5: https://bugreports.qt.io/browse/QTBUG-54350 And I personally remember reporting it in Qt4 since 10 years ago (but sadly I don't have the link from my old account). So we are talking about decades of broken user interfaces for Arabic users with all Qt applications, in Q4 all the way up to Qt6. Is there anything we can do to help fix this issue or "accelerate" interest in it? :) I have tens of folks who would confirm this issue and its importance to the Qt team if you would like. This bug causes a very unfortunate user experience for Arabic users on the Linux desktop; because every Qt application they use has a broken UI. I wish I was able to help by providing code but sadly I don't know C or the structure of Qt, so all I can do is bring attention to it and/or help test any possible fixes or patches. It sounds this bug can be fixed only from someone who knows the internals of Qt, mainly the Qt dev team itself (thus why I post here). Thank you in advance for any possible help! Regards. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
On Thu, Jan 19, 2023 at 01:44:16PM +, Friedemann Kleint via Development wrote: > Hi, > > we also need to agree on whether the Qt library rules apply to the > full extent; for example: > > - Do we use the modern string literals (u"bla"_s, previously, example > code just constructed QString from ASCII and did not care about > -DQT_NO_CAST_FROM_ASCII, IIRC) I'd rather keep it concise, i.e. undecorated or _at most_ u"..." The prefered "modern" decoration changes rather rapidly (I think the previous incarnation barely survived a year in Qt base) and on the application side there's practically no user-noticable benefit at the price of serious developer time to stay "up to date". I wouldn't encourage through the examples. So: -1 > - Should tr() be used for all user-facing messages (although examples > mostly do not have translations set up) On the pro side this solves the string decoration problem, on the con side this uses the automatic class contexts which I don't think are a good idea for larger application and also requires "weird" Q_OBJECT / Q_DECLARE_TR_FUNCTION setup. So: +/- 0 on this one... > - Do we use std::as_const to avoid detaching > containers in loops (mostly missing for code ported from Q_FOREACH) +1 > Generally, when polishing examples, I found that member initialization > greatly simplifies code. +1 Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
Den tors 19 jan. 2023 13:34Giuseppe D'Angelo via Development < development@qt-project.org> skrev: > Il 19/01/23 10:27, Tor Arne Vestbø ha scritto: > >> All the contrary, do NOT do that, as it results in 200+ lines unnamed > lambdas. Strongly prefer named slots. Keep the lambdas short and to the > point. Do not use unnamed lambdas. > > No, strongly prefer lambdas if they are within a reasonable size. No-one > is arguing for 200+ line lambdas. > > The reason for such a harsh rule is that "reasonable size" tends to go > out of control very quickly. Is 10 lines too much? Maybe 15? Giving it a > fixed size opens up the door to a sorites paradox. The point is that > when you write the lambda the first time, it'll be completely obvious > what it does to you, even if it's long. You'll even avoid giving it a > name and connect straight to it, as it makes "perfect sense", in the > context of the code surrounding the lambda. > > But on the long run, this makes the code worse to read and understand. > No one will understand what the lambda is _meant_ to do without > analyzing the body of the lambda, line by line (cf.: a named > lambda/slot, where a proper name tells you everything). And reasoning on > the code surrounding the lambda is also much harder as it's intermingled > with the lambda itself. > > If anything: the fact that this is seen as _questionable_ and people > disagree on it should be a good indication that examples shouldn't do > it, as examples shouldn't feature _questionable_ code styles. > Agree. Code base I'm working on now is starting to get infested with "swollen" lambdas. Happens easier than you think. Elvis > My 2 c, > -- > Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
On Thursday, 19 January 2023 05:44:16 PST Friedemann Kleint via Development wrote: > - Do we use the modern string literals (u"bla"_s, previously, example code > just constructed QString from ASCII and did not care about > -DQT_NO_CAST_FROM_ASCII, IIRC) I don't mind using modern string literals, but don't set QT_NO_CAST_FROM_ASCII. That means non u"" strings are fine. Separate problem: we have to figure out a way that u"bla" without _s also works. It HAS to work. > - Should tr() be used for all user-facing messages (although examples > mostly do not have translations set up) Would be good, yes. > - Do we use std::as_const to avoid detaching containers in loops (mostly > missing for code ported from Q_FOREACH) Yes, that's good practice. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
Hi, we also need to agree on whether the Qt library rules apply to the full extent; for example: - Do we use the modern string literals (u"bla"_s, previously, example code just constructed QString from ASCII and did not care about -DQT_NO_CAST_FROM_ASCII, IIRC) - Should tr() be used for all user-facing messages (although examples mostly do not have translations set up) - Do we use std::as_const to avoid detaching containers in loops (mostly missing for code ported from Q_FOREACH) and probably some more? Generally, when polishing examples, I found that member initialization greatly simplifies code. Regards, Friedemann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
Il 19/01/23 10:27, Tor Arne Vestbø ha scritto: All the contrary, do NOT do that, as it results in 200+ lines unnamed lambdas. Strongly prefer named slots. Keep the lambdas short and to the point. Do not use unnamed lambdas. No, strongly prefer lambdas if they are within a reasonable size. No-one is arguing for 200+ line lambdas. The reason for such a harsh rule is that "reasonable size" tends to go out of control very quickly. Is 10 lines too much? Maybe 15? Giving it a fixed size opens up the door to a sorites paradox. The point is that when you write the lambda the first time, it'll be completely obvious what it does to you, even if it's long. You'll even avoid giving it a name and connect straight to it, as it makes "perfect sense", in the context of the code surrounding the lambda. But on the long run, this makes the code worse to read and understand. No one will understand what the lambda is _meant_ to do without analyzing the body of the lambda, line by line (cf.: a named lambda/slot, where a proper name tells you everything). And reasoning on the code surrounding the lambda is also much harder as it's intermingled with the lambda itself. If anything: the fact that this is seen as _questionable_ and people disagree on it should be a good indication that examples shouldn't do it, as examples shouldn't feature _questionable_ code styles. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
> On 18 Jan 2023, at 13:12, Giuseppe D'Angelo via Development > wrote: > >> RECOMMENDED >>Prefer signal/slot connection with lambdas: >> https://doc.qt.io/qt-6/signalsandslots.html > > All the contrary, do NOT do that, as it results in 200+ lines unnamed > lambdas. Strongly prefer named slots. Keep the lambdas short and to the > point. Do not use unnamed lambdas. No, strongly prefer lambdas if they are within a reasonable size. No-one is arguing for 200+ line lambdas. Tor Arne ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
On 1/18/23 19:56, A. Pönitz wrote: As a data point, even at it's height of .ui usage, Qt Creator (which is a "namespace aware" code base, see https://wiki.qt.io/Qt_In_Namespace) needed the QT_*_NAMESPACE for about 30 of its >200 .ui classes, and that in the presence of ~680 places where it was needed for other reasons. That's probably because we went out of our way to explicitly add a namespace to the types in the ui file. If it had been considered a problem at the time, we'd probably had the uic flag for 13 years or so... There are various bug reports along the lines of https://bugreports.qt.io/browse/QTCREATORBUG-19590, which we basically ignored. Christian ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
