swaywm/sway

i3 feature support

ddevault opened this issue · 129 comments

Layouts

  • Horizontal tiling
  • Vertical tiling
  • Stacked
  • Tabbed
  • Floating
  • Saving layouts to disk will not support
  • Loading layouts from disk will not support

Config/commands

  • Config parser
  • Variables/set
  • bindsym
    • mouse bindings
    • --release
  • bindcode
    • --release
  • focus_follows_mouse
  • exit
  • exec
  • exec_always
  • fullscreen
  • workspace
    • left/right/up/down
    • number
    • next/prev
    • next_on_output/prev_on_output
    • <name>
    • <name> output <output>
    • back_and_forth
  • splith/splitv
  • focus
    • left/right/up/down
    • parent
    • mode_toggle
  • move
    • left/right/up/down
    • workspace to output
      • left/right/up/down
      • named output
    • position
  • kill
  • mode
  • layout
    • stacking
    • tabbed
    • splith
    • splitv
    • toggle split
  • bar
  • floating toggle
  • floating_modifier
  • for_window
  • font
  • default_orientation
  • workspace_layout
  • assign
  • popup_during_fullscreen
  • force_focus_wrapping
  • workspace_auto_back_and_forth
  • scratchpad
    • move scratchpad
    • scratchpad show
  • resize
    • grow
    • shrink
  • move position mouse
  • sticky toggle
  • show_marks
  • no_focus

Features

  • IPC
  • Restart in-place
  • Reload config on the fly
  • Resize containers with mouse
  • Command line options
  • Ignore i3 commands that aren't valid (i.e. force_xinerama)
  • swaybar
  • swaylock - usable, but incomplete
  • swaymsg
  • borders
  • color customization
  • Mode_switch
  • gaps
  • [criteria] command

See also:

IPC feature support: #98
i3bar feature support: #343
i3-gaps feature support: #307

onny commented

Nice write up! Especially looking for a i3 statusbar

It'll probably be a while before I tackle i3bar (swaybar?)

exec implemented.

Today we implemented splith, splitv, fullscreen, and focus. Thanks for helping out, @jdiez17!

workspace [name] done.

You forgot the scratchpad functionality.

Good call.

Nice, I have been looking at i3way but there's no single line of code after so many years.

I want to propose a feature request though, which i3 developers ignored: A tiling mode for binary space layout representing windows as the leaves of a full binary tree, very similar to default window tiling mode that comes with bspwm. It could be very handy letting the software manage my windows(specially terminals) instead of managing the arrangement in a single desktop. I don't want to break any compatibility though so I am hoping it does not.

Also an option to set the gap between windows would be nice. This was done in i3 but by a third party git fork. I don't know why it was deemed not a necessity by i3 developers.

BTW This project should also get its own website.

I want to propose a feature request though, which i3 developers ignored: A tiling mode for binary space layout representing windows as the leaves of a full binary tree, very similar to default window tiling mode that comes with bspwm. It could be very handy letting the software manage my windows(specially terminals) instead of managing the arrangement in a single desktop. I don't want to break any compatibility though so I am hoping it does not.

Perhaps eventually. That doesn't sound like it needs to be a high priority.

Also an option to set the gap between windows would be nice. This was done in i3 but by a third party git fork. I don't know why it was deemed not a necessity by i3 developers.

This is in the list of features to add.

BTW This project should also get its own website.

Yeah, it'll have one eventually.

Also an option to set the gap between windows would be nice. This was done in i3 but by a third >party git fork. I don't know why it was deemed not a necessity by i3 developers.

Due to it not fitting the i3 way, which means using all the screen space. I can understand why, but that doesn't mean this project has to enforce the same rules.

Will have a go at the move command. Should have some results tonight.

Hi. I want to propose a feature request: vertical bar. I think the easiest way is to only do a 90° rotation. The text orientation should be configurable: bottom to top, or top to bottom.

