Bug 80918

Summary: ctrl-drag to move windows bad default
Product: [Retired] Red Hat Public Beta Reporter: Daniel Resare <noa-bugzilla-redhat>
Component: metacityAssignee: Havoc Pennington <hp>
Status: CLOSED RAWHIDE QA Contact:
Severity: low Docs Contact:
Priority: medium    
Version: phoebeCC: aoliva, mitr
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-01-14 21:56:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 79579    

Description Daniel Resare 2003-01-02 13:11:41 UTC
Description of problem:

Since ctrl-click is the standard (only?) way to deselect the last item in a
multivalue select list in mozilla using ctrl-drag to move windows by default in
metatcity seems like a bad idea.

A good default IMHO would be alt-drag :)

Version-Release number of selected component (if applicable):
metacity-2.4.8-1

Comment 1 Miloslav Trmac 2003-01-02 14:55:04 UTC
People complain regardless of choice made,
but I'd also prefer having the Maya people
change the defaults - listbox behavior
(fortunately) can't be configured.
Not to mention the long-standing tradition
of using Alt.

Comment 2 Havoc Pennington 2003-01-02 16:14:13 UTC
It sure doesn't use ctrl+drag by default as far as I know. Uses
Super+drag which is the windows key by default.

What's the output of "xmodmap -pm" for you? Please reopen bug
if you add that info.

Comment 3 Daniel Resare 2003-01-02 16:20:54 UTC
[noa@c-2c1a72d5 webwork-1.3]$ xmodmap -pm
xmodmap:  up to 2 keys per modifier, (keycodes in parentheses):
 
shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_R (0x6d)
mod1        Alt_L (0x40)
mod2        Num_Lock (0x4d)
mod3
mod4
mod5        ISO_Level3_Shift (0x71)


This is the result of

Section
        Identifier  "Keyboard0"
        Driver      "keyboard"
        Option      "XkbRules" "xfree86"
        Option      "XkbModel" "pc102"
        Option      "XkbLayout" "se"
EndSection

in XF86Config

Comment 4 Havoc Pennington 2003-01-02 20:09:37 UTC
*** Bug 80917 has been marked as a duplicate of this bug. ***

Comment 5 Miloslav Trmac 2003-01-03 14:16:08 UTC
Um, how can Super be a reasonable default when it is
not present in the list box at all?

Comment 6 Havoc Pennington 2003-01-03 15:39:48 UTC
The config dialog only displays keys that you actually have 
on your keyboard. But the configuration defaults are just fixed to a single 
value, there's no connection to the X server at that point to know 
what your keyboard has.

If you create a Super key for yourself, and bind it to a modifier,
or use the pc105 keymap, then you should get that option in the config dialog.

Comment 7 Alexandre Oliva 2003-01-06 03:19:23 UTC
I use a us pc105 keyboard, but the default used to be Ctrl, and it still offers
me only Ctrl and Alt as the options.  I know X does know about the Windows key
since it's used as the Compose key.  What now?

$ xmodmap -pm
xmodmap:  up to 2 keys per modifier, (keycodes in parentheses):
 
shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_R (0x6d)
mod1        Alt_L (0x40)
mod2        Mode_switch (0x71),  Mode_switch (0x74)
mod3
mod4        Select (0x73),  Mode_switch (0x74)
mod5

XF86Config says:
        Identifier  "Keyboard0"
        Driver      "keyboard"
        Option      "XkbRules" "xfree86"
        Option      "XkbModel" "pc105"
        Option      "XkbLayout" "us"

Atop that, I'm using the keyboard layout switcher with `gkb_xmmap us'  settings
with a US 105-key keyboard (with windows keys).

Comment 8 Havoc Pennington 2003-01-06 03:53:41 UTC
The Compose key (Mode_switch) is filtered out of the available options on purpose, 
since it's used for something else. If you wanted to use the Windows key for 
WM bindings, you'd need to bind it to Super_L or Super_R instead of Mode_switch.


Comment 9 Alexandre Oliva 2003-01-06 04:13:56 UTC
Sounds reasonable to me, but it still leaves us with a bad WM default since it
conflicts with the default key/mouse bindings of our default browser.  Hmm... 
Perhaps we only get the bad default when migrating from 8.0 settings?  That
might be it.

Comment 10 Havoc Pennington 2003-01-06 04:17:18 UTC
It doesn't default to control. I haven't tried in phoebe but I'm pretty sure
if you log in to either a fresh account or an upgrade and try doing control+drag
it won't work.

It's possible it switches to control if you open the control panel. I could fix 
that by putting Alt first in the list probably.


Comment 11 Alexandre Oliva 2003-01-06 05:26:00 UTC
Confirmed.  I've just tried a new account, and it does default to Super until
the point where I run `gkb_xmmap us'.  Then, if I open the preferences window
again, it switches to Ctrl, even though Super-drag was still functional, but
then it woudln't offer me the option of Super any longer.
Perhaps you could just refrain from taking Super out of the list of options?

Comment 12 Havoc Pennington 2003-01-06 06:09:01 UTC
It's not nice to offer Super and Hyper when those don't exist, I don't think.
Then you'd click them and they wouldn't work.

I'll just make the control panel a bit smarter, and maybe change the default 
back to Alt.



Comment 13 Alexandre Oliva 2003-01-06 06:43:21 UTC
Well, then the code to tell whether they exist has to be improved, because in my
set up Super works, even though it's not offered as an option.

Comment 14 Havoc Pennington 2003-01-11 23:41:24 UTC
What is your setup now then? The "xmodmap -pm" output you gave has no Super.


Comment 15 Alexandre Oliva 2003-01-12 12:52:56 UTC
Set up unchanged.  xmodmap -pm makes no reference to Super, but it somehow still
works.

Comment 16 Alexandre Oliva 2003-01-12 13:10:21 UTC
Hmm...  Could it be just because the window manager starts up before the gnome
keyboard layout switcher kicks in and changes the set up?

Comment 17 Havoc Pennington 2003-01-12 16:32:31 UTC
I suppose it's possible. You're saying gconf stores <Super>?

If you do:
 gconftool-2 -R /apps/metacity/global_keybindings
 gconftool-2 -R /apps/metacity/window_keybindings

and find the keybinding in question, how is it listed? <Mod2> or <Super> or?

Comment 18 Alexandre Oliva 2003-01-12 16:49:48 UTC
Erhm...  Couldn't find it under keybindings (not surprising, since it's a mouse
sequence).  But there it was in /apps/metacity/general:

 mouse_button_modifier = <Super>


Comment 19 Havoc Pennington 2003-01-12 17:39:09 UTC
Right, sorry about the dumb gconftool instructions.

I don't have a clue where it gets Super from if it's not in your config - your
theory about the keymap switcher applet may be right.



Comment 20 Havoc Pennington 2003-01-14 21:56:10 UTC
The default is now Alt.

Filed http://bugzilla.gnome.org/show_bug.cgi?id=103516
to mop up the "keymap changes midstream" corner case.