Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2024-03-28 21:09:13



Reply to topic  [ 8 posts ] 
Hide particles shortcut keys 
Author Message

Joined: 2016-06-19 21:33:37
Posts: 337
Location: Columbus area, OH, USA
Reply with quote
The shortcut key combination for Hide particles doesn't work for me. The actual Hide particles menu option performs the function properly when using the mouse. I haven't found any other mention in the forums or via Google so it may be my set up, Fedora distro, Gnome, etc. Wondered if anyone else can confirm.

My info:
Code:
Cool VL Viewer v1.26.20.7, 64 bits, Feb 11 2017 09:01:39
Release Notes

You are at 196727.7, 308919.2, 24.5  in Innsmouth located at
sim10450.agni.lindenlab.com (216.82.51.156:13004)
Second Life Server 17.01.27.323172
Release Notes

CPU: AMD A4-7300 APU with Radeon HD Graphics (2200 MHz)
Memory: 16073MB
OS version: Linux-x86_64 v4.9.8-201.fc25.x86_64 #1 SMP Tue Feb 7 11:28:07 UTC 2017
Memory manager: OS native
Graphics card vendor: NVIDIA Corporation
Graphics card: GeForce GTS 450/PCIe/SSE2
OpenGL version: 4.5.0 NVIDIA 375.26
Detected VRAM: 1024MB
J2C decoder: OpenJPEG: 1.4.0.635d
Audio driver: OpenAL v1.1 ALSOFT 1.17.2 (OpenAL Soft: OpenAL Soft)
Networking backend: libcurl/7.47.0 OpenSSL/1.0.1i zlib/1.2.8
Embedded browser: CEF3 plugin v1.5.3c-(CEF-LIN-3.2526.1371-64)
Packets lost: 0/44947 (0.0%)

Built with: GCC v4.6.4

Compile flags used for this build:
-O3 -fno-delete-null-pointer-checks -fno-align-labels -fno-align-loops -fno-ipa-cp-clone -fsched-pressure -frename-registers -fweb -DNDEBUG -pipe -g -fexceptions -fno-strict-aliasing -fvisibility=hidden -fsigned-char -m64 -mfpmath=sse -fno-math-errno -fno-trapping-math -pthread -fno-stack-protector -Wall -Wno-reorder -Werror -DLL_LINUX=1 -D_REENTRANT -DXML_STATIC -DLL_ELFBIN=1 -DLL_LUA=1 -DOV_EXCLUDE_STATIC_CALLBACKS -DLL_FMODEX=1 -DLL_OPENAL=1 -DLL_SDL=1 -DLIB_NDOF=1 -DLL_X11=1


2017-02-12 05:22:59
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Sadly, many shortcut keys (all the ones using the upper row of the keyboard keys, i.e. "1" to "=") are unsuitable for anything else than QWERTY keyboards with English system locale. This is in no way a bug, but just a known limitation. Be also wary of your Gnome keyboard shortcuts that may conflict with other applications (SL viewers included).

I might add a Lua function to toggle render debug features, which would allow to setup a side bar button for them, for quick access...


2017-02-12 09:36:36
Profile WWW

Joined: 2016-06-19 21:33:37
Posts: 337
Location: Columbus area, OH, USA
Reply with quote
Fortunately I do meet the QWERTY and English locale conditions. Indeed, all of the other render debug options work just fine (1-0 and \). I have verified that the default keyboard shortcuts (that I can see/configure), do not have the 4 key combo in question. I wondered/speculated if the problem could have anything to do with the setting being available in more than one menu. It seems to be the only render option like that.

This isn't a big pain point though. I can click a menu item via mouse fairly easily. I just happened to stumble upon it when I was in a heavily particled area when I wanted to quickly toggle them and thought I would mention it here.

Cheers.


2017-02-12 14:01:21
Profile

Joined: 2016-06-19 21:33:37
Posts: 337
Location: Columbus area, OH, USA
Reply with quote
I don't like resurrecting old threads but I may have figured out why the "=" shortcut for particle render toggling doesn't work. I noticed in the recent change log/source that improvements where made to llwindow/llkeyboeardsdl.cpp to support the numeric keypad. I had hoped that perhaps my "=" key there would start functioning for the shortcut but it did not.

I started looking around at the mTranslateKeyMap and noticed a couple of oddities. SDLK_MINUS seems to be mapped twice. I suspect its key mapping works because the 2nd occurrence overwrites the first with the character '-' instead of the value 0x90. That isn't as interesting as the mapping for SDLK_PLUS, which is mapped to the character "=" at line 120. When I change the key to SDLK_EQUALS for that line, effectively overwriting the value mapped at line 99, and build, the keyboard shortcut for toggling particle rendering functions as expected.

