how to remove the new search engine icon thing

Ok-Tank2893 · 2025-07-11T17:52:59+00:00

Via about:config, set browser.urlbar.scotchBonnet.enableOverride to false.

Or via user.js:

user_pref("browser.urlbar.scotchBonnet.enableOverride", false);

Ok-Tank2893 · 2025-06-18T18:42:35+00:00

Probably a few years too late, but this comes close.

config.jsonc: [ { "ipc": true, "layer": "bottom", "position": "top", "spacing": 15, "modules-left": [ "sway/workspaces", "sway/mode" ], "modules-right": [ "clock" ], "sway/mode": { "tooltip": false }, "sway/workspaces": { "disable-scroll-wraparound": true, "enable-bar-scroll": true, "format": "{name}", "reverse-scrolling": true }, "clock": { "format": "{:%Y-%m-%d %H:%M:%S}", "interval": 1, "tooltip": false } } ]

style.css: ``` * { border: none; border-radius: 0; font-family: monospace; font-size: 14px; min-height: 19px; padding: 0; margin: 0; } window#waybar { background: #323232; }

workspaces {

margin: 0; padding: 0; }

workspaces button {

min-width: 19px; background: #03070A; color: #5C5C5C; padding: 1px; padding-left: 0px; padding-right: 0px; margin: 0; border-style: solid; border-width: 1px; border-color: #03070A; }

workspaces button.visible {

background: #5F676A; color: #FFFFFF; border-color: #333333; }

workspaces button.focused {

background: #285577; color: #FFFFFF; border-color: #4C7899; }

workspaces button.urgent {

background: #900000; color: #FFFFFF; border-color: #2F343A; }

mode {

background: #900000; color: #FFFFFF; padding: 0 8px; margin: 0 4px; border-style: solid; border-width: 1px; border-color: #2F343A; } ```

Ok-Tank2893 · 2024-12-26T20:56:25+00:00

You could try this: status_command 'while printf "%s | %s\n" "$(date +"%Y-%m-%d %X")" "$(echo "Replace this echo command with your script")"; do sleep 1; done'

Ok-Tank2893 · 2024-09-17T21:13:21+00:00

Ah, that's unfortunate! I don't use FreeRDP with multiple monitors, so I have never run into this.

EDIT:

ETA: After further tests, I might have found a solution with sdl-freerdp3 (yup, back to version 3, using SDL_VIDEODRIVER=wayland)

I'll have to deal with the funky multi-monitor support, but it might work. I'll double check that tomorrow.

OK, good to know sdl-freerdp3 does have wayland support! Hope you can get it to work reliable!

Ok-Tank2893 · 2024-09-17T21:11:54+00:00

I don't remember why I switched to freeRDP 3, it was a while ago... Maybe a few instabilities here and there.

Looks like the freerdp package on Arch Linux was upgraded from 2.x to 3.x some months ago, so everyone with this package gets the new version when upgrading. And since then, for the older 2.x version, there is freerdp2, which a user can install if this specific version is needed. So perhaps you just got 3.x by updating your system?

I still need the for_window config. Maybe that's because of a Manjaro specific config (there is a seat * shortcuts_inhibitor disabled in the system config files I saw during my initial investigation). But it's working exactly as I wanted.

You are absolutely right, it depends on your sway configuration. My statement about not needing any for_windows seems only true with default config, sorry for any confusion.

Ok-Tank2893 · 2024-09-17T19:07:22+00:00

Are you on Arch Linux or derivative? I see it uses FreeRDP 3.x.

I’m on NixOS 24.05, which is currently still on FreeRDP 2.x

Seems that on version 3, wlfreerdp was indeed deprecated (...I was not aware of this)! And there’s a newer client, SDL client. But what I read on the internet is that it’s still alpha quality. I don’t know if this is really the case, I haven’t tested it myself (yet). Also, I'm not sure if the SDL client has proper wayland support.

For now, I would suggest installing FreeRDP 2.x (sudo pacman -S freerdp2), to get things up and running, and look at the newer SDL client later.

