an idea about an alternative to multiple configuration files

[mouser]

i was thinking, what if, instead of alternate config files, you could specify for any of the search folders or pattern matching rules, a set of keywords that it was governed by.

for example you could say that certain folders only should be searched when the keyword mp3 was used.

then you could use these keywords when typing, to restrict to certain config options..

just an idea

[kfitting]

I'll admit, when I first read your idea, I didnt really care for it, mouser.  But, after having thought about it a little bit, I love it.  Perhaps you could make it something like this:     mp3:Artist    would return all files that have Artist in them and fit the already configured mp3 config file.  Or, C:help        would find all files wtih help in them based on the C config file.  Here the ":" is used as delimiter but you could choose one that doesn't require shift or make it customizable.

Another idea along these same lines and something that was talked about before, was the idea of file extension searching.  I think this is already implemented but it could follow very similar syntax.  eg, ogg.artist would find all ogg files with artist in the title or xls.budget would find all excel files.

Both of these ideas use a prefix to determine how to search... this makes more sense to me because FindRun searches as you type.  It seems weird to type in the search, get a bunch of hits then restrict them by extension or config file.  Better to load the config and then do the search.  Also, multiple config files could be loaded at once by doing something like ogg.mp3.artist or C:mp3:artist. 

Just some thoughts.  Let me know if i don't make sense!

Kevin

[mouser]

i didn't think of the fact that this would let you combine configurations, but this is actually a nice benefit..

the other nice thing is that we could offer two different ways to select the config "modes" to use.

so for example you might type

+mp3 +mydocs artist

which would search for files with the word artist in them, using the mp3 and mydocs configurations.
(where a configuration specifies paths to search and file pattern scores).

AND

there might be a checklist line displayed somewhere on the screen with checkboxes for all the configurations, so instead of typing +mp3 +mydocs you could also just tick the checkboxes for mp3 and mydocs; would be useful as an alternate method and a handy reminder of which configurations are going to be searched.

--

i would also like to suggest that the 'configurations' would not be full separate configuration files, but rather that when you specify file paths for searching, and file pattern scorings, you can also specify the list of configuration groups it matches.

for example instead of in pattern tab of dialog
*.mp3 | score=+400
*.ogg | score=+500

you would have
*.mp3 | score=+400 | mp3,music
*.ogg | score=+500 | music

[kfitting]

How does mydocs fit into your non-seperate-config-file idea?  I see how for extensions it would be nice, but if you have arbitrarily named search settings how would this work?  Also, what are your ideas on delimiter?  You used "+ " two characters.  Would this be configurable? 

I would argue (just so the board remains interesting!) that while extension settings should work as you suggested, the user could make their own config files.  I always envisioned these as only controlling extension and folder, not an entire configuration duplication.  The problem is that sometimes there are mp3s in folders that I don't want to enter the results at all (eg from games).  Merely having a weighting system allows me to still find files in those folders.  Or, using your way, would you have seperate weighting configurations?  The way I see it you need some kind of different setting "style sheet" if you will. 

Interesting ideas though!

Kevin

[mouser]

here i've been waiting for a reply to my long post... only to find it not here... maybe i forgot to click send 
let me retype it.

[mouser]

as for special deliminator, doesn't matter to me, we could even have F&R detect when keywords are config group names automatically.

so my basic idea was that the the Pattern Scoring tab and the Search Folder tab,
each item would have a new field called Config Groups.

so in search folder tab you might have

C:\MyDocs\Music | +500 | mydocs,music
C:\Windows\ | +1000 | system

and then in patterns tab you might have

*.mp3 | +1000 | music

-------------

so now when you search, if you typed
music blondie

then it would only search
C:\MyDocs\Music

and it would use the *.mp3 score bonus

but if you typed
system *.scr

then it would only search
C:\Windows\
and would not apply the *.mp3 scoring bonus


so all other configuration options would be shared, only those two tabs would enable you to customize their entries for different config groups.

a benefit is as you say, you could COMBINE config groups, so
music system blondie

would search both
C:\Windows\  and C:\MyDocs\Music
for files named blondie

and if you dont specify a config group, all will be searched

another nice benefit would be we could display a checklist of config groups that you could manually check or uncheck just as a visual reminder of available groups.

[mouser]

a real attraction of this approach for me is the desire to avoid multiple configuration files, for the reasons i have described previously (things like hotkeys and aliases seem like they should be shared between config groups).

