Remember the "One Laptop Per Child" project, that developed a low-cost computer for children in developing countries?

So if you've been wondering why I'm into obscure bugs this week like:

- Figuring out why I'm missing icons in pavucontrol https://chaos.social/@blinry/116081436255395069

- Improving the man page of a Nix CLI helper https://github.com/nix-community/nh/pull/568

- Reporting broken shortcuts in the Firefox DevTools https://bugzilla.mozilla.org/show_bug.cgi?id=2017113

… it was testcases for tying out this "View Source Button".

You'd roughly need to:

- Figure out which program is currently focused
- Figure out the Git repo of this software
- Clone it into a temporary directory
- Set up the required tools to start hacking on it and compile it

As a quick prototype, I wrote a li'l Bash script that does some of these things. It makes heavy use of #nix and #nixpkgs:

https://codeberg.org/blinry/view-source-button

I enters a "dev shell" with the required tools already in the PATH, and even sets up a Git remote to start contributing.

Remember the "One Laptop Per Child" project, that developed a low-cost computer for children in developing countries? I was always amazed by a certain feature: The "View Source" button.

When you pressed it, the source code for the currently running application would open. This was supposed to encourage tinkering with the software on your device!

I've been pondering what it would take to build that button on modern machines. Has anyone seen something like that?

(Prototype in next toot.)

It's been fun, it feels like a new superpower to "quickly fix something and send a PR". It's also a super dangerous rabbit hole generator, because now that it's easy to fix stuff, it's very tempting to do so…

My prototype has some rough edges:

It clones the latest commit, which doesn't always compile using the #nixpkgs setup (but it seems reasonable to check whether the bug is still there).

And invoking the phases of the nixpkgs stdenv manually can be tricky. https://nixos.org/manual/nixpkgs/stable/#sec-building-stdenv-package-in-nix-shell

You'd roughly need to:

- Figure out which program is currently focused
- Figure out the Git repo of this software
- Clone it into a temporary directory
- Set up the required tools to start hacking on it and compile it

As a quick prototype, I wrote a li'l Bash script that does some of these things. It makes heavy use of #nix and #nixpkgs:

https://codeberg.org/blinry/view-source-button

I enters a "dev shell" with the required tools already in the PATH, and even sets up a Git remote to start contributing.

@blinry Everything in me currently screams "Smalltalk"

It's been fun, it feels like a new superpower to "quickly fix something and send a PR". It's also a super dangerous rabbit hole generator, because now that it's easy to fix stuff, it's very tempting to do so…

My prototype has some rough edges:

It clones the latest commit, which doesn't always compile using the #nixpkgs setup (but it seems reasonable to check whether the bug is still there).

And invoking the phases of the nixpkgs stdenv manually can be tricky. https://nixos.org/manual/nixpkgs/stable/#sec-building-stdenv-package-in-nix-shell

For myself, ideally, the script would set up a #Nix flake with all dependencies in it, and activate it using direnv. Which would probably mean transforming the nixpkgs package into a flake?

The script could also give you some aliases to run the nixpkgs phases like configure, patch, or build, from your current shell – I like using the fish shell, but the stdenv assumes bash. I haven't found a reasonable way to invoke the phases "in a subshell"… Getting errors like this: https://github.com/NixOS/nix/issues/15282

Remember the "One Laptop Per Child" project, that developed a low-cost computer for children in developing countries? I was always amazed by a certain feature: The "View Source" button.

When you pressed it, the source code for the currently running application would open. This was supposed to encourage tinkering with the software on your device!

I've been pondering what it would take to build that button on modern machines. Has anyone seen something like that?

(Prototype in next toot.)

@blinry Not sure if I'm thinking too complicated here, but doesn't it get ever more complicated what exactly to show there?

If I'm currently looking at a web app that shows some data retrieved from a server-side backend in a browser whose UI is written in (say) Python calling one of the dominant rendering engines and one of the dominant Javascript engines, which of the sources do I show on “View Source”?

It could be anything from the operating system kernel via the CPython or the Javascript runtime to the web app or its server-side counter-part that could be considered most interesting and answering the question: “Oh, I wonder how this works.”

You'd roughly need to:

- Figure out which program is currently focused
- Figure out the Git repo of this software
- Clone it into a temporary directory
- Set up the required tools to start hacking on it and compile it

As a quick prototype, I wrote a li'l Bash script that does some of these things. It makes heavy use of #nix and #nixpkgs:

https://codeberg.org/blinry/view-source-button

I enters a "dev shell" with the required tools already in the PATH, and even sets up a Git remote to start contributing.

@blinry Might I suggest using `nix eval --raw nixpkgs#$PKG --apply 'pkg: …'` to avoid repeatedly invoking `nix eval`?

@blinry
Yeah, I've often wondered about that myself. I understand that you can install the Sugar DE on Linux, generally, and get that "view source" button. But it seems specifically designed to oppose multitasking, too.

https://en.wikipedia.org/wiki/Sugar_(desktop_environment)

@blinry Well. Several idea pop up. The currently focused Application is easy to find. With something like apt-file you can find the package, download the source package and show that. That won't be much fun.

If you were to limit it to python-Apps, showing the directory of the python-file seems easy. Then you will want an overlay fs to not destroy the installed App, but write changes to "disk" and rerun the application from there.

@TerryHancock Ohh, I didn't know it was still (kind of) maintained!

@blinry
Is it possible to find out what shared library is responsible for some windows? I often wonder which project is actually behind the file browser or print dialog that I'm using and whether I can change it. My understanding is that these are usually delegated to an SO?

Remember the "One Laptop Per Child" project, that developed a low-cost computer for children in developing countries? I was always amazed by a certain feature: The "View Source" button.

When you pressed it, the source code for the currently running application would open. This was supposed to encourage tinkering with the software on your device!

I've been pondering what it would take to build that button on modern machines. Has anyone seen something like that?

(Prototype in next toot.)

@blinry

Or have the entire system built around being interpreted like Python or C#. Maybe C# would even be a better option as it's JIT compiler is better in my eyes. And it integrates better with that XML based GUI definition language Microsoft had.

Edit: WPF XAML was it.

@snaums Yeah, I also thought this should work well with tools that do a "reverse lookup" from your binary to a software package!

You mean it won't be fun because you can't easily modify the source code and then use it immediately? That's probably right…