Skip to main content

guake 类quake的下拉终端 | guake: a quake-alike drop-down terminal

平时需要个顺手的终端,希望呼之即来,挥之即去的。gnome-terminal 本身不错,但是呼叫用鼠标太慢了,最近考虑绑定个super+t之类的,但是每次开启也比较慢,另外不好隐藏,而且如果运行一个程序就想隐藏了,一会儿再回来找它看结果也不方便。

于是就想起了guake,以前装过,没好好设置,这次设了一下,还不错,主要是设了透明,去了tab和滚动条,失焦自动隐藏,绑定呼出/隐藏快捷键为super+`。

于是感觉生活太美好了,而且这样呼出一个terminal确实如quake系fps游戏一样,感觉在和系统核心打交道。

[Update] 刚看了一下guake源码,原来还有很多隐藏的gconf可以调整。现在把resizer也去了,完美了~



I really need a handy terminal in my daily life, I want it to appear as soon as I call it, and I want it to disappear when I do not need it any more. gnome-terminal itself is good, I've been using it, but maybe it is not quite suitable for this task, as it's too slow to call it, and I've considered to bind a shortcut super+t to call it, but it will not be convenient when I run something on it, hide it and want to see the result later.

The I recalled guade, I had tried it before, but without a deeper look. This time I went through the settings and make it a really handy terminal. Basically I adjusted the transparent background, hide the tar bar and scroll bar, make to auto-disappear when losing focus, and at last I bind the shortcut calling/hiding it to be super+`.

Then my life changed! It really likes those terminals in those fps game in quake style, and it dos make feeling communicating with the core of the system.

[Update] I found several hidden gconf settings after a quick browse of its source code. Now I've hidden the resizer, making guake perfect!

Comments

Popular posts from this blog

A Rocky Migration: Moving from docker-compose to Podman and gVisor

I've been running a few containers for several years. They were all running under rootless Docker with a single user. Initially, I planned to  migrate the containers to VMs , but I couldn't get a stable workflow after about two months of effort. Later,  gVisor caught my attention , and I decided to migrate to Podman with gVisor instead. The new plan is to run each container with  --userns=auto  and use Quadlet for systemd integration. This approach provides better isolation and makes writing firewall rules easier. I'm now close to migrating all my containers. Here are a couple of rough edges I'd like to share. Network Layout I compared  various networking options  and spent a few hours trying the one-interface-per-group approach before giving up. I settled on a single macvlan network and decided to use static IP addresses for my containers. To prevent a randomly assigned IP address from conflicting with a predefined one, I allocated a large IP range for my ...

Exploring Immutable Distros and Declarative Management

My current server setup, based on Debian Stable and Docker, has served me reliably for years. It's stable, familiar, and gets the job done. However, an intriguing article I revisited recently about Fedora CoreOS, rpm-ostree, and OSTree native containers sparked my curiosity and sent me down a rabbit hole exploring alternative approaches to system management. Could there be a better way? Core Goals & Requirements Before diving into new technologies, I wanted to define what "better" means for my use case: The base operating system must update automatically and reliably. Hosted services (applications) should be updatable either automatically or manually, depending on the service. Configuration and data files need to be easy to modify, and crucially, automatically tracked and backed up. Current Setup: Debian Stable + Docker My current infrastructure consists of several servers, all running Debian Stable. System Updates are andled automatically via unattended-upgrades. Se...

mkosi: First Impressions

I stumbled upon the Gentoo wiki page for systemd-nspawn , which in turn led me to nspawn.org , mkosi , and later systemd-sysupdate . mkosi quickly caught my eye because it's almost exactly what I wanted to build myself, as mentioned in a previous post . So, I decided to spend my "sysadmin fun quota" on it. Overview mkosi is similar to docker build or podman build , but it's designed for creating full OS images. It focuses on development and testing. For example, much like nix-shell , mkosi can quickly launch a sandboxed shell with a specific distribution and selected packages installed. The systemd project itself uses mkosi for testing across different distros. The re-introduction article  is a great read. Speed Note that this is by no means a rigid benchmark. My setup is an SSD with LUKS and an ext4 filesystem (without reflink support). Building Container Images mkosi is pretty fast. A simple mkosi command creates a fresh Debian image. I used the --incrementa...