I get this issue. The ubuntu bugzilla has a bug about this with some details
(config, xev, ...):
https://bugzilla.ubuntu.com/5764

svu, any idea on this ?

As we found, these two bugs are irrelevant.

Created attachment 45856 [details] [review]
gnome-settings-daemon patch

The problem is that even if you have the Windows key set to show up as Mod4,
gnome-settings-daemon ignores it as a modifier while metacity doesn't. This
causes a few of the actions in gnome-keybinding-properties to be able to set
with Mod4 as a modifier, but no action will be performed when the combination is
pressed. I've attached a proposed patch for fixing this in gnome-settings-daemon.

This one is really annoying. Can it please be fixed for 2.12?

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

svu, what do you about this patch?

(Only commenting as I'm adding my name to the CC list, glad to see this is
already marked as High priority)
the lack of expected bindings was mentioned on the usabilty mailing list again
http://mail.gnome.org/archives/usability/2005-June/msg00033.html

re: #3 patch, working fine here for some time, 2.10.0 control-center.  Great
easy fix.

I've tried the attached patch as well, but unfortunately it doesn't work. When
pressing the windows key it is still recognized as isolated "Super_L" and not as
modifier.

My configuration:

model: Generic 105-key (Intl) PC
layout: German Eliminate dead keys

:~# xmodmap 
xmodmap:  up to 3 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),  Alt_L (0x7d),  Meta_L (0x9c)
mod2        Num_Lock (0x4d)
mod3      
mod4        Super_L (0x7f),  Hyper_L (0x80)
mod5        Mode_switch (0x5d),  ISO_Level3_Shift (0x7c)

re:10 - I checked my xmodmap and have both 0x73 and 0x7F as Super_L.  You also
don't have Super_R defined.  Not sure if you have a wildly different keyboard
layout or what, but something to try...

~ $ xmodmap
xmodmap:  up to 4 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),  Alt_L (0x7d),  Meta_L (0x9c)
mod2        Num_Lock (0x4d)
mod3
mod4        Super_L (0x73),  Super_R (0x74),  Super_L (0x7f),  Hyper_L (0x80)
mod5        Mode_switch (0x5d),  ISO_Level3_Shift (0x7c)

Re: #10 - The patch doesn't address the default mapping of the Windows key to
Super_L not being recognized as a modifier by gnome-keybinding-properties.
Actually it probably should have been on a seperate bug, as it deals with the
backend issue that you will only see if you fix what the reporter is talking about.

To get the Windows key to show up as Mod4 in gnome-keybinding-properties, run
gnome-keyboard-properties, choose "Layout Options", drop down "Alt/Win key
behavior", and choose "Super is mapped to the Win-keys (default)", then click
OK. Actually, choosing pretty much anything other than "Default" will make the
Windows key correctly show as Mod4 in gnome-keybinding-properties on my computer
it seems. I tested each setting and here's what I got:

Windows key shows up as Super_L in gnome-keybinding-properties:
-Default
-Add the standard behavior to the Menu key
-Alt and Meta on the Alt keys (default)

Windows key shows up as <Mod4> modifier in gnome-keybinding-properties:
-Meta is mapped to the Win-keys
-Meta is mapped to the left Win-key
-Super is mapped to the Win-keys (default)
-Hyper is mapped to the Win-keys

Here's the relevant portion of xmodmap for each layout setting:

Default/Add the standard behavior to the Menu key/Alt and Meta on the Alt keys
(default):
mod4        Super_L (0x7f),  Hyper_L (0x80)

Meta is mapped to the Win-keys/Meta is mapped to the left Win-key:
mod4        Meta_L (0x73),  Meta_R (0x74),  Super_L (0x7f),  Hyper_L (0x80), 
Meta_L (0x9c)

Super is mapped to the Win-keys (default):
mod4        Super_L (0x73),  Super_R (0x74),  Super_L (0x7f),  Hyper_L (0x80)

Hyper is mapped to the Win-keys:
mod4        Hyper_L (0x73),  Hyper_R (0x74),  Super_L (0x7f),  Hyper_L (0x80)

Like Nick brought up in #11, it seems to be an issue where 0x73 has to be set to
Mod4.

Re: #11: 
> "Not sure if you have a wildly different keyboard layout
> or what, but something to try..." 

No, I don't think:
"physical" keyboard model: "standard" german keyboard, 105 keys
Keyboard model: "Generic 105-key (Intl) PC"
Layout: "German Eliminate dead keys"



Re: #12: Yes, different settings in "layout options", "alt/win key behavior" let
the windows key show up in gnome-keybinding-properties as Mod4 or super_l. But
on my system I got different results than you:


Windows key shows up as Super_L in gnome-keybinding-properties:
- Default
- Add the standard behavior to Menu key
- Alt and Meta on the Alt keys (default)
- Super is mapped to the Win keys (default)
- Hyper is mapped to the win-keys

Windows key shows up as <Mod4> modifier in gnome-keybinding-properties:
- Meta is mapped to the win-keys (additionally this breaks AltGr+"+" for the
tilde symbol and all other keybindings with AltGr(=IsoLevel3Shift))
- Meta is mapped to the left Win-key (in this case AltGr works)

If it helps here is the ouput of xmodmap for mod4 for every setting:

Default: "mod4        Super_L (0x7f),  Hyper_L (0x80)"

Add the standard: "mod4        Super_L (0x7f),  Hyper_L (0x80)"

Alt and Meta on Alt: "mod4        Super_L (0x7f),  Hyper_L (0x80)"

Meta to win keys: "mod4        Meta_L (0x73),  Meta_R (0x74),  Super_L (0x7f), 
Hyper_L (0x80),  Meta_L (0x9c)"

Meta to left win: "mod4        Meta_L (0x73),  Super_L (0x7f),  Hyper_L (0x80),
 Meta_L (0x9c)"

Super is mapped: "mod4        Super_L (0x7f),  Hyper_L (0x80)"

Hyper is mapped "mod4        Super_L (0x7f),  Hyper_L (0x80)"

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

Sergey, could you comment on the issue? It happens with the current xorg/GNOME
2.12 on Ubuntu by example

Sebastien, I am not sure I am the right person to ask about
gnome-settings-keybindings.c etc. The patch looks a bit like hack - instead of
fixing the layouts (mapping Super_* keys to Super) it makes shortcut engine kind
of "blind" in some aspects. As a hack it is not terrible - but it is still a
hack. And I foresee some people which may want to use Super_R and Super_L
differently indeed... 
So, for me this bug looks like "NOTGNOME" and should be directed to the X server
people who might be able to provide options for having two keys mapped to same
Super keysym.

Sergey,
The patch is hacky because the code for g-s-d is hacky. Why is it arbitrarily ignoring certain modifiers to begin with?

As I mentioned earlier, this is really two seperate issues. The first one is being unable to set a Windows+<key> shortcut in gnome-keybinding-properties, because it is immediately captured as Super_L instead of being used as a modifier. This is because apparently the default keyboard layout is set up in such a way that 0x73 (and probably 0x74) is not mapped to mod4, and the numerous Alt/Win behaviors available in gnome-keyboard-properties do not immediately indicate which option should be chosen to fix this. The second is, once you get gnome-keybinding-properties to accept the key being used as a modifier, certain actions do not work if you map them using a Mod4 modifier. This is because some of the actions are carried out by metacity, and some of the actions are carried out by g-s-d. g-s-d for some reason ignores Mod4 as a modifier which means any shortcuts you map using it don't get carried out. This patch only corrects the second problem.

An example use case would be an average GNOME user who wants to map Windows+L to "Lock screen" like they have on their Windows machine. In the current state of things, they would at first only be able to get Super_L recognized in gnome-keybinding-properties. If they then were to fool around in gnome-keyboard-properties and discover which Alt/Win behavior resulted in it being recognized as a modifier in gnome-keybinding-properties, it would seem as though they were done because they were able to set <Mod4>l as a shortcut for "Lock screen". But now whenever they press Windows+L, nothing actually happens. This is because the "Lock screen" action is handled by g-s-d, which masks off Mod4 and ignores the shortcut as a result.

