I have Debian 2.6 running on a SBC that I plan on using in an embedded setup. What I need to do is configure it so that linux will start up and run just my Qt GUI application. Do I need a window manager to do this or can I just do it with X11. Also because it is going to be for an embedded system I do not want to load any desktop manager. Any info on how this can be done would be great!
Yes you can do this without a window manager.
first: You need to boot into a non X session, init level 1 or 3.
second: You need to start the X server, in a basic mode by just calling X or xinit.
third: Start your app. You may need to take a little more control over where your app is positioned on the screen and its dimensions in your code, as you will not have a window manager to help with this.
alternatively: you can launch one of the more basic window managers to see how they play with your system. Motif Window Manager (mwm) and Tab Window Manager (twm)
Note: While working without a window manager, you may get into a state where you cannot do some very basic operations (ex: close a window, move a window, resize a window). You may find that you cannot survive without at least some of the more basic window management functions. Until you close the loop on this, remember, Ctrl + Alt + Backspace will kill the XServer.
If you want to start your app just with X11, you need do:
copy file /etc/X11/xinit/xinitrc to ~/.xinitrc
write all you want to run to it
run command startx
It worked for me and I hope it will help you
Related
I am trying to run x11 on cygwin, mainly to run xfig utility, and I am facing a problem.
When I run xinit to start x11, I get a big popup window with one terminal open. But I am unable to open any other terminals in it. To be more specific, when I run "xterm &" in it, a new terminal opens up but it sits on top of the old terminal, and there is no way I can move this window, so the old terminal is as good as useless to me, till I kill the new terminal.
I also tried running "xwin". There a big window popped up, but it does not contain any terminal, and I cant open any terminal, whether by left or right clicking.
I also tried running "startx". A big window opens up but gets killed automatically after a few seconds.
How can I use x11 effectively on cygwin? As of now, I can use with "xinit", but with only one terminal.
The proper mode to start the Xserver on cygwin is to use starxwin.
From its manual:
The startxwin script is a front end to xinit(1) that provides a
some what nicer user interface for running a single session of the X Window
System in multiwindow mode. It is often run with no arguments.
To move windows around, you need to have a window manager running. You can start this either from the xterm, by passing the name of the window manager as an argument to startx, or by starting it from your X11 startup configuration (memory says that would be ".xinitrc" in your home directory on most unix boxes, but I am not sure if that's true on Windows using Cygwin). The .xinitrc file is "just" a shell-script, with the end of the script indicating "X should shut the server down now" (see example at the end).
There are many possible window managers, including fvwm2 (which according to your comment, you managed to find on your own). A full list of X11 window managers is probably too long to fit in this answer (there are many, there are new ones popping up, and old ones going out of maintenance on an ongoing basis). Some of the not entirely uncommon ones are fvwm2 (already mentioned), cinnamon, twm, ctwm, ratpoison, ... For a more up-to-date list, ask your favourite search engine for "list of X11 window managers".
Example .xinitrc file:
# This is an example .xinitrc file, starting first an xterm,
# then a window manager. As the X server terminates when this script
# does, we start the X terminal in the background, but the window
# manager in the foreground, so that "WM exists" signals "X server shuts down"
xterm &
fvwm2
I've created a small NodeJS script that compiles down using EncloseJS so the app becomes its own binary. The app is meant to run in Terminal and be interactive with the user. I'd like to package this in a .app so it feels like a full application that regular users can run.
How can I go about this? I've so far tried Platypus with mixed results as it doesn't seem to exit correctly.
Try the following:
Use [Apple]Script Editor to create a new script and save it as an application.
Place your binary - let's call it foo - in the new .app bundle's Contents/MacOS subfolder.
Place the following code in the application's AppleScript:
set embeddedBinary to POSIX path of (path to me) & "Contents/MacOS/foo"
tell application "Terminal"
do script quoted form of embeddedBinary
activate
end tell
When you run the application, the embedded binary is opened in a new Terminal window that you can interact with.
Append & "; exit" to the do script command to automatically close the Terminal window when the binary terminates.
Note, however, that your application merely act as a launcher for the embedded binary:
It terminates after the Terminal window has been created
so its Dock icon only shows up briefly and disappears again
and you'll get no application menu (which wouldn't be an option anyway, given that your binary runs in Terminal).
Every time you start the app, a new Terminal window is opened, even if your binary is already running in one.
There are ways to address these issues (except the menu one), but they require additional work - see below.
A solution that addresses above issues for a more integrated experience:
It keeps the wrapper application open (showing its own Dock icon).
It relays activation to the launched Terminal window running the embedded binary when the app is activated (e.g., by clicking on the Dock icon)
The wrapper application terminates automatically when the launched Terminal window is closed.
However, it has limitations:
Sadly, to relay activation, GUI scripting is needed, which requires a one-time authorization with administrative privileges on any given machine; the user is prompted on first launch, but it requires a few steps.
For the application to be able to quickly relay activation when clicked and to quickly quit when the Terminal window closes, its on idle event handler must be invoked frequently, which consumes CPU resources, although the extra load on the CPU is pretty small - see comments in source code below.
Instructions:
Use [Apple]Script Editor to create a new script and save it as a stay-open application:
In the Save As dialog, choose format Application and check the Stay open after run handler checkbox.
Place your binary - let's call it foo - in the new .app bundle's Contents/MacOS subfolder.
Place the following code in the application's AppleScript:
# Global variable to track the launched Terminal window (tab).
global g_winLaunched
on run
# Get full path of embedded binary.
set embeddedBinary to POSIX path of (path to me) & "Contents/MacOS/foo"
tell application "Terminal"
# Launch embedded binary in new Terminal window, and
# have the window closed when the binary terminates *successfully*.
# This leaves the window open in case of error - whether on
# initial launch or on existing - giving the user a chance to investigate.
do script quoted form of embeddedBinary & " && exit"
set g_winLaunched to front window
end tell
end run
on idle
if frontmost of me then # If this app is activated, relay activation to the launched Terminal window.
try
# Activate the running window using GUI scripting.
# Sadly, `set index of g_winLaunched to 1` is NOT enough to activate the window.
# NOTE: This requires that this app be authorized for assistive access via
# System Preferences > Security & Privacy > Accessibility.
tell application "System Events"
perform action "AXRaise" of window (name of g_winLaunched) of process "Terminal"
end tell
activate application "Terminal"
on error
tell me to quit # Window is no longer alive, quit this app.
end try
else
# See if tab is still alive, and, if not, quit this app.
try
id of g_winLaunched
on error
tell me to quit
end try
end if
# Call this handler every N seconds.
# This is a trade-off between responsiveness and CPU usage.
# With 0.3 secs., CPU usage of this app is around 0.8%
# on my 3.2 Ghz quad-core Intel Core i5 iMac.
return 0.3
end idle
You can try JXcore which offers native packaging (self executables) of Node.JS apps with a single command, like:
$ jx package myapp.js MyApp -native
Then you can just run it on OSX (or other unix systems):
$./MyApp
For Windows (if you would ever need it) the file name would be MyApp.exe.
More on this here: Packaging & Code Protection.
When working in GUI we do alt-tab (or cmd-tab in mac) to switch between multiple programs, for example I am writing a text file in a text editor and then I do alt-tab to switch to already running browser to google up something then I alt-tab again to come back to keep editing.
How do you perform such "switch between" programs in command line interface - for example working with a ssh command line shell?
EDIT: I forgot to mention it, I am using ssh to connect to my university's server, and they don't have screen & tmux installed, and my account have no right to install any new apps... Is there any built-in functionality to perform this task, or any work around? For exmaple can I "minimize" running proggram and come back to regular shell interface, do some work, then display the "minimized" process again?
Another workaround: use the shell's job control, eg if you're editing a file, CTRL-z pauses the editor and brings you back to the shell, where you can compile, see manpages, browse the web or whatever -- and of course you can background the browser or anything else.
Screen command offers the ability to detach a long running process (or program, or shell-script) from a session and then attach it back at a later time.
As a crude workaround, run multiple terminal windows on your computer, and alt-tab between them.
Incidentally, at the Linux console, you can switch virtual terminals with ctrl+alt+F for at least F1 through F6, commonly F8 or more (depends on how the distro sets them up). Not your case, I know, but in case future visitors should benefit.
If you are comfortable in Emacs, it allows you to run multiple independent ansi-term buffers.
You can also use "GNU screen" to emulate multiple terminals in one terminal.
I want to implement a simple specialized window manager for presentations (not user-controllable) that supports only the following operations:
Moving and resizing of windows
Switching desktops
Starting applications not on current desktop (in background) without disrupting current image.
I don't need any user input, button/titles, ...
What existing window manager should I use as example? There are many little "hello world" window managers, but they usually does not support desktop switching.
You don't need to reimplement the wheel.
openbox will do everything you mention and more besides.
Simply edit the rc.xml to disable the root menu, and re-launch.
Openbox also allows per app setting so that certain applications can open on a particular desktop by default, or with a particular size, or open hidden.
It also supports wildcards in the window selection, so that settings can apply to all windows.
devilspie2 is a window matching utility that can perform actions whenever a window opens.
It is highly hackable and the code is available on github. It will match windows by name/class/etc when they open, and perform actions on them. (including matching all windows and moving them to a different desktop. It will work with most window managers.
Based on the original devilspie which does not have Lua scripting, but is configured using s-exprs instead.
xdotool will also allow you to perform complex actions on windows without hacking any code. It will even fake user input (mouse/kbd) if you need it.
There are a few window managers written in Python that could be good starting points. Qtile and whimsy both describe themselves as hackable.
I am working on old Motif-based application for Linux. I want to be able to programmatically change the active window of our application. I can redirect the input by using XSetInputFocus() function and the keyboard input start to go there, but XReconfigureWMWindow() and XRaiseWindow() functions just don't work.
I've read that Window Managers try to stop this behaviour, so tried to disable configure redirection, but this doesn't work either. Any ideas how to make one of my own windows on top of the window stack?
There is a tiny program called wmctrl available (at least in Debian/Ubuntu it is in standard distribution) which is able to perform many operations on windows and desktops, and handles plenty of window managers. I'd suggest testing whether it works in your environment, and if so, peeking at its sources.
You may find the answer to this is dependent on the Window Manager the user is using, or even what settings they've given to the Window Manager. I like to set my Window Managers to do "focus follows mouse", which means you can't send the focus to a window that I haven't put my mouse on, unless you also warp the mouse there (is that function called XWarpMouse?).