DonationCoder.com Software > Find And Run Robot

Feature Request Thread

<< < (7/9) > >>

cracksloth:
what are the advantages of having a different "mode" over having different "configurations"?  to me, config files are just a way to specify a different mode in which all options are mutable.  you could add the features to a config file for number of results, window size, search within mp3 tags, etc.  i would also think that this would keep the filesize of f&r smaller and it would have less of an impact on the existing ui (for those users who only want to use f&r to search the start menu).  the only impact loading different config files would have on the ui is a means by which to switch between them.  several ways have been suggested, including possibilities as graphical as tabs and as minimal as a commandline.  to me, the method of switching config files is gravy so whatever you choose is great.

i also like the idea of "commands".  it is kind of like what many commandline apps call an "alias"  :)  a nice script for such a feature would be a commandline-based volume control.  for example:
"vol 25" would set the master volume to 25%
"vol m" would toggle the mute status

for others looking for applications for such a feature, you could create "commands" to load playlists, like:
"play playlist"

you could also create single word commands to lauch frequently accessed items.  for example:
"wp" would launch wordperfect
"wa" would launch winamp

f&r makes access to programs quick but it could always be quicker  :)

-cracksloth

mouser:
yeah, i wasn't disagreeing with idea of different configurations,
i was just trying to think out loud about the idea that f&r might he able to be configured to run in two very different ways.

cracksloth:
ah...  i probably misunderstood you.  what are the features of this second mode?

mouser:
yeah i don' know yet, i was just playing with ideas..
it would probably be more oriented to more interactive search.

so for example the current interface is designed to be very minimal, so it can just pop up, list only top 10 items or so, and let you activate by pressing number key.

but for those of you who want to use it to do real search of files,
i'm guessing that having a tiny interface with top 10 results might not be your primary concern;
you may be more interested in more easily adjusting areas searched, and having more flexibility with regard to results.

cracksloth:
these are all great ideas.  i think that what i don't understand is which features would be unsuitable for integrating into a config file?  already, config files can designate the max number of entries displayed.  there are some types of searches where it would be beneficial to show *all* matching results, but again, to me this just means that you should be able to deselect:
"max. entries to display in results list"
so that all matches are listed.

if you don't want to include the option to specify windowsize in the config file, perhaps you could allow the user to create windowsize presets in the general program options?

also, remember how i was trying to get you to think of f&r as a plugin container?  for example, a user could create a config that would load the search plugin (and associated options).  a second config could be made that loads the minibrowser plugin.  from the way it sounds, are you looking for a way to be able to specify the folders being searched on the fly (like a traditional file search tool)?  if so, it would be conceivable to create a third plugin where the user can select the folder(s) they want to search from a dropdown list.  the benefit of treating these different "modes" as plugins, it that:
  - they are optional.  users who don't want them don't have to fuss with them
  - users who choose not to use a particular plugin will not be wasting resources running those features in the background.  they will not be forced to load any features into memory that they do not want.  f&r could remain a quick and sleek app launcher or it could be a more powerful file launcher or it could be a powerhouse of features and system management
  - plugins would not impact the existing ui for the current method of app launching
  - it would be possible for other users to create plugins (like a calendar plugin, a to-do list plugin, a cpu usage plugin, a task killer plugin, etc.)...  all optional, of course.
  - it is upgradeable.  a plugin can do virtually anything.  a simple program that houses plugins and can be pulled up at the touch of a button means that a user could do *anything* with the movement of a finger.  it's kind of like playing god without all the commandments.
  - sometimes, users become divided about how a feature should perform and react.  this would allow for users to make more than one plugin that has virtually the same task but each tailored for different preferences.  an unrealistic goal if you are the only one coding features.
  - the plugins would be reusable in any future endeavor that could use such functionality (i swear i though i heard you speak of making a sidebar one day...  perhaps i was dreaming)  :)

anyway, as always, i talk too much!  :)

Navigation

[0] Message Index

[#] Next page

[*] Previous page