Well, Ryan, generally I agree. I do not particularly like that g-s-d ignores some modifiers anyway - so your patch does not make things particularly better or worse. So, within the current architecture this looks like minimalistic solution. Though being a bit of purist I'd still prefer just to ask people to use some XKB configuration where SuperL == SuperR (if they really want them to behave absolutely identically).

With GNOME 2.14 almost on the street this bug still exists. I am one of the users that would like his <Mod4>l to lock the screen and I can't do it with gnome-control-center 2.13.91. Can it still be fixed before release?

Just adding myself to the CC list. Guess I'll use my own patched gnome-settings-daemon for the foreseeable future. This really is inconsistent.

So Sebastien, will we commit it to 2.15? It seems people still need it.

> Though being a bit of purist I'd still prefer just to ask people to
> use some XKB configuration where SuperL == SuperR (if they really 
> want them to behave absolutely identically)

I am another of the users that would like Windows+l to lock my screen. I do not care wheter Super_L == Super_R but I do expect the key combination I assign to lock the screen to lock the screen; even if only Super_L+l does so.

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

I always try to tie all window operations to win+key -- it makes more sense than alt+ctrl. Pretty please, get someone to fix all these keyboard and shortcut problems Gnome has -- some of these bugs are ridiculously old already.

KDE has extremely flexible options for binding keys; perhaps someone can take a peek?

Any progress on this? I'm primarily adding myself to the CC list. If I was to use the patch posted on comment #3, are there instructions on what to do with the file? Does it involve recompiling etc?

I found a (sort of) workaround for some of these after a bit of fiddling. If anyone finds this page seeking a solution, this may offer one. It's possible to create additional keybindings via gconf-editor /apps/metacity/global_keybindings and /apps/metacity/keybinding_commands.

Steps that worked for me to enable lock screen, create a new key in /apps/metacity/global_keybindings called "run_command_20" and add the key mapping you want (<Mod4>L for example) then in /apps/metacity/keybinding_commands add a key called command_20 (type string) with the command you want to run. To lock the screen I use "gnome-screensaver-command --lock" but "xscreensaver-control -lock" may also work for you, depends on your screensaver.

This has fixed the problem for me, although I realise it's not an ideal solution, but for a relative newbie it's much easier than patching / recompiling, etc.

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

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

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

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

wow.. so is this ever going to get fixed?
its been reported at least 8 times on this board alone
as well as on ubuntu bugzilla and a usability bugzilla

this is one the very first things people try to do on linux and it is one of the very first things (if their lucky) that doesnt work and in some cases the last thing before they dump on linux and go back to windows

i have been having to set up that workaround #26 mentioned on every linux install ive used, and i always assumed it would be fixed soon so never posted a bug report before, until yet again, i installed another linux box here at work and had to reset all my keys again, its a hassle setting them the gconf-editor and there are only 12 or so available keys there

i hope at least the Mod4 issue is fixed soon, or maybe just remove having the g-s-d handle those shortcuts and add them into metacity? the hotkeys metacity handles work fine

I agree, I think it's a serious problem, espeically because there's often no apparent error to the user, so they have no idea why it doesn't "just work".

I have managed to map 32 custom keys by manually adding the entries to gconf, but at 32 I seem to have hit a wall. Here's hoping I don't need more shortcuts than that... :)

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

well i guess this is never going to be fixed..
user friendliness is overrated anyway ;)

im gonna try and see how hard it might be to move all of the hotkey functionality out of gnome, and into metacity

GTK+ 2.10 can tell apart whether we're using Super/Alt/etc.
We should use that to ignore Num-lock and the likes in the gnome-settings-daemon.

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

I just wanted to chime into this report with a bit of information that some of you might not know.

