GNOME Bugzilla – Bug 87056
cannot set custom commands
Last modified: 2004-12-22 21:47:04 UTC
The "File types and Internet Services" control panel does not save custom commands for non-leaf categories. Steps to reproduce the problem: 1. Bring up the "File types and Internet Services" dialog, also known as "gnome-file-types-properties". 2. Click on the expansion arrow next to "Documents" to show its subcategories. 3. Double click on "Plain Text" to bring up an "Edit file category" dialog for this subcategory. 4. Uncheck the "Use parent category defaults" toggle if it is checked. In my case, this is already unchecked. 5. Set the "Default action" option menu to "Custom" if it is set to something else. In my case, this is already set to the desired value. 5. Type "gnuclient -q" (without quotes) in the "Program to run" field. 6. Click "OK". 7. Double click on "Plain Text" again. Actual Results: The "Program to run" field has reverted to being empty. Expected Results: The "Program to run" field should have retained the "gnuclient -q" value set earlier. How often does this happen? Every time. Consistently repeatable. Additional Information: grep'ing through ~/.gconf shows no mention of "gnuclient", so it either the change was never actually set out to gconfd, or the bug is in gconfd for failing to store the updated value.
Setting a custom command for leaf file types used to work, which is why I originally reported this as a problem with non-leaf categories. However, I just tried again, and I cannot even set custom commands for leaves. No custom command is saved *anywhere*. Updating summary.
Jody: is this what you've been trying to fix? :)
That is what I am working on now. Mime types should work. Categories are screwed and basicly useless give me another 2 days.
Categories have basicly been lobotomized for now. However, the rest should work smoothly.
I still cannot set custom commands for many leaf MIME types. There is some variation, so I'm not sure if these are all the same bug or distinct problems. Representative examples include: - text/plain - "Viewer Component" menu is insensitive and set to "View as Text" - "Default action" menu is insensitive and set to "Custom" - "Program to Run" field is insensitive - audio/basic - "Viewer Component" menu is insensitive and set to "None" - "Default action" menu is insensitive and set to "Custom" - "Program to Run" field is sensitive, but forgets typed-in value as soon as dialog is dismissed - audio/x-ulaw - "Viewer Component" menu is insensitive and set to "None" - "Default action" menu is sensitive and set to "Custom" - "Program to Run" field is sensitive, but forgets typed-in value as soon as dialog is dismissed In each case I am unable to set a custom command.
Updated version details to reflect the Ximian snapshot in which I'm now seeing these problems.
Hmm I can replicate the total disabling of text/plain. I'll look at that now. However, I can not replicate the losing of custom commands for the others. Are you entering a real application ? Putting /usr/bin/xmms worked for me.
Thanks for giving this your attention, Jody. > Are you entering a real application ? Yup. I tried both "xmms" and "/usr/bin/xmms", and the value was forgotten in both cases. You might be seeing different behavior if you are using a different snapshot. As noted in the "Version" field, I've got Ximian's 2.0.0.0.200208040535 snapshot. On another box I use regularly, the 2.0.0.0.200207300226 snapshot behaves differently: it remembers commands given as absolute pathnames ("/usr/bin/xmms"), but forgets ones given as just a command ("xmms").
I'm working out of CVS and nothing has changed between 7/30 and 8/04 Something fishy is going on. The case of just 'xmms' was slightly broken in that it would be converted into $cwd/xmms but I've got a fix for that that will go in tonight.
Here's some new detail regarding the forgotten typed-in custom commands. I'm seeing an "Invalid application" warning when I click "OK". This is in a current CVS checkout, built for debugging. The warning is coming from function mime_type_info_save() on line 240 of mime-type-info.c. Examining the logic in mime_type_info_save(), I see that it is trying to validate the *info->default_action structure. In this particular case, that structure has the following value: *info->default_action = { id = 0x8214c00 "698fcb75-e3eb-4eed-8261-bc2f4ed60408", name = 0x80c11c8 "Custom video/x-msvideo", command = 0x80d50d8 "", can_open_multiple_files = 0, expects_uris = GNOME_VFS_MIME_APPLICATION_ARGUMENT_TYPE_PATHS, supported_uri_schemes = 0x0, requires_terminal = 0, reserved1 = 0x0, reserved2 = 0x0 } Two weird things about this. First, the "command" field is an empty string, rather than "/usr/bin/xmms" as I typed. That, at least, is the proximate cause for the warning. Second, the "name" field is "Custom video/x-msvideo", even though I was setting this for audio/basic. Full stack trace at the point where that warning is produced:
+ Trace 25914
1) I have no idea why you are editing one things and saving another 2) Having app == NULL would certainly cause problems but that should not be happening. We're not going to solve this before I release tonight. Try a clean build wit hthe 2.0.1 release tommorow and we'll see if we can track it.
I hate to say it, but I think I've tracked the forgotten-custom-command problem down to a bug in gcc. I never like to blame the compiler, especially when optimizations are not even turned on. But consider the following events, which I have just observed in my debugger: Clicking the OK button eventually results in a call to store_data(), which in turn calls mime_edit_dialog_get_app(). In mime_edit_dialog_get_app(), we call gnome_file_entry_get_full_path(), which correctly returns "/usr/bin/xmms". This is on line 674 of mime-edit-dialog.c. So far, so good. On line 687 of mime-edit-dialog.c, we extract the basename of this command into base_cmd. base_cmd now points to the string "xmms". Everything is still correct. The very next line (688) tests base_cmd for equality with NULL. The test succeeds, even though it is quite obvious that it should fail. Having incorrectly concluded that the command has a NULL basename, the code takes the wrong control path and sets base_cmd to the empty string (""). And it's all pretty much down hill from there. Jody, am I crazy, or has this happened to you and I before? I seem to remember some other bug that I claimed was trivially reproducible but you could not make happen. That one turned out to be a gcc bug too.
Aaaggh! I found it! Take a look at that basename checking code. Take a really close look: if (base_cmd == NULL); base_cmd = g_strdup (""); Do you see what I see? The indentation is lying -- there's an extra semicolon after the "if" predicate! Therefore, the g_strdup() replacement happens wether base_cmd is NULL or not. Aaagh!
Created attachment 10287 [details] [review] patch to fix forgotten custom command
Hmm, that does not explain the behavior you are seeing. It is definitely a bug, and I've patched it. However, a couple of lines lower there is res->name = base_cmd; if (res->name != NULL && *res->name) { ... } else { /* fail safe to ensure a name */ g_free (res->name); res->name = g_strdup_printf ("Custom %s", mime_type); } All the bug did was disable a a little flourish to make the custom command name prettier. Does this actually change anything for you ?
> Does this actually change anything for you ? Yes, it actually does. With that fix applied, when I type something in the custom field, click "OK", and then bring that dialog back up, the basename of the command I typed appears in the custom field. Previously, the custom field was blank. So this certainly does change something for me. You know, I'm not convinced that this fiddling with basenames is really appropriate, though. If what I *originally* typed was a non-absolute command name ("xmms"), then that command should be found using $PATH at the time a file is launched. If what I originally typed was an absolute command name ("/usr/bin/xmms"), then the full absolute path should be retained and should be what is presented to the user. I might have typed "/usr/bin/xmms" because I wanted to explicitly avoid using a bogus version in "/usr/local/bin/xmms". If the dialog reduces that to just "xmms", I don't have any confidence that it will run the command I want it to run.
The base was used to _name_ the command. That name is not visible in the ui. The command itself is store differently.
Jody, looking at the code, I can see why you'd be suprised that this makes any difference. I don't have a complete answer for you, but I can tell you that without that fix, my debugger shows that I am not executing the code you cited: res->name = base_cmd; if (res->name != NULL && *res->name) ... Rather, I'm showing ptr != NULL on line 46, which means that I'm running this code instead: g_free (cmd); g_free (base_cmd); res = gnome_vfs_application_registry_get_mime_application (ptr->data); That's the code that's giving me back a structure with name == "Custom video/x-msvideo" and command == "". Perhaps this is some old junk in my "user.applications" file? Yes, I see it there. I have a bogus user.applications entry with that name, and whose command is empty ("command="). So once the basename gets mistakenly nulled out, this entry looks like a match, since it also has a null command. This must be junk left over from earlier bugs or something. OK, so that's it then. I have some local cruft in my config, and there was also a genuine bug with that extra semicolon. cruft + bug == the behavior I was seeing. This also explains why you were not seeing this behavior, since presumably you had the same bug but not the local cruft.
Verifying as fixed using GNOME2 as shipped with Red Hat 8.0. This has been working correctly for a while now.