If some program relies on specific files and the program binary being in a specific location in /documents, is it possible to disable linking?
Is is possible to associate a file extension to a hidden program?

Could you add an option "savefile=" or something similiar where you can list a file as savefile in the package metadata?
On uninstallation, the user will (if the program has savefiles and they exist) be prompted whether they should be removed.
It's hard to remove files in /pacspire..

Could you add an option "savefile=" or something similiar where you can list a file as savefile in the package metadata?
On uninstallation, the user will (if the program has savefiles and they exist) be prompted whether they should be removed.
It's hard to remove files in /pacspire..

Sure, but maybe something like savefolder would be better?

Would it be possible to hook the deletion of the lnk file (if any) to trigger pacspire so that it can properly uninstall everything, as you say ?

Possible: Yes, but probably not for me. Maybe someone who is better at reverse engineering could do it
I'll make a GUI where it will be possible to remove packages.

Isn't it easier to simply hook the remove() function?
(Not the function itself, the location it's pointing to)

You can undo deleting files? Reminds me of DOS "undelete".

Quote from: Lionel Debroux on August 10, 2013, 10:28:31 am

Quote

you're simply restraining the target of the whole project to a few dozens people...

There are far more than "a few dozen persons" who can install Ndless...

As a side note, to get a rough idea of how may new users try Ndless: there are about 1400 visits of the Ndless user guide each month.

Well, of course a lot of people install ndless (even thought we don't really know the % compared to the number of Nspires in the world (this would be very cool to know even if it would probably be scarily low in absolute, partly because a lot of handhelds are owned by schools and not students....)

But as I was saying :

Of course, but not so many if you're combining the conditions : getting aware of the project && getting convinced it is a good idea && resticting (with no other motive than pissing the management off) to ndless files.
I'm just trying to help growing the targeted people ("catchment area" / "zone de chalandise" )

Oh and, on our (TI-Planet) part, Ndless 3.1, launched in late January 2012, reached 40k downloads a few days ago (or was it yesterday ?) and is the most downloaded file every week I believe (not counting exam stuff when it's exam time, though), and is the 1st overall (again not counting the exam stuff). Approx 71 times / day , 2100 / month.

Lionel, you said libti* couldn't handle files in nested directorys, but that is simply wrong, because it works just fine

The test program enables doing more stuff, but dirlist of a hierarchy containing nested directories does not work as it should (although an old commit at least prevents it from crashing upon such directory hierarchives, which it used to do)

While some pieces happen to work, as you've noticed, the Nspire dirlist code simply does not handle recursive enumeration of more than one level in the hierarchy.
To see what I mean: on the calculator side, create an a1 folder at the root of the documents folder, then an a2 folder inside a1, then an a3 folder inside a2; then, on the computer side, trigger a dirlist from the root of the hierarchy. a2 is not enumerated, and it has broken type itself.

Locally, I've had some working code for higher-recursivity Nspire dirlist for a long time (like, more than a year), but I never finished reworking and cleaning up the dirlist data structure (some Glib trees) -> UI data structure (some GTK+ trees) code in TILP, so as to add support for > 1 level of folders (Nspire OS 2.xx and 3.xx) without breaking 0-level (TI-Z80) and 1-level (TI-68k) support.

And the code base contains assumptions that there's a single / in a valid calculator-side path. Nested folders trip that assumption. At select places, invocations to strchr()-type functions would have to be replaced by strrchr()-type functions.