On Fri, Dec 12, 2014 at 12:34 PM, Gonzalo A. PEÑA CASTELLANOS
<[email protected]> wrote:
> Thanks for input Todd
>
>> After erasing my current config, after opening spyder for the first
>> time, I think some work could be done optimizing the initial
>> experience. This includes the initial selection of panels, the
>> initial layout of panels, and making sure the panels don't expose too
>> much or too little to users.
>
>
> This is indeed a great idea to take into account. On my side I believe the
> spyder interface is getting cluttered with too many toolbars (unneeded if
> you asked me..) and we should strive to make it a simple as possible. I have
> been working on a PR in order to make custom layouts. With this in mind I
> think is a great idea to make an initial first run screen so people get to
> choose their most suitable layout plus minus some other things. Right now
> the PR includes an R-Like, matlab-like, vertical and horizontal split
> layouts as well as the default spyder.
I think having some "clones" is good, but it might also be good to
have some layouts oriented to specific tasks. For example:
1.
a. A layout oriented towards interactive use (console, object
inspector, variable explorer, online help, history log)
b. A layout oriented towards simple editing with some interactive work
(editor, file explorer, console, variable explorer, history log))
c. A layout more like an IDE (editor, project explorer, static code
analysis, online help)
d. A layout oriented towards profiling and debugging (editor, project
explorer, breakpoints, variable explorer, profiler, object inspector)
e. Matlab Clone
f. R Clone
g. Current
> Also, inspired by the notebook I started to working in some sort of
> interactive tours
>
> What else do you think it would be a good idea to have as a startup
> setup/main configuration screen?
A few ideas (mostly related to my other suggestions):
2. Select which modules to import at startup:
a. Bare-bones (nothing)
b. Minimal (numpy, matplotlib)
c. Standard (minimal + scipy, pandas, from numpy import r_) <-- this
is the default
d. Large (standard + sympy, statsmodels, scikit-learn, from scipy
import stats, etc.)
e. custom...
3. Select how modules are imported (greyed out if "Bare-bones" is
selected above)
a. Python-style, short names (import numpy as np) <-- this is the default
b. Python-style, full names (import numpy)
c. Matlab-style (from numpy import *) (not available if "large"
profile is selected due to conflicts)
4. Select a default command prompt
a. IPython <-- Default
b. IPython Notebook (when finished)
c. Python native
based on Julien's suggestion:
5. Select how plots are displayed
a. In the command prompt <-- this is the default
b. In a new window
c. In a panel (if this is possible)
6. Select how print is handled (python 2.x only)
a. Python 3.x style <-- default
b. Python 2.x style
7. Select how division is handled (python 2.x only)
a. Python 3.x style <-- default
b. Python 2.x style
Another possibility would be to have general "styles", which combine
multiple of these, then have an "advanced" button to get the above
options. This would include:
1. Matlab-style (1==e, 2==d, 3==c, 4==a, 5==b, 6==a, 7==a)
2. Scientific interactive (1==a, 2==d, 3==a, 4==b, 5==a, 6==a, 7==a)
3. Scientific development (1==b, 2==c, 3==a, 4==a, 5==c, 6==a, 7==a)
4. Development environment (1==c, 2==a, 3==NA, 4==a, 5==b, 6==b, 7==b)
3. Bare-bones (1==g, 2==a, 3==NA, 4==a, 5==b, 6==b, 7==b)
One nice feature kdevelop has is that you can define your own
profiles, which remember what panels are open, how they are
configured, how they are laid out, etc. If you combine that with
these settings, users could define their own profiles that they can
they quickly switch between depending on what they are doing, rather
than picking one and being stuck with it. Further, it is smart about
them. So, for example, if you start the debugger, it switches to the
debugging profile automatically. And if you modify the layout of the
debugger profile, when you debug next time it remembers your changes.
>> So in this regard, I have some suggestions:
>> 1. Import the more standard python scientific packages by default (as
>> long as they are installed). At the very least this would include
>> numpy, scipy, matplotlib, and pandas, but could also include things
>> like sympy, scikit-learn, and/or statsmodels.
>
>
> I think that instead of doing this by default would not be such a great
> idea, besides the basic Scientific stack...(numpy, scipy, matplotlib,
> ipython, and now maybe pandas) everyone has a different setup in mind.
The reason I suggest sympy is because it is used extensively by, e.g.
ipython for its enhanced pretty printing, and statsmodels is a package
that pandas recommends. scikit-learn seems to be used in a wide
variety of fields and has a lot of books and stuff written about it.
I don't personally use any of these (I use numpy, scipy, matplotlib,
pandas, and a variety of subject-specific modules). But I think the
important thing is to have sensible defaults that will appeal to the
greatest number of users while not significantly increasing startup
time. That is what I was aiming for with these suggestions. Of
course other people may have different ideas.
>>
>> 2. Import them into their own namespaces using the format normally
>> found in documentation ("import numpy as np", "import scipy as sp",
>> "import matplotlib.pyplot as plt", "import pandas as pd", etc.). Only
>> import numpy's "r_" into the global namespace (so "from numpy import
>> r_").
>>
>
> Again, it is something that should be customizable instead of imposed.
Of course, these are only defaults.
--
You received this message because you are subscribed to the Google Groups
"spyder" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