In X there are 8 physical modifiers.  Some of these are directly mapped to common modifiers.  Notably, shift and control get their own physical modifiers.  Also, caps lock gets one.  So aside from those three there are five other physical modifiers called Mod1, Mod2, ... Mod5.  By convention, Mod1 is the Alt key.  The other 4 get arbitrarily mapped to the remaining virtual modifiers like Super, Hyper, Meta, Compose, Num Lock, etc.  Interestingly enough, there is no Windows key modifier, so normally the windows keys are treated like Super keys, I think.

Whether Super gets mapped to Mod4 or any of the other ModX modifiers is arbitrary.   

Right now gnome-settings-daemon ignores the Mod2-Mod5 modifiers.  I'm guessing it does this because the virtual modifiers they map to might change in the middle of a session or from session to session.

If a user presses the Super key we should probably store that in GConf as <Super> and not <Mod4>, so that if the mapping changes we can float the passive key grab over to the new key combination.  That's why attachment 45856 [details] [review] probably isn't the best way to go.

I do think something like attachment 45856 [details] [review] (but for all of Mod2-Mod5, not just Mod4) is better than what we have now, but ideally, we should handler virtual modifiers.

adding myself to CC with gnome-2.16.x . Can somebody report to proper people to fix, if it's not gnome problem, or any chance it will be fixed ?!

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

I looked at the code, and we'd either need to change eggaccelerators or use the GtkAccelRenderer. The proper way is to use the GtkAccelRenderer...

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

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

Adding myself to CC, using gnome-2.18, important to me, hope I'm not going to wait another 2 years.

wow, january of 2005?  i guess i won't hold my breath :)

please add me to the list of people who'd like to see win+l lock their workstations.  it just makes sense :)

For those still longing, a workaround can be found w/xbindkeys.  Bind your Win+L to 'gnome-screensaver-command --lock' and you'll be golden.

Also, beryl (probably compiz too) handles Win-L just fine, so that is an option as well.

