X Commander

[JimmyDansbo]

I am in the beginning stages of writing a Norton Commander-like filemanager for the Commander X16

It has been a bit of a struggle to actually get any code done, but I have finally reached a point where I can show off just a bit.

paneandhotkeydemo.gif (6.91 MiB) Viewed 6143 times

I am only planning on supporting the default text-modes on the Commander X16, but the program should be able function in all of them.

Norton Commander had menus for things that were not directly accessible by function keys. I plan to implement similar menus, but the question is:
* What items should be contained in the menu(s)?
Other questions I have no answer to yet are:
* How should long filenames be handled?
* Do we need different modes such as brief and full mode?
* Is there a need for Directory Tree mode and Info mode in the panes?

Let me know what you guys think. As this project is still in very early development, I am open to any and all suggestions.

Edit - Functionality that should be included in the program:
* Sorting (ascending/descending)(name, size, date ?)
* Search and Filter
* Multi-select of files/folders
* Ability to LOAD and/or RUN programs
* Mouse support, including scroll wheel

Functions that I already have in mind of including are:
* Rename/Move
* View and/or Edit file
* Create directory
* Copy directory/file
* Delete directory/file

[Xiphod]

I think it's great! I remember using Norton Commander for awhile. One of my earliest programs was called "DOS BOSS" as a file manager type program. It was based on an even earlier file manager program - from early MS DOS 3.0 days, it was a 24K COM program, but other than that I never could remember the name and haven't been able to find a copy again. But I do remember it introduced me to the idea of multi-selecting files, and performing some operation on those selected files.

