Closed p-e-w closed 6 years ago
Hei,
I'm currently getting the same error using GNOME Shell 3.14.4.
Are there any updates on this issue / will there be a fix for it?
Are there any updates on this issue / will there be a fix for it?
Not from me most likely, as I don't run GNOME Shell 3.14 and have no idea what line of code is causing this problem. If this is still unresolved a few months from now I am probably just going to remove support for 3.14.
I think it is caused by GLib.spawn_async_with_pipes in spawnWithCallback (utilities.js) which expects "flags"
https://people.gnome.org/~gcampagna/docs/GLib-2.0/GLib.SpawnFlags.html
--- /tmp/button.js 2017-05-14 21:58:45.816321799 +0200
+++ button.js 2017-05-14 21:56:51.499841579 +0200
@@ -74,7 +74,7 @@
this._updateRunning = true;
try {
- Utilities.spawnWithCallback(null, [this._file.get_path()], null, 0, null,
+ Utilities.spawnWithCallback(null, [this._file.get_path()], null, GLib.SpawnFlags.DEFAULT, null,
Lang.bind(this, function(standardOutput) {
this._updateRunning = false;
ah sorry. Here is the real fix.
Gio.FileMonitorFlags.WATCH_MOVES is only available since GLib Version 2.46
https://lazka.github.io/pgi-docs/Gio-2.0/flags.html#Gio.FileMonitorFlags.WATCH_MOVES
That's where the "undefined" message originated from...
--- /tmp/extension.js 2017-05-15 19:15:14.436073897 +0200
+++ extension.js 2017-05-15 19:17:48.799620671 +0200
@@ -53,7 +53,12 @@
GLib.spawn_sync(null, ["chmod", "+x", scriptPath], null, GLib.SpawnFlags.SEARCH_PATH, null);
}
- directoryMonitor = directory.monitor_directory(Gio.FileMonitorFlags.WATCH_MOVES, null);
+ if ( Gio.FileMonitorFlags.WATCH_MOVES !== undefined ) {
+ directoryMonitor = directory.monitor_directory(Gio.FileMonitorFlags.WATCH_MOVES, null);
+ } else {
+ directoryMonitor = directory.monitor_directory(Gio.FileMonitorFlags.SEND_MOVED, null);
+ }
+
}
@p-e-w I just tested the fix that @vaporup suggested and I can confirm that it's working.
Will this be fixed then?
I honestly don't see an "official" fix coming soon since @p-e-w wasn't active on Github in the past few months. 😞
@vwugd97 Let's wait a bit. I have no experience with GNOME shell development but I am willing to help with a fork. Or @p-e-w gives someone else write permission to pull fixes and stuff.
I'm still a bit on the fence about actually merging @vaporup's fix. To be honest, including 3.14 in metadata.json
was more of an oversight than anything else. I never had any real intention to support 3.14, which is now well over three years old and long precedes GNOME's extension API stability announcement.
So in a sense, the intended "fix" is to just remove 3.14 from the list of supported versions. Obviously, some people still use 3.14 and want Argos to work for them but then the patch introduces an ugly "version switch" that Argos has avoided until now. Fortunately, the patch is easy to apply locally so I don't feel much pressure to make it part of an official release.
As for project activity, I'm not a fan of the idea that a project is dead unless it sees regular updates. Argos is stable and feature complete, and I use it every single day without issues. I'm interested in adding some of the functionality BitBar is working on (stdout streaming) to Argos eventually, but likely not anytime soon and I don't consider any of the open bugs (including this one) nearly problematic enough to warrant a hotfix. But the only way this project will ever be abandoned is if I stop using Argos myself, which seems unlikely because it is very useful to me. Feel free to fork and experiment!
@p-e-w good to hear back from you! I didn't want to suggest that the project is dead. We just didn't get any reaction from you in almost a year and you weren't active on GitHub in the past few weeks.
Besides that I'm also using Argos every day and it's working great.
What do you mean with
the patch introduces an ugly "version switch" that Argos has avoided until now
?
The patch looks fine to me and fixes the problem. If you really don't want to add it, then I'd suggest you just remove 3.14 from the supported versions.
This is now fixed on master. Thanks again to @vaporup for identifying the source of the problem.
Several people have reported that in GNOME Shell 3.14, this error is thrown: