1. 24 Jun, 2020 3 commits
  2. 21 Jun, 2020 4 commits
    • Anders Jonsson's avatar
      Update Swedish translation · e3085c9d
      Anders Jonsson authored
      e3085c9d
    • Jehan's avatar
      app, libgimp: protect a bit GDK X Window calls. · 33520a54
      Jehan authored
      The GDK_WINDOWING_X11 build-time macro check is not enough as GDK can be
      built with both X11 and Wayland backends. We need to add a runtime check
      of the type of display.
      33520a54
    • Jehan's avatar
      NEWS: update. · 95454060
      Jehan authored
      Maybe we should also add some details about the API update, but so much
      has been changed already. Maybe later…
      95454060
    • Jehan's avatar
      app: [Wayland] fix invalid preedit range in text tool. · 2ae1ab50
      Jehan authored
      So it seems that pango_attr_iterator_range() could return G_MAXINT for
      a Pango attribute when it is at the end of the preedit string. Looking
      at Pango code, I see they initialize the attribute end property to
      PANGO_ATTR_INDEX_TO_TEXT_END (G_MAXUINT), later clamped to G_MAXINT by
      pango_attr_iterator_range(). So I guess for the specific case where we
      are at the text end, it is normal. Only weird thing is that this didn't
      happen at all on X11, only in Wayland.
      
      So let's do our own pre-check. Also double the check by adding a UTF-8
      validation.
      
      This fixes preedit text not being displayed and the following warning:
      
      > Gtk-CRITICAL **: 12:31:25.118: gtk_text_buffer_emit_insert: assertion 'g_utf8_validate (text, len, NULL)' failed
      
      Even worse, this was potentially an out-of-range reading, though
      fortunately checked early enough.
      2ae1ab50
  3. 18 Jun, 2020 8 commits
  4. 17 Jun, 2020 12 commits
  5. 16 Jun, 2020 4 commits
  6. 15 Jun, 2020 3 commits
  7. 14 Jun, 2020 3 commits
  8. 13 Jun, 2020 3 commits
    • Jehan's avatar
      app: remove the "Keys" list in the Input Device editor. · f0281e14
      Jehan authored
      After discussion with Carlos Garnacho, we came to the conclusion this
      list is a useless feature. Basically what we call "input device" here is
      pretty much "pointer device" only. We are indeed explicitly ignoring any
      device identified as GDK_SOURCE_KEYBOARD, leaving us only with various
      types of pointer devices (and pads actually, which maybe we should also
      ignore in fact).
      Such devices don't usually come with "keys", only "buttons". And in rare
      cases of very weird devices coming with both buttons and keys, they will
      usually identify as 2 separate devices (a pointer device and a keyboard
      one) anyway, in Carlos experience, so we would still wouldn't have
      access to the real keys anyway.
      
      Moreover these keys were not only useless, but also sometimes confusing,
      because some pointer devices would actually list keys, but then if you
      tried to map some key event, it would not do anything (as they are not
      real keys). The tablets I was testing with were such, reporting hundreds
      of keys which do nothing and only confused the hell out of me.
      Carlos says it probably means that the tablet drivers send bogus data of
      key descriptions (so a bug in the driver, harmless yet still confusing).
      
      So let's just get rid of this key list as our tablet expert says these
      are bogus and let's see if anyone ever reports feature loss of some
      extra weird pointing device which one would have used in GIMP while
      mapping keys. Note that I leave the concept of keys inside
      GimpDeviceInfo for now (only removing the widget part listing these)
      just in case we realize we have to bring these back (less chance of code
      conflict in the future when reverting the small GUI commit). But chances
      are high that we will have to clean GimpDeviceInfo too and just get rid
      of key code there.
      f0281e14
    • Jehan's avatar
      app: Input Devices "Reset" button should actually reset to defaults. · 4def457c
      Jehan authored
      In other dialogs, it is not a revert to how it was before opening the
      dialog, but a reset to default settings.
      To just revert to dialog opening values, we can just use "Cancel" and
      reopen the dialog (a bit cumbersome, but not something done often
      anyway).
      
      Currently what "Reset" does is to set back the device mode and any
      customized axe curve. It doesn't touch customized keys, but these will
      disappear anyway in a further commit.
      4def457c
    • Michael Schumacher's avatar