Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

i3bar compatability #343

Closed
17 of 19 tasks
ddevault opened this issue Dec 17, 2015 · 64 comments
Closed
17 of 19 tasks

i3bar compatability #343

ddevault opened this issue Dec 17, 2015 · 64 comments

Comments

@ddevault
Copy link
Contributor

ddevault commented Dec 17, 2015

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
@ddevault ddevault mentioned this issue Dec 17, 2015
81 tasks
@mikkeloscar
Copy link
Collaborator

I think font support is missing as well.

@ddevault
Copy link
Contributor Author

Thanks, added that.

@mikkeloscar
Copy link
Collaborator

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
Copy link
Contributor Author

Probably worth having a second issue for that.

@StephenBrown2
Copy link
Contributor

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

Keep up the great work!

@progandy
Copy link
Contributor

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

@ddevault
Copy link
Contributor Author

Good call.

@StephenBrown2
Copy link
Contributor

Rather important feature missing from the list: click events

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

@ddevault ddevault mentioned this issue Dec 24, 2015
@Drakulix
Copy link

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

@ddevault
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor Author

My intention is to support both.

@DerpyCrabs
Copy link

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

@ddevault
Copy link
Contributor Author

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
Copy link

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
Copy link
Contributor Author

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

@ddevault
Copy link
Contributor Author

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

@deklov
Copy link
Contributor

deklov commented Jun 30, 2016

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

@ddevault
Copy link
Contributor Author

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
Copy link
Contributor

deklov commented Jun 30, 2016

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
Copy link
Contributor Author

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
Copy link
Contributor

deklov commented Jun 30, 2016

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
Copy link
Contributor Author

ddevault commented Jun 30, 2016

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
Copy link
Contributor

deklov commented Jun 30, 2016

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
Copy link
Contributor

deklov commented Jul 3, 2016

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
Copy link
Contributor Author

ddevault commented Jul 3, 2016

@deklov
Copy link
Contributor

deklov commented Jul 3, 2016

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
Copy link
Contributor Author

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

@sullome
Copy link

sullome commented Jul 29, 2016

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
Copy link
Contributor

progandy commented Aug 4, 2016

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
Copy link
Contributor Author

ddevault commented Aug 4, 2016

Send patch?

@progandy
Copy link
Contributor

progandy commented Aug 4, 2016

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

@ddevault
Copy link
Contributor Author

ddevault commented Aug 4, 2016

Of course. Thanks!

@progandy
Copy link
Contributor

progandy commented Aug 4, 2016

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

@sullome
Copy link

sullome commented Aug 4, 2016

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

@sullome
Copy link

sullome commented Aug 4, 2016

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
Copy link

sjug commented Aug 14, 2016

Shouldn't tray icon support be in this list?

@ddevault
Copy link
Contributor Author

I suppose.

@johnae
Copy link
Contributor

johnae commented Dec 6, 2016

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
Copy link
Contributor Author

ddevault commented Dec 6, 2016

Thanks @johnae, added those to the list.

@ItachiSan
Copy link

What is the progress about the tray icon bar?

@ddevault
Copy link
Contributor Author

None. Work on it yourself if you want.

@tmccombs
Copy link
Contributor

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
Copy link
Contributor Author

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

@kellpossible
Copy link

kellpossible commented Aug 21, 2017

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

@soredake
Copy link

@kellpossible XEmbed is still not implemented.

@PeaceAlways
Copy link

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

@kafran
Copy link

kafran commented Sep 28, 2017

Will it support vertical bar/panel?

@ddevault
Copy link
Contributor Author

That's unrelated to i3 compatability, but perhaps.

@ptMuta
Copy link
Contributor

ptMuta commented Oct 28, 2017

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
Copy link
Contributor Author

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

@ddevault
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests