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

DocSavage · « **Reply #275 on:** February 09, 2007, 06:24 PM »

I, too, would like the link to ver 2.00.45
Thanks,
dk

mouser · « **Reply #276 on:** February 09, 2007, 06:32 PM »

ps. no need to post when you want to try the alpha, just click the little balloon icon under my name on the left and send me a private message requesting the download.

perlguy · « **Reply #277 on:** February 09, 2007, 07:24 PM »

Quote from: mouser on February 09, 2007, 06:27 PM

Let's see how many of your requests already exist
you can now hide column headers, status bar, and toolbar (just drag toolbar to full right and buttons are gone

Hmm... gained 1 new feature (hide headers), learned about 1 existing feature (shoving toobar off the window) and lost one old feature: I can get used to it, but I really liked having the "Edit Bar at Bottom" option. I could park FARR at/near the bottom of the screen, and the edit bar would always be in the same place, and the window would grow/shrink above it.

Also maybe already covered here) the Results Display Style radio buttons are greyed out - so no small icons/large icons available - which I never use, just thought I'd mention it.

Quote from: mouser on February 09, 2007, 06:27 PM

Check out the path completion and hopefully it does what you want.
-mouser

Pretty close - again, it's not exactly the same behaviour as the Run box but it's something I think I could get used to.

Being able to scroll through all files/folders is handy sometimes. But that would mean having an option to enable Explicit Directory Searching to use a scrolling listbox for output instead a static display of the N item, ordered search results window you currently use. The scrolling list would be alpha sorted, preferably (or make options available to change sort order).

Another useful option related to this would be separate max limits for normal searches vs. explicit directory searches? For normal searches, 9 items has always been plenty - I don't think I've ever gone past the 3rd result item. But for file/directory browsing, I could see needing as many as 50 results visible - if scrolling all results is not an option.

And if you add back in the option of "Edit Box at Bottom", could you add an option to reverse the display of the search results - #1 at bottom?

mouser · « **Reply #278 on:** February 09, 2007, 07:36 PM »

the idea to add a separate limit for dir completion results (presumably higher than for file searching) is not a bad idea at all.

perlguy · « **Reply #279 on:** February 09, 2007, 07:52 PM »

Something else for a feature request: Edit Box and Display Results font selection.

Is it by design that the new Edit Box font is different than the list results?

jgpaiva · « **Reply #280 on:** February 09, 2007, 07:53 PM »

+1 for separate limits. I used to use 9 results and had to change to 20 results after dir search came up. I think this option would solve that problem.

JennyB · « **Reply #281 on:** February 09, 2007, 09:36 PM »

Quote from: perlguy on February 09, 2007, 07:24 PM

Being able to scroll through all files/folders is handy sometimes. But that would mean having an option to enable Explicit Directory Searching to use a scrolling listbox for output instead a static display of the N item, ordered search results window you currently use. The scrolling list would be alpha sorted, preferably (or make options available to change sort order).

Another useful option related to this would be separate max limits for normal searches vs. explicit directory searches? For normal searches, 9 items has always been plenty - I don't think I've ever gone past the 3rd result item. But for file/directory browsing, I could see needing as many as 50 results visible - if scrolling all results is not an option.

That sounds like what I've been suggesting. When you do a tab completion FARR doesn't know yet which file you are looking for (maybe you don't either!) so the most helpful thing it can do is throw up a scrolling list of the folder contents, with the focus on the list. Right arrow drills down further if on a folder, left arrow backs out. Any character key echoes to the input box, shifts the focus there and narrows the results.

perlguy · « **Reply #282 on:** February 10, 2007, 05:23 AM »

Quote from: JennyB on February 09, 2007, 09:36 PM

That sounds like what I've been suggesting. When you do a tab completion FARR doesn't know yet which file you are looking for (maybe you don't either!) so the most helpful thing it can do is throw up a scrolling list of the folder contents, with the focus on the list. Right arrow drills down further if on a folder, left arrow backs out. Any character key echoes to the input box, shifts the focus there and narrows the results.

Yes, that's a much better explanation of the behavior I'd like to see.

mouser · « **Reply #283 on:** February 10, 2007, 05:34 AM »

remember that the farr keyboard maniac answer for this is:
tab autocompletes with the top item in the list
alt+# autocompletes with other suggestions.

or you can down arrow to the suggested subdirector and then right arrow to autocomplet into it.
alt+left arror backs up a directory.

so i think this stuff already exists..

perlguy · « **Reply #284 on:** February 10, 2007, 05:48 AM »

Agreed. Except for the scrolling list of all contents at current level. That's really the big thing that's missing. Navigation is just retraining muscle memory from the Run box behavior. But if there's a 100 folders, and you just want to browse through them, that's impossible to do unless you set max results to 100.

In addition to adding "max directory search results", how about adding a "max listbox rows" option. If your max results option is set high enough, and you have more than "max listbox rows" results, you get a scrolling listbox.

mouser · « **Reply #285 on:** February 10, 2007, 05:55 AM »

yes, i thnk i can do this.

tranglos · « **Reply #286 on:** February 12, 2007, 03:01 PM »

I was going to post a request regarding the UI, but having seen the latest version, I have no more requests

I really needed a larger, bold font in the search entry box; it's perfect right now.

The only other thing I would mention is that there is quite a bit of flicker on painting windows, esp. the options dialog, since it's larger, but also perceptible in the main window. When using a skin, you can see the dialog being drawn without the skin, then redrawn properly. (Actually, it seems to flicker three times, but it is a little too fast to be sure.) The effect is diminished when disabling skins: the flicker still exists, but is less obvious. My system is not the newest, but it was spec'ed to run Doom3 at the high quality, and it did

I only ever see similar flicker in some .Net apps, but that doesn't apply to FARR. Probably just some inefficiency in the skinning engine?

mmenfin · « **Reply #287 on:** February 13, 2007, 08:28 PM »

hi

i'm french, using a azerty keyboard, and i can't type the \ character in the search box (altgr+8 on azerty). it runs the "show shell context menu" on the 8th result... if i remove the corresponding ctrl+alt+# shortcut, it doesn't work at all. nothing. i can't type a full path in the search box.

mouser · « **Reply #288 on:** February 14, 2007, 01:37 AM »

tanglos the flicker is kind of crazy when displaying the options form i know - ive tried to fix it but the skin engine (vclskin) has some oddities.

mmenfin - ok let's find a solution because that sounds unbearable!
i'm trying to think what the best solution is.. it sounds painful not having an easy \ key on your keyboard that sounds crazy. when you say altgr+8 is supposed to be the \ character, what does altgr mean? is it just alt key or only RIGHT alt key? at the least i think i should be able to make it so you can disable alt+# key launching and use your alt+8 to put in a \.

nitrix-ud · « **Reply #289 on:** February 14, 2007, 10:18 AM »

Hi mouser,

i have an azerty keyboard but use it as a qwerty (which is much better for programming)
the alt gr (i think it means alternate graving) is the one on the right

Cheers !

mouser · « **Reply #290 on:** February 14, 2007, 10:22 AM »

ah ok, well that makes life easier and i will try to see if i cant at least make it so you can still use rightalt+# to generate such keys, while left alt+# launches them.

ps.
if anyone is wondering why its been a week since the last farr update it's because im working every day on the new plugin system which will be used in farr and my other programs as well

mmenfin · « **Reply #291 on:** February 14, 2007, 07:22 PM »

yes, the altgr is the right alt key on azerty, it is used to type some special characters. the \ is the third character on the 8 key, first is _ , second is 8 (shift+8).

thanks if you can change something

TucknDar · « **Reply #292 on:** February 16, 2007, 09:49 PM »

Some issues (using latest Alpha on XP Home)

1. Focus. Even with "Always maintain focus" on, focus sometimes shifts to another window, which can be pretty annoying. I can't seem to find any pattern when or how this happens, but it does from time to time. Note that I have window focus follow the mouse pointer, the window under the pointer is raised and focused after 500ms (or thereabout....), but I didn't have this problem with the latest full release.

2. Tooltip stays on top when exiting FARR. This occurs when the pointer hovers over any result, and I exit the FARR window with Esc. See screenshot
[attachimg=#1]

3. List results all displayed in lowercase. This one's a bit weird, when previously launched results (i.e. based on date and/or score) are launched from the list without typing anything, just using the numpad keys, upon next launch of FARR the result is all in lowercase... Look at the screenshot:
[attach=#2]
As you can see only two results contain uppercase letters, and these are the newest entries in the list, and hasn't been launched by pressing the corresponding number key. I'm sure that after I launch it with the number keys, it'll be displayed in lowercase letters.

This is not a big problem, but it's weird and makes reading the result list slightly more difficult.

Hope this helps. I'll be happy to elaborate on any of these issues if needed. I might stop by IRC later tonight, too, btw.

tranglos · « **Reply #293 on:** February 16, 2007, 10:32 PM »

Quote from: TucknDar on February 16, 2007, 09:49 PM

2. Tooltip stays on top when exiting FARR. This occurs when the pointer hovers over any result, and I exit the FARR window with Esc.

It may not be a FARR issue. On XP SP2, I see this happen all the time with other programs, notably Firefox. If there is a bug, it could be in Microsoft's window manager, since a tooltip window should not outlive the application window.

TucknDar · « **Reply #294 on:** February 16, 2007, 10:37 PM »

ah, ok, that could be right. I haven't seen this in other applications since switching to xp recently, though.

mouser · « **Reply #295 on:** February 17, 2007, 03:59 AM »

TucknDar: All your comments i agree with, and will be fixing. I've been working on my plugin system for last couple of weeks and i've finally got it working (at least the basics) so as soon as i wrap that up ill get back to ironing out all these issues and then we can have something nice

TucknDar · « **Reply #296 on:** February 17, 2007, 08:17 AM »

Excellent, mouser!

Looking much forward to the plugin system

dclagoa · « **Reply #297 on:** February 20, 2007, 10:18 AM »

Hi all,
since last week i have also noticed the "bug" with the tooltips as TucknDar pointed out, don't know if as tranglos said is a winxp issue, but i haven't noticed the tooltip in any other application as far as I remember. I also don't know if the farr main window is created/destroyed from the tray or it's simply hidden/showed, if it is destroyed, definitely is a winxp bug, if it is only hidden, maybe it could be a farr bug.

I'm also wainting eagerly for the plugin system. It would be cool a plugin to interact with foobar2000.

jgpaiva · « **Reply #298 on:** February 20, 2007, 11:10 AM »

+1 for the tooltip bug (not that's a big issue)

I also have another bug to report. If you search for a file and use the right-click menu to launch it, farr stays up. The problem is that it can get on the background, and pressing the hotkey won't bring it forward. So, i just ended up thinking that farr became unresponsive when what really happened was that it was the last window in the Z-order and the hotkey wouldn't make it come up.

mouser · « **Reply #299 on:** February 20, 2007, 11:21 AM »

keep the bug reports coming - it's not that i'm not listening it's that im working every day on plugin system and some new features that i think are very cool.

i finally added ability to filter and score within an alias. so if you have an alias group list of 20 programs you can now type the alias name followed by some more words to filter and score from within your list. extrememely useful if you have big aliases.

i also added a feature Joto calls search templates, which basically lets you make regular expression shorthands for more complicated searches:

This can be very useful when you have certain search strings that you reuse often.

For example, let's say you often do a searches like this :

+audio .mp3 Dylan
+audio .mp3 Blondie
+audio .mp3 Bratmobile

You can now create an alias which makes this easier. Just create a new alias, give it any name you want, and choose a regular expression pattern, like

^msearch (.*)

And now the important part. for the results, put a single entry as follows:

dosearch +audio .mp3 $$1

Now when this pattern is matched by the user typing something like:

msearch Dylan

Then FARR will behave as if the user had typed:

+audio .mp3 Dylan