I am creating a GUI interface that will be using a 7" touch display with a raspberry pi 3. I want the GUI to take the place of the desktop, I do not want it displayed in a window on the desktop. any thoughts on how to do that. I have read the raspberry pi documentation to edit the rc.local script to start the application at login, but I can not figure out how to set up the python GUI with out creating a window
-
This sounds dangerous. In any case, it's likely to depend on the operating system you're working with. – Arya McCarthy May 25 '17 at 19:00
2 Answers
Your pi boots up and displays a console - just text - by running a program (getty). Then you run another application called a graphical display manager which then runs a window manager. On a pi it is usually gnome but there are many others,.. this window manager is what displays your GUI window. What you want is obviously possible, it is just that it is non-trivial to do. What you are talking about is either kiosk-mode application still running 'on the desktop' as you say but which obscures the desktop completely and does not allow you to switch or de-focus or an even more complicated JeOS like Kodi/XBMC bare metal installation running without your current window manager. Your python would have to do the job of the display manager and the window manager and it would be very, very slow.
Use a really light window manager and go kiosk mode. Or you could go with text! There are libraries eg ncurses but I'm not sure how that would work with your touch screen display.

- 115
- 1
- 9
-
How do I give you half an up vote??? Bravo for remembering of kiosk-mode. But what are you talking about slowdowns and I don't know what!??? You run one application, X gets commands and draws graphics. Faster than anything that is managed from outside. Only one problem may occur if your app opens new windows. Then you would have to implement window switching manually. – Dalen May 25 '17 at 20:09
-
If the display in Q is registered as mouse, then it would work in text mode. With or without ncurses. – Dalen May 25 '17 at 20:13
1. Disable graphical interface i.e. stop the desktop manager from running. On Raspbian you can use raspiconfig to do it.
2. Set up autologin into bash
3. Block startx from automatically running desktop manager
4. Add your app to be started from .bash_rc when autologin is performed.
To setup autologin first create a script called autologin in /bin directory that does:
#! /bin/bash
/bin/login -f pi
Note: pi is an user on raspbian that won't ask for password when sudo-ing.
To use the created script edit /etc/inittab:
Scroll down to where terminals are assigned and change tty1's line to be:
1:2345:respawn:/sbin/getty -n -l /bin/autologin 38400 tty1
Take care that ids are matching old tty1 settings. Then in the user's home directory (/home/pi) add (if it's not already there) a file named ".xinitrc" containing just:
#! /bin/bash
cat
This will prevent X server from invoking desktop manager when started.
Now add in /home/pi's .bashrc your app or better a script that will run your app (at the end):
export DISPLAY=:0
/home/pi/Desktop/appstart &
startx
And appstart is:
#! /bin/bash
# Wait a second for X server to start:
sleep 1
# Now X is running and we have to switch into video terminal using chvt (change virtual terminal) command
# Graphic terminal is on Raspbian tty7
sudo chvt 7
# Start the app:
python /home/pi/Desktop/myapp/myapp.py
After all this is set up what will hapen is the following:
1. You run Raspberry Pi and it autologins into user pi
2. When Bash logs in it executes /home/pi/.bashrc
3. .bashrc sets $DISPLAY variable because there are no X displays yet, runs starting script as a background job and starts X server.
4. X server won't enter desktop manager because /home/.xinitrc will stop it step short of it.
5. Starting script sleeps for a second to ensure that X is running and able to send graphics to tty7, switches to tty7 so that user doesn't have to do it manually, and then runs your application which will show up. If your app is not graphical you will see only one big nothing. :D
Problems here are that you definitely should create an user just for this stuff. If your app crashes or user switches to tty1 and terminates X there he/she is in bash, logged in.
Depends on what level of security you need. You can do a lot of things to prevent abuse. For example, use fcntl to change mode tty1 is in so that it cannot receive key input any longer. Or use some other tricks, or rearange this procedure somewhat, or ensure that tty1 runs everything in jobs with nohup, then logs out etc, etc.

- 4,128
- 1
- 17
- 35
-
thank you for your inputs this helps focus me on a potential solution - I'll have to play with this to see which works best - Cursers will not work as I will be creating a GUI, but I think your suggestions will allow me to move forward - Again , thank you – Kurt Jun 25 '17 at 12:32