I need to create a very simple program, that should run on raspberry pi without network connection. The program should first show one full-screen bitmap ("insert disk"), and after receiving somehow an external signal (disk inserted), another bitmap which would ask to input password. After inputting the password (each pushed button shows an asterisk *) the application should show yet another bitmap, which would inform whether the password was correct or not.
So in principle I would like to create something that looks like password screen in any Hollywood movie!
Raspberry should boot directly to the application.
I was expecting that this would be easy to do (and it would be if we could use Windows and Visual Studio), but I haven't yet found a simple tool to create this for pi. Booting Raspberry into browser with kiosk mode and creating HTML application seems like an overkill.
Although a browser in kiosk mode might look that a sledgehammer to crack a nut, I think you might find this nut harder than it looks.
It wouldn't be difficult to write a simple app in Java, or Python, or perhaps even C using GTK, that carries out the actions you want. You could have the app loaded when X starts, as an alternative to a desktop and Window manager. You could even do away with X altogether, and write some code that interacts directly with the video framebuffer and the keyboard hardware. Or, heck, go the whole hog, and have your code substitute for the operating system kernel :)
I would guess that even the simplest of these approaches involves more work than hacking something up using a HTML and JavaScript in a browser.
Related
How would I go about detecting if my go CLI program is in focus or minimized?
Current program based off https://github.com/jroimartin/gocui
I require the functionality as it is a chat program and I would like to send OS notifications but only when the program is not in focus or is minimized.
Your help/direction is much appreciated as of right now unsure where to start.
This is not possible from the library itself. A command line program does now have a focus, but the terminal program it is running in.
To implement that (if possible at all) would be dependent on os, window manager etc.
To refine the answer provided by #mbuechmann, I suggest the OP not to try to resort to APIs etc.
The reasoning is simple.
"Contemporary" users are used to running programs in terminal emulators which are typically presented as separate windows, and so the users naturally think of these programs as not really different from GUI apps.
But the reality is different: a terminal emulator—whether graphical or not (for instance, so-called "virtual consoles" provided by the Linux kernel running on an x86/amd64 hardware are terminal emulators as well)—really emulates a typical work session on a real hardware terminal, and there, a program would work in foreground solely, and the only means of "switching" to another program was using the shell's job control (those jobs, bg and fg commands).
In other words, the whole concept of a program working in a terminal has an inbuilt assumption that the terminal is always "foreground"—since at the time the concept was developed, a terminal was a physical device.
Now please also consider that "terminal emulation" may be more pervasive on a contemporary system than you might think: screen and tmux on a Unix-like OS are multiplexing terminal emulators—which may themselves be run in a terminal emulator, and a console window on Windows™ may be considered to be a terminal emulator of sorts as well.
So, "resorting to APIs" have several technical problems:
Terminal emulation tries to actually decouple the program which uses this facility from being aware of how the facility is actually provided.
To put it simple, there's, say, no easy way on X Window System, to know what window is used by the terminal emulator running your program.
You'd need to cover diverse set of APIs in order for your program to still be useful: X Window System on Unix-like systems, Mac OS, Windows™. And contemporary GUI stacks running on Linux tend to be switching to Wayland instead of X.
In certain cases, like running a program in a "nested" terminal emulation sessions (for example, a pane in a "window" of a tmux running in xterm), figuring out such facts about the environment might be next to impossible.
And still the crucial problem is that if your program really needs to know whether it's focused or not, it actually wants to be aware about the concepts currently hardly accessible to it. I mean, it wants to be GUI. And if so, just make it GUI.
In fact, it may be simpler than you think. The core of your program might still be a CLI app with a thin GUI wrapper around it which uses any sort of IPC to talk with the app (which might be two-way, if needed).
The simplest is to write some (usually line-wise) data to the program's standard input.
I wrote a compiled MATLAB GUI that we run on a remote machine via Remote Desktop. Overall it runs fine, but sometimes the GUI will blank out many of the control objects (buttons, table, popups). It seems to happen after the screen of the client computer has been locked or after the GUI has been minimized.
If you move the mouse over the buttons, popups, or table headers, they reappear. The table cells will reappear if they are selected. The GUI hasn't crashed and still works fine, but the objects just disappear until you make them reappear again. I have only seen this happen when using remote desktop (Windows-Windows using Remote Desktop Connection).
How can I get this to stop happening? It isn't really breaking anything, but it is very annoying.
I don't know if this is an issue with MATLAB or with the Remote Desktop configuration, so I posted this question here. Feel free to move this to superuser if you think it's more appropriate.
Remote Desktop has issues with handling low level rendered graphics, and interacting with graphics cards. In our experience (we use Nvidia GPU's for rendering and computation engines on multiple projects/applications) we have found remote desktop to fail in so many cases, that we have ditched it for a third party tool.
I suspect this is what you are running into.
One option I would consider, is forcing Matlab to do software rendering, if this fixes the problem, then for certain it's the graphics cards. The first hit on a google search for "matlab software rendering" returns the matlab command opengl. Reading the documentation page for that, gives the command:
opengl software
It sounds like the remote desktop minimization is causing it. For efficiency, Windows will disable various graphics when a Remote Desktop window is minimized on the client computer. To prevent this, create and set a DWORD RemoteDesktop_SuppressWhenMinimized to 2 at the following registry location:
HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client
After doing this minimizing and locking your screen shouldn't do anything to the RDP session. I doubt it's a graphics card issue, as Windows 10 Creator's Edition allowed remote sessions to use the remote graphics card just like as if you were running locally.
I want to develop App with GUI, that can be run without showing GUI. How I can do it?
If it's possible would this App work on servers that do not have nothing related with GUI (ex: can I work with such App with ssh or so).
Any example please if it's possible.
Yes, it isn't always easy though and might not be worth it. The general idea is to write a console program that attempts to dynamically load the gui libraries and create a window. If that succeeds, it detaches from the console/controlling terminal and becomes a gui program. On Windows, this may pop up a console window briefly when the user double clicks the exe as it would be created first, then quickly destroyed.
You would want to dynamically load the gui with dlopen/LoadLibrary because the libs might not even be present on the computer you're running on, and if you rely on the system to load them at startup, your program won't run at all when they are missing. This is the most painful part - checking the return value of XOpenDisplay or CreateWindow or whatever is easy, and detaching from a console is easy (FreeConsole or fork). But first you need to get your program to actually start in the worst case scenario of no client side gui libraries at all.
If you're ok with ignoring that case - if the libs are present but the display isn't, you just handle it as a regular runtime error - then it isn't too hard at all.
Years ago, there were functions in Win32 whereby the app could check to see if a user was running the app via Terminal Services/Remote Desktop. I thnk it was something like:
GetSystemMetrics(1000H)
Is there a system call one can make to check to see if a Win32 or Win64 app is being run remotely via a program like GotoMyPC or LogMeIn?
No, there is not. Those are third party apps doing their own video/input capturing and network streaming. They are plain ordinary apps as far as Windows is concerned. Terminal Services is built into Windows, which is why there are APIs to query TS status.
The only way I can (currently) think of, other than using the aforementioned API call, is also seeing if any particular processes you can identify are running (e.g. GotoMyPC or LogMeIn... they will have some process running). Without doing too much research, they may be running without actually having someone using them. If, however, they launch something to do the streaming, you could check for that.
Just to make sure that this isn't an XY problem, what is it that you're trying to do - and perhaps there is another way?
I want to make a windows application whose GUI will be streamed to another device (allowing remote control). The point is that I'm not willing to rely on creating Windows Sessions to isolate the GUI I/O's (1)
To achieve this, I started observing some existing solutions that are able to enable remote access using this premise to see if I could get a clue about where to start.
One of these solution is Winflector (BTW: it is free up to 2 connections).
I got interested in this solution because it seems (I'm guessing) it detects only the repainted regions. What I took from my observations are that:
While the streamed application is "invisibly" running locally in the same session I'm logged in (it shows the application process in my task manager), the application window seems not to be created anyhow - at least Inspect can't get any window information/handle of the application process - It looks like sort of a "GUI StdOut Redirection".
Apparently, no additional Desktop is created;
Also apparently, no Mirror Driver is installed;
Using Process Explorer, I found out Winflector adds some thread's to the original application process. I suspect it is about the GUI redirection (by the thread's names);
The application is started by the Winflector server - that is, it has control about the CreateProcess arguments.
What is the most likely technique to be used in this case?
Windows Hook?
Windows Messages interception?
Special Display Driver?
Sort of Memory Device Context?
Where should I start researching to get a similar approach? Any open source project regarding this subject would also be very welcomed.
PS: By my programming experience, this is sort of a whole "new world" - sorry if my questions are redundant/obvious/non-sense.
(1) That is, this application could be spawned, streamed and interact
with the remote client using the same session which a local user is
already logged in, without conflicting the IO (like a regular VNC
would do, for example). PS: At this moment, I'm focusing only at the
output.