Lister flickering
Moderators: white, Hacker, petermad, Stefan2
-
majkinetor !
- Power Member
- Posts: 1580
- Joined: 2006-01-18, 07:56 UTC
- Contact:
-
StickyNomad
- Power Member
- Posts: 1933
- Joined: 2004-01-10, 00:15 UTC
- Location: Germany
-
majkinetor !
- Power Member
- Posts: 1580
- Joined: 2006-01-18, 07:56 UTC
- Contact:
2StickyNomad
Check out the new version.
BTW, editing plugin is not plugin at all. That is Edit Plus.
I use it because it is xtremely fast for the editor with such number of features (starts llitter slower then Notepad) and it has all options good editors have. I created portable version. If you need it, just drop me a mail.
If people are interested and if people on TotalCmd.net support my idea to change plugin API, that is, to add new function that will eliminate flickering I will rewrite the plugin to dll so Alex can integrate it. With flickering present, I just don't have enough will to do so but I will continue to update QV script to perfection. The script at release state will be mergable (of course) so you can add it among your startup scripts to eliminate separate AHK instance just for that.
Check out the new version.
BTW, editing plugin is not plugin at all. That is Edit Plus.
I use it because it is xtremely fast for the editor with such number of features (starts llitter slower then Notepad) and it has all options good editors have. I created portable version. If you need it, just drop me a mail.
Check out the new version.icfu wrote:Impressive video!
If people are interested and if people on TotalCmd.net support my idea to change plugin API, that is, to add new function that will eliminate flickering I will rewrite the plugin to dll so Alex can integrate it. With flickering present, I just don't have enough will to do so but I will continue to update QV script to perfection. The script at release state will be mergable (of course) so you can add it among your startup scripts to eliminate separate AHK instance just for that.
Habemus majkam!
-
StickyNomad
- Power Member
- Posts: 1933
- Joined: 2004-01-10, 00:15 UTC
- Location: Germany
-
majkinetor !
- Power Member
- Posts: 1580
- Joined: 2006-01-18, 07:56 UTC
- Contact:
I just realised that some of you, including Ghisler didn't understand problem:
Flicker should be eliminated for situation in witch the same plugin is called again. NOT when another plugin is called.
I will describe precisely eatch situation. I will reference both quick view and N/P key movement, since Lister flickers in both cases. The new function that should be added to WCL API I call ListReload
The point here is that people are usualy working with the large collections of same file types, or different file types handled by the same plugin (like music or images).
If user set JPG to be handled by P1 and GIF to be handled by P2, then it is his desire to have different plugins for the same thing, so it is responsible for flickering, which would not be there if JPG & GIF would be handled by the same plugin. In this case, user can sort the list by file type, and browse first group by P1 and second by P2.
In situation where many different file types are browsed Lister will flicker but, this is less probable scenario for 99% of users. U usualy browse single file types or file types belonging to the same category.
This mechanism can also be upgraded not to flicker for different file categories, but lister API will not have to be additionaly changed. Some smart caching and initial folder scanning to see all possible file types in the folder/selection can do the job. However, typical user, even advanced user will have little benefits. This is for special situations and so, it doesn't have to be considered now. However, it is nice to know that the same API update will allow even this scenario to be handled (for instance, by my Quick View script version 2.0
)
Flicker should be eliminated for situation in witch the same plugin is called again. NOT when another plugin is called.
I will describe precisely eatch situation. I will reference both quick view and N/P key movement, since Lister flickers in both cases. The new function that should be added to WCL API I call ListReload
- [face=arial]User opens the Quick View. Lister opens in oposite panel with currently selected file. Plugin P1 on the top of the list handles the call.
1. User selects another file F
If F is handled by the P1, call its ListReload. If F is file handled by some other plugin, P2, close P1 and open P2 normaly.
2. User moves to another plugin P2 by pressing the hotkey for next plugin in the order. Then he moves to another file F.
If F is handled by P2 don't close it and open P1 but remember users choice and open F in P2. If F is handled by another plugin, do the same as in 1.[/face]
The point here is that people are usualy working with the large collections of same file types, or different file types handled by the same plugin (like music or images).
If user set JPG to be handled by P1 and GIF to be handled by P2, then it is his desire to have different plugins for the same thing, so it is responsible for flickering, which would not be there if JPG & GIF would be handled by the same plugin. In this case, user can sort the list by file type, and browse first group by P1 and second by P2.
In situation where many different file types are browsed Lister will flicker but, this is less probable scenario for 99% of users. U usualy browse single file types or file types belonging to the same category.
This mechanism can also be upgraded not to flicker for different file categories, but lister API will not have to be additionaly changed. Some smart caching and initial folder scanning to see all possible file types in the folder/selection can do the job. However, typical user, even advanced user will have little benefits. This is for special situations and so, it doesn't have to be considered now. However, it is nice to know that the same API update will allow even this scenario to be handled (for instance, by my Quick View script version 2.0
)Habemus majkam!