Commit 6d5597b070 introduced a guard against multiple concurrent operations.
This guard also avoid any real serial monitor "open" during the compile+upload phase, but it didn't handle keyboard shortcuts.
Fixes https://github.com/arduino/Arduino/issues/6015
When the serial monitor window is focused again (not reopened but put
in background and selected again) the text input field is now
automatically focused.
Fix#5810
The properties:
System.setProperty("awt.useSystemAAFontSettings", "on");
System.setProperty("swing.aatext", "true");
actually works on Linux (where the hint helps X11 to enable antialiased
rendering) but makes things worse on Windows where the outcome is exactly
the opposite (anti-alias is disabled).
Previously those settings had no effect because they were executed
*after* the initialization of the graphics. This is no more true
after the merge of #5578, that moved the graphics initialization
after commmand line parsing and consequently revealed the weird
behaviour on windows.
Fix#5750
Fixes#5401
The bug was introduced by 982d4f3f, when DiscourseFormat(Editor, bool html) declarations were swapped. The contextual/right click menu in EditorTab already behaves correctly.
Previously it was used to prevent the Editor from being displayed
when running in command-line mode. Now the Editor is not created at
all, so this parameter is useless.
This is also confirmed by the remaining calls to `handleOpen` that
all have the parameter set to `true`.
Move the initialization of Editor into the GUI section of the big
if-then-elseif chain. This actually breaks cases for Verify and
Upload that uses Editor to access core functions.
This will be fixed in next commits.
This commit makes this changes:
- SplashScreenHelper is now local in Base constructor
- if SplashScreenHelper is instantiated with a null SplashScreen
instance then it outputs progress in console and avoid to make
calls to Swing toolkit
- The parsing of command line arguments is anticipated so we can
determine if we are in command line or GUI mode early and setup
objects that produces output to not use graphics toolkits.
- In this case the SplashScreenHelper is initialized with a real
splashscreen only if we are in GUI mode
Previously it was selected always the last tab because the action
sequence was:
- create the new tab (in the last position)
- select the new tab index (last)
- sort the tabs (the new tab is now in the middle but the selected
is always the last)
instead the correct action sequence is
- create the new tab (in the last position)
- sort the tabs (now the new tab is in the middle)
- select the new tab index (now the correct index is selected)
The snippet:
boolean wrapNeeded = false;
if (wrap && nextIndex == -1) {
// if wrapping, a second chance is ok, start from the end
wrapNeeded = true;
}
Can be moved inside the `if (nextIndex == -1)` that follows, this way:
if (nextIndex == -1) {
boolean wrapNeeded = false;
if (wrap) {
// if wrapping, a second chance is ok, start from the end
wrapNeeded = true;
}
[...CUT...]
if (wrapNeeded) {
nextIndex = backwards ? text.lastIndexOf(search) : text.indexOf(search, 0);
}
}
but since `wrapNeeded` is used only at the very end of the `if` statement
we can move it forward:
if (nextIndex == -1) {
[...CUT...]
boolean wrapNeeded = false;
if (wrap) {
// if wrapping, a second chance is ok, start from the end
wrapNeeded = true;
}
if (wrapNeeded) {
nextIndex = backwards ? text.lastIndexOf(search) : text.indexOf(search, 0);
}
}
and finally simplify it by removing `wrapNeeded` altogether:
if (nextIndex == -1) {
[...CUT...]
if (wrap) {
nextIndex = backwards ? text.lastIndexOf(search) : text.indexOf(search, 0);
}
}
The snippet:
boolean wrapNeeded = false;
if (wrap && nextIndex == -1) {
// if wrapping, a second chance is ok, start from the end
wrapNeeded = true;
}
is present on both sides of the `if` statement so it can be factored out.
From: `Examples from Built-in Libraries`
To: `Examples for any board`
From: `Examples from Arduino AVR Boards Libraries` (selected platform)
To: `Examples for Arduino/Genuino Micro` (selected board)
From: `Examples from Arduino AVR Boards Libraries` (referenced platform)
To: `Examples for Arduino AVR Boards` (referenced platform)
When searching through all tabs, the order was accidentally reversed.
This was broken by commit d2bac86 (Remove tab switching logic from
Sketch).
This also fixes a problem where "replace all" would only work on the
first and last tab (since it would search backwards from the first tab
to the last tab and then conclude it was done).
This fixes a part of #5380.
Comparing a File object automatically takes care of filesystem case
sensitivity, whereas strings do not, so this makes the comparison
slightly more reliable.
Previously, everywhere where it was needed, the path was requested from
BaseNoGui. Because the path is based on a hash of the sketch filename,
every caller would get the same path for the same sketch.
However, it makes more sense to store the path used for a given sketch
inside the Sketch object. This prevents having to pass around or
regenerate the build path everywhere, and no longer requires the build
path to be deterministic (though it still is in this commit).
This allows removing some methods and constructors of which two versions
were available - one with a build path argument and one without.
Previously, callers of `SketchFile.delete()` would also call
`Sketch.removeFile()`, but letting SketchFile handle this is more
robust.
This is possible now that SketchFile keeps a reference to Sketch and
makes updating the Sketch file list less fragile.
Eventually this might be further decoupled by letting SketchFile
broadcast a "deleted" event instead.
This isn't much code, but it makes deletion more consistent with
renaming and saving with the SketchController handling the UI part and
Sketch actually doing the delete.
Now that SketchFile keeps a reference to its Sketch,
`SketchFile.renameTo()` can call `Sketch.checkNewFilename()`, so there
is no need for the renaming itself to go through Sketch.
This changes the parameter for `SketchFile.renameTo()` from File to
String, to enforce that only the filename is changed, not the directory
name.
These methods shouldn't really be in Base (or BaseNoGui, which did the
actual work), especially since there is already a
`FileUtils.recursiveDelete()` which just does the same thing. This
commit removes the code from Base and BaseNoGui and instead uses the
method from FileUtils.
There is one difference between these methods: the Base methods did not
delete files if the "compiler.save_build_files" preference was set.
However, the Base methods were only used when deleting a sketch, or
deleting an existing folder before overwriting it on save as, so this
preference didn't actually do what it was supposed to anyway, so
dropping it shouldn't be a problem.
This commits replaces a significant part of the code handling these
features. A lot of responsibilities are moved from SketchController to
Sketch, though the code involved is rewritten mostly.
Most of the handling now happens inside Sketch, including various checks
against the new filename. Basically SketchController processes the user
input to decide what needs to be done, and Sketch checks if it can be
done and does it.
If problems occur, an IOException is thrown, using a translated error
message that is shown by SketchController as-is. This might not be the
best way to transfer error messages (regular IOExceptions might contain
less-friendly messages), so this might need further improvement later.
In addition to moving around code and responsibilities, this code also
changes behaviour in some places:
- Because Sketch and SketchFile are now in control of renames and
saves, they can update their internal state after a rename. This
removes the need for reloading the entire sketch after a rename or
save as and allows `Editor.handleOpenUnchecked()` to be removed.
- When renaming the entire sketch, all files used to be saved before
renaming, since the sketch would be re-opened after renaming. Since
the re-opening no longer happens, there is no longer a need to save
the sketch, so any unsaved changes remain unsaved in the editor after
renaming the sketch.
- When renaming or adding new files, duplicate filenames are detected.
Initially, this happened case sensitively, but it was later changed to
use case insensitive matching to prevent problems on Windows (where
filenames cannot differ in just case). To prevent complexity, this
did not distinguish between systems. In commit 5fbf9621f6 (Sketch
rename: allowig a case change rename if NOT on windows), the
intention was to only do case insensitive checking on Windows, but it
effectively disabled all checking on other systems, making the check
not catch duplicate filenames at all.
With this commit, all these checks are done using `File.equals()`
instead of comparing strings, which is already aware of the case
sensitivity of the platform and should act accordingly.
- Some error messages were changed.
- When adding a file, an empty file is not created directly, but only a
SketchFile and EditorTab is added. When the sketch is saved, the file
is created.
- When importing a file that already exists (thus overwriting it),
instead of replacing the SketchFile instance, this just lets the
EditorTab reload its contents. This was broken since the introduction
of EditorTab. The file would be replaced, but not this was not
reflected in the editor, which is now fixed. This change allows
`Sketch.replaceFile()` to be removed.
- When importing a file that does not exist yet (thus adding it), a tab
is now also added for it (in addition to a SketchFile). This was
broken since the introduction of EditorTab, and would result in the
file being added, but not shown in the editor.
This commit adds a `Sketch.renameFileTo()` method, to rename a single
file within the sketch. It would be better to integrate its contents
into `Sketch.renameTo()`, but that does not have access to the `Sketch`
instance it is contained in. This will be changed in a future commit.
