Quote from: Streetwalker on August 09, 2013, 03:47:51 am

Quote from: Lionel Debroux on August 09, 2013, 03:29:48 am

An app store would indeed be nice, but who will do the work of setting it up, maintaining it in the long-term, and sifting through old programs for re-packaging them ?

Maybe Linux style repos ? This way devs maintain their stuff themselves and it's pretty easy to set up (you just need an HTTP server and there are plenty of free hosts).

Why not a simple Web UI for submitting and updating apps?

Great! If you want to, I could help

But if I click on tworld.pcs.tns again, it says 1.3.0 would be newer than my installed version 1.3.0, but in the log file it states otherwise xD

The installed version of tworld (1.3.0) is newer than the one you are trying to install (1.3.0). Continue?

checking if the package is newer than the installed version... no

The [great, in my option] idea of an Nspire App-Store has been in mind of several people for quite some time, yet nothing has been done on that path
It could be coupled with some remote control software to automatically extract/isntall/launch whatever. nRemote for example can do that quite easily with its "script" support.

Anyways, great work Compu, that will surely help people installing their programs. I think there should be (if not already present) a way to decide if the installation is done in a specified folder (for in-dev programs that still don't support to be in any folder or don't support their dependencies to be in random folders, or for programs that must be in startup) or in a folder that the user would choose (for programs that can be run from any folder and that the user would like to put in the Game folder for example).

Quote from: Vogtinator on August 09, 2013, 09:09:07 am

Why not a simple Web UI for submitting and updating apps?

That's what I was thinking of + a command-line client that downloads packages and sends them to the calc (I guess that would be possible with libti*?).

Quote from: Vogtinator on August 09, 2013, 09:09:07 am

Great! If you want to, I could help

Sure, why not

Quote from: adriweb on August 09, 2013, 09:27:37 am

The [great, in my option] idea of an Nspire App-Store has been in mind of several people for quite some time, yet nothing has been done on that path
It could be coupled with some remote control software to automatically extract/isntall/launch whatever. nRemote for example can do that quite easily with its "script" support.

Thanks, I will take a look at nRemote, but if it doesn't work on Linux as Vogtinator says, it probably won't be an option.

But doesn't nRemote use the mysterious NavNet.jar to interface with the Nspire windows driver?
That would make it completely useless to me, as I'm using Linux.

Quote from: Vogtinator on August 09, 2013, 09:30:18 am

But doesn't nRemote use the mysterious NavNet.jar to interface with the Nspire windows driver?
That would make it completely useless to me, as I'm using Linux.

Same here. libti* supports this functionality though as Lionel stated a few posts up.

