Sway: Verify sway commands match i3 commands

[progandy]

There are at least some commands that don't support the same boolean representations, for example focus_wrapping. sway only allows yes, no and force. i3 allows anything.
force is matched the same,
yes can be anything that eval_boolstr recognizes (1, yes, on, true, enable, active)
no is everything else

[ddevault]

We should probably use something similar to eval_boolstr ourselves.

[ianyfan]

Made a start. Most seems to be there, mainly issues of documentation.

@SirCmpwn moved this list into the top-level description so that GitHub can track the progress of this issue

[ddevault]

Thanks for putting that list together, much appreciated! I went through and crossed out some things that don't make sense for sway to implement.

• [ ] font (sway: can be command)
• [ ] workspace_layout default|stacking|tabbed (sway: can be command; allows auto)
• [ ] set $ (sway: can be command, despite documentation; if is given without $, the $ is silently added instead of error)
• [ ] workspace output
  (sway: can be command)
• [ ] workspace_auto_back_and_forth yes|no (default: no) (sway: can be command)
• [ ] show_marks yes|no (default: yes) (marks starting with _ will never be drawn) (sway: can be command)

Can you elaborate on these? Are these just differences with i3 rather than things sway is missing (save for better set docs)?

• clipboard
• seamless_mouse

These aren't present on master, was this list prepared against 0.15?

[ianyfan]

was this list prepared against 0.15?

I accidentally started on the 0.15 docs and when I switched to the 1.0 docs I forgot to check ones that were removed.

The ones that I put "can be command" means that in i3, they're only supposed to be used in the config file but in sway they can also be executed at runtime. I don't know if you want to change it. Otherwise, it works as well as in i3.
(I was going to put a note about that in the original comment but forgot)

I also noticed a few markdown escapes I missed, I'll fix that.

[ddevault]

Gotcha, thanks

[ianyfan]

Actually, if primary outputs aren't being supported you can mark them off.

[ddevault]

Good call, updated.

[ianyfan]

i3-gaps:

• [x] gaps (though setting for workspace syntax is slightly different)
• [x] smart_gaps on|off
• [x] smart_borders on|no_gaps|off
• [x] hide_edge_borders smart_no_gaps

[martinsb]

I noticed that "tiling" and "floating" criteria do not work.
Ex. for_window [tiling] border none yields error that Token 'tiling' is not recognized. The same happens if using floating criterion.
EDIT: forgot to mention, using version 1.0 alpha 6.

[ddevault]

Thanks @martinsb, @RyanDwyer fixed that in #2755.

[ddevault]

All done! Special thanks to @ianyfan for their hard work on shoring this up.

[ndrewtl]

Hooray! Thank you so much @SirCmpwn and all contributors for making this happen. This project is so exciting, as is wl-roots. Huge shoutout to everyone volunteering hours of their lives to make this work, and many thanks!

[orestisfl]

New stuff in i3 4.16:

• strip_workspace_name yes|no - https://i3wm.org/docs/userguide.html#_strip_workspace_numbers_name
• title_align left|center|right - https://i3wm.org/docs/userguide.html#_window_title_alignment
• i3-msg: add support for the SUBSCRIBE message type - https://github.com/i3/i3/pull/3435
• border toggle now accepts an optional pixel argument - https://i3wm.org/docs/userguide.html#_changing_border_style
• resize set now accepts the width and height keywords - https://i3wm.org/docs/userguide.html#resizingconfig
• allow multiple assignments of workspaces to output - https://i3wm.org/docs/userguide.html#workspace_screen

[ddevault]

Can you open a new ticket for those things?

[orestisfl]

A new ticket for each or a single for all?

[ddevault]

Up to you.

[Arnaudv6]

disclaimer: never used i3 and really new to this all.
And I know this is hackish/defeating.
But those lines in config should work isn't it?
for_window [class="[.]*"] floating enable, focus;
I also tried this one:
for_window [id="[.]*"] floating enable, focus;
yet I get Token 'class' is not recognized
respectively Token 'id' is not recognized

[Arnaudv6]

Should I open a new bug?

[ddevault]

Yes. And send a patch

[Arnaudv6]

3653

@ddevault: I would take years to send a patch there really sorry, just hope this gets tackled before.

[ddevault]

That's total horseshit.

[paualberto]

What about set_from_resource? It's strikethrough'd in the issue, but not sure if it's implemented, this breaks compatibility with i3 configs

[RedSoxFan]

What about set_from_resource?

set_from_resource loads a value from the X resource database. Sway does not use the X resource database and there is not a Wayland equivalent.

[paualberto]

set_from_resource loads a value from the X resource database. Sway does not use the X resource database and there is not a Wayland equivalent.

You're right, appearently this is what the i3 guide says.
I was using set_from_resource $user echo "$USER" which actually work for getting your username into i3 config to write multi-user configs. It also works for reading any other env variable.
Is there another way to read env variables in sway config?

[RedSoxFan]

I was using set_from_resource $user echo "$USER" which actually work for getting your username into i3 config to write multi-user configs. It also works for reading any other env variable.

You can just replace it with set $user $USER (or better yet, just replace all instances of $user with $USER). See https://www.reddit.com/r/i3wm/comments/4zq30r/is_there_a_way_to_use_bash_environmental/d6y50tt/

Is there another way to read env variables in sway config?

No, there is no way to read an environment variable's value into a sway variable

[emersion]

You can use command substitution in include directives, e.g. include `hostname`.conf.

[Patricol]

Couldn't find a more relevant issue for this:

set $<name> <value> doesn't work inside mode <name> {} blocks, which doesn't match i3's behavior.

Is that a bug, an intentional divergence, or an oversight?

Also, @RedSoxFan, i3's set_from_resource $<name> <resource_name> <fallback> does allow for the inclusion of a fallback. If drop-in compatibility with i3 configurations is desired, sway could just interpret set_from_resource commands including <fallback> args as set $<name> <value (fallback)>.

In interpreting my 450 line i3 config file, those are the only two stumbles sway had.

[RedSoxFan]

set $<name> <value> doesn't work inside mode <name> {} blocks, which doesn't match i3's behavior.
Is that a bug, an intentional divergence, or an oversight?

I think this is an oversight since they don't really have any relation to modes since they are not scoped. I'll submit a PR to allow it -- Submitted as #3940

sway could just interpret set_from_resource commands including <fallback> args as set $<name> <value (fallback)>

I have no problem submitting a PR to add this for i3 compatibility and just documenting that the fallback is always used and the command only exists for compatibility with i3 configs. @ddevault @emersion any objections?

[ddevault]

I'd rather not implement set_from_resource, no.