I'm trying to use the ocaml graphics module.
The line:
#Graphics.open_graph "";;
works fine in the interactive module, i.e. a small window pop up in X11 with white background.
However, when I try to use the script mode -- put this line in a file then compile it:
ocamlc -o a.out graphics.cma code.ml
only X11 starts but with no window popup.
Am using a mac. Anyone knows why? Thanks.
Followup:
It seems under script mode the popup window will closeup immediately after code execution. Because if I compile using XTerminal, I can see a small window popup but then closes.
I managed to keep the window open by adding an infinit loop at the bottom:
while true do () done;;
But still don't understand how things really work. Please help. Thanks.
All ressources are freed when the script terminates: memory, file descriptors, including the X window.
If you add an infinite loop, the script does not terminates, and the windows stays open.
Likewise, under the toplevel, the window stays open as long as you don't close the toplevel.
I would suggest to add two lines add the end of your script:
print "press enter to exit"
read one line from keyboard input
This way the script will not terminate until the user presses enter.
Indeed, as jrouquie explains you need to delay the termination of your program. The way I personally do that is by waiting on user input. At the end of the interactive program (or function being studied that opens the graphic mode), I put:
ignore (Graphics.read_key ())
This will wait until a key has been hit on the keyboard, and ignore the key value before returning.
Related
I'm trying to test out if the compiled rust program is portable but the window immediately closes. Opening the program in a terminal in vs code doesn't immediately close the program but waits for you to enter any key before closing. Is there a function or any code that would make it act like that?
Opening the program in a terminal in vs code doesn't immediately close the program but waits for you to enter any key before closing.
I'd guess that's just the vscode behaviour. Immediately closing the window is the normal behaviour for a program terminating.
Is there a function or any code that would make it act like that?
Reading from stdin usually does the trick.
When I am running firefox as my active application and do a [ctrl]+[shift]+T, firefox opens a new tab. Hoever when I do a [ctrl]+[alt]+T, linux opens a new terminal window. Just made me ponder over the possible internals of this operation.
I had assumed that the control over stdin lies with the active application and if it reads something that makes sense to it, it goes ahead and does it. Now I feel that before the input is even put into stdin, the kernel scans it for the shortcuts that are relevant to it, and only the ones leftover are passed onto stdin, and from there to the user space applications.
Is this view accurate?
You are correct about what is causing it, just not the details. It's not the kernel that is swallowing it in this case, it's the Window Manager.
Your keyboard shortcut for Ctrl+Alt+T is getting eaten by your window manager. If you go to your Window Manager keyboard shortcuts, find the one bound to Ctrl+Alt+T and un-define it, it will work in FF properly.
The WM is a "layer" if you will that receives all events and passes on the ones that it determines are relevant to the underlying application.
I am running a big python script on a bash terminal. The problem is that everytime I use Alt+Tab or click outside the terminal into another windows (Say, google-chrome), the program stops execution. Then I need to put the terminal back in focus by clicking inside it to resume execution. This keeps happening all the time.
What could be wrong?
I am using the ncurses library to show some funny output on the screen, but in the middle of the program I need to temporarily exit ncurses mode. I call endwin(), after which my program should be able to use printf() to show a menu to the user. Unluckily, my program was unable to show the menu. I tried using fflush() after printf(), and only then is it able to show the menu on the screen.
Can anyone tell me why, after I call endwin(), the terminal can't return to normal and I'm unable to use printf()?
Use def_prog_mode prior to endwin to save state.
After returning, do: reset_prog_mode and then refresh.
Your original screen will be shown.
Yes, after using printf you have to do: fflush(stdout).
I have an application that sends the focus to other windows but those windows then don't automatically display themselves in the foreground, i.e. on top of all the other windows. Where can I configure the preferences of my window manager so that this is the default behaviour?
In particular I'm using the Ctrl-0 and Ctrl-Shft-0 shortcuts in the MATLAB IDE to move between the command window and the editor window and although the focus seems to be transferred the new window doesn't automatically redraw itself in the foreground.
Not sure of a key binding off hand that does it, but if you alt-click on a window (which allows you to drag a window) it should come to the front.
As codeDr suggests, MATLAB is also kind of bad about repainting its windows. If you draw to a figure while code is executing, the figure does not update unless you execute drawnow or have some similar pause in the execution to allow the GUI to repaint. Since we're talking about MATLAB, the figure command will also cause the indicated figure to come to the front (in fact, it's harder to get it to not come to the front). So you could do figure(gcf) to bring the current figure to the front, or save the figure number with h = figure; and then later do figure(h). Incidentally, if you want to switch current figures without switching focus, set(0, 'CurrentFigure', h) should set h to the current figure.
Your window manager (probably Metacity?) implements focus-stealing prevention so that rogue apps don't pop up windows that would disturb your typing. Matlab needs to raise its window, and give it the input focus with the correct timestamp. If this is being done from a KeyPress event handler, the timestamp for setting the input focus would be the timestamp from the KeyPress event (i.e. the timestamp of the user-generated event that caused a window to be raised/focused).
To politely give the input focus to a window, google for _NET_ACTIVE_WINDOW.
Usually when the window doesn't repaint, it means that the application's main application loop isn't running to refresh the window. Could it be that Matlab is doing some computation or disk activity when you are switching between windows?