1. 09 Jun, 2016 1 commit
  2. 09 May, 2016 1 commit
  3. 28 Apr, 2016 1 commit
  4. 25 Apr, 2016 2 commits
  5. 19 Apr, 2016 1 commit
    • Chun-wei Fan's avatar
      MSVC builds: Update how introspection builds are done · 9a87b6be
      Chun-wei Fan authored
      This first adds a common autotools module that can be included by
      the Makefile.am's to generate the file lists and the g-ir-scanner/
      g-ir-compiler command lines to build the introspection files.
      
      The autotools files for gdk/ and gtk/ are then updated to generate
      the full file lists needed to build the introspection files, with
      the full command lines for g-ir-scanner and g-ir-compiler as NMake
      Makefile modules that can be used to build the introspection files
      for Visual Studio builds.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=765195
      9a87b6be
  6. 09 Apr, 2016 1 commit
  7. 28 Feb, 2016 1 commit
    • Paolo Borelli's avatar
      win32: move gdkvisual code in gdkscreen · e48bd2e0
      Paolo Borelli authored
      Except for the init function, all the visual related code is made
      of gdkscreen vfuncs, so let's move it to gdkscreen-win32. This way
      we avoid keeping other static variables and instead store the info
      inside the screen struct.
      e48bd2e0
  8. 22 Feb, 2016 1 commit
  9. 15 Jan, 2016 1 commit
  10. 14 Dec, 2015 2 commits
  11. 15 Sep, 2015 2 commits
    • Chun-wei Fan's avatar
      MSVC Builds: Massive Rename of Projects · 6423a02c
      Chun-wei Fan authored
      We need to rename the projects so that when these projects are added
      into an all-in-one solution file that will build the GTK+ 2/3 stack,
      the names of the projects will not collide with the GTK+-2.x ones,
      especially as GTK+-2.x and GTK+-3.x are done to co-exist on the same
      system.  This is due to the case that the MSVC projects are directly
      carried over from the GTK+-2.x ones and was then updated for 3.x.
      
      We still need to update the GUIDs of the projects, so that they won't
      conflict with the GTK+-2.x ones.
      6423a02c
    • Chun-wei Fan's avatar
      build: Clean Up Visual Studio Project Generation · d836a52b
      Chun-wei Fan authored
      Use the common automake module from the previous commit in the
      Makefile.am's, which means that the Makefile.am's in gdk/ and gtk/ can be
      cleaned up as a result.  As a side effect, the property sheet that is used
      to "install" the build results and headers can now be generated in terms of
      the listing of headers to copy during 'make dist', where we can acquire
      most of the list of headers to "install", so that we can largely avoid the
      situation where the property sheet files are not updated in time for this,
      causing missing headers when this build of GTK+ is being used.
      
      Also use the Visual Studio Project file generation for the following
      projects:
      gtk3-demo
      gtk3-demo-application
      gtk3-icon-browser
      gdk-win32
      gdk-broadway
      gail-util
      
      So that the maintenace of these project files can be simplified as well.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=681965
      d836a52b
  12. 02 Feb, 2015 1 commit
  13. 13 Dec, 2014 1 commit
  14. 30 Nov, 2014 1 commit
  15. 08 Nov, 2014 1 commit
    • Emmanuele Bassi's avatar
      Make global GDK libgtk_only functions more private · eedbec20
      Emmanuele Bassi authored
      The current way of exposing GDK API that should be considered internal
      to GTK+ is to append a 'libgtk_only' suffix to the function name; this
      is not really safe.
      
      GLib has been using a slightly different approach: a private table of
      function pointers, and a macro that allows accessing the desired symbol
      inside that vtable.
      
      We can copy the approach, and deprecate the 'libgtk_only' symbols in
      lieu of outright removal.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=739781
      eedbec20
  16. 22 Oct, 2014 1 commit
  17. 13 Oct, 2014 1 commit
    • Alexander Larsson's avatar
      gdk: Add support for OpenGL · 038aac62
      Alexander Larsson authored
      This adds the new type GdkGLContext that wraps an OpenGL context for a
      particular native window. It also adds support for the gdk paint
      machinery to use OpenGL to draw everything. As soon as anyone creates
      a GL context for a native window we create a "paint context" for that
      GdkWindow and switch to using GL for painting it.
      
      This commit contains only an implementation for X11 (using GLX).
      
      The way painting works is that all client gl contexts draw into
      offscreen buffers rather than directly to the back buffer, and the
      way something gets onto the window is by using gdk_cairo_draw_from_gl()
      to draw part of that buffer onto the draw cairo context.
      
      As a fallback (if we're doing redirected drawing or some effect like a
      cairo_push_group()) we read back the gl buffer into memory and composite
      using cairo. This means that GL rendering works in all cases, including
      rendering to a PDF. However, this is not particularly fast.
      
      In the *typical* case, where we're drawing directly to the window in
      the regular paint loop we hit the fast path. The fast path uses opengl
      to draw the buffer to the window back buffer, either by blitting or
      texturing. Then we track the region that was drawn, and when the draw
      ends we paint the normal cairo surface to the window (using
      texture-from-pixmap in the X11 case, or texture from cairo image
      otherwise) in the regions where there is no gl painted.
      
      There are some complexities wrt layering of gl and cairo areas though:
      * We track via gdk_window_mark_paint_from_clip() whenever gtk is
        painting over a region we previously rendered with opengl
        (flushed_region). This area (needs_blend_region) is blended
        rather than copied at the end of the frame.
      * If we're drawing a gl texture with alpha we first copy the current
        cairo_surface inside the target region to the back buffer before
        we blend over it.
      
      These two operations allow us full stacking of transparent gl and cairo
      regions.
      038aac62
  18. 15 Sep, 2014 1 commit
  19. 13 Aug, 2014 1 commit
  20. 11 Jul, 2014 2 commits
  21. 22 Jun, 2014 1 commit
  22. 03 Jun, 2014 1 commit
  23. 22 May, 2014 1 commit
  24. 01 Apr, 2014 2 commits
  25. 05 Jan, 2014 1 commit
  26. 02 Aug, 2013 1 commit
    • Chun-wei Fan's avatar
      Add Visual Studio Build Support for Broadway · dcb766c4
      Chun-wei Fan authored
      -Add Visual Studio 2008 projects and pre-configured gdkconfig.h for
       Broadway builds
      -Decouple the Visual Studio property sheets, to simplify maintenance and
       enhance flexibility for different builds
      
      Visual Studio 2010 projects updates will follow later.
      dcb766c4
  27. 15 May, 2013 2 commits
  28. 09 May, 2013 1 commit
  29. 07 May, 2013 2 commits
  30. 05 May, 2013 2 commits
    • Matthias Clasen's avatar
      Remove regex-based export control · ec724fe0
      Matthias Clasen authored
      All export control is now happening through annotations
      in the headers.
      ec724fe0
    • Matthias Clasen's avatar
      New visibility handling in gdk · 8af16c5d
      Matthias Clasen authored
      Change the visibility handling to be the same way we do it in
      GLib now. We pass -fvisibility=hidden to gcc and decorate public
      functions with __attribute__((visibility("default"))).
      
      This commit just does this for GDK, GTK+ will follow later.
      8af16c5d
  31. 22 Apr, 2013 1 commit
  32. 15 Apr, 2013 1 commit
    • Benjamin Otte's avatar
      gdk: Make atoms handled generically · aa9e974c
      Benjamin Otte authored
      This is another step towards making GdkDisplayManager backend-agnostic.
      
      Most of the backends profit from this as their atom implementations
      where generic anyway - x11 needed that to allow multiple X displays and
      broadway, quartz and wayland don't have the concept of displays.
      
      The X11 backend still did things, so I only #if 0'd some code but did
      not actually update anything.
      aa9e974c