Hi etotheipi,
I am afraid that the threading branch does not work well on Mac OS X. The file save dialogs are unresponsive, you can write a file name, but no other widgets react, and pressing return does not result in the file being saved. This essentially renders offline mode useless, as I cannot save the unsigned transactions.
Suspecting an update of a library or something, I reverted to the master branch and recompiled, and then it works as it always did (but I immediately miss the multithreading stuff).
I actually do suspect some kind of race conditions, for even in the master branch the save window behaves slightly inconsistently. Sometimes the file name is prefilled with a file name for the unsigned transition, sometimes it is not, apparently randomly. Is it possible that the save window is somehow popped up before it is 100% initialized?
All this mess leads me to an unrelated question regarding offline transactions. I now created a number of unsigned transactions that never got saved. Will Armory remember these and by trying to avoid creating double spends prevent me from spending some of my funds. If not, what if I create two or more offline transactions and wait signing them to later, will I then risk that they contain double spends when I transmit them?
picobit,
That is unfortunate about the save-file dialogs. I'm really not sure how I can do anything about that, since the chunk of code that runs those dialogs is entirely out of my control. Perhaps it is a Qt library upgrade on OSX? What version of OSX? @RedEmerald: do you see this too? I am not near an OSX machine or VM, so I can't really do anything at the moment. I will examine the code around those calls and see if I can find anything that looks suspicious. But I doubt it -- those save dialogs are 100% part of the Qt library (I'll check to make sure I'm not doing something stupid before I invoke them).
The question about offline transactions is a good one. The answer is: nothing is saved. You could go either way with the design, but I think they are both annoying, and actually putting in the work to save off the maybe-used-coins info might get the user into more of a mess than the way I did it. So the answer is that Armory does not remember anything at all about unsigned transactions it saves. Thus, if you create two consecutive ones without broadcasting the first, it is likely to create an invalid second transaction. One solution is to make a single, multi-output transaction...
The converse is not only more work, but could put the user into states of unusability. If they create an offline tx and then decide not to ever send it, then Armory would treat those coins as "locked," yet the user would believe they should still have access to the coins. Maybe they were just messing around with the interface to see if things would work, and then canceled out when it told them to take it to the offline computer. Their balance would be artificially low, and they'd have to do something to unlock the coins. I could see that being confusing. (I could probably find a way to make the interface accommodate both, but it won't be high on priority list, right now).
The way it's done right now: if the user takes two transactions over and only one is valid, then one will go through, the second one won't, and then they'll be annoyed, but they'll try the second one again... which will now go through. It was a bit extra work, but it gets done.
