Remember the "One Laptop Per Child" project, that developed a low-cost computer for children in developing countries?
-
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.)
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 itAs a quick prototype, I wrote a li'l Bash script that does some of these things. It makes heavy use of #nix and #nixpkgs:
view-source-button
view-source-button - A script that allows you to start tinkering with software
Codeberg.org (codeberg.org)
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.)
@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. -
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 itAs a quick prototype, I wrote a li'l Bash script that does some of these things. It makes heavy use of #nix and #nixpkgs:
view-source-button
view-source-button - A script that allows you to start tinkering with software
Codeberg.org (codeberg.org)
I enters a "dev shell" with the required tools already in the PATH, and even sets up a Git remote to start contributing.
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.
-
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 itAs a quick prototype, I wrote a li'l Bash script that does some of these things. It makes heavy use of #nix and #nixpkgs:
view-source-button
view-source-button - A script that allows you to start tinkering with software
Codeberg.org (codeberg.org)
I enters a "dev shell" with the required tools already in the PATH, and even sets up a Git remote to start contributing.
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".
-
The python IDE. Basically you'd have to make the entire system in an interpreted language. Whatever that may be.
-
-
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".
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 itAs a quick prototype, I wrote a li'l Bash script that does some of these things. It makes heavy use of #nix and #nixpkgs:
view-source-button
view-source-button - A script that allows you to start tinkering with software
Codeberg.org (codeberg.org)
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`?
-
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 I guess that this idea was inspired by smalltalk, which usually comes with a combined desktop/IDE.
-
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
@blinry Everything in me currently screams "Smalltalk"
-
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 itAs a quick prototype, I wrote a li'l Bash script that does some of these things. It makes heavy use of #nix and #nixpkgs:
view-source-button
view-source-button - A script that allows you to start tinkering with software
Codeberg.org (codeberg.org)
I enters a "dev shell" with the required tools already in the PATH, and even sets up a Git remote to start contributing.
@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.”
-
@blinry Everything in me currently screams "Smalltalk"
@dwardoric @blinry I was thinking Lisp Machines, but, nevertheless, very cool project! :3
-
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
-
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
@blinry this looks extremely useful / promising!
-
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 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.
-
@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.”
@HeptaSean Yeah, that doesn't really seem possible to figure out. For non-web applications, maybe the button could show you the tree of processes that are involved in your "current application", and allow you to pick?
For expert users, I guess they could provide the name of the desired component directly.
-
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 itAs a quick prototype, I wrote a li'l Bash script that does some of these things. It makes heavy use of #nix and #nixpkgs:
view-source-button
view-source-button - A script that allows you to start tinkering with software
Codeberg.org (codeberg.org)
I enters a "dev shell" with the required tools already in the PATH, and even sets up a Git remote to start contributing.
@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? -
@blinry Might I suggest using `nix eval --raw nixpkgs#$PKG --apply 'pkg: …'` to avoid repeatedly invoking `nix eval`?
@korenchkin Oh cool, that would speed things up a bit for sure!
-
@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.@TerryHancock Ohh, I didn't know it was still (kind of) maintained!
-
@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.
@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…
