GTK 2020 Hackfest notes

Tuesday

No notes from Tuesday

Wednesday

Carlos continued to work on porting text handles to use a popover. Matthias continued css performance tweaks and finished a dnd blog post. Emmanuele woked on ci and documentation builds.

Decisions:

  • we probably don't need a manual menu creation api
  • kill the simple search engine, rely exclusively on system indexers for recursive search
  • move primary monitor and workarea apis to the x11 backend
  • make the emoji chooser public
  • Emmanuele is rebasing the shortcuts branch

Thursday

A11y day one. We spent the morning walking through using a11y tools in practice.

Ideas:

  • Take opportunity of gtk4 to change some basic designs, notably the current possibilities of global functionalities. Necessary for sandboxing untrusted applications, etc.
    • instead of global accessibility bus, peer2peer connections between application and AT
    • for each window, the compositor hands a fd to AT
    • different AT get separate connections
    • on X11 we'd like something like this too, see how to pass an fd, possibly through dbus

    • AT can discuss (for e.g. cooperation between speech & zoom) on a bus

    • embedding like XEmbed will never be a thing anymore
  • Information can't come only from the application, but also compositor, AT side has to cope with it (even if implementation stuffed in libatspi)
  • Authorizing access:
    • when started by compositor, trusted
    • when started by hand, if trusted path (/usr/bin, /usr/local/bin), trusted
    • otherwise, ask confirmation (which needs to be accessible)
    • a developer who knows the risks can enable for all applications, or his AT build tree
  • no global coordinates
    • AT can ask the compositor which window has the mouse
    • AT can ask the application which Accessible is behind the mouse
    • AT can ask the compositor which window has some coordinates (whatever that may mean however that is obtained, even if rendering is done on e.g. a sphere), and get the translated relative coordinates in the application window
    • AT can ask the application which Accessible is at some relative coordinate
    • AT can ask the application to notify when the mouse moves to another Accessible
    • AT can ask to embed in that notification various information (basically, answers to IPCs it would make), so that the notification is just one trip
  • zero-copy optimisation?
    • probably not useful, we shouldn't have that much information to send, we won't have ways to convey it all to the user, it should be "compressed" on the application side before sending (e.g. "1000 mails in inbox", not the 1000 events)
  • key events
    • compositor / xinput2 can provide with the key events to avoid the toolkit having to send them
    • AT needs to translate keycode to keysym to be able to pronounce it
    • per-application layout is theoretically possible, but compositor can tell AT which window uses what
    • XCompose / input method goes through the compositor, so it can also tell AT about input expansions
    • implementation in registryd to hide away the X11 vs wayland details from AT
      • take the opportunity to drop unused details, basically keep only modifier + keysym
  • orca shortcuts
    • orca to register what it wants to catch
      • With XInput2, can XIGrabKeycode the "orca" modifier (capslock / insert), and then XIGrabKeycode the possible shortcuts
      • when orca enters the navigation mode (simple shortcut without the orca modifier, extremely useful for browsing a webpage), can XIGrabKeycode what it wants
      • With Wayland, have to register to the compositor for the desired shortcuts
        • new protocol to be devised
  • compositor-side implementations
    • making them libraries so that all compositors can share the implementation
  • dasher
    • should be an input method
  • go through the IPCs to
    • drop elder ones
    • reduce chattiness

      • e.g. drop/compress addchild events, we most often don't need the detail, at best the number of additions, at best want to know about a new tab, but not a flurry of mails -> collapse on the application side

  • Revamp ATK completely
    • basically drop at-spi2-atk, and even integrate into gtk
    • generate it as much as possible directly from IDL
    • but mxake sure applications can make their own widgets accessible
    • including when it creates it from scratch

  • Add an 'a11y check' command to gtk-builder-tool that would warn about various a11y problems, such as missing / mismatched labels, etc. There is a tool like that written in python, already used by libreoffice and MATE CI: gla11y, https://github.com/hypra/gla11y , which could be integrated e.g. in the accerciser repository

Friday

A11y day two:

  • went through TODO list, agreed on some more details, put names
  • discussed a few bugs/merge requests
    • socket/plug
    • scrollTo / scrollToPoint
    • Pressing tab in name part of "save as" dialog bo
    • files showing up progressively in "open" box
    • "open" / "save as": name left panel as "places" panel
    • "places" panel: make tab switch to the list of files rather than moving between places, otherwise the user is stuck in the places panel, can not escape from it.
    • more generally, be sure to be able to predict what a keypress will achieve
    • arrows / tab / F6 should ideally be always completely separate spaces
    • can probably write a checker for this, to at least avoid "stuck" places, Hypra plans to do this
    • font chooser, make font sample smaller, otherwise with zoom it's way too big
    • theming management with css

TODO a11y

This was moved to Accessibility/TODO

Hackfests/GTK2020/Notes (last edited 2020-06-23 17:00:22 by SamuelThibault)