yes changing the mouse type doesn't influence the X11 mouse behaviour 
but the GPM mouse parameters for the console. The module is only capable 
of doing this nothing more 

Well, that is the problem. This dialog during the installation should provide a
way to set up the mouse (X) correctly if the autodetection failed.

Even the manuals are writen that way.

if you can provide a new X11 misc extension which is able to apply all 
kind of mice on the running X-Server we can enable it again otherwise 
this doesn't make any sense because a mouse which has not been detected 
by the kernel and libhd cannot be applied by the X11 misc extension. 

Then it should be made clear to users. the current documentation says:

"If &yast; failed to detect your mouse automatically, press
    <keycap>Tab</keycap> in the suggestion window several times until
    <guimenu>Mouse</guimenu> is selected. Then use <keycap>Space</keycap> to
    open the dialog in which to set the mouse type."

Even without reading the manual, any user would expect this dialog to set X11
mouse, and would try to use it if her mouse hadn't been autodetected correctly.
She would be very frustrated then, not knowing why her mouse didn't respond to
the settings.

If we are really not able to enable X11 mouse configuration here, then it should
 be made clear and obvious both in the documentation and in the dialog.

- Good heavens that's not a critical bug ;) If you want the docu-team 
  to change something file a bug report there I'm not responsible for that 
 
- unfortunately we have text freeze for 10.0 so I'm not allowed to change 
  the text displayed in the GUI. Adding text should be avoided but is possible 
  changing text will trigger a complete new translation round which is not 
  allowed after freeze 
 
 

Is not it really possible fix it or retrieve old X mouse dialog? Sorry if my 
question sounds silly, I don't know amount of changes which you made in the 
mouse module. 
 
At worst we can add a few words about it to Release Notes to prevent users 
complaints and bug reports of this problem. 
 

what for the world does it help to revert the old X mouse dialog ? There 
is no such dialog and of course the changes cannot be merged. As I already 
said so please listen: 
 
 - the X11 misc extension is able to apply mouse with a maximum of 3 
   buttons (no wheel) talking standard PS/2 or old serial mouse 
   protocol. All of these devices are safely detected automatically 
   by the kernel. A device which is not detected CANNOT be activated 
   with the very old misc extension stuff. It does not make sense to 
   provide a NON working dialog as we did in the past. 
 
The yast mouse dialog is for configuration of GPM and not more. I agree 
we have to clear the texts but it's too late for 10.0 therefore I set this 
to later 
 
If you want to add a paragraph in the release notes or in the documentation 
please refer to the responsible people it's not me to do that :-)  
 
Thanks 

OK. Is it then possible take away it from installation completely?  

Yes, I think this should be easy and correct solution: jsrain?

Technically, it is of course no problem. It can be remove completly (via the 
control file), or only from X (Qt) installation (mouse_proposal.ycp has to 
return empty map if running under X - similar to yast2-x11). 

Ok, Jiri please remove it from the control file. Thanks 

I talked about the technical possibilities. But according to comment #7, it 
should stau there for the NCurses configuraiton. So, wouldn't it be better if 
it behaved similar to X11 proposal? 

why should it stay for ncurses configuration ? 
 
- YaST in ncurses mode is not capable of using a mouse 
- SuSE linux does not activate GPM by default even in runlevel 3 
 
For the installation I see no reason to urgently provide that dialog. 
A user who wants to use GPM has to activate it manually. 
 
 
Do you mean a proposal check like this: 
 
if ( 
    (! Arch::x11_setup_needed ()) || 
    (! Installation::x11_setup_needed ()) 
) { 
  ... 
} 
 
? 

Hmm, and what did it set in ncurses until now? Didn't it set GPM for the 
installed system? 
 
The check shouls IMHO look like 
 
if (Linuxrc::text ()) 
  behave_normally 
else 
  do_not_put_mouse_to_proposal 

It set the GPM parameters for the installed system, yes that's the 
task the module has been made for *originally* :-) and the task it will 
fulfill in the future 
 
Ok, please check the attached patch 

Created attachment 47216 [details]
mouse_proposal.dif

The patch seems to look fine. 

fine ;) I will include it now. Thanks for helping  

So did I get that right?

o NCurses: Mouse module present in proposal. Sets GPM parameters.

o Qt: Mouse module not present in proposal.

In Qt-YaST would it be possible to call the SaX2 mouse module at this point in
the installation and let it do whatever it does? This would be more consistent
but I assume it's impossible because X is not configured yet?

Of course the docu talks nonsense when it says "If your mouse could not
be detected, do this and that etc." This has to be corrected in any case.

*** Bug 114625 has been marked as a duplicate of this bug. ***