Wouldn't have it made sense to split the nspire support into an entirely different lib?

In 2007, Romain Liévin definitely thought about making a new, fresh library, instead of adding support for the Nspire to libti*.
On the one hand, it would have made some sense, given that support for the Nspire doesn't use a number of facilities of the framework that the TI-Z80 and TI-68k supports use.
On the other hand, it's a calculator with mostly the same operations as the others, there is definitely some code sharing, it has the same direct USB cable as the 84+(C)(SE) and 89T, so it could be made to fit within the rest of the framework, and have TILP not depend on two different, though very similar, libraries.

It doesn't share ANY code (except unneeded, like FileContent, which is for file group support and VirtualPacket)

While some of them are definitely unnecessary for the Nspire, don't be too quick to remove all layers of data structures and abstractions. Cable send/receive (libticables) <- raw packet (splitting/reassembling what goes over the wire, nsp_rpkt) <- virtual packet and session handling (nsp_vpkt) <- commands (nsp_cmd) <- calc functions (calc_nsp) <- high-level operations combining multiple functions (e.g. tilp_calcs.c) does make perfect sense, even in the context of a single calculator and protocol series.
Although it looked complicated to me as well in the beginning, and it isn't perfect (but who is ?), the fact that the making of the libti* framework has received some thought. For the narrower purposes of interacting with the Nspire, it's over-designed... but it's much better to somewhat over-design things, than to under-design them and have to significantly refactor them later
"Start from small stuff and try to scale up" was exactly the approach used by Microsoft in the MS-DOS, then "early" Windows area (all the way up to ME), instead of "descend from big stuff and scale down to smaller computers" like the *nix series does... The end result was not quite the same from a reliability point of view.

and it is very unlikely to be used by an application which supports both the nspire and the other TI calcs.

TILP is actually the main use case, the one the libs have always been primarily designed for


In 2007, what Romain did was probably the best course of action at the time. People were only warming up to Qt 4 (from 2005), the first version which had a FLOSS code base for Windows, and porting from Glib/GTK+ to Qt 4+ would have been much more work than the libti*/TILP I -> II API rework. At least, he was able to complete the API rework in the time he could allocate to it, instead of having some unfinished transition, and we all have been able to build some stuff on top of the improved rewrite since then
Nowadays, in 2013, restarting from scratch to build a C++11/STL, framework-neutral code base, on top of which Qt applications can be built without a Glib dependency, is a good idea, and has been for a while...

I'm convinced that the making the skeleton of a brand-new C++ framework tailored to the Nspire (but by all means, keeping the good design bits of the old ones, and reusing lots of code because at the lower level, the dependency on Glib is mainly g_malloc/g_free, g_list and g_tree !) wouldn't even be highly time-consuming...
A week of full-time work would go some way towards the creation of such a framework. Witness BrandonW's single-purpose C# hack for receiving an OS from a Nspire, inspired from the code in libticalcs and libticables.
But who can spend a week or two of work, full-time, on such a task ? Not me (not alone), sorry - I have a full-time job, I need it for paying the bills, paid holidays are not to be spent working full-time, and it's the same thing for everybody else...
[EDIT1, less than 1h later: sure, if people paid for several hundreds of euros, then I could spend a week full-time on creating the skeleton of a fresh code base, and certainly filling in some bits. But facts show that this is simply not going to happen - ask ExtendeD, who received almost zero over the years for Ndless... ExtendeD didn't even get a CX until Jim Bauwens sent him one of his calculators... I'm just about as responsible about the lack of donations as anybody, though unlike most, I did work on Ndless and related programs, such as nspire_emu.]

[EDIT2, around 5 p.m. CEST:
At least, you have motivated me for working on the libti*/tilp code base, which I hadn't done for a little while
I've just completed an examination of the commits which occurred in upstream TILP between 1.16 (the base for strip_tilp_nspire) and 1.17. A majority of them contains hunks relevant to strip_tilp_nspire...]

[EDIT3, around 7 p.m. CEST: I've started upgrading the strip_tilp_nspire code base from TILP II 1.16 to TILP II 1.17. I've ported nearly 40% of the relevant commits, among which is the Glade/gettext -> GTK+Builder/intltool conversion, whose porting was relatively painless after all
Most of the translations are missing (the strings from libti* were never imported in the first place...), but the code base otherwise continuously works for the purposes of interacting with a Nspire CX CAS.]

[EDIT4, around 8 p.m. CEST: pushed 3 commits squashing the relevant bits of 23 upstream commits to http://github.com/debrouxl/strip_tilp_nspire . That's a bit less than 50% of the upstream libti*/tilp commits (with Nspire-related bits or documentation bits) between 1.16 and 1.17.]

But I don't want to be only complaining, I'll presumably look at C++, as it's easier for me to understand the code by rewriting/copying and finding out why it doesn't work anymore But I don't want to promise anything, I'll have some work to do, so it might take a while.

During the next few days, I'll try to finish bringing the strip_tilp_nspire code base towards the code in TILP II 1.17 + associated libraries, as well as making strip_tilp_nspire somewhat less of a one-off hack.
For now, everything is fused into a single "tilpm" ("tilp merged") executable, which is no good - there should be a shared library ("libtinspire" ?) again, and a front-end ("tinlp" = "TI-Nspire Linking Program" ?).
I've chopped out the unused Intel hex handling code, but that's less than 400 lines (~1+%).

I definitely think we need some way to install something on not jailbroken calcs.

Functionality would be severely limited...

Quote from: Lionel Debroux on August 13, 2013, 04:22:08 am

Quote

I definitely think we need some way to install something on not jailbroken calcs.

Functionality would be severely limited...

Well, for non-jailbroken calcs, "installing" would mean to just transfer one or more files into a specific directory, most of the time it'd be /documents (and sometimes /mylib), and.. that's all, since there is no more handling on the calc side.
Looks pretty simple ? (Both with libti* and navnet)

And probably a database file for installed programs (updates, uninstall, etc).

Unsync between the database and the listed could be avoided by not using a database. A well-defined file naming would do I suppose, computer side software can easily discover what's on the calculator with directory listing.

Well, do we have an idea of how long it takes for navnet/libti to list the whole /documents folder (recursively....) ?
For a small amount of files, medium, and big ?

If it's fast enough, the idea would be good (but the user can't rename files)

Yeah right... >.<

So, a proper filenaming convention like :

UserDefinedOrDefaultName{1,40}_vMajor[.Minor[.Build]]{1,8}_ArchiveID{1,5}.pcs.tns

So, for example :  FormulaPro_v1.4.1_6034.pcs.tns

(Although idk about the usefulness of a .pcs extension for the final .tns file. Well, maybe to speed up the process of knowing it's been installed through the app store, in case, it's very useful ^^)

?

I'll have to say I guess it can become quite annoying in the long term to have all those largely-named files yeah

However, same question as a bit before (I'm calling Levak here ), can we hook up the renaming process, to update the database accordingly, then ?
(edit : for the files that are not in MyLib, since their names has not to change
Edit2 : and yes, thanks to levak which raised the valid point of saying that without a database, in fact, you can't track them with the naming conventions the lib files since they're hardcoded names))