i3bar compatability
ddevault opened this issue · 64 comments
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
I think font support is missing as well.
Thanks, added that.
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.
Probably worth having a second issue for that.
Looking forward to the day when I can use i3blocks seamlessly with swaybar...
Keep up the great work!
I guess sway should also support a custom command for the swaybar. i3 has i3bar_command <command>, so maybe swaybar_command <command> works.
Good call.
Rather important feature missing from the list: click events
What about trayicon support? I might be difficult to do, but it is a quite major feature.
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.
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.
My intention is to support both.
Can you also add smart_hide mode when swaybar is visible only if there is any window on workspace?
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.
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?
It's not implemented yet. The link from #222 has nothing to do with mouse events.
#450 is what really needs to get done before we can think about mouse events on swaybar.
Is anyone working on getting swaybar to handle mouse events? If not I might take a stab at it.
Not yet afaik. It has to be made into a shell surface. A good start would be working on swaybg as a shell surface.
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.
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.
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.
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.
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.
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?
Yes, that's how it works. No, desktop-shell is not sway specific.
If there is a reliable way to detect that the created view is either swaybar or swaybg in handle_view_created(), I guess we can essentially do nothing for swaybar and swaybg handle_view_created() and render them in handle_output_pre_render() as is done today.
Perhaps if we assume that swaybar and swaybg is launched by sway, we can stash away their PIDs and call wl_client_get_credentials() in handle_view_created() and compare the PIDs. Is there a better way of doing this? Can we get the PID of the process invoking set_panel and set_background? If we can, then at least we don't have to rely on sway launching swaybar and swaybg.
I would rather call set_panel before creating the shell surface, then associating that surface with a panel and catching that in handle_view_created.
We can also just use that one wlc function that creates a shell surface out of an arbitrary surface without any client-side interactions.
I would rather call set_panel before creating the shell surface
I don't follow. I thought that set_panels was called by the client through the wayland protocol. Hmm, are you talking about changes to the swaybar and swaybg?
We can also just use that one wlc function that creates a shell surface out of an arbitrary surface without any client-side interactions.
Not familiar with that function but if it does what I think it does based on your explanation, I think this is the way to go.
I am talking about changes to swaybar and swaybg, yes.
I was looking at how keryboard is handled in registry.c and how pointer is handled in window.c. Why is keyboard handled per registry and pointer per window? struct registry has field of type struct input with some keyboard related state, e.g. last_code. Should this not be tracked on a per window basis?
I went ahead and made keyboard state tracked per window.
Is it OK, that it is possible to use only half of the colors?
I am trying to configure swaybar. In the config file:
bar {
position top
colors {
statusline #000000
background #7f7f7f
}
}
If I set background to darker colors, like #303030 it would be ok, but if I change any color (R,G or B) to the 80 or brighter (like #f0f0f0) it will turn to the bright cyan color (instead of white, gray, whatever) — it will be #7fffff.
Just to be clear, this config:
bar {
position top
colors {
statusline #000000
background #808080
}
}
will produce bar with background color #7fffff.
I don't fully understand what you're asking for.
Hm... I am trying to ask, is this an error, or not. Looks like an error.
You have to provide all three colors if I recall correctly. The relevant error should have been logged.
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.
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
Send patch?
I can do that, but I'll have to test it first.
Of course. Thanks!
Well, I can't reproduce it, that may depend on the specific strtol implementation. I'll send the patch anyways.
I can try to test this. If this is the only line that require changes...
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!
Shouldn't tray icon support be in this list?
I suppose.
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).
What is the progress about the tray icon bar?
None. Work on it yourself if you want.
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.
Some direction on tray icons is given in the bounties issue.
Is this issue's tray icons item closed with the merging of #1234?
@kellpossible XEmbed is still not implemented.
Really need mode options.
Appreciation for this much fast and perfect development. Really awesome man.
Will it support vertical bar/panel?
That's unrelated to i3 compatability, but perhaps.
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.
Yeah that looks wrong. This is the repository to send patches to.
i3bar's features are fully supported (except tray icons, which are being tracked separately).