Comment 10 for bug 328980

The new one I opened requests that users be told to include their .xsession-errors in bug reports, which is a first step. So if a user encounters some xkbcomp error, and wants to report a bug about it, then he will include a portion of that error log file, and the resulting bug report will be more likely to be useful to developers, as THEY can find the xbcomp errors.

This one here is about displaying the xkbcomp errors directly to user himself, which should be our final goal. So if the user encounters some xkbcomp error, some window pops up and mentions the full error message, just as xkbcomp reported it on its standard error. The user himself can then decide whether that information is useful to him in resolving the issue all by himself, or whether he needs to file a bug report.

In short, the difference is between being told a file likely to contain the error message, or being told the error message itself. The first is easy to implement, and bug #430705 has a patch. The latter, which this bug here is about, is much more difficult.

I guess there are two general approaches. One would pass the error message using normal function call interfaces. As the function was originated by the xkbcomp execution in libxklavier, libxklavier would be the resonable place to pick up this error message and pass it up the chain. Therefore I marked all packages in the chain as affected, and am still not sure why exactly you believe that these are "not useful".

The second approach to fixing this bug here would be to have gnome-settings-daemon redirect its stderr somewhere else (like a pipe, a temporary file, or something similar) before calling out to libgnomekbd. Then, if something went wrong, it could use that captured error output and display it to the user. Feels a bit hackish to redirect stderr of the current process just to get error messages of some child forked off by some lib. But this solution could in fact be implemented in gsd alone, without libxklavier or libgnomekbd.

I guess I prefer the first approach, as it's much cleaner and more flexible in the long run.