JSXGraphm with MathJax in fullscreen - fullscreen

I have this small piece of JSXgraph code:
JXG.Options.text.useMathJax = true; // <--
var board = JXG.JSXGraph.initBoard('BOX-test', { showFullscreen: true });
var point=board.create('point', [0,0]);
When I go in fullscreen mode, all good, but I have the following problem as soon
as I try to drag something, like move the point: the
board immediately goes back to its normal size, and stays on top of a weird
gray page (I don't see my webpage anymore), like so:
Gray page on top.
But as soon as I remove the first line JXG.Options.text.useMathJax = true;,
the problem dissapears and I can drag the point in fullscreen mode.
This means that if the board contains some LaTeX, I can't really interact with
the elements (points, sliders, etc.) when in fullscreen.
Note: I have observed this phenomenon on Firefox and Chrome, so the
problem is apparently not related to the browser.

Related

Neutralino.window.setDraggableRegion is malfunctioning on windows

What happens is that I initiate the window drag instruction with Neutralino.window.setDraggableRegion, it works but there is a very big problem in rendering.
I am on a windows system. Here is a video of the problem:
Video of the problem
As you specified, the window is dragging but the mouse doesn't move with the point you click on, instead the mouse is at a different position.
I Looked at how draggable region function works under the hood, and it's handled by the JavaScript Client File, by setting the window position to the amount of mouse has moved on x and y.
since the mouse pointer doesn't move instead the window moves relative to the position from where you started clicking.
I will raise this issue, and soon a fix for this will be out!
Issue has been raised

DirectX-based game display always on top. Need solution

You can see the video of the problem below. When I press the Minimize button, the screen disappears, but when you put the other window on top without pressing the Minimize button, the screen will not be covered and it will always float on top. This problem did not occur in Windows 7, but it occurs after upgrading to Windows 10.
Problem video
I would like to know the DirectX initialization code for the function or function argument related to this problem. (As far as I know, this game uses DirectX 9.)
Additional Information
Based on Castorix's advice, I used the Spy ++ program to test it. Below is the result screen.
The problematic program consisted of two windows, a parent window and a child window. The parent window style consists of WS_CAPTION, WS_MINIMIZE, WS_VISIBLE, WS_CPLISIBLINGS, WS_SYSMENU, WS_OVERLAPPED, WS_MINIMIZEBOX, WS_MAXIMIZEBOX, 0x00008000. And the child window style consists of WS_CHILDWINDOW, WS_VISIBLE, WS_BORDER.
Additional Information 2
If you look carefully at the above video, when the game window goes under the notepad window, the game title bar is hidden, but you can see that the game screen is always on top instead of just being covered.

How can I create an X window/client that is on top of all other windows, not under WM control and has no input? (overlay, OSD)

I want to write applications (or use existing ones, that would be even more convenient) that behave like a hardware screens OSD (on screen display), only without input.
That is: A graphical output (e.g. from a GUI toolkit like Qt or Gtk) is placed on a layer where it is above even fullscreen-windows like Firefox F11 mode or a video player in fullscreen mode. That includes "above" the mouse cursor as well, so technically and graphically the mouse cursor would move below this widget.
I don't know about real fullscreen applications with SDL or OpenGL though, but this is not the requirement. If you know this as well please include it in your answer.
Real world applications are read-only overlays like a little webcam window, a TV-station like logo or premade annotations. So all in all this is meant for live presentations, streaming and recording of screencasts and tutorials with minimal post processing.
My own hacked, unsuccesful, experiments showed at least that removing this window from the WM control ( I did this by choosing a GTK popup dialog instead of a real main window) lets you position in absolute coordinates and it will ignore things like virtual desktops and workspaces, which is good, so you can switch between those and the overlay/HUD will stay in place.
Of course this cannot be done in software with the same Z-value (top/bottom windows) as the hardware screen. So technically I am talking above all other windows but below the screensaver or lock-screen layer.
+1 internet for linking to docs and giving the right keywords.
+2 internet for a working code example, language, gui-toolkit etc. doesn't matter.
You probably need composite overlay window from Composite extension - see section 3.2 "Composite Overlay Window" extension docs. (cursor is above this window)
Version 0.3 of the protocol adds the Composite Overlay Window, which
provides compositing managers with a surface on which to draw without
interference. This window is always above normal windows and is always
below the screen saver window. It is an InputOutput window whose width
and height are the screen dimensions. Its visual is the root visual
and its border width is zero. Attempts to redirect it using the
composite extension are ignored. This window does not appear in the
reply of the QueryTree request. It is also an override redirect
window. These last two features make it invisible to window managers
and other X11 clients. The only way to access the XID of this window
is via the CompositeGetOverlayWindow request. Initially, the Composite
Overlay Window is unmapped.
Example using node-x11:
var x11 = require('x11');
x11.createClient(function(err, display) {
var X = display.client;
var root = display.screen[0].root;
X.require('composite', function(err, Composite) {
Composite.GetOverlayWindow(root, function(err, overlay) {
// already automatically mapped here:
//
// CompositeGetOverlayWindow returns the XID of the Composite Overlay
// Window. If the window has not yet been mapped, it is mapped by this
// request. When all clients who have called this request have terminated
// their X11 connections the window is unmapped.
});
});
});

Three.js First Person Controls moves the camera all the time

The game I'm designing currently requires a first person controller and luckily Three.js offers that class as well.
However I can't stop the camera from flying around. I know that the mouse movement causes the fly because it happens as soon as I move the mouse. But reading the js code,I cant find the attribue which causes this movement. Here is how I initiate the controls:
controls = new THREE.FirstPersonControls(camera);
controls.movementSpeed = 0.1;
controls.lookSpeed = 0.001;
controls.lookVertical = true;
I do not want the view direction to change when I am not moving the mouse.
any idea ?
Keep in mind that the FPS style mouse movement in webGL is usable rather only in a full screen mode. If an application runs in a standard windowed mode, the cursor is visible, and the application can not detect cursor movements that cross the edge of the window. This makes it impossible to look around in the FPS style (look movement stops when the cursors reaches the window edge).
This is probably the main reason why a PointerLockControls demo asks you to switch to the full screen mode.
With FirstPersonControls the look movement continues when the mouse reaches the edge. Such approach works well in the windowed mode.
You might want to use the PointerLockControls instead
See an example here:
https://github.com/mrdoob/three.js/blob/master/examples/misc_controls_pointerlock.html

Unbind Key Presses

I'm making a game that involves, like all games, key presses. Only left and right arrow and the Space Bar. They work, but the browser is pre-set to scroll left, right, or jump down on those keys. Is there any way to unbind those keys in the code? Thanks.
you should be able to prevent the default browser behavior by returning false after the key is pressed. However depending on how you are intercepting the key events it seems to work different on different browsers and even for different types of keys (alpha vs 'command' keys)
jquery preventDefault and stopPropagation might also work,
the comments at the bottom of this documentation give alot of good hints
http://api.jquery.com/event.preventDefault/
based on the info there I put this small bit of code together, seems to stop the space bar and down / up arrows from moving the scrollbar in both opera and firefox
try this code (jquery needed) in firefox with firebug console enabled
$(document).bind('keydown, keypress', function(event) {
console.debug(event.keyCode + " - " + event.which);
// event.preventDefault();
return false;
});

Resources