Sign In:     

Forum: VirtualDJ Technical Support

Topic: Proper Mac windowing and International Keyboard support
Hi there,
Been using Virtual DJ for some time now and considering buying the license but...
two big issues: as a mac user I like to get a real fullscreen mode where Virtual DJ doesn't seems to properly support it, if you two monitors it doesn't properly move the window to one or the other.
Also it as a very poor keyboard handling... Not as a controller but as a basic shortcut support. For example: CMD+A doesn't do a select all with my AZERTY keyboard. I need to do CMD+Q (because Q is where the letter A is place on a QWERTY). Guys this is 2025, does are basic given of any software. Is this planned to be fix?
 
Posted 7 days ago @ 12:38 pm
I don't know about the multiple screen issue (never tried it) but I confirmed the keyboard layout problem before on MacOs, and I agree that should be fixed.
 
Shortcuts should be fixed in Early Access release 8663

Maximize should maximize virtualdj on the screen it was on, so you can drag it to the screen you want and press maximize.
This doesn't work for you?
 
@Adion I don't think this is fixed (at least on MacOS). I just tried the new build (v2025-m b8663) and added a switched the keyboard input to Canadian French (AZERTY) and VirtualDJ still recognizes the old keybindings:

  • CMD+A as marked on the keyboard = Select All, even though what is actually being sent is CMD+Q
  • CMD+Q as marked on the keyboard quits the application (I've set the keyboard mapping to do such), even though what's actually being sent is CMD+A)
 
The keyboard mapping comes first, so if you want to use a key as the normal shortcut, you can't have it in the mapping.

Edit: It's indeed true that visually in the mapping window, the keys are labeled based on their position on a qwerty layout on mac, that is not fixed, but is less critical as it still matches what you press to learn the key.
 
@Adion something still isn't right - CMD-A is not something I mapped for the Keyboard mapper (it works correctly with the OS level shortcuts so I didn't have to map that), and it still selects all in the browser when I switch over to the different Input Source layout.

Also, if I don't map CMD-Q in the keyboard mapper, it doesn't trigger the OS level command to close the window + kill the process.
 
If you actually had an AZERTY keyboard, the key you wanted to map to close vdj would come up as CMD+A
 
So I do understand what you're saying, but I'm also saying that the switch at the OS level (which causes translation) should be detected/respected in the app for shortcuts but it isn't.

There is even a discrepancy that can be seen currently - The browser search bar is actually showing the correct translation for single character being done correctly (if I push Q on the keyboard, A shows up in the search bar), but the mapper section in the settings is not (it's showing the original).

In addition, other apps are recognizing the translation change correctly, both for the single keys and shortcuts.
 
Yes, that's what I said, the mapping window still shows the keys with their position on a QWERTY keyboard, but cmd+a/x/c/v/z will work fine (assuming not yet mapped)
Unfortunately on mac it is a little bit more complicated than on windows to correctly show the actual letters, and mappings use the position because especially for the default mapper, the position is more important (otherwise pads wouldn't line up properly for example)
 
So I follow all that but still, the behavior at the very least seems unexpected.

If we subtract the mapper section discrepany, let's look at the browser section for example (and the key combination being mentioned below isn't mapped in the Keyboard mapper):

- QWERTY with physical keyboard matching that has Physical CMD-A selecting all (expected)

- AZERTY with physical keyboard matching QWERTY is still having Physical CMD-A (which should be CMD-Q after translation) still doing Select All songs in the browser listing

This is unexpected - every other MacOS native app would have that invoke application quit

And then add to that the search bar, when typing physical A, shows Q.

Even though this is translation, it feels like any user who might decide to do this (unsuggested/unrecommended) route (and maybe even buy a keyboard cover showing the AZERTY layout), would be confused, especially as the behaviour is as expected in other apps (including competing software that I won't name).
 
On azerty, currently indeed both CTRL+A and CTRL+Q will do the same thing, unless one of them is mapped.
 
I'm okay with what ever you guys decide for this case, as long as the story is consistent from all input cases in the application.