|
From: Benjamin M. <flo...@us...> - 2011-10-19 03:42:48
|
>> Sounds good. One other point regarding the user interface: should we >> display the "save" dialog before or after receiving variables? In the >> non-silent case, we have to finish receiving variables first, but in >> the silent case, we could, in theory, display the save dialog first. >> > > I've working a little bit on it. Now, getting vars is done before printing > the dialog even for silent case. OK. > If the getting vars function do not work correctly, the receive dialog > simply prints an empty list (so user must use refresh to get entries). Hmm, failing without an error message isn't good... > Another subtle point to consider is which file format to use. When >> transferring multiple variables, they can normally be stored in a >> "flat" group file (.??g). But if we are transferring applications in >> addition to variables, or if we have more than 64k total, we need to >> use a TIG file instead. Some users might prefer to use a TIG file in >> any case. >> > > As you prefer. > > I've added a feature wich allow to list ti82 and ti85 vars. > I think that's not really exactly how we had decided to do but it's > basically working. > Currently the user must prepare the calc himself to be in "send all" state. > I think it could be done automatically (using a kind of > prepare_for_link(emu) function) but for the moment I can't get it working > automatically. This makes some sense, but I don't really like the idea of blindly pressing a sequence of keys - not knowing what state the calculator is in to begin with - and hoping that somehow we'll end up in the right place when we're done. I know I did that in the test GUI, but only because at the time, I needed a quick way of sending files from the command line, after a cold reset - I didn't care to do anything fancier or more robust. > With this method, I get the var entries easily (even if the calc prints an > "error link" message after 4 or 5 seconds). Sounds like the EOT isn't being acknowledged for some reason? I don't remember how this is dealt with in ticalcs2. I'll check it out. > A this state, is it possible to only write the selected entry without > reusing "ticalcs_calc_recv_var_ns" (and preparing link)? > I would say : just extracting an entry from FileContent? Yes, you can do that. tifiles2 might have some convenience functions for "grouping" and "ungrouping" FileContent structures, I don't remember. Either way, it's not hard to rearrange them by hand. >> The VarEntry structure is also used within a FileContent, to store the >> variable data. >> > Yes I have studied a little bit libtifiles and tilp today. A FileContent > could even contains more than one entry (content->num_entries , > content->entries[0]). > > One thing I'm not sure : does a VarEntries contains all the data we need to > transfert it on the computer? > As said before, getting a FileContent containing all vars then extract only > one VarEntry and use tifiles_content_write_regular to write the destination > file could be a solution to do not ask the user to do some actions on the > calc link menu. > I'm don't know if I'm telling something stupid or not... I suppose it could be made to work. I'm still skeptical about the idea of pressing a long sequence of keys automatically, but maybe by peeking at the calculator state we could tell that it's actually at the home screen to begin with? Then, if we fast-forward through all the link operations, it should be quick enough to transfer all of the variables without a huge delay. It's a nice idea UI-wise, I'm just worried about the implementation. >> However, it can't be used to store Flash apps or memory backups. And >> we could use VarEntries to store TI-81 programs, but that's >> non-standard. Maybe we could define our own generic file content >> structure, and a set of GUI-independent functions for manipulating >> them. >> >> (The logic for reading and writing all of the various file formats is >> complicated enough that I think it would be worth keeping it separate >> from the GUI.) > > > As you want, tell me more about this possibility :) I haven't thought it out completely, but here goes. :) We should be able to handle at least the following file formats: - for the TI-81, PRG files - for other models, normal program/variable files (e.g., .82P), group files (.82G), and backup files (.82B) - for the TI-73 and 83+ family, Flash apps (.8XK) and OSes (.8XU) - TIG files We could have a "TilemFileContent" structure, that could contain either a FileContent, BackupContent, FlashContent, or TI81Program. Also a "TilemVarHeader" structure that describes a single variable (or application.) A generic "read file" function would parse an input file and return a linked list of TilemFileContents. A "write file" function would write such a list to a file. A "send variable" function would take a TilemFileContent and send it to the calculator. A "get directory" function would produce a list of TilemVarHeaders (from which you could extract the names, types, and sizes of each variable.) A "get variable" function would take a TilemVarHeader and produce a TilemFileContent. When called from the GUI, these would all be asynchronous, but we'd also want synchronous versions for command-line processing. > Yes you're right code is duplicated and not optimized ;) > And there's a lot of others problem in my code... As soon I have something > working correctly, I will do a refactoring to add error handling etc... Error handling - and more generally, returning results to the GUI asynchronously - does make things quite a bit more complicated. :) > Have you seen the new ti80 emulator by Randy Compton? That's great ;) Yes, I've just heard about it, but I haven't had the opportunity to try it. Pretty cool; I gather that he reverse-engineered the entire instruction set?! Benjamin |