The original filter would only populate the contribution list with perfect matches.
Previously, if a core was installed but didn't match the search it wouldn't appear in the results (due to a board being added or the description changed);
the user could then install (not upgrade) the core, triggering a confusing situation.
When moving to arduino-cli backend we should take care of this issue, at least visually (the cli logic would correctly update/downgrade the core)
Fixes#11416
The patch on MenuScroller.java is needed to avoid a clash between custom menus with the same label.
This behaviour artificially increases the amount of objects that the scroller will calculate.
Eg. if two boards share the same custom menu, that menu will contain the properties for both the boards (since it's parsed twice).
if 'showingHint' == true, then many potentially expensive String operations are being executed on an empty string. This change wraps these operations in an if block which will only run them when needed.
This can happen happen in some unlikely cases (such as when renaming a
platform in a way that breaks the "select a board when none is selected
logic").
Even though a board should always be selected, code should still handle
no selected board gracefully (rather than raising a NullPointerException
like this used to do).
See #10887 for the underlying issue that caused no board to be selected.
A dedicated repository for the examples will make it easier for them to be built in to arbitrary development tools. It will make it easier to use them for compilation testing of boards platforms. It provides a dedicated location for issue reports and pull requests that are specific to the examples. It continues the work done by moving the AVR and SAM boards platforms and built-in libraries towards making the arduino/Arduino repository solely a place to host the GUI code of the Arduino IDE.
Some platforms may not define directly 'build.core' because it may be defined
through a custom menu.
For example, the arduboy platform has in the boards.txt:
[...]
menu.core=Core
[...]
# core #
arduboy-homemade.menu.core.arduboy-core=Arduboy optimized core
arduboy-homemade.menu.core.arduboy-core.build.core=arduboy
arduboy-homemade.menu.core.arduino-core=Standard Arduino core
arduboy-homemade.menu.core.arduino-core.build.core=arduino:arduino
[...]
the build.core is determined only after applying the submenu options.
Previously changing "Category" would filter libraries by the selected
category but without applying the "Type" previously selected.
For instance selecting Type="Installed" and Category="Communication"
will display *all* the libraries belonging to "communication" instead of
the installed only.
This commit fix this behavior.
The filters content is unlikely to change, so just prevent it from live
updating it because it has some side effects:
- it's slow
- it changes the selection back to the default and it's very tricky to
make it re-select the previous selection.
Fixes#10439
Previously rescanLibraries() was automatically called internally in
setLibrariesFolder(). This lead to double calls to rescanLibraries()
when setLibrariesFolder() was used in combination with an explicit
call to rescanLibraries().
This commit adds a new method setLibrariesFoldersAndRescan(..) and
removes the internal call to rescanLibraries() from setLibrariesFolder().
The existing setLibrariesFolder()+rescanLibraries() combos have been
replaced with setLibrariesFoldersAndRescan().
Fix#10228
Previously, any CR without NL was treated just like a NL. For tools that
used single CRs to update a progress bar (such as dfu-util), this would
end up printing the subsequent versions of the progress bar below each
other, instead of updating a single line as intended. Additionally,
since ConsoleOutputStream only scrolled the view on \n, these updates
would end up outside of the main view, making the upload progress quite
unclear.
This commit makes EditorConsole support lone CRs by resetting the insert
position to the start of the current line, so subsequent writes
overwrite existing content. If subsequent lines are shorter than an
earlier line, only part of the earlier line will be overwritten (this
mimics what terminal emulators do).
Previously, the redirection would be triggered in the EditorConsole
constructor. However, this was problematic for unittests, which do not
need this redirection.
Since the redirection really is not useful intul there is a current
EditorConsole anyway, it can just be delayed a bit until
setCurrentEditorConsole is called.
This prevents the Arduino instance in tests from checking for updates. I
have not seen any problems resulting from this, but disabling network
requests is generally a good idea in tests (to prevent external factors
from influencing the test results).
In addition to update checks, there is also the CloudBoardResolver that
could do network requests, but there does not seem to be a preference
for disabling that.
This would match the "Close" dialog, by looking for any JDialog on
screen. However, in some cases, there could be a second dialog (I have
seen a "Install this package to use your xxx board" popup because I
happened to have an Arduino Zero connected, presumably an "Updates are
available" popup could cause this as well).
By matching not just the type of the dialog, but also the title, only
one dialog is matched and the testcase runs more reliably.
The tests would initialize Base, PreferencesData with default settings
and/or run the arduino executable, without specifying any settings to
use. In practice, this would read settings from e.g. `~/.arduino15`,
load libraries from the user's sketchbook, etc.
This is not a good idea, since this can be influence the test. For
example, the presence of invalid libraries would cause extra output to
be generated, which breaks the `--version` test. Or having the "Use
external editor" setting set would break tests that try to edit a
sketch.
This commit fixes this. The core of this commit is in
`AbstractWithPreferencesTest`, which sets up a clean settings dir (to
replace `~/.arduino15`) with a sketchbook and `preferences.txt` file
inside before every test (and removes it again after the test.
For some tests, this is enough, but some tests create an instance of
`Base`, which again initializes everything, including preferences, from
the default location. To prevent that, `--preferences-file` is passed to
the `Base` constructor, loading the previously set up preferences. This
is handled by the new `AbstractWithPreferencesTest.createBase()` method.
Furthermore, CommandLineTest calls the actual Arduino executable, which
has the same problem. This is fixed by passing the same
`--preferences-file` option on the commandline (generated by
`AbstractWithPreferencesTest.getBaseArgs()`).
This should prevent all tests from reading the the default settings
files, fixing some tests on my system and even speeding up the tests
somewhat (due less libraries and cores to load, probably).
Previously, this used the DeleteFilesOnShutdown class and a shutdown
hook, which would delete the files only after shutdown. However, the
shutdown handler would be re-added for every testcase, potentially
leading to a lot of threads trying to delete the same files.
This uses an alternative: Just keep a list of files to delete inside the
testcase and use an @After handler to delete the files directly after
each usecase.
Both classes contained some duplicate code, so unify that by making one
a subclass of the other. This also prepares for further additions that
should be inherited by both.
In one test, `--get-pref` is passed on the commandline to prevent
starting the full GUI. When ran without arguments, `--get-pref` causes
*all* preferences to be printed. Using `--version` achieves the same (no
GUI is started) with just a single line of output.
This abstracts some the common code (running Arduino, copying
output, waiting for completion, checking result) from all testcases into
a single method. This simplifies each testcase, but also prepares for
adding more common arguments to all runs in a subsequent commit.
