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!