So - some suggestions: one challenge here will be SORTING. Specifically, when you have a bunch of files in a folder. Note that the new R44 ROM has a LONG file listing feature, to show additional information (filesize in bytes, timestamp). Sorting a lot of filenames (or maybe based on filesize or some other criteria) may be a good way to use BANKing? Or just accept that you can only deal with some limit of files in a folder (I'm not sure if CMDR-DOS itself puts some limit to the number of files in a folder??).

- Multi-select, as mentioned, will be a great feature. Like if I want to select a subset of files, and only move them to another folder (re: cut and paste).

- Many some kind of file-association. I'm not really sure how to pull that off, since so far I don't think there is a standard way to pass command line arguments to BASIC programs. cc65 has a convention for passing a form of "command line arguments" (I'd have to look up the format). But imagine selecting an audio file and being able to launch an audio player. Or a TXT file and have it loaded into X16EDIT.

- features of: delete a file, rename a file, copy a file. A "top viewer" (or maybe also a "bottom viewer") to show the top N lines (or bottom N lines) of a file [ text files; for bin files hard to define what a line is - I guess whatever fits in N rows of the current screen resolution ].

- search and filter: like an input to say "just show me *.PRG files"

- mouse support, such as to select/unselect files

- make/remove folders

- split view: not sure if really practical for CMDR-DOS, in terms of maintaining context of two folders at once. Recall users can list across device 8 and device 9 (like IEC devices).

[JimmyDansbo]

- split view: not sure if really practical for CMDR-DOS

Thanks for your suggestions, I have added them to my initial post.
The plan is to have split view in modes that are wide enough to handle it. (read 40 colums or wider)
In the smaller modes, there will only be one pane visible at a time, but the second pane will still be there as a "virtual" pane and it will be possible to switch between the two panes.
I also plan to keep the ability to have only a single pane visible in the wider modes.

I still need to figure out what to do with long filenames when we can not display all of the filename at once...
* Should the filename be truncated to a fixed width like Windows 95 did it and only show the complete name when showing information for the file?
* Should the filename scroll to show the entire name? Should it then be for all visible filenames or only the one currently highlighted?

So many questions that needs answering

[kelli217]

Regarding long filenames...

The old Commodore systems only supported up to 16 characters for the length of a file name. So why not just pick that as a default?

[JimmyDansbo]

Regarding long filenames...

The old Commodore systems only supported up to 16 characters for the length of a file name. So why not just pick that as a default?

The problem is that I plan to have to program support all official text modes and some of those are very narrow.
In the smallest text modes there is only a total of 18 characters pr. line when the panel has been drawn. Of those 18 characters, 2 are used for delimiters if showing full information.

Come to think of it, I think I will just show as much of the filename that there is room for and if the user needs the entire name, they will have to display the files info or something like that...

[mortarm]

> I am in the beginning stages of writing a Norton Commander-like filemanager
> for the Commander X16

Ah that takes me back. I used three such programs back in the DOS days: PathMinder (which I read was the first of its kind), NC, then Midnight Cmdr. (my fav).

> I am only planning on supporting the default text-modes on the Commander
> X16, but the program should be able function in all of them.

From a practical standpoint, I wouldn't bother with anything less than the 40- character screens. Anything less and you'd have to compromise too much. 'Sides, how many people actually use the low-end screens?

> * What items should be contained in the menu(s)?

Looking at images of NC will be a good starting point.

> * How should long filenames be handled?

Couple ideas: 1) If the file name comes within three spaces of the border, use an ellipsis to indicate there's more to the name. Enough of the file name should be visible to distinguish it from others. 2) reserve a line at the bottom of the screen to show the full file name, along with other info if there's room.

> * Do we need different modes such as brief and full mode?

Depends on how you define the two. 80-col. screens would be good for this.

> * Is there a need for Directory Tree mode and Info mode in the panes?

Everybody has different needs, so that's a hard one to answer. Again, 80-col. is your friend.

> Edit - Functionality that should be included in the program:
> * Sorting (ascending/descending)(name, size, date ?)
> * Search and Filter
> * Multi-select of files/folders

Pretty much a must for any file management program.

> * Ability to LOAD and/or RUN programs

That means X Cmdr. would need to be a TSR program. Is that possible on this architecture?

> * Mouse support, including scroll wheel

I don't really see the need, given the limited size of the workspace.

> Functions that I already have in mind of including are:
> * View and/or Edit file

Which brings us back to the multiple-programs-in-RAM issue.

All-in-all, I like the idea.

[JimmyDansbo]

From a practical standpoint, I wouldn't bother with anything less than the 40- character screens. Anything less and you'd have to compromise too much. 'Sides, how many people actually use the low-end screens?

My thinking is that there is a reason those text modes have been created... I know that Adrian (from his Digital Basement) requested some of the modes because of overscan on older CRTs, but I am not entirely sure if that is the origin for all of the low-resolution modes.

> * How should long filenames be handled?

Couple ideas: 1) If the file name comes within three spaces of the border, use an ellipsis to indicate there's more to the name. Enough of the file name should be visible to distinguish it from others. 2) reserve a line at the bottom of the screen to show the full file name, along with other info if there's room.

My thinking is also to somehow indicate that the filename is longer than what can be displayed. I think I am just going to use a single character for that.

> * Ability to LOAD and/or RUN programs

That means X Cmdr. would need to be a TSR program. Is that possible on this architecture?

No, I think that X Commander should do the same thing as BASIC does - Get out of the way of the program being loaded

> * Mouse support, including scroll wheel

I don't really see the need, given the limited size of the workspace.

I am sure that people will ask for mouse support if it is not included I am actually thinking of making most functions accessible with the first joystick as well.

Thanks for your ideas and suggestions.

[mortarm]

> My thinking is that there is a reason those text modes have been created...

I was wondering about that myself. One mode that's missing that, to me, seems obvious to have, is 80x25. This was a common size for terminal users.

> I think I am just going to use a single character for that.

Since we have all those PETscii characters to choose from, that would make more sense.

> I am sure that people will ask for mouse support if it is not included I am actually thinking of making
> most functions accessible with the first joystick as well.

Technically speaking, sure why not; it's there, might as well use it. It's just, to me, using a mouse on an '80s-style computer kinda spoils that 8-bit vibe. It wasn't until I got an Amiga 1000 did I use a mouse.

[kelli217]

It's just, to me, using a mouse on an '80s-style computer kinda spoils that 8-bit vibe. It wasn't until I got an Amiga 1000 did I use a mouse.

Which came out right in the middle of the '80s...

[mortarm]

Which came out right in the middle of the '80s...

But it wasn't an 8-bit computer.