1. 07 Jan, 2019 16 commits
  2. 05 Jan, 2019 4 commits
    • Ondrej Holy's avatar
      user-account: Use the same Categories as other panels · a800e975
      Ondrej Holy authored
      gnome-user-accounts-panel.desktop has some differences in "Categories" in
      comparison to other desktop files provided by gnome-control-center for no
      obvious reason.
      
      Add "GNOME" and "GTK" categories, which are used in all other desktop files.
      
      Remove "System" and use just "Settings" main category. This among others
      prevents the following output from desktop-file-validate:
      
      /usr/share/applications/gnome-user-accounts-panel.desktop: hint: value
      "System;Settings;X-GNOME-Settings-Panel;X-GNOME-DetailsSettings;" for key
      "Categories" in group "Desktop Entry" contains more than one main
      category; application might appear more than once in the application menu
      
      All other desktop files uses just the "Settings" main category.
      
      But maybe this is totally useless patch, because it seems that GNOME Shell
      do not care about the most of categories and GNOME Classic do not show those
      desktop files in menus at all.
      a800e975
    • Jeremy Bicha's avatar
      datetime: Use accessible-description instead of -name for Hour & Minute · 021140d8
      Jeremy Bicha authored
      In my testing, default orca didn't seem to read the "Hour" or "Minute"
      words when we used accessible-name but it does work with
      accessible-description.
      
      This is the only place we used accessible-name in gnome-control-center
      but we use accessible-description in a few other places.
      021140d8
    • Jeremy Bicha's avatar
      7cac1854
    • Carlos Garnacho's avatar
      wacom: Always try to add the stylus page UI on proximity · a4cc9d35
      Carlos Garnacho authored
      This used to be done only if the stylus was "brand new", because pages for
      previously known styli are added when the tablet is detected/plugged. There
      are however situations where this may break: eg. the stylus was previously
      known through a tablet that is not plugged ATM. The tool is however "not
      new" so no UI is added for it.
      
      We should try to add the stylus invariably on proximity, add_stylus_page()
      ensures there is only one page per tool anyway.
      
      Closes: #315
      a4cc9d35
  3. 03 Jan, 2019 2 commits
  4. 02 Jan, 2019 1 commit
  5. 29 Dec, 2018 1 commit
  6. 28 Dec, 2018 1 commit
  7. 25 Dec, 2018 1 commit
  8. 18 Dec, 2018 3 commits
    • Peter Hutterer's avatar
      wacom: ignore the wacom driver's touch tool type · def41bc0
      Peter Hutterer authored
      When the wacom driver handles the touch device, we get a tool id of 0x3. Let's
      ignore that because we don't need a tool for the touch node.
      
      Ideally we should be able to rely on the GDK tool type but that one is always
      GDK_DEVICE_TOOL_TYPE_UNKNOWN see
      gtk!453
      
      A GTK bug (also fixed in that MR) prevents the tool id from updating.
      Until that GTK bug is fixed the pen will only be detected if it is the first
      event from this physical device. If the touch node sends an event before the
      pen, the pen won't be detected.
      def41bc0
    • Peter Hutterer's avatar
      wacom: Only write a generic pen to the keyfile when it's previously unseen · a82b9753
      Peter Hutterer authored
      When we bring a generic pen (serial 0) into proximity, the tool is initialized
      as "generic" and mapped to the current tablet. This is then written out into
      the keyfile, so we end up with something like:
      
      [056a:00d1]
      Styli=generic;
      
      On the next g-c-c start the generic pen is pre-loaded from the keyfile but not
      yet associated with the tablet. When the pen gets into proximity the
      association was handled like a completely new pen, thus triggering a key file
      entry again. Eventually, our styli list looked like this:
      
      [056a:00d1]
      Styli=generic;generic;generic;generic;generic;generic;
      
      Fix this by remembering whether we freshly initialized the tool or whether it
      was already known. Since we can only have one generic tool per tablet (because
      we wouldn't notice the difference between two physical tools) we just skip the
      write of the keyfile.
      
      Fixes #313
      a82b9753
    • Peter Hutterer's avatar
      wacom: Map wacom-driver-specific generic IDs to 0 · d925ea3c
      Peter Hutterer authored
      The xf86-input-wacom driver doesn't use 0 for tools that do not have an id or
      serials. Serials default to 1, and the tool id is either 0x2 for stylus or 0xa
      for eraser, see xf86WacomDefs.h, the defines for STYLUS_DEVICE_ID and
      ERASER_DEVICE_ID.
      
      libwacom uses 0xfffff and 0xffffe for the generic pens and all the lookup code
      we have in the panel is designed for a serial/tool id of 0. So let's just map
      the wacom driver IDs to 0 at the only transition point between Gdk and our
      panel.
      
      No devices with serials 0 or hw ids 2/10 exist, so this shouldn't have side
      effects. This only affects X + xf86-input-wacom.
      d925ea3c
  9. 11 Dec, 2018 6 commits
  10. 09 Dec, 2018 1 commit
  11. 08 Dec, 2018 1 commit
  12. 07 Dec, 2018 3 commits