DonationCoder.com Software > FARR Plugins and Aliases

Plugin: AlbumDisplayer (BETA)

<< < (4/5) > >>

Nod5:
the alb * feature has been delayed by awesome weather, plenty of swimming in lakes and other distracting outdoor activities. Sorry about that.  ;D

I've tested it some more though. I'm unsure what the best design would be. If I let it first load 50 covers and then load 50 more each time the user scrolls to the bottom then there's a noticeable freeze for a second or more with each additional 50 cover load. This happens the first time for each cover during a session. The covers seems to be cached after that.

I tried decreasing the number of albums to display at each bottomscroll to 20. That shortened the freeze but on the other hand gave a larger number of freezes.

I think the best thing would be to incrementally inject more covers at a pace that does not cause the freezes but still does not feel slow. I'm unsure how to do that in javascript however.

Another idea is to initially let alb * display 50 covers plus empty image frames for all the rest of the albums. FARR would then incrementally keep loading the rest of the images into those frames until the user does some other FARR action.

Any thoughts?

TucknDar:
the alb * feature has been delayed by awesome weather, plenty of swimming in lakes and other distracting outdoor activities. Sorry about that. -Nod5 (August 01, 2008, 05:20 PM)
--- End quote ---
How dare you!?!?!? 8)

I can see what you mean about the freezes, not really ideal. Does it make any difference if the album images are smaller? Or maybe let user type how many albums to display, so that the user can decide how much "freezing" is acceptable or how many albums at the time alb * should display.

I'd be happy to test any work in progress!

Nod5:
AlbumDisplayer v080813 v080814
-- link removed, use newer version below -- (md5 ebb905356dd7aa7e3a27ece19302de1e)
changelog:
v080814
- folders with ' in path now works
v080813
- now trims all % in input to avoid FARR crash (example: "alb abc%" previously caused crash)
- special search phrase "alb *" displays all albums (first 100 then 50 more at each scroll to page bottom)
- ctrl+click album to open its folder

Let me hear your impressions on "alb *" - does it freeze FARR too long/too often?

Nod5:
One year later...  

I'm trying to update this plugin to use a non-static index via Everything.exe !
I have done this:
- changed Fscript to call new autohotkeyscript getindex.exe
- set getindex.exe to search Everything.exe via command line through es.exe (re-using code from Skrollster's InEverything script - thanks!) and generate albumindex.txt index file on the fly
- changed FScript to thereafter load album.html
- changed album.html to not filter anything and instead display all in albumindex.txt

This works roughly but is not optimal. I need to reliably wait with the html loading until the indexing is completed.
As of now I do this:

FARR.setStrValue("launch", currentDirectory + "\\getindex.exe " + albtemp);
FARR.setstrvalue("launch", "sleep " + 200);
FARR.setStrValue("launch","htmlviewurl " + currentDirectory + "\\album.html");
--- End quote ---

But regardless of what sleep time I put in FARR often displays a blank html (with no thumbnails). Clicking in the FARR window and pressing F5 (refresh) displays the thumbnails correctly.

In general I'd like to re-work the plugin like this: (1) f(sub)script calls everything es.exe directly, (2) gets matches back IN MEMORY, (3) generates HTML output IN MEMORY and (4) pushes it to FARR. That would rid the need for an extra autohotkey, an index txt, a html file.

But I don't have the F(sub)script skills that it takes ATM - that's why I'm taking the detour through autohotkey. Does the above seem doable? Any pointers on commands needed? Especially on (2), (3) & (4). edit: and possibly on doing (1) by FARR internal calls to the TinyEv plugin instead.

edit: I would also like some way to let FARR keep the html output displayed even when new text is typed in the inputbox AS LONG AS that text stays within the plugin alias. I.e. if the user has typed "alb beatl" and now enters "alb beatle" then FARR first offloads the html, goes through the other plugin steps and then reloads the html. I want it to not offload the html if possible.

Nod5:
I never got this sorted  :( Tried both to solve it through changes in the .html (javascript to reload once after some time) and in the .js but without success. So I'm reverting to the previous alb version, at least for the moment. I'll just mod it so that the static index is generated via Everything since that is so much faster compared to a autohotkey file loop. That would be some progress, though not as much as I had aimed for.

Navigation

[0] Message Index

[#] Next page

[*] Previous page