Author Topic: Latest FARR v2.00.140 ALPHA PREVIEW Release - Aug 15, 2007 (Read 634000 times)

mouser · « **Reply #725 on:** July 13, 2007, 10:39 AM »

add +sall to your search to see more results (i removed it from the context menu).

the extended results list is used mainly for directory browsing+completion. for example, type c:\ and youll see.

jack99999 · « **Reply #726 on:** July 13, 2007, 01:37 PM »

i'm using 2.00.128

i have settings not too dissimilar from those shown by justice. i've been experimentining with them a little... currently:

max files in history: 50
max entries to display: 15 ( a recent change, mostly i've been on 9)
max entries in extended: 30

however, the problem is not general performance or general searching. it's when the search seems to be for one or perhaps two characters, resulting in over 400 hits (although only a small fraction are displayed, of course)

jack

mouser · « **Reply #727 on:** July 13, 2007, 10:33 PM »

New version posted -- the updater tool should have picked it up and installed it for you if you are using it.
(the updater now knows how to smoothly update plugins without ever exiting farr, for maximum convenience).

New version has sine nice new fixes, including much faster directory browsing.

jack99999 · « **Reply #728 on:** July 14, 2007, 12:42 AM »

i'm using .129

Tab completion problem...

when i start with 'C:\Program Files' the first item in the listing is 'C:\Program Files'. pressing Tab does nothing, which is not surprising because the first entry matches what i just typed. Tab does pick up whatever line i put the cursor on, but i can't get the top entry because it's the same as the current text.

i haven't tried the Tab before, so i'm not sure whether this is a bug or a feature... but it feels like a bug.

cheers

jack

mouser · « **Reply #729 on:** July 14, 2007, 12:45 AM »

i'm not sure if it's a bug either.. it's waiting for you to type something to tell it which directory to go into next, since the first directory listed is exactly what you have in your editbox.

i could make tab in this case autocomplete the NEXT item, which is the first child subdirectory of the current directory.

jack99999 · « **Reply #730 on:** July 14, 2007, 03:17 AM »

i think that would be a good thing to do, although it might be a little confusing. it's difficult to tell without experiencing it

jack

jgpaiva · « **Reply #731 on:** July 14, 2007, 04:55 AM »

"c:\program files" appears as the first result because that's intended to be launched by pressing -enter-. It wouldn't make sense not to be the first result, since that's the best match for the text on the editbox.

As for having -tab- autocompleting to the first entry after "c:\program files", that sounds a bit confusing, it'll probably surprise people.

justice · « **Reply #732 on:** July 14, 2007, 07:38 AM »

Woah browsing directories is blazingly fast now! Right that's Folderscout of the disk then!

mouser · « **Reply #733 on:** July 14, 2007, 11:05 AM »

I have now uploaded version 2.00.130

I have made a big under-the-hood change the way that the window is refreshed with new contents.

There is a fair chance that this update will have a bug or two in display updating in some cases but i wanted to push it out to get bug reports coming in as soon as possible.

The new refresh is *MUCH* smoother -- if you try out previous versions, expecially in directory browsing, you would see lots of "flickering" as new window contents were updated and window was shrunk and resized. You should find now a much gentler update of window contents.

Let me know what you think.

jack99999 · « **Reply #734 on:** July 14, 2007, 11:38 AM »

now trying .130

i can't tell whether it's much smoother, cos it's running on my work machine and i need a vpn connection to it today.

however, i discovered that my long wait problem seems to depend on which folders it searches. when i include the desktop the searches can take ages. remove the desktop, it's quick. put the desktop back again and it's slow.

does this make any possible sense? is there something different about the desktop?

jack

nitrix-ud · « **Reply #735 on:** July 14, 2007, 12:02 PM »

I have made a big under-the-hood change the way that the window is refreshed with new contents.

There is a fair chance that this update will have a bug or two in display updating in some cases but i wanted to push it out to get bug reports coming in as soon as possible.

The new refresh is *MUCH* smoother -- if you try out previous versions, expecially in directory browsing, you would see lots of "flickering" as new window contents were updated and window was shrunk and resized. You should find now a much gentler update of window contents.

Let me know what you think.

this rocks !

mo more flickering

Implemented small (500ms) delay between updating of results -- yields much faster directory browsing and somewhat faster display of results when there are lots of results.

It would be great if one could set up the delay between updating of results...
I almost always use FARR with aliases (folder modifier with action modifier, ...) so in fact i have the impression the delay (even small) does not yield to faster display of results

mouser · « **Reply #736 on:** July 14, 2007, 12:08 PM »

what i can do is force update IMMEDIATELY after aliases are found, which would solve this problem.

nitrix-ud · « **Reply #737 on:** July 14, 2007, 01:27 PM »

@mouser

i'm mainly using "dosearch alias", so i'm not sure it would work

i type the "dosearch alias", then the search terms...

Cheers, Nitrix

jdmarch · « **Reply #738 on:** July 14, 2007, 01:47 PM »

130... much cleaner display, lovely.

nitrix-ud · « **Reply #739 on:** July 15, 2007, 06:40 AM »

@mouser,

since the new "refresh result routines", i have the impression that the search edit box is not as "free" as before
sometimes there is a (very very small) delay to show what i type or what i delete

i reinstalled a previous version (a private 2.00.129 where the refresh routines were not implemented yet) and although there are many flickering...
the search edit box feels much more responsive

In conclusion, i prefer the responsiveness of the search edit box than the "non flickering" of the result list
(that is if we cannot have both !

)

if it is only linked to the new small delay implemented between result updating, i would be great to be able to set it (even in the FARR ini...)

Keep up the good work

mouser · « **Reply #740 on:** July 15, 2007, 07:49 AM »

i'm working to make it feel more responsive.

zajc · « **Reply #741 on:** July 16, 2007, 11:58 AM »

I noticed the same issue as "nitrix-ud".

Anyway, keep up the good work

mouser · « **Reply #742 on:** July 18, 2007, 12:00 AM »

new version is up -- those of you who prefered the old refresh method -- can you see if this one is any better.

keep in mind, yes there is a slight delay now between your keypress and the update of the display of results, but in fact the underlying search should be a little faster.

that's not to say that you won't prefer the old method. just a reminder that we aren't talking about a slower search.

anyway, let me know what you think since i'm making some hard decisions here about how this should work.

nitrix-ud · « **Reply #743 on:** July 18, 2007, 04:19 AM »

new version is up -- those of you who prefered the old refresh method -- can you see if this one is any better.

it's not that i prefer the old refresh method, it's more that i prefer the old feel of the search box
i just feel it is not as "free" as before ... when typing or backspacing

keep in mind, yes there is a slight delay now between your keypress and the update of the display of results, but in fact the underlying search should be a little faster.

the delay between keypresses and update of the display of results is not my concern (although it would be great to choose which it is), what really concerns me is the fact I feel that the search box is linked to the display of results...
i'm not in the internals of FARR here... but is it possible to have a routine monitoring the search box and taking care of updating instead of (WARNING !!!

WILD GUESS) keypresses in the search box launching updates (with delays) of the display of results...

