Re: [Development] Backwards compatibiltiy break in Qt 5.5
27.07.2015, 11:01, "NIkolai Marchenko" enmarantis...@gmail.com: Once we venture into the territory of debugging 50%+ non-latin, it will be impossible to extract any useful information from debug output at a glance. And that is the situation, where aforementioned flag to change the behaviour in one place will be VERY useful. Unlike your suggestion of fixing source code everywhere line by line.And users genrally know if they need to consider the case you are arguing about or not. qDebug is just a macro so you may override it:#define qDebug() qDebug() unescape It's a bit more tricky if you use it as both function and output stream, but it's still solvable by single header include. P.S. As a Russian speaker I prefer Thiago's solution, I've faced numerous times with ambiguous output of qDebug and even 'a' vs 'а' problem (which led to lots of text.toHex()) and I'm happy that it's finally solved. On Mon, Jul 27, 2015 at 8:58 PM, NIkolai Marchenko enmarantis...@gmail.com wrote:The problem with your approach to qDebug is that it only works well where most of the text is in English and only individual letters are unicode. Once we venture into the territory of debugging 50%+ non-latin, it will be impossible to extract any useful information from debug output at a glance.2015-07-27 20:25 GMT+03:00 Thiago Macieira thiago.macie...@intel.com:On Monday 27 July 2015 09:05:29 Thiago Macieira wrote: "а", which was the attack vector for homograph sites like pаypal.com or pаypаl.com or раураl.com or other permutations of the letters. A control Question: which of the three is the legit website? And what method did you use to find out?The following is an excerpt from the Japanese Wikipedia homepage just so that KMail will encode the email in Base64 instead of quoted-printable: 1988年10月に競走馬としてデビュー。翌1989年にアメリカ三冠のうち二冠（ケンタッキーダービー、プリークネスステークス）、さらにブリーダーズカップ・クラ シックを勝つなどG1を5勝する活躍を見せ、エクリプス賞年度代表馬に選ばれた。1990年に右前脚の靭帯を痛めて競走馬を引退。引退後は日本で種牡馬となり、初年度 産駒がデビューした翌年の1995年から13年連続で日本のリーディングサイアーを獲得。さらに中央競馬における種牡馬にまつわる記録を次々と更新した。サンデーサイ レンスを起点とするサイアーラインは日本競馬界における一大勢力となり、サンデーサイレンス系とも呼ばれる。幼少期は見栄えのしない容貌ゆえに買い手がつかず、生命に かかわる事態に見舞われながら競走馬、さらに種牡馬として成功した生涯は童話『みにくいアヒルの子』に例えられる。PS: if you've answered that you opened in the web browser, please send me your credit card number so I can credit you for $5. You may also want to talk to this prince who came into a fortune recently -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ,___Development mailing listDevelopment@qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development --Ruslan Nigmatullin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] XDG icon theme support
Hello, 30.03.2014, 16:56, Gladhorn Frederik frederik.gladh...@digia.com: A fix for this would certainly be appreciated. http://qt-project.org/wiki/Gerrit-Introduction Thanks, here are the commits: https://codereview.qt-project.org/82185 https://codereview.qt-project.org/82186 On Saturday 29. March 2014 14.56.16 Rex Dieter wrote: Ruslan Nigmatullin wrote: If the changes will be done and accepted is there any hope to have them in Qt 5.2.* It's a bug fix rather than a new feature, so yeah, I'd expect it could be included in a subsequent bugfix release (assuming there is one). There will be no more 5.2 releases. If you get the patch soon it might make it into 5.3.0. May be worth actually filing a bug to both highlight the the status of the bug and when the fix(es) land too. Yes, if you don't work on a fix yourself then you should file a bug. -- Rex Cheers, Frederik ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Ruslan Nigmatullin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] XDG icon theme support
Hi friends, Current Qt's implementation of QIcon::fromTheme violates xdg icon naming specification ( http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html ). By specification if icon drive-removable-media-usb is not found implementation should fallback to drive-removable-media and so on until the icon is not found. If icon is not found at this theme is should make lookup at parents' themes. The dash “-” character is used to separate levels of specificity in icon names, for all contexts other than MimeTypes. For instance, we use “input-mouse” as the generic item for all mouse devices, and we use “input-mouse-usb” for a USB mouse device. However, if the more specific item does not exist in the current theme, and does exist in a parent theme, the generic icon from the current theme is preferred, in order to keep consistent style. For example this makes possible to use most of icons provided by Oxygen theme (which has really specific icons like network-wireless-connected-50) with more generic fallbacks under with other themes (like network-wireless). In C++ the possible workaround is to use something like QIcon::fromTheme(network-wireless-connected-50, QIcon::fromTheme(network-wireless-connected. QIcon::fromTheme(network-wireless, QIcon::fromTheme(network but it's not the most efficient and elegant solution. And it still violates the specification in the case if: 1. Current theme contains icons network-wireless-connected-50 and network-wireless 2. Parent's theme contains icons network-wireless-connected-50 By specification current theme's network-wireless icon should be choosed, but not the parent's network-wireless-connected-50 for better user experience as current implementation does. Also the pain starts if one would decide to change the icons theme at runtime (i.e. by changing KDE's settings). Original icon's names are already lost at this point (as we iterated by prefixes until the valid icon) so invalid or no icon will be chosen after the theme change. In QML the situation is even worse, it's not possible at all to determine from QML if icon is correct one so it's totally impossible to do anything and it ruins my life :( Was this done specially or it should be considered as a bug? If the first option what was the main idea? I would like to implement the correct behavior by the following changes: 1. Never return fallback from QIcon::fromTheme if it is null. So it will be possible to show the icon once the correct theme will be shown. 2. Change the logic of QIconLoader::findIconHelper to fit the specification by adding check for fallback icons. If the changes will be done and accepted is there any hope to have them in Qt 5.2.* (so it will come once to Ubuntu Trusty)? -- Ruslan Nigmatullin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Keyboard shortcuts don't work in multi-language mode
Hello friends, https://bugreports.qt-project.org/browse/QTBUG-32274 is still actual (both for Qt 5.1.* and Qt 5.2.*, haven't tried Qt 5.3 beta yet, but I suppose there is no difference). Can somebody reopen it, please? I have no such rights or don't know how to actually do it. --Ruslan Nigmatullin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Windows Extras and Jump Lists
25.01.2013, 03:09, "Jake Thomas Petroules" jake.petrou...@petroules.com:Implementing something like QtDockTile is somewhat odd because the it was developed as a series of plugins with a single QDockTile API. I think the abstraction of these platform features into a single logical API is useful, however I'm not sure we can do that easily with the current QWindowsExtras / QMacExtras / QX11Extras trio. QDockTile as a class would have to go into QtGui to make proper use of that abstraction, but then you have the problem of backporting it to Qt 4. Or you could duplicate the header across all 3 libraries which isn't exactly ideal. I guess the best approach is to just forego having it as a single API and just have a series of individual classes for the functionality of each platform in each of the Q***Extras libraries. Hi Jake, QtDockTile is not something we want to bring to Qt, link to it was done only as example of the idea for windows implementation. QWindowsExtras should contain, as I suppose, API for JumpLists, TaskBar Icon and other windows-specific APIs, part of which is implemented as plugin for QtDockTile. By the way API for Unity should be provided by canonical in it's own repositories, as it's already done for indicators. --Ruslan Nigmatullin___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Playground: Crypto module
QMessageAuthenticationCode is ready: https://codereview.qt-project.org/44512 11.01.2013, 02:51, Richard Moore r...@kde.org: On 10 January 2013 22:32, Ruslan Nigmatullin euroeles...@yandex.ru wrote: 11.01.2013, 00:55, Richard Moore r...@kde.org: On 10 January 2013 20:48, Ruslan Nigmatullin euroeles...@yandex.ru wrote: 2. HMAC is unsupported, so it's usually impossible to use OAuth with hmac-authorization (like hmac(sha256)) Adding support for HMAC to QCryptographicHash would be pretty trivial. I don't see any reason why such a change would not be accepted. If it's fit logically into QCryptographicHash, there is no problem to implement it, I agree. Should I implement it as another one class, i.e. QMessageAuthenticationCode? I think a separate QMessageAuthenticationCode class is probably a better API. Cheers Rich. -- Ruslan Nigmatullin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Playground: Crypto module
Hi all, With Qt5 there are no Qt-based cryptographic interfaces now. There was an QCA for Qt3/Qt4, but it had over-engineered interface and a lot of bugs. So I would like to start Crypto module for Qt5 with convience crypto-methods (Qt-based wrappers for TLS/SSL encryption, SASL, AES/etc encryption, SHA/HMAC hashing, etc) and nice Qt-style API. It's proposed to use appropriate libraries like OpenSSL/cyrus-sasl/gnugp/etc. -- Ruslan Nigmatullin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Playground: Crypto module
Botan, as I see is C++ wrapper around OpenSSL itself. Qt already has OpenSSL dependency. What's are benefits of using it if Botan is just additional dependancy? Also neither Botan or OpenSSL have SASL and GPG support. 10.01.2013, 22:31, Konstantin Tokarev annu...@yandex.ru: 10.01.2013, 21:03, Ruslan Nigmatullin euroeles...@yandex.ru: Hi all, With Qt5 there are no Qt-based cryptographic interfaces now. There was an QCA for Qt3/Qt4, but it had over-engineered interface and a lot of bugs. So I would like to start Crypto module for Qt5 with convience crypto-methods (Qt-based wrappers for TLS/SSL encryption, SASL, AES/etc encryption, SHA/HMAC hashing, etc) and nice Qt-style API. It's proposed to use appropriate libraries like OpenSSL/cyrus-sasl/gnugp/etc. Qt Creator is using Botan library [1]. You may want to implement Qt-style wrapper for it. -- Regards, Konstantin -- Ruslan Nigmatullin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Playground: Crypto module
Qt misses some core features connected with TLS/hashing: 1. it's impossible to create unencrypted connection to server and initialize TLS encyption sometime afterwards (common usecase: connection to jabber server). 2. HMAC is unsupported, so it's usually impossible to use OAuth with hmac-authorization (like hmac(sha256)) That's why Qt supports nothing from my needs. Another one issue - Qt is sometimes shipped to some platforms with statically-linked OpenSSL, which makes nearly-to-impossible to use external libraries with OpenSSL as dependancy. 11.01.2013, 00:35, Richard Moore r...@kde.org: On 10 January 2013 17:03, Ruslan Nigmatullin euroeles...@yandex.ru wrote: Hi all, With Qt5 there are no Qt-based cryptographic interfaces now. There was an QCA for Qt3/Qt4, but it had over-engineered interface and a lot of bugs. So I would like to start Crypto module for Qt5 with convience crypto-methods (Qt-based wrappers for TLS/SSL encryption, SASL, AES/etc encryption, SHA/HMAC hashing, etc) and nice Qt-style API. It's proposed to use appropriate libraries like OpenSSL/cyrus-sasl/gnugp/etc. Qt already has support for TLS/SSL in qtnetwork, and I've already written https://gitorious.org/qt-certificate-addon/ to cover key and certificate generation (supports qt 4.x and qt5). SHA etc. are covered by QCryptographicHash (http://qt-project.org/doc/qt-5.0/qtcore/qcryptographichash.html) out of your list that really just leaves SASL and actual crypto algorithms like AES. I don't see any reason why those couldn't be supported by another two Qt addons, one for AES and one for SASL, though I'm unsure how much demand there is. Cheers Rich. -- Ruslan Nigmatullin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Playground: Crypto module
11.01.2013, 00:55, Richard Moore r...@kde.org: On 10 January 2013 20:48, Ruslan Nigmatullin euroeles...@yandex.ru wrote: Qt misses some core features connected with TLS/hashing: 1. it's impossible to create unencrypted connection to server and initialize TLS encyption sometime afterwards (common usecase: connection to jabber server). That's incorrect, you can do that (though personally I regard protocols that do this as broken). My fault, it really works( So there is one less QCA dependence, that's nice. 2. HMAC is unsupported, so it's usually impossible to use OAuth with hmac-authorization (like hmac(sha256)) Adding support for HMAC to QCryptographicHash would be pretty trivial. I don't see any reason why such a change would not be accepted. If it's fit logically into QCryptographicHash, there is no problem to implement it, I agree. Should I implement it as another one class, i.e. QMessageAuthenticationCode? That's why Qt supports nothing from my needs. Another one issue - Qt is sometimes shipped to some platforms with statically-linked OpenSSL, which makes nearly-to-impossible to use external libraries with OpenSSL as dependancy. I'm not aware of any platforms where we ship with a statically linked openssl. We dlopen it in the normal case, and link to it as normal with -openssl-linked. Cheers Rich. -- Ruslan Nigmatullin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