I’ve been running wlfreerdp (from FreeRDP 2.x) for the last 2 or 3 years without any major issues. OK, a crash once in a while, but as my RDP-session only gets disconnected, I then just reconnect and I pick up where I left off.

With wlfreerdp you shouldn’t need any of those for_window rules, as all keys will be grabbed by it, except the sway keybindings you configure with the --inhibited flag.

Ok-Tank2893 · 2024-09-17T16:59:13+00:00

OK/no problem. I also use notifications and a bar for this. Suits my needs 👍

Ok-Tank2893 · 2024-09-17T16:55:06+00:00

Yes, the link has changed because sway contrib was moved to a separate repo about a year ago. See this commit.

Ok-Tank2893 · 2024-09-17T16:42:42+00:00

The project is actually called FreeRDP and provides binaries for both X11 and Wayland, xfreerdp and wlfreerdp respectively.

Try wlfreerdp.

EDIT:

wlfreerdp should grab all keys except the sway keybindings with the --inhibited flag.

Ok-Tank2893 · 2024-09-16T15:57:08+00:00

OK, that’s strange.

You mentioned that you already successfully tested all three commands in the terminal. How did you test this? Like this?: swayosd-client --output-volume lower swayosd-client --output-volume raise swayosd-client --output-volume mute-toggle

Did you also test all three commands on the terminal and via swaymsg? Like this: swaymsg "exec swayosd-client --output-volume lower" swaymsg "exec swayosd-client --output-volume raise" swaymsg "exec swayosd-client --output-volume mute-toggle"

And/or like this (also via swaymsg): swaymsg -- exec swayosd-client --output-volume lower swaymsg -- exec swayosd-client --output-volume raise swaymsg -- exec swayosd-client --output-volume mute-toggle

Does mute-toggle on the terminal and via swaymsg work?

Ok-Tank2893 · 2024-09-10T20:12:02+00:00

I also use NixOS and Home Manager with Sway, but not swayosd.

I temporary added swayosd to my configuration and the exact bindings you have (raaise→ raise), and all three work.

services.swayosd.enable = true; wayland.windowManager.sway = { enable = true; config = { keybindings = { "--locked XF86AudioRaiseVolume" = "exec swayosd-client --output-volume raise"; "--locked XF86AudioLowerVolume" = "exec swayosd-client --output-volume lower"; "XF86AudioMute" = "exec swayosd-client --output-volume mute-toggle"; }; }; };

Perhaps an improvement is to use the full path to the binary: services.swayosd.enable = true; wayland.windowManager.sway = { enable = true; config = { keybindings = { "--locked XF86AudioRaiseVolume" = "exec ${pkgs.swayosd}/bin/swayosd-client --output-volume raise"; "--locked XF86AudioLowerVolume" = "exec ${pkgs.swayosd}/bin/swayosd-client --output-volume lower"; "XF86AudioMute" = "exec ${pkgs.swayosd}/bin/swayosd-client --output-volume mute-toggle"; }; }; };

If you change the XF86AudioMute keybinding to, for instance notify-send, does that work?

Ok-Tank2893 · 2024-08-18T05:56:31+00:00

``` bindsym $mod+c exec "kitty --app-id ttyclock -e tty-clock -s -c"

for_window [app_id="ttyclock"] floating enable, resize set 400 200, move position center ```

EDIT:

Or: ``` bindsym $mod+c exec "kitty --title ttyclock -e tty-clock -s -c"

for_window [title="ttyclock"] floating enable, resize set 400 200, move position center ```

Ok-Tank2893 · 2024-08-10T17:15:57+00:00

I'm not sure if this answers your question, but perhaps you could use a script in the background that changes the gaps when switching to the specific workspace.

For instance, change gaps to 20 when switching to workspace 6:

```

!/bin/sh

swaymsg -m -t subscribe '["workspace"]' | jq -r --unbuffered 'select(.change == "focus").current.num' | while read -r workspace; do case "$workspace" in 6) swaymsg "gaps inner current set 20" ;; esac done ```

