2:31 p.m.
Hi,
this is an interface annoyance that I've experienced for a while,
possibly even years. (On Windows, don't know right now if it happens on
Linux as well.) In the built-in script editor if you're typing at the
bottom of the screen and then hit return, often it happens that the new
bottom line isn't shifted up so that it's "in full sight". Either
it's
fully off-window or it might be only partly visible.
A second variation of this problem is that when I do a text search (or
search&replace), the highlighted text that was found is also in the line
that is just below the bottom visible window area, if you understand
what I mean.
The workaround is to manually scroll down by the equivalent of one line
height, which gets annoying after a while.
Anybody else seeing this?
thanks,
sven
2:39 p.m.
Yes, I experience this too on latest snapshot with win 7 64 bit.
-----Original Message-----
From: gretl-devel-bounces(a)lists.wfu.edu [mailto:gretl-devel-bounces@lists.wfu.edu] On
Behalf Of Sven Schreiber
Sent: Friday, July 01, 2016 7:31 AM
To: Gretl development <gretl-devel(a)lists.wfu.edu>
Subject: [Gretl-devel] Text with focus/highlight in script editor off screen
Hi,
this is an interface annoyance that I've experienced for a while, possibly even years.
(On Windows, don't know right now if it happens on Linux as well.) In the built-in
script editor if you're typing at the bottom of the screen and then hit return, often
it happens that the new bottom line isn't shifted up so that it's "in full
sight". Either it's fully off-window or it might be only partly visible.
A second variation of this problem is that when I do a text search (or
search&replace), the highlighted text that was found is also in the line that is just
below the bottom visible window area, if you understand what I mean.
The workaround is to manually scroll down by the equivalent of one line height, which gets
annoying after a while.
Anybody else seeing this?
thanks,
sven
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
5:10 p.m.
Am 01.07.2016 um 16:39 schrieb Logan Kelly:
Yes, I experience this too on latest snapshot with win 7 64 bit.
Thanks for the feedback; one other (even more minor) thing with the
script editor: When window-splitting is active (so an upper and a lower
window pane are there) and I'm pasting something into the upper view,
the lower view jumps to the same place as the lower, defeating the
purpose of the splitting. Don't know if this is outside gretl's
responsibility.
thanks,
sven
9:16 p.m.
On Fri, 1 Jul 2016, Sven Schreiber wrote:
this is an interface annoyance that I've experienced for a while,
possibly even years. (On Windows, don't know right now if it
happens on Linux as well.) In the built-in script editor if you're
typing at the bottom of the screen and then hit return, often it
happens that the new bottom line isn't shifted up so that it's "in
full sight". Either it's fully off-window or it might be only
partly visible.
I haven't yet experimented on Windows, but I can say that on Linux a
GtkText window does not behave quite as I'd expect (from experience
with several editors). That is, if you're typing on the last visible
line in a GtkText window and hit the Enter key, the new (so far,
empty) line does not appear, it's off the bottom of the window.
However, on Linux, as soon as you start typing content into the new
line it is (fully) scrolled on-screen.
A second variation of this problem is that when I do a text search
(or search&replace), the highlighted text that was found is also
in the line that is just below the bottom visible window area, if
you understand what I mean.
I think I see what you mean, but I'm not seeing that on Linux. Any
line containing a search hit is displayed OK.
I suppose I'll have to check on Windows (ugh). Maybe we can add some
callbacks to GtkText signals that will improve matters.
Allin
12:04 a.m.
Am 01.07.2016 um 23:16 schrieb Allin Cottrell:
On Fri, 1 Jul 2016, Sven Schreiber wrote:
several editors). That is, if you're typing on the last visible
line in
a GtkText window and hit the Enter key, the new (so far, empty) line
does not appear, it's off the bottom of the window. However, on Linux,
as soon as you start typing content into the new line it is (fully)
scrolled on-screen.
That's right, same here. Probably just have to trust my rational
knowledge that after hitting return it's an empty line where I'm
starting to type in, even without seeing it.
> A second variation of this problem is that when I do a text search (or
> search&replace), the highlighted text that was found is also in the
> line that is just below the bottom visible window area, if you
> understand what I mean.
I think I see what you mean, but I'm not seeing that on Linux. Any line
containing a search hit is displayed OK.
Hmm, the typical effect now -- I'm not seeing the problem anymore,
either. Perhaps I was fooled with wrapped-around searches (adding to
that the problem that in the "classic" setting of the editor the
background shading of the found text snippet is quite hard to see for my
old eyes).
thanks,
sven
9:18 a.m.
Am 02.07.2016 um 02:04 schrieb Sven Schreiber:
Am 01.07.2016 um 23:16 schrieb Allin Cottrell:
> On Fri, 1 Jul 2016, Sven Schreiber wrote:
>> A second variation of this problem is that when I do a text
search (or
>> search&replace), the highlighted text that was found is also in the
>> line that is just below the bottom visible window area, if you
>> understand what I mean.
>
> I think I see what you mean, but I'm not seeing that on Linux. Any line
> containing a search hit is displayed OK.
Hmm, the typical effect now -- I'm not seeing the problem anymore,
either. Perhaps I was fooled with wrapped-around searches (adding to
that the problem that in the "classic" setting of the editor the
background shading of the found text snippet is quite hard to see for my
old eyes).
I've definitely seen it again now. It seemed to have something to do
with changing the search term in the search window and then going on
with the search, but I cannot give a 100% reproducible way of triggering it.
cheers,
sven
4 p.m.
Am 03.07.2016 um 11:18 schrieb Sven Schreiber:
>
I've definitely seen it again now. It seemed to have something to do
with changing the search term in the search window and then going on
with the search,
or perhaps switching to a different editor tab while the search dialog
window remains open, maybe together with also changing the search text
in the dialog...
-s
3098
days inactive
3100
days old
6 comments
3 participants
participants (3)
-
Allin Cottrell -
Logan Kelly -
Sven Schreiber