1. 20 Jan, 2013 3 commits
  2. 19 Jan, 2013 3 commits
  3. 18 Jan, 2013 4 commits
  4. 17 Jan, 2013 11 commits
  5. 16 Jan, 2013 2 commits
  6. 15 Jan, 2013 17 commits
    • Carlos Garnacho's avatar
      gdk: strengthen touch crossing event synthesizing on programmatical crossings · 3210cd65
      Carlos Garnacho authored
      There are cases where crossing events aren't generated by input devices themselves
      but rather through programmatical means (windows being moved/hidden/destroyed while
      the pointer is on top).
      
      Those events come from X as sourceid=deviceid, and GDK does its deal at lessening
      this by setting a meaningful source device on such events, although this caused
      some confusion on the mechanism to block/synthesize touch crossing events that
      could possibly cause bogus enter events on the new window below the pointer.
      
      Fixes https://bugzilla.gnome.org/show_bug.cgi?id=691572
      3210cd65
    • Benjamin Otte's avatar
      cssvalue: Remove NULL check · a763738f
      Benjamin Otte authored
      The value cannot ever be NULL here.
      a763738f
    • Benjamin Otte's avatar
      cssvalue: Move value initialization · 301e2212
      Benjamin Otte authored
      Makes it easier to track places where tha value is not initialized.
      301e2212
    • Benjamin Otte's avatar
      cssvalue: Fix return_if_fail() calls... · b60478bb
      Benjamin Otte authored
      b60478bb
    • Benjamin Otte's avatar
      cssvalue: Remove useless call · 993e3f71
      Benjamin Otte authored
      993e3f71
    • John Lindgren's avatar
      Better resize of expandable columns · 0050d469
      John Lindgren authored
      Since 16195adc the “expand” property is always set to FALSE when a
      column is resized.  This commit takes a different approach and enables
      “expand” whenever the column is wide enough.  An appropriate
      “fixed-width” (so that the desired width is achieved after expanding) is
      calculated using equations that are explained in the code.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=691751
      0050d469
    • John Lindgren's avatar
      Use minimum/natural size semantics · 6d53c233
      John Lindgren authored
      Rewrites gtk_tree_view_column_request_width() and
      gtk_tree_view_size_allocate_columns() to respect the minimum and natural
      sizes that are already being returned by
      gtk_cell_area_context_get_preferred_width().
      
      The convoluted logic explained (not!) by this comment has been removed:
      “Only update the expand value if the width of the widget has changed, or
      the number of expand columns has changed, or if there are no expand
      columns, or if we didn't have an size-allocation yet after the last
      validated node.”  This logic seems to have been a workaround for the
      “jumping” behavior fixed in 16195adc and is no longer necessary.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=691751
      6d53c233
    • John Lindgren's avatar
      Minor refactoring · 9b6661a0
      John Lindgren authored
      No functional change, only moves a self-contained block of code out of
      size_allocate_columns() to its own function.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=691751
      9b6661a0
    • John Lindgren's avatar
      Use fixed width for resizing · 16195adc
      John Lindgren authored
      Removes the hidden “resized-width” and “use-resized-width” properties
      from GtkTreeViewColumn and instead uses the “fixed-width” property to
      serve the same purpose.  “fixed-width”, if set, will now override the
      auto-sized width (-1 is now a legal value meaning “not set”).
      
      Additional “cleanups” in this commit:
      
      1. When the user resizes the column the “expand” property is now also
      set to FALSE, in order to prevent the column from suddenly jumping to a
      different width when the window is resized.
      
      2. The code that translated mouse movement to column sizes has been
      simplified:
      the change in column width is now calculated directly from the distance
      the mouse cursor has traveled.  Weird behavior that might have happened
      previously if the position of the column changed during resizing, is now
      prevented.
      
      3. There was some lengthy logic handling the keyboard shortcuts used to
      resize treeview columns, which would call gtk_widget_error_bell() once
      the minimum or maximum width was reached.  Instead of rewriting these
      checks I simply set the “fixed-width” property to what was requested,
      relying on the fact that it is already clamped between the minimum and
      maximum width during size allocation.
      I will greatly surprised if anyone notices the missing error bell.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=691751
      16195adc
    • John Lindgren's avatar
      Kill gtk_tree_view_size_request · d0e0e489
      John Lindgren authored
      Splits up size_request() so that the height calculations are only done
      when get_preferred_height() is called and the width calculations are
      only done when get_preferred_width() is called.  Since
      get_preferred_width() does not change the treeview->priv->width value,
      treeview->priv->prev_width will always be equal to it and can therefore
      be removed.  The only place where prev_width was used is a block in
      gtk_tree_view_size_allocate().  This block seems to be adjusting the
      horizontal scrollbar to account for treeview->priv->width having been
      changed in size_request() and should no longer be necessary.  A similar
      block immediately above it seems to already account for the width change
      in size_allocate().
      
      https://bugzilla.gnome.org/show_bug.cgi?id=691751
      d0e0e489
    • John Lindgren's avatar
      Remove extraneous size request · 91949934
      John Lindgren authored
      After “validation” (i.e., background size calculations) of some cells,
      size_request() was called here to update the internally cached size of
      the treeview.  Apparently not updating the sizes leads to some kind of
      “inconsistency” that messes with top_row_to_dy().  In the GTK3 model for
      size allocation, things are more complicated.  The treeview can’t just
      go ahead and calculate its own size any more; instead it reports both a
      “minimum” and a “natural” size, and it doesn’t know what size it will
      actually get until size_allocate().  It may be necessary to update
      top_row_to_dy() to deal with not knowing the exact size.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=691751
      91949934
    • Matthias Clasen's avatar
      Bump version · 199ecc12
      Matthias Clasen authored
      199ecc12
    • Matthias Clasen's avatar
      3.7.6 · 940971bd
      Matthias Clasen authored
      940971bd
    • Matthias Clasen's avatar
      2adf1a49
    • Matthias Clasen's avatar
      Don't run gtkdoc-check in make check · 8d81b1a4
      Matthias Clasen authored
      It fails for dubious reasons that should not cause make check
      to fail, such as a few undocumented symbols.
      8d81b1a4
    • Matthias Clasen's avatar
      Remove a no-longer existing symbol · 065f9529
      Matthias Clasen authored
      065f9529
    • Matthias Clasen's avatar
      Update expected output of a11y tests · cdaa6e03
      Matthias Clasen authored
      The output for GtkAboutDialog changed as a result of the
      Homepage -> Website string change.
      cdaa6e03