A Shopping Bag With a Calculator On it, a mashup of different calculator store logos, the TI logo On a shopping bag.

That's a nice idea. Just needed some inspiration. Thanks!

Now I had this idea just now. What if the desktop application uses an HTML file to send files? Might potentially switch back to a desktop application.

I cannot figure out a way to send files! It would be too tedious to recreate the entire application online, and my earlier approach also does not work. I'm thinking about really canceling development if you can only download files.

some concept are of what the logo could look like https://ibb.co/WWY8QW26

If You Go Back to the Desktop Application, Yo uCould Just Have a Transfer Files Section that Embeds the ticalc.link website as that section.

Yeah, it could work, but then the user has to manually find the downloaded files and send them. I also planned on showing a list of connected devices, which won't be possible if I go this way.

Bleh. This sounds useful, but I don't think I'll have any reason to use it. Windows-only is a major turnoff.

I'm aware of more OS-independent ways that this could be done, particularly in relation to requiring TI Connect and using WinForms. I don't think I'll act on the idea yet, as it seems rude to try to one-up your project as soon as you start working on it, but if ever you need porting help, I should be around.

Please don't fret! I'll try to make this available on Mac and Linux too.

Killer. I wish you good luck on this.

You could develop the application in a compiled language like C(++) or Rust and then use Emscripten and/or Web Assembly to make the software run natively on the web. There are additional considerations to be made when you are choosing the web as a compile target, but it doesn't end up being restrictive in most cases. This is the reason you can run old versions of Minecraft, the original PS1 version of wipE'out'', and the entirety of Valve's GoldSrc game engine in your browser without having to install anything (except for the obvious things). I'm fairly certain taking advantage of WASM to port desktop applications to the web doesn't inherently require the use of compiled languages but using languages like the one I listed will give you much more control over what you're making and depending on what you're doing it could be the difference between a web app that barely works and a web app that works perfectly fine and is, for all intents and purposes, identical to the actual executable software.

Multiple technical demonstrations of libraries run on the web to demonstrate their ability to run effectively inside of browsers. See the website of egui, a Rust GUI library for an example.

At any rate, I would suggest trying to either take this approach if browser compatibility is desired; fall back on compiled languages in general if you want greater speed, control, and less API language binding headaches at the expense of lesser cross-system compatibility; or use an interpreted language or one that is more operating system/technology-agnostic like Ruby or Python. All of these languages are perfectly capable of creating fast and user friendly GUI (and non-GUI) applications for modern(-ish) systems and it's largely just a matter of what specific approach you want to take with the development of this tool combined with what your personal preferences and specialties are. All of this typically goes without saying, of course, but I thought I'd explain it anyway.

I would mildly advise against using languages like C# and Java as those require .NET and the JVM respectively. Everyone has the JVM these days coz of Minecraft but plenty of computer users, especially those not on Windows -- myself included -- don't have .NET installed and, in my case, can't be bothered to obtain it. It's an inhibitive initial step to running software that should ordinarily be relatively quick and painless to get working.

Also, I'm not entirely sure of this, but I believe a FOSS alternative to the TI Connect API exists. I'm sure it's been name-dropped multiple times here and in the IRC/SAX/Discord. I don't remember the specifics, but try looking into libticalc(? if my memory serves me correctly) and the Linux Programmer Group.

I'm thinking about coming back to this sometime soon, but I only know C#, Python, Java(script).

It is probably better to use a desktop application, and nowadays everyone has the JVM because of games like Minecraft, so I could recreate the app using Java, and you could just install JVM for your OS to use this app. Java is already cross platform!

Sorry for my long absence from this project; school's getting tighter.

I'm really doing this.

Okay, I just found a repo that can work for calculator communication: https://github.com/hypothermic/ticomm

Then again, I could use Python's TkInter because it also works on Mac.

EDIT: It's actually easier to manipulate calculator files in Python then I thought, so I'm sticking with Python.

Okay, so I reimplemented the file-searching algorithm in Python, but it freezes the application for a few seconds:

This is the searching method:

This looks like it's doing a lot of extra work and manages to be accidentally quadratic several times over.

I'd go about it like this:

Code:


Your check for known directories seems particularly expensive, because you're searching for a substring match (childDir[0] in x) for every item in your list box for every directory that gets visited. I've avoided that by pruning the search to simply avoid searching any directory that calculator files have already been found in, although checking for a match at the beginning of each string only (using str.startswith rather than in) would also help.

Okay, I updated the searching algorithm (thanks @Tari).

So this method does not use recursion. Instead, the program asks where you store your calculator files, and of that directory, it only searches first-level subdirectories, and lists the names of the ones that include calculator files.

Currently the program has a few readability issues with README files due to using:
Code:

For example, this is an original README file:

And shown in the program:

EDIT: There's also some invisible character issues, like this is another original README file:

And shown in the program:

Looks like you're bumping into things using varying text encoding, since your first example looks like UTF-8 interpreted as CP-1252 ('\u2014'.encode('utf-8').decode('windows-1252') to incorrectly interpret a UTF-8 em-dash yields that repeating pattern) and the second looks like UTF-16 also interpreted as CP-1252 ('T'.encode('utf-16').decode('windows-1252') gives you a byte order mark at the beginning then alternating null characters throughout).

A very simple heuristic you could use would be to assume UTF-8 unless there's a UTF-16 byte order mark at the beginning of the file and then use UTF-16. That would correctly handle both of the examples you've given and plain ASCII, but not any less common encodings. More robust would be to automatically guess the correct encoding using a library such as chardet.