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.
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.
