
The Tree Slider - GitHub - sant0sk1
https://github.com/blog/760-the-tree-slider
======
jfager
Very nice, but what I'd personally rather have is a two-pane navigator:
explore the tree in the left pane, see file contents in the right, a la
NERDtree, eclipse, and other IDEs.

~~~
jdminhbg
This isn't [only] two panes, but it gives you the ability to navigate files
while still seeing the directory structure:
<https://github.com/sr3d/GithubFinder>

It's implemented as a bookmarklet that you can activate on any github repo for
an advanced view.

~~~
jfager
That is beautiful, thank you.

------
compay
I find the animation to be rather annoying.

------
wmf
It looks like the sliding transition may also mask network latency; clever.

~~~
jws
From the Digital Equipment Corporation, VMS Guide to Performance Tuning, from
before 40% of the HN readership were born:

    
    
      5.3.4.3 Lower the Baud Rate if Terminals Smooth Scroll
        If many of the applications at your site write characters to
        terminals in the smooth scrolling mode … you might consider 
        reducing the baud rate [from 9600 to 4800] …  the decrease in
        the baud rate would be barely perceptible to the users.
    

VT100 _transitions_ come to the rescue!

(Smooth scrolling was at 6 lines per second. Glassy smooth, especially if you
kept the line saturated to the flow control limits. But as a consequence it
couldn't accept more than about 4000bps of data on 80 character lines.

That particular hint never made much sense to me because it is about saving
interrupts and a screen of data took the same number of interrupts at 4800 or
9600. I think it was more about slowing down the users without them noticing
to avoid upgrading the computing resources.)

~~~
borism
"A century after the wireless telegraph revolutionised communications, the
Internet has re-established a telegraph that runs on (telephone) wires."
-Umberto Eco,

who's essay was widely criticized here yesterday for some factual mistakes. He
did get one thing right though.

------
yan
I guess this is a good place to ask, but does anyone know why GitHub opted not
to list the file size in the file viewer? Whenever I browse other peoples'
code I always want to glance at file sizes to see which files I should peruse
first.

~~~
cdavid
Maybe because it is difficult to do so efficiently ? It is hard to get per-
file information in git, so you would have to be pretty clever to get it
working w.r.t. history.

Other bugtrackers which were based on svn had a lot of issues with git because
of this.

------
storborg
I would love it if this widget eager-loaded the directory structure for a
couple levels (doesn't even need to load the commit data) so that it made the
navigation to a specific file/folder even faster.

~~~
tjarratt
Actually I don't think that's necessary - I'd much rather they focus on making
individual loads very fast, instead of pre-loading data. 9 times of out 10,
I'm not going to peruse the ENTIRE directory structure even one level deep, so
it should only get the data I want.

Also, they would need to store that, and I don't necessarily want my browser
storing my entire directory structure (and possibly file contents) for any
amount of time other than when I'm actually browsing it.

Try it out, it really is very fast without having to eagerly load anything at
all.

~~~
pjscott
They could build a page-transition graph: for each page, what are the links
that people are most likely to click? This could let them figure out what the
top one or two most common next-pages are, and those could be pre-loaded.

That would be more work for the GitHub guys, but I'm pretty sure it would
work.

~~~
entropie
Good idea, but _lots_ of work to implement it the right way.

~~~
stevenbedrick
Not to mention that the _vast_ majority of Github repositories don't have
enough traffic to properly build such a graph.

~~~
bdonlan
A reasonable fallback would be to look at the proportion of commits that touch
files under each directory - the more active a directory is, the more likely
it is to be of interest. Still probably not worth it in the majority of cases
though.

~~~
stevenbedrick
I like that idea quite a bit, actually- I'm envisioning a sort of "heat map"
UI, where each entry in a directory listing's background color is determined
by its commit frequency.

------
bodhi
And thankfully they didn't screw up the ability to open links in a new tab.

~~~
muitocomplicado
Agreed, would like to see this applied to Issues.

------
cool-RR
Great! I've been looking forward to this feature for a long time.

------
marknutter
I wonder if this is better than sammy.js

------
binaryfinery
A sliding UI is worth #2 HN spot? Wow.

~~~
olalonde
If I'm correct, it's interesting because the transition is done without using
a URL fragment (<http://url/#fragment>).

~~~
binaryfinery
FTFA: "Want more? Check out the HTML History API Demo and MDC's Manipulating
the browser history documentation. Facebook has blogged about their use of
this stuff, and Flickr has been doing it for months on their lightbox view."

So, its not even news. Unless, I suppose, the reader learned javascript in
2001 and feels they don't need to keep up on new things. That's the HN crowd
is it?

Fuck, I've been learning javascript for a _week_ and I know how to do this.

~~~
jonursenbach
It's interesting because it's been a major gripe on Github (at least in my
circle), and now that they finally have it, we're all happy.

Relax, dude.

