Open SuzanneSoy opened 7 years ago
I agree that we can improve this, but my premise with the "disable on single-core machines" was that nearly any single-core machine that people have these days will be hard to use when there is a second place going that's continuously compiling the program. So I think we do want to stick with that as a default. After all, there were some 15 years of people using DrRacket when online check syntax wasn't available to them and we don't want the experience to be worse than that experience. Put another way, it is the non-experts I had in mind when I changed the default of the preference.
(I object to the speech bubble, especially if a paperclip is doing the talking ...)
As for tools, I don't think they affect the editing experience; only the app start up time. Is that what you experience?
Yes, the tools mostly (only?) influence app start up time, not the editing experience.
I just realized that after running the "Check Syntax" tool (which shows the arrows even when background expansion is disabled), the blue boxes do appear afterwards (on 20170510-e6793c4598 at least), and use a cached list of require
d modules. So I suppose background expansion is not as essential as I thought :) .
As for the paperclip, agreed. What about showing the blue quarter-of-circle by default, and inside the blue box, show "to enable on-line documentation, click on the Check Syntax tool or enable background expansion" ? This is not nagging, the blue quarter-of-circle can be disabled altogether using the usual mechanism, the blueboxes feature is discoverable, and when the user curiously tries to see what the purpose of the blue thing is, there is a clear hint on how to start using the feature.
Otherwise, is it technically possible/easy to make the background expansion process have a lower priority (say a "nice" value of 10 on Linux, IIRC Windows has a similar mechanism)?
Commit https://github.com/racket/drracket/commit/2ec3dc0489f681920d9944940444783ac72b7ffc disabled background expansion on machines where places are not enabled, and where there is only one CPU.
This is IMHO a bad thing, as clueless beginners will have a hard time guessing why they do not get contextual help, while their friends have nice blue boxes and arrows to help them out. The feature is made hard to discover: one has to click on a literally invisible icon (see #116) or a red dot in the lower-right corner, which tooltip says "background expansion is disabled" (no mention of help bubbles or arrows) to get a help bubble in the top right corner and arrows overlaid on the program.
I think we should make the experience as effortless as possible for new learners (the initial welcome screen which asks the user to select a language goes towards that goal, for example), and enable helpful features by default. If seasoned programmers want to disable the blue boxes for performance reasons, they are more likely to manage to find that hard-to-discover button and use it to disable the feature, rather than the other way round.
If performance is really a concern on single-CPU machines, then maybe we should display a small speech bubble upon the first startup, pointing towards that icon and indicating "For a more smooth experience at the expense of features, you can disable background expansion by clicking on this button" (and not the opposite).
Along the same line of thinking: if we really wanted to ship a super-efficient IDE, we would disable all tools (teachpacks etc.) by default (that's what I do on my machine, to shorten DrRacket's startup time), and require that users enable the ones which they want in the preferences. Clearly, that would be unhelpful to newcomers.