nls1729 / acme-code

Gnome Shell Extensions etc...
https://nls1729.github.io
GNU General Public License v2.0
66 stars 25 forks source link

Do Not Disturb Button 31 overwrites some of its own files? #57

Closed audreytoskin closed 5 years ago

audreytoskin commented 5 years ago

I package Do Not Disturb Button as an RPM for Fedora. I noticed after updating the package to DNDB version 31 (I was a little late getting the notification) that I was getting an error saying:

Extension "donotdisturb-button@nls1729" had error: Gio.IOErrorEnum: Error opening file “/usr/share/gnome-shell/extensions/donotdisturb-button@nls1729/correctClass.js”: Permission denied

and

Apr 18 13:14:02 mars.localdomain gnome-shell[3326]: Extension "donotdisturb-button@nls1729" had error: Gio.IOErrorEnum: Error opening file “/usr/share/gnome-shell/extensions/donotdisturb-button@nls1729/force.js”: Permission denied

Like most nonbinary software from an RPM package, the DNDB files are in a directory under /usr/share/ and are owned by root, but all the files had universal read permissions, so I thought this was weird. Just to see what would happen, I added execution permissions, then write permissions, and restarted GNOME Shell each time. After adding write permissions, the files changed, but DNDB started to function normally again. Then I removed the write and execution bits, but the left the files with their newly altered contents, and DNDB seems to continue to work.

...Is there a reason you decided to write the extension this way? RPM packages aren't normally supposed to change themselves as you use them, and I don't think I could get away with changing the file permissions in the finished package to read/write for everyone. If I use the self-edited version of those files in my RPM instead of the version downloaded from the GNOME Shell Extensions website, how reliably could I expect them to work on other people's computers?

nls1729 commented 5 years ago

@terrycloth

I did not know an RPM package was being provided for this extension. The reason the extension modifies itself is to avoid having to maintain more than one version of the extension.

With the release of Gnome Shell version 3.32 there was a change in the way you code a class that is based on a GObject. There is no ifdef in javascript. To be able to use the same version of the extension for Gnome shell versions before 3.32 I wrote code that modifies the extension as it is being loaded so it will work with the new GObject classes or the ES6 classes. Depending on the shell's version the "correct class" is constructed and imported. This requires writing the correct two lines of code into the file correctClass.js. Once the correctClass.js is written for the older versions it is used until the shell is updated to 3.32. When the shell is updated to 3.32 the code detects the new version and re-writes the correct two lines of code into the file correctClass.js.

The file force.js is re-written when the extension is installed from the GNOME Shell Extensions website or locally from a zip file.

"how reliably could I expect them to work on other people's computers?"

It would not be reliable. I can change the extension to work with only version GS 3.32 or later and upload it to the extension website for review. A new version should be available in a few days. I assume you want to provide an RPM for Fedora 30 which will be on 3.32.

Let me know if you want a new version.

audreytoskin commented 5 years ago

Ah, I think I understand. So the different versions is just one set of classes for GNOME >=3.32 and another set of classes for <3.32?

I thought for a moment of setting the package files to be owned by GDM, but that build is still getting permission errors too for some reason. Whatever, patching the package is probably the better solution anyway.

I could take care of the patching from my end, since it's mostly important for distro packages and not so much for users on the GNOME Extensions site --- if you can just tell me (and maybe mention in the README for possible future packagers) what the code for GNOME 3.30 and GNOME 3.32 should be.

nls1729 commented 5 years ago

I am assuming you are packaging for Fedora 30 which will use GS 3.32. I would prefer to upload a version 32 of the extension that supports only GS 3.32 to the website and have it reviewed. It would keep the extension website your upstream source. I can have the version 32 extension on the website in a few hours. It is a matter of removing some code and testing. Currently the review process usually takes only two or three days.

audreytoskin commented 5 years ago

Well yes, Fedora 30 with GNOME 3.32 is about to get its first stable release.

Fedora 29 (with GNOME 3.30) will continue to see updates for at least another 6 months. But I guess branching would only be necessary if you ever offered backported features or bugfixes, which I think doesn't happen often in the world of GNOME Shell extensions.

audreytoskin commented 5 years ago

So, I think you should go ahead with the GNOME-3.32-only version. But I think I'll build one last package of DNDB 31, patched for Fedora 29 / GNOME 3.30. When I allow DNDB to edit itself, the files that changed now look like this:

↪  cat ./correctClass.js 
const Me = imports.misc.extensionUtils.getCurrentExtension();
var DoNotDisturbButton = Me.imports.dndBtn;

↪  cat ./force.js
function getForce() { return false; };

Shall I just patch correctClass.js and force.js to look like that, or is there some variable other than the GNOME Shell version which determines those files' contents?

nls1729 commented 5 years ago

I would prefer to create a 3.30 version and a 3.32 version and submit them to the extension website. When they are reviewed and are available at the website I will contact you. There is a lot of code to remove and change to do it right. Since I am the person who gets the bug reports and issues I want it done right. I am sure you could do it but it would take me more time to identify and explain than to do it myself.

nls1729 commented 5 years ago

@terrycloth

Version 32 for GS 3.30 and version 33 for GS 3.32 are in the review queue at the extension website. They should be available for you in a few days.

audreytoskin commented 5 years ago

Great, thanks.

audreytoskin commented 5 years ago

DNDB v32 and v33 look good to me. The packages have built and will be pushed to the Fedora repos this week.

nls1729 commented 5 years ago

I don't see v32 and v33 as active on the extension website. Where did you get them?

nls1729 commented 5 years ago

Never mind. I just received an email that they were reviewed.