One of the NavNet JARs (don't remember which one) contains the 3-byte key code definitions. Adriweb, remind us which one

BTW, libticalcs contained support for Nspire remote control before nRemote was released, though I used a beta version of nRemote in a Windows VM to debug and fix my implementation of the feature through sniffing USB packets.

You don't need the 3-Byte key code definition. You can just send ascii, as shown in my code

Quote from: Vogtinator on August 09, 2013, 09:30:18 am

But doesn't nRemote use the mysterious NavNet.jar to interface with the Nspire windows driver?
That would make it completely useless to me, as I'm using Linux.

Quote from: Streetwalker on August 09, 2013, 09:32:53 am

Quote from: Vogtinator on August 09, 2013, 09:30:18 am

But doesn't nRemote use the mysterious NavNet.jar to interface with the Nspire windows driver?
That would make it completely useless to me, as I'm using Linux.

Same here. libti* supports this functionality though as Lionel stated a few posts up.

Yes sure, but at least it will function directly and more quickly (no install time, I mean) for those on windows (and mac) with TINC[L]S installed, with no need of filter driver and such because of that crappy windows roadblock...
For Linux obviously libti* is the choice as it's easy to use there (and, well, is the only one).
Remember the main point here, whatever the choice : it has to be extremely simple for the user (no installation would be great)

And, also, let's not forget that if such App-Store project comes to life, it'll have to be for all .tns of course (there are tons of TI activities that could use this, but also Lua scripts, and duh, the ndless programs (especially those with external resources), so if it ever gets popular (who knows ), the majority of users will be PC, then Mac, then Linux (and the order of file type will be TI BASIC things, then the Lua stuff, then the ndless stuff...)

Also, it'd be good to have such a program linked to the major community repos (ticalc, omni, tiplanet, cemetech...)

Quote

So is tilp the only reliable source for documentation?

The documentation of libti* was already incomplete / partially outdated when I became the maintainer, and (with the help of contributors) I have focused more on the code (which needs bugfixes, feature expansion and hardening) than on the documentation (all the more libti* have relatively few users, and documentation of the API has pretty little user-visible effect, eh ?), so yeah, the source code of the libraries and testcases is your best bet. You're coders as well, after all

Have a look at libticalcs (calc_xx -> calc_nsp -> nsp_cmd -> nsp_vpkt -> nsp_rpkt) and the testcase, libticables (link_xxx -> link_usb) and the testcase, TILP (especially tilp_calcs.c), titools. The testcases and titools are about as bare-bones as you can get.

One of the NavNet JARs (don't remember which one) contains the 3-byte key code definitions. Adriweb, remind us which one

BTW, libticalcs contained support for Nspire remote control before nRemote was released, though I used a beta version of nRemote in a Windows VM to debug and fix my implementation of the feature through sniffing USB packets.

Quote

And I wonder why there are four libti* libraries.

Actually, for the combination of TI-Z80, TI-68k and Nspire, four libraries is not enough
There's a clear need for a fifth library on top of the four current ones, so as to consolidate some code currently duplicated, with variations, across clients (TILP, TIEmu, TilEm, titools). I started creating it locally, though it contains pretty little.
The whole libti* framework looks complex and seems to have deep nesting of functions, but after a while maintaining the code base, I realized that for the purposes of presenting a single, mildly abstracted API to clients (instead of at least three sets of APIs with significant overlap, due to TI-Z80/TI-68k/Nspire, DBUS/DUSB/NSP, and some commonalities between TI-Z80 and TI-68k), it's not easy to do simpler. Just follow the call chains I outlined above - there's a use for each file, in the complete framework

Quote

In my opinion it would have made more sense to combine them into one libticalcs.

It's equally clear that for the narrower purposes of interacting with the sole Nspire series, four libraries are far too much, and you're completely right about a single library making sense:
* libticonv deals with character conversion, which is necessary on TI-Z80 and TI-68k models, but the Nspire uses Unicode (and conversions can be handled more directly by other frameworks);
* libtifiles deals with file types... but the Nspire has very few of them, unlike the TI-Z80 and TI-68k series;

* libticables deals with multiple cables... most of which don't work on modern computers due to lack of the physical interfaces, and the Nspire uses a single cable type;
* libticalcs deals with the raw DBUS, DUSB and NSP protocols and transport protocols built on top of them.

On my Github, you'll find a one-off experiment of a few hours, where I fused libticonv, libtifiles, libticables, libticalcs and tilp into a single code base (I probably should have let libti* on the one side and tilp on the other side, but oh well), shaved most code related to TI-Z80 and TI-68k calculators. Doing so slashed the size of the code base by more than half (~78K RLOC -> <35K RLOC). I didn't bother thoroughly purging the code base, there remain some bits directly aimed at TI-Z80 or TI-68k series and some APIs which are not necessary for dealing with the Nspire series.
I didn't merge developments from mainline since I created that one-off experiment. With several months of full-time paid work, it would be possible to make a fresh API, simplified from the current one while keeping the good bits, tailored to Nspire interaction, replacing Glib with C++11/STL, making a whole new Qt UI on top of it (GTK+ is falling out of favor), making a solid up-to-date documentation, etc... but who can afford that kind of luxury, all the more it's for the benefit of relatively few users ? At least, I cannot

Quote

Even with WINE it doesn't.

USB support in Wine is in the "TODO" group, anyway.

Quote

Remember the main point here, whatever the choice : it has to be extremely simple for the user (no installation would be great)

Well, the "no installation" part is not going to happen, especially on Windows, due to the "everything USB needs a driver, which in turns requires admin privileges for installing" behaviour. On the day the two main FLOSS Web browsers (Firefox and Chrome) start providing an interface to USB peripherals on the host (notwithstanding the severe security problems), maybe...

Vogtinator:
get_event() will be helpful. (http://hackspire.unsads.com/wiki/index.php/Libndls#Keyboard )
It receives keystrokes AND you can receive files while waiting for an event to happen. Pretty awesome and it should solve many problems

Test attached. It waits for an event and prints the event data (through serial). If you send a file while waiting, it will be received successfully. (Press ESC to close)