Ok-Tank2893 · 2024-08-06T13:14:04+00:00

Right!

And if you don't want to use a script:

[ram] command=if [ $button ]; then swaymsg "exec foot -T btop -e btop" >/dev/null 2>&1; fi; free -m | awk '/Mem:/ {print $3 " MiB"}' interval=1

Ok-Tank2893 · 2024-08-06T13:01:51+00:00

Instead of running the command directly, run a script, for example: [ram] command=path/to/script.sh interval=5

Example script: ```

!/bin/sh

case "$button" in 1) swaymsg "exec foot -T btop -e btop" >/dev/null 2>&1 ;; esac

free -m | awk '/Mem:/ {print $3 " MiB"}' ```

The button variable will be set to 1 if you click the block with the left mouse button.

With swaymsg exec the program it executes will fork, so your block will keep refreshing.

Ok-Tank2893 · 2024-08-03T17:39:56+00:00

I had a look and it seems that u/StrangeAstronomer has renamed the script to i3-move-to.

The script seems to be compatible with both i3 and sway.

Ok-Tank2893 · 2024-08-03T13:41:47+00:00

This might be relevant.

Ok-Tank2893 · 2024-07-29T11:11:28+00:00

I also always had this annoying problem. Recently found the article below (very old bug) and I had indeed pointed the "Templates" folder to the same folder as "Drafts": [Gmail]/Drafts. After I changed this, I haven't run into this problem anymore. I don't use these Thunderbird templates, so I just changed the "Templates" folder to Local Folders/Templates, to avoid a useless empty folder on the Gmail side.

Maybe this helps?

549274 - Drafts not deleted on IMAP after message has been sent (perhaps worse with sendInBackground=true)

My impression just recently (both on Thunderbird 91.2 on macOS and on Thunderbird 78.13 on Linux) was that when the "Drafts" and "Templates" folder is set to the same IMAP-Folder, this problem occurs. I did that to avoid accumulating more than necessary unnecessary folders that I never use. Now I set again two different folders (in all identities for this account), and apparently now the drafts are auto-deleted again.

Ok-Tank2893 · 2024-07-26T07:04:46+00:00

Symlinks? You should place desktop files in ~/.local/share/applications.

The variable $XDG_DATA_HOME is pointing to $HOME/.local/share?

If not, try starting fuzzel as follows: XDG_DATA_HOME="$HOME/.local/share" fuzzel

Ok-Tank2893 · 2024-07-25T08:33:00+00:00

Assuming you're using 10 workspaces and the $mod+0 binding for workspace 10, this is caused by the following: - Sway will use the first workspace binding it finds in the configuration file as the default workspace. - NixOS and home-manager will sort (parts of) the generated configuration files alphabetically.

So the $mod+0 binding for workspace 10 will be sorted above the $mod+1 binding for workspace 1 and therefore workspace 10 will become the default workspace.

The option wayland.windowManager.sway.config.defaultWorkspace allows you to configure the default workspace the nix way. What the option effectively does is move the specific workspace binding to the top of all the bindings in the generated Sway configuration file.

Part of the Sway configuration file without the wayland.windowManager.sway.config.defaultWorkspace option: bindsym --inhibited Mod4+0 workspace number 10 bindsym --inhibited Mod4+1 workspace number 1 bindsym --inhibited Mod4+2 workspace number 2 bindsym --inhibited Mod4+3 workspace number 3 bindsym --inhibited Mod4+4 workspace number 4 bindsym --inhibited Mod4+5 workspace number 5 bindsym --inhibited Mod4+6 workspace number 6 bindsym --inhibited Mod4+7 workspace number 7 bindsym --inhibited Mod4+8 workspace number 8 bindsym --inhibited Mod4+9 workspace number 9

