<p><br>
On Jul 14, 2012 1:58 PM, "Brian Granger" <<a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a>> wrote:<br>
><br>
> On Fri, Jul 13, 2012 at 7:05 PM, Kent Inverarity<br>
> <<a href="mailto:kent.inverarity@adelaide.edu.au">kent.inverarity@adelaide.edu.au</a>> wrote:<br>
> > I'd like to add a vote in for the continued presence of the dashboard, and<br>
> > for Brian's idea for incorporating multiple directories in the dashboard. I<br>
> > have no need at all for a fully-fledged file manager, just a means to switch<br>
> > between project dirs. And only an "Open" dialog doesn't fit that idea of a<br>
> > project dir at all.<br>
><br>
> One other issue we need to work out:<br>
><br>
> What if I have a git repo at ~/foo, that has subdirectories, bar and<br>
> bam, each with notebooks. With the model I propose, how does the user<br>
> register the project? Do they register ~/foo and we automatically<br>
> scan that dir and all subdirs for notebooks? Or do we require them to<br>
> separately add ~/foo/bar and ~/foo/bam as projects dirs?<br>
><br>
> My intuition is to go with the first option and include the last part<br>
> of the path in the notebook name in the dashboard like:<br>
><br>
> bam/notebook1.ipynb<br>
> bar/notebook3.ipynb<br>
><br>
> That would enable a user to add an entire directory tree of notebooks<br>
> in one quick step.<br>
><br>
> > Also probably worth considering that an awful lot of users hate the command<br>
> > line, even for simple things like changing directories.<br>
><br>
> How do you feel about requiring users to use the command line for more<br>
> advanced things such as:<br>
><br>
> * Moving notebooks between directories.<br>
> * Renaming directories.<br>
> * Copying entire projects.<br>
> * etc?</p>
<p>I don't see that as a problem, because everyone's used to doing that, whether in a shell or using something like Windows Explorer. It'd be good to have in the dashboard, but not as necessary as changing the project directory.</p>
<p>> > With a dashboard<br>
> > that allows you to change dirs, the local-user use scenario doesn't require<br>
> > you to use the command line at all beyond the initial launch, which can be<br>
> > wrapped up into a shortcut, etc.<br>
><br>
><br>
><br>
> > Cheers<br>
> ><br>
> > Kent<br>
> ><br>
> ><br>
> > On 14 July 2012 08:39, Brian Granger <<a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a>> wrote:<br>
> >><br>
> >> Carl,<br>
> >><br>
> >> On Fri, Jul 13, 2012 at 10:23 AM, Carl Smith <<a href="mailto:carl.input@gmail.com">carl.input@gmail.com</a>> wrote:<br>
> >> > Each to their own. I never got the dashboard myself. I don't think it<br>
> >> > makes<br>
> >> > sense to have two interfaces when one of them can already do everything<br>
> >> > the<br>
> >> > other is meant to do.<br>
> >> ><br>
> >> > Google docs is different because a doc can't manage other docs.<br>
> >><br>
> >> I want to understand your view on this. In my view, each notebook is<br>
> >> a document, just like Google Docs. In fact much of the design on the<br>
> >> current notebook app is a blatant rip off of Google Docs. In your<br>
> >> mind, how does the notebook differ from Google Docs?<br>
> >><br>
> >> > If other people like the dashboard, that's cool. There's nothing really<br>
> >> > wrong with it. I'm just a minimalist.<br>
> >><br>
> >> We are pretty minimalist as well. Initially I thought about going in<br>
> >> the direction you are talking about = having no dashboard and a more<br>
> >> complex UI in the notebook page. What I found though is that the<br>
> >> notebook page grew a lot of complexity that made it feel less simple.<br>
> >><br>
> >> Cheers,<br>
> >><br>
> >> Brian<br>
> >><br>
> >> > On Jul 13, 2012 5:59 PM, "Junkshops" <<a href="mailto:junkshops@gmail.com">junkshops@gmail.com</a>> wrote:<br>
> >> >><br>
> >> >> On 7/12/2012 7:30 PM, Carl Smith wrote:<br>
> >> >> > I would suggest just creating a magic that can open a notebook, given<br>
> >> >> > a path to it, using a bit of JavaScript.<br>
> >> >> ><br>
> >> >> > If you then started new IPython Notebook sessions with a new, empty<br>
> >> >> > notebook, instead of the dashboard, the user could do everything<br>
> >> >> > Brian<br>
> >> >> > suggested regarding the file system from within that notebook, and<br>
> >> >> > open any other notebooks whenever they wanted with the magic.<br>
> >> >> ><br>
> >> >> > You could add the options to open a notebook in the same tab, and<br>
> >> >> > either save and close the current notebook, or just delete it.<br>
> >> >> ><br>
> >> >> > Then there's no need for the dashboard at all and the Open... option<br>
> >> >> > in the File menu can be gotten rid of too.<br>
> >> >> ><br>
> >> >> > Maybe I've missed something, but I just thought I'd add my two<br>
> >> >> > pennies.<br>
> >> >> > I think cluster controls and drag and drop uploads can be done from<br>
> >> >> > within a notebook too.<br>
> >> >> I assume this is all fine for advanced users, but my 2bits as an<br>
> >> >> IPython<br>
> >> >> newbie is that the dashboard and file menus make IPy much more<br>
> >> >> user-friendly for new users. I'd recommend keeping the dashboard and<br>
> >> >> the<br>
> >> >> file/engine tabs as the default, but perhaps there could be a command<br>
> >> >> line option to disable the dashboard and start instead with a bare<br>
> >> >> notebook when connecting to the nbserver.<br>
> >> >><br>
> >> >> I guess I don't understand why having the File>open menuitem is a<br>
> >> >> drawback. Again, it's friendly to new users as opposed to having to<br>
> >> >> look<br>
> >> >> up a magic command.<br>
> >> >><br>
> >> >> Cheers, Gavin<br>
> >> >> _______________________________________________<br>
> >> >> IPython-User mailing list<br>
> >> >> <a href="mailto:IPython-User@scipy.org">IPython-User@scipy.org</a><br>
> >> >> <a href="http://mail.scipy.org/mailman/listinfo/ipython-user">http://mail.scipy.org/mailman/listinfo/ipython-user</a><br>
> >> ><br>
> >> ><br>
> >> > _______________________________________________<br>
> >> > IPython-User mailing list<br>
> >> > <a href="mailto:IPython-User@scipy.org">IPython-User@scipy.org</a><br>
> >> > <a href="http://mail.scipy.org/mailman/listinfo/ipython-user">http://mail.scipy.org/mailman/listinfo/ipython-user</a><br>
> >> ><br>
> >><br>
> >><br>
> >><br>
> >> --<br>
> >> Brian E. Granger<br>
> >> Cal Poly State University, San Luis Obispo<br>
> >> <a href="mailto:bgranger@calpoly.edu">bgranger@calpoly.edu</a> and <a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a><br>
> >> _______________________________________________<br>
> >> IPython-User mailing list<br>
> >> <a href="mailto:IPython-User@scipy.org">IPython-User@scipy.org</a><br>
> >> <a href="http://mail.scipy.org/mailman/listinfo/ipython-user">http://mail.scipy.org/mailman/listinfo/ipython-user</a><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > IPython-User mailing list<br>
> > <a href="mailto:IPython-User@scipy.org">IPython-User@scipy.org</a><br>
> > <a href="http://mail.scipy.org/mailman/listinfo/ipython-user">http://mail.scipy.org/mailman/listinfo/ipython-user</a><br>
> ><br>
><br>
><br>
><br>
> --<br>
> Brian E. Granger<br>
> Cal Poly State University, San Luis Obispo<br>
> <a href="mailto:bgranger@calpoly.edu">bgranger@calpoly.edu</a> and <a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a><br>
> _______________________________________________<br>
> IPython-User mailing list<br>
> <a href="mailto:IPython-User@scipy.org">IPython-User@scipy.org</a><br>
> <a href="http://mail.scipy.org/mailman/listinfo/ipython-user">http://mail.scipy.org/mailman/listinfo/ipython-user</a><br>
</p>