so i think this might be a way to have our cake and eat it too..
the search tab and pattern scoring tabs seem like the main (only?) things that one would want to configure differently,
and this lets us do that in a very flexible way that lets you use it when you want, or ignore it when you dont care (simply dont type in a config group in your search and it will search all).

maybe instead of using all if no config group is specified we should explicitly let user specify * as a config group
ie:

C:\MyDocs\Music | +500 | mydocs,music,*
C:\Windows\ | +1000 | system

now if you just type
blondie

it will only search in C:\MyDocs\Music

but if you type
system blondie

then it will search in
C:\Windows\

i think we might be onto something..

[mouser]

i formalize my suggestion that we autodetect config names; it will be responsibility of user not to use config names that they might ever want to search for.  if user wants, they can include a special character, like

C:\MyDocs\Music | +500 | @mydocs,@music,*
C:\Windows\ | +1000 | @system

so that they would type:
@system blondie

[kfitting]

I think your idea about turning config files into more advanced weighting is a good one.   I see it as a different way of reaching the same goal as the config files, since the config files would have contained the same info as your weighting idea.  Further, perhaps "config files" would have given the user the impression they could change more than that leading to confusion.  I like your idea here.

However, I still advocate a delimiter.  If you include a special character, you essentialy have a delimiter... which, as I think about it, probably defeats my argument because then those who want a delimiter can have it while those who don't aren't forced to.  One thing though, why do you allow spaces?  How can you determine if someone is typing in a multiple word search or config options?  Is it because you must choose names you won't search?  Basically, my arguement is that I don't see why you wouldn't use a delimiter, though I suppose as long as you allow special characters and ;:'".,/\<> then I don't have a major complaint.  What about filetype searches?  Will those allow special characters as well?  I would love to be able to type something like     .xls:personal budget    to force an xls extension in my "personal" config options. 

One other suggestion.  Could there be a way to quickly pull up a list of configured search criteria (for lack of a name for the concept we are trying to discuss)?  If I'm trying to do a search, I will more than likely forget some of the options I have.  Maybe a hotkey that will bring up a list of the options.  I don't know.  I just have this feeling that I'll configure a bunch of settings and then never use them because I forget they're there. 

I'll admit, at this point I'm talking in circles here.  Mainly because at this stage I'd need something to play with to see how it works in actual practice.  Therefore I advocate a beta to try it all out!  (Easy for me to say!)  But, further discussion should also continue.  But, I need something to "hold" at this point.

Kevin

[mouser]

yeah, basically i was saying that if we allow any characters in config group names, then if a user wanted to use a special delimiter they could, or they could just make sure to only use config group names that they wont want to search for.

F&R would first check if any keyword is a config group, and if so, use if for that and NOT search for it.

you can already do filetype searches, just do
*.xls to search for files with xls extensions.

i say we keep this (or make it like .xls)

so for your example, you could have a config group called :personal

then you could type
:personal *.xls

to find all files ending in .xls, search the folders and scoring patterns as configured in your :personal group.

OR

and here is the nice part
you could set up a pattern group called "myxls" for example
and add a +1000 score to *.xls and set up the folders with your data files in them

then you could just type
myxls finance

and it would find all *.xls files in the directories where you keep your documents


as far as list of options:
yes this is what i was saying about having a checklist box, or set of checkboxes automatically showing all available config groups that you have set up.  they would be auto discovered by F&R and shown.

that way you would
1) see at a glance which config groups you have set up
2) could use the checkboxes to choose them instead of typing them, if you prefer

[kfitting]

I see your point better now.  I think because of the flexibility of your system, I could easily use my system... which is one reason why you should actually yours! 

As far as the list is concerned, I wasn't talking about showing the list in the options dialog.  I mean when you hit pause/break you should be able to easily invoke another "window" (maybe a notice or alert box or something) with a listing of your config setups.  The idea is to make it easy to recall what you have setup.  You shouldn't have to go into the options dialogue to invoke this listing, however.

Just an idea,

Kevin

[mouser]

interesting...
so you mean like hit a key or push a button to see a quick list of your config groups and what they mean.


like it would show:

system:
C:\Windows\ | +1000

music:
C:\MyDocs\Music | +500
*.mp3 | +500


like that?

[kfitting]

Precisely!

Kevin

[mouser]

sounds like a good idea to me.

[mouser]

i think i really like this new approach - nice and clean and only 1 config file.
but i'd like to hear cracksloth's opinion on it since i know he had his heart set on multiple config files and i'm curious as to his take on whether this will do what he wanted or be insufficient.

the ability to combine config groups seems like a really nice benefit to me, plus the ability to specify config groups all from the keyboard has to be seen as a strength for a keyboard-maniac tool.

[cracksloth]

i've been busy lately so sorry i haven't provided much feedback lately.  anyway, i though i should reply to some of these ideas:

a real attraction of this approach for me is the desire to avoid multiple configuration files, for the reasons i have described previously (things like hotkeys and aliases seem like they should be shared between config groups).

i meant to imply that hotkeys and aliases would be found in the general program options (not a config file).  using multiple config files would require that you separate some features into general options so that they apply universally to all configs (like hotkeys and aliases).  i guess i miscommunicated.  so, to me, there isn't a lot of difference between the idea of a separate config "file" and a "config group" that keeps its settings internally.  both suit the same function.

the real innovation mentioned here is the method of switching between configs.  like i mentioned before, there are many ways to be able to switch between configs.  we've mentioned quite a few in the past including the ability to switch between configs using the keyboard by creating a "command" or "alias".  the method of switching configs presented here (as a prefix) is also acceptable and it has the added bonus of easily being able to specify multiple configs simultaneously.  this may be useful if a user does not want to specify a specific config group for both sets of folders.

but lets talk about what options need to be in each config group/file:

search folders
heuristic scoring
pattern scoring
max entries to display in results list (X)
results display style (small icons, large icons, detailed report)
result label extension (yes, no)

specifying multiple config groups simultaneously may interfere with the last two settings because they define *how* results are displayed - this means multiple config groups could have conflicting settings.  because i believe these settings are essential, we need to discuss ways of addressing these issues:

------------------
results display style (small icons, large icons, detailed report):  what happens when different display styles are specified in each config group?  i think that each style should be given a value:
  - thumbnails (0)
  - large icons (1)
  - small icons (2)
  - detailed report (3)
when multiple config groups are specified, f&r should display the results using the style of the greatest number.  for example, if you specified both a video config group (that was set to display thumbnails) and a music config group (that was set to display small icons), then f&r would display the results as small icons.  i realize, that f&r does not currently have a thumbnail display style - i just used it as an example.

if you don't like that idea or if you want something more simple, you could just have f&r always display as a detailed report if the two config groups do not have the same display style.
--------------------
result label extension (yes, no):  this one is easier... if the config groups disagree, then just show all extensions.
--------------------


anyway, i hope this was helpful.  for the record, i do not want the checkboxes you mentioned for selecting configs to be a part of the main interface.  i would rather that the screen popup when i enter a specific keywork into f&r (like "config" or something).

also, as an aside i thought of another good heuristic score but when i looked at the heuristic scoring tab, this might be a feature you have already included but i just never realized.  basically, it would add a percentage of the "score" amount equal to the percentage that the search characters match the result filename.  so if i set a heuristic score item:
percentage match bonus = 200 points
then i entered "word" into the search field.  let's say i get 3 matching results:
Word
Word Perfect
Wordy

the "Word" result would get the full 200 point bonus.  the "Word Perfect" result would only get 33% of the 200 points (66 points) because the entry "word" comprises 33% of the result "Word Perfect" (unless you want to ignore spaces).  likewise, the "Wordy" result would receive 80% of the 200 points (160 points).  make sense?  well, when i was looking at the heuristic tab, i noticed "percentage of search string points".  since i don't know what this is, it might already be what i am trying to describe. 

anyway, that's about it!  take care guys!

-cracksloth

[mouser]

percentage score does exactly what you say - its meant to favor more exact matches over partial matches;
there is also a bonus for matching the start of a filename vs. middle.

you previous points about config file selecting modes of display - this is the real issue that must be resolved.

my inclination is to make those display options NOT part of multiple configuration groups; it just seems too messy.

let's simplify our discussions a bit by defining some terms.


lets use Config Files to talk about the configuraiton file which contains ALL options.

and lets use Filter Groups (instead of config groups) to mean the new proposed method of being able to label search directories and scoring patterns to be used when you specify an extra filter group name (like music).


so what i would like to propose is the following:
Filter Groups as we've discussed in this thread, which only affect search folders and scoring patterns.

but i'm open to the idea of a ability to maintain multiple Config files, and load them when you want, and load them on startup through commandline; A config file will be a complete set of independent options, search folders, aliases, etc.  Frankly i would be loathe to use multiple config files, but i'm willing to add it if its something people are compelled to you because they sometimes want one kind of display mode and sometimes another.


i think we have to ask ourselves how often it will be that people will want to quickly switch between display modes - and if so, lets make quick button options for this - rather than separate config files.

cracksloth i hear what you are saying about multiple config files and then having other options that would be shared between all config files (e.g. aliases), but what i'm saying is that maybe this is overkill.

lets identify the things that users will want to easily switch between frequently (if its number of results, then lets have a button for changing betweeen few and many).  if its size of window, ditto.  rather than having different config files which is really a pain to deal with both from programming standpoint, user interface standpoint, and explaining to user standpoint.

i think if we can capture 90% of the motivation for separate config files using Filter Groups, i'm inclined to go with that and find an alternative to having separate config files for the other settings.

ps.
cracksloth i was thinking a little more about your plugin idea and i'm actually starting to consider it.. i'll report on this more, but basically it would be just a little more than what is already planned to let you type arbitrary commands into F&R.  i'll post more later when i figure out a little more.

[cracksloth]

comments:

mouser, would you divide those heuristic options into two:
"percentage match bonus" & "beginning of filename bonus"
when searching for the title of an mp3s (for example), it would be beneficial not to give bonuses for being in the beginning of a filename.  in addition, these phrases might be more descriptive to slow people like me. 

but i'm open to the idea of a ability to maintain multiple Config files...

this is unneccessary.  to me, filter groups and multiple configs are the same feature, only different in implementation.  i think other features are more important if for coding reasons, you prefer to switch filter groups rather than config files.  however, commandline options for switching filter groups would still be a good idea (for scripting and setting up aliases).

if you do not want to add the options i mentioned to fiter groups then it is acceptable to add toolbar buttons for:
  - few and many results (assuming that these can be configured by the user).
  - switching display modes
  - a checkbox list to select active filter group(s)

plugins could also exist for the type of content searched.  for example, a search plugin for id3 tags, exif tags, document content, email, etc.  just an idea.  obviously, these ideas would not need to be implemented immediately but they would provide expansion for down the road and would allow f&r to keep up with the many content search tools that are becoming popular these days.  since it is a plugin, other users could contribute by creating these.  and because plugins are optional, they would not need to be loaded by users who do not want them.  they could be listed in each config group under a new tab called "search methods" where the user would select one or more:
  - filename
  - document content
  - id3
  - exif
  - internet history
  - outlook email
  - etc.
each of these search methods would have unique heuristic scoring, pattern scoring, and search folders.  this would be done to reduce confusing options that may not apply in all situations (and it would be more powerful).  for example, you could create a "url" search that would search your internet history and the filenames of your favorites for keyword(s).  anyway, just me rambling again about long term possibilities.    really i am just giving my vote for a plugin system!

[mouser]

i think it sounds like we have come to some good compromise solution.

percentage match is differen from begining of filename bonus
begining of filename bonus is in the score list described as "leftmost match bonus"
sorry if i confused the issue by making it sound like they were both called "percentage match"
see help file for description of what all the heuristics do

i think i agree with the toolbar button idea - i want to add toolbar buttons for other things and i think we can spare a short row of buttons on f&r screen for such things.

i like the idea of special file-type plugins that would allow you to search specific details of files like mp3 tags.
(though i think i might just build in mp3 tag and url favorites checking and some other common ones).

so there are really 2 different kinds of plugins,
first would be file scanning plugins, like looking for mp3 tags.

the other kind would be a plugin that would react to what you type; like if you typed "dict blah" it would show you the definition of the word in the window.. im still not convinced this is really much of an improvement over the already planned command exe launching function, except that it would be faster to view.

[cracksloth]

i like the content plugin idea as well - similar to the plugin system i discussed previously.  i assume that your "dict" command would reap the info from a web dictionary?  this would open up the possibility to reap other kinds of info like weather and movie listings.  potentially, it could behave like a wap browser for access to quick information.  me likey! 

[kfitting]

Interesting discussion.  I like it.  One question: Cracksloth, what were you talking about when you said this?

anyway, i hope this was helpful.  for the record, i do not want the checkboxes you mentioned for selecting configs to be a part of the main interface.  i would rather that the screen popup when i enter a specific keywork into f&r (like "config" or something).

I thought the checkboxes would work like the folder choosing method currently implemented, not that you would see the checkboxes on a daily basis.  I think it's an interesting idea that you could type config (or some other alias) to bring up the options... seems interesting for all those keyboard lovers!  I was just confused by the quote above.

Also, I just want to insert a reminder that there should be a quick way of looking at all the filter groups (correct terminology?) from the main window.  I envision this as a small window that would popup at a hotkey command and show the alias, folders, and whatever other info we choose.  It wouldnt steal focus but as soon as a number is pressed (basically, a file is chosen) it vanishes along with FindRun.  Sorry, I know I sound like a retard for repeating this, and no, I dont think it's been forgotten, but I know if I make a bunch of filter groups I will completely forget what I have made and not use them.

But, overall, excellant ideas.  mouser, I was just thinking about the whole mp3 tag scanning option last night, but thought maybe it was too ambitious... would be an awesome addition though!  Now, if you could get ogg support, that would be even more worthwhile!  One question on this direction: what are your plans as far as scanning inside files?  Will plugins allow you to look inside pdf, doc, rtf, html, etc?  Will FindRun have to resort to indexing?  These are questions that arise naturally once the scanning inside tags idea is brought up.  I, for one, am not real thrilled about having FindRun keep an index of a bunch of files.  However, I think it would be neat to be able to look inside certain file types, or be able to.  Also, maybe an index method could be made that doesnt take up a ton of disk space.  I dont know, something to kick around.

Kevin

[mouser]

the issue of popup list of filter groups and checkboxes are all related -
they have to do with making it easy to remember what filter groups you've set up.

i definitely hear what you are saying about wanting a pop up reminder of what goes in each filter group -
though i wonder if just a list of filter groups available on the main screen wouldn't be sufficient and better in some cases.
it wouldnt' show you what each filter group actually DOES, but then you probably won't forget that..
the main thing you are bound to forget is what the names of the filter groups are..
so thats why i was thinking like just a row of checkboxes like:
[] music  []mydocs  []system

and then to search in music you would type
music blondie

OR
you could just CHECK the box marked music and type blondie.

at least that was my idea.


as far as searching in files..
i already have written for another project some nice fast code for searching in files... the real thing is that this is more a task for a real file searchers instead of something like F&R, so its probably best left out of it i'm guessting.  but i can see the argument for some limited stuff like mp3/ogg tag searching, and i think its worth adding that stuff at least.  if we want to give F&R a full fledged file search mode then we might reconsider adding full text / hex search to it.

[cracksloth]

@kfitting:

anyway, i hope this was helpful.  for the record, i do not want the checkboxes you mentioned for selecting configs to be a part of the main interface.  i would rather that the screen popup when i enter a specific keywork into f&r (like "config" or something).

i assumed when you guys were talking about a checkbox list for selecting multiple filter groups simultaneously.  i thought mouser was suggesting that these checkboxes would be shown in the main window.  i simply wanted to suggest that they be found in a separate menu (which is shown by pressing a toolbar button or by a custom command entered into f&r).  a row of checkboxes would become problematic if you had a lot of filter groups.  a vertical arrangement like a menu would be better for longer lists.  you could navigate the menu with the arrow keys and use the "space" key for selecting a checkbox or the "enter" key to only activate the selected filter group.  or they could be toggled with the mouse.  anyway, i like filtergroups, i just don't want to look at them all day! 

i would personally love to see a fulltext search of files.

i already have written for another project some nice fast code for searching in files

since you have access to code to do this, it would make a great plugin.  since plugins are optional, no one should be very upset with this but there would likely be quite a few who would *really* like it (especially since you can setup multiple folders that are properly filtered so that you are doing full text searches through a very specific group of files - this is a feature i've never seen in traditional search tools).

@kfitting
i think that mouser's code would search through the actual files - it wouldn't create an index file.  a lot of new search tools have started using index files to increase speed because thay are basically attempting to quickly search the entire harddrive very quickly and to keep track of where files are located.  with the targeted search method that f&r is capable of, similar speed can be achieved by intelligently filtering files.  this is a really good idea because often you do not want to search through every help file, program documentation, and letter to aunt mollie found on your hard drive - most of the time, you have a good idea of what filter group your document would be found in and other matching results found elsewhere on your harddrive would just get in the way.  yes, this is a very good idea!  i think that this function fits very well with the underlying theme of f&r (finding files) and i think that it puts f&r a step above the rest.

[mouser]

i thought mouser was suggesting that these checkboxes would be shown in the main window

yes, you accurately described what i was suggesting - and i take your point about the problems with it.

perhaps we should consider a button that reveals a panel of extended search items, including filter groups checklist, options for searching within files, etc.

[cracksloth]

perhaps we should consider a button that reveals a panel of extended search items, including filter groups checklist, options for searching within files, etc.

sounds perfect.  maybe this panel would be displayed within the results area?  just a thought - no strong attachment to it.