Will consider that once we hit feature parity with i3.

Sway looks like a really great project. I love i3, and the lack of something similar is the only thing that has been stopping me from giving Wayland a try. Great work so far!

However, looking at the list above, I see that sway is still missing tabbed layout, which is essential for my workflow; I use it heavily in i3. This is the main thing stopping me from trying out sway at this point. I could live without the other missing features.

Once tabbed layout is done, I will try playing around with sway. I am really looking forward to it. Hope to catch/report some bugs and maybe contribute some patches.

I honestly think this project has the potential to eventually become even better than i3.

The tabbed layout is sort of blocked by the lack of borders.

@Swoorup This is off-topic, but

This was done in i3 but by a third party git fork. I don't know why it was deemed not a necessity by i3 developers.

We don't want this in i3 for many reasons. For one, the i3-gaps patch (of which I am the maintainer) is really more of a hack (for example, window decorations don't work with it). But that could be solved. However, gaps violate the i3 tiling philosophy and that is why they will never be found in i3 itself.

Being a collaborator of i3 I understand this reasoning, being the maintainer of i3-gaps I obviously personally prefer gaps, though. ;)

Would it be sensible to have our own wallpaper management, or somehow hook into a process like feh?
(and as on a sidenote, how would I hint to sway/wlc that a surface should be drawn behind everything?)

No, we'll have something like feh for you to use instead.

And you can't do that hinting, I've been asking @Cloudef for it in wlc for a while.

hi,
can you add the support to layout keyboard azerty.

That's not really our problem, it's wlc's problem. And wlc let's you set it through XKB environment variables, XKB_DEFAULT_LAYOUT.

@SirCmpwn In the longterm, sway should implement configuration options for input and output devices, but that has to wait until wlc implements an API for that. Maybe even provide some ipc options to allow dynamic changes like xinput/xrandr.
Cloudef/wlc#6
Cloudef/wlc#37

Sway already does provide configuration options to alter the size, position, and status(on/off) of monitors. As of right now dynamic changes are not available though.

Sorry , but the other keyboard are not supported on my pc (fr).
I know i just need to export XKB_DEFAULT_LAYOUT=fr
But i can't use number to switch to other worspace, because on fr keyboard the "1" is "&" and & was forbiden.
Message log:
Bindsym - unknow key &.
Can you help me ?

I used to use bindcode in i3 for unknown symbols. I'm guessing another wlc feature.
On 12 Sep 2015 11:54, tiregram notifications@github.com wrote:Sorry , but the other keyboard are not supported on my pc (fr).
I know i just need to export XKB_DEFAULT_LAYOUT=fr
But i can't use number to switch to other worspace, because on fr keyboard the "1" is "&" and & was forbiden.
Message log:
Bindsym - unknow key &.
Can you help me ?

—Reply to this email directly or view it on GitHub.

bindcode isn't supported on sway yet. Try binding "ampersand".

yes i have try but i have the message.
Bindsym - unknow key &
on the tty, this message error was genenrate by the line:
command.c:154
because you check
xkb_keysym_from_name(split->items[i], XKB_KEYSYM_CASE_INSENSITIVE);

Updated with features from i3 4.11.

Not strictly an i3 feature, but since there is no root window on Wayland, sway now supports setting your wallpaper from the sway config. See man 5 sway for details.

Is it possible to start a program as floating with Sway?

Not yet, no.

@SirCmpwn Would it be possible to change the layout of a window to floating via sway command or sway-msg? Also, what exactly is the proper way of using sway [command]? Every combination I tried just ended up spawning a new sway instance.

sway [command] does not work yet (sorry). You can use i3-msg, it'll work on sway. Use the floating toggle command to change the focused window to floating and back, just like i3.

Ah, that makes sense; I blindly trusted the man page. Thanks, I'll give that a try!

I just pushed swaymsg.

