Teensyduino 1.20 Release Candidate #5 Available

Status
Not open for further replies.
How about a check box to confirm that you read the message... then an 'OK' click is thwarted, and people are forced to read.

Sometimes the simple solutions are right there in front of you.
 
xxxajk said:
How about a check box to confirm that you read the message... then an 'OK' click is thwarted, and people are forced to read.
Click to expand...

Usually I'm opposed to this sort of GUI design.

However, I did briefly consider a checkbox for "yes, I posted complete source to reproduce my problem" on this forum, which would enable the button to post a new thread. But simple adding guidelines and the "forum rule" with red text seems to be working pretty well. (I recently spent a little time over on Arduino's official forum.... we have much better quality questions and most thread arrive at good answers much sooner).

But, back to the installer GUI.

I do like pawelsky's list of words.

1. SKIP
2. ADD
3. REMOVE
4. KEEP
5. UPDATE

I think these might work well, perhaps also with use of color, probably gray for SKIP and KEEP, red for REMOVE, maybe green for ADD and UPDATE. I'm imagining the "all" button will turn them all green (ADD the ones currently missing, UPDATE the ones already installed), and "none" would turn them all grey. To delete already-installed libs, I believe clicking on each individual one is probably reasonable.


Just to be absolutely clear, this conversation is about possibilities for a future installer. Maybe 1.21, but probably farther out. A big last-minute change is definitely not going to happen in 1.20, which I had intended to release today... but I'm investigating a mysterious issue when OctoWS2811 and Audio are used together in a specific way. I want to fully understand this and make sure it's not an obscure bug before a final release.
 
PaulStoffregen said:
I think these might work well, perhaps also with use of color, probably gray for SKIP and KEEP, red for REMOVE, maybe green for ADD and UPDATE. I'm imagining the "all" button will turn them all green (ADD the ones currently missing, UPDATE the ones already installed), and "none" would turn them all grey. To delete already-installed libs, I believe clicking on each individual one is probably reasonable.
Click to expand...

I was thinking about colors as well, and I agree with one exception - I would consider UPDATE red (i.e. needs user attention, and for the red ones warning message would be displayed).
 
PaulStoffregen said:
I believe the installer's default behavior has all the boxes unchecked, causing no libraries to be written.
Click to expand...

Yes, that's not the idea. The Idea is a check box that won't let you just click the OK button. OK would be disabled until the check box is ticked.
 
pawelsky said:
Because it can overwrite someone's local changes.

It can be green as well, as long as the warning popup is displayed before overwriting.
Click to expand...

How should the installer distinguish between overwriting user customizations vs simply updating an older version that doesn't have any user changes?

I want to avoid "false positives" that cause a strong warning to be shown in harmless situations.


xxxajk said:
Yes, that's not the idea. The Idea is a check box that won't let you just click the OK button. OK would be disabled until the check box is ticked.
Click to expand...

No, I'm not going to do that. I'm philosophically against this sort of GUI design, which I believe is hostile or at least antagonistic to end users. But I will admit, the idea is tempting...
 
I'm not in favor of complicating the installer GUI. Time spent doing installation is time not spent doing cool projects.

If you're worried about overwriting locally modified libraries, have the installer compute a checksum for each library and refuse to install over something not recognized as identical to the expected older version. This implies the installer has a list of checksums for all older versions of all libraries it installs. Maybe it's reasonable to only go back a few versions and leave the behavior for older versions as it currently is. With this policy, it is always possible to undo an installation and roll back to an older version.

The problem with asking the user if they want to do 1-5 above is that unless they're very clear about the state of all their local libraries and the updates, they're stuck guessing. If they're not very clear, then they're probably not well prepared to investigate and do better than guessing. So, they'll guess wrong and complain.

Let the small minority of users who locally modify libraries deal with the problems of version management.

It would be nice if the release notes were integrated into the installer so it was possible to go through each library and see right there what had changed.
 
Yes, I believe to make this work, some sort of comparison against known checksums will be needed, to detect when a library has been edited or changed by a user.

I'm reluctant to start managing revision history for so many libraries.

But perhaps if the installer were to write a checksum list, it could later use those checksums to see if the library has been edited. Presumably people would not bother to edit the checksums in a separate file. Of course, this doesn't do anything for the very first time Teensyduino is installed, where copies of the extra libraries might already be present.
 
I agree folks are unlikely to mess with checksum files in library directories, however, either way, managing the checksums would need to be automated. If it's automated, you're better off storing the checksums in a location you control, namely inside the install image.

If you're reluctant to manage revision histories (and as well you should be--not a high leverage feature), fearlessly keep the installer as is. No one will get burned twice. I'll shed a crocodile tear for anyone who complains that a software update updated libraries after they explicitly requested this.
 
Use SHA checksums, just like git does...

Oh, and I always install everything fresh personally. I must have at least 10 different Arduino and teensified Arduino installs :)
 
You seem to install the libraries in Program Files. Users should not touch files in that folder and if they do, too bad. If they want to modify a library it should be copied or moved to their Arduino folder in My Documents or where ever they choose.

I believe the only proper Windows like response for your installer is to delete all the libraries and install only the checked ones or at least offer the option to do that. I understand why that might not be your favorite choice, but I think it would be the only solution that fits the Windows paradigm.
 
I think Ira might have a good and simple solution. I would add a checkbox by default to any library that was already installed, and just go by the folder name to find matches.

Here's my use case: Some of the SmartMatrix examples require the prerelease FastLED 2.1. Teensyduino includes the stable FastLED 2.0. Some users already installed Teensyduino and checked the FastLED install, so for those users I have to tell them to navigate inside "Program Files\Arduino" or inside the Arduino.app on the mac (no idea for Linux), and delete the libraries\FastLED folder. I'd rather tell them to run the Teensyduino install again with FastLED unchecked, and install the FastLED 2.1 library using Arduino "Add Library".

If users install an alternate version of a library I expect they will either use the Arduino "Add Library" or put the folder in their sketchbook\libraries folder so it wouldn't interfere with what's inside the Arduino application folder.
 
PaulStoffregen said:
How should the installer distinguish between overwriting user customizations vs simply updating an older version that doesn't have any user changes?
Click to expand...

It doesn't, it displays the warning in both cases to give the end user a chance to decide.

If you want to avoid tons of warning popups you can display just one containing a list of libraries that will be removed/overwritten during the installation.

Calculating checksums would be nice, but I think we shall keep it simple.

Alternatively you can create a backup of removed/updated libraries somewhere during the installation.
 
Last edited:
Paul, I know lots of work has gone into this, and you can miss a thing or two, which is why we do testing.
I've noticed that we are missing SPI examples using the new transaction goodness.
Any chance of putting in some kind of simple examples for the new modes like interrupt driven?
 
The trouble with adding a transactional SPI example is that it either has to be hardware specific (and to run it you need the two specific devices connected) or it is generic (in which case you can examine and compile the code, but it doesn't do anything).

I did include a generic transactional SPI example when I rewrote the PJRC SPI page. However, that updated page has not been posted on PJRC yet.
 
That reminds me of one other small tid-bit with SPI, and possibly a few other libraries that have architecture dependencies.
SPI_HAS_TRANSACTION should not be defined if it does not match any of the architectures, and it should possibly do an #include-next <SPI.h>
I've actually ran into this as an issue with some of my own crazy code.

Also, if I recall correctly, if a user has an SPI library, doesn't that "trump" the one provided?
I haven't had a chance to test the theory yet, and just wondering if that is a correct assumption, but I will be needing to do that in the future.
 
xxxajk said:
I've noticed that we are missing SPI examples using the new transaction goodness.
Click to expand...

Do the Ethernet and SD libraries count? And ILI9341_t3?

Any chance of putting in some kind of simple examples for the new modes like interrupt driven?
Click to expand...

RadioHead and Audio (as of only a few hours ago... on github) are the only ones so far.

Yes, there should probably be examples added in File > Examples > SPI. Anyone want to write and contribute some?
 
Nantonos said:
The trouble with adding a transactional SPI example is that it either has to be hardware specific (and to run it you need the two specific devices connected) or it is generic (in which case you can examine and compile the code, but it doesn't do anything).

I did include a generic transactional SPI example when I rewrote the PJRC SPI page. However, that updated page has not been posted on PJRC yet.
Click to expand...

Not if you just connect MISO to MOSI as a loopback and just spew data and verify it. :p Yes it is "useless" as far as anything practical, with exception to testing your SPI port, but it does provide an example to draw on, and it should be way easy to whip one up fast.
 
Paul: Yes, I looked in there for some basic usage, which is fine for now, since I am just polling.
Do any of the other libraries use an SPI IRQ or DMA to transfer data?
I just glazed over them quickly, and didn't really notice anything like that.
 
Well, I had hoped to finalize 1.20 yesterday.... but it's looking like 1.20-rc6 is coming later today!

I added SPI.notUsingInterrupt(), which undoes the effect of SPI.usingInterrupt(), and put code into the audio lib to use it. I also did quite a bit more testing and debugging of stuff with the audio library. OctoWS2812 is converted to use DMAChannel.h and has several more examples. Lots of testing there revealed leftover debugging code in Audio that interfered.

Dealing with all this stuff is what makes the whole platform nice to use. But it also seems to make for perpetual release delays!
 
xxxajk said:
Do any of the other libraries use an SPI IRQ or DMA to transfer data?
Click to expand...

I believe Adafruit_CC3000 is the only other one at this moment. But that code is so horrible, I wouldn't recommend looking.

I intend to port many more, but after a 1.20 final release.
 
Status
Not open for further replies.
Back
Top