This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Vogtinator
Pages: 1 ... 47 48 [49] 50 51 ... 83
721
« on: August 13, 2013, 07:41:20 am »
But then the software needs to now where the files in a package are and how they're called.
This for every package could be slow, depends on how many packages exist.
722
« on: August 13, 2013, 07:16:41 am »
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).
723
« on: August 12, 2013, 07:00:22 pm »
At least, you have motivated me for working on the libti*/tilp code base, which I hadn't done for a little while Yay, I did it! 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. For the app store/pacspire: I definitely think we need some way to install something on not jailbroken calcs. The newer ones come shipped with boot2 > 3.1, which makes installing ndless without soldering skills and an rs232 converter impossible (yet).
724
« on: August 11, 2013, 06:53:43 pm »
Wouldn't have it made sense to split the nspire support into an entirely different lib? It doesn't share ANY code (except unneeded, like FileContent, which is for file group support and VirtualPacket) and it is very unlikely to be used by an application which supports both the nspire and the other TI calcs. And it seems I accidentially circumvented the assumptions that there's a single / in a valid calculator-side path by not using a slash in front of the path  I know it's slowly getting off-topic, but it doesn't fit anywhere else and the previous posts are important for context. If anyone wants to move it 
725
« on: August 11, 2013, 06:58:13 am »
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) Umm, it does work? File size and type are correct as well. TRYF(cmd_s_dir_enum_init(handle, "ndless/games"));
TRYF(cmd_r_dir_enum_init(handle));I overwrote folder_name with "ndless/games" in the library and tilp shows the files just fine
726
« on: August 10, 2013, 08:50:40 pm »
Lionel, you said libti* couldn't handle files in nested directorys, but that is simply wrong, because it works just fine The next thing I'm trying to do is making a simple JNI lib for libti* for java, just as proof-of-concept.
727
« on: August 10, 2013, 04:10:29 pm »
You can undo deleting files? Reminds me of DOS "undelete".
728
« on: August 10, 2013, 03:35:44 pm »
Isn't it easier to simply hook the remove() function?
(Not the function itself, the location it's pointing to)
729
« on: August 10, 2013, 03:05:50 pm »
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..
730
« on: August 10, 2013, 02:53:58 pm »
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?
731
« on: August 10, 2013, 01:39:13 pm »
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.
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)
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.
732
« on: August 10, 2013, 12:37:28 pm »
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.
It won't be too much work to get support for such apps in, too. I mean, it's just two things (hiding, linking) that will not be done for non-native programs. 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.
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?).
733
« on: August 10, 2013, 10:34:34 am »
There are far more than "a few dozen persons" who can install Ndless... But many school require OS > 3.1. The nspire is not a "gaming" platform, it's a calculator. OK, so you're thinking about moving more functionality on the computer side than I was thinking. That could be an option. Is libti* able to send and receive files without *.tns? At least "/documents/packspire/packages.txt" or whatever the database will be called should be hidden.
734
« on: August 10, 2013, 09:22:32 am »
Another question: Do we want to support calculators without ndless installed (newer models, or if the owner isn't allowed to)?
Can libticables send files to hidden folders? I'd be great to have the appstore recognize packages installed with pacspire and vice versa.
Or handle jailbroken calculators differently than "genuine" ones?
735
« on: August 10, 2013, 07:35:13 am »
What if we simply store the programs below /documents? Only the links to them would be visible.
Pages: 1 ... 47 48 [49] 50 51 ... 83
|
Show Posts