I have written some GTK programs using the gtkD bindings for the D programming language that are otherwise console apps, but are capable of displaying plots on the screen and saving them to a file. I'd like to run these on a machine that I only have console-based SSH access to, which means that the plots wouldn't be displayed on the screen, but would still be written to files.
When I call Main.init(), I get a Gtk-WARNING **: cannot open display, as expected. When I call Main.initCheck() instead and ignore the errors, I simply get more errors later in execution related to the lack of a screen.
Is there some easy way to make my program ignore the fact that there's no screen available, do all its on-screen drawing to some dummy device (the graphics equivalent of /dev/null) and still actually draw to Pixmaps and Pixbufs (necessary for saving plots to files) and run the non-GUI-based parts of the app?
Edits: In cases where the app launches a window and blocks on an event loop, the ideal thing to do would be to close the window immediately (or not succeed in opening it in the first place) and continue running the non-GUI based parts of the program. If this is impossible I can work around it by making sure I don't launch any windows.
Also, it appears that Pixbufs and Pixmaps don't work without a screen present. I tried drawing to a Pixmap, creating a Pixbuf out of that, and saving the results to a file, either after calling Main.checkInit() and ignoring the errors or without an init statement and either way GTK complains about lack of a screen.
I believe the simplest solution is to use only GdkPixbufs for processing your plots; as far as I know, the gdk-pixbuf library only deals with pixbufs in memory and doesn't need a window system. Keep the processing and display parts of your code strictly separated. If you do that, it shouldn't matter that there is no screen. You could even make a command-line option to disable drawing to the screen.
You could also use GtkOffscreenWindow but this has only been available since GTK 2.20 and as far as I can tell the D bindings only cover up to 2.18.
Alternatively, you could use X forwarding in your SSH session; use -X or -Y on your SSH command line. See your SSH manual for more information. If you are running an X server on the machine you are SSH'ing from, then the plots can be displayed on your local machine's screen.
Pixmaps won't work without server - they are, by definition (in X terminology), image resources stored on X server. Pixbufs, however, are stored in client application, and they should work without X.
If you need Pixmaps but don't want to graphics, you have two choices:
Enable SSH X tunneling by passing -X flag. In this case, your app will be able to use local X server.
Use Xvfb - it's dummy X server that does no output at all, and all graphics are stored in memory.
Related
In my Electron app, I am trying to use dialog.showOpenDialog() to allow users to choose the image file that they want to open. On Ubuntu 18.04, when they choose an image file, a preview of the image would appear on the right side like so:
https://i.stack.imgur.com/RG6Po.png
However, if the user chooses a file that is too large (typically 1GB+), my app would crashes, with the following being printed on the command line:
tcmalloc: large alloc 1073741824 bytes == 0x32f584ab4000 # 0x7fb5985b16cf
I tried disable thumbnail generation in the Search & Preview tab of the file manager but it didn't disable this right-hand-side preview in the dialog box.
My app works with very large raster files so being able to choose these image files is crucial. I have considered either installing a new file manager or moving my code to another OS, but I want to ask beforehand if there is any less drastic solution that I can take?
The previews are being added to the GtkFileChooserDialog by Electron itself, so changing your file manager or its settings won't have an effect. Changing OS would work, of course, as drastic as it is.
It does seem like Electron should offer an option for turning off previews among the platform-specific ones in dialog.showOpenDialog. At the minimum, it should enforce a reasonable cutoff on file sizes for previews.
To accomplish that, you'd have to patch Electron locally (and then ideally submit a PR). Whatever you decide to do, I don't see a bug reported about this in the Electron repo, so doing that could be helpful to anyone else who runs into the problem.
Programs like less, top, htop, git-log, man and also editors like vi, vim or nano all open in this well known sort of "window" in the terminal, that is different from the typical prompt you normally work with.
Example:
When using cat it simply prints out the results onto stdout and shows you the prompt again.
On the other hand, when using top it goes into this separate "window" to display the information and even update it dynamically. Obviously it isn't a window as we understand it today, it just seems to be a visual trick where they overwrite the entire terminal screen repeatedly. Still, I think the analogy fits.
I was wondering, what is the underlying library or program that is used here? What is the proper name for such a "window"?
I do know about libraries like ncurses, which do similar stuff to what I am talking about, but I cant find any reference that for example top is using this library specifically. Also it looks quite differently from screenshots I have seen - might just be configuration.
I am writing a command line application in Ruby using GLI. My app uses the Bio gem to query PubMed and print out bibliographic information for the results, one by one, to the terminal. The user is prompted for a small amount of information using HighLine, this is recorded to a database, and the display cycle repeats. Here is example output:
I would like to create a frame around my application as it runs to show the key bindings for exit, help commands etc. The text editor nano provides an example:
How can I create a similar frame around my program output, while allowing scrolling within that frame? Is there a cross-platform way to do this? I'd like to handle both Windows and *nix.
I'm working on a unique project using terminal/Shell but I've hit a little bit of a roadblock I haven't been able to work around.
I want to be able to read the content of the location of the cursor.
For example, if the cursor is currently located on line 2, column 5 which contains an E, I want to be able to read that E and create a variable with it.
Can you explain what your project entails? It might help if we knew what you're trying to accomplish.
No tools exist to do this in the shell, as far as I know. To actually read a remote screen would require this as a feature of the remote terminal (or emulator).
Neither do any compiled language support this. All applications that appear to do this fake it by keeping an internal copy of what they assume is displayed on the screen.
Lookup the curses* library for more information. This toolkit allows a programmer to address the screen as a random accessible grid, and hides all of the updates to the actual terminal screen.
See also: ncurses
I'm writing an MacOSX bundled app in GLFW.
When the window pops up, I want it to be on top of all the other windows. I also want it to grab focus (I'm coding in vim, and I type ":make run" -- and I after that, I want to interact with the app).
Question:
1) Is there some API call I can use to make this happen?
2) Is there some configuration I can do in MacOSX to say something like "the program named blah, have it steal focus on startup"?
Thanks!
The cocoa API is [NSWindow makeKeyAndOrderFront:] there's probably something similar you can do from your library.
If you wrap your built executable in a application bundle, then you should be able to open it in the terminal (e.g. via the open command) and the focus will automatically switch to it.
Note that you will probably need to package your application in a bundle anyway.
First, you need to package it because that is what the GLFW FAQ says.
I personally found this to be necessary because, at least in GLFW currently available on github (commit 3e78), atop Mac OS X 10.7.5, the keyboard handling is stolen by the terminal if you don't have the executable sitting in an app bundle.
I witnessed the keyboard-input-stealing behavior occurring even when I manually switched the mouse focus to the window that popped up when I ran the binary. That is, the keystrokes I typed still ended up in the terminal window.
You can test this behavior yourself on your own system by taking one of the example apps for GLFW, like Triangle.app, copy its binary to a different directory, like /tmp/, and then run the binary from there. Here is a demonstration of the distinction I am making.
% pwd
/Users/pnkfelix/Dev/OpenGL/glfw/objdir/examples/Triangle.app/Contents/MacOS
% ./Triangle
(The open command works too:)
% open ../../../Triangle.app
In the above scenarios, hitting ESC with the triangle window focused made it quit, as expected.
However, the problem comes when the program is not sitting in an bundle:
% cp ./Triangle /tmp
% /tmp/Triangle
^[^[^[^[^[^[^
In this scenario, hitting ESC with the triangle window focused passed the keystroke to the terminal window that launched the program. (That is what the ^[ glyphs are -- the terminal responding to the ESC keystrokes it has received.)
The good news is, it is relatively easy to wrap a built executable in a bundle.
For example, when I was doing other experiments with binding the GLFW library, I found the following Makefile rule sufficed for constructing a makeshift bundle from an executable:
test: Triangle.app
open Triangle.app
Triangle.app: Triangle.app/Contents/MacOS/Triangle
Triangle.app/Contents/MacOS/Triangle: triangle
mkdir -p Triangle.app/Contents/MacOS
cp $< $#
(note that the 8-space indented commands above should not be copied verbatim, but rather rewritten as tabs as required for Makefiles).
However, please note that the above Makefile rule is not the official structure for application bundles, and shouldn't be trusted for anything except personal experimentation. Apple has the documentation on how to officially package your application in a bundle, so you should take the time to do whatever steps they describe before you release anything you produce into the wild. (For example, the Makefile rules listed above make no attempt to generate an Info.plist file, which is one of the required components according to Apple's documentation.)