-
-
Notifications
You must be signed in to change notification settings - Fork 7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add per-session recently used boards list #8607
base: master
Are you sure you want to change the base?
Conversation
✅ Build completed. Please test this code using one of the following: ⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-8607-BUILD-831-linux32.tar.xz ℹ️ The |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good to see this change, will be very helpful. However, I wonder if we should persist the LRU list right away. Only keeping one per session is helpful if you're working with two boards at the same time, but typically I'll work with one board on one day, then with another board another day (and now I end up scrolling to a long list). If the LRU list is persisted, it will gradually become a list of boards you have / regularly use. For that to work, it might need a bit more than 4 entries, though.
Finally, I was a bit confused with your commit message saying "CTRL+SHIFT+INDEX", thinking "Where is the INDEX key?". Not a big deal, but perhaps rephrase that as "CTRL+SHIFT+" or something?
if (!first) | ||
boardMenu.add(new JSeparator()); | ||
first = false; | ||
boardMenu.add(new JSeparator()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this separator be present for the first platform when there are no recently used boards? Rather than checking that, perhaps this could just see if boardMenu
contains > 1 element and if so, add the separator?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems you fixed this in the next commit by always including the LRU header, I believe? I guess it will always have a value, since on startup some board will be selected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And a newer commit makes the LRU header again optional (when the preference is set to 0), so I again wonder if that produces a duplicate separator?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love to see that feature...
IMHO the last 4to5 recently used boards are fine, put persistent, not by session, please!
Thank you.
private static ButtonGroup boardsButtonGroup; | ||
private static ButtonGroup recentBoardsButtonGroup; | ||
private static Map<String, ButtonGroup> buttonGroupsMap; | ||
private static List<JMenuItem> menuItemsToClickAfterStartup; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why make this a static variable? It used to be a local variable, but now it is used in two places to pass to createBoardMenusAndCustomMenus
. However, in the new place in rebuildRecentBoardsMenu
, this list is not actually used after createBoardMenusAndCustomMenus
fills it, so there is really no point in sharing the same list. It would be just as well to let rebuildRecentBoardsMenu
have its own dummy list and pass that, or even pass null to indicate it does not actually care about this list (which requires some changes for createBoardMenusAndCustomMenus
to support that).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that this menuItemsToClickAfterStartup
has a lot of code smell and is probably better removed entirely, but that seems out of scope here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, seems you partially fixed this in your next commit, where one of the occurences is again a local variable, but the other one now still uses the instance variable for no apparent reason. I would make both a local variable, and revert the name change with the leading _
in the next commit.
app/src/processing/app/Base.java
Outdated
rebuildRecentBoardsMenu(); | ||
} catch (Exception e) { | ||
// TODO Auto-generated catch block | ||
e.printStackTrace(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this try block needed? I suppose that GUI modifications can throw, but why doesn't the same hold for e.g. rebuildExamplesMenu()
? Does that catch exceptions internally? Should rebuildRecentBoardsMenu()
do the same?
for (JMenu menu : boardsCustomMenus) { | ||
if (label.equals(menu.getText())) { | ||
return menu; | ||
} | ||
} | ||
throw new Exception("Custom menu not found!"); | ||
return null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this change? Is this case suddenly a normal occurence with this LRU list? Or is this just an unrelated improvement (that would perhaps be better in a separate commit)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's indeed a separate commit, thanks
if (!recentlyUsedBoards.contains(targetBoard)) { | ||
recentlyUsedBoards.add(targetBoard); | ||
} | ||
if (recentlyUsedBoards.size() > 4) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the size of the LRU list be a preference? I'm pretty sure people will be asking for more entries soon :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, a preference will not hurt and will be future proof 🙂
Hi @matthijskooijman , |
This commit is part of arduino#7120 by @sandeepmistry
The list appears at the top of Board submenu Boards are also reachable via a CTRL+SHIFT+number (starting from 1)
a5ea265
to
c0710e0
Compare
c5ab4e3
to
ea8755d
Compare
✅ Build completed. Please test this code using one of the following: ⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-8607-BUILD-856-linux32.tar.xz ℹ️ The |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did another review, but I think most of my previous comments are still unresolved? I also found some new things that I missed previously (or that you added, not sure).
try { | ||
rebuildRecentBoardsMenu(); | ||
} catch (Exception e) { | ||
// fail silently |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need this? Please don't eat exceptions...
app/src/processing/app/Base.java
Outdated
recentLabel.setEnabled(false); | ||
boardMenu.add(recentLabel); | ||
rebuildRecentBoardsMenu(); | ||
//rebuildRecentBoardsMenu(null); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This commented line can be dropped?
@@ -118,6 +118,11 @@ | |||
Editor activeEditor; | |||
|
|||
private static JMenu boardMenu; | |||
private static ButtonGroup boardsButtonGroup; | |||
private static ButtonGroup recentBoardsButtonGroup; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does recentBoardsButtonGroup
need to be a ButtonGroup? AFAIU, a ButtonGroup is intended to group radio buttons so only one of them can be selected at once, but all recent-boards radiobuttons are also added to boardsButtonGroup
, so they are already mutually exclusive. It seems you are using recentBoardsButtonGroup
just to keep track of all recent-boards menu items, and then it is probably better to use a plain LinkedList or other collection?
while (btns.hasMoreElements()) { | ||
AbstractButton x = btns.nextElement(); | ||
if (x.isSelected()) { | ||
return; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this return?
@@ -1367,7 +1367,7 @@ public void rebuildRecentBoardsMenu() throws Exception { | |||
buttonGroupsMap, | |||
board, board.getContainerPlatform(), board.getContainerPlatform().getContainerPackage()); | |||
boardMenu.insert(item, 3); | |||
item.setAccelerator(KeyStroke.getKeyStroke('0' + index, | |||
item.setAccelerator(KeyStroke.getKeyStroke('1' + index, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems an unrelated off-by-one bugfix that should have been squashed into the previous commit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not an off by one really but a different shortcut, so I'd leave it as a separate commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean that this shortcut is introduced in the previous commit and changed in this commit, so there is not really a point in separating them? You might as well introduce the shortcut correctly in the first commit? Also, this change (short 0 to 1) is currently in the " Fix concurrent access to menuItemsToClickAfterStartup" commit, where it does not belong at all AFAICS? So it should at least be moved into its own commit then.
app/src/processing/app/Base.java
Outdated
} | ||
JMenuItem recentLabel = new JMenuItem(tr("Recently used boards")); | ||
recentLabel.setEnabled(false); | ||
boardMenu.add(recentLabel); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also seems like a change unrelated to the click after startup commit that is better squashed into the previous commit.
if (!first) | ||
boardMenu.add(new JSeparator()); | ||
first = false; | ||
boardMenu.add(new JSeparator()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And a newer commit makes the LRU header again optional (when the preference is set to 0), so I again wonder if that produces a duplicate separator?
while (btns.hasMoreElements()) { | ||
AbstractButton x = btns.nextElement(); | ||
boardMenu.remove(x); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why all this bookkeeping? It seems that rebuildRecentBoardsMenu()
is only called from rebuildBoardsMenu()
, which AFAICS starts with making boardsMenu()
empty, so you can always just start from an empty slate here? Maybe that can be emphasized by renaming to addRecentBoardsMenuItems()
or something like that, if you're worried about people calling this method from other contexts as well?
cd41ab5
to
c0710e0
Compare
✅ Build completed. Please test this code using one of the following: ⬇️ https://downloads.arduino.cc/javaide/pull_requests/arduino-PR-8607-BUILD-950-linux32.tar.xz ℹ️ The |
The list appears at the top of Board submenu
Boards are also reachable via a CTRL+SHIFT+INDEX
This doesn't really fix, but is equivalent to arduino/arduino-ide#2339