Re: semicolons and the policy that was none
Le mercredi 10 août 2022 à 3:57 PM, Harald Sitter a écrit : > Aloha, > > Someone recently dug up this page from 2012 > > https://community.kde.org/Plasma/QMLStyle#JS_Code_Blocks > > First I'd like to point out that this page isn't a policy page, if it > was meant to be then it needs to be linked on the policies page and > supposedly somehow agreed upon, which I don't recall this one being > (but then I wasn't really following plasma 10 years ago). > > Secondly, can we clarify our stance on semicolons? > > a) we don't care, do whatever you feel like but be consistent with > your surrounding > b) use semicolons never [*unless required] > c) use semicolons always > d) use semicolons sometimes [*define sometimes] > > Please cast votes I would vote for c, it's more consistent with C++ and avoids some rare issues where removing the semicolon creates issues. This is what I'd been already doing for the app I maintain. Cheers, Carl PS: speaking of outdated policies, we ought to maybe revisit this one https://community.kde.org/Policies/Packaging_Policy since we provide binary packages in some cases now and we should probably also try to enforce this one https://community.kde.org/Frameworks/Frameworks_Documentation_Policy more often in kirigami and plasma frameworks > > Please cast votes > > I vote for a) or b) because the point of having a policy on this > eludes me entirely > > HS
Re: semicolons and the policy that was none
I don't really care as long as it's not a) because the surroundings are already inconsistent and it would be a mess. b) would be simplest and require fewer physical keypresses so I guess I *slightly* lean in that direction. Nate On 8/10/22 07:57, Harald Sitter wrote: Aloha, Someone recently dug up this page from 2012 https://community.kde.org/Plasma/QMLStyle#JS_Code_Blocks First I'd like to point out that this page isn't a policy page, if it was meant to be then it needs to be linked on the policies page and supposedly somehow agreed upon, which I don't recall this one being (but then I wasn't really following plasma 10 years ago). Secondly, can we clarify our stance on semicolons? a) we don't care, do whatever you feel like but be consistent with your surrounding b) use semicolons never [*unless required] c) use semicolons always d) use semicolons sometimes [*define sometimes] Please cast votes I vote for a) or b) because the point of having a policy on this eludes me entirely HS
Re: semicolons and the policy that was none
Am 2022-08-10 15:57, schrieb Harald Sitter: Aloha, Someone recently dug up this page from 2012 https://community.kde.org/Plasma/QMLStyle#JS_Code_Blocks First I'd like to point out that this page isn't a policy page, if it was meant to be then it needs to be linked on the policies page and supposedly somehow agreed upon, which I don't recall this one being (but then I wasn't really following plasma 10 years ago). Secondly, can we clarify our stance on semicolons? a) we don't care, do whatever you feel like but be consistent with your surrounding b) use semicolons never [*unless required] c) use semicolons always d) use semicolons sometimes [*define sometimes] Please cast votes I vote for b) I think its what people have been using recently (and a not entirely good reason, I think it looks better and writes more easily) I vote for a) or b) because the point of having a policy on this eludes me entirely HS
semicolons and the policy that was none
Aloha, Someone recently dug up this page from 2012 https://community.kde.org/Plasma/QMLStyle#JS_Code_Blocks First I'd like to point out that this page isn't a policy page, if it was meant to be then it needs to be linked on the policies page and supposedly somehow agreed upon, which I don't recall this one being (but then I wasn't really following plasma 10 years ago). Secondly, can we clarify our stance on semicolons? a) we don't care, do whatever you feel like but be consistent with your surrounding b) use semicolons never [*unless required] c) use semicolons always d) use semicolons sometimes [*define sometimes] Please cast votes I vote for a) or b) because the point of having a policy on this eludes me entirely HS
Re: testing UIs and improving a11y all at once!
Cool initiative! I also could recommend similar projects related to Qt, UI and Appium-based testing to take a look for a reference. It's from the local company which maintains Sailfish fork called Aurora here at github: https://github.com/omprussia - appium — Appium patch to add an additional platform to the platforms list - appium-aurora-driver — a js-based driver for Appium (that later could be used via http from the python for example) - appium-aurora — alpine and ubuntu Dockerfiles to reproduce - aurora-test-example — python test example (Aurora-specific) - qapreload — appium-related library that could be injected into the Qt-based application for tests automation - qainspector — Qt/QML GUI client to be used with qapreload library to inspect elements tree of a Qt-based application ср, 10 авг. 2022 г. в 13:47, Nicolas Fella : > Am 10.08.22 um 12:29 schrieb Harald Sitter: > > Servus, > > > > A while ago I prototyped a "new" approach to UI testing and I'm > > wondering if there's general interest in doing more Plasma testing > > using it. I'm able to invest time in polishing the experience for us. > > > > Very rough prototype: > https://invent.kde.org/sitter/selenium-webdriver-at-spi > > > > The testing is run through the accessibility API we have on Linux > > https://www.freedesktop.org/wiki/Accessibility/AT-SPI2/ as well as the > > testing API selenium https://www.selenium.dev/ respectively the more > > specific appium https://appium.io/ > > > > Architecturally appium is an extension to selenium and selenium is a > > client-server system where the client is the test and the server is a > > so called webdriver. Webdriver is a standardized well-defined API of > > various UI interactions https://www.w3.org/TR/webdriver/ and we'd > > implement one based on the a11y APIs (the feature sets match fairly > > well). > > > > Since selenium has wide spread use across the industry we get to use > > excellent tooling on the client without any extra work from us. And > > because it is so wide spread the stuff is generally very well > > maintained. All we need to maintain is the webdriver that interacts > > with the a11y API. > > > > The way this type of testing works is by UI interaction and state > > validation. There is a kcalc test available in the prototype repo [1] > > - the test operates the various UI elements to perform a calculation > > and then checks that the output UI element contains the expected > > value. > > > > A simple plasma test might open kickoff, and launch one of the > > favorites, then validate that indeed a new window has opened. > > > > Since all this is driven by the a11y API there is the additional > > advantage of making us notice a11y problems and deal with them, > > resulting in bettery a11y support in the long run. Two birds, one > > stone! > > > > What do you reckon? > > > > [1] > https://invent.kde.org/sitter/selenium-webdriver-at-spi/-/blob/91486b50995ade23c6b03a54f77347c263c2f03a/calculatortest.py > > > > HS > > +energy-efficie...@kde.org > > Servus Harald, > > that looks very cool! > > It could also come in handy for energy consumption measurements where we > need an automated and predictable way to emulate user interaction. > > The idea of using a11y API for that came up, but AFAIK there's no work > to actually do it on our side. > > That's three birds one stone I guess? > > Cheers > > Nico > > > PS: I pondered about different ways to do GUI automation for energy > consumption measurements in my master thesis recently, but I left the > a11y way for future work. If you are interested you can find the thesis > at https://nx9294.your-storageshare.de/s/PDQK4DEyPMW8AHM > > > > >
Re: testing UIs and improving a11y all at once!
Am 10.08.22 um 12:29 schrieb Harald Sitter: Servus, A while ago I prototyped a "new" approach to UI testing and I'm wondering if there's general interest in doing more Plasma testing using it. I'm able to invest time in polishing the experience for us. Very rough prototype: https://invent.kde.org/sitter/selenium-webdriver-at-spi The testing is run through the accessibility API we have on Linux https://www.freedesktop.org/wiki/Accessibility/AT-SPI2/ as well as the testing API selenium https://www.selenium.dev/ respectively the more specific appium https://appium.io/ Architecturally appium is an extension to selenium and selenium is a client-server system where the client is the test and the server is a so called webdriver. Webdriver is a standardized well-defined API of various UI interactions https://www.w3.org/TR/webdriver/ and we'd implement one based on the a11y APIs (the feature sets match fairly well). Since selenium has wide spread use across the industry we get to use excellent tooling on the client without any extra work from us. And because it is so wide spread the stuff is generally very well maintained. All we need to maintain is the webdriver that interacts with the a11y API. The way this type of testing works is by UI interaction and state validation. There is a kcalc test available in the prototype repo [1] - the test operates the various UI elements to perform a calculation and then checks that the output UI element contains the expected value. A simple plasma test might open kickoff, and launch one of the favorites, then validate that indeed a new window has opened. Since all this is driven by the a11y API there is the additional advantage of making us notice a11y problems and deal with them, resulting in bettery a11y support in the long run. Two birds, one stone! What do you reckon? [1] https://invent.kde.org/sitter/selenium-webdriver-at-spi/-/blob/91486b50995ade23c6b03a54f77347c263c2f03a/calculatortest.py HS +energy-efficie...@kde.org Servus Harald, that looks very cool! It could also come in handy for energy consumption measurements where we need an automated and predictable way to emulate user interaction. The idea of using a11y API for that came up, but AFAIK there's no work to actually do it on our side. That's three birds one stone I guess? Cheers Nico PS: I pondered about different ways to do GUI automation for energy consumption measurements in my master thesis recently, but I left the a11y way for future work. If you are interested you can find the thesis at https://nx9294.your-storageshare.de/s/PDQK4DEyPMW8AHM
testing UIs and improving a11y all at once!
Servus, A while ago I prototyped a "new" approach to UI testing and I'm wondering if there's general interest in doing more Plasma testing using it. I'm able to invest time in polishing the experience for us. Very rough prototype: https://invent.kde.org/sitter/selenium-webdriver-at-spi The testing is run through the accessibility API we have on Linux https://www.freedesktop.org/wiki/Accessibility/AT-SPI2/ as well as the testing API selenium https://www.selenium.dev/ respectively the more specific appium https://appium.io/ Architecturally appium is an extension to selenium and selenium is a client-server system where the client is the test and the server is a so called webdriver. Webdriver is a standardized well-defined API of various UI interactions https://www.w3.org/TR/webdriver/ and we'd implement one based on the a11y APIs (the feature sets match fairly well). Since selenium has wide spread use across the industry we get to use excellent tooling on the client without any extra work from us. And because it is so wide spread the stuff is generally very well maintained. All we need to maintain is the webdriver that interacts with the a11y API. The way this type of testing works is by UI interaction and state validation. There is a kcalc test available in the prototype repo [1] - the test operates the various UI elements to perform a calculation and then checks that the output UI element contains the expected value. A simple plasma test might open kickoff, and launch one of the favorites, then validate that indeed a new window has opened. Since all this is driven by the a11y API there is the additional advantage of making us notice a11y problems and deal with them, resulting in bettery a11y support in the long run. Two birds, one stone! What do you reckon? [1] https://invent.kde.org/sitter/selenium-webdriver-at-spi/-/blob/91486b50995ade23c6b03a54f77347c263c2f03a/calculatortest.py HS
