Waybar: IMPORTANT: 1.0.0 Release 🎉

Created on 5 Apr 2020 · 21Comments · Source: Alexays/Waybar

Hi!
I've been pretty busy lately, but I'm going to get back into Waybar and start working on the 1.0.0 release.
Here the 1.0.0 milestone.

I'm gonna go around all the issues and put some in this milestone.
But I also wanted to ask you which ones you find priority and want to see soon!
If you have ideas for improvement, don't hesitate!
And don't hesitate to add your own modifications!
Can't wait to share this with you!

Alex.

question

Source

Alexays

🎉35

Most helpful comment

To me it's #255 , which seems to have a fix in this fork https://github.com/xPMo/Waybar/commit/8e6b6a781dc4b1fdd53eca57cf0d21620dfba59c

EDIT: pullable https://github.com/Alexays/Waybar/compare/master...xPMo:sway-hide

yory8 on 1 May 2020

👍5

All 21 comments

First of all, congratulations on the progress of the project. It has simply become great, and de facto, a great standard. :tada:
Then, for the 1.0.0 milestone, I'm interested in issue #66 . I've seen the work done on PR #556 , and I think I can fork it and fix the problems that have been raised. Let me know if it's a feature that fits in the milestone.

BlueGone on 7 Apr 2020

👍1

First of all, congratulations on the progress of the project. It has simply become great, and de facto, a great standard. 🎉
Then, for the 1.0.0 milestone, I'm interested in issue #66 . I've seen the work done on PR #556 , and I think I can fork it and fix the problems that have been raised. Let me know if it's a feature that fits in the milestone.

Sure go ahead @BlueGone ❤️

Alexays on 7 Apr 2020

Great progress on the project @Alexays 🎉

There two issues hurt me most: #388 (already part of the milestone) and at the end of every month #581. I would be happy to help with #581, if you could comment in that issue your thoughts of the preferred approach?

maximbaz on 11 Apr 2020

434 would be great, I think configuration file has to be more easy and confortable to edit, I think YAML or TOML are the way to go.

ZJaume on 27 Apr 2020

👍3

To me it's #255 , which seems to have a fix in this fork https://github.com/xPMo/Waybar/commit/8e6b6a781dc4b1fdd53eca57cf0d21620dfba59c

EDIT: pullable https://github.com/Alexays/Waybar/compare/master...xPMo:sway-hide

yory8 on 1 May 2020

👍5

@yory8 @xPMo any news about #255 ? 😃

Alexays on 2 May 2020

@Alexays i'm not involved with that effort; it seems they got stuck with some segfaults?

yory8 on 2 May 2020

I like to have a current keyboard layout but not based on sway, some people use waybar with wayfire.

bluebyt65 on 24 May 2020

https://github.com/Alexays/Waybar/issues/509 and https://github.com/Alexays/Waybar/issues/585 would be at the top of my list and seem to be related and/or the same issue?

luispabon on 28 May 2020

509 and #585 would be at the top of my list and seem to be related and/or the same issue?

This one should be fixed, can you test?

Alexays on 28 May 2020

I feature nice to have a "taskbar/window list" like this:
https://www.reddit.com/r/Polybar/comments/gsxdh3/polywins_a_customizable_polybar_taskbarwindow_list/

bluebyt65 on 30 May 2020

👍2

509 and #585 would be at the top of my list and seem to be related and/or the same issue?

This one should be fixed, can you test?

They seem to be, :ok_hand:

luispabon on 13 Jul 2020

❤1

Flatpak package? This is my Flatpak manifest and it's how I'm now runnning Waybar.
So far I didn't notice issues with this but my needs from Waybar are very basic.
Note that the manifest needs some cleanup and I packaged in Sway for swaymsg and also jq.

tinywrkb on 16 Aug 2020

@tinywrkb Scaling on wayland does not seem to work via flatpak, so that should probably be addressed before encouraging users to adopt that.

WhyNotHugo on 20 Aug 2020

@WhyNotHugo this? sounds like a GTK issue, not a Wayland one.
What do you mean by encouraging users? it just a distribution method, users should be free to choose how to install apps. The fact that some issue is affecting your setup doesn't mean Flatpak packaging should not be considered, it's up to the developer to decide.
Note that it's possible to add a disclaimer to the Flathub app page about the issue or to keep the app on Flathub-beta repo until the issue is resolved.

tinywrkb on 20 Aug 2020

sounds like a GTK issue, not a Wayland one.

Not entirely certain where the fault lies -- applications scale fine when running natively on Wayland, it's just via flatpak that they fail. I can't honestly figure out if the issue is Wayland, Flatpak, or GTK.

WhyNotHugo on 20 Aug 2020

@WhyNotHugo do you have gnome-settings-daemon installed? see if the xsettings schema helps. If you're on Arch Linux then I already packaged the xsettings schema separately here.
I don't know about scaling but it helps with having the fonts rendered correctly and it supposed to be moved from gnome-settings-daemon into gsettings-desktop-schemas.

tinywrkb on 21 Aug 2020

any news?

eoli3n on 27 Nov 2020

No, I don't have gnome-settings-daemon. The README indicate that this is a GNOME-specific thing:

The GNOME Settings Daemon is responsible for setting various parameters of a
GNOME Session and the applications that run under it.

I'm using swaywm.

I did install it anyway. Apps now draw a different kind of blurry. Fonts are very blurry, but images are sharp. So it's no longer a scaling problem, but some other rendering problem...?

WhyNotHugo on 28 Nov 2020

@Alexays i don't see https://github.com/Alexays/Waybar/issues/434 in the milestone

eoli3n on 28 Nov 2020

👍1

Would you consider making another intermediate release between now and 1.0? There were some commits merged back in October dealing with the taskbar module that would be great to have in a tagged release.