Althogh Java is absolute crap to develop a graphical application in, it might be the best option.
Using JNI to interface Qt with NavNet might be too complex.

Yeah, I had Java that in mind because it's at the same time directly cross-platform (no need for external QT and such) and could be linked to both libti* (JNI I guess, loading .dlls or .so or .dylib) and navnet (itself is using JNI but that's the deep navnet part which we won't use, only the high-level stuff are necessary. You can pretty much see what here.)
But I indeed know it's not the preferred language for many of us here (I myself didn't write much Java except nRemote ^^)

*Cough* Just thought I would mention that TILP would not be usable for me (and I'm sure) other windows users. I have never successfully gotten it to run properly on this PC (running windows 7). In fact, the last time I tried to install it (a few months ago) it rendered both TI connect and itself unusable. This was following the instructions to a T.

Same here (the filter driver thing is what blocked me, all the rest was fine) And of course, it went flawlessly on Ubuntu... Ah, Micro$oft....

Quote

Quote from: hoffa on August 10, 2013, 01:41:36 pm

And, the two things above are the exact same thing, just with a different layout. We would need a native client, which also handles transferring the files (libticalcs + Qt?).

I'd very much like to insist that to get as many people attracted to this project as possible, something without any external install would be better, and thus it's why I'd be thinking of a Java program which :
- if running on Linux, uses libti*
- if Mac or Windows, detect if TINC[L]S is installed, then use navnet, otherwise fallback on libti* if installed.
On both cases, if no transfer "driver" is detected (unlikely...), well, tell the user to get either one. (But the rest of the program could still work)

You really think that would make people want to use it? Most people pretty much never hook up their calculator to their computer, it's hacky, requires to download tools and has minimal benefits (compared to the work required to implement it nicely). [rant]Plus, who uses a joke like Java anyway?[/rant]

I used to send my buddies games just by cable during classes (oh boy the hours spent during mathematics class playing Pokemon), and that's up to where the majority of people bother to go just to put some stuff on a calculator (and with the package manager at the very most two files would be required to be sent, one if it was integrated into ndless)

I believe this is way more true for z80 platforms than Nspires (and 68k at a lesser extent, though). That's probably because students would get a z80 "by default" whereas a 68k or an Nspire would actually be a choice.

And that is a good point for making the software (especially the computer one, since the calc one, once installed, means the user trusts the whole thing anyway) as intuitive/portable/easy-to-use as possible. Which is again why feature detection on Mac/Windows is important : if the user has TINC[L]S installed, the program needs to install nothing : it justs sits there (no install needed to launch a .jar or an exe/app where it's embedded into), using what's already available and not installing complementary libs (which is, also, not possible all the time, especially for a driver, if the user is not an administrator).

PS : I was/am also the calc-guy in class

Quote from: adriweb on August 10, 2013, 11:21:03 am

You don't seem to have read : [...] nor [...]
But I have to say it's difficult to keep up for new posts in this topic while writing

Yeah, I skipped an entire page ... damn me.
Then, yes, for MyLib Basic/Lua programs, there is an interest, but how many are they exept Make3D demo and FormulaPro ?

Some programs of critor, too
And some "big" basic (and rarer, Lua, like your Make3d, yes) projects by other community members or even TI sometimes.

On another topic, talking about web hosting, what should differ from the existing if there is no PC-side client ?
I mean what will be the differences between TI-Planet hosting and the pretty concept posted earlier ?

Hmm.. the computer side is to have a unified repo-browsing and transferring experience that also makes the whole package-with-metadata thing easier (not made by hand by the user).
Concerning TI-Planet, since we'd already talked about having some API to get archive-info and whatnot (-in JSON, I believe, but that's not much the point), this would be the chance to get it done for a good/well-defined purpose.

largely more of a competitor to the Nspire CX CAS than the Prizm, I'd say.

Right, but the thing is that we have to support these kinds of documents since it's exactly the purpose of pacspire : easier multi-file projects installation

But as said, before, whatever the type, lua, basic, or ndless, it should not have to matter to the program (both computer and calc side)

Quote

Do we want to support calculators without ndless installed (newer models, or if the owner isn't allowed to)?

I'm not sure how could we support calculators without Ndless installed, when neither BASIC, nor Lua, can read and write files ?
What's more, in general, on principle grounds, we don't need or want to support the views of the manufacturer and school system. Most programs which could be installed through a package managers are games, because it's easier to make games than integrate with the OS.

Reasoning like this, you're simply restraining the target of the whole project to a few dozens people... which is clearly not the goal here.
And we are talking of generalizing the whole thing so that it can be used for any document, we wouldn't even "need" to know what type it is (of course, it's preferrable to do so in order to let the user know the maximum amount of info/metadata, it's always better). On the computer side, that is. On the calc side, of course, a package manager for just a single file may be overkill, but .. so what ?

Oh, BTW, you're wrong when saying "neither BASIC, nor Lua, can read and write files" : there are (and not just a handful) Lua and Basic projects that come with multiple files that have to be put inside of MyLib, to function, so they are reading/writing to external things, just not very freely.

I think we should indeed handle both cases :
- if the calc is not ndlessed, warn the user that the files won't be transfered outside of /documents, and that, of course, only Basic + Lua based .tns will work, unless they install Ndless (give a link and/or automate the installation if the user accepts to install it).
- if ndlessed, then, files will be transfered within /documents temporarily and then handled by the calc program to be moved somewhere else with a directly-user-accessible link created.

Some parameters could also be the default location of the transferred files, default behaviour for creating links, etc.

I'd be great to have the appstore recognize packages installed with pacspire and vice versa.

Approchaing some sort of a "syncing" feature, then, at the same time With a list.txt.tns within /documents that would be retrieved and parsed to see what's installed, the version, etc.

Quote from: adriweb on August 09, 2013, 11:22:44 am

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)

I think the requirement to have tilp installed is as easy for the average windows user as having the TI software.

With the big advantage of not having a 42th abstraction over the real communication.

Tilp itself isn't the problem, in fact, it's the filter driver for windows.... The number of people willing to install new software (especially drivers, in fact, with some manual configuration...) for this would be very low...
The reason why I proposed nRemote is because it works "directly" as long as you have TINC[L]S (and well, it's Java, so at least it's mac+windows directly, too). But then, no Linux indeed. To be good, the backend thing about communication should be separate, so that on Mac and Windows, users could use the nRemote layer (well, the java thing, that is, not the whole nRemote obviously), and on Linux, Tilp.

Quote

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...)

For a real package manager (like pacspire  ) every file is just a file, nothing special (except the metadata, of course).

Yep, good enough

Quote

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

Oh, that wouldn't be a good idea. I prefer having a single repo. Fetching packages and metadata would get horribly slow and what is with different version (but same version number!) of the same app in two repos?

Yeah, a single repo is less of a maintenance problem.

That's perfectly true.... but what repo is going to be used ?
ticalc.org and tiplanet.org are the two websites with most nspire-related files (I dont know which has more, honestly, but I know tiplanet has a lot ...)
We (tiplanet) probably wouldn't have a problem making some php layer/web-service ( / API) to get the correct files in a wanted format over our archives system as it is right now, IDK about ticalc.org

Having a user-exposed file to edit repos and rules to get files from it (if not "standard" from the software POV, or something, IDK), would be cool.

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

Yes, but in case you want to actually send nspire-related keystrokes