Omnimaga
Omnimaga => News => Topic started by: critor on February 05, 2012, 09:32:12 am
-
Latest Ndless 3.1 beta (r530) adds support for file associations based on file extensions.
Thanks to a little text config file (ndless_cfg.tns), you can tell Ndless to automatically look for a "mviewer.tns" file and launch it each time you try to open a ".png.tns" or ".bmp.tns" file.
All similar Ndless programs will have to be updated in order to support this new feature.
We hope to see updates for mViewer, nDoom, gbc4nspire and nespire soon ;)
Download the latest Ndless 3.1:
http://www.unsads.com/projects/nsptools/downloader/download/release/1
-
Awesome. So does trying to open a ".png.tns" file open it with mViewer, or does it just open mViewer and you still have to navigate to the file you want to open?
-
Great update! I'll try to update nPlayer soon! :)
-
Wow, this is just getting better and better.
-
Something with argc/argv?
-
The file name is passed in argv[1]. I just haven't had the time to update the documentation (anyway this update is useless as long nespire/gbc4nspire/mViewer/nPlayer aren't updated too).
-
Here is nPlayer CX, updated to support this feature! I also updated the version in the Omni archives! :D (If someone could, please update the version on TI-Planet also ;)).
-
apcalc DFon't forget TI-Planet too :P
Also I can't wait for being able to launch WAD files directly from the Nspire file list :D
-
apcalc DFon't forget TI-Planet too :P
Oh, yeah, I meant TI-Planet. D:
/me forgot about the change!
-
Hmm, I guess it would even be possible for a program to auto-install its own file associations by accessing the config file, right? It would be cool if Ndless included a built-in function for that, to enforce the correct format and not allow duplicates and such.
-
I thought of this, but I'm not sure if it will be really intuitive for users to ask them to run at least one time the main program for the file extensions to work.
-
I thought of this, but I'm not sure if it will be really intuitive for users to ask them to run at least one time the main program for the file extensions to work.
It's more intuitive than setting it up manually (though of course, that would also be possible).
Edit: Here's another idea which would make it simple to package file associations with program releases (no text editing required). For example, for .nes.tns, there could be a file called ndless_cfg_nes.tns which contains the name of the program to open. (Since that file doesn't actually have a .nes.tns extension, it won't be treated as a NES file itself, naturally)
-
Very nice :)
-
Hmm, I also wonder how I'll handle file associations for gbc4nspire, which has 3 different versions with different program names (gbc4click, gbc4touch, gbc4cx)
-
Excale suggests that the config file value contains {CX_program,[touchpad_program,[clickpad_program]]}.
-
Excale suggests that the config file value contains {CX_program,[touchpad_program,[clickpad_program]]}.
Ah, is that valid syntax currently?
-
No but I could add it.
-
Hmm, I also wonder how I'll handle file associations for gbc4nspire, which has 3 different versions with different program names (gbc4click, gbc4touch, gbc4cx)
You could also give the same name to the 3 versions, and put them in your archive in subfolders .
I think it would be easier than having to give updated config files for 3 different models. (as for now, those config files have to come with Ndless, and in theory with all programs which would require an additional line)
-
Alternatively, I could make a single executable that works on all 3 models (which would be the 3 programs appended together with hardware checks to select which binary to run). As long as nobody minds the tripled program size, that is.
-
Supporting the "cx,touch,click" syntax isn't much work for me anyway.
-
Very nice work here. :)
-
Alternatively, I could make a single executable that works on all 3 models (which would be the 3 programs appended together with hardware checks to select which binary to run). As long as nobody minds the tripled program size, that is.
Great idea! :)
-
Alternatively, I could make a single executable that works on all 3 models (which would be the 3 programs appended together with hardware checks to select which binary to run). As long as nobody minds the tripled program size, that is.
Hm, much like Mac OS X does with their Universal binaries. Interesting idea.
-
It's really not too hard since gbc4nspire (like all other Ndless programs) can be run from anywhere in memory, so each of the binaries will have no idea that the other ones have also been loaded :P
-
Aren't the other versions made by patching the original Clickpad version? Should be much smaller to just have the Clickpad version + patches + code to apply patches at startup.
-
Yeah, but that's a lot of work. :P
-
nDoom has just been updated with file associations! :)
You'll need to manually add the "ext.wad=ndoom" line to your "ndless.cfg.tns" file for now.
French news:
http://tiplanet.org/forum/viewtopic.php?p=120405#p120405
Download:
http://tiplanet.org/forum/archives_voir.php?id=3889
-
Because I'm not keen on bricking my calc, could someone tell me how to update ndless(so I don't screw up)
-
What about following the installation procedure described in the documentation of Ndless ? ;)
-
What about following the installation procedure described in the documentation of Ndless ? ;)
That meaning that I can safely overwrite the ndless_resources.tns file on my calc and install the OS on top of my current Ndless OS, right?
EDIT: Nevermind already figured it out(not thanks to you though) you have to uninstall first then reinstall.