Re: Implementing accessibility non-regression check tool

On Sat, 2019-04-20 at 10:33 +0200, Samuel Thibault wrote: > ...as discussed before we could as well > just put the suppression rules in > solenv/sanitizers/ui/modules/scalc.false > to tell that there is nothing to fix here Seeing as I've being putting the suppressions in foo.supr its just a

Re: Implementing accessibility non-regression check tool

Hello Caolán, It seems there is an unwanted effect: for instance 8d526da34810 ("weld ScChiSquareTestDialog") turns input-range-button and output-range-button from a foruilo-RefButton to a GtkButton, and a gla11y warning shows up. In solenv/gbuild, gla11y is told that no labelling warning should

Re: Implementing accessibility non-regression check tool

Jan-Marek Glogowski, le mer. 29 août 2018 06:53:52 +, a ecrit: > Am August 28, 2018 4:04:37 PM UTC schrieb Samuel Thibault > : > >Samuel Thibault, le lun. 12 févr. 2018 15:30:59 +0100, a ecrit: > >> - At some point we'll get confident that we won't introduce other > >> big classes of warnings

Re: Implementing accessibility non-regression check tool

Am 29.08.2018 um 09:33 schrieb Samuel Thibault: > Jan-Marek Glogowski, le mer. 29 août 2018 06:53:52 +, a ecrit: >> Am August 28, 2018 4:04:37 PM UTC schrieb Samuel Thibault >> : >>> Samuel Thibault, le lun. 12 févr. 2018 15:30:59 +0100, a ecrit: - At some point we'll get confident

Re: Implementing accessibility non-regression check tool

Am August 28, 2018 4:04:37 PM UTC schrieb Samuel Thibault : >Samuel Thibault, le lun. 12 févr. 2018 15:30:59 +0100, a ecrit: >> - At some point we'll get confident that we won't introduce other >> big classes of warnings over hundreds of .ui files. That's the point >> where we can say "ok, let's

Re: Implementing accessibility non-regression check tool

Hello, Samuel Thibault, le lun. 12 févr. 2018 15:30:59 +0100, a ecrit: > - At some point we'll get confident that we won't introduce other > big classes of warnings over hundreds of .ui files. That's the point > where we can say "ok, let's start fixing the existing issues over > all .ui files

Re: Implementing accessibility non-regression check tool

Hi Eike, On Wed, Feb 28, 2018 at 05:27:43PM +0100, Eike Rathke wrote: > The initial reason (correct if I'm wrong) was that the checker could be > used standalone and work on any glade .ui file, not even related to > LibreOffice, and thus be used by any project to raise a11y

Re: Implementing accessibility non-regression check tool

Hi Miklos, On Wednesday, 2018-02-28 10:42:07 +0100, Miklos Vajna wrote: > If I focus on maintenance, I would just use the same XML parsing > infrastructure that we use everywhere else for file import purposes, and > the checker would be in C++. We do report line and column numbers when > ODF

Re: Implementing accessibility non-regression check tool

Hi, On Tue, Feb 27, 2018 at 02:57:23PM +0100, Samuel Thibault wrote: > It's interesting. One frightening thing however is "we assume the > default XML parser which is expat", and the _start_list (which should > actually be _start with python3) and _end hooks are not even

Re: Implementing accessibility non-regression check tool

On 27.02.2018 15:23, Michael Stahl wrote: i'm wondering, not having looked at your tool: if it doesn't print line numbers, is it easy to figure out which XML element it warns about? would the element contain some unique text or have a unique identifying attribute? line number is just one way

Re: Implementing accessibility non-regression check tool

Michael Stahl, on mar. 27 févr. 2018 15:23:43 +0100, wrote: > i'm wondering, not having looked at your tool: if it doesn't print line > numbers, is it easy to figure out which XML element it warns about? > > would the element contain some unique text or have a unique identifying > attribute? It

Re: Implementing accessibility non-regression check tool

On 27.02.2018 14:57, Samuel Thibault wrote: > Hello, > > Miklos Vajna, on mar. 27 févr. 2018 14:08:33 +0100, wrote: >> On Thu, Feb 22, 2018 at 05:22:26PM +0100, Samuel Thibault >> wrote: >>> An issue with these is that they do not keep source line numbers of the >>> nodes.

Re: Implementing accessibility non-regression check tool

Hello, Miklos Vajna, on mar. 27 févr. 2018 14:08:33 +0100, wrote: > On Thu, Feb 22, 2018 at 05:22:26PM +0100, Samuel Thibault > wrote: > > An issue with these is that they do not keep source line numbers of the > > nodes. That's really concerning for providing useful

Re: Implementing accessibility non-regression check tool

Hi, On Thu, Feb 22, 2018 at 05:22:26PM +0100, Samuel Thibault wrote: > An issue with these is that they do not keep source line numbers of the > nodes. That's really concerning for providing useful information to > the programmer. Does

Re: Implementing accessibility non-regression check tool

On 24.02.2018 03:29, Samuel Thibault wrote: Now, it happens that the lxml build on windows seems hard, it's apparently not actually supported by upstream :/ One thing that could be done is to make gla11y work with either python's implementation and lxml's implementation (that's really easy),

