[IDE] Slow Startup - Create Examples menus for Libraries (need ignore files) #10235
Comments
ricardojlrufino
changed the title
ricardojlrufino
changed the title
|
I had to look at the code a bit closer, but it seems there's two versions of Then, the two-argument library version then calls the three-argument version (as shown in your post). This then recursively scans the entire library dir for sketches, rather than just the "examples" directory. You would wonder why this does not show up submenus labeled "examples" everywhere, but that is because there is a special case here: Arduino/app/src/processing/app/Base.java Lines 1833 to 1835 in 02a2e22 I actually think that this might be a bug in itself: If a library includes sketches outside of the
Your proposal seems to also fix this, which I think is a good thing. However, your proposal seems to duplicate some code, the code you added is already here: Arduino/app/src/processing/app/Base.java Lines 1838 to 1844 in 02a2e22 I thought it could be reused by just passing the Maybe a little refactoring could help here, to have a function that says "Add a submenu with this name containing the subdirectories of this directory recursively" helper function could be added to be used in both cases?
Probably a good idea, since it allows separating discussions about each problem easily, and referring to each problem separately in commit messages. |
Yes, it was the first test I did. And I realized this problem.
It already exists, as you mentioned: The fix I made adds little code and reuses existing functions |
|
Another problem is that not all libraries put the examples in the |
|
Should we really cater for those? The library spec clearly says it should be "examples" in lowercase, and the fact that those work at all is basically due to a bug I think (and even if they do work, you'll have an extra "Example" submenu now). I would be in favor of only supporting Would it be hard to scan all libraries in the library manager for any folders that look like examples but are not exactly? Maybe even just file bugs against? |
That's the problem, people will see the examples disappear on some libraries with no apparent reason -> more issues to handle later.
Let me check this... |
|
Looking at the list again, just adding |
|
In principle, I like having a single specific folder name for examples, but the fact that the IDE has recognized any sketch as an example for so long means there are a lot of libraries that don't follow the specification. I think being a little fuzzy with the supported folder name, but restricting support to variants of "examples" that clearly indicate the library author intended this folder to contain examples is a good compromise. This would fix #5688 and https://github.com/arduino/Arduino/issues/7315. One thing to consider when looking at the list above is that quite a few of those and so wouldn't be recognized by the Arduino IDE anyway. There are also some where the
I have a script that scans all the Arduino libraries on GitHub for common problems, including containing sketches that are outside a specification-compliant folder. I have made some efforts to submit PRs to fix this on my campaigns to fix the issues reported by the scan, but I found it difficult to convince some library authors that it was worth making the change to follow the specification when the IDE didn't enforce the specification, so I didn't consider that particular issue to be a priority for my efforts. With a clear signal that this will no longer be supported in the next release, I think I would have much more success. I'd be willing to do a run of submitting PRs to the libraries that are using unsupported sketch locations in order to mitigate the potential impact of this change. |
|
I tested some layouts, and we have the following result Supporting ALIB_Test02, may be good.. Implementation: private boolean addSketchesSubmenu(JMenu menu, UserLibrary lib) {
JMenu submenu = new JMenu(lib.getName());
boolean found = false;
// Compatibility mode: not all community libraries are following the specification, look for common names found.
File[] list = lib.getInstalledFolder().listFiles(new ExamplesFilter());
for (File folder : list) {
if(addSketches(submenu, folder)) {
found = true;
}
}
if (found) {
menu.add(submenu);
MenuScroller.setScrollerFor(submenu);
}
return found;
}public class ExamplesFilter extends OnlyDirs {
@Override
public boolean accept( File dir , String name ) {
if(!super.accept(dir, name)) return false;
return name.toLowerCase().startsWith("example") ;
}
} |
I don't think so. Those are never valid sketches, so it will require significant code to allow loading them, and then users could be very much confused that these sketches work like this as an example, but break when they copy them elsewhere (e.g. without a top-level directory that matches the .ino name). Your code proposal looks good, using such a filter neatly takes care of all the different ways and casings. Also, with this additional filtering, the code duplication I mentioned before is reduced (because this now includes potentially multiple directories in the same menu) and probably not a problem anymore. I do wonder: Do we need that |
|
IIRC the I would change the condition with othewise also for the rest look good to me. |
If each recursive call takes care to never add a menu unless it is non-empty, I think it should be ok? Agreed with your other comments, @cmaglie. |
I think it will get more complicated than just returining |
If we update the spec, probably also include there that the examples folder(s) are scanned recursively, so example sketches can be categorized by putting them in subfolders (this is currently the case already, but not made explicit in the spec). |
will not match that cases.
|
|
My idea was to support this format too, which is similar to the print above.
|
IMO, that's fine. They will just need to move the examples to a specification-compliant location. Only the It is unfortunate that the user experience will be worsened by the examples of some unmaintained libraries no longer being visible, but the current behavior of picking up all sketches is also causing some harm, so I think it's worth the trade-off. |
I really doubt that's a common convention. It doesn't seem worth adding extra complexity to the code to support this very rare usage. |
Ok, I agree to align the specification:
OK ?! |
|
Now let's move on to the next problem, similar to this one, which is related to the 'Skecthbook' folder. In my case I have a Sketch that has the node_modules folder, and it takes a long time to scan. I can imagine now only two options ...
|
|
re: libraries with examples folders not called 'examples': |
per1234
added
the
feature request
Hi, I realized that also the code that builds the examples of the libraries, may have a problem. If the library has large documentation (docs) like generated by doxygen, or some other directory with many files, the IDE will take a long time to scan.
My first idea was to ignore the known files ... as is done with .svn and .git ... but I ended up identifying that it is better to do this treatment below:
Arduino/app/src/processing/app/Base.java
Lines 1779 to 1781 in 02a2e22
to this:
To only focus on the folder of interest.
In my case I had a node_modules folder (don't ask me why ... lol) it took about 5s to read it
total time was around 11s, because i had another library with a big docs folder.
PS: Sorry for opening several separate problems, but it is for us to track the errors I found. As it is part of an ongoing refactoring, in order to solve part of the same "slow startup" problem, it is difficult to make several separate pull requests.
The text was updated successfully, but these errors were encountered: