In playing with the curses library, I discovered that if a default color is changed (say COLOR_BLUE, for example) using init_color, that changed color will continue to be used across stopping and restarting my program if I don't reset it back to its original definition. Even creating a new terminal window in which to run the program, the color of blue shows up as defined in the original windows. It even survives running a completely different program.
How is this happening? I would have thought the original definition would be used upon starting a new instance. I can only surmise that these default colors are cached somewhere at the OS level. Can someone explain what is happening here that allows this to happen?
I'm running this on a Centos 7.6 distro.
The colors are maintained/cached/whatever by a given terminal.
If the terminal description has this feature:
orig_colors oc oc Set all color pairs
to the original ones
that would be sent by the ncurses library as part of exiting curses mode.
It also might be sent by reset (or tput reset) command as part of the rs1 string. That's not automatic (and those commands do nothing special with color other than as a side-effect of the initialization and reset strings).
xterm supports a control sequence for resetting palettes back to their default, which was added to the terminal description in
2016-04-23
# + add 'oc' capability to xterm+256color, allowing palette reset for
# xterm -TD
referring to this:
oc=\E]104\007,
That uses OSC 104, which was developed for xterm in patch #252 (2009/12/7):
add OSC 104, for resetting ANSI/16/88/256 colors to default.
However, in discussing CentOS (RHEL), you have to keep in mind that it doesn't get updates for things like that:
The package information says that it has a development snapshot of ncurses from just a couple of days past 8 years ago.
Your terminal may/may not support the control sequence. If you are using xterm, no problem. For anything else (with that version of CentOS), you are out of luck. VTE developers (e.g., gnome-terminal) copied the feature in January 2014, but that version of VTE was released as 0.35.2, while CentOS 7 has 0.28.2
Related
I've installed Karaf 4.1.0 and after opening the console, I've experienced that the commands were disappearing when I was typing them. After inspecting carefully, I've noticed, that their color changed to dark blue, which is for me almost indistinguishable from black background from the distance I sit from my monitor.
Is it possible to revert those colors settings and get back all commmands simply in visible white? It's very uncomfortable to type something you can't see...
In
$KARAF_HOME/etc/shell.init.script
add following command:
setopt disable-highlighter
then restart karaf.
The colors can be configured via property HIGHLIGHTER_COLORS as documented for the Apache Felix Gogo command line shell used within Karaf.
For instance assign
HIGHLIGHTER_COLORS = "fu=32;1:bf=31;1"
within the Karaf shell for bright green functions fu=32 and increased red bad functions bf=31;1 to gain improved readability on a black terminal background.
The color settings can be persisted to be enabled on each Karaf start via adding the above configuration line to the
karaf/etc/shell.init.script
You can use any Ansi Escape Code for configuring the shell color.
This works for us on Apache Karaf 4.1.2 and we are happy (again) now with the new coloring feature :-)
I've got a bit of an interesting problem here. There are plenty of threads I've found where people are working to hide or get rid of a cursor on an embedded Qt GUI...but I'm trying to get a cursor to show up on an embedded Qt GUI.
I inherited a project that was 'finished' some time ago, and the person who did the most work on the project has moved on. Fast forward to today and there is a need to add a cursor to this functional touchscreen GUI. The system OS is Yocto Linux, and it is running a Qt 5.4 application on a framebuffer.
I've scoured the Qt code and there is nothing there that would hide a cursor. I've added in the appropriate QT_QPA_FB_HIDECURSOR=0 environment variable to my Qt startup script. I've experimented with adding a QCursor obejct to the GUI. Unfortunately none of these things are working. Using the QCusor I am sometimes able to get a cursor up on the screen, but isn't tied to the touch input (the cursor shows up at the position I programatically move it to, but it stays there when I interact with the GUI).
My touch input events are tied into Qt (via QT_QPA_GENERIC_PLUGINS=evdevtouch and QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS=/dev/input/event9:rotate=180), but for some reason that touch input cannot be tied to a cursor.
At this point I've spent a few days messing around with environment variables and startup script modifications, but nothing I've done has got the result I'm looking for.
Does anybody out there have some ideas on where to look for solutions to this problem?
Thanks!
Ian
So, now 3 months later I think my team and I just came up with a passable solution to this problem.
The path towards the solution started with the Qt Documentation on "Using libinput". The documentation boils down to a few important statements:
Parameters like the device node name can be set in the environment variables QT_QPA_EVDEV_MOUSE_PARAMETERS, QT_QPA_EVDEV_KEYBOARD_PARAMETERS and QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS
The mouse cursor shows up whenever QT_QPA_EGLFS_HIDECURSOR (for eglfs) or QT_QPA_FB_HIDECURSOR (for linuxfb) is not set and Qt's libudev-based device discovery reports that at least one mouse is available. When libudev support is not present, the mouse cursor always show up unless explicitly disabled via the environment variable.
The evdevtablet plugin provides basic support for Wacom and similar, pen-based tablets. It generates QTabletEvent events only. To enable it, pass QT_QPA_GENERIC_PLUGINS=evdevtablet in the environment or, alternatively, pass -plugin evdevtablet argument on the command-line. The plugin can take a device node parameter, for example QT_QPA_GENERIC_PLUGINS=evdevtablet:/dev/event1, in case the Qt's automatic device discovery (based either on libudev or a walkthrough of /dev/input/event*) is not functional or misbehaving.
So, in my system I have the device nodes: event0, event1, event2, event3, event4, event5, mice, and mouse0. Because I'm trying to get the mouse working, I made the assumption that I'd have to use the mouse0 node. This lead to me setting these environment variables:
QT_QPA_GENERIC_PLUGINS=evdevmouse
QT_QPA_EVDEV_MOUSE_PARAMETERS=/dev/input/mouse0
Much to my frustration these environment variables led to nothing. After some time my team and I figured out how to get debug output from Qt source on our system:
Modifying source code in the qtbase directory under our yocto build (roughly /yocto/poky/build/tmp/work/temp build directory/qtbase
Copying qtbase/plugins/generic/libqevdevmouseplugin.so to my hardware (roughly /usr/lib/qt5/plugins/generic)
Running Qt from the command line
We quickly discovered that the input events coming from mouse0 and mice were basically garbage data. On our system we did set up EVDEV in the kernel, so the mouse input was also tied to the device node event0. When we tried setting the Qt mouse parameter to event0 we started to see debug output that looked like real data.
QT_QPA_GENERIC_PLUGINS=evdevmouse
QT_QPA_EVDEV_MOUSE_PARAMETERS=/dev/input/event0
However, the problem of no-mouse-pointer still remained. After a while we looked back at the Qt Documentation, specifically at the 2nd paragraph listed above. As a last ditch attempt we tried adding in the QT_QPA_FB_HIDECURSOR environment variable...
QT_QPA_GENERIC_PLUGINS=evdevmouse
QT_QPA_EVDEV_MOUSE_PARAMETERS=/dev/input/event0
QT_QPA_FB_HIDECURSOR=0
And...voila! After countless hours of debugging and reading documentation, we finally got a mouse pointer.
I think the main crux of our issue was misinterpreting the Qt Documentation.
The mouse cursor shows up whenever ... QT_QPA_FB_HIDECURSOR (for linuxfb) is not set
By "not set", Qt means explicitly defined as FALSE...not simply "not set" at all.
This solution will work for us, but it does leave at least one thing to be desired. Along the way I stumbled across this thread answer on the Unix StackEx which points to the Kernel documentation of input/input.txt. In section "3.2.2 mousedev" you can see the line:
Each 'mouse' device is assigned to a single mouse or digitizer, except
the last one - 'mice'. This single character device is shared by all
mice and digitizers, and even if none are connected, the device is
present. This is useful for hotplugging USB mice, so that programs
can open the device even when no mice are present.
What this means for us is that while we can use event0 (which goes away when we unplug the mouse) for our mouse input event handling, we won't be able to support hot plugging without making some kernel/Qt-source modifications or figuring out how to get mice working as a Qt mouse input parameter.
So, the question of "why does event0 work and not mouse0/mice" still stands...but for now we've got a solution we can live with.
UPDATE: Now a little bit later we've figured out that udev was not working properly on our system. We added udev to the RDEPENDS in our package group for the Yocto build, and now we can set
QT_QPA_GENERIC_PLUGINS=evdevmouse
and we get a working mouse pointer with hotplug support.
I dont know if this applies to your problem (i dont use QT), but there is a
HAVE_TOUCHSCREEN=1 variable in the machconfig file. It is located normally in your BSP-layer in a recipes-bsp/formfactor/formfactor directory.
Setting this to 1 makes the cursor invisible.
Try setting it to 0
I have setup ConEmu with Cygwin and Zsh quite a while ago. So far everything is working good.
I'm very interested in changing my oh-my-zsh theme to "agnoster"..
I've installed the powerline fonts and turned on the xterm256 colors as requested.
I'm still having problems with the colors though, the cwd path has the same color of the background (and appears to be hidden), no matter which color scheme I use.
Anyone had luck with that?
In my case, the issue was a combination of having a background image with a black background configured and the value for Replace Color Indexes being set to #1.
I had reset according to this comment:
After reading about -basic, I realized it something with my configuration. Reset it to default.. and configured from the beginning.. it works perfect now, I really really appreciate your help.
Everything was fine after the reset, so I went through and added my background image. That was fine, but because of the black background on the image and the fact that I was using transparency and a slightly off-black background, I started playing with that setting and once set to #1, it failed. I also noticed that the tooltip indicated that the default setting is #0 #1 (though after reset, it was set to *).
I have this problem on every host I run ConEmu on. Every host was setup several months ago and all have that same background image. I don't recall ever setting the Replace Color Indexes setting when I set it up -- heck, I didn't even know what that did so I can't imagine setting it. I'm guessing it might have been a default in an earlier version (I run the alphas) that, perhaps, carried over due to my setting it up a while ago?
I suspect, in my case, that this was the entire issue and that there wasn't something else going on. I saw the correct background to my prompt in PowerShell, but I use a hard-set value to an RGB color and take advantage of TrueColor ANSI support (which, when it fails, falls back to something that's not #0 or #1).
So, at least in my case, it definitely wasn't a bug -- it was doing exactly what it was asked to do, replacing a "blue" #1 background with the black from my image which yielded black-on-black text. I'll try changing that field on my other laptop exhibiting this problem when I'm home to confirm an alternative to resetting the entire configuration.
From the many posts on how to change emacs' default font, it seems as though emacs 24 should have an option called "set default font" under Menu --> Options. As you can see from the image below, I'm given no such option. (The only option related to fonts is "Set default font".) I've tried adding various scripts to my .emacs file which are intended to change the global font, yet the default persists.
I've downloaded and installed Inconsolata via sudo apt-get install fonts-inconsolata (ttf-inconsolata no longer works) and I've also run sudo fc-cache. Given the usual answers don't seem to be working, I'm lost on what to do next...
At this point, I'm suspecting if I need to make a shell-level (or possibly system-level) change in settings in order to enable font selection on emacs (i.e., similar to ensuring that my XTERM color settings were 256 color in order to get Zenburn to work; am a Linux newbie if it isn't obvious - just trying to brainstorm here).
Version info, if helpful: I'm running Ubuntu 14.04.1 (Xubuntu), emacs 24.3.1 and am launching via "emacs -nw" from the default Xubuntu shell.
Here's what I see when I go to the Menu and then select Options (i.e., pressing "F10", then "o"):
The simple answer is that Emacs can't change the font of the terminal. It can only set the colour (and possibly adding bold and underline properties). This is true for all console mode programs. You need to run Emacs in GUI mode to enable full font selection.
I have an SDL2 windowed window accessed via Derelict 3.
It is supposed to strobe black and white (not because I hate epileptics), and it does this successfully. However, after a certain period of time, Ubuntu 13.10 marks the window as 'unresponsive', grays it out, and dulls the strobe effect.
This is highly irritating and totally kills the effect required by the application for visual stimulation to retrieve SSVEP readings from my EEG headset.
How do I get my OS to realize that the window is doing exactly what it should be doing?
Code
As I have wrapped the SDL calls in my actual code, I'm going to provide pseudo-code and the SDL methods called in those sections (I've checked that I'm not calling any other SDL functions):
make a window using SDL_CreateWindow (no set flags)
make a renderer using SDL_CreateRenderer (with presentvsync flag set)
for( ... )
{
fill screen black using SDL_RenderFillRect and SDL_SetRenderDrawColor
update screen using SDL_RenderPresent
fill screen white (same as above filling)
update screen (same as above update)
}
exit
I pedantically check error codes and return values for all SDL calls in the wrapper lib. They're all fine. What I need to know is what I must add to provide the heartbeat to my OS so it stops graying out my window.
Another thing...
Could someone please add an SDL2 tag? SDL2 has a very different API from SDL1.2...
Added event processing into the loop via SDL_PollEvent(null). This satisfied the OS.
For anyone using Ubuntu 16.04 and SDL2.0x -
The solution that worked for me was:
SDL_SetHint(SDL_HINT_VIDEO_X11_NET_WM_PING,"0");
set immediately after your SDL_Init(); call.
see : SDL2 wiki here.