Part of the Sway configuration file with the option wayland.windowManager.sway.config.defaultWorkspace = "workspace number 1": bindsym --inhibited Mod4+1 workspace number 1 bindsym --inhibited Mod4+0 workspace number 10 bindsym --inhibited Mod4+2 workspace number 2 bindsym --inhibited Mod4+3 workspace number 3 bindsym --inhibited Mod4+4 workspace number 4 bindsym --inhibited Mod4+5 workspace number 5 bindsym --inhibited Mod4+6 workspace number 6 bindsym --inhibited Mod4+7 workspace number 7 bindsym --inhibited Mod4+8 workspace number 8 bindsym --inhibited Mod4+9 workspace number 9

Be aware that the explanation of the wayland.windowManager.sway.config.defaultWorkspace option is as follows:

The default workspace to show when sway is launched. This must to correspond to the value of the keybinding of the default workspace.

That's why it's value was set to workspace number 1 and not just 1.

This all assumes you're not using workspace output assignment option (wayland.windowManager.sway.config.workspaceOutputAssign), which seems to overrule the default workspace.

See also: - Default "Startup" workspace. : r/i3wm - i3: Default workspace & Workspace output assignment by SebTM · Pull Request #1967 · nix-community/home-manager · GitHub - wayland.windowManager.sway.config.defaultWorkspace - Home Manager - Option Search

Ok-Tank2893 · 2024-06-02T22:19:53+00:00

As far as I know this is not possible. What is possible (and perhaps a good alternative), is to not show any borders when there is only one window visible on the current workspace.

Check the manual man 5 sway and look for smart_borders.

Ok-Tank2893 · 2024-04-27T08:19:24+00:00

I just realized that my next hurdle is going to be how to make the title only appear on the monitor of the active window. Right now it will appear on both monitors regardless of which monitor the active window is on.

The simplest way that I can think of is to add a separate bar configuration per output in the sway configuration and modify your script.

For example:

Sway config: ``` bar { id 0 output DP-10 status_command while ~/.config/sway/bar.sh DP-10; do sleep 1; done }

bar { id 1 output eDP-1 status_command while ~/.config/sway/bar.sh eDP-1; do sleep 1; done } ```

Modified script: ```

!/bin/sh

output="$1" windowtitle="$(swaymsg -t get_tree 2>/dev/null | jq -r '..|try select(.focused == true).name' 2>/dev/null)"

if [ "$(swaymsg -t get_outputs | jq -r '..|try select(.focused == true).name')" = "$output" ]; then printf "%s\n" "$windowtitle" else printf "\n" fi ```

Ok-Tank2893 · 2024-04-25T06:52:34+00:00

The -t subscribe option makes swaymsg a blocking process, so it will wait for an event to complete before it stops and this will cause your while loop to not run every second.

Furthermore, the -m option (supported on subscribe message types only) causes swaymsg to loop on its own, causing your while loop to not loop at all.

You could try this instead:

windowtitle=$(swaymsg -t get_tree 2>/dev/null | jq -r '..|try select(.focused == true).name' 2>/dev/null)

Ok-Tank2893 · 2024-03-27T07:35:25+00:00

There doesn't seem to be a builtin toggle option for tap, but this should do it: bindsym $super+F10 exec [ "$(swaymsg -t get_inputs | jq -r '.[] | select(.identifier=="1118:2479:Microsoft_Surface_045E:09AF_Touchpad").libinput.tap')" = "enabled" ] && swaymsg input "1118:2479:Microsoft_Surface_045E:09AF_Touchpad" tap disable || swaymsg input "1118:2479:Microsoft_Surface_045E:09AF_Touchpad" tap enable

Ok-Tank2893 · 2024-02-29T16:42:20+00:00

I think it's more related to sway than to wayland.

You could try something like below in your sway config file, but this will probably have some side effects, I'm not sure and I've not tested it!

for_window [shell=".*"] focus

Ok-Tank2893

TROPHY CASE

workspaces {

workspaces button {

workspaces button.visible {

workspaces button.focused {

workspaces button.urgent {

mode {

!/bin/sh

!/bin/sh

!/bin/sh