Guillotine is a gnome extension designed for efficiently carrying out executions of commands from a customizable menu. Simply speaking: it is a highly customizable menu that enables you to launch commands and toggle services. For the most recent version (including compatibility for gnome 46) head over to the extension repository. No new updates will be published on Gnome-extensions.
Note: Binary files aren't shown on the web site. To see all files, please download the extension zipfile.
Version | Status |
---|---|
23 | Rejected |
22 | Rejected |
21 | Rejected |
20 | Rejected |
19 | Rejected |
18 | Active |
17 | Active |
16 | Active |
15 | Active |
14 | Active |
13 | Active |
12 | Rejected |
11 | Active |
10 | Rejected |
9 | Active |
8 | Rejected |
7 | Active |
6 | Active |
5 | Inactive |
4 | Inactive |
3 | Inactive |
2 | Rejected |
1 | Rejected |
If you really don't want to change the property name for timeouts, at lease remove the old one right before creating a new one. Want to fix that?
Lets see. Let's have a closer look to the switch: the constructor creates a timeout for "test()" (0 seconds, but it goes to some command queue and does not delay the overall loading process). Once "test()" is started, it immediately deletes the timeout (line 424). "test()" will start an async process that is followed up in "tested()". "tested()" sets up a new timeout. Now let's assume for a second, the timeout at the beginning of "test()" would not have been deleted but would rather continue to fire all 2 seconds. Instead I delete the timeout just before I create a new one in "tested()". And lets assume the async process started by "test()" would take 5 seconds. What would that end up in? Would deleting the timeout in "tested()" save anything? How does Gnome feel like when every 2 seconds there is one more background process running that stops after 5 seconds? Above has been the process flow: constructor --timeout--> test() --async--> tested() --timeout--> test() --async--> tested() --timeout--> test() --async--> tested() --timeout--> .... Now the user may use the switch. That is triggered in the function "switch()". It starts an async background job that is followed up in "switched()". The user using the switch may happen any time. Even if a `tested() -timeout-> test()` is running. That is why "switch()" deletes any running timeouts (line 312). Then it starts an async job to perform the switch followed up by a "switched()". "switched()" will run a "test()" (without timer) to verify the result of the switch. Again "test()" just performs an async job followed up in "tested()". So the flow is: `switch() --async--> switched() --> test() --async--> tested()`. In my world, I delete all timers at the beginning of switch. Then I perform 2 background jobs. lets for a second assume they take 5 seconds each. And lets assume I did not delete the timer of 2 seconds in "switch()" but I rather delete the timer in "tested()" just before I create a new timer in "tested()". So I will start a 10 second background job and every 2 seconds I will start another 5 second background job. How often will the user be able to use the switch before Gnome gives up? Now an attentive reader might ask: what if a user presses the switch too often and too fast? That's why the switch is disabled after it has been pressed until the test is done. Coming back to your question, if I am willing to add a line to delete any timer before I create a "new timer". Yes. Yes I will. Because this bullshit here is just bad for the actual users that are using this extension. But I will very clearly document that this change is performed purely due to a "reviewer" (that obviously did not understand a single line of the code) enforced this most stupid change.
Now that we are hopefully done with reviewing this extension, please go ahead and review https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/js/ui/popupMenu.js. Specifically have a look to line 902 in combination with line 1272. Now imagine a submenu inside a submenu.