|
|
Post by Stefan on Mar 14, 2015 11:58:19 GMT -5
File Manager always lists directories before files, regardless of the sort order (Name, Date, Size, etc). While I can (just about) understand this when the sort order is "Name", it makes little sense to me when the list is sorted according to other criteria, e.g. Date. It hampers selections when looking for a file in a folder with many sub-directories. I realise that Windows Explorer does this (for Name sort sequence only), but the difference there is obvious due to the yellow Folder icons. In the SPFLite textual environment, it's rather like ISPF 3.4 listing the VTOC by displaying PDS datasets before sequential files. My suggestion is: - Maintain strict sort sequence in FM lists, irrespective of entry type.
- Provide the differentiation usually derived from the Folder icon by displaying directories in a different colour to files, e.g. files in green, directories in yellow. That way, directories appear in the correct sort sequence and are still obvious.
- The current sort sequence is highlighted only in its column heading (not yellow throughout the column) e.g. display column heading in reverse video
Thanks for considering this change. By the way, the input field for each FM line is sometimes shown as ". . . . ." more often as "_ _ _ _ _". I have so far failed to determine the reason for this distinction. Any clues? |
|
|
|
Post by George on Mar 14, 2015 16:13:00 GMT -5
Stefan: Robert:
Ouch! This is already a custom sort. Now you guys want to muck up a carefully designed sort key. This is highly disruptive.
Where would you like .. to appear, my bet is you'll say 'well obviously at the top'.
I can't believe Dir* is in any way useful, I've worked with a file manager that did this, I found it VERY confusing.
George
|
|
|
|
Post by George on Mar 15, 2015 11:35:59 GMT -5
Robert: The problem with your prefixing idea is that there is already is another field which is effectively a prefix along with being an indicator of the type of line item. There are already 9 types. So it isn't a matter of just jamming in a 0/1, but of jamming in something that magically has to equal a range of possible values so they will sort together.
And inserting a byte into a field just causes grief everywhere else the field is used as all those places now have to carefully undo the prefixing. Did that in prior FM versions, a royal pain.
The Dir+ and Dir- I can cope with in the current design, I can fudge values to make it sort top/bottom, but the Dir* is tough, how do I make it 'equal' to 6-7 different line types?
George
P.S. And where does .. go? I really can't see this anywhere but the top.
|
|
|
|
Post by George on Mar 15, 2015 15:05:06 GMT -5
Not being privy to the internals, I am not sure how you'd go about doing Dir*. Main idea is that you have a "sort key" that is independent of the line type. I don't understand what you mean by 6-7 different line types. Are you counting excluded lines, top/bottom, etc.? If it were me, I'd have a 'sort object' containing a sort key, a line type code, and a pointer to the specific data for each line type. Then, you'd sort the 'sort object'. Why is it you always want a redesign of the internals as a solution. Considering how many times already I've re-written FM, I have no inclination to do it again for some sort problem. There are already custom sort exits for all the 'flavors' of sorting, I'm sure something can be added to the custom code to get us by this one."Where does .. go?" You mean the entry to go to the parent directory? Yes, since ".." is not a name, but a notation that defines the parent folder, it should go at the top regardless of the sort order, IF you intend to keep it there. HOWEVER, the .. entry serves only one purpose - to go up to the preceding level. Because of that, there is really no need to have this as an entry at all. You could remove it, and on the line where New, Flists, etc. appears, you could add an entry for "Up" or "Back". That is how stuff like Windows Explorer does it, and other software does similar things. The .. entry will remain. As to adding another entry to the quick bar, it's already pretty full, the existing entries barely fit as it is. And remember, we also have the END command to go back up.
George |
|
