Commander X16

Question:

UFM now reads 255 files maximum. I recon having a list of more then 255 slows things down and doesn't add much in usability.

I have a few solutions in mind:

1. Add a 'read more files' option at the bottom of the lists. This will replace the current 255 files in the list with the next 255 files.
2. Just add a filter/search option to narrow down the list

What are your thoughts on this?

A search/filter is probably needed/useful anyway.

Someday maybe a music list might have over 255 files. Actually, the "Magic Slideshow" has a sample containing 500 files. Oh, and a Palette for each one, so 1000 files?

For performance or practical reasons, you could just keep it to 100. 255 of course is a technical limit, but general users might be fine with a "normal" limit. Then at the 100, give the option for "next group" or "more files".

Expanding on voidstar’s idea:

You can limit the group of files in memory to whatever is practical.

The more functionality could simply be implemented by reopening the dir, skipping over the files previously shown before reading the new ones.

That way you can handle any number of files with the same amount of memory.

AndyMt wrote: ↑Wed Nov 22, 2023 3:26 pm Tested this extensively. Very good already! Here is my feedback:
-Speed: quite good, totally practical for traversing directories and files
-user interface: as expected, very close to the good old NC, felt at home immediately. Funny how well muscle memory works after all that time.

Some suggestions:
- offer to use 80x30 text mode
- support crt safe modes like 64x30

I know this makes drawing the UI harder - I have the same pain...

I've been thinking about how to handle 64 and 40 column modes: the simple way would be just draw one panel, and let the tab key switch which panel is visible by horizontally scrolling the screen. (Because 128 columns are always there... you just don't see them all when in 64 or 40 column mode.)

So on 64 column mode, you might see the left panel and 24 columns of the right panel, and pressing tab focuses on the right panel, still showing part of the left panel on the left side of the screen.

And in 40 column mode, you see one panel or the other, just not both at the same time.

And, obviously, the program works the same in 80x30, 64x25, and 40x30 modes. You're just moving the screen around to show the currently selected panel.

That is exactly what I am doing with X Commander.
As soon as the width of the screen is below 40 columns, I create one panel off screen and just HSCROLL between the two panels.

How are you planning on handling different types of devices? My own development has stalled a bit by the fact that there seems to be quite a lot of different devices that handle differently.
In the emulator alone we have:
* HostFS
* SD card
On real hardware I would like to be able to handle:
* All Commodore disk drives (Does stuff like JiffyDOS play a role here?)
* Pi1541
* SD2IEC
* Possibly others that I do not know of

The thing is that as far as I can see, there is a difference i what can be provided by the different devices. HostFS and SDcard in the emulator should be able to provide timestamps and size when using DOS"$=L", but Commodore disk drives and images mounted on Pi1541 and possibly SD2IEC do not. Pi1541 does provide some information when an image is not loaded and I guess SD2IEC does as well...

Below I run through all the supported screenmodes on the CX16 and show how X Comander handles them with regards to panel switching.

TomXP411 wrote: ↑Thu Nov 30, 2023 8:13 am

I've been thinking about how to handle 64 and 40 column modes: the simple way would be just draw one panel, and let the tab key switch which panel is visible by horizontally scrolling the screen. (Because 128 columns are always there... you just don't see them all when in 64 or 40 column mode.)

So on 64 column mode, you might see the left panel and 24 columns of the right panel, and pressing tab focuses on the right panel, still showing part of the left panel on the left side of the screen.

And in 40 column mode, you see one panel or the other, just not both at the same time.

And, obviously, the program works the same in 80x30, 64x25, and 40x30 modes. You're just moving the screen around to show the currently selected panel.

I’ve already implemented support for different screen modes. All modes with at least 40 columns are supported. For less columns the program is less usable, so maybe I’ll support them in the future.

The approach I used is just not showing all info. If less then 80 columns I first hide the file times. If it still doesn’t fit I’ll hide file date and even file size. The main goal is to always have 2 windows present.

I’v almost added support for the snes controller as well and will upload the new version when finished.

TomXP411 wrote: ↑Thu Nov 30, 2023 8:13 am ...(Because 128 columns are always there... you just don't see them all when in 64 or 40 column mode.)

Say whuuuuut? This is new to me. I thought the screen dimensions were locked at whatever mode you were in.

mortarm wrote: ↑Thu Nov 30, 2023 3:43 pm

TomXP411 wrote: ↑Thu Nov 30, 2023 8:13 am ...(Because 128 columns are always there... you just don't see them all when in 64 or 40 column mode.)

Say whuuuuut? This is new to me. I thought the screen dimensions were locked at whatever mode you were in.

In textmode a row has 256 bytes, 2 bytes per character (1 for character and one for color) is 128 columns. Depending on the screen mode a subset of these columns are visible on the screen. Seen from the left top most character.

Yup. The screen buffer is always 128 columns (or 256 bytes) wide. This was probably done to allow for 8-bit registers in VERA, and it sure makes screen math easy: instead of adding 40 or 80, you can just increment the high byte of the address to change rows.

Anyway, when you change the screen dimensions, what you are actually doing is changing the scaling factor: setting the mode to 40x30 just tells VERA to double the pixels, as well as set some registers in the editor so that text wraps at 40 columns.

So for things like text editors, this allows you to maintain a 128 character wide text line, while showing a 40, 64, or 80-column window. For tile mode games, this would let you keep a 128 cell wide map in VRAM at any given time, which gives you a nice, 24 column wide buffer on either side of the screen for updating invisible tiles.

While Frank likely made the decision to make it easy to use 8-bit registers when dealing with screen coordinates, this was a fantastic decision from a programming perspective, as well, since it gives programmers a lot of latitude in dealing with the screen.

So, the first version of Ultimate File Manager is ready and is posted on de download-section of the forum. Alle communication about it, will be at the new topic.

Link: viewtopic.php?t=7014