User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060413 Ubuntu/dapper Firefox/1.5.0.1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060413 Ubuntu/dapper Firefox/1.5.0.1 not sure if this shoiuld be fixed in otherwise or in thunar at all, but since this create new document from xfdesktop rigth click menu silently fails when there's an error (same filename), unlike with directories. The file create job does not emit a signal on error, and thunar does not create new files using the job in the way xfdesktop does. Reproducible: Always
Created attachment 543 this makes xfdesktop creation work and does not seem to affect thunar's behaviour in any way in my limited testing
Hm, I'm not sure about the patch. Why does xfdesktop need the error? The job will already popup a message dialog saying that the file could not be created.
I'm not sure about the patch either, but the other way is to make xfdesktop create files as thunar does. xfdesktop makes a file create job directly while thunar calls it via a thunar_application. Not sure why but this makes xfdesktop not get the error popup.
I guess xfdesktop does not connect the interactive job signals for the creat job. CC'ing Brian.
Yeah, it's possible I left some of the error handling for later, since a failed creation isn't really that big a deal. I'll look into it when I get a chance.
I'd say xfdesktop should connect the interaction signals, so it's consistent with Thunar wrt the user interaction on file creation. BTW: Why should file creation in xfdesktop fail? ~/Desktop does not exist?
(In reply to comment #6) > I'd say xfdesktop should connect the interaction signals, so it's consistent > with Thunar wrt the user interaction on file creation. BTW: Why should file > creation in xfdesktop fail? ~/Desktop does not exist? No idea why. If ~/Desktop doesn't exist, it gets created. If that fails, we give an error message on startup. Though I guess if you went and deleted ~/Desktop while xfdesktop is running, it wouldn't be so thrilled. Otherwise, the only reasons I can think of it failing are... um... if the FS got corrupted and the kernel remounted read-only. Or if the FS filled up. Or if it's NFS-mounted, and the network died. Or if you tried to put invalid chars in the filename. I dunno. Regardless, I should check the error return, so that's an oversight on my part.
as I mentioned in the orginal entry - same filename. IOW just create new document and don't bother changing the name from New Empty File, then repeat :) There could be other reasons though as well... So probably xfdesktop should connect to the ask signal as thunar does. Although it is weird not getting the error signal too on error, are interactive and error signal supposed to be exclusive? Not sure if every job is supposed to emit the error signal or just noninteractive ones...
The error signal is only emitted on errors that cannot be skipped or don't make sense to be skipped, as the error signal handlers are supposed to cancel the job. I have to document that.
Not sure what's wrong here. Xfdesktop already is connecting to the job's 'error' signal. It was originally ignoring the GError return val of thunar_vfs_create_file(), but I fixed that, and it still shows no error. Benny, feel free to look at xfdesktop-file-icon-manager.c:1720 if you want.
The cause is that thunar-vfs does not emit an 'error' signal in this case. As Benedikt said in a previous comment it is only emmitted for non-cancellable errors I think. In thunar-vfs-creat-job for this error rather the interactive jobs' 'ask' signal is emmited so the connecting app gets error messages which it can create dialogs from. My patch worked around this by emmitting an 'error' along with the interactive signals but apparently that's not the way to do it, and needs to be documented.
Ok, should be fixed.
Yep, looks good.