context menu suggestions

[adamantine]

1) i suggest to implement a new (revolutionary) context menu item: Content

in the 1.5-aplha we already have a new notable context menu item (in my case it is placed right after the 'copy full path to clipboard' item)
the title of this new context menu item coincides with the title of a parent folder of the selected folder
this new context menu item may have numerous nested menus (which are already implemented in a nice and neat way)
moreover, all those nested menus are opened without a tiniest delay (in my OS i've done it on purpose a long time ago because it's much better in my opinion)

the very new 'Content' item may be placed right before or right after the above mentioned item (since they both have nested menu/menus)
but it's better to place the 'Content' item somewhere higher (as possible) (ideally, as the first item of a folder's context menu in ET)


the sense of this 'Content' item is to display a list of all child folders/files belonging to the selected folder. example:
there is a folder 'album-1999', it contains 3 files: 1.cue and 1.wav and note.txt
the new 'Content' item allows to open the cue-file (or txt-file) with just 2 clicks:
- right click on an 'album-1999' folder
- move the cursor to the 'Content' item (after that: it instantly starts to display the nested menu with 3 files)
- so we now see a small and convenient list containing 3 lines: 1.cue, 1.wav, note.txt
- left click on 1.cue (or on note.txt) to immediately open it in the corresponding program (Notepad2 in my case)

inside the 'Content' item:
- folders (if any) are listed on top
- then there is a separator between folders and files (it is absent if there are no folders) (it is also absent if there are no files)
- files (if any) are listed under the folders
- there should be not a single excessive/useless line here, for example 'Folders:' or 'Files:'

- if the selected folder is empty, then the nested menu should simply not appear at all
(there is no need in displaying various distractive words like: 'Empty' or 'Folder Is Empty' or '0 Items' or 'No Objects'
in this case i propose to display the 'Content' word without the right arrow. this approach is elegant and intuitive)
- all folders should be sorted alphabetically ('natural numeric sort order' should be used)
- all files should be sorted alphabetically ('natural numeric sort order' should be used)


an additional discussions are possible later in this thread (concerning the cases when there are much more child objects than just 3)
a) there could be something like a vertical scroll with arrows on top and bottom of the nested context menu
b) there could be user-defined limits like: display the first 50 or 100 objects only
c) there even could be something like a multiple vertical sub-menus where the first 50 objects go to the first vertical sub-menu, while the objects from 51 to 100 go the 2nd vertical sub-menu placed right after the first vertical sub-menu and so on:
as long as horizontal space of the screen may fit all these sub-menus

additional idea: if the selected folder contains not just files but also some folder/folders, then these folders should have their nested menus too

so, clicking on a file should always run this file using the associated program
while clicking on a folder should always open this folder (in my case: in the 'xyplorer' file manager)

another idea: the title of a new context menu item Content may be displayed even in a slightly better/advanced/informative way. examples:
0 child folder/file:         Content
1 child folder/file:         Content (1 Item)
2 child folders/files:      Content (2 Items)
10 child folders/files:    Content (10 Items)
105 child folders/files:  Content (105 Items)


2) i propose to expand the 'options > general > context menu' list by adding there literally all existing context menu items of ET
for example, these items: Cut, Copy, Paste, Create Shortcut, Delete, Rename, Properties, Set Property Value... (TODO), [all separators], Edit, Print, Add to archive..., Open With

that list may also be improved by adding the following possibilities for a user:
rename any item, hide any item, remove all underlinings (for instance: 't' in Cut, 'C' in Copy), move any item to any position, remove any separator, add a separator to any place

(this 2nd suggestion is related to the main context menu too, not just to the context menu of a folder/file)

[void]

Thanks for the suggestions adamantine,

I do have plans for Everything 1.5 to overhaul the Context menu options with full customization of the all menu items.
This should include what items are shown and the position of each item in the right click context menu.

new notable context menu item

I've been calling this the 'parent' menu internally.
The main reason for this new menu is so you can paste in the containing folder of a selected file (eg: right click a file -> parent -> paste )
Another reason is so you can quickly open a parent of a parent (eg: right click a file -> parent -> parent -> open)

moreover, all those nested menus are opened without a tiniest delay

These are my own menu items.
I may load the complete folder shell context menu in a future release. This would be loaded dynamically so the menu would still be responsive.

the sense of this 'Content' item is to display a list of all child folders/files belonging to the selected folder. example:

I have put this on my TODO list, it would most likely go next to the 'Parent' menu item or maybe in the 'Parent' menu item (Parent -> Content (x items) -> ...).
I may have to pull the child folder/file names from the index for performance reasons.

2) i propose to expand the 'options > general > context menu' list by adding there literally all existing context menu items of ET

It's on my TODO list.

rename any item, hide any item, remove all underlinings (for instance: 't' in Cut, 'C' in Copy), move any item to any position, remove any separator, add a separator to any place

I will keep these in mind.

Thank you for the suggestions.

[adamantine]

it would most likely go next to the 'Parent' menu item or maybe in the 'Parent' menu item (Parent -> Content (x items) -> ...)

my vote certainly goes for the 1st variant: "go next to the 'Parent' menu item"
(in case there are these 2 variants only)

(in case there are other variants, i would have preferred to see the Content item at the very top of the context menu
or at least right above the 'Parent' menu item, not below it)

i'm sure that the 1st variant is simply more convenient and also slightly faster than the 2nd variant

[void]

Thank you for the suggestions adamantine,

For folders, I prefer the 1st variant too (otherwise it's an extra click under with the Parent submenu).

For files, this menu item might need to be named Siblings or Parent Content (to avoid confusion) as it's not content of the selected item.
Or, for files, the 2nd variant might work with having Content under the Parent submenu.

[adamantine]

having Content under the Parent submenu

i think that it is not a good idea

Siblings or Parent Content

Siblings is the best variant, i have no doubts here

[adamantine]

while waiting for implementation of the above-mentioned stuff, i decided to share my new approach that is closely related to this thread

i often have a need to quickly see (and have a quick access to) the content of a folder that is displayed in the result list

the solution becomes much better and more convenient if status bar is placed at the top (close to the "search edit" bar)
in my present case: status bar is placed right above the "search edit" bar

the workflow is the following:
- drag a folder to "search edit" bar
- get the content of that folder in the "result list"
- move the mouse cursor several pixels higher (so that it was above the status bar), and just make 1 scroll down
- get the previous content of the "result list" (with that folder being selected)
- optionally make 1 scroll up (above the status bar), and get the content of that folder again

 
(off-topic starts)
here i have a question concerning the behavior of this "history" feature:
(at present) the "back/forward" commands actually do not remember the history
if i understand correctly, they only remember 1 step of that history (a step back / a step forward)
for example, sometimes it's not possible to get the content of the 1st dragged folder (using the "back/forward" commands)

this is not a big problem but i would like to specify anyway: am i missing something?
how do i achieve the following behavior?:

- drag a folder-1 to the "search edit" bar
- history > back
- drag a folder-2 to the "search edit" bar
- history > back
now it's possible to return to the content of a folder-2 (using the "history > forward" command)
but it's not possible to return to the content of a folder-1 (using the "back/forward" commands)
(off-topic ends)
 
 
these are the 2 ahk-codes that make it happen:

Code: Select all

#If MouseIsOverControl("msctls_statusbar321") && (MouseIsOver("ahk_exe Everything.exe"))
WheelDown::
if a_timesincepriorhotkey > 100
count = 0
count++
If (count < 2)
{
PostMessage, 0x111, 40040,,, ahk_exe Everything.exe
}
return
#If

the "40040" value launches the "history > back" main menu command

Code: Select all

#If MouseIsOverControl("msctls_statusbar321") && (MouseIsOver("ahk_exe Everything.exe"))
WheelUp::
if a_timesincepriorhotkey > 100
count = 0
count++
If (count < 2)
{
PostMessage, 0x111, 40041,,, ahk_exe Everything.exe
}
return
#If

the "40041" value launches the "history > forward" main menu command

the codes are working even if et is not active

[adamantine]

off-topic: i would like to ask for a little help concerning those ahk-codes

there is a problem:
if there are more than 1 instance of et in task-bar, the codes are working for the most recently launched et-window only

this is always a very unwanted behavior because:
- after the usage of the code: i don't get the desired result in a current window of et (if it's not the last et in task-bar)
- i usually lose the state/view (of folders/files/selections) in 1 other instance of et

in my options of et:
- run in background: no
- create a new window when running et: yes

in my ini-file:
- allow_multiple_windows=1
- allow_multiple_instances=0
- show_in_taskbar=1
- show_tray_icon=0
- minimize_to_tray=0

allow_multiple_instances=1 doesn't help. it only leads to the appearing of more than 1 Everything.exe process

the problem is seemingly related to the following part of the ahk-manual:    The WinTitle Parameter & the Last Found Window
but somehow i cannot find a solution now

[raccoon]

there is a problem:
if there are more than 1 instance of et in task-bar, the codes are working for the most recently launched et-window only

This is just how AutoHotkey works. It can't read minds, so it always acts upon the most recently launched process when using ahk_exe.

If you want to act upon the Active Window, then use "A" instead. As in: PostMessage, 0x111, 40040,,, A

[adamantine]

(in result list) i suggest to add to context menu of an object:         a new   'statistic > '   item
that may contain:

1. the 'full path length' info - for instance 265 or 259
2. and some other useful quick info (about this file/folder, and more), for example:
 
- its previous name (if an object was earlier renamed)
- the exact date-time of a recent rename (and all older renames too)

- its previous full path (if an object was earlier moved)
- the exact date-time of a recent move (and all older moves too)

- maybe a quick preview of a simple textual file (.txt, .cue...)
         (in this very context menu)
         (not in the menu itself, but in a part of that menu: a part that appears to the right of a menu item)

 
- info about quantity of files with the same extension (as the selected file)     (in result list)

- info about quantity of files with all other extensions (that are present in result list), for example:
                 15 cue
                 1 mp3
                 2 png
                 3 txt
                 103 wav

         but it seems that the better way is to just show all extensions (from result list) in 1 list like this:
                 3 txt
                 15 cue
                 1 mp3
                 2 png
                 103 wav
         where the first line will always contain the extension of a selected file
        (other extensions are always sorted alphabetically)
 
 
- info about quantity of all folders (and info about empty folders). 2 examples:
                 209 folders (2 empty)
                 6 folders (0 empty)
        (there may be an additional line/command: 'select empty folders')
 
- in cases when very long paths are present (more than 255 symbols): display their quantity
        (and implement a possibility to open a special list - with all of them - to rename them manually)

 
 
this is the idea that is quite raw (there are many ways for an additional thinking/discussing)

this idea does not seem to be very important for my personal work-flow, but i decided to post it anyway
(some other people may find such potential possibilities useful)

[void]

(in result list) i suggest to add to context menu of an object: a new 'statistic > ' item
that may contain:

1. the 'full path length' info - for instance 265 or 259
2. and some other useful quick info (about this file/folder, and more), for example:

I will consider a context menu item to show this information.
I am also considering a dialog to show all properties for the current selection.

One way to do this now is to select the file, right click the result list column header and click Add column.
Right click the property header and check Preview.
All property values are shown for the selected file.
I realize this is not fast or ideal, just pointing out the option exists..

If you use this information often, consider adding the "full path length" column.

- its previous name (if an object was earlier renamed)
- the exact date-time of a recent rename (and all older renames too)
- its previous full path (if an object was earlier moved)
- the exact date-time of a recent move (and all older moves too)

I will consider properties to record this information.
For now, this would need to be accessed from the Index Journal.

- maybe a quick preview of a simple textual file (.txt, .cue...)
(in this very context menu)
(not in the menu itself, but in a part of that menu: a part that appears to the right of a menu item)

I will consider a "preview" in the context menu.

- info about quantity of files with the same extension (as the selected file) (in result list)

- info about quantity of files with all other extensions (that are present in result list), for example:
15 cue
1 mp3
2 png
3 txt
103 wav

but it seems that the better way is to just show all extensions (from result list) in 1 list like this:
3 txt
15 cue
1 mp3
2 png
103 wav
where the first line will always contain the extension of a selected file
(other extensions are always sorted alphabetically)


- info about quantity of all folders (and info about empty folders). 2 examples:
209 folders (2 empty)
6 folders (0 empty)
(there may be an additional line/command: 'select empty folders')

- in cases when very long paths are present (more than 255 symbols): display their quantity
(and implement a possibility to open a special list - with all of them - to rename them manually)

I might start with a simple list of properties to show in the context menu.
Something to think about when I add context menu customization..
I would need to add a property that shows all the extensions and counts.


Thanks for the suggestions.