Feature request- Pause updating

[Geoff]

Hi Tom

First - apologies for the re-post. I sent this 5 days ago, but it has not
appeared on the list.

I think this is a feature request rather than a bug report - although the
behaviour in question seems to have become noticeable relatively recently.

When browsing directories with numerous files (so that the list extends beyond
the bottom of the panel), if one of those files is changed by some application,
the panel is redrawn so that I lose my place. It would be nice to have a
button to "pause updating". I know I can get round the problem by filtering the
file list to target the class of file I am looking for, but a pause button
would be nicer.

Geoff

[Serge]

Sorry for intrusion but you can disable "show parent directory entry
'..' in file lists". And filelist will preserve position when
refreshing.

On Wed, 8 Jan 2014 04:25:15 +0000

Post by Geoff
Hi Tom
First - apologies for the re-post. I sent this 5 days ago, but it has
not appeared on the list.
I think this is a feature request rather than a bug report - although
the behaviour in question seems to have become noticeable relatively
recently.
When browsing directories with numerous files (so that the list
extends beyond the bottom of the panel), if one of those files is
changed by some application, the panel is redrawn so that I lose my
place. It would be nice to have a button to "pause updating". I
know I can get round the problem by filtering the file list to target
the class of file I am looking for, but a pause button would be nicer.
Geoff

[t***@onepost.net]

On Wed, 8 Jan 2014 08:50:36 +0400

Post by Serge
Sorry for intrusion but you can disable "show parent directory entry
'..' in file lists". And filelist will preserve position when
refreshing.

Curious. Not sure why that would make any difference. Nor anything else, for that matter.

The filelist treeview scroll position should not be affected at all by any change of content of the underlying treestore, unless there's some peculiarity like not enough content to maintain position after the refresh.

The displayed content may change, of course, depending on sorting arrangements and what has changed.

Mind you, I'm referring to gtk2 behaviour, I haven't looked at a gtk3 version for a while.

Regards
Tom

Post by Serge
On Wed, 8 Jan 2014 04:25:15 +0000

Post by Geoff
Hi Tom
First - apologies for the re-post. I sent this 5 days ago, but it has
not appeared on the list.
I think this is a feature request rather than a bug report - although
the behaviour in question seems to have become noticeable relatively
recently.
When browsing directories with numerous files (so that the list
extends beyond the bottom of the panel), if one of those files is
changed by some application, the panel is redrawn so that I lose my
place. It would be nice to have a button to "pause updating". I
know I can get round the problem by filtering the file list to target
the class of file I am looking for, but a pause button would be nicer.
Geoff

--
Claws Mail version 3.8.1
Linux debian 3.2.0-4-rt-amd64 #1 SMP PREEMPT RT Debian 3.2.53-2 x86_64
GNU/Linux
--

[Serge]

Hello, Tom.
Maybe treeview scroll position should not be affected at all, but...
File list skips to the top with '..' enabled, when external program is
changing something and sometimes after e2's file operations.
Look at video:

Two times 'touch z' command with '..' disabled and two times with '..'
enabled.
Please note, after enabling '..' in preferences and pressing 'commit'
button, glitch happens too.
After disabling and pressing 'commit', file list preserve position.
This is happens in Debian Wheezy and Debian Jessie.

On Wed, 8 Jan 2014 19:15:37 +1100

Post by t***@onepost.net
On Wed, 8 Jan 2014 08:50:36 +0400

Post by Serge
Sorry for intrusion but you can disable "show parent directory entry
'..' in file lists". And filelist will preserve position when
refreshing.

Curious. Not sure why that would make any difference. Nor anything else, for that matter.
The filelist treeview scroll position should not be affected at all
by any change of content of the underlying treestore, unless there's
some peculiarity like not enough content to maintain position after
the refresh.
The displayed content may change, of course, depending on sorting
arrangements and what has changed.
Mind you, I'm referring to gtk2 behaviour, I haven't looked at a gtk3 version for a while.
Regards
Tom

Post by Serge
On Wed, 8 Jan 2014 04:25:15 +0000

Post by Geoff
Hi Tom
First - apologies for the re-post. I sent this 5 days ago, but it
has not appeared on the list.
I think this is a feature request rather than a bug report -
although the behaviour in question seems to have become
noticeable relatively recently.
When browsing directories with numerous files (so that the list
extends beyond the bottom of the panel), if one of those files is
changed by some application, the panel is redrawn so that I lose
my place. It would be nice to have a button to "pause
updating". I know I can get round the problem by filtering the
file list to target the class of file I am looking for, but a
pause button would be nicer.
Geoff

--
Claws Mail version 3.8.1
Linux debian 3.2.0-4-rt-amd64 #1 SMP PREEMPT RT Debian 3.2.53-2
x86_64 GNU/Linux
--
Users can unsubscribe from the list by sending email to
field or by logging into the web interface.

[t***@onepost.net]

On Wed, 8 Jan 2014 12:18:23 +0400

Post by Serge
Maybe treeview scroll position should not be affected at all, but...
File list skips to the top with '..' enabled, when external program is
changing something and sometimes after e2's file operations.
http://youtu.be/Lc6PiR4tVUU
Two times 'touch z' command with '..' disabled and two times with '..'
enabled.
Please note, after enabling '..' in preferences and pressing 'commit'
button, glitch happens too.
After disabling and pressing 'commit', file list preserve position.
This is happens in Debian Wheezy and Debian Jessie.

OK, I threw in a few lines of code around the filelist 're-filtering' process, to explicitly preserve the scroll position. See how that works.

Regards
Tom

[Serge]

On Fri, 10 Jan 2014 14:02:36 +1100

Post by t***@onepost.net
OK, I threw in a few lines of code around the filelist 're-filtering'
process, to explicitly preserve the scroll position. See how that
works.

Partially fixed) Now, if '..' enabled, position preserved only if
something selected in the list. But (with '..' enabled), selection is
cleared after refresh.
For example:
1/ enable '..'
2/ select something in the file lists
3/ command 'touch z' -
positions are preserved but selections are cleared
4/ command 'touch z2' -
lists skips to the top.

Selection preserved after refresh if ".." is disabled.

[t***@onepost.net]

On Fri, 10 Jan 2014 13:09:50 +0400

Post by Serge
Partially fixed) Now, if '..' enabled, position preserved only if
something selected in the list. But (with '..' enabled), selection is
cleared after refresh.
1/ enable '..'
2/ select something in the file lists
3/ command 'touch z' -
positions are preserved but selections are cleared
4/ command 'touch z2' -
lists skips to the top.
Selection preserved after refresh if ".." is disabled.

Another tweak committed. Seems better now.

Regards
Tom

[Serge]

On Sat, 11 Jan 2014 06:52:25 +1100

Post by t***@onepost.net
Another tweak committed. Seems better now.

I don't see any changes, still the same.
And, after two updates, list moves one line down, even if created file
placed at the bottom, last line. The same one line movement happens
sometimes when refreshing list by hotkey or renaming file's extension.

[t***@onepost.net]

On Sat, 11 Jan 2014 23:33:50 +0400

Post by Serge
On Sat, 11 Jan 2014 06:52:25 +1100

Post by t***@onepost.net
Another tweak committed. Seems better now.

I don't see any changes, still the same.
And, after two updates, list moves one line down, even if created file
placed at the bottom, last line. The same one line movement happens
sometimes when refreshing list by hotkey or renaming file's extension.

Then we'll need to explore in some detail. Here, the treeview scroll positions are unchanged (gtk2) or sometimes very slightly changed (gtk3) whether or not "../" entry is present. Though IIRC there's a couple more tweaks since last post on this.

BTW, re-selection after rename is not as bullet-proof as it should be, on gtk3 at least.

Regards
Tom

[Serge]

On Fri, 17 Jan 2014 20:49:45 +1100

Post by t***@onepost.net
Then we'll need to explore in some detail. Here, the treeview scroll
positions are unchanged (gtk2) or sometimes very slightly changed
(gtk3) whether or not "../" entry is present. Though IIRC there's a
couple more tweaks since last post on this.
BTW, re-selection after rename is not as bullet-proof as it should be, on gtk3 at least.
Regards
Tom

Hello.
Sorry to say that, but before tweaks and with '..' disabled list was
solid as rock when refreshing. Now position skips sometimes to the top
even with '..' option disabled. And one line moves are wrong things)
I am using old build for now.

[t***@onepost.net]

On Sun, 19 Jan 2014 18:13:49 +0400

Post by Serge
On Fri, 17 Jan 2014 20:49:45 +1100
Sorry to say that, but before tweaks and with '..' disabled list was
solid as rock when refreshing. Now position skips sometimes to the top
even with '..' option disabled. And one line moves are wrong things)
I am using old build for now.

Svn is worth another evaluation, now.

Regards
Tom

[Geoff]

On Wed, 22 Jan 2014 10:27:29 +1100

Post by t***@onepost.net
Svn is worth another evaluation, now.

I have been feeling guilty about reporting that all was well here the other
day, because on further use the problem is not fixed for me either. I have
been trying to work out what triggers the issue, because there is an element of
randomness.

I don't know if it will help you, but I will explain my circumstances, I have
an IRC channel which is logged 24/7. The log file is updated 3 or 4 times per
minute on average and lives in /home/me/.xchat2/xchatlogs/ (which has 2,371
files as I type). I also have a /home/me/fetchmail_log which is updated every
5 minutes. Subject to what I will say about the the IRC log file in point
(4) below, changes to these files seem to be the triggers for skipping to the
top- albeit the skipping occurs a few seconds after the file is updated, and
sometimes does not happen at all.

I have tried running with the default theme, and disabling conky, as well as
experimenting on a spare machine using a different WM (fluxbox rather than my
usual icewm). These things make no difference.

As I write this I am using revision 3022 (installed a couple of hours ago) -
with my usual 2 vertical pane layout, my home directory being on the left. I am
testing by opening the vast /usr/lib in the right pane and scrolling a long way
down without selecting any file. My results are :

(1) The skipping occurs *only* if no file is selected in the pane (eg
the /usr/lib panel updates even if a file is selected in /home). There is no
skipping in /usr/lib if I select a file in the panel, even though I then scroll
up and down so that it is out of view.
(2) /home does not always skip even if no file is selected - the effect seems
to be random.
(3) Enabling or disabling '..' makes no difference.
(4) /home/me/.xchat2/xchatlogs/ (in which, you will recall, the regularly
updated log file resides) never skips - except for a slight realignment of the
top line on the first update after I enter the directory.

Geoff

[t***@onepost.net]

On Wed, 22 Jan 2014 09:23:39 +0000

Post by Geoff
On Wed, 22 Jan 2014 10:27:29 +1100

Post by t***@onepost.net
Svn is worth another evaluation, now.

I have
been trying to work out what triggers the issue, because there is an element of
randomness.

That sort of behaviour is probably a symptom of a race occurring during the filelist refresh process (which is performed in its own thread).

Post by Geoff
I don't know if it will help you, but I will explain my circumstances, I have
an IRC channel which is logged 24/7. The log file is updated 3 or 4 times per
minute on average and lives in /home/me/.xchat2/xchatlogs/ (which has 2,371
files as I type). I also have a /home/me/fetchmail_log which is updated every
5 minutes. Subject to what I will say about the the IRC log file in point
(4) below, changes to these files seem to be the triggers for skipping to the
top- albeit the skipping occurs a few seconds after the file is updated, and
sometimes does not happen at all.

Sometimes there's a 3-second interval imposed between refreshes, to prevent 'never-ending' updates when contents are changing rapidly.

Post by Geoff
As I write this I am using revision 3022 (installed a couple of hours ago) -
with my usual 2 vertical pane layout, my home directory being on the left. I am
testing by opening the vast /usr/lib in the right pane and scrolling a long way
(1) The skipping occurs *only* if no file is selected in the pane (eg
the /usr/lib panel updates even if a file is selected in /home). There is no
skipping in /usr/lib if I select a file in the panel, even though I then scroll
up and down so that it is out of view.

More specifically, nothing was ever selected ? or there was selection (which positions the treeview cursor) followed by un-selection ?

Post by Geoff
(2) /home does not always skip even if no file is selected - the effect seems
to be random.
(3) Enabling or disabling '..' makes no difference.
(4) /home/me/.xchat2/xchatlogs/ (in which, you will recall, the regularly
updated log file resides) never skips - except for a slight realignment of the
top line on the first update after I enter the directory.

I'm struggling to construct here a test case that has similar features e.g. mere 'watch > some file in a subdir of home' doesn't replicate your observations.

Is your lib dir being refreshed due to some access-time change(s) ?

Regards
Tom

[Geoff]

On Thu, 23 Jan 2014 18:31:13 +1100
<***@onepost.net> wrote:

<snip>

Post by t***@onepost.net

Post by Geoff
(1) The skipping occurs *only* if no file is selected in the pane (eg
the /usr/lib panel updates even if a file is selected in /home). There is
no skipping in /usr/lib if I select a file in the panel, even though I then
scroll up and down so that it is out of view.

More specifically, nothing was ever selected ? or there was selection (which
positions the treeview cursor) followed by un-selection ?

When nothing was ever selected. My testing protocol is to open a fresh and
only instance of emelfm2 and move down the file list(s) by use only of the
scroll bar.

I am a dummy, but I don't know how I would un-select having once clicked on a
file? I can select another of course, if that is what you mean?

Post by t***@onepost.net

Post by Geoff
(2) /home does not always skip even if no file is selected - the effect
seems to be random.
(3) Enabling or disabling '..' makes no difference.
(4) /home/me/.xchat2/xchatlogs/ (in which, you will recall, the regularly
updated log file resides) never skips - except for a slight realignment of
the top line on the first update after I enter the directory.

I'm struggling to construct here a test case that has similar features e.g.
mere 'watch > some file in a subdir of home' doesn't replicate your
observations.
Is your lib dir being refreshed due to some access-time change(s) ?

I don't think so. I don't usually show access-times, but did so for the
purpose of testing just now. The skipping occurs even though it is some
minutes (or more), since a library was accessed. I have done the same thing
with /usr/bin and with the same result. So far as I can tell, the skipping is
clearly related to that xchat log file being altered. Even when I have selected
a file (eg a long way down in /usr/lib) so that there will be no skipping, I see
the mouse pointer change briefly to the wristwatch at about the time the
alteration occurs.

Geoff

[t***@onepost.net]

On Thu, 23 Jan 2014 09:45:57 +0000

Post by Geoff
On Thu, 23 Jan 2014 18:31:13 +1100
I am a dummy, but I don't know how I would un-select having once clicked on a
file? I can select another of course, if that is what you mean?

Gtk recognises <Ctrl>click to toggle selection of a focused treeview row.

Post by Geoff

Post by t***@onepost.net

Post by Geoff
(2) /home does not always skip even if no file is selected - the effect
seems to be random.
(3) Enabling or disabling '..' makes no difference.
(4) /home/me/.xchat2/xchatlogs/ (in which, you will recall, the regularly
updated log file resides) never skips - except for a slight realignment of
the top line on the first update after I enter the directory.

I'm struggling to construct here a test case that has similar features e.g.
mere 'watch > some file in a subdir of home' doesn't replicate your
observations.
Is your lib dir being refreshed due to some access-time change(s) ?

I don't think so. I don't usually show access-times, but did so for the
purpose of testing just now. The skipping occurs even though it is some
minutes (or more), since a library was accessed. I have done the same thing
with /usr/bin and with the same result. So far as I can tell, the skipping is
clearly related to that xchat log file being altered. Even when I have selected
a file (eg a long way down in /usr/lib) so that there will be no skipping, I see
the mouse pointer change briefly to the wristwatch at about the time the
alteration occurs.

There is (or at least, there should be) nothing in e2 which causes a refresh of one filelist to trigger a refresh of the other one.

That's distinct from the change of scroll-position, of course, but it may be a clue as to what's happening.

I'm thinking it's time for some off-list exchanges of customised file(s) with extra debug messages.

Regards
Tom

[Geoff]

On Fri, 24 Jan 2014 06:54:56 +1100
<***@onepost.net> wrote:

<snip>

Post by t***@onepost.net
Gtk recognises <Ctrl>click to toggle selection of a focused treeview row.

ah .. well a quick test on /usr/lib suggests that so long as I have once
selected a file, then the skipping stops even after I unselect it in this way.
This holds true (so far), even if, after unselecting, I use the scroll bar to
bring a different set of files into view in the pane.

<snip>

Post by t***@onepost.net
I'm thinking it's time for some off-list exchanges of customised file(s) with
extra debug messages.

Sure,

Geoff

[t***@onepost.net]

On Thu, 23 Jan 2014 20:24:55 +0000

Post by Geoff
On Fri, 24 Jan 2014 06:54:56 +1100
<snip>

Post by t***@onepost.net
Gtk recognises <Ctrl>click to toggle selection of a focused treeview row.

ah .. well a quick test on /usr/lib suggests that so long as I have once
selected a file, then the skipping stops even after I unselect it in this way.
This holds true (so far), even if, after unselecting, I use the scroll bar to
bring a different set of files into view in the pane.
<snip>

Post by t***@onepost.net
I'm thinking it's time for some off-list exchanges of customised file(s) with
extra debug messages.

For those following this thread, Geoff reports that this behaviour now looks to be fixed.

Regards
Tom

[Geoff]

On Sat, 11 Jan 2014 06:52:25 +1100
<***@onepost.net> wrote:

<snip>

Post by t***@onepost.net
Another tweak committed. Seems better now.

Apologies for raising this issue then vanishing. I have, however, just
compiled Revision 2994 under kernel 3.12.7-1-ARCH with GTK+-3.10.6, and it
segfaults on starting. My current installed/working emelfm2 was compiled on
13th October last year under kernel 3.11.4-1 and GTK+3.10.1.

Geoff

[t***@onepost.net]

On Sun, 12 Jan 2014 21:42:10 +0000

Post by Geoff
Apologies for raising this issue then vanishing. I have, however, just
compiled Revision 2994 under kernel 3.12.7-1-ARCH with GTK+-3.10.6, and it
segfaults on starting. My current installed/working emelfm2 was compiled on
13th October last year under kernel 3.11.4-1 and GTK+3.10.1.

I've now updated to 3.10.6. Seems like some further icon-related change(s) making more mischief.

In evaluating this, I decided to re-factor the related code, to make the 'forced' installation of relevant gtk stock icons into a build-time option.
i.e use WITH_SYSTEM_ICONS=1

Might take a few days. Need to fit this in between heat-waves, here.

Regards
Tom

[t***@onepost.net]

On Fri, 17 Jan 2014 20:40:23 +1100

Post by t***@onepost.net
On Sun, 12 Jan 2014 21:42:10 +0000
In evaluating this, I decided to re-factor the related code, to make the 'forced' installation of relevant gtk stock icons into a build-time option.
i.e use WITH_SYSTEM_ICONS=1
Might take a few days. Need to fit this in between heat-waves, here.

OK to try svn again now.

Regards
Tom

[Geoff]

On Sat, 18 Jan 2014 10:47:28 +1100
<***@onepost.net> wrote:

<snip>

Post by t***@onepost.net
OK to try svn again now.
OK to try svn again now.

Working fine here thank you Tom. Just what I asked for.

Stay out of the heat.

Geoff