i3bar compatability

[ddevault]

These features need to be implemented in swaybar:

• colors
• status_command
• hidden_state / bindsym / modifier
• output
• position
• id
• separator_symbol
• strip_workspace_numbers
• height
• workspace_buttons
• binding_mode_indicator
• mode
• font
• Parse JSON status (with colors etc)
• Mouse events
• click_events
• Tray icons
  • SNI
  • Xembed

[mikkeloscar]

I think font support is missing as well.

[ddevault]

Thanks, added that.

[mikkeloscar]

I don't know if this belong here, but the bar doesn't seem to get fresh bar configuration if you edit the config and reload it from within sway.

[ddevault]

Probably worth having a second issue for that.

[StephenBrown2]

Looking forward to the day when I can use i3blocks seamlessly with swaybar...

Keep up the great work!

[progandy]

I guess sway should also support a custom command for the swaybar. i3 has i3bar_command <command>, so maybe swaybar_command <command> works.

[ddevault]

Good call.

[StephenBrown2]

Rather important feature missing from the list: click events

http://i3wm.org/docs/i3bar-protocol.html#_click_events

[Drakulix]

What about trayicon support? I might be difficult to do, but it is a quite major feature.

[ddevault]

I plan on addressing that at some point, but no Wayland compositors currently support tray icons, so we'd have to make up our own protocol extension and try to land it in the various GUI toolkits, as well as in xwayland.

[progandy]

Regarding trayicons, I suggest you use the StatusNotifier / AppIndicator protocol which is promoted heavily as the new way to display status icons. I guess that is what wayland applications will use.
For those who need old tray icons, simply try running e.g. stalonetray. Maybe implement a special case so that swaybar can swallow stalonetray.

[ddevault]

My intention is to support both.

[DerpyCrabs]

Can you also add smart_hide mode when swaybar is visible only if there is any window on workspace?

[ddevault]

Is that a request for a sway-exclusive feature, rather than one for a feature already in i3? If so, please create a new Github issue for it.

[Kommynct]

You linked click events to issue #222, but I can't find click events mentioned anywhere there, and click events currently do not seem to work, at least on my i3blocks setup they do not.

Am I doing something wrong or is this functionality just not implemented yet?

[ddevault]

It's not implemented yet. The link from #222 has nothing to do with mouse events.

[ddevault]

#450 is what really needs to get done before we can think about mouse events on swaybar.

[deklov]

Is anyone working on getting swaybar to handle mouse events? If not I might take a stab at it.

[ddevault]

Not yet afaik. It has to be made into a shell surface. A good start would be working on swaybg as a shell surface.

[deklov]

Not sure exactly what "working on swaybg as a shell surface" means. I haven't looked at swaybg yet and I'm still trying to understand the difference between a surface and a shell surface. I'll take a look at swaybg and and do some more research on surface vs shell surface and maybe it will become clear. Thanks.

[ddevault]

A surface is any rectangular area of pixels that the compositor knows about. Shell surfaces are surfaces that act like windows. Presently swaybg and swaybar are both surfaces but not shell surfaces. To interact with the mouse they need to be shell surfaces, but currently sway assumes that all shell surfaces are windows and will attempt to tile them and such.

[deklov]

Thanks for the explanation. Could you please point me to the code that makes the assumption that shell surfaces are windows and where (non shell) surfaces are treated differently.

[ddevault]

wlc invokes this for shell surfaces. Some surfaces configure themselves through protocol extensions like this instead where sway makes a note of it and renders them later like this.

[deklov]

Thanks. I'll try and play around with this over the next couple of days to try to understand Sway and wlc a little better.

[deklov]

How is Sway "notified" that Swaybar is launced? handle_view_created() seems to get called whenever a window, or I guess a shell surface, like a terminal is created but it does not get called when Swaybar is launched by Sway. I'm trying to find the code that ensures that Swaybar is rendered in the appropriate place.

[ddevault]

https://github.com/SirCmpwn/sway/blob/master/sway/extensions.c#L85-L99

[deklov]

Is this how it works? set_panel() gets called. It calls find_or_create_panel_config() which does list_add(desktop_shell.panels, config). desktop_shell.panels is then used in handle_output_pre_render() which calls wlc_surface_render() to render the bar.

And is the desktop-shell.xml a Sway specific extension?

[ddevault]

You have to provide all three colors if I recall correctly. The relevant error should have been logged.

[sullome]

Well, there is no error in log, actually. And the strange thing with colors appearing even with the default configuration (in which the statusbar, text on the swaybar, are bright cyan).
Also, for background and statusbar as I can see in man sway-bar only one color is needed.

Log from another example:

Configuring bar bar-0
handling config command 'position top'
find_handler(position) 0
Setting bar position 'top' for bar: bar-0
handling config command 'colors {'
find_handler(colors) 0
handling config command 'statusline #000000'
find_handler(statusline) 0
handling config command 'background #ffffffff'
find_handler(background) 0
handling config command '}'
End of bar colors block
handling config command '}'
End of bar block

Background also cyan here.

[progandy]

I think there may be an error in parse_color. It should use strtoul instead of strtol with an explicit cast to uint32_t.
https://github.com/SirCmpwn/sway/blob/44a4905466599155fb7203a585dfca1ce1720b33/common/util.c#L107

[ddevault]

Send patch?

[progandy]

I can do that, but I'll have to test it first.

[ddevault]

Of course. Thanks!

[progandy]

Well, I can't reproduce it, that may depend on the specific strtol implementation. I'll send the patch anyways.

[sullome]

I can try to test this. If this is the only line that require changes...

[sullome]

Yeap, this worked for me:
https://itmages.ru/image/view/4684832/e27eb77c
Bar config:

bar {
    position top
    status_command sway_status.py
    strip_workspace_numbers yes
    pango_markup enabled
    font swaybar-icons 14
    colors {
        statusline #000000
        background #dedede
        separator  #b7b7b7
        inactive_workspace #00000000 #dedede #555555
        focused_workspace  #b7b7b7   #f5f5f5 #555555
        urgent_workspace   #00000000 #dedede #00a0ff
    }
}

And the colors are correct now.

Thanks!

[sjug]

Shouldn't tray icon support be in this list?

[ddevault]

I suppose.

[johnae]

Should click events be part of this list? Eg. https://i3wm.org/docs/i3bar-protocol.html - when configuration specifies "click_events": true. I saw mouse events being part of this list but I assume those mean just in general (and perhaps clicking on workspace labels).

[ddevault]

Thanks @johnae, added those to the list.

[ItachiSan]

What is the progress about the tray icon bar?

[ddevault]

None. Work on it yourself if you want.

[tmccombs]

I don't know very much about wayland or tray icons, but if someone points me in the right direction I'd be willing work on implementing the tray icon bar.

[ddevault]

Some direction on tray icons is given in the bounties issue.

[kellpossible]

Is this issue's tray icons item closed with the merging of #1234?

[soredake]

@kellpossible XEmbed is still not implemented.

[PeaceAlways]

Really need mode options.
Appreciation for this much fast and perfect development. Really awesome man.

[kafran]

Will it support vertical bar/panel?

[ddevault]

That's unrelated to i3 compatability, but perhaps.

[ptMuta]

Did i3bar toss in trailing garbage during click events? Currently swaybar adds a trailing comma which means it emits a malformed JSON value and breaks the usability for example of i3status-rust.

I would love to provide a patch for this but I'm not sure which repository to submit it to.

[ddevault]

Yeah that looks wrong. This is the repository to send patches to.

[ddevault]

i3bar's features are fully supported (except tray icons, which are being tracked separately).