I completely agree that we need new tools. Interesting overview, and the searches seem very fast for such a huge code base - good work! Curious, could you reveal the idea behind the layout algorithm a bit more? The most obvious choice would be to just position pixels based on the file/directory structure, but there must be a reason you instead do it somewhat chaotically.
@@emilsprogrammingviz1811 it walks the file tree, picking random locations within a certain distance from a center point associated with the parent directory, looking for an empty spot. It has some heuristics for picking suitable radii based on the volume of files in subdirectories. It's maybe ~100loc, but works pretty well.
@@emilsprogrammingviz1811 this method is a pretty simple and minimal amount of code, it works well, and it's fast. If I did something like a force-directed graph drawing algo, maybe it would be a little prettier but it would be much more expensive, especially on big codebases. This is almost instant.
@@charlesrosenbauer3135 That's cool, but what I tried to ask was rather: 1. Is there an advantage of this fuzzy organic-looking layout over a more box-based layout where files in the same directory are always next to each other? Apart from the "coolness" factor of course :) And 2. Could you describe the algorithm used? Or maybe it's a trade secret :)
This is cool and it definitely seems useful for getting oriented in large codebases c: One thing I'm curious about, though, it does it provide anything that couldn't be done by parsing ripgrep output with a nice UI? (Not trying to cast doubt on your work, just genuinely curious)
Cool tool :)
Tbh I would just use it for the fun if it -- the UI looks vey nice
Nice
I completely agree that we need new tools. Interesting overview, and the searches seem very fast for such a huge code base - good work! Curious, could you reveal the idea behind the layout algorithm a bit more? The most obvious choice would be to just position pixels based on the file/directory structure, but there must be a reason you instead do it somewhat chaotically.
@@emilsprogrammingviz1811 it walks the file tree, picking random locations within a certain distance from a center point associated with the parent directory, looking for an empty spot. It has some heuristics for picking suitable radii based on the volume of files in subdirectories. It's maybe ~100loc, but works pretty well.
@@emilsprogrammingviz1811 this method is a pretty simple and minimal amount of code, it works well, and it's fast. If I did something like a force-directed graph drawing algo, maybe it would be a little prettier but it would be much more expensive, especially on big codebases. This is almost instant.
@@charlesrosenbauer3135 That's cool, but what I tried to ask was rather: 1. Is there an advantage of this fuzzy organic-looking layout over a more box-based layout where files in the same directory are always next to each other? Apart from the "coolness" factor of course :)
And 2. Could you describe the algorithm used? Or maybe it's a trade secret :)
This is cool and it definitely seems useful for getting oriented in large codebases c: One thing I'm curious about, though, it does it provide anything that couldn't be done by parsing ripgrep output with a nice UI? (Not trying to cast doubt on your work, just genuinely curious)
When looking at the UI, can you also import samples and arrange them in tracks?
how is the search so fast? this is so cool!
impressive tui, what library?
@@ryanyoung8886 custom thing I built in C/SDL2. Font is Code Page 437.
@@charlesrosenbauer3135 thanks. will be following this project