ROM-root chooser shall remember recent filepath AND have better default starting directory

[porg]

File chooser shall remember recent filepath This can be a time-saver if a user sets up multiple ROM-root-folders. It is very likely that the other rom-roots are in close proximity (1-2 drill-ups + 1-2 drill-downs + ). It can saves a lot of time compared to starting from root each time (2-6 drill-downs + it needs more concentration to navigate the full path, than to simply drill up to the siblings hierarchy and drill down to another sibling).

File chooser's default starting directory /media/ instead of / In 99,99% roms reside on an external medium, again 95% probability that it's on a SD card, and ~5% on a USB accessible storage device, but only in the rarest cases on the NAND. Therefore a good default starting point for the file chooser would be /media/ instead of /. Those edge cases can still navigate up (..) if needed.

Example rom folder structure (for comprehension)

/
    media/
        sd1/
            pandora/
                roms/
                    platform1/
                    platform2/
                    platform3/

[nuhrin]

Hmm, interesting. The fact that the chooser is defaulting to / is a bug.

There is a configurable preference to set the default rom path presented when viewing a platform that you've not yet used (to select your roms that first time). The default preferences file installed at first run sets that to /media/mmcblk0p1/pandora/roms.

Looks like there are two related issues:

• if the configured default path doesn't exist it falls back to /
• in contexts other than entering into an shipped platform for the first time (such as creating a brand new platform), the configured default path is not respected (just uses /).

So, at the least I'll fix the above by respecting the configured default in other contexts and changing the internal fallback to /media. I wonder if I should also change the shipped default preference to /media/mmcblk0p1/?

As far as the "remember recent filepath" request, perhaps having the bug(s) described above would make this unnecessary or even undesirable? Looking at the code, there are currently exactly three places this chooser is used:

• configuring the default rom folder (preferences)
• choosing the rom folder for a new platform
• choosing the rom folder on first use of a shipped platform

Starting at the configured rom folder (or a sensible fallback) seems like it would end up starting you off closer to your desired path selection in these specific cases than using the last selected path. You just move down a folder or two rather than popping up and then back down.

[nuhrin]

I fixed the bugs mentioned in my last comment, and changed the fallback path (when default rom path not specified in preferences, which shouldn't happen) to /media.

I believe this fully addresses the problem statements (as discussed in my previous comment), but I'll leave this issue open to give you the change to respond.

[porg]

1. Note, that /media/mmcblk0p1/ is not present if the SD card volume has a label! Many users label their SD cards, I assume. Therefore /media/ is the only safe common ground, which should therefore be the default fallback. Also some users may have roms/ in the root of their SD card, and not nested within /pandora/. But still, a default preference /media/mmcblk0p1/pandora/roms/ is a good thing, as it will suit those, which just format a SD card, assign no name (label) to it, then create a pandora folder on it, as taught in all Pandora related instructions, and very likely will create a roms folder within, second most likely on the root level, or somewhere else. Should /media/mmcblk0p1/pandora/roms/ not be present, the fallback will kick in, and bring you to the safe common ground /media.
2. "Remember recent filepath" is a desired feature, because it best fits the individualism of each user! Regardless of where in the hierarchy the rom folder(s) is/are, very likely the user will have the different platform rom root folders somewhere nearby (see original post). So for setting up multiple platforms while the program's first use (particular interesting for @b_o_b's idea of a "Pandora Pandafe OS distro") this is the method with the least navigation steps! Not navigate through the whole path, but only jump to the very likely existing neighboring siblings! And it is also safe, because if the recent path is gone meanwhile, simply fall back to the common ground path, /media.

[nuhrin]

If the default rom path has been explicitly set, then starting in the last used path is actually an anti-feature, since it fails to respect the choice actively made by the user ("start with this path if you need to ask me where the roms are" -- the purpose of the setting).

If the default rom path has NOT been explicitly set, then starting with the last used path as you've outline does start to make some sense to me.

So the last used path becomes a best guess fallback for default rom path, up until an explicit preference is set (if ever).

That seems logical and reasonable.

[porg]

If the default rom path has NOT been explicitly set, then starting with the last used path as you've outline does start to make some sense to me.

This is what I always meant.

If the default rom path has been explicitly set

And I did yet not know, that your idea was a user configurable global default path (the root which contains all platform-rom-root-folders, as I understand it).

I think now we understand each other, as you outlined in your latter paragraphs. In pseudocode (just to sum up behavior, neither logically nor structurally optimised):

defaultPath = preferences.defaultPath // default="", may get initialised somewhen
currentPath = preferences.currentPath // i.e. "/media/myLabeledSd/roms/nes/", default="", changes frequently, written to file at quit (efficient) or each time it changes (less efficient but crash-safe) or if not changed for treshholdSeconds (more efficient and still quite crash-safe)
defaultPathGuess = "/media/mmcblk0p1/pandora/roms/"
defaultPathMinimum = "/media/"

if (!defaultPath.exists() && !currentPath.exists()) { // Happens at first use and if user voluntarily defined no defaultPath and moved/renamed recent currentPath (rom folders) or moved/renamed defaultPath
    if (!defaultPathGuess.exists()) { // More likely in my estimation
        currentPath = defaultPathMinimum
    }
    else { // Less likely in my estimation
        currentPath = defaultPathGuess
    }
}
else if (defaultPath) {
    // If defaultPath is defined it always overrides currentPath
    currentPath = defaultPath
}
// If nothing in the if-else-clauses caught, then currentPath must be ok and is used as-is.

As I am an interaction designer not a developer, I did not code for a while. Such a small if-else-clause, which is only run once at program start anyhow, is a piece of cake for modern computers anyhow, nevertheless I would like to know from you wether I made it logically correct, and what would be the optimum structure/order. Thanks!

[nuhrin]

"As I am an interaction designer not a developer"

Provides some interesting context for your feedback. I wish some of my coworkers were as detailed in their notes as you are. :)

[nuhrin]

Implementation tested and committed.