1. 22 Sep, 2022 1 commit
  2. 20 Sep, 2022 1 commit
  3. 15 Sep, 2022 1 commit
  4. 14 Sep, 2022 1 commit
  5. 11 Sep, 2022 1 commit
  6. 10 Sep, 2022 2 commits
  7. 05 Sep, 2022 1 commit
  8. 03 Sep, 2022 1 commit
  9. 01 Sep, 2022 1 commit
  10. 30 Aug, 2022 1 commit
  11. 22 Aug, 2022 1 commit
  12. 20 Aug, 2022 1 commit
  13. 18 Aug, 2022 2 commits
  14. 14 Aug, 2022 3 commits
  15. 13 Aug, 2022 1 commit
  16. 12 Aug, 2022 1 commit
  17. 01 Aug, 2022 3 commits
  18. 31 Jul, 2022 1 commit
  19. 28 Jul, 2022 3 commits
  20. 27 Jul, 2022 5 commits
    • Yuri Chornoivan's avatar
      Update Ukrainian translation · 1f6e0664
      Yuri Chornoivan authored and Administrator's avatar Administrator committed
      1f6e0664
    • Sébastien Wilmet's avatar
      tab: tune number of milliseconds for the scroll timeout · 0476a1d4
      Sébastien Wilmet authored
      See #42
      
      It works for small files (100 lines with all small lines).
      Works for large files (100k lines with all small lines).
      Works for medium-sized file with long lines.
      
      So, good enough for now.
      0476a1d4
    • Sébastien Wilmet's avatar
      Fix previous commit · 5caf28a5
      Sébastien Wilmet authored
      5caf28a5
    • Sébastien Wilmet's avatar
      About dialog: translate some strings · 71f121b1
      Sébastien Wilmet authored
      I've dropped the indentation for the last one, doesn't worth the
      difficulty of getting this right for all languages (especially RTL, for
      which I don't know if it would work at all, matching the indentation of
      non-localized names).
      71f121b1
    • Sébastien Wilmet's avatar
      About dialog: better list authors and contributors · ea4558d1
      Sébastien Wilmet authored
      Add a "Many thanks also to" section.
      
      Remove email addresses for documenters too, there are better means to
      communicate with the doc team.
      
      This kind of things is always delicate, it's not nice to remove someone.
      But it's nice to thank past contributors, and it's useful to communicate
      who are the main authors (number of commits here, one metric needed to
      be chosen, and that metric is easily available with git shortlog -sn).
      
      The trailing blank line at the end of authors is to space out the next
      section in the credits.
      
      Sort some lists alphabetically, also (by first name, easier).
      ea4558d1
  21. 26 Jul, 2022 4 commits
    • Sébastien Wilmet's avatar
      cff72b4d
    • Sébastien Wilmet's avatar
      3b5626d2
    • Sébastien Wilmet's avatar
      tab: after loading, no need to scroll to cursor if already at start · be6c7695
      Sébastien Wilmet authored
      Especially useful if the org.gnome.gedit.preferences.editor
      restore-cursor-position gsetting is set to false, and if the file is
      loaded without specifying a position.
      
      In that case the cursor will be placed at the start, so no need to setup
      the idle+timeout.
      be6c7695
    • Sébastien Wilmet's avatar
      tab: a bug fix for the text-cut-off problem · 21ae0bab
      Sébastien Wilmet authored
      It's a hack, but it works in all situations, as far as I've tested.
      
      Hopefully a proper fix in GTK will be submitted (but it requires more
      investigation work in gtktextview.c).
      
      I will copy/paste my detailed debugging of this, written here:
      https://wiki.gnome.org/Apps/Gedit/FixingTextCutOffBug
      (a commit message or something in git has a better chance to still exist
      in the distant future).
      
      Fixes #42
      
      -----
      
      = Apps/Gedit/FixingTextCutOffBug =
      
      See:
       * https://gitlab.gnome.org/GNOME/gedit/-/blob/master/docs/common-bugs.md
       * #42
       * #42 (comment 774722) and further comments
      
      100% reproducible with certain files.
      
      Generating a file to reproduce the bug (here 100 lines, might need to be adapted for your screen size):
      {{{
      $ seq 1 100 > text-cut-off
      }}}
      
      Open the file from the terminal, with gedit window already maximized.
      
      Some printf-debugging is possible (gdb might not be appropriate because of switching windows between gedit and the terminal, which triggers different events in the gedit app).
      
      See the wip/text-cut-off git branches in gedit for some tests.
      
      == Workarounds ==
      
      === Workaround 1 ===
      
      {{{
      g_object_set (gtk_settings_get_default (),
                    "gtk-enable-animations", FALSE,
                    NULL);
      }}}
      
      === Workaround 2 ===
      
      Unrelated to workaround 1 (so it's an OR, not an AND).
      
      After loading a file, do not scroll to the cursor.
      
      == Hints for finding the location of the bug ==
      
      Most probably related to the '''combination''' of: animations, and scrolling the !GtkTextView (see the two workarounds above).
      
      In gtkadjustment.c? If gtk_adjustment_enable_animation() (internal function) does nothing, the bug doesn't occur.
      
      A small digression with a new mini Adjustment class (ideas such as: respect class invariants at all times, and store the original value before being clamped):
       * https://gitlab.gnome.org/swilmet/gte-adjustment
       * https://gitlab.gnome.org/swilmet/gte-adjustment/-/blob/main/NOTES.md
      
      == First conclusion ==
      
      It's related to !GtkAdjustment. Either its implementation, or its use by !GtkTextView.
      
      In gtktextview.c, after `s/gtk_adjustment_animate_to_value/gtk_adjustment_set_value/`, the bug doesn't occur anymore.
      
      == Locate the bug more precisely ==
      
      I think it's that ('''Update:''' yes it's that):
       * gtk@9d7f1cac
      
      On the ''last'' call to gtk_text_view_size_allocate() (while the text is still cut off), the adjustments are animating, but ''some'' adjustment values need to change (at least the ''page_size'' needs to be updated to its final value).
      
      Because gtk_text_view_size_allocate() calls text_window_size_allocate(), which can change the SCREEN_HEIGHT(). And SCREEN_HEIGHT() is used as the vadjustment page-size.
      
      Suggestion (?): take into account gtk_adjustment_is_animating() ''inside'' gtk_text_view_set_vadjustment_values() (and for the horizontal one too).
      
      See comments in https://bugzilla.gnome.org/show_bug.cgi?id=733406
      
      == What happens in gedit ==
      
      Example:
      {{{
      GtkTextView vadjustment: value=0.0 lower=0.0 upper=2000.0 page_size=969.0
      
      Then gtk_text_view_size_allocate() is called one more time,
      but the vadjustment is animating, so the page_size is not updated correctly.
      The vadjustment value can go to (upper - page_size = 1031.0) max, so the text is cut off.
      
      After unmaximize/maximize the gedit window, we get the right page_size:
      
      GtkTextView vadjustment: value=0.0 lower=0.0 upper=2000.0 page_size=917.0
      
      upper - page_size = 1083.0, so value can go further and show the bottom of the text.
      }}}
      
      Even without animation, there is a problem to restore the cursor position to the last line(s) (even though the text is not cut off and can be scrolled down manually):
      {{{
      We request to scroll to the last line.
      
      GtkTextView vadjustment: value=1031.0 lower=0.0 upper=2000.0 page_size=969.0
      
      value has been clamped.
      
      Then we get the additional call to gtk_text_view_size_allocate(),
      and because animations are disabled here, the vadjustment is updated.
      
      But the value of 1031.0 is not updated, while page_size is:
      
      GtkTextView vadjustment: value=1031.0 lower=0.0 upper=2000.0 page_size=917.0
      
      To show the last line, it should instead be:
      
      [scrolling manually here]
      
      GtkTextView vadjustment: value=1083.0 lower=0.0 upper=2000.0 page_size=917.0
      }}}
      
      == Simple fix in gedit ==
      
      We ask to scroll to the cursor too early. By changing the idle_scroll to a timeout (250ms seems fine), everything works. But it's a hack.
      
      '''Edit:''' actually no, doesn't work with larger files, even though the timeout is dispatched (so gtk_text_view_scroll_to_mark() is called after 250ms but it doesn't scroll to the position, weird). Need more debugging...
      
      '''Edit 2''': wait idle -> wait timeout of 250ms -> finally scroll: that works in all cases that I've tested :-) (but it's even more hacky). It's because the idle takes longer than 250ms with larger files: if we launch both the timeout and the idle at the same time, we first get the timeout and then the idle (while with smaller files it's the reverse).
      
      == Why there is an extra call to gtk_text_view_size_allocate() ==
      
      We get the extra call to gtk_text_view_size_allocate() via gtk_container_idle_sizer() on the !GeditWindow. gtk_container_idle_sizer() is called during !GdkFrameClock::layout, which is thus called after the idle_scroll (idle_scroll from gedit-tab.c).
      
      '''Better solution:''' we can expect that gtk_text_view_scroll_to_mark() works in all situations. Maybe with an implementation that connects to the !GdkFrameClock (?).
      
      == gtk_text_view_flush_scroll() is maybe called too early ==
      
      With this code inserted at the beginning of gtk_text_view_flush_scroll():
      
      {{{
        if (text_view->priv->layout == NULL ||
            !gtk_text_layout_is_valid (text_view->priv->layout))
          g_warning ("%s() layout not valid", G_STRFUNC);
      }}}
      
      we get several warnings.
      
      gtk_text_view_scroll_to_mark() directly calls gtk_text_view_flush_scroll() if the layout is valid. (If not, gtk_text_view_flush_scroll() is called later on).
      21ae0bab
  22. 25 Jul, 2022 1 commit
  23. 24 Jul, 2022 2 commits
  24. 23 Jul, 2022 1 commit