Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Obviously needed: some flexibility regarding DirTree and FileList #65

Closed
klaus101 opened this issue Aug 27, 2023 · 23 comments
Closed

Obviously needed: some flexibility regarding DirTree and FileList #65

klaus101 opened this issue Aug 27, 2023 · 23 comments

Comments

@klaus101
Copy link

From other threads (see #44, #64) it becomes evident that different preferences to work with the folder treeview and the file list do exist.

Personally for me the folder tree is for folder navigation whereever the folder is, ideally (optionally) not flooded with file objects.
The file list is responsible for files ... so ideally (optionally) not flooded with subfolders, for not to waste space.
Apperently different opinions about these matters had come up.

First proposal to serve different needs: Explorer options dialog: Options:

Folder Tree:
( ) Don't show folder tree panel // If this is not selected:
( ) Include file objects

File List:
( ) Don't show file list panel // If this is not selected:
( ) Parent dir enabled // Show the [..] symbol or not
( ) Include subfolders

@tiomanisland
Copy link

this would be PERFECT! i would only use the "File List" panel, just like i do with vscode and Notepad++ (Open Folder As Workspace). i know @funap is busy but if he could do this, it would be so nice. i also allow him to rename the plugin ;-)

@tiomanisland
Copy link

any new regarding this @funap ?

@tiomanisland
Copy link

anything?

@funap
Copy link
Owner

funap commented Oct 1, 2023

Sorry, I've been working on other things lately and haven't had the time.
It may take some time, but please be patient. Pull requests are also appreciated.

@tiomanisland
Copy link

I will just go with VS code. not your fault. i think N++ dev should add such functionality not rely on plugins anyway. It is way too important. Thanks!

@vinsworldcom
Copy link

@klaus101 not sure I understand. I think the only way this works - using 1 "pane" in the Explorer Dialog instead of 2 - is to keep the top folder view and just add files to it. @tiomanisland is misguided if advocating for only the bottom files view. If we only use the bottom view, we lose all context of what folder hierarchy we are in.

Even VS Code and N++ folder as Workspace show the hierarchy like in the top tree view:

image

image

I think keeping the upper "tree" folder view and adding files to it is the only way to collapse the 2 panes into a single one.

Not sure I'd be a fan of that, so your idea of a setting in Options would do nicely, radio button select one or the other:

( ) Use single tree view for folder and files
( ) Use current default 2-pane view, top folder, bottom files

Cheers.

@tiomanisland
Copy link

I agree with you. Two radio buttons. The problem is funap is busy with other things.

@funap
Copy link
Owner

funap commented Nov 21, 2023

I think this is the best way to deal with the situation if it is to be addressed.

( ) Use single tree view for folder and files
( ) Use current default 2-pane view, top folder, bottom files

@tiomanisland
Copy link

You are right funap. I would select option 1 :-)
Do you have some time to do this? See how popular you are? ;-)

@vinsworldcom
Copy link

The "simplest" pilot implementation may be to just add files to the upper tree view. Not sure how that gets its contents, but seems a directory listing just asking for "folder" attribute. If that could be "removed" with an options panel checkbox so it would get folders AND files, one could just use the splitter window to "hide" the bottom files only view. The Filter panel would be useless in this quick implementation as it would still be tied to the files view (which would be hidden by moving the splitter to the bottom of the window). This way, we could experiment with how useful or useable this kind of view would be.

Note to fully implement, there would need to be other changes - like greying out the "Plugins => Explorer => Show Explorer (Focus on file)" option if only the tree view were active and to re-point the filter combo box to actually filter files in the Tree view if the file view is hidden. It would be a lot of work.

FYI, I would welcome this feature, but if not implemented I am happy to continue using Explorer plugin as I do now - it is ESSENTIAL part of my Notepad++ development workflow and I could not live without it or switch to the feature-lacking Plugin Admin version.

Cheers.

@funap
Copy link
Owner

funap commented Nov 21, 2023

I'll have some time in December, so please wait a little longer.

@vinsworldcom
Copy link

No rush from me. Thanksgiving week here in the States and then Christmas holidays soon. Please find some time to enjoy the upcoming holiday season - if you celebrate - and don't let this weigh on you.

Cheers.

@tiomanisland
Copy link

I'll have some time in December, so please wait a little longer.

That would be perfect!!! I really can't wait. Thank you so much!

@klaus101
Copy link
Author

I'm quite emotionless here because i normally use simply: tree pane for folders, files pane for files.

Nevertheless: for the files pane, i'd give to consider:
that well-established (by most file explorers) options would be neglected now from the design.

  • Mostly sub-folders can be shown too (this can be de-selected to show files only)
  • Option to "Show parent folder '..'" (sometimes done as equivalent "up" icon)

Why should those options by excluded by principle and design? They can be helpful for navigation being within a neighboured context.

1 similar comment
@klaus101
Copy link
Author

I'm quite emotionless here because i normally use simply: tree pane for folders, files pane for files.

Nevertheless: for the files pane, i'd give to consider:
that well-established (by most file explorers) options would be neglected now from the design.

  • Mostly sub-folders can be shown too (this can be de-selected to show files only)
  • Option to "Show parent folder '..'" (sometimes done as equivalent "up" icon)

Why should those options by excluded by principle and design? They can be helpful for navigation being within a neighboured context.

@vinsworldcom
Copy link

@klaus101 not sure I follow. I don't think there is a proposal to change the current Explorer window GUI. I think this is about adding an option (which is not checked by default - so current appearance would be default) to modify it by "merging" the files from the bottom list to the top folder tree view to be something like the images I show above. If you don't prefer that view and like the current GUI, do nothing, your default appearance would not change.

If you like a single merged view - folders and files together - I think the only option that works is a tree view like I show above in the pictures from VS Code and N++ (folder as workspace). I think that is most easily accomplished by adding files to the current Explorer top folder-only tree view.

I think files view (bottom) is pretty useless on it's own - it needs the top folder view for context. So the only option which someone could select would be to "merge" files into the top tree view or leave as is (2 panes, top folders, bottom files in the current folder).

Hope that makes sense.

Cheers.

@vinsworldcom
Copy link

Here is a simple change, lots of functionality broken, but it looks like this:

image

Created with a simple change to remove the folder-only filter from upper tree view.

diff --git a/src/Explorer/Explorer.cpp b/src/Explorer/Explorer.cpp
index 12da60a..bbfec13 100644
--- a/src/Explorer/Explorer.cpp
+++ b/src/Explorer/Explorer.cpp
@@ -668,7 +668,7 @@ bool IsValidFileName(LPTSTR pszFileName)

 bool IsValidFolder(const WIN32_FIND_DATA & Find)
 {
-    if ((Find.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) &&
+    if (//(Find.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) &&
         (!(Find.dwFileAttributes & FILE_ATTRIBUTE_HIDDEN) || exProp.bShowHidden) &&
             (_tcscmp(Find.cFileName, _T(".")) != 0) &&
             (_tcscmp(Find.cFileName, _T("..")) != 0) &&

Issues:

  • Double-clicking on file in the tree view does nothing, would have to remap that in this layout to open the file in editor like double-click in the lower files pane
  • The filter combo box does nothing - maybe it's just hidden as well as the files only pane in this "mode"?
  • The sort order is alphabetical - should be directories alphabetically, then files alphabetically for each tier in the hierarchy
  • Right-click context menu is the same for all items - folders or files - so one could right-click a file and select "New folder" and then get an error about it not being able to be created (as a subitem of a file). The "New folder" right-click still works OK when right-clicking a folder.

Maybe others? Those are just a few of the issues in just implementing this. There would be other needed updates as mentioned previously (e.g., greying out the "Plugins => Explorer => Show Explorer (Focus on file)" option if only the tree view were active.

Cheers.

@klaus101
Copy link
Author

klaus101 commented Nov 21, 2023

@vinsworldcom, but we don't differ at all in the most parts. Except a single one.
Dual pane window:, within the file list show folders here too - useless? You argue no, and i'd disagree here.
It's a very legitimate option, because it is useful for a kind of "near-field" navigation to the directly neighboured folders up/down. Not for overall navigation along the hierarchy of course.

Why else the Windows explorer does show folders within it’s file list?

It's not my favourite option, but a very understandable option, that’s my point. You cannot rule it out from the start when talking about the design.

From an own app, for to illustrate:
optsample

@vinsworldcom
Copy link

but we don't differ at all in the most parts. Except a single one.

@klaus101 , understand now and I think the "single one" maybe just a misunderstanding. I think the subdirectory folders of the currently selected folder in tree view - should appear with the files in the file view. This is the current behavior and I do not think the current behavior or GUI should change at all - keep it as is!

The option (click to enable) would make a single tree view structure with folders and files for those that prefer the "unified", "single" pane view. For current users, not checking the option to enable the new unified mode, would see no difference at all.

I think that puts us in agreement? I like the current file view having the subdirectory folders and rely on that as part of my current workflow.

Cheers.

@klaus101
Copy link
Author

@vinsworldcom: a possible misunderstanding … yes, i‘d feared so and therefore my reply. I think it’s clarified now.

As said in my OP I’m quite happy with the existent layout, but as discussions about some options came up, initially I’d simply tried to summarize the potential candidates for options here separately.
To “show subfolders” (or not) for the file list, this could be one of those legitimate options, that’s simply I tried to say. Some might be disturbed by finding a lot of sub-folders where they are searching for files only, and sometimes I feel the same. But personally I don’t really want it to be changed either.

@tiomanisland
Copy link

i am sorry if i sound rude but i dont know how to express myself better. two panels are stupid. to have folders in upper panel with files and then same folders in bottom panel that is like UI designer was drunk. why you dont just follow normal view like 99% of programs do? files and folders together, who ever wants to move back use [...]. thats how it has been for decades.

the other important thing is that search by filenames actually works! vscode ctrl+p works perfect. you can type part of file name, part of words and it will find everything. once it shows you results, you can click right arrow to open the file and still stay in the dropdown, move down, right arrow again, etc. everything should be easy and functional. just copy the vscode behaviour, simple.

@vinsworldcom
Copy link

@tiomanisland , we understand you prefer a single pane. However, the Explorer plugin was not just created by a "drunk UI designer" - it was originally made to mimic Windows own Explorer:

image

The files pane (on right) has the "same" folders as the folder view (on left).

That aside, there is room for improvement and especially when a plugin to another program (not the main window itself) space consolidation becomes a UI concern and collapsing files and folders to a single tree view makes sense. That is what this issue is discussing and from my screenshots above:

https://user-images.githubusercontent.com/9657169/284665498-6e5caa32-a4d7-4e6a-8b4b-70e5d334ae73.png

seems possible - although with quite a bit of work to make it useable.

If you feel this need is immediate, please code it and submit a pull request - @funap has been very accommodating with my PRs. If you don't have the skills to contribute, I suggest patience - or move to VS Code if you really like the functionality of it.

Cheers.

@funap
Copy link
Owner

funap commented Jan 1, 2024

Ver1.8.2.28 added option to use full tree.
if you have any other requests, please register new issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants