GNOME Bugzilla – Bug 662288
Fails to execute program when Glade UI file has unsaved changes
Last modified: 2020-11-06 20:22:15 UTC
From the original report: When editing a project which contains Glade UI files, if a Glade UI file is changed and is not explicitly saved and either the Run menu's Execute or the Tool bar's 'Gear' Execute button is pressed, the changed UI file is auto-saved, but the program is not started. Once this happens, the program can still be run with Run menu's Debug Program selection, but the non-debug Execute no longer functions. To Execute again, Anjuta must be quit and restarted. (I could reproduce this with current master)
As the run plugin is saving the file I guess the problem is that it afterwards tries to build the problem (to have it up-to-date) but that somehow fails as you cannot build a glade file. The code is in plugins/run-program/*
Thanks for finding the way to get this bug. It is perhaps the bug reported by John on the mailing list a few time ago. I will look at this, it shouldn't be difficult to fix. Normally, I build the whole project not the saved file so it shouldn't matter if it's a glade file.
This is due to an error in the glade plugin. The implementation of ianjuta_file_savable_save of the glade plugin doesn't emit the saved signal at the end. Then the build plugin is waiting that all files are saved before checking if the project is up to date and the run plugin is waiting to know if the project is up to date before running it. The glade plugin is emitting the signal "update-save-ui" instead, should we consider that it replaces the "saved" signal? If yes we need to update the documentation. Then, this interface is a bit fragile because a bad implementation can break another plugin. I'm not sure we can do really better if someone has an idea I'm interested. By the way, I think the document manager doesn't emit the "saved" signal neither.
Hi! > This is due to an error in the glade plugin. The implementation of > ianjuta_file_savable_save of the glade plugin doesn't emit the saved signal at > the end. Then the build plugin is waiting that all files are saved before > checking if the project is up to date and the run plugin is waiting to know if > the project is up to date before running it. OK, I will fix this. > The glade plugin is emitting the signal "update-save-ui" instead, should we > consider that it replaces the "saved" signal? If yes we need to update the > documentation. No. update-save-ui has a different purpose and I wouldn't want to use it for other things. update-save-ui is emitted when the files goes from saved to changed, too. > Then, this interface is a bit fragile because a bad implementation can break > another plugin. I'm not sure we can do really better if someone has an idea I'm > interested. Well, I think we have other things that could break other plugins. But we should make clear that certain interface methods need to emit signals. > By the way, I think the document manager doesn't emit the "saved" signal > neither. That should be fixed, too, I guess.
(In reply to comment #4) > > This is due to an error in the glade plugin. > OK, I will fix this. I have already a fix for this. It's a bit annoying because you have to create a GFile object just for getting the right argument but it's quite obvious. I can commit it if you prefer. > Well, I think we have other things that could break other plugins. But we > should make clear that certain interface methods need to emit signals. The documentation is quite clear about this.
Hi! > > > This is due to an error in the glade plugin. > > OK, I will fix this. > > I have already a fix for this. It's a bit annoying because you have to create a > GFile object just for getting the right argument but it's quite obvious. I can > commit it if you prefer. Sure, commit it, I guess it's pretty obvious to fix. > The documentation is quite clear about this. OK, maybe I should read it next time...
(In reply to comment #6) > > The documentation is quite clear about this. > OK, maybe I should read it next time... You have read it because the saved signal is emitted when the save fail. Anyway, I have fixed this bug in the glade plugin in both master and gnome-3-2 branch. I haven't fixed the document manager though, so I'm keeping the bug open but this shouldn't be seen as a bug by the user. One solution could be to not implement IAnjutaFileSavable in the document manager. By the way, it's not clear to know what GFile should be used in the saved signal emitted in the document manager, or should it emits one signal for each file?
*** Bug 660618 has been marked as a duplicate of this bug. ***
Hi! > I haven't fixed the document manager though, so I'm keeping the bug open but > this shouldn't be seen as a bug by the user. One solution could be to not > implement IAnjutaFileSavable in the document manager. By the way, it's not > clear to know what GFile should be used in the saved signal emitted in the > document manager, or should it emits one signal for each file? Hmm, the docman implementation (is it used? not sure?) calls the ianjuta_savable_* methods on each of the doc widgets which should emit the signal (if correctly implemented). I think that's correct.
(In reply to comment #9) > Hmm, the docman implementation (is it used? not sure?) calls the > ianjuta_savable_* methods on each of the doc widgets which should emit the > signal (if correctly implemented). I think that's correct. Yes, the docman implementation is used at least in the tools and subversion plugin but the saved signal is not used in this case. It's probably not right, because it means that the tools plugin could run a command while all source files are not saved. I think the docman implementation is not correct, the saved signal has to be emitted by the object implementing the function. Else how could we know which object emit the signal? Currently, if the object is a document manager we have to list all documents and connect to all saved signals. At that point, it isn't more difficult to directly call ianjuta_file_savable_save on each document. Then as we have to know if the object is a document manager or not to use the function correctly. It would make more sense to rather have a save function in the IAnjutaDocumentManager interface which doesn't emit a saved signal or better emit it when all documents have been saved and without a GFile arguments or having a list of GFile saved.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/anjuta/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.