xkbcomp errors should be displayed

I just confirmed that the stderr of the xkbcomp invocation is redirected to /dev/null, so error messages are indeed completely lost.

A fist step towards sensible error messages would probably be to redirect stderr in libxklavier in such a way that it can be directed into the syslog. This would involve no change to interfaces or other packages, and while being far from optimal, would give users a realistic chance to see their error messages.

Once we have the message available in the current process, and sent to syslog, we could augment the interfaces to pass the message up to gnome-settings-daemon and incorporate it into the error message.

to send to bugzilla.gnome.org by somebody having interest in this change

could you describe a way to trigger the error? do you get that at the session start or when using the capplet?

> could you describe a way to trigger the error?

I hit this in bug #327963. So a way to reproduce is this:
1. set keyboard layout to "Germany Macintosh, no dead keys"
2. set keyboard model to "MacBook / MacBook Pro (Intl)"

This might only work until someone fixes #327963, though. After that, you might have to revert their change or introduce some artificial problem with the xkeyboard-config data. Or use some unfixed aspect of bug #67188.

> do you get that at the session start or when using the capplet?

Both. When using gnome-keyboard-properties it happens, and when leaving the broken settings, it happens again at session start.

Starting with Jaunty, error messages from xkbcomp end up in ~/.xsession-errors where they can be inspected by the technically inclined user.

This is probably due to the following change in gnome-settings-daemon:
http://git.gnome.org/cgit/gnome-settings-daemon/commit/?id=015e92a82c6bd19b4d3fcbcbe6ebf950790aba24
This changeset might proove difficult to backport to intrepid, though, because it builds on the following one:
http://git.gnome.org/cgit/gnome-settings-daemon/commit/?id=3be2d805d369f0812882e18792e51cb1bd8bf1c5
So either both would need to be backported, or the second argument of daemon(3) should be changed to 1 to give similar behaviour. All assuming that you want to backport this kind of usability fix in the first place.

For the not so technically inclined user, finding the error message is probably still rather difficult. As an alternative, I'd suggest changing the error dialog generated by the activation_error function in plugins/keyboard/gsd-keyboard-xkb.c of the gnome-settings-daemon sources. That error message already tells users to include some information if they wish to file a bug, namely the result of "xprop -root | grep XKB" and the result of "gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd". In my opinion, it would make a lot of sense to ask them for the contents of ~/.xsession-errors as well. Will the gnome-settings-daemon admins from ubuntu tale it from here, or should I file a separate bug for the change of this error message? Do you need a patch?

I'll take the two months without reply from the ubuntu maintainers of gnome-settings-daemon as a "No" to my question wherther they'd take it from here. So I just filed a separate request, bug #430705, about mentioning ~/.xsession-errors in the error message after a failed xkb activation. Let's hope this will make it into karmic...

should this bug be closed now? the lack of reply is a manpower issue and due to the fact that nobody in the ubuntu desktop team has special interest for keyboard issues

I personally would wish for the error message to be displayed to the user in a dialog window, not only logged in some obscure file. So my original request hasn't been dealt with in full.

However, I believe that taking the lack of manpower into account, a solution at the distro level is at the moment rather unlikely. The upstream gnome report might be better suited to deal with this.

If you can resolve this as LATER, that would be great. If not, decide for yourself whether keeping this open is in any way useful to getting a proper solution implemented and included into Ubuntu in the long run.

Closing the libxklavier and libgnomekbd tasks they are not useful, how this bug is different of the new one you opened about changing the user dialog?

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.

not sure I agree with displaying those errors to users, that would just be non understandable dialogs, those technicals details should go in bugs and not be showed in user's face directly where they are of no use

So you say that an error message containing some technical information is worse than one with almost no information at all? I'm sure I disagree for myself, as I find an error message like 'No Symbols named "mac_nodeadkeys" in the include file "macintosh_vndr/de"' (from bug #327963) to be both understandable and useful, and to be a good description of the cause of the error, not a mere "technical detail". But I have to concede that I'm no average user, and my ideas of how they would react to such a message might be completely wrong.

Of course, I agree that it would be even better if such error messages would not occur in the first place, and bug #327963 is aiming at avoiding the error message I just quoted. That might not be the only possible error, though.

the issue is that the current dialog message is of no use, the fix would not be to add technical informations but to change it to be clear to an average user and give useful clue on what to do not requiring techinical skills

The core problem this is trying to address is that currently errors occur in the underlying code, but due to the nonspecific error message, the bugs are all getting lumped together and not even getting triaged properly, thus the bugs are failing to get fixed.

Ultimately, the real solution is to get those underlying bugs fixed so this error dialog shows up less frequently. By making the error message being hit be more explicit, it will help to achieve this goal. Currently a lot of these errors are not getting investigated because all we have to go on is "Some generic error occurred".