Apparently, KDE/Qt is handling this properly (I've got global keybindings using the Win key working when using Amarok). It may be worth looking at what design decision they took to manage the issue.

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

The solution that worked for me is to add altwin(super_win) to my symbols keymap. And it works. But it does not solve others problems I had so I'll reopen my bug.

Adding myself to CC. Using the keyboard settings solution presented here, the keyboard shortcuts config screen recognises my win + $key combos and I'm able to assign them to certain actions, but only Mod4+m actually works; Mod4+e (run nautilus) and Mod4+l (lock screen) do nothing.

While gnome-keybinding-properties recognizes Windows+Left/Right when I attempt to assign them to next/previous track, the resulting assignment does nothing when invoked. Is this g-s-d ignoring the super modifier?

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

Using control-center 2.18.1 i was able bind the logo key to 'mute volume'.

In the keyboard preferences i mapped meta to the win keys.
I used gconftool-2 to set the bindings:
 gconftool-2 -t str --set /apps/gnome_settings_daemon/keybindings/volume_mute "<Meta_L>KP_Multiply"

The 'Keyboard Shortcuts' window insisted on using '<Mod4><Hyper>KP_Multiply', which is not working.
Also the dialog shows just '*' after using gconf directly.

All keybindings handled by metacity do work.

Forget the previous post.. Meta_L is just ignored, it's just like binding 'KP_Multiply' directly.

Hi, I couldn't read the *so many* bugzilla comments about this bug, so I just will say that I'm cc'ing to this bug because I'm using ubuntu gutsy with gnome 2.20 and I haven't been able to create any keybinding that uses the Windows key. 

You know, all keyboards come with this key and is present in the default keybindings on win xp (win+e opens explorer, win+m shows desktop, win+r launch command), and I use windows xp at work and linux at home, so it's a pitty that I can't use the keybindings I'm used at work when I'm at home with linux.

Sorry for sounding a bit ranting.

Read comment <a href="#c26">26</a>, it provides a workable solution.

Yes, comment 26 provides a workaround, albeit not a clean one. Gnome has a keybinding for "home folder", for example. When you search it, it appears in apps -> gnome_settings_daemon -> keybindings as the key called "home". That would be the correct place to define it, however if you define it as "<Super>e", it doesn't work. In the keyboard shortcuts applet it turns up as Ctrl+Alt+E, which also doesn't do a thing when pressed. Hovering over the key there switches it from Ctrl+Alt+E to just E, and back again. Of little practical use, but great fun on a rainy afternoon...

This behaviour is inconsistent with the key for "show desktop", which is located in apps -> metacity -> global keybindings as the key called "show_desktop", which you can perfectly define as "<Super>m", and simply works as advertised.

Had to resort to defining it as run_command_1 with a value of "<Super>e", and define a matching command_1 with a value of "nautilus $HOME".

Even so, it's not a clean, nor the correct way to do things. This bug is almost 3 years old. I wonder when it will finally be fixed upstream, because it remains an annoyance and working around it takes knowledge beyond what can be expected of newbies or other technically challenged users, who shouldn't be expected to know about these things anyway. Some of us can find the answers here, or on the forums, but non-technical people with little or no understanding of the English language are pretty much out of luck on these issues.

(In reply to comment #17)
> Sergey,
> The patch is hacky because the code for g-s-d is hacky. Why is it arbitrarily
> ignoring certain modifiers to begin with?

Because there's (well, there was) no way to know which one of Mod2 to Mod5 was the Meta, Super or Hyper, so we ignored them all.

The problem for most people is that the Windows key isn't a modifier. You can change that behaviour in the layout options tab of the keyboard preferences, under "Alt/Win behaviour".

Selecting "Hyper is mapped to the Win-keys" will make the Windows key a modifier.

The patch attached below should allow using Super and Meta combinations.

Created attachment 98956 [details] [review]
gcc-ignore-only-hyper.patch

Unstable only, please.

I read the bug but didn't finally figure whether a solution has been made available to use Super in key combinations (like Super+L) or not. If there is, I would be thankful if someone would make it bolder.

huji:  Looking at the patch, it would seem this has been resolved pending testing...

2007-11-18  Jens Granseuer  <jensgr@gmx.net>

        Patch by: Bastien Nocera <hadess@hadess.net>

        * gnome-settings-multimedia-keys.c: allow key bindings using Super and
        Meta combinations (bug #165343)

Can we consider this one fixed now, or are there other issues left?

(In reply to comment #62)
<snip>
> Can we consider this one fixed now, or are there other issues left?

The only issue left is whether the Super key is a modifier, or a stand-alone key, which we can't fix on our side. So fixed now.

can someone tell, what gnome version will include this bug fix? so we can test and confirm that it was fixed? i'm not a developer, i'm end user, so can't recompile whole gnome.

The first release will be 2.21.3. If everything works as expected and noone complains it might be applied to the 2.20 branch after that as well.

The change breaks the multimedia keys, they are correctly listed in the capplet and you can assign a keycode correctly but there is no action when using the volume keys for example, reopening

Patch has been reverted in gnome-settings-daemon and gnome-control-center modules

I currently have this behaviour on 2.22.1:
* gnome-keybinding-properties correctly detect keybindings with "Win" (reporting it as Mod4, and writing in gconf <Mod4><Hyper>)
* Metacity responds to the keybindings correctly (like changing the size of the windows, changing workspace...)
* gnome-setting-deamons _does not_ correctly detect the keybindings (such as volume change, locking the screen...) (It works with other modifiers, but not <Mod4><Hyper>)

It seems to be the latest variation of this bug, but let me know if I should open another one. It looks like gnome-setting-deamons would gain in stealing some code from metacity ;-)

I have seen similar issues to Comment 68. Seriously, this bug really needs to get fixed. It's been over three years and one can still not bind shortcuts to the Windows key. Has anyone taken a closer look at gcc-ignore-only-hyper.patch?

This should hopefully fix it. Scheduled for 2.23.5.

2008-06-28  Jens Granseuer  <jensgr@gmx.net>

        * plugins/common/gsd-keygrab.c: don't ignore any ModX modifiers.
        This should finally make g-s-d recognize keybindings with Super
        and Meta although we still don't handle the corresponding virtual
        modifiers (bug #165343)

Revison 386 to gnome-settings-daemon/plugins/common/gsd-grabkey.c meant to fix this bug has the unfortunate side effect of making it impossible to use the media keys when Num_Lock is on, which is the normal state of affairs for most users, since most keyboards have both a set of editing keys and a number/editing keypad.

Num_Lock is usually assigned to MOD2 which this fix puts in GSD_USED_MODS instead of GSD_IGNORED_MODS. The most correct fix for this would be to detect which mod is being used for Num_Lock using XGetModifierMapping and then add that mod to the set of ignored mods. The easier fix would be to revert to including GDK_MOD2_MASK in GSD_IGNORED_MODS.

Sigh.

2008-08-03  Jens Granseuer  <jensgr@gmx.net>

        * plugins/common/gsd-keygrab.c: (setup_modifiers), (grab_key),
        (match_key): resolve NumLock dynamically and make sure we ignore it
        so using e.g. the media keys works even when NumLock is on (still
        bug #165343)

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

I don't see how this can possibly be marked as FIXED as in 2.24 I still press Win+L and only see "Super L" instead.

(In reply to comment #74)
> I don't see how this can possibly be marked as FIXED as in 2.24 I still press
> Win+L and only see "Super L" instead.

Then you should reopen the bug (I did it now) and explain the problem you're experiencing in some more detail. Thanks.

This bug is about not being able to use the Win key as a modifier. If it shows up as Super, it is clearly possible. Feel free to file another one if you don't like that but don't raise the dead.

And please let me know what the bug number is so that I can add myself to the CC list, seeing as how the bug I reported isn't actually fixed.

If you still get the Windows key recognised as Super rather than a modifier then you need to go to Preferences -> Keyboard -> Layouts ->  Layout Options -> Alt/Win key behaviour -> Super is mapped to the Win-keys. Then if you assign Windows+X to something it will show up as 'Mod4+X'.

If you want this changed by default, I guess a new bug needs to be opened against gnome-control-center, or maybe gnome-settings-daemon, or xorg itself.

If I set up Alt/Win key behaviour -> Super is mapped to the Win-keys, then I can use 'Mod4+L' as a shortcut for Lock Screen (via Preferences->Keyboard Shortcuts), however it doesn't work. So it seems that Mod4+SomeKey cannot be used as global shortcut.

I've been following this bug on Ubuntu's downstream Launchpad (https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/12153).

I don't believe I have rights to reopen this bug, but it's neither RESOLVED nor FIXED.

The bug title is "Super (Windows key) isn't recognized as a modifier".

Yes, there's a workaround. Changing "Super is mapped to Win keys" makes it work.

A workaround is not a fix.

gnome-control-center, in its default state, ships with this bug. Compare this to the Compiz ccsm tool, which works with the Windows key. Yes, there are complexities which have kept this issue open, but they are idiosyncratic.

This has got nothing to do with unusual keyboards: it's something trivial, used by many computer users, and which is broken out of the box.

As with Sam's comment, if this bug cannot be fixed until those idiosyncrasies are smoothed out of another GNOME component, then it should stay open awaiting that.

Jens, is this fair? If a fix is needed in another component, could you direct a layman where to look? Thanks for your continued hard work. :-)

The bug, as originally filed, was that the Win keys (aka Mod4) would be ignored even if they were being used as modifiers. That has been fixed.

The fact the Win keys aren't configured to be used as modifiers by default is either a problem in the X server, or somewhere in the keyboard layer, depending on how exactly keyboard options work, of which I'm no expert, myself. We might be able to override the default setting in the GConf schema in GNOME (that would probably move it over to libgnomekbd), but again, that depends on how xkb options are implemented.

In any case, all of that is not *this* bug.

Jens, thanks for the rapid response.

I disagree with your interpretation of what the bug is, and I suspect Ignacio (the original bug opener) does as well, from his comment #77 ("the bug I reported isn't actually fixed").

Nevermind that though: perhaps the issue reported in 2005 described two bugs, and you've fixed one of them, I will open another. I don't mean to disparage your efforts, there's a lot going on here.

I have raised #579658 under libgnomekbd. HTH.