Default tag hotkeys clash with windows native win + number switching taskbar applications

[FantomX1-github]

Default tag hotkeys clash with windows native win + number switching taskbar applications. I did not come up with solution how to reconfigure hotkeys configuration eg. to
Lwin & Shift & 2, because autohotkey doesnt support it but bug.n #+2 is overriden by windows native shortcut functionality windows + 2 , - which activates second (pinned) application on taskbar, thank you

[FantomX1-github]

@i have been able to somehow overcome the issue, as i am not native English speaking, and i am using therefore multiple country keyboard layouts. When i replaced numbers with other language counterparts keys , (which are normally active when keyboard layout is switched),special characters located on keyboard at place of numbers, ive been able to use number shortcuts successfully. Though i realized it depends on app it is used with, some installers still wont me to tag copy window, because they will eg run application at 5th taskbar place no matter what (they have forced english lang probably) though taskbar/systray keyboard layout icon still displays unchanged.

For number 1, there doesnt exist my native - slovak character counterpart, therefore i am not able to use desk/tag 1. So i dont know if issue is because of different keyboard layouts existing simulatenously, or just bug.n clashes with some default windows hotkey configration. Same happened to me at Windows 7 Professional, and Windows 10.

For sample, my configuration now looks like this;

#BackSpace::Monitor_activateView(-1)
#+é::Monitor_setWindowTag(10)
#=::Monitor_activateView(1)
#+=::Monitor_setWindowTag(1)
#^=::Monitor_toggleWindowTag(1)
#ľ::Monitor_activateView(2)
#+ľ::Monitor_setWindowTag(2)
#^ľ::Monitor_toggleWindowTag(2)
#š::Monitor_activateView(3)
#+š::Monitor_setWindowTag(3)
#^š::Monitor_toggleWindowTag(3)
#č::Monitor_activateView(4)
#+č::Monitor_setWindowTag(4)
#^č::Monitor_toggleWindowTag(4)
#ť::Monitor_activateView(5)
#+ť::Monitor_setWindowTag(5)
#^ť::Monitor_toggleWindowTag(5)
#ž::Monitor_activateView(6)
#+ž::Monitor_setWindowTag(6)
#^ž::Monitor_toggleWindowTag(6)
#ý::Monitor_activateView(7)
#+ý::Monitor_setWindowTag(7)
#^ý::Monitor_toggleWindowTag(7)
#á::Monitor_activateView(8)
#+á::Monitor_setWindowTag(8)
#^á::Monitor_toggleWindowTag(8)
#í::Monitor_activateView(9)
#+í::Monitor_setWindowTag(9)
#^í::Monitor_toggleWindowTag(9)

#+0::Monitor_setWindowTag(10)
#1::Monitor_activateView(1)
#+1::Monitor_setWindowTag(1)
#^1::Monitor_toggleWindowTag(1)
#2::Monitor_activateView(2)
#+2::Monitor_setWindowTag(2)
#^2::Monitor_toggleWindowTag(2)
#3::Monitor_activateView(3)
#+3::Monitor_setWindowTag(3)
#^3::Monitor_toggleWindowTag(3)
#4::Monitor_activateView(4)
#+4::Monitor_setWindowTag(4)
#^4::Monitor_toggleWindowTag(4)
#5::Monitor_activateView(5)
#+5::Monitor_setWindowTag(5)
#^5::Monitor_toggleWindowTag(5)
#6::Monitor_activateView(6)
#+6::Monitor_setWindowTag(6)
#^6::Monitor_toggleWindowTag(6)
#7::Monitor_activateView(7)
#+7::Monitor_setWindowTag(7)
#^7::Monitor_toggleWindowTag(7)
#8::Monitor_activateView(8)
#+8::Monitor_setWindowTag(8)
#^8::Monitor_toggleWindowTag(8)
#9::Monitor_activateView(9)
#+9::Monitor_setWindowTag(9)
#^9::Monitor_toggleWindowTag(9)

[x29a]

which windows are you referring to? i assume win10?

[FantomX1-github]

I refer to win10 and win7 both tested same. But mainly windows 7 currently i am working on. But i ve been having this issue for longer time on many computers, thats why i almost give up on using bug.n because not working hotkey (on computers with multiple keyboard layouts) prevented me to tag window with mutliple tags, what was not problem on older bugn (but possibly it was because older windows xp i was using at that time didnt have overriden it with those shortcuts )

[FantomX1-github]

I want to note, that after leaving English keyboard layout as default language or as single one the problem went away, so maybe this issue could be closed, though better off would be if bug.n app in source code automatically forced english layout somehow when relying on specific hotkeys.

[joten]

This issue is similar to #55 . I copied your suggestion for the hotkey configuration to doc/User-hotkeys.md.
The corresponding key to 1 should be + as far as I can see.

Personally, I do not like the idea of forcing a specific keyboard layout; bug.n is not totally relying on one. I prefer the way, you solved the problem by suggesting a different configuration (Config.ini). It should work consistently as long as the keyboard layout chosen in Windows stays the same throughout the bug.n session.

[ViRGiL175]

Hi.

I'm not native English speaker too, as a result I have similar OS keyboard/locales setup.
I'm, however, not noticed very critical problems with standard and bug.n shortcuts.

But there is a some annoyance instead. If I'm changing my View (I hope I'm using terms correct, first day user) to View number N, and in my number N View I have an opened (or just pinned) App on N-th place in bottom Windows bar, Windows Start menu will be opened.

I'm using Windows 10.

It is not very critical, just very annoying to press Esc nearly every time I change View with Win + N combination.

I'm searching way to just disable standard Windows Win + N shortcut now, because I don't need it anyway. But maybe you can easily fix that for next versions.

[FantomX1]

Yeah, thanks. The workaround with a separate config works, but would be interesting idea if possible to recognize in Autohotkey that if at any other language layout the physical key pressed was the same, and therefore it would trigger the corresponding desktop, anyway the advanced user get used to after time to switch layout every time needed, but still it is a little slowing down.