Pandora Standard File Format?


I believe the solution you're all looking for is the Application Directory. These are implemented by ROX filer (available for Linux) and I believe a lot of OS X apps use a similar scheme.

Basically, if a directory contains an executable called "AppRun" it is an AppDir. If you open the directory in the file browser, the executable called AppRun is run. The icon is defined by a file in the directory called .DirIcon.

To the casual user the AppDir is just an icon that can be copied and run anywhere. In reality it is a directory containing all software and data an application needs.



Edit: Spelling
 
Squidge said:
It will be. The Linux nuts will probably change there firmware to mount sd cards as ext2 or whatever, but we don't care about that, as the they'll come from the "factory" as mounting fat32.
Why not just mount with the filesystem autodetect option?
 
Last edited by a moderator:
Blah said:
Why not just mount with the filesystem autodetect option?
Due to the fact that every time I use the autodetect option, it mounts the cards as fat, rather than vfat. I don't think people will be happy with 8.3 character filenames. Do you know how to change that bahaviour easily?
 
Last edited by a moderator:
Disable the normal FAT driver in the kernel. VFAT works for FAT16 and FAT32 anyway, so it's fine. That's how it's done on Open2x (and I think GPH firmware too).
 
Cool, thanks Orkie. I assumed that disabling the FAT driver would also disable VFAT, as VFAT would depend on FAT.

Obviously not :)
 
Squidge said:
Cool, thanks Orkie. I assumed that disabling the FAT driver would also disable VFAT, as VFAT would depend on FAT.
Well in menuconfig, you have to enable "DOS FAT fs support" then it gives you the option of compiling "MSDOS fs support" and/or "VFAT (Windows-95) fs support". It is the MSDOS option that causes the problem so that's the one to avoid.
 
Last edited by a moderator:
Dutch_Cap said:
I believe the solution you're all looking for is the Application Directory. These are implemented by ROX filer (available for Linux) and I believe a lot of OS X apps use a similar scheme.

Basically, if a directory contains an executable called "AppRun" it is an AppDir. If you open the directory in the file browser, the executable called AppRun is run. The icon is defined by a file in the directory called .DirIcon.

To the casual user the AppDir is just an icon that can be copied and run anywhere. In reality it is a directory containing all software and data an application needs.



Edit: Spelling



After considerable thought I whole heartedly agree, lame ass file extensions was a just plain stupid idea inherited from CPM, a complete throwback and the completely wrong direction to turn.
 
Last edited by a moderator:
fusion_power said:
Scary, that some users seem to don't care about us poor windows slaves. ^^"""
Heh... We care. But like all addicts, we have to get you off the vile stuff you're on to really be able to help you... :D
 
Last edited by a moderator:
Dutch_Cap said:
I believe the solution you're all looking for is the Application Directory. These are implemented by ROX filer (available for Linux) and I believe a lot of OS X apps use a similar scheme.

Basically, if a directory contains an executable called "AppRun" it is an AppDir. If you open the directory in the file browser, the executable called AppRun is run. The icon is defined by a file in the directory called .DirIcon.

To the casual user the AppDir is just an icon that can be copied and run anywhere. In reality it is a directory containing all software and data an application needs.



I think this is a good idea, and I'm pretty sure it's what craigix was talking about as well (a package format). Maybe we could put this Application Directory inside a zip-file (for space-saving), with a custom extension to keep the casual user from doing anything (possibly harmful) to it.
That (without the zipping) is the way OS X does it, too. Most apps have the .app extension, and with a right click on it and "show package contents", the user can see the directory.
The zipping would make it harder - and slower - for the launcher to get to the icon, though... I don't know by how much, really, so if anyone could tell that would be great :)

Oh, and I third .pwn - that was the first thing I came up with, too (;

Seriously, though, I thought .box was a neat idea.
 
Last edited by a moderator:
Nilsiboy said:
Oh, and I third .pwn - that was the first thing I came up with, too (;

Seriously, though, I thought .box was a neat idea.
Heh... I shied away from .pwn because we don't want to seem too l33tsp34k for the crowd if we succeed with the funding of this little project to the point where it kind of just takes off like Linux has over the years. >:)

.box actually sounds kind of cool, really.
 
Last edited by a moderator:
I think .PXE would be a great idea, As it is similar to the GP32`s file extension of .FXE, And would carry on the spirit of the original console that this site was created for.

Trooper
 
Dutch_Cap said:
I believe the solution you're all looking for is the Application Directory. These are implemented by ROX filer (available for Linux) and I believe a lot of OS X apps use a similar scheme.

Basically, if a directory contains an executable called "AppRun" it is an AppDir. If you open the directory in the file browser, the executable called AppRun is run. The icon is defined by a file in the directory called .DirIcon.

To the casual user the AppDir is just an icon that can be copied and run anywhere. In reality it is a directory containing all software and data an application needs.



Yeah! All the way.
I am happy that you have posted this. I read the thread from teh bgeiining and had in mind that Apple is doing this. And you can't get easier then that. I would even consider (like it was said above as well) to pack it into an ZIP (please, no RAR! ZIP is used everywhere: zlib, Windoes-Explorer (XP), ...) but there have to be tests how much is slows down the basic things which have to be fast when you build a file list for a menu or the like. I don't know about teh ROX, just read teh front page of the web page quickly. Does it contain a "DirCategory" file? Which could be used for structuring the software into Emulators, MediaPlayers, DocViewers, WhatNot, ...

On a side note: The DLL-Hell, or the thounds of .so.X appeare, cause every developer uses the current version of some lib he needs, although, he don't need the added functionallity at all. Therefor, it could be possible that libc, libSDL, ... will be put into NAND and the developer HAS TO USE this version, so they can be linked dynamically. However, I don't know if it is possible to use static AND dynamic linking, because the non-standard libs have to be linked statically ( or have to be put in the ROX directory :).

To conclude: USE A rox STYLE PACKAGE SYSTEM! :)

P.S.:
and change the design of the Pandora to somethin gwith the slide-out keboard like the mdoern handys (Xperia X1 and the like)
 
Last edited by a moderator:
Creature XL said:
However, I don't know if it is possible to use static AND dynamic linking, because the non-standard libs have to be linked statically ( or have to be put in the ROX directory :).
Yes, of course it's possible.
 
Last edited by a moderator:
Creature XL said:
and change the design of the Pandora to somethin gwith the slide-out keboard like the mdoern handys (Xperia X1 and the like)
Can't tell if you're trying to be funny, so I thought I'd do what I always do and assume seriousness. Please read here. :p
 
Last edited by a moderator:
The problem is see with zip is that the launcher will have to unzip the contents somewhere, run the program, and then delete the temporary files. Orkie's method is completely transparent to the file system.

Anyone fancy doing a zipfs, so you can basically mount a file as a directory?
 
Heh, this all reminds me of Screens Environment, which just implemented ZIP-mounting capabilities so ZIP's are seen as objects (equivalent of folders) like everything else on its file-system.

It would be cool if that could be implemented... or, even better, tar.bz2! Now there's a developer challenge! :p
 
javaJake said:
It would be cool if that could be implemented... or, even better, tar.bz2! Now there's a developer challenge! :p
.tar.bz2 has already been done :D

"Allows mounting of cpio, .tar.gz, .tar.bz2 archives. Reading and writing supported."
 
Last edited by a moderator:
Back
Top