Author Topic: Feature Request: Super Context... (Read 18150 times)

nontroppo · « **on:** August 29, 2005, 01:03 PM »

First off FRR is excellent. I've been looking for something ever since I was blown away by seeing QuickSilver on a friends Mac.

Now, what makes QuickSilver utterly revolutionary is the context system. FFR has added support for the context menu, but it seems it needs to be clicked, thus making the purpose of a super-fast keyboard launcher not so fast or so "keyboard"!

This screenshot shows QuickSilver (QS) at work. The user has found a file, presses <tab> and can now search for contextual tasks to perform on that file. In this case move the file to another folder:
http://quicksilver.b...reenshots/Bezel2.gif

Here, QS has found an Illustrator file, the user <tab>s to the actions field and chooses to email the file; on the Mac the address book entries then pop up!
http://quicksilver.b...reenshots/Bezel6.gif

Now I don't believe we could get something quite so elegant on Windows, but even a more basic context system would make FRR unique and powerful in the Windows world.

I see two options for development. First is to somehow allow the contents of the windows context menu to be accessible by FRR. This puts the burden of the contextual items at Windows doorstep, FRR just packages those items in a keyboard driven search system as it does already. Does windows make this info available?

Second is to make some hard-coded "actions" and just present that list letting the history and scoring mechanisms of FRR to do the work. This could of course be made more elegant and smart as needed.

Of course the UI to present the contextual items needs to be thought out. I suppose splitting the results window in two panes and letting <tab> select the result pane item then move to the context pane would be fairly trivial to set up using the Windows UI elements. Of course QS has a Zen like elegance all to itself, but as long as functionality is there, the wonderful Zen aesthetics of QS can wait!

nontroppo · « **Reply #1 on:** August 29, 2005, 02:42 PM »

Here are the various UI designs employed by QS — note all of them show the context action:

http://docs.blacktre...icksilver/appearance

In this case the Preview application has been found and the default action (Launch) is displayed. Pressing tab would allow the conxtextual actions to be searched/modified.

kfitting · « **Reply #2 on:** August 29, 2005, 02:47 PM »

Super Context is certainly intriguing... especially if more advanced groups are used to list files of a certain type etc. It would be cool to just be able to hit tab and select from the normal windows context menu even. The problem is, how do you select the file to expand the context menu for? Since FindRun is also a program launcher, pressing a number should not bring up the context menu by default since then it would take more presses to launch programs. But, interesting idea nonetheless, and with a little refining it could be made very powerful.

Kevin

nontroppo · « **Reply #3 on:** August 29, 2005, 03:42 PM »

Well, one would probably need a default selection, so <tab> selects the entry with the highest points within current system FRR uses. I'd prefer to see some kind of autocomplete mechanism instead of the current seperate edit/results partitioned UI, and in that case this conundrum would disappear.

Of course one could simply use hotkeys - "2" launches the second result and "CTRL+2" accesses the context system for it. A setting in prefs could define what the default behaviour would be.

OK, how about this - can you measure how long a key is held down. This way a short press of "2" would launch and a long press of "2" would trigger the context actions!

mouser · « **Reply #4 on:** August 29, 2005, 07:45 PM »

i'm kind of fond of the idea of taking advantage of ctrl+numberkey and alt+numberkey (maybe also winkey+numberkey).

the other question is more intriguing - what to show...

two main choices: 1) show regular shell context menu vs. 2) show a custom menu based on file extension.

if there is interest in #2, i could add another tab to the options dialog that let you specify custom commands associated with certain extentions. so you could configure:
"*.txt":
edit file | c:\program files\ultraedit.exe $$1
print file | c:\program files\printfile.exe $$1

and then when user does a search, and finds a file they want, they would hit like Ctrl+1
which would then show this custom list in results view:
1. edit file
2. print file

where they could then hit 1 or 2.

the only problem is it is a bit confusing to use and would require configuration by user before it would work, whereas the context menu seems more logical, and is already premade. maybe just ctrl+1 to bring up context menu for item 1 is the best solution.

nontroppo · « **Reply #5 on:** August 30, 2005, 11:29 AM »

I actually envisaged that the great progressive find used to find the file/target is ALSO used for the actions. So when you <tab> you select the first element in the target list, you then start typing "edit" to edit and the edit action comes to the top of the list. This simply uses the same mechanism that the initial search FARR already does. I'd prefer that to key commands if possible as it is more intuitive.

I would prefer the items of the context menu - but not presented AS a menu, but as a list the same as your current target list. That's why I suggested a split-pane UI.

Can you perform different actions based on how long a key is pressed?

mouser · « **Reply #6 on:** August 30, 2005, 11:59 AM »

i'll have to think about what you are saying - it makes some sense but it would be difficult to do with the current system..

kfitting · « **Reply #7 on:** August 30, 2005, 12:14 PM »

I agree with nontroppo as far as usability is concerned... that would be a simple (workflow wise) way to do things. But, is a split pane viewer required? Could a menu be made to update? This would require less modification, it seems to me, and also not wreck the simplicity inherent in FindRun's gui. Worth looking into, though ctrl/alt/win modifications would still work.

Kevin

nontroppo · « **Reply #8 on:** August 30, 2005, 12:31 PM »

If I get a chance, I'll mock something up in photoshop; various UI ideas to play with...

mouser · « **Reply #9 on:** August 30, 2005, 12:41 PM »

cool, that would be useful.

cracksloth · « **Reply #10 on:** August 31, 2005, 01:07 AM »

maybe everyone already knows this but you can currently access the context menu using only the keyboard (although it is a slow process). just perform a search and select the result of interest using the arrow keys. then press the "context menu button" (that weird key introduced with the windows key that no one uses). it will give you the context menu (and you can continue to the windows context menu using the arrow keys).

my suggestion would be to create a coding snack that creates a new popout submenu in the traditional explorer context menu of windows. in this submenu you could place common actions specific to a certain filetype(s). this would be a useful tool separately *but* you could create a special menu for f&r that will graphically list the actions found in this submenu. it would allow users quick access to the most frequent actions for that item without being overwhelmed with the large number of options available in the explorer context menu.

so basically it looks like we have 5 potential actions for a result item:
- select an item: arrow keys or single-click
- launch: # key or double-clicking
- f&r context menu: by pressing the "context menu key" or right-clicking
- explorer context menu: by jumping around in the f&r context menu
- action list proposed by nontroppo: not yet completed

let's face it, you will never get all users to agree on the "best method". i think that each user should be able to specify the method they prefer in the options. here is a preliminary list of possible triggers:

mouse triggers:
- single-click
- double-click
- right-click
- middle-click

triggers with an implied item number:
- # key short
- # key long
- ctrl+#
- alt+#
- win+#

triggers affecting the currently selected item(s):
- tab
- backspace
- enter
- space
----------------------------------------
users could pick their own preferred trigger for each of the 5 actions written above. it would also make it easier to expand the action list in the future. for example, if a user wanted a hotkey to add an item to an alias group, to delete the item, etc.

it doesn't quite apply yet, but when you add support for finding other filetypes (multiple configurations or whatever you call it), it would be necessary to be able to select multiple files (using ctrl to select files one at a time and holding shift to select a group of files using the arrow keys). this also makes your drag and drop support more useful.

that's about it! good job mouser!

mouser · « **Reply #11 on:** August 31, 2005, 02:20 AM »

very thoughtful summary.
i'm open to the idea of allowing user to choose triggers for what keys cause what reactions,
especially win+#, alt+# and ctrl+#

let me implement the functionality and then we can figure out how to offer the trigger customization.

we will be coming out with a context menu adding utility here at donationcoder soon so that would do what you're saying,
though i suspect that the people who requested this dont want to have to go into the menu and really want results in result window.

actually there might be a way for me to do that, at least for customized actions.. im going to think about it a little more and implement the regular expression stuff first and we can come back to it.

cracksloth · « **Reply #12 on:** August 31, 2005, 06:54 AM »

could you explain:

though i suspect that the people who requested this dont want to have to go into the menu and really want results in result window

i don't know that i understand this entirely

mouser · « **Reply #13 on:** August 31, 2005, 07:30 AM »

in this post: https://www.donation...ndex.php?topic=788.0
nontroppo described his idea, which as a i understand it was to somehow present context menu type results in a window that would be easily selectable using keyboard, much like the normal results are, rather than simply calling up the normal shell context menu.

i actually might consider such an approach with custom actions.

for example, imagin in options you could specify certain alias groups associated with filemasks,
so you could say:
"*.txt":
open $$1 in editor|C:\program files\uiltraedit\uedit.exe
open $$1 in notepatd|C:\program files\notepad\notepad.exe

then lets say you do a search for "taxes"
and the results are
1) mytaxes2005.txt
2) mytaxes2004.txt

ok so maybe we could do something like, you hit Alt+2
and then the results would change to:
1) open mytaxes2005.txt in editor
2) open mytaxes2005.txt in notepad

just an idea..

mouser · « **Reply #14 on:** August 31, 2005, 07:32 AM »

the main downside i see to all this is, how much is it really going to add for all the work involved..
user would have to add those custom actions manually, wherase the context menu is already premade.

i guess i think i favor the simpler approach of being able to assign a hotkey to trigger context menu on an item, ie Alt+2 brings up system context menu for item 2. Ctrl+2 brings up F&R context menu for it.

kfitting · « **Reply #15 on:** August 31, 2005, 07:58 AM »

Your ideas make sense mouser... I especially agree with the idea of less user involvement up front. One of the problems with this app is that it has SO many customization options it will become rather overwhelming for newcomers. Customization is great, dont get me wrong, but intuitiveness is key; whether this comes in the form of a well-written helpfile or user-friendly GUI, I dont know. Besides, if a freak accident occurs and you dont get a chance to save your settings you will spend a long time getting everything back!

For example, the regular expressions are going to be confusing to new users (if they arent familiar with them to begin with). Now, I know they arent critical to using FindRun and a new user could get by without them, but they will make FindRun so useful it would be a shame to have people just give up on them (or FindRun) because they see a big confusing piece of software that will take a lot of time to learn and get running. (I will reiterate: regular expressions are going to be helpful and I am NOT saying they shouldnt be included!!)

<<rant>> That is one of my biggest disagreements/peeves with the whole Open Source movement: sure, the software is free, but often you get what you pay for in terms of gui and documentation! I played around with Linux and came away unimpressed for the simple reason that the GUI for many of the programs I was using (some engineering apps) was downright pathetic. This isnt to say that all OS programs are trash, I just get upset when I read places like Slashdot (the comments section... the news is still good!) and people will bash a program solely because it costs money, while advocating an OS alternative. Usability usability documentation!!! <</rant>>

So, all that rambling to say, it's worth giving a few less options in certain places if it will make a program more user-friendly. Obviously, the question is "where is that line?" I dont know, and since mouser is the one writing the software, he gets to answer it as he goes!

Kevin

mouser · « **Reply #16 on:** August 31, 2005, 08:14 AM »

i agree with you kfitting, and i hope you will help me not go crazy with making it too complex.
regular expressions are going to be beyond most people,
which is why we will want to make a good chunk of default commands come pre-configured,
ie web searches, etc.

then users can more easily
1) see examples
2) just use the built in commands
3) just tweak and modify existing commands without having to understand them completely.

cracksloth · « **Reply #17 on:** August 31, 2005, 08:20 AM »

ah... i was trying to say that nontroppo's context menu could simply load those actions defined by a separate context menu tool (by parsing the registry or a config file). it was just a way to remove some bloat from f&r and to maximize your coding time by creating a second tool that would also be helpful in other situations.

but i agree about not worrying about this yet - it's not pretty, but the explorer context menu is functional and complete.

kfitting · « **Reply #18 on:** August 31, 2005, 09:07 AM »

Well, I'll try to help... though on features and things that I want I tend to go overboard myself! Oh well, checks and balances I suppose. I will continue commenting on the regex stuff in the appropriate topic! Read on...

Kevin

nontroppo · « **Reply #19 on:** August 31, 2005, 02:10 PM »

I don't know anything about the Win32 API so my suggestions may not always be easily implementable. I had hoped that somewhere there was a get-at-able representation of the context menu (an object which gives a list of things doable), without having to show it (I think this is how OSX does it as it seems there are many such apps around). Maybe the registry has most of what is needed? Navigating a serial menu with arrow keys is slower, less elegant and less simple than the adaptive search that FARR is based on. But if it requires a manual recreation of contextual actions because of the Win32 API, it see may be quite a bit of work.

Nevertheless with mousers custom commands and file type matching, some basic contextual configuration sets would be trivial to set up. I am quite happy to noodle around with regex's, and I think we can easily come up with a library of commands to perform for those who don't need/want to regex.