Good news: swaybar is working! It's not completely compatible with i3bar, though. I've made a new issue, #343, specifically to track the progress of i3bar feature parity.

That's pretty cool! You guys move fast. Out of curiosity, do you have a screenshot?

2015-12-16_19 47 52

Note that this is using colors from my sway config.

Cool, thanks. Great work, guys!

Thanks :) and this is just in time for our 1,000th commit, too!

I found a small feature that is missing on this list: workspace number <number>
I use that for my keybindings so that I can easily rename a workspace while keepig the hotkey.

I added it to the list, but I don't understand what it does. Can you explain?

i3 allows you to select workspaces that start with a number before the name using only the number part. You can also define a default name that is ignored if a workspace with the same number already exists. Numbered workspaces are also useful to keep them in the same order regardless of the name.
5.13. Strip workspace numbers: http://i3wm.org/docs/userguide.html#_strip_workspace_numbers
6.7.1. Named workspaces: http://i3wm.org/docs/userguide.html#_named_workspaces

Update: Implemented with PR #352 and #424

I love you for this. I too have grown frustrated with i3way's lack of progress. I can't code very well, otherwise I would have done something :/ Anything I would have made would be horrible, ugly, and slow XD Sway is looking great!

@progandy +1, I have icons as workspace labels and without numbering them, the order changes when switching workspaces.

Looking forward to using this wm! I like the aim to let it just work with your existing i3config. Can't wait for support for assign and tabbed layouts.

@agboom can you create a separate issue about the workspace order changing?

Never mind, I just discovered it's not an issue. Strip workspace numbers work, but double quotes are not stripped as opposed to in i3.

but double quotes are not stripped as opposed to in i3.

@agboom I pushed a fix for that earlier today #444

Wow, that's fast. Thanks!

~/.sway/config, line 16

font pango:DejaVu Sans Mono 9

$ sway

Error on line 16 'font pango:DejaVu Sans Mono 9': Unknown/invalid command

~/.sway/config, line 16

font DejaVu Sans Mono 9

$ sway

Error on line 16 'font DejaVu Sans Mono 9': Unknown/invalid command

~/.sway/config, line 16

font "DejaVu Sans Mono 9"

$ sway

Error on line 16 'font "DejaVu Sans Mono 9"': Unknown/invalid command

(ಠ_ಠ)

@kueea-yumi you can only change the font for the bar not global

swaylock works for me now, can anyone else confirm this? Not going to tick it off until it has some sort of visual feedback of the password entry like i3lock does, though.

I just tested with a color and image. I am able to type my password and get back in with no issue

It seems to work alright for me also.

Sorry to ask like this, but when will the tabbed/stacked layout be implemented ? Or, is it waiting for some other feature. I'm asking because I want to use sway as my daily wm , but these features are essential.
I'm sorry to nag, but just an expected timeline will be fine.

Tabbed and stacking layouts are blocked by window borders, which are a WIP.

Thanks.

On Fri, Mar 25, 2016 at 4:29 PM, Drew DeVault notifications@github.com
wrote:

Tabbed and stacking layouts are blocked by window borders, which are a WIP.


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#2 (comment)

A bit minor and not sure if relevant, but changing the cursor (that swaybar and swaybg) uses should be supported to much i3 feature parity. For now it is set to default what wlc uses (?) and i cannot for the life of me find where it is installed in my system...

@nicman23 that's an issue related to #450 when that's fixed then it will use the correct cursor.

resize set [width] [height] wasn't mentioned on the list.
It resizes a floating window to specified dimensions in i3 (see https://git.io/vwl3L for the spec and https://git.io/vwlse for the impl).

As a heads up, we have resource <…> $<name> <fallback> coming in i3. Since X resources don't exist in Wayland, sway should probably just translate this to set $<name> <fallback>.

This isn't merged yet, though, so it's really just an early hint.

Thanks for the tip, @Airblader. What's that meant to do?

It let's you set variables based on X resources. So instead of having to define the color in the i3 config you can do

resource i3wm.color0 $black #000000

This looks up the resource i3wm.color0 in the X resource database and assigns it to $black. For example, people typically have something like this in their X resources:

*color0: #121212

The last part of the directive is just a fallback in case the resource can't be found (e.g., no match found or if the config validation is called which doesn't have a connection). This is needed to avoid config errors in these cases.