[edit]
i forgot to tell you that IT IS better !!
keep up the good work

jdmarch · « **Reply #744 on:** July 18, 2007, 04:41 AM »

I wasn't one who preferred the old refresh method, but I *was* silently concerned with a slight new feel of unresponsiveness which I did not analyze earlier. With the newest version, I think I can pin it down as follows (seems that this is what nitrix is saying too):

Yes, the result display is better. But the feel of unresponsiveness is not because of the result display but because of the display of the keys as I type them (just that one line). The user should never have any doubt whether her keystrokes have been received... or worse, be in any doubt about what keystrokes she has already typed. When a keystroke is received, top priority should be to update this line.

Mind you, this is really borderline, really close to perfect, just not quite.

justice · « **Reply #745 on:** July 18, 2007, 04:46 AM »

Actually I think it's perfect in build 133, the delay is not in the input box but only in the result view, which means in total the app is speedier. I guess it's similar to how browsers build up webpages, some wait till the page is complete, some build them up every so often, and really old ones show all the content jumping up and down

nitrix-ud · « **Reply #746 on:** July 18, 2007, 05:06 AM »

Yes, the result display is better. But the feel of unresponsiveness is not because of the result display but because of the display of the keys as I type them (just that one line). The user should never have any doubt whether her keystrokes have been received... or worse, be in any doubt about what keystrokes she has already typed. When a keystroke is received, top priority should be to update this line.

Mind you, this is really borderline, really close to perfect, just not quite.

exactly what i wanted to say, thanks jdmarch

jack99999 · « **Reply #747 on:** July 18, 2007, 05:07 AM »

i found the performance problem with including Desktop in the search.

i had a shortcut that went to something like:

\\DeadComputer

i deleted the shortcut and the performance problem disappeared. everything is just super now!

jack

TucknDar · « **Reply #748 on:** July 18, 2007, 05:12 AM »

But the feel of unresponsiveness is not because of the result display but because of the display of the keys as I type them (just that one line). The user should never have any doubt whether her keystrokes have been received... or worse, be in any doubt about what keystrokes she has already typed. When a keystroke is received, top priority should be to update this line.

Mind you, this is really borderline, really close to perfect, just not quite.
-jdmarch (July 18, 2007, 04:41 AM)

Have to agree with this. FARR is such a great app, and some excellent new and improved features, but the slight delay is a bit annoying. Could the behaviour be optional?

jdmarch · « **Reply #749 on:** July 18, 2007, 06:46 AM »

mouser, a multi-layered problem using FARR to run "add-remove program" (ARP).

1. FARR's ARP link doesn't work for me, either from FARR or directly from explorer. When it's invoked, nothing happens.

2. FARR's other CPL links seem to work fine, which is puzzling to me since (browsing their guts) they all seem to point to C:\WINDOWS\.... which does not exist on my system (my system is in D:\WINNT\). I guess Windows is smart enough to translate C:\WINDOWS to the actual system dir.

3. I have my own shortcut to ARP (it refers to D:\WINNT\...) which works fine from explorer but does not work from FARR (FARR finds it ok but when it is invoked, nothing happens, just as with FARR's own shortcut.) I reported this 3 months ago. At the time, you informed me that FARR now provides a full set of control panel links. From my response at the time, it appears that I was then able to run ARP using the FARR shortcut, but I don't actually remember this, and I'm not sure I really believe it given the above.

I'm running Win2K SP4.

Thanks!
====
Edit: Further investigation... this does not seem to be a FARR-specific issue. I wrote a batch file which invokes my own ARP link. If I call the batch file from within a command-line window, ARP starts, but if I invoke it from explorer, it does not. So there's something very screwy on my system about within what context ARP will start or not. I will not be able to spend much time investigating this further, unfortunately.

P.S. Could somebody else who runs Win2K on drive D: please try starting ARP using FARR's CP shortcut?