Re: Implementing accessibility non-regression check tool

Samuel Thibault, on jeu. 22 févr. 2018 17:22:26 +0100, wrote: > Michael Stahl, on jeu. 22 févr. 2018 16:59:21 +0100, wrote: > > On 22.02.2018 16:36, Stephan Bergmann wrote: > > > I was more hoping that there might be an established plain Python option > > > for XML processing? > > > > FWIW,

Re: Implementing accessibility non-regression check tool

Khaled Hosny, on sam. 24 févr. 2018 01:02:29 +0200, wrote: > On Thu, Feb 22, 2018 at 04:13:42PM +0100, Samuel Thibault wrote: > > Stephan Bergmann, on jeu. 22 févr. 2018 15:49:40 +0100, wrote: > > > That means external/lxml will need to: > > > > > > * build against and run with either the system

Re: Implementing accessibility non-regression check tool

On Thu, Feb 22, 2018 at 04:13:42PM +0100, Samuel Thibault wrote: > Stephan Bergmann, on jeu. 22 févr. 2018 15:49:40 +0100, wrote: > > That means external/lxml will need to: > > > > * build against and run with either the system Python or the locally-built > > one from external/python3, > > > > *

Re: Implementing accessibility non-regression check tool

Stephan Bergmann, on jeu. 22 févr. 2018 16:36:44 +0100, wrote: > I have e.g. no idea whether/how > it's possible to tell that lxml setup.py which libxml2/libxslt to use. That was indeed a missing part in my patch, it's a mere setup.py option which does work fine. > (And whether e.g. the

Re: Implementing accessibility non-regression check tool

Michael Stahl, on jeu. 22 févr. 2018 16:59:21 +0100, wrote: > On 22.02.2018 16:36, Stephan Bergmann wrote: > > I was more hoping that there might be an established plain Python option > > for XML processing? > > FWIW, there is at least xml.etree.ElementTree and xml.dom.minidom in the > CPython

Re: Implementing accessibility non-regression check tool

On 22.02.2018 16:36, Stephan Bergmann wrote: > I was more hoping that there might be an established plain Python option > for XML processing? FWIW, there is at least xml.etree.ElementTree and xml.dom.minidom in the CPython bundled libs.

Re: Implementing accessibility non-regression check tool

On 22.02.2018 16:13, Samuel Thibault wrote: Stephan Bergmann, on jeu. 22 févr. 2018 15:49:40 +0100, wrote: That's four different ways how to build external/lxml, and slightly more different ways (using the system lxml versus external/lxml) how to run the gla11y tool in

Re: Implementing accessibility non-regression check tool

Stephan Bergmann, on jeu. 22 févr. 2018 15:49:40 +0100, wrote: > That means external/lxml will need to: > > * build against and run with either the system Python or the locally-built > one from external/python3, > > * build against and run with either the system libxml2/libxslt or the >

Re: Implementing accessibility non-regression check tool

I'm not sure basing this gla11y tool on lxml () is a good choice: "The lxml XML toolkit is a Pythonic binding for the C libraries libxml2 and libxslt." () Different LO builds have the choice/need to use either a system Python or a locally-built one from

Re: Implementing accessibility non-regression check tool

On 16.02.2018 09:55, Samuel Thibault wrote: Miklos Vajna, on ven. 16 févr. 2018 09:24:38 +0100, wrote: On Thu, Feb 15, 2018 at 06:58:42PM +0100, Samuel Thibault wrote: For now I have patched the build system to call the tool as the attached patch does, does it look OK?

Re: Implementing accessibility non-regression check tool

On 16.02.2018 09:55, Samuel Thibault wrote: Miklos Vajna, on ven. 16 févr. 2018 09:24:38 +0100, wrote: On Thu, Feb 15, 2018 at 06:58:42PM +0100, Samuel Thibault wrote: For now I have patched the build system to call the tool as the attached patch does, does it look OK?

Re: Implementing accessibility non-regression check tool

Miklos Vajna, on ven. 16 févr. 2018 09:24:38 +0100, wrote: > On Thu, Feb 15, 2018 at 06:58:42PM +0100, Samuel Thibault > wrote: > > For now I have patched the build system to call the tool as the attached > > patch does, does it look OK? (basically it's called along building

Re: Implementing accessibility non-regression check tool

Hi Samuel, On Thu, Feb 15, 2018 at 06:58:42PM +0100, Samuel Thibault wrote: > For now I have patched the build system to call the tool as the attached > patch does, does it look OK? (basically it's called along building the > image list in the UIC rule, I need to doublecheck

Re: Implementing accessibility non-regression check tool

Hello, For now I have patched the build system to call the tool as the attached patch does, does it look OK? (basically it's called along building the image list in the UIC rule, I need to doublecheck the clean rule, but the build rule works fine) Samuel diff --git a/solenv/gbuild/Helper.mk

Re: Implementing accessibility non-regression check tool

Hi Samuel, On Monday, 2018-02-12 15:30:59 +0100, Samuel Thibault wrote: > [... a nice plan ...] > What do people think about this plan? Makes perfectly sense to me. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GPG key 0x6A6CD5B765632D3A - 2265 D7F3

Re: Implementing accessibility non-regression check tool

Hello, So there was a presentation about this tool at FOSDEM, the video recording is already available on https://fosdem.org/2018/schedule/event/ode_testing/ Basically, the tool (improved a bit since FOSDEM) is currently reporting about 8000 warnings, i.e. 8 per file on average. I have attached

Re: Implementing accessibility non-regression check tool

Hi Samuel, On Thu, Jan 25, 2018 at 05:07:44PM +0100, Samuel Thibault wrote: > Is there a particular codestyle that we should follow? I didn't find > particular codestyle in various python script in LO, probably because > the python syntax already imposes quite a

Re: Implementing accessibility non-regression check tool

Hello, Caolán McNamara, on jeu. 25 janv. 2018 15:31:34 +, wrote: > FWIW, there is a little script in LibreOffice as bin/lint-ui.py which > checks for various things. It doesn't do the above, but it does at > least demo some simple .ui parsing. Thanks! Is there a particular codestyle that we

Re: Implementing accessibility non-regression check tool

On Thu, 2018-01-18 at 12:36 +0100, Samuel Thibault wrote: > Hello, > > This is a small mail to briefly present the work we (Hypra) will be > doing for accessibility in LibreOffice. > > Basically, the idea is to design a tool which will check .ui files > for accessibility issues: missing

Re: Implementing accessibility non-regression check tool

On 01/18/2018 11:36 AM, Samuel Thibault wrote: > Basically, the idea is to design a tool which will check .ui files for > accessibility issues: missing relations between widgets and labels, > notably. The tool would just use libxml to parse the files and emit > warnings for the found issues.

Re: Implementing accessibility non-regression check tool

Samuel Thibault, on jeu. 18 janv. 2018 12:36:49 +0100, wrote: > We can discuss about it at the ESC call today. Ok, that mail didn't get to the list before the call, so it didn't get into the agenda and I didn't manage to speak in. We can probably start discussing what we can on this list, and