However, the (or a similar) concept of X resources doesn't exist in Wayland, so sway can't do anything useful with this directive. Having the default at least allows sway to fail gracefully, just like in the X case of the resource not being found, by translating this into

set $black #000000

Makes sense. Thanks!

I'm a Debian user who only just yesterday installed and started using i3. I'm liking it. Today, I started wondering about Wayland and stumbled here. This is amazing. Not that I know anything about Wayland except that it's supposed to be the next-generation windowing system following X.

So I have two questions, only the second of which is directly related to sway:

  1. Is it already reasonable to run Wayland these days and have a usable system for getting regular work done, perhaps by way of an X server running on Wayland so that one could run non-Wayland things (Firefox, XTerm)? I notice the xwayland package in Debian but have never played with it.
  2. Is there among the folks here any Debian developer who might make a deb package for sway et al. and get them into Debian unstable, so that one could just install the package and then log into wayland+sway+xwayland via lightdm or some such mechanism?

Is it already reasonable to run Wayland these days and have a usable system for getting regular work done, perhaps by way of an X server running on Wayland so that one could run non-Wayland things (Firefox, XTerm)? I notice the xwayland package in Debian but have never played with it.

Yes

Is there among the folks here any Debian developer who might make a deb package for sway et al. and get them into Debian unstable, so that one could just install the package and then log into wayland+sway+xwayland via lightdm or some such mechanism?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821397

@tevaughan

Yes, sway is good enough for everyday use. Lots of people have been using it exclusively for quite a while now.

That said, there are some bugs and issues that still need to be sorted out, so do not expect to have a flawless experience. The most annoying one IMO is that dropdown menus and similar UI components in X11 apps (in XWayland) don't render correctly in the latest sway. Most of the other issues are fairly small and bearable.

Some features such as changing the video mode (monitor resolution / refresh rate), dynamic hot-plugging / detection of monitors, and monitor power saving (DPMS, turning off the monitor) are not supported yet, so if you need those features, sway might not be suitable for you just yet.

Overall, if you want to have a very good, flawless, feature-complete experience, you should probably wait a little more for sway to mature as a project, but if you don't mind the occasional small issues, and don't require the missing features, you can switch to Wayland+sway now, and help report bugs.

mmlb commented

@SirCmpwn is font actually supported? swaymsg -t command font Hack 12 returns success but nothing changes.

You can't change the font at runtime.

mmlb commented

oic. I'ts not documented in sway.5.txt, shall I open an issue or PR?

It wouldn't be that hard to support, just tell swaybar about the update and refresh window borders.

mmlb commented

@mikkeloscar font for window titles and such, not just bar.

Open a github issue please

What about transparency? For X11 it was done with a separate compositor, e.g. Compton, but what now about Wayland? I didn't see it in feature list, perhaps am I misunderstand something about how it is supposed to work?

FWIW, besides being a fancy, tiling is uncomortable to use without effects like fading or transparency (of inactive windows), because otherwise the focus placement upon switching a desktop is not immediately obvious.

Hey, I know this isn't super important, but I can't help but notice [window_role=] under for_window isn't on the list or mentioned in the thread anywhere.

We don't actually have access to window_role. Not everything that works on x makes sense on Wayland, I'm afraid.

ArenM commented

Assigning windows to workspaces doesent seem to work. Example: assign [class="Firefox"] $w1. when I open firefox it opens on the active workspace not workspace 1. $w1 is set to the name of my first workspace.

