This commit makes the Preferences dialog more usable by accessibility devices like screen readers.
Previously, a screen reader would only read the content of the text boxes. By using JLabel's setLabelFor() feature (and in some extreme cases, setAccessibleName()), a screen reader will know that a label is assigned to a text field. For example, instead of just reading "12", it will now read "Editor font size: 12".
This commit adds the Menu+Shift+I shortcut to the remaining menu entry in Base.java.
When the shortcut is called, the menu entry from Base.java is the one that will be called.
Please note that this commit actually adds the shortcut to its menu
entry under the "Tools" menu.
As a side effect, the shortcut tip is only shown in this entry and not
on the another one.
Menu usually means the Ctrl key on most modern systems.
This duplicates the entry, so now "Manage Libraries..." is available
in both under the "Tools" menu and inside the "Sketch" -> "Include
Library" menu.
The reasons for this change are:
- It makes sense for the entry to be there
- It makes easier for the user to click on the entry
Aditionally, I added a comment about a issue I found with the
newJMenuItemShift function on Xubuntu 17.04 regarding the Ctrl+Shift+K
shortcut.
In menu Sketch/Include Library/ library types (Arduino|Recommended|Contributed) are not translated into selected «Editor language» although types are translated in .po files.
There could be a couple of edge cases in this approach (for example, if someone wants to keep the serial monitor window only half visible).
However, it should be at least safe (no serial monitors on the second screen) if the Window Manager acts correctly (by moving all the windows on the second monitor to the primary on detach).
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);
}
}
