Re the all-splash log. What is the output of"inxi -G"? Do you get background colors on the virtual terminals?

over here: antix-14-console-decoration-t5034.html
you mentioned"virtual consoles" and, at the time, I was not seeing those.
As of the patched 14-alfybeta2 (May?) I began seeing the"picture frame with squashed globe" at startup...
...but didn't begin seeing that frame during shutdown until this (Oct2014) version.
Because 1920x1080 isn't a provided option (and so everything looks blurry/squashed) I didn't bother to check out messing with color schemes...

Here, at reading"virtual terminals" I was thinking roxterm,lxterminal,urxvt...
...but then I recalled that you posted separately about urxvt color schemes rocking-urxvt-with-style-t5048.html
so I guess"virtual terminals" ~="virtual consoles".
Just now, I re-read the t5034 thread, and finally tested
splash-select and splash-term {theme-name}
Prior to messing with those, I suppose the"default theme" was in effect (a dark, dark blue bg, which I figgered was black?)

Why doesn't the main screen of splash-select bother to mention"press h for help" ?
Upon displaying the first screenful of helptext, the prompt reads"press h for help or q to quit"
(at this juncture, it would be equally (in)accurate as"q to quit, any alphabetic key other than z, s, c, or v to display more helptext)
At the second screenful... now user is told to press enter (not h), and is told to press q to quit... but pressing q displays yet another page...
(Hey, that's what testers do -- we nitpick)
Umm, what else? Uppercase"C" does not, as indicated, change text alignment. It is treated same as"c" (light/medium/dark)

Maybe (or not) the content of /var/log/spash-all.log is more meaningful in light of the above.

minimize to tray would probably be a welcome feature for search-bar

The problem was that unless everyone has those bash aliases then the shorter versions of the commands break mysteriously.

if populated via etc/skel ...how the hell could everyone not have those bash aliases?

Making them actual commands seemed more robust. I also had longer commands for the clipboard searches but this polluted /usr/local/bin and was confusing.

In my earlier post, I refrained from suggesting to roll 'em into a single executable and handle as args, ala
sb g linuxrootkit
sb ddg happymeal
(considered suggesting that because"sb g" seems an unlikely typo for me)

One quick fix might be to require a command line parameter (perhaps"--" or even"--clipboard") to activate the clipboard search. So"g" alone does nothing."g skidoo" searches for"skidoo". and"g --" searches for what is in the clipboard. I have never wanted to do a clipboard search from the CLI. Although that may be because I have two copies of the search-bar on my screens. Do you think"--" or"--clipboard" is better? I guess it depends on how often you want to do a clipboard search from the CLI.

I think"goog" as the executable name (or alias) is plenty short, and changing to that seems like less work than revising the script to accommodate additional optional argv parameters.

I have never wanted to do a clipboard search from the CLI.

Wow, i expected that (cli) to be the primary use case.

other considerations:
Might a user ever install a package which contains an executable named"wiki"?
Might a user already have an established habit of aliasing"antix" or"imdb" to some other application?

posting to confirm that I am now able to run persist-save from cli
yayYAYyay! Thanks!

skidoo wrote:if populated via etc/skel ...how the hell could everyone not have those bash aliases?

One problem area is runboxes where you open up a little window to run commands. That is a very popular way (for me) to run searches but many of those run boxes don't use a .bashrc file.

In the runbox I constructed out of zsh, over half the history lines start with"g". This despite the fact that in that runbox unrecognized commands default to doing a Google search. So I will compromise to"gg" but no further.

I have never wanted to do a clipboard search from the CLI.

Wow, i expected that (cli) to be the primary use case.

If I am at a command line (or in a run box) then I just type in my search criteria. It is very awkward to use a mouse to highlight text and then switch to the keyboard to run a search on the highlighted text.

My primary use cases are: A) typing in the search command and arguments in a terminal window/runbox and B) highlighting text with a mouse and then selecting to do a search with that text using the mouse.

Proof of Concept for a Search-bar tray icon

This version *work* with the existing search functions. You will have to download and install the icon. Left-click on the icon will do a StartPage search. Right-click on the icon will open up a menu to let you choose what search to do. There is another version that works with the latest scripts on
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/BitJam/Search-Bar"
linktext was:"GitHub"
====================================
I've compromised and now the"--" argument as well as the"--clipboard" argument will cause the clipboard contents to be used for the search.

I've attached the icon created by Utopia on the MX forums and I've attached a zipped version of the script.