onny commented

@arem: maybe it does only work with wayland windows so far?!

ArenM commented

@onny that seems to be the case. Should I file a bugg report?

spagy commented

@ArenM I also found that assigning windows to workspaces didn't work initially. I don't know what you're using to find the class of windows but with xprop there seems to be a list of classes given. I've found that using the first item in the list should work. This involves using Navigator instead of Firefox and urxvt instead of Urxvt, for example. This is from memory but I think this is accurate info.

ArenM commented

Thanks @spagy that is the case.

@spagy That means this is a bug and instance is used instead of class
WM_CLASS(STRING) = [$INSTANCE], [$CLASS]
Edit: AFAIK wlc copies the whole string list from xorg, so it should be stored as $INSTANCE\0CLASS\0. If the view is an x11 view, you should try to parse the class this way I think.

Missing:

  • move workspace to output current
  • move window|container to output current
  • command criteria tiling / floating

And hopefully soon also swap which sway likely wants to have independently of whether i3 will merge it. Unless you already have it, I don't follow sway development.

I see this is an old discussion, but this seems to be the most relevant page: how do I match the window class? I have this in my i3 config:

bindsym m [class="Thunderbird"] focus

which allows me to jump to mail by pressing $alt+m. This does not seem to work with sway

wlc returns the instance instead of the class in the latest stable version. In the next release (and HEAD) it returns the class correctly.

If I read xprop output correctly, the instance of Chromium is "chromium" and class is "Chromium", but

sway assign '[class="chromium"]' 1

does not seem to bring Chromium to workspace 1. And I cannot find a command to focus a Window that matches a criteria. And matching [instance="chromium"] gives an error.

That's not how assign works. You'll have to put that in your config file, reload, and then start Chromium. [class="chromium"] focus should focus the window but I'm not sure if that works on sway yet.

I think I remember seeing that vertical monitors were not supported some time ago. Is that/was that ever true?

@RatanRSur vertical monitors are not presently supported. But that's more of an xorg feature than an i3 feature.

Ah ok, but now, in the wayland/sway pair it's sway's responsibility? Sorry, not sure where the responsibility boundaries lie

Yeah it's sway's problem.

show_marks and [criteria] should be implimented.

Thanks!

We don't actually have access to window_role. Not everything that works on x makes sense on Wayland, I'm afraid.

@SirCmpwn Is there an equivalent in Wayland as far as you know? For example I often use window_role="pop_up" which is common for things intended to be dialogs. When investigating with xprop, window_role was the only distinguishing factor IIRC.

Not really, no.

Can we add i3-input to the list?

Eh, I'm not sure that's worth supporting. It's kind of a stupid feature. I'd just use dmenu. Maybe we can add a script that utilizes dmenu for this purpose, I guess.

I'll just direct people to this comment if anyone else asks for sway-input.

#!/bin/sh
format="%s"
dmenu="dmenu"
swaymsg="swaymsg"
while [ $# -gt 0 ]
do
    case $1 in
        -s)
            swaymsg="$swaymsg -s '$2'"
            shift
            ;;
        -F)
            format="$2"
            shift
            ;;
        -f)
            dmenu="$dmenu -fn '$2'"
            shift
            ;;
        -P)
            dmenu="$dmenu -p '$2'"
            shift
            ;;
        -l)
            echo "Warning: -l is not supported"
            ;;
        -v)
            exec swaymsg -v
            ;;
        *)
            echo "Unknown argument '$1'" >&2
            exit 1
            ;;
    esac
    shift
done
cmd=$(eval $dmenu < /dev/null)
[ $? -ne 0 ] && exit $?
cmd=$(printf "$format" "$cmd")
eval $swaymsg "$cmd"
exit $?

@SirCmpwn regarding the vertical monitor support, could this be added here or addressed in a new issue? Would love to use Sway as soon as that's supported.

It's already supported in wlroots.