I am not that experienced with the key mapping here though. I cannot say if the value for KEY_EQUALS [0x91] (also potentially KEY_HYPHEN [0x90]), defined in llcommon/indra_constands.h, is wrong though they seem to be for any key code/value I could attain with my rig. It seems that at the point SDLK_MINUS was overridden to the character '-' and I suspect SDLK_EQUALS was supposed to be overridden as well and not keyed to SDLK_PLUS.

Just a bit of 'arm chair debugging' on my part. I could be completely off base about the how/why but it does seem that changing the key to SDLK_EQUALS from SDLK_PLUS fixes that particular mapping/shortcut.


2017-06-27 05:48:48
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
ZaneZimer wrote:
I don't like resurrecting old threads but I may have figured out why the "=" shortcut for particle render toggling doesn't work. I noticed in the recent change log/source that improvements where made to llwindow/llkeyboeardsdl.cpp to support the numeric keypad. I had hoped that perhaps my "=" key there would start functioning for the shortcut but it did not.
There is no "=" key on the keypad... At least not for almost all QWERTY and AZERTY keyboards; there are just the "/", "*", "-", "+", "." and ENTER keys on the keypad, in excess of the numbers from 0 to 9...

Like I already wrote in this thread, it is alas a known limitation of keyboard shortcuts, that they cannot meet every single keyboard layout requirement/capability. I'm afraid there is no good solution to this problem, short of never using shortcuts other than the ones with alphabetic keys (i.e. A to Z), but the number of combinations is then very limited...


2017-06-27 09:10:43
Profile WWW

Joined: 2016-06-19 21:33:37
Posts: 337
Location: Columbus area, OH, USA
Reply with quote
Henri Beauchamp wrote:
There is no "=" key on the keypad... At least not for almost all QWERTY and AZERTY keyboards; there are just the "/", "*", "-", "+", "." and ENTER keys on the keypad, in excess of the numbers from 0 to 9...
I use an after market Mac-compatible keyboard on my Linux rig. I actually have a KVM that it goes through so I can use my Macbook or my Linux PC with it. It does have an '=' on the numeric keypad. In general, it has worked very well with my various versions of Fedora over the years.

Anyhow, I agree that it was a poor choice for LL to use so may 'special' character keys for shortcuts but, unfortunately, they did because, as you mentioned, the number of combinations needed. If the Advanced -> Rendering -> Types -> Particles menu entry weren't hard coded, I would have just changed it and the View -> Hide Particles to something different with a custom 'skin' configuration. I was just trying to figure out why that particular one, out of all of them, didn't work for me. It seems to be a bug. I can just do custom builds for myself, if you feel my find isn't suitable for inclusion as fix. I'm just glad to have figured it out 'for me' because it was driving me crazy why I couldn't get that one key combo to work. :-)


2017-06-27 12:59:52
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
For next Linux release, I added the translation of numeric keypad operators keys (/*-+=) into "normal" characters. Note that this must not be done as you suggested in mTranslateKeyMap (I'd rather not touch those: there are weird issues with how keyboard character codes are mapped in various OSes: see for example the comment around line 69 in llkeyboardwin32.cpp, which may explain why the '=' is mapped differently as what you think should be the right way), but in adjustNativekeyFromUnhandledMask(), still in indra/llwindow/llkeyboardsdl.cpp.

I also sorted out weird issues with accelerator keys sometimes handled as unicode characters and also appearing as typed in the chat bar, and changed some shortcut keys that were in conflict ("Hide particles" in the View menu had the same accelerator as the "Particles" toggle in the Advanced/Rendering/Types menu, which was wrong since they do the exact opposite thing), and replaced the "=" and "\" accelerators in the Advanced/Rendering/Types toggles with "*" and "/", which are both present on the keypad, whatever the keyboard language/layout...

Whatever the OS, the keyboard codes handling is a total mess and a PITA, letting the programmers to deal with that mess (and of course, everyone deals differently with it)... If only some new standard could be adopted by everyone and for all languages/layouts...


2017-07-03 21:20:34
Profile WWW

Joined: 2016-06-19 21:33:37
Posts: 337
Location: Columbus area, OH, USA
Reply with quote
Wow, thanks for the further investigation and effort into fixing what seems like a challenging bit of code. I did see the comment in llkeyboardwin32.cpp. I thought perhaps that mapping behavior was only true for Windows. On Linux, I certainly didn't experience the <ctrl> + '=' results in '+'. Anyway, I like the sound of
Henri Beauchamp wrote:
I also sorted out weird issues with accelerator keys sometimes handled as unicode characters and also appearing as typed in the chat bar, and changed some shortcut keys that were in conflict ("Hide particles" in the View menu had the same accelerator as the "Particles" toggle in the Advanced/Rendering/Types menu, which was wrong since they do the exact opposite thing),
It has often puzzled me that some accelerator key combos 'typed' a character in the chat bar. As always, I appreciate your work.


2017-07-04 13:44:23
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 8 posts ] 

Who is online

Users browsing this forum: No registered users and 17 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.