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.
This makes a few related changes:
- `FileUtils.replaceExtension()` is introduced to handle replacing the
.pde extension with .ino.
- Instead of iterating .pde files on disk, this iterates SketchFiles in
memory, saving another lookup from filename -> SketchFile later.
- `SketchController.renameCodeToInoExtension()` is removed. Now it no
longer needs to look up the SketchFile and FileUtils handles the
extension replacement, this method did not have any reason to exist
anymore.
- Instead of hardcoding the .pde extension, a new
Sketch.OLD_SKETCH_EXTENSIONS constant is introduced.
There was already a nearly identical `FileUtils.copy()` that copies
directories recursively.
The only difference is that now hidden files *are* copied, but version
control files (according the list in FileUtils) are not. Since this only
affects the copying of the "data" directory during save as, this
should not be much of a problem.
Keeping filenames as File objects for as long as possible is generally a
good idea and this removes a dependency on `Sketch.getMainFilePath()`,
so it can be removed later.
Previously, it returned a File object, which the Sketch separately
stored from the primary SketchFile. By letting it just return the
SketchFile, and let callers query that for the filename, Sketch does not
need to store the File object itself and there is less chance of info
getting out of sync.
This limitation was added a long time ago, when the build system did not
cope with this. The current build system handles this situation just
fine, so this limitation can be lifted.
This handler was only always assigned the DefaultStopHandler, which did
nothing. It was called in a few places, but since it never does
anything, better remove it. For properly supporting stopping of external
processes, some better architecture should be added instead.
That name more accurately reflects its purpose: It represents a single
file within a sketch. This just updates the class name and variable
names referring to these objects and some comments, so no behaviour
should change.
Previously, the index of the SketchCode instance in the list kept by
Sketch was kept, which isn't really robust.
With this change, Sketch.indexOfCode is no longer needed and is removed.
For determining if the current file was a sketch file, it previously
(indirectly) used a hardcoded "ino" comparison. Now, it uses
`SKETCH_EXTENSIONS` so it also applies to .pde files and the hardcoded
"ino" (and the methods leading up to it) can be removed.
This lets it use FileUtils.splitFilename and reference Sketch.EXTENSIONS
and the new Sketch.DEFAULT_SKETCH_EXTENSION directly, allowing to remove
a few helper functions.
Before, `getPrettyName()` would return the extension-less name for all
files. There were a lot of places that checked for .ino and/or .pde
files and and called `getPrettyName()` for those, and `getFileName()`
for others. By moving this check into `getPrettyName()`, all those
callers become more simple, and more consistent (there were 5 different
checks to basically achieve the same thing).
There are small changes in behaviour, where .pde is now also hidden but
was not before. Also, the print header now shows extensions for other
files, which makes it more consistent with the tab names. For cases
where the old behaviour was still required, `Sketch.getBaseName()` was
added.
At the same time, the actual handling of the filenames is simplified by
using methods from FileUtils.
With this change `Sketch.getFileNameWithExtensionIfNotIno()` and
`SketchController.getHiddenExtensions()` are no longer needed and are
removed.
When renaming a file, the current tab is already the correct
one, so no need to switch. This allows looking up the tab index based on
the SketchCode object, instead of doing a filename lookup.
Sketch is now called SketchController, since it didn't really represent
a sketch, but just handled the GUI-related stuff for a given sketch
(note that it is not strictly a controller in the MVC-sense, but it does
have a similar function). SketchData more accurately represented the
actual sketch, so it is now called Sketch. Below, the new names are
used.
Editor now keeps both a current Sketch and SketchController object, and
the Sketch object is created by Editor and passed to SketchController,
instead passing a File and letting SketchController create the Sketch.
Wherever possible, code now uses the Sketch directly (or indirectly,
through the new `SketchController.getSketch()`) and the accessors in
SketchController that merely forwarded to Sketch have been removed.
There are few things that now live in SketchController but should be
moved to Sketch (`isModified()`, `isUntitled()`), so some of the code
still has a dependency on SketchController that should be removed later.
This commit mostly renames classes, methods and variables, it should not
change the behaviour in any way.
The only remaining thing that the method did was call `ensureExistence()`.
However, a call the `prepare()` was always followed by a call to
`build()`, which already calls `ensureExistence()`, so `prepare()`
didn't have any remaining value.
When adding a file to a sketch (using drag and drop, or the Sketch ->
Add file... menu item), .o, .a and .so files would be saved into a
"code" subdirectory of the sketch. This seems to be a remnant of
processing, where also .dll and .jar files could be added to a sketch to
be used. In the Arduino IDE, these code files serve no special purpose,
and are not treated specially, so it makes no sense to keep this code
around.
One implication of this is that when "save as" is used, a "code"
subdirectory is no longer copied, which might affect people using this
"code" subdirectory for other purposes.
Similarly, there is support for a "data" subdirectory, in which all
other files (that are not sketch source files) are stored, and which is
also copied on "save as". Support for this folder is kept intact, since
this appears occasionally used (the ESP8266 project uses it to store and
upload additional data files, for example).
This change was discussed on the mailing list in the "Anyone using
"data" and "code" subdirectories in sketches?" thread:
https://groups.google.com/a/arduino.cc/forum/#!msg/developers/zPlraPq55ho/ejrLqITnAgAJ
The former gives focus to the window in which a component is present,
while the latter only changes the focus within the current window (not
focusing the window itself if it is not focused yet). Java documentation
recommends changing `requestFocusInWindow()` where possible, due to some
platform-dependent behaviour in `requestFocus()`.
When focusing the serial monitor and plotter, `requestFocus()` is still
used, since then the focused window *should* change.
`EditorTab.setText()` now already preserves the caret position. The code
used during auto-format tried a bit harder to preserve the position
correctly, and probably worked better in a few specific cases, but for
most cases they would both end up approximating the caret position
anyway. To make the code simpler, better just stick to the simpler
approach.
When completely replacing all text, all highlights will end up at the
start of the file. Since keeping them at the right place is tricky (even
impossible in some circumstances), just remove them now.
This already happened in the autoformat code, so that part can be
removed.
By now, all calls to `addCode()` were followed by a call to
`sortCodes()`, and it seems like a task for SketchData to keep its list
sorted. Previously, this separation made some sense, since `addCode()`
was also used while loading a sketch, and you would only want to sort
once. Now, sketch loading uses a SortedSet, so this is no longer a
requirement.
Previously, the Sketch constructor called its `load()` function, which
called the `SketchData.load()` function to load files and then
`Editor.sketchLoaded()` to initialize the GUI with the loaded files.
When external editing was enabled, `Sketch.load()` was called again
when activating the Arduino app, to reload the entire sketch.
With this commit, the `Sketch.load()` function is removed, and
`SketchData.load()` is called from the SketchData constructor. Instead
of Sketch calling `Editor.sketchLoaded()`, that method is renamed
to `createTabs()` and called by `Editor.HandleOpenInternal()` directly
after creating the Sketch object.
Handling of external editor mode has also changed. When the Arduino
application is activated, instead of fully reloading the sketch (through
the now-absent `Sketch.load()` method), the new `SketchData.reload()`
method is called to reload the list of files in the sketch. If it
changed, all tabs are re-created. If not, only the current tab is
reloaded. When the user switches from one tab to another, that tab is
also reloaded. This ensures that the visible tab is always up-to-date,
without needlessly reloading all tabs all the time. When external
editing mode is enabled or disabled, all tabs are reloaded too, to make
sure they are up-to-date.
When re-creating all tabs, no attempt is made to preserve the currently
selected tab. Since adding or removing files happens rarely, this should
not be a problem. When files are changed, the currently selected tab is
implicitly preserved (because the tab is reloaded, not recreated). The
caret (and thus scroll) position is preserved by temporarily changing
the caret update policy, so the caret does not move while the text is
swapped out. This happens in `EditorTab.setText()` now, so other callers
can also profit from it.
To support checking for a changed list of files in
`SketchData.reload()`, a `SketchCode.equals()` method is added, that
just checks if the filenames are equal. Additionally, the loading of the
file list for a sketch has now moved from `SketchData.load()` to
`SketchData.listSketchFiles()`, so `reload()` can also use it. At the
same time, this loading is greatly simplified by using a sorted Set and
`FileUtils.listFiles()`.
In external editor mode, to ensure that during compilation the version
from disk is always used instead of the in-memory version, EditorTab
detaches itself from its SketchCode, so SketchCode has no access to the
(possibly outdated) in-memory contents of the file.
This makes checking for the primary file easier, without having to know
the index of a file in the list of tabs, or relying on the fact that the
primary file is always first (it still is, though).
This changes some places in Sketch to use the new
`SketchCode.isPrimary()` method, but there probably are a lot more
places in the code that could be start to use it as well.
This class served no purpose anymore, so it can be removed. The
`SketchCode.getMetadata()` and `setMetaData()` methods only served to
keep track of a SketchCodeDocument instance (and were no longer used),
so these are removed too, just like some SketchCode constructors dealing
with this metadata object.
This lets all code directly call `Editor.selectTab()`, or the newly
introduced `Editor.selectNextTab()` or `Editor.selectPrevTab()`. This
also adds a new `Editor.findTabIndex(String)` to look up a tab based on
the filename (what `Sketch.setCurrentCode(String)` used to do). At some
point, this method might need to be removed, but for now it allows other
code to keep working with minimal changes.
Instead of letting Sketch (also) keep track of the currently selected
tab, this moves the responsibility to Editor instead. When Sketch need
to know the current tab and file, it now asks Editor.
Switching between tabs is still handled through Sketch methods, but that
will be cleaned up later.
Previously, some of the GUI code would use Editor.getSketch() to get the
current sketch, and Sketch.getCurrentCode() to find out the currently
selected tab. Since this code is really concerned with the currently
open tab in the GUI, it makes more sense to query the Editor tabs list
directly.
This removes all references the current sketch code, as tracked by
Sketch, external to Sketch itself. This prepares for removing the
current tab tracking from Sketch later.
Now that each file in the sketch has its own text area in the GUI, it is
no longer needed to store the (possibly modified) contents of each file
inside SketchCode. Keeping the contents in the text area is sufficient.
Doing so allows removing the code that dealt with copying contents from
the text area into the SketchCode instance at the right time, which was
fragile and messy.
However, when compiling a sketch, the current (modified) file contents
still should be used. To allow this, the TextStorage interface is
introduced. This is a simple interface implemented by EditorTab, that
allows the SketchCode class to query the GUI for the current contents.
By using an interface, there is no direct dependency on the GUI code. If
no TextStorage instance is attached to a SketchCode, it will just assume
that the contents are always unmodified and the contents from the file
will be used during compilation.
When not using the GUI (e.g. just compiling something from the
commandline), there is no need to load the file contents from disk at
all, the filenames just have to be passed to arduino-builder and the
compiler. So, the SketchCode constructor no longer calls its `load()`
function, leaving this to the GUI code to call when appropriate. This
also modifies the `SketchCode.load()` function to return the loaded
text, instead of storing it internally.
To still support adding new files to a sketch (whose file does not
exist on disk yet), the EditorTab constructor now allows an initial
contents to be passed in, to be used instead of loading from disk. Only
the empty string is passed for new files now, but this could also be
used for the bare minimum contents of a new sketch later (which is now
down by creating a .ino file in a temporary directory).
Another side effect of this change is that all changes to the contents
now happen through the text area, which keeps track of modifications
already. This allows removing all manual calls to `Sketch.setModified()`
(even more, the entire function is removed, making `Sketch.isModified()`
always check the modification status of the contained files).
Previously, EditorTab set the Document on the SketchCodeDocument, and
the latter would listen for changes, only forwarding the modified status
to SketchCode. This commit cuts out a step and lets EditorTab call
SketchCode::setModified directly.
Additionally, the DocumentTextChangedListener helper class is added,
which wraps a simple (lambda) function to be called whenever anything
about the document text is modified. This hides the verbosity of having
to handle both insertion and deletion, and instead suffices with just
having a single lambda function instead.
RSyntaxTextArea appears to support using a single instance and replacing
the underlying text and document when switching between tabs, but in
practice this support is not complete and even though the
RSyntaxTextArea developers did some work to improve the situation, they
recommend to just use a seperate instance for each tab.
This commit implements exactly that. A new class EditorTab is introduce
to wrap the RSyntaxTextArea and containing scroll pane, and to
encapsulate the code related to handling the text area itself. Doing so
removes some quirks and prepares for some later additions. In
particular, error highlights are now no longer shared between all tabs,
which was previously the case.
This commit mostly moves code from Editor into EditorTab, and updates
the callers to use getCurrentTab() and call methods on the result
instead of calling them on Editor. Some code is added to take care of
creating multiple EditorTab objects and switching between them. Some
small changes have been made to make the flow of opening files work,
though these are mostly a bit hacky.
While moving code, changes to the rest of the code were kept minimal,
retaining existing interfaces as much as possible. This sometimes result
in less than ideal code, which should be cleaned up in subsequent
commits.
The SketchCodeDocument class has been pretty much emptied out, since
it was mostly used to store things for tabs in the background, which are
now just stored in each RSyntaxTextArea separately. The last remaining
bits of this class can probably be moved or implemented differently
later, so it can be removed.
The entire flow of working with sketches and files needs to be cleaned
up next, so no thorough attempt at testing this commit was done. It is
likely that there are plenty of corner cases and race conditions, which
will be fixed once the reset of the code is cleaned up.
Fixes#3441
For some toolbar buttons, when it is clicked while shift is pressed, its
function changes. When handling the click event, this information is
directly taken from KeyEvent.isShiftDown(). However, to also show the
proper tooltip *before* clicking, EditorToolbar listened to key events
on the main text area, to know when shift is (not) pressed.
This approach means that pressing shift while the text area is not
focused will not change the tooltip, and creates some unwanted coupling
between the toolbar and the text area.
This commit changes this approach to instead use the global
KeyboardFocusManager. Any key presses pass through there before being
dispatched to the currently focused component, so this makes sure that
any shift presses are caught, as well as making EditorToolbar a bit more
self-contained.
This fix a regression introduced in:
048a8a61 (VersionHelper now correctly strip snapshot info)
actually neither 048a8a61 nor the version before are correct becuase:
048a8a61 - strips all the extra `-snapshot` and `+build`
previous - doesn't handle the case `x.y-snapshot`
Now both are handled correctly and a test has been added to verify this.
To be completely semver compliant we should deny versions in the
format `x.y`, but this will break all legacy version that have been
published until now, so this changed should be postponed for the next
major release of the IDE.
Fix#5251
A new property "includes" has been added to library.properties.
This property contains a comma-separated list of the files to be included when
the user selects the "Include library" command on the Arduino IDE.
If the property is missing the old behaviour is used.
OS X supports many simple Emacs keybindings in native text fields. (It
can do this because the system UI uses Cmd instead of Ctrl as its main
modifier key.) Add bindings to functions which already exist in
DefaultEditorKit.
I have a Ctrl-k (cut to end of line) implementation, but it is an
additional static RecordableTextAction class. I have not included it.
The current method of reporting upload errors is based on an exoteric combination of exceptions which makes return error code useless
The Uploader.java message() implementation is too avrdude-dependant to allow easy portability since the upload tools are becoming a lot and very different
With this commit we try to avoid exceptions and only use the external uploader's exit code to decide the status bar message.
The message can be:
- the last line containing "error" string (any case) or
- the usual avrdude message parsing (to keep compatibility with translations)
Needs testing with all platform and all supported upload tools
This commit introduces the concept of stateful board list (vs. original stateless) and board serial number.
The board is now an "entity" composed by the triplet port/vid/pid. These informations come from libListSerial "light" function. When the board list changes, it triggers a request for the additional infos to libListSerial. These information contains the serial number of the boards.
These brings a lighter and faster scanning process. Some logic has been introduced to handle a board with the S/N only exposed in the bootloader (like 32u4).
In this case the disappearing port acquires the bootloader's S/N
A menu (under Ports menu) shows the currently connected port info and can be used for bugreporting
Disable Compile/Run buttons as they get press, and reenable only on function exit.
The launched upload process has now a 2minutes timeout before being terminated forcefully.
10 second after pressing "Upload" the button comes pressable again, but this time the previous upload command gets killed explicitely
The caller of Theme.getThemeImage(...) now pass only the name of
the needed resource and the theme folder is searche in the following
order:
- name.svg
- name.png (if svg is not available)
- name@2x.png (if none of the above are available or if 1x png is
too low resolution for the current scaling factor)
Hi-resolution images are saved with the "@2x.png" suffix, the image
loader will select the best image available based on the user selected
scaling.
Missing hi-res images can be added later together with lo-res images.
This allows the use-case with users editing one sketch at a time, that
seems to be the most common scenario:
1. User position the editor as desired
2. User close the IDE
3. User opens the IDE by double clicking on another .ino file
4. The IDE is opened again at the same position
See #4432
The check for "resolution-changed" is performed when an editor
location is retrieved from preferences. This commit rationalize
access to PreferencesData and prepares for the next improvement.
This rationalization helps to better follow the swing abstractions
of table models and increase separation of concerns.
(WIP: ContributedPlatforms needs a similar refactoring that will be
done in the next commits)
When a sketch has unsaved changes, a temporary copy of the sketch is
made with those changes applied. This copy is then passed to
arduino-builder.
Previously, the name of this directory contained a hash of the main
sketch filename, so the same directory would be used between builds. Now
that this directory is deleted after every build, it can just use a
randomized directory name, which is what this commit does.
Addtionally, the prefix used for generating the name is changed from
"arduino_" to "arduino_modified_sketch_" to make it slightly clearer
what the directory is for (just in case it somehow survives the build,
or a user sees it during the build).
When a sketch has unsaved changes, a temporary copy of the sketch is
made with those changes applied. This copy is then passed to
arduino-builder.
Previously, this temporary copy was kept around and only deleted when
the IDE was closed. However, all files were written to it again on every
build, so keeping the old files around did not serve any real purpose.
When a file was renamed in the IDE, the original name would still be
present in the temporary copy, and could cause linker errors because
both were compiled.
This commit makes sure the temporary copy is deleted after every build,
instead of at IDE exit, which fixes this problem with renames.
When a file is deleted from the sketch, the file would also be deleted
from the temporary copy, presumably to fix this same problem for
deletes (but renames were forgotten). With this commit, this special
handling for deleting files is no longer needed, so it is removed.
This fixes#4335
Previously, there was a handler on the text area that consumed most
KEY_TYPED events with control pressed. This was added a long time ago to
fix a problem with ctrl-slash doing both the toggle comment action and
inserting a /. Further investigation shows that with RSyntaxTextArea
this problem is still present, but is caused by a weird binding on the
slash key that Arduino is not even using. Removing that binding is a
cleaner workaround for this problem, so this commit switches to that
workaround.
Ideally this would be fixed in RSyntaxTextArea, see
https://github.com/bobbylight/RSyntaxTextArea/issues/157
In the previous commit, these bindings were moved to EditorTab and
registered in a cleaner way, but this move also allows more components
to hijack these keystrokes and prevent them from reaching EditorTab.
This commit makes the keybindings work again, by preventing other
components from handling the keys. In particular:
- JSplitPane had a binding to switch between its two panes, which is
now removed after creating the JSplitPane.
- The default focus traversal manager in Swing uses these keys to
traverse focus (in addition to the the normal tab and shift-tab
keys). By removing these keys from the set of "focus traversal keys"
defined for the window, this should be prevented when the focus is on
any component inside the window.
- JTextPane didn't respond to the previous modification of the
window-default focus traversal keys, since it defines its own set (to
only contain ctrl-tab and ctrl-shift-tab, but not tab and shift-tab,
for undocumented reasons). To fix this, focus traversal is simply
disabled on the JTextPane, since this wasn't really being used
anyway.
There was some code in SketchTextArea that tried to modify the focus
traversal keys for just the text area, which is now removed. This code
wasn't really useful, since focus traversal is disabled for the text
area already. Also, the code contained a bug where it would not actually
set the new set of keys for the backward focus traversal.
Closes#195
Previously, EditorListener handled these keys, by registering a handler
in the text area. This meant that they would only work while the text
area was focused. By registering the keys as WHEN_IN_FOCUSED_WINDOW
bindings, they can always be handled, and EditorHeader seems like a more
appropriate place.
Note that this does not currently work (so this commit breaks these
keys), since these keys are also handled in a few different places as
well, preventing these newly added keybindings to take effect. This will
be fixed in the next commit.
One additional change is that previously, these keybindings did not work
when the text area was readonly. This was probably a remnant from when
EditorListener took care of a lot of other editing keybindings, but
this does not make much sense anymore now.
Finally, with the old bindings, ctrl-shift-tab did not (seem to) work.
What happened is that the binding for ctrl-tab did not check the shift
state, so both bindings would fire on ctrl-shift-tab, switching forward
and back again, making it seem the keys did not work. The Swing
keybinding mechanism that is now used for these bindings checks the
complete keystroke, including all modifier keys, so this problem is
fixed by this change.
References #195
These key combinations were registered as accelerator keystrokes in the
tab bar popup menu, but also handled by EditorListener. This was
probably added in an attempt to work around the broken accelerator keys
on the tab bar popup menus, but in practice this only meant that the
shortcut would sometimes (and now that the accelerator keys are fixed,
always) switch tabs *twice*. Removing the handling from EditorListener
helps to fix this.
References: #4228
Previously, this would use a single ActionListener object, and pass the
filename of the file to switch to in the action command. This means that
whenever switching the filename needs to be looked up. This commit
instead uses a lambda to capture the index of the tab to switch to for
every tab (so it uses a different ActionListener for each tab).
Some items in this menu had accelerator keys (shortcuts) defined.
Normally, this automatically takes care of registering such keybindings
when the menu item is added to a menu. However, this requires adding the
item (indirectly) to a menubar, which is again added to a window. Since
the tab menu is just a separate popup menu, this did not work.
It seems an attempt was made to fix this by adding the popup menu to the
EditorHeader JComponent, which indeed made the keybindings work.
However, this is a hack at best, and as soon as the popup menu was
opened, it would be moved to another container and again detached when
the menu was closed, breaking the keyboard shortcuts again (re-adding
the popup menu turned out not to work either, then the menu would
actually be drawn on top of the tab bar).
To properly fix this, keybindings for the menu items are added to the
EditorHeader itself. By looking at the existing accelerator keystroke
property of the actions, there is no need to duplicate the keystrokes
themselves, and the displayed value will always match the actually bound
value. To simplify this, some methods are added to the Keys helper
class, which will likely come in handy in other places as well.
Instead of defining JMenuItems, setting accelerator keys, and attaching
an ActionListener inline, this first defines a list of actions (with a
name, optional accelerator key and using a lambda as the action
listener). Then menu items are added, that simply refer to the
previously defined actions.
The actions are defined in a inner class named Actions, of which one
instance is created. This allows grouping the actions together inside
the `actions` attribute, and allows external access to the actions (in
case the same action is present in multiple menus, or otherwise
performed from other places). This might not be the best way to expose
these actions, and perhaps they should be moved elsewhere, but for now
this seems like a good start.
This adds new helper classes SimpleAction, to allow more consisely
defining Action instances, and a new class Keys, to allow consisely
defining keyboard shortcuts.
back to the IDE. Instead of having just stdour and stderr, stdout only is
used, but each message has a log level: info, warn, debug, error
Plain stdout/stderr are still used by child processes
There is no need to instantiate a SystemProfilerParser object
each time extractVIDAndPID is invoked.
Added also `synchronized` keword to avoid reentrance problems
if the method is being used in multiple threads.
