Focus bugs

[serendipity]

I can best describe this with an example:

1. Say I have a file called xy.txt
2. I click on this file (which should select and focus it).
3. type ::msg <curname> in addressbar and I get xy.txt which is OK.
4. Click away from xy.txt so that it is unselected but still focused.
5. Now, select xy.txt by NOT clicking on the filename but by making a selection rectangle.
6. The ::msg <curname> now returns empty, even though the file is both focused and selected.
Not a biggie, but it seems unconsistent. Can anyone reproduce this?

A related bug: There is no way to bring focus to the file which has been selected by selection rectangle using scripting.

[jacky]

Yeah, that's a known behavior that, if I got things right, is actually "expected"/normal behavior, because that item is both focused&selected yet is not the "current item" (and his name ain't shown on statusbar)

It's been bugging me as well (and I'd say it should become the current item), especially when working on script, which is why I sometimes use the To Clipboard functions to actually use the first item on selection (if any) instead of the current item.

It's not really the same, but at least for what I wanted to do that worked better!

Here's a little example, in this one you get the full path to the first item in selection, if no selection then current path:

Code: Select all

	set $clipboard, <clipboard>;
	#101;
	set $curitem, <clipboard>;
	copytext $clipboard;
	strlen $l, $curitem;
	strpos $p, $curitem, <crlf>;
	regexreplace $p, $p, "^-1$", "$l";
	substr $curitem, $curitem, 0, $p;
	msg $curitem;

[serendipity]

Here's a little example, in this one you get the full path to the first item in selection, if no selection then current path:

Code: Select all

	set $clipboard, <clipboard>;
	#101;
	set $curitem, <clipboard>;
	copytext $clipboard;
	strlen $l, $curitem;
	strpos $p, $curitem, <crlf>;
	regexreplace $p, $p, "^-1$", "$l";
	substr $curitem, $curitem, 0, $p;
	msg $curitem;

Nice, I was looking to make something like this myself. Thanks for that Jacky. I would say this non-focusing issue should be fixed somehow internally in XY.

[admin]

Yeah, that's a known behavior that, if I got things right, is actually "expected"/normal behavior, because that item is both focused&selected yet is not the "current item" (and his name ain't shown on statusbar)

It's been bugging me as well (and I'd say it should become the current item), especially when working on script, which is why I sometimes use the To Clipboard functions to actually use the first item on selection (if any) instead of the current item.

The reason for this old behavior (> 8 years) is that a "current item" is auto-previewed, and I gathered that in a couple of situations you do not want a preview to be started. But in fact I think the whole thing can be improved... I put it on my list.

[admin]

Yeah, that's a known behavior that, if I got things right, is actually "expected"/normal behavior, because that item is both focused&selected yet is not the "current item" (and his name ain't shown on statusbar)

It's been bugging me as well (and I'd say it should become the current item), especially when working on script, which is why I sometimes use the To Clipboard functions to actually use the first item on selection (if any) instead of the current item.

The reason for this old behavior (> 8 years) is that a "current item" is auto-previewed, and I gathered that in a couple of situations you do not want a preview to be started. But in fact I think the whole thing can be improved... I put it on my list.

I slightly improved variable <focitem> in the next BETA:

Code: Select all

    * Variable <focitem> now returns
      - if Tree is focused: current path
      - else: currently focused file in List
      Before, it only returned currently focused file in List when the 
      List had focus.

I wonder if <curitem>, <curext>, etc should all refer to this (make <focitem> obsolete) instead of to the item that's currently on the Info Panel!?!? That would solve the problems mentioned in this thread...

Or maybe better and clearer:
- <curpath> and <curfolder> refer to Tree
- All other <cur...> refer to focused List item
Independent of focus!
Goody?

[jacky]

I wonder if <curitem>, <curext>, etc should all refer to this (make <focitem> obsolete) instead of to the item that's currently on the Info Panel!?!? That would solve the problems mentioned in this thread...

Nope, wouldn't be good I think because <curitem> implies a selected item, and there can be none, whereas there's always a focused item (and it might not be (one of the ones) selected)...

Or maybe better and clearer:
- <curpath> and <curfolder> refer to Tree
- All other <cur...> refer to focused List item
Independent of focus!
Goody?

hmm.. but doesn't <curpath> & <curfolder> already always return such info, regardless of where the focus is (ie. always refer to Tree) ??
And again, I don't thin <cur...> should refer to focused item, that ain't the same.

The ideal would be not to care what item is loaded on Panel or whatnot, and have <cur...> variables (except <curpath> & <curfolder>) to refer to the item both focused&selected, and if none be blank.

Of course when we'll have <numselected> and a way to scan through all selected files, things will get much easier.

[admin]

The ideal would be not to care what item is loaded on Panel or whatnot, and have <cur...> variables (except <curpath> & <curfolder>) to refer to the item both focused&selected, and if none be blank.

What can I say, jacky is right again!

[jacky]

What can I say, jacky is right again!

hehe.. you can't escape it