Discussion:
executable items are automatically unselected
Liviu Andronic
2012-05-23 09:01:28 UTC
Permalink
Hello
There is one recurring issue concerning file selection: some items get
unselected in ~1sec, rendering the c-menu quite useless.

Try the following:
- select a text file that is not marked as executable (colour black),
access the c-menu: the selection will stay put, and accessing View
will allow you to view the file
- select a text file that is marked as _executable_ (colour green),
access the c-menu: the item will become unselected in ~1sec, and
accessing View will fail with
"No item selected
Failed to expand macros"
- redo use case 2 but now use a 'shift + c-menu' combo: the selection
will stay put, and accessing Rename will work

Using 0.8.1 compiled with: WITH_KERNELFAM=1 NEW_COMMAND=1
EDITOR_SPELLCHECK=1 WITH_LATEST=1 WITH_GTK2=1 WITH_THUMBS=1
WITH_THUMBLIB=0 WITH_TRACKER=1 WITH_ACL=1 WITH_POLKIT=1 WITH_UDISKS=1.

Could this be addressed? Regards
Liviu
--
Do you know how to read?
http://www.alienetworks.com/srtest.cfm
http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail
t***@onepost.net
2012-05-23 13:30:49 UTC
Permalink
On Wed, 23 May 2012 11:01:28 +0200
Post by Liviu Andronic
Hello
There is one recurring issue concerning file selection: some items get
unselected in ~1sec, rendering the c-menu quite useless.
- select a text file that is not marked as executable (colour black),
access the c-menu: the selection will stay put, and accessing View
will allow you to view the file
- select a text file that is marked as _executable_ (colour green),
access the c-menu: the item will become unselected in ~1sec, and
accessing View will fail with
"No item selected
Failed to expand macros"
- redo use case 2 but now use a 'shift + c-menu' combo: the selection
will stay put, and accessing Rename will work
Using 0.8.1 compiled with: WITH_KERNELFAM=1 NEW_COMMAND=1
EDITOR_SPELLCHECK=1 WITH_LATEST=1 WITH_GTK2=1 WITH_THUMBS=1
WITH_THUMBLIB=0 WITH_TRACKER=1 WITH_ACL=1 WITH_POLKIT=1 WITH_UDISKS=1.
Could this be addressed? Regards
Liviu, you'll need to provide some more insight. The behaviour you report does not happen here, and it's not obvious where to look for a problem.

For example - just one item selected, or a few, or many?
If more than one, and they include multiples of the same type, do those all get de-selected?
Does it matter whether the file has an extension?
Does it matter what such extension is?
Does it matter whether the filelist is scrolled away from its top position?
What if any refreshing is happening when the selection disappears?

Regards
Tom
Liviu Andronic
2012-05-23 14:00:11 UTC
Permalink
Post by t***@onepost.net
Liviu, you'll need to provide some more insight. The behaviour you report does not happen here, and it's not obvious where to look for a problem.
For example - just one item selected, or a few, or many?
One item.
Post by t***@onepost.net
If more than one, and they include multiples of the same type, do those all get de-selected?
Does it matter whether the file has an extension?
No. I've tried extension-less executable files as well as various
extensions: .txt, .sh, etc.
Post by t***@onepost.net
Does it matter what such extension is?
Does it matter whether the filelist is scrolled away from its top position?
I can replicate this with a filelist in top position and in a middle position.
Post by t***@onepost.net
What if any refreshing is happening when the selection disappears?
I think a refresh is happening, but it is not user initiated.

Would a log help? In any case, I prepared a short video exhibiting the
issue. [1]

Liviu

[1] http://s000.tinyupload.com/index.php?file_id=56999425241393741087
Adam Krolnik
2012-05-23 19:05:12 UTC
Permalink
Hi Tom;

For setting environment variables (maybe internal variables too), can we
have a delimiter that is removed from the value before setting it in the
environment ?

For example I was trying to set the GREP_COLOR environment variable to
48;5;230.
Without delimiters, this is taken as three commands:

% set GREP_COLOR 48;5;230

The 5 and the 230 have errors issued about them.
But if I surround the value with ' ' or " ", the value contains them.

% set GREP_COLOR "48;5;230"
% echo $GREP_COLOR
"48;5;230"


% cat delimiter_strip.patch
*** e2_command.c 2012-05-22 08:28:04.812745000 -0500
--- e2_command-old.c 2012-05-23 11:55:00.679443000 -0500
***************
*** 2696,2701 ****
--- 2696,2707 ----
}
}

+ if (*value == '"')
+ {
+ value++;
+ gchar *vend = strchr(value, '"');
+ *vend = '\0';
+ }
if (value != NULL)
result = (g_setenv
(command2, value, TRUE)) ? 0 : 1;
else
% set GREP_COLOR "48;5;230"
% echo $GREP_COLOR
"48;5;230"

%
--
Adam Krolnik
t***@onepost.net
2012-05-24 02:31:08 UTC
Permalink
On Wed, 23 May 2012 14:05:12 -0500
Post by Adam Krolnik
Hi Tom;
For setting environment variables (maybe internal variables too), can we
have a delimiter that is removed from the value before setting it in the
environment ?
Done. Also, escaping the ';' chars now works as intended.

Regards
Tom
Liviu Andronic
2012-05-24 05:26:22 UTC
Permalink
Post by Liviu Andronic
Would a log help?
Here comes the log. The issue happens in between these log lines:
[DEBUG ] focus row is 46
[DEBUG ] setup to clear stores later
[DEBUG ] NO need for encoding conversion change after refresh
[DEBUG ] enable refresh, fileview_refresh list
[DEBUG ] 1 old liststore(s) cleared
[DEBUG ] _e2_context_menu_selected_cb, menu: 13e41a0
[DEBUG ] e2_utils_key_translate_cb, key: 65307 widget: 11d93b0
[DEBUG ] e2_utils_key_translate_cb, key: 65513 widget: 11d93b0
[DEBUG ] _e2_fileview_key_press_cb, key 65513
[DEBUG ] In _e2_fs_FAM_inotify_timeout, for target 1


The below is the similar log lines for a non-executable, i.e. without
the unselect issue:
[DEBUG ] focus row is 48
[DEBUG ] setup to clear stores later
[DEBUG ] NO need for encoding conversion change after refresh
[DEBUG ] enable refresh, fileview_refresh list
[DEBUG ] 1 old liststore(s) cleared
[DEBUG ] _e2_context_menu_selected_cb, menu: 13eb330
[DEBUG ] e2_utils_key_translate_cb, key: 65307 widget: 11d93b0
[DEBUG ] In _e2_fs_FAM_inotify_timeout, for target 1
[DEBUG ] callback: mouse button 3 press event type 4
[DEBUG ] _e2_context_menu_selected_cb, menu: 153fe30
[DEBUG ] e2_utils_key_translate_cb, key: 65307 widget: 11d93b0
[DEBUG ] e2_utils_key_translate_cb, key: 65513 widget: 11d93b0
[DEBUG ] _e2_fileview_key_press_cb, key 65513


Regards
Liviu
t***@onepost.net
2012-05-24 07:07:13 UTC
Permalink
On Thu, 24 May 2012 07:26:22 +0200
Liviu Andronic <***@gmail.com> wrote:

The only candidate I can think of for changing a selection (other than the user, of course) is filelist refreshing. However that involves logging the selected items, and reinstating their selection after the view is refreshed, so there will appear to be no change. And that has worked happily for ages.

So here's the question: why does the process not work for you, for one particular type of file?

I can't see anything to answer this, in the supplied log.

For now, can you check and report what happens to the selection if several similar items are selected when you pop up a context menu. Say, those various compiz-related items shown in the .ogg file.

And ditto for several items selected, of which > 1 but not all are executable scripts.

Regards
Tom
Post by Liviu Andronic
Post by Liviu Andronic
Would a log help?
[DEBUG ] focus row is 46
[DEBUG ] setup to clear stores later
[DEBUG ] NO need for encoding conversion change after refresh
[DEBUG ] enable refresh, fileview_refresh list
[DEBUG ] 1 old liststore(s) cleared
[DEBUG ] _e2_context_menu_selected_cb, menu: 13e41a0
[DEBUG ] e2_utils_key_translate_cb, key: 65307 widget: 11d93b0
[DEBUG ] e2_utils_key_translate_cb, key: 65513 widget: 11d93b0
[DEBUG ] _e2_fileview_key_press_cb, key 65513
[DEBUG ] In _e2_fs_FAM_inotify_timeout, for target 1
The below is the similar log lines for a non-executable, i.e. without
[DEBUG ] focus row is 48
[DEBUG ] setup to clear stores later
[DEBUG ] NO need for encoding conversion change after refresh
[DEBUG ] enable refresh, fileview_refresh list
[DEBUG ] 1 old liststore(s) cleared
[DEBUG ] _e2_context_menu_selected_cb, menu: 13eb330
[DEBUG ] e2_utils_key_translate_cb, key: 65307 widget: 11d93b0
[DEBUG ] In _e2_fs_FAM_inotify_timeout, for target 1
[DEBUG ] callback: mouse button 3 press event type 4
[DEBUG ] _e2_context_menu_selected_cb, menu: 153fe30
[DEBUG ] e2_utils_key_translate_cb, key: 65307 widget: 11d93b0
[DEBUG ] e2_utils_key_translate_cb, key: 65513 widget: 11d93b0
[DEBUG ] _e2_fileview_key_press_cb, key 65513
Regards
Liviu
Liviu Andronic
2012-05-24 08:43:19 UTC
Permalink
Post by t***@onepost.net
The only candidate I can think of for changing a selection (other than the user, of course) is filelist refreshing. However that involves logging the selected items, and reinstating their selection after the view is refreshed,
Likely this is what fails in some cases.
Post by t***@onepost.net
so there will appear to be no change. And that has worked happily for ages.
So here's the question: why does the process not work for you, for one particular type of file?
Well, I'm getting similar behaviour in other contexts, not reported
because I couldn't find any definite recipe to replicate. For example,
I often get deselection when I:
- select a file
- view it via F3
- ~1sec after the View window pops up, in the background the item
previously opened will get de-selected
- it doesn't matter if the file is executable or not, and I'm pretty
sure this deselection is accompanied by an automatic refresh

I tried to shoot a video of the above, but no luck getting it on camera.
Post by t***@onepost.net
I can't see anything to answer this, in the supplied log.
Is it possible to increase the verboseness of the log mechanism, so
that I could test using a custom build?
Post by t***@onepost.net
For now, can you check and report what happens to the selection if several similar items are selected when you pop up a context menu. Say, those various compiz-related items shown in the .ogg file.
And ditto for several items selected, of which > 1 but not all are executable scripts.
When selecting two non-executables all is as expected. But I do get an
interesting pattern when selecting several mixed (or only exec files)
files.

It seems that the exec item that gets deselected is always the one
that has been right-clicked upon. See video [1] and attached log. I
suspect that emel somehow logs a 'right-click' as a 'deselect' action,
and when reinstating the selected items after an automatic refresh the
one that was right-clicked is reinstated as deselected.

Liviu

[1] http://s000.tinyupload.com/index.php?file_id=57016188077429078740
t***@onepost.net
2012-06-02 01:17:00 UTC
Permalink
On Thu, 24 May 2012 10:43:19 +0200
Liviu Andronic <***@gmail.com> wrote:

Liviu reports that this is now solved. Turned out to be related to filename filtering.

Regards
Tom

Loading...