with reference to previous position of cursor on document, switching
between docs will change accordingly.
Evert:can u elobarate on your expected results bit more?

The slidebar on the right hand side of the GtkTextView widget should
be at the same position as when that document was "left" for another
one (by clicking on its tab). In other words, the slidebar position
should only change when the user explicitly requests this.

Additional Information:
In the current implementation, the slidebar position is apparently
always reset to the document "view" where the text cursor is visible,
ignoring the fact that the user may have intentionally moved down the
slidebar in order to display another section of the document.

Evert:currently the slide bar position is wirh respect to curson
position. the expected requirement is independent of cursor point. It
should retain previous slide bar position. am I right?

Yes, you're right. gedit2 should retain the previous slidebar position
(independent of the position of the text cursor).

*** Bug 90190 has been marked as a duplicate of this bug. ***

*** Bug 100771 has been marked as a duplicate of this bug. ***

retaining the position regardless of the cursor in tabbed documents
would be the same behavior as retaining the position in documents in
their own window.

If the document was in a window by itself, you wouldn't expect the
position to change each time you focus the window, and the tab (which
is really just another model of window) should behave the same way.

*** Bug 101206 has been marked as a duplicate of this bug. ***

Marking high since a lot of people report this one.

IMO, this is due to a GtkTextView bug. 
I really don't see why it should scroll on focus. 

Refiling this bug as a gtk+ (GtkTextView bug) and changing summary for
clarity.

I will provide a patch against GtkTextView ASAP.

Created attachment 13027 [details] [review]
Patch to disable scroll on focus

IIRC the reason we scroll to cursor on focus is that the 
blinking cursor is the only way you can tell the widget 
has focus.

Yuck. Why did we get rid of external focus indication for text fields
again?   It's still good enough for the Mac... :)

If you don't scroll on focus, then you have to figure out
what happens when the user starts typing or keynaving.
Jumping at that point would also be confusing.

This is _generally_ a problem when mixing keynav and mouse usage;
when doing pure keynav, the cursor is basically never outside
the visible area.

Notebooks are a bit different; the focusing onto a page of
a notebook by clicking on the tabs is a little different
than focusing by clicking on the widget. (Which would set
the cursor)

I suspect a very effective rule would be to never scroll
if gtk_get_current_event() is a mouse event; this would
also get rid of the current special case for the clicking
in the widget with the mouse.

Putting on 2.2.1 since I think there are open questions
here.

Why is there any difference between how two documents in two seperate
windows, and two dpcuments inside tabs inside a window work?

If I scroll a documents in it's own window and then refocus that
window, then the document remains where it was scrolled too, even if
the cursor isn't on the page.

The same behavior should occur for tabs?  Yes?

Isn't a tab just another model for windowing?

I think we could commit the attached patch (at least it fixes a
frequently reported bug in gedit) and eventually search a better
solution for the future.

BTW, I think that the behavior of the patched GtkTextView is the one
the users are used to. It is quite normal scolling at cursor when the
user starts typing or keynaving.

There are a number of other bugs which ultimatively originate in the
design decision to keep the cursor always visible, e.g. bug 68963. 
I think keeping the cursor visible or not should be decided
individually for each operation on a text view. Operations which take
an effect at the cursor position like inserting text or moving the
cursor should keep the cursor visible, scrolling or moving the focus
should not.

This bug is one of the most frequently reported bugs in gedit. The
patch I attached a few months ago seems to solve the problem. 

As I already said: could we commit it and eventually search for a better
solution for the future?

*** Bug 107206 has been marked as a duplicate of this bug. ***

Other GTK applications are affected by this as well. For example, in
gAIM's gtk2 cvs versions, they have a tabbed interface for viewing the
history of a conversation... consider the following:

1) I have two tabs open, both with chat histories which extend beyond
the visible window... both chat histories have their scrollbars at the
bottom to so that incoming messages are visible...
2) I switch from tab 1 to tab 2... I scroll up in tab 2 to the top of
the chat history and select the first line of text... I scroll back
down all the way to the bottom so that incoming messages are visible...
3) I switch from tab 2 to tab 1 and paste the selected text from tab 2
into the "send message" text widget... I then switch back to tab 2 to
view a new message my buddy has sent me...
4) Tab 2 automatically scrolls back up to the very top where I
selected my text, even though I explicitly scolled back down to the
bottom.

I don't even have to select text to generate this. I can simply click
my cursor somewhere on the chat history widget.

Anyways, I concur with the reporter that a tab/notebook system is
simply another way to draw multiple windows and that changing focus
should never change the scrollbar.

-jag

*** Bug 112835 has been marked as a duplicate of this bug. ***

Can we please fix this bug? The current behavior really sucks in gedit
and anjuta2. Why not just have the cursor onscreen when the user moves
it? That's the behavior i'm used to. Having the textview scroll to the
cursor position on switching tabs is _highly_ annoying.

In the patch, I think this could break ABI:

-  /* disable scrolling to cursor on focus */
-  guint disable_scroll_on_focus : 1;
+  guint reserved;

I would do "guint reserved : 1" instead to be safe.

I don't mind applying this patch, it makes sense to me. 
We should be sure the textview scrolls to cursor when you 
start typing though, if that's expected. (Maybe it already does.)

Has there been any examination of how other text widgets
behave? And what should the details of the new behavior
be? Should it scroll immediately on Tab in? Does
it jump on any key press or only on key presses that
insert text or move the cursor?

(And since it seems to be popular, no, we don't need
more people jumping in to say how awfully the current
behavior affects their app.)

I just did a quick test on windows and MacOS X to see what the cursor
behavior was.

ON WINDOWS

On NotePad, WordPad and NotePadLight the cursor stay in the same place
on the screen (where possible) when you press the <page up> and <page
down> keys.

By where's possible I mean that if the cursor is 30 characters out and
the line it ends up on has less than 30 characters is appears at the
end of the line.  In this case the cursor then thinks of itself as at
the end of the line and moves to the end of each line as you scroll up
and down.

If you are at the top of the document but the cursor is in the middle
of the work area then pressing <page up> will move it to the start of
the document.  Similarly for the bottom except to the end.

ON MAC OS X

The cursor stays where it is and the page scrolls up and down.  Typing
moves you back to the current cursor position.

WHAT I'D LIKE TO SEE

I think the MacOS X behavior is better.  Being able to move through
the document while retaining you focus somewhere else gives you the
ability to find what you want and then move back to where you were
without having to search for that too.

Related, I think that tabbed content areas should behave in much the
same way as windows.  For example, if I place the cursor at the start
of a long document and scroll to the bottom.  Then I focus another
window and then move back to the original window, I would expect (and
it is so) that the cursor would remain at the top, but the document
view would be of the bottom.  This is the same behavior I would expect
for tabbed 'windows'.

I did a quick test to see what the current GtkTextView behavior is
based on gedit:

At the start, the cursor is at the top of the document and vertical
scrollbar is visible. When i scroll to the bottom and then perform the
following actions, i get the following results:

- Move to next/previous character/line using arrow keys
  -> Textview scrolls to cursor.
- Type/insert/delete a character
  -> Textview scrolls to cursor.
- Page Up/Down
  -> Textview scrolls one page up/down from the current scroll
position. The cursor is also repositioned so it appears in the current
scrolled window.

This behavior doesn't change with Paolo's patch. Aside from Page
Up/Down, the behavior is exactly what i expected. I expected page up &
down to first scroll to the cursor and then do a page up/down, but
this behavior is ok with me as well.

In relation to Rodd's comment, I find the opposite-- i.e. for a
keyboard user, the Windows behaviour is more useful than the MacOS
behaviour.  But they're designed to optimise two different use cases:

- MacOS is optimised for reviewing previous pages, not editing them. 
If I want to go back and edit a paragraph three pages back, I either
have to move the cursor up a line at a time, or press PgUp three times
then click with the mouse, which isn't an option for some people. (And
it means having to take your hands off the keyboard even if it is an
option, which is usually annoying).  

- Windows model is optimised for re-editing previous pages. If you
were just using PgUp for review purposes, to get back to where you
were and continue editing you have to press PgDn the corresponding
number of times, or Ctrl+End just once if "where you were" happened to
be the end of the document.

Personally I think that makes the Windows PgUp/Dn behaviour a better
compromise, especially from an accessibility standpoint.

Calum, good points.  Having explained it, I'd do it your way.

Examined Qt, OpenOffice.org, Mozilla, and they all shared the
characteristics:

 - No focus indication if the cursor is off the screen [1]
 - Cursor position does not change on Tab in
 - Scroll jumped to current cursor position on text
   on insertion/deletion/keynav. This includes page-up/down.
   (That is, scrolling began from the old cursor location)

I'll attach a slight extension to Paolo's patch to make
GtkTextView do exactly that. I don't feel it is 100% right,
but it should cause less complaints than the current
behavior.

[1] OpenOffice.org was an exception here - there was
    focus indication on tab in since it selected the
    entire buffer. But that is clearly wrong

Created attachment 17191 [details] [review]
Patch also changing PageUp/Down

Makes sense to me

Thu Jun  5 16:52:54 2003  Owen Taylor  <otaylor@redhat.com>
 
        * gtk/gtktextview.[ch]: Never scroll on focus in
        (#81893, Patch from Paolo Maggi)
 
        * gtk/gtktextview.c (gtk_text_view_scroll_[h]pages):
        Scroll to the current cursor location before handling
        the action, in case the user just tabbed in
        and the cursor is offscreen.

*** Bug 117669 has been marked as a duplicate of this bug. ***