XYplorer Beta Club

jacky wrote:

admin wrote:But this would run into some problems concerning the GUI. If column visibility is per-tab, then the Columns menu should be under Current Tab menu. Even worse with Line Numbers which is implemented as part of List Style!

Yes, "Columns" might have to move under Current Tab (and thus be available on tab header's ctxt menu also).

Line number : Well, it's a weird one anyhow because it's under both List Style & Columns! So just remove it from List Style, so it's only under "Current Tab|Columns", and we're good. (Or remove it from Columns, but then it has to go away from FV as well... plus from ctxt menu of Name column header, and that might just be weird, too)

admin wrote:Looks like trouble... repectively like work ... I mean column visibility per-tab sounds quite natural, doesn't it? But think of the disadvantage (and the reason why it is implemented as it is): once you decide you want to see e.g. the Attributes column, you will have to do it for each tab.

Not necessarily, you could just use the same tip as when setting up the View : hold Shift while clicking to make it applied to all opened tabs

Yes, I was thinking along the same lines.

I just wondered: if I move Columns under Current Tab the View menu turns into some monster where a submenu "Current Tab" is much bigger than the main menu. I wonder if I should add another top menu right of View called "Tab".

OTOH, Views and SortBy will be naturally looked for under View! So maybe better move Views and SortBy UP to the top of View which would be:
--------
Current tab
Views
SortBy
Columns
--------

All these would be per tab, but easier to reach than now.
The tab's ctx menu would of course still look like now (+ Columns).

admin wrote:I just wondered: if I move Columns under Current Tab the View menu turns into some monster where a submenu "Current Tab" is much bigger than the main menu. I wonder if I should add another top menu right of View called "Tab".

To be honest I really think the entire menu bar is in need of some attention.

I'm just not sure what can be done, and haven't spent the time to think about how it could be better organized.

admin wrote:I just wondered: if I move Columns under Current Tab the View menu turns into some monster where a submenu "Current Tab" is much bigger than the main menu. I wonder if I should add another top menu right of View called "Tab".

hmm.. not sure. As you said some of the menus here might be expected under View... It should be "Current Tab" anyhow, but I don't know if that'd be the best to do.

admin wrote: OTOH, Views and SortBy will be naturally looked for under View! So maybe better move Views and SortBy UP to the top of View which would be:
--------
Current tab
Views
SortBy
Columns
--------

All these would be per tab, but easier to reach than now.
The tab's ctx menu would of course still look like now (+ Columns).

Yeah, no, I don't like that. I have no problem having a submenu being bigger than its parent, and that setup would be misleading to me, because Views/Sort by/Columns belong under Current Tab to indicate they are Tab settings, not global ones. I'd say it's even more important to have things feel "natural" and "obvious", especially to newbies.

TheQwerty wrote:To be honest I really think the entire menu bar is in need of some attention.

I'm just not sure what can be done, and haven't spent the time to think about how it could be better organized.

Why? I don't know, doesn't look bad(ly organized) to me...

jacky wrote:

TheQwerty wrote:To be honest I really think the entire menu bar is in need of some attention.

I'm just not sure what can be done, and haven't spent the time to think about how it could be better organized.

Why? I don't know, doesn't look bad(ly organized) to me...

Mostly it's because there are so many items that are in the main menus that it's overwhelming, even to me. I'm not convinced they all need to be at that level or even in the menu in the first place.

I also think XY needs to have the option/tweak of displaying menus more intelligently. For instance, hide the disabled items. I only use UDC for scripts, so only 3 of 11 items are enabled on that menu.

If I go to File when nothing is selected 10 of 25 items are enabled; Swap Names and Preview shouldn't be, so it's really 8 of 25. Plus, it's confusing that Properties does the current folder, while Quick File View does the focused item.

File and Edit both have different copy commands. Generally "New..." functions are found under File. I'm not convinced Compare, Find, Select should be under Edit.

Do people really change their Tree/List style often enough to warrant having all those items in the main menu or should some of them be moved to Configuration? Since they only really apply to details view and are available by clicking the column headers do we need items to change the Date/Size Column Formats?

That's just some issues I came up with now. But I don't want to take this thread off-topic, just mention that I think the whole menubar could use some attention in the near future.

Update: Moved my response to the new thread about this topic in Wishes: "Menu Bar stuff" where it now appears after jacky's comment about it, but figured it was much cleaner to have it there instead of here.

Found a bug: If you open a folder in the background the FV is not applied. Instead it inherits the view of the currently active folder.

Question: you mention startup as exception to the rules (i.e. not loading any matching FV). When will that actually have an impact, except for when a path was specified on command line to a folder with a FV (Or using Permanent startup path to a folder with FV) ?

Also, is it not "wrong" to not load the FV, yet name it as the active FV ?

jacky wrote:Question: you mention startup as exception to the rules (i.e. not loading any matching FV). When will that actually have an impact, except for when a path was specified on command line to a folder with a FV (Or using Permanent startup path to a folder with FV) ?

Also, is it not "wrong" to not load the FV, yet name it as the active FV ?

When you manually change the view settings while a FV is active, the FV is "wrong" in that sense. When you close XY in that "wrong" state it will open in that wrong state next time. The FV is not applied (but shown as active), but the last state remembered.

admin wrote:When you manually change the view settings while a FV is active, the FV is "wrong" in that sense. When you close XY in that "wrong" state it will open in that wrong state next time. The FV is not applied (but shown as active), but the last state remembered.

Yeah, okay, you're "right".

Good thinking on that one, too, I'd not thought of that case!

I don't think it's possible (yet) but maybe i'm overlooking something:
Is there a way to create a FV for all subfolders but not for the currently active folder? Let's say i have: I want the default FV for C:\abc\ but a special FV for all subfolders. Right now i have specified one FV for "C:\abc\" (with my current "default" settings) and another FV for "C:\abc\*". Downside: If i make changes to the default view, "C:\abc\" is not updated obviously.

Pagat wrote:I don't think it's possible (yet) but maybe i'm overlooking something:
Is there a way to create a FV for all subfolders but not for the currently active folder? Let's say i have:

Code: Select all

C:\abc\
C:\abc\def\
C:\abc\ghi\
C:\abc\jkl\

I want the default FV for C:\abc\ but a special FV for all subfolders. Right now i have specified one FV for "C:\abc\" (with my current "default" settings) and another FV for "C:\abc\*". Downside: If i make changes to the default view, "C:\abc\" is not updated obviously.

Simply define one FV for "C:\abc\*\" and it will only apply to subfolders of "abc" but not that folder itself.

jacky wrote:Simply define one FV for "C:\abc\*\" and it will only apply to subfolders of "abc" but not that folder itself.

Nice! Didn't think of that one...

thx.

I was thinking about the following: For some folders i usually set a Visual Filter to show only, let's say .pdf files. Wouldn't it be good if one could define a visual filter already in the folder view so that it is set automatically everytime i visit that folder? Since the pipe symbol is already used to separate directories what about a special field to enter a visual filter which will be applied to that FV? Maybe for FV version 2?

What do others think?

Pagat wrote:I was thinking about the following: For some folders i usually set a Visual Filter to show only, let's say .pdf files. Wouldn't it be good if one could define a visual filter already in the folder view so that it is set automatically everytime i visit that folder? Since the pipe symbol is already used to separate directories what about a special field to enter a visual filter which will be applied to that FV? Maybe for FV version 2?

What do others think?

The way to do this would be simpler: you define the VF in the list, and I do the rest. (The rest: add VF to the stored and applied view settings.)

But yes, this will be only in FVS 2.0.

Pagat wrote:I was thinking about the following: For some folders i usually set a Visual Filter to show only, let's say .pdf files. Wouldn't it be good if one could define a visual filter already in the folder view so that it is set automatically everytime i visit that folder? Since the pipe symbol is already used to separate directories what about a special field to enter a visual filter which will be applied to that FV? Maybe for FV version 2?

That's actually one of the reason I can't wait for "onEvent Actions" myself : cause then I'll stop using FVS that I only use now for sort order, to have it replaced by a script of my own triggered "onLocationChanged". That way, not only will I be able to change the sort order, but also affect other settings I'd like to "link" to location as well, like VF, Hide Folders in List, Suspend Auto-Refresh...

(AAMOF it'll even allow me to revert back some of my Catalog items to simple locations, not scripts as they are now, which also means I'll get to be able to use them as D&D destinations or "scroller" (Ctrl+Alt+Shift+Click) again! (PS: would still love a command scrollto) Right now I have to have "dupes" to support that...)