1. 24 Sep, 2022 1 commit
  2. 11 May, 2022 1 commit
  3. 05 Jan, 2022 1 commit
  4. 22 May, 2021 1 commit
  5. 11 Mar, 2021 1 commit
  6. 15 Oct, 2020 1 commit
  7. 28 Jul, 2020 1 commit
    • Carlos Garnacho's avatar
      gdk: Conflate GDK devices · cab1dcb6
      Carlos Garnacho authored
      Make GdkEvents hold a single GdkDevice. This device is closer to
      the logical device conceptually, although it must be sufficient for
      device checks (i.e. GdkInputSource), which makes it similar to the
      physical devices.
      
      Make the logical devices have a more accurate GdkInputSource where
      needed, and conflate the event devices altogether.
      cab1dcb6
  8. 24 Jul, 2020 2 commits
  9. 24 Apr, 2020 1 commit
  10. 16 Apr, 2020 1 commit
    • Emmanuele Bassi's avatar
      Restructure the GdkEvent type hierarchy · f28aa1ba
      Emmanuele Bassi authored
      GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
      using a union of sub-types. This has always been problematic when it
      comes to implementing accessor functions: either you get generic API
      that takes a GdkEvent and uses a massive switch() to determine which
      event types have the data you're looking for; or you create namespaced
      accessors, but break language bindings horribly, as boxed types cannot
      have derived types.
      
      The recent conversion of GskRenderNode (which had similar issues) to
      GTypeInstance, and the fact that GdkEvent is now a completely opaque
      type, provide us with the chance of moving GdkEvent to GTypeInstance,
      and have sub-types for GdkEvent.
      
      The change from boxed type to GTypeInstance is pretty small, all things
      considered, but ends up cascading to a larger commit, as we still have
      backends and code in GTK trying to access GdkEvent structures directly.
      Additionally, the naming of the public getter functions requires
      renaming all the data structures to conform to the namespace/type-name
      pattern.
      f28aa1ba
  11. 07 Mar, 2020 1 commit
    • Timm Bäder's avatar
      padcontroller: Copy action entries · 049f8419
      Timm Bäder authored
      The label and action_name entries of GtkPadActionEntry are supposed to
      be const, so copy them into a private ActionEntryData struct that we
      later free.
      049f8419
  12. 21 Feb, 2020 3 commits
    • Matthias Clasen's avatar
      events: reorganize getters · b1eaa502
      Matthias Clasen authored
      Restructure the getters for event fields to
      be more targeted at particular event types.
      
      Update all callers, and replace all direct
      event struct access with getters.
      
      As a side-effect, this drops some unused getters.
      b1eaa502
    • Matthias Clasen's avatar
      Strip const from GdkEvent · 31bf9da6
      Matthias Clasen authored
      Events are refcounted structs, and we generally don't
      pass these as const.
      31bf9da6
    • Matthias Clasen's avatar
      Pass translated coordinates outside the event · dd251d85
      Matthias Clasen authored
      We want to make events readonly, so stop translating
      their coordinates and instead pass the translated
      coordinates separately, when propagating events.
      dd251d85
  13. 26 Apr, 2018 1 commit
  14. 06 Feb, 2018 1 commit
    • Matthias Clasen's avatar
      The big versioning cleanup · 4c150d8e
      Matthias Clasen authored
      Remove all the old 2.x and 3.x version annotations.
      GTK+ 4 is a new start, and from the perspective of a
      GTK+ 4 developer all these APIs have been around since
      the beginning.
      4c150d8e
  15. 06 Oct, 2017 1 commit
    • Benjamin Otte's avatar
      build: Enable -Wswitch-enum and -Wswitch-default · 43c212ac
      Benjamin Otte authored
      This patch makes that work using 1 of 2 options:
      
      1. Add all missing enums to the switch statement
        or
      2. Cast the switch argument to a uint to avoid having to do that (mostly
         for GdkEventType).
      
      I even found a bug while doing that: clearing a GtkImage with a surface
      did not notify thae surface property.
      
      The reason for enabling this flag even though it is tedious at times is
      that it is very useful when adding values to an enum, because it makes
      GTK immediately warn about all the switch statements where this enum is
      relevant.
      And I expect changes to enums to be frequent during the GTK4 development
      cycle.
      43c212ac
  16. 19 Sep, 2017 2 commits
  17. 01 Mar, 2017 1 commit
  18. 23 Aug, 2016 3 commits