search

tobi-wan-kenobi / bumblebee-status

bumblebee-status is a modular, theme-able status line generator for the i3 window manager.
https://bumblebee-status.readthedocs.io/en/main/
MIT License
1.23k stars 228 forks source link

[RFC] State of the "development" branch #606

Closed tobi-wan-kenobi closed 4 years ago

tobi-wan-kenobi commented 4 years ago

@somospocos @martindoublem @bbernhard @ibrokemypie @TheEdgeOfRage @fredj

Hello everyone,

sorry for mentioning you all together, but for some reason or another, I regard all of you as core/alpha/long-time/veteran bumblebee users and contributors.

I appreciate you might not use bumblebee anymore, and if that's the case, please feel free to stop reading.

Otherwise:

The development branch of bumblebee (significant refactoring and improvement) has matured to a point where I use it every day without issues and there's only a short list of known issues:

If you would like to switch to the development branch and give me some feedback on how it works for you, I would appreciate that a lot!

Many thanks in advance and thank you very much for your contributions to this tool!

TheEdgeOfRage commented 4 years ago

Any preferences about creating issues on the development branch? Should I just create it as a regular one or add something like [development] in the title?

martindoublem commented 4 years ago

Wow, thank you on seeing me as a valued user/contribtutor. I remember doing some of my first steps in python on this project.

I still use bumblebee on my daily driver and it was actually on my to-do list to switch bumblebee to development, most largely for the the interval per module which would be great for reducing the load on my laptop on idle.

I will be sure to provide you feedback as I use it and try my best to help with issues if I can.

tobi-wan-kenobi commented 4 years ago

@TheEdgeOfRage good point. I'd say: [development] in the title is appreciated, and I will also add a label "development" for filtering. Hope that helps!

@martindoublem Great, thanks a lot!

bbernhard commented 4 years ago

Just switched to the development branch and got that: 

usage: bumblebee-status [-h] [-m MODULES [MODULES ...]]
                        [-p PARAMETERS [PARAMETERS ...]] [-t THEME]
                        [-i ICONSET] [-a AUTOHIDE [AUTOHIDE ...]] [--debug]
bumblebee-status: error: unrecognized arguments: -d

I can easily fix that, so no problems if -d is not supported anymore. I was just wondering if that change was intended or slipped through :)

tobi-wan-kenobi commented 4 years ago

damn, overlooked that one. The only thing around debugging that was intentional was that debugging into a file isn't supported anymore (since you can easily pipe, and some people had log files filling up, because they forgot to switch it off again)

tobi-wan-kenobi commented 4 years ago

@bbernhard fixed (yay lunchbreak :P )

Thanks for reporting! I am especially curious how your bluetooth and vpn modules work, because I had to port them "blindly", since I have no way of testing them.

ghost commented 4 years ago

Good to see such a status report.

I am still using bumblebee-status, albeit not with i3. There's one particular window management thing that I can't achieve with i3 (not related to bumblebee-status at all). I don't even know if it's possible with i3. But this is offtopic for this issue. bumblebee-status has been working great for me with dwm.

This issue seems to be the right place to ask the question I had for a while. I recall you saying once that you plan to merge the development branch into master. What are your plans for master branch before merging the development branch someday? As an end user, I'd expect you to tag the last revision before the big merge and make one last stable release based on master, so those users who prefer to use the then-legacy version would have a reference git tag / source code tarball. I'm wondering about this for mercantile reasons :D, because this is my own plan as well, at least for the near future.

As for the development branch:

some small functionality I deemed "corner case" have been dropped

I hope you don't mind me asking instead of diving up into the code in development branch, I'm a bit time constrained lately to do that. Do you have a list of those dropped features anywhere? Is my preciousss Braille graph feature one of those? I'd like to know, since I'm using it, but even if it is, this shouldn't affect any of your milestones. Once I'll switch to the development branch after it hits master, if it doesn't have support for Braille graphs, I'll probably stop using this feature for a while, then at least try to add it again on top of the new code, then you could decide if you want it back in mainline.

Regarding issues related to development branch:

I'd say: [development] in the title is appreciated

It's good to have a consistent git history indeed, though "[development]" feels a bit long in context of a 80 chars per line constraint. Would just "[dev]" be a valid prefix? I guess I'm just being picky, not trying to stir a "[development]" vs "[dev]" holy war here, just wondering if either of those would be fine. Then one could just grep the history for "[dev" and get all of them.

tobi-wan-kenobi commented 4 years ago

@somospocos Yes, I am planning to do a last "stable 1.x release" with a tag, PIP and AUR package right before switching. If there's a lot of users staying on 1.x, I'll probably also do the occasional bugfix release from a 1.x branch.

Reg. the corner cases: Braille support of course is still there - it's one of the features I'm really proud bumblebee has, so thanks for contributing that! I don't have the list, unfortunately, because it happened gradually, it was mostly really small "special theme" handling things (like the possibility to exclude decorations such as pre and postfix on a configurational level). That was really ugly in the code, and I don't see a lot of usage scenarios for it. And TBH, I probably dropped some thing accidentially that I implemented specifically for single bug reports. But I just had to clean up and simplify the code base.

On [development] vs [dev] - that's for ticketing only, and I am fine with both, whatever floats your boat :) In the branch itself, I am not using that at all, as the commits contain information about where they originated, so that should be good already. Hopefully :)

Thanks a lot to the feedback, everyone!

tobi-wan-kenobi commented 4 years ago

@somospocos One more thing that's not yet in is the additional "meta" fields in the output that I added for your dwm bridge, but I will make sure that this is in before merging to master, just in case :)

martindoublem commented 4 years ago

I had a question for interval, would there be a way a way of doing it so that it runs at the start and then on the top of the interval. Say for example for an interval f 1h if I start my laptop and bumblebee at 13:25, could it run then and at 14:00 and then 15;00 and so on...

The aim being if I set date at 24h, it wont miss the date change, yet wont refresh it every second.

tobi-wan-kenobi commented 4 years ago

@martindoublem

Interesting idea, for that, either you just set it to 1h, that should be sufficient, or I could extend the system to have something like an "alignment" parameter :thinking:

martindoublem commented 4 years ago

Here is an idea, would ther be a way to give a fixed size to give a fixed size to a widget/module as to avoid them moving all the time.

bbernhard commented 4 years ago

@bbernhard fixed (yay lunchbreak :P )

works again, thanks! :)

Thanks for reporting! I am especially curious how your bluetooth and vpn modules work, because I had to port them "blindly", since I have no way of testing them.

Do you maybe mean the pihole module? I think I haven't changed anything in the bluetooth module so far :thinking:

bbernhard commented 4 years ago

The only thing around debugging that was intentional was that debugging into a file isn't supported anymore (since you can easily pipe, and some people had log files filling up, because they forgot to switch it off again)

Is there maybe a chance to get the "logging into a file" option somehow back? I found that one really convenient during developing - especially as it was just a single flag that I could easily set in my i3 config without changing anything else. I tried to pipe the output of bumblebee into a file, but haven't got that to work from within my i3 config. (To be honest, I also haven't spent much time on that ;-)).

edit: In order to avoid that people forget to turn the debug mode off again, I guess we could show that somehow in the status bar(e.g: by displaying a warning icon, changing the color of the status bar, etc). But not sure if you wanna go that route. :grinning:

tobi-wan-kenobi commented 4 years ago

@bbernhard good idea - tracked in #614

(piping the debug log should be something like bumblebee-status -d -m cpu 2> ~/bumblebee.log)

Ah, I confused that, I thought you contributed bluetooth :thinking: pihole, I did test, that one works for sure :)

ghost commented 4 years ago

Regarding redirecting the output into a file - if it has to be done from within the i3 config, and it doesn't work by approaching it directly, it's worth trying to make use of tee.

tobi-wan-kenobi commented 4 years ago

@martindoublem Which modules are affected, in your experience? I tried to make most of the modules constant-width (I really hate if modules jump around).

But anyway, I agree that having an option to set the (min)width of a module/widget would make sense. It's just a bit difficult to do for a multi-widget module, as there's no way yet to specify per-widget parameters.

How about something like: -p <module>.widget.width="2,10,5", maybe?

bbernhard commented 4 years ago

good idea - tracked in #614

works perfect :+1:

As we are talking about development here: What is the current state of Python 2? Should new modules still aim to be compatible with Python 2? (Just writing a module which makes heavy use of byte operations...already a bit afraid to port that to Python 2 ;-))

martindoublem commented 4 years ago

Last release ever of python2 should be april normally.

martindoublem commented 4 years ago

Tested several modules successfully: I have an idea for one more that I might write in the next while.

tobi-wan-kenobi commented 4 years ago

@bbernhard @martindoublem I've decided to drop Python 2 support. It's also not included in the unit test of Travis anymore.

tobi-wan-kenobi commented 4 years ago

Short progress update:

  1. I am amazed by the amount of feedback I got from you guys - many thanks!
  2. What I have added over the last couple of days:
    • tons of bugfixes :)
    • logfile output
    • dwm compatibility fields (_raw, _prefix, _suffix)
    • right-to-left output
    • help output (list modules/themes)
    • bumblebee-ctl
  3. There's only a couple of things still missing now:
    • adding support for different text alignments
    • adding config file support
    • default handling of mouse wheel events (I find that really useful)
    • finishing up documentation (have a look at doc/ to see what I'm aiming at)

The plan is to finish those over the next 1-2 weeks, then have maybe another week or so of stabilization, and then merge to master. After that, another 1-2 weeks of gathering feedback, and once everything has calmed down, push the new version to PIP and AUR.

ghost commented 4 years ago

A bit more feedback.

I have tried to run a couple of my bumblebee-status setups with the development branch (only pure i3 setups, didn't look at bridges yet) and aside from the nvidiagpu module little trouble that is already fixed, I only had to remove the --markup and --iconmarkup arguments from the bumblebee invocation command line. I do remember that the Pango voodoo went straight into theme files in development branch, hopefully you don't mind if I postpone further testing by porting the themes as well (so I fully match my config that uses master branch) closer to the big merge. I just want to avoid dealing with two branches of -contrib and bridge stuff. Since this preliminary test went well enough, I might just fully switch to the new version once it gets officially merged, if adapting the bridges won't be too time consuming. Don't want to plan too far ahead, but if I'll be happy with the transition, I might fully drop support for now-master-then-legacy branch in my -contrib and bridge repos, because I have no idea if anybody else except me is using them.

bbernhard commented 4 years ago

Anyone else getting those type of messages in the debug log? 

CRITICAL failed to import pihole: No module named 'modules.core.pihole'
CRITICAL failed to import system: No module named 'modules.core.system'
CRITICAL failed to import vpn: No module named 'modules.core.vpn'

The module seems to be successfully loaded though. I guess it should be modules.contrib.pihole, no? :thinking:

tobi-wan-kenobi commented 4 years ago

@somospocos Yes, exactly, pango is now a "real" part of the themes, I think the new implementation is substantially less hacky and more extensible (i.e. it supports all pango attributes).

I hope that your bridge implementation "just works", I tried to maintain backwards compatibility with that regard.

@bbernhard Good catch, that's a not-so-nice logging stemming from the fact that modules are always first looked up in core, then in contrib. Will fix that to only display errors when the module wasn't loaded at all.

fredj commented 4 years ago

@tobi-wan-kenobi thanks for you work on this !

tobi-wan-kenobi commented 4 years ago

@rad4day forgot to pull you in as well, your past contributions showed how much you care about good code, so any input from your side would be much appreciated!

tobi-wan-kenobi commented 4 years ago

Hopefully the last time that I am nagging all of you, but this might be of interest.

Most of you at one time or another have raised the issue of documentation (or the lack thereof, @somospocos hint hint ;) ).

I present to you my attempt at a solution:

https://bumblebee-status.readthedocs.io/en/development/

ghost commented 4 years ago

I had a quick sprint over the docs.

I have no formal pull request to make, because the only thing I remember about sphinx is the super hilarious image example from the sphinx docs.

Here are my findings:

features.html

modules.html

themes.html

development/theme.html

tobi-wan-kenobi commented 4 years ago

@somospocos thanks for the detailed feedback, I hope I have now incorporated all your suggestions!

martindoublem commented 4 years ago

@martindoublem Which modules are affected, in your experience? I tried to make most of the modules constant-width (I really hate if modules jump around).

But anyway, I agree that having an option to set the (min)width of a module/widget would make sense. It's just a bit difficult to do for a multi-widget module, as there's no way yet to specify per-widget parameters.

How about something like: -p <module>.widget.width="2,10,5", maybe?

nic with wifi ssid, redshift during the transation time.

tobi-wan-kenobi commented 4 years ago

nic with wifi ssid, redshift during the transation time.

For redshift, I see how that happens - for NIC - what piece of the data changes?

martindoublem commented 4 years ago

NIC would be the SSID for wifi especially if you go from a short one to a longer one.

tobi-wan-kenobi commented 4 years ago

@martindoublem

At least for redshift, you can already use redshift.theme.minwidth to set a minimum width.

For the nic module, that might be cumbersome, since it's multi-widget. A "workaround" would be to split out the WLAN interface into a separate nic module that you give an alias and a minwidth, for example:

-m nic:wired nic:wireless -p wired.exclude="wlp*" wireless.include="wlp*" wireless.theme.minwidth=20 or something like that (not tested), but I concede that this is pretty cumbersome.

martindoublem commented 4 years ago

@tobi-wan-kenobi, the recent updates I made to redshift solved that issue for me, however the same remains to be done for and or make a nic-wifi or interface. Your idea to split the module is also good, although it does seems to be quite demanding.

tobi-wan-kenobi commented 4 years ago

@martindoublem how about the suggestion of using "minwidth" together with a nic config that specifically only shows wireless devices?

tobi-wan-kenobi commented 4 years ago

Also, here's the plan from now onwards:

I guess I'll be flooded by complaints from git users then :P

A week or two later, I'll do the first proper release and push it out on AUR stable and PIP.

And with that, the switch to the refactored bumblebee-status should be complete.

Let's cross fingers, and thanks a lot to the help from all of you!

martindoublem commented 4 years ago

@martindoublem how about the suggestion of using "minwidth" together with a nic config that specifically only shows wireless devices?

My issue here is that I would like a maxwidth, no a minwidth. so that when I switch from a short one to a super long it is not affected. A minwidth would be good for the other way around though.

tobi-wan-kenobi commented 4 years ago

My issue here is that I would like a maxwidth, no a minwidth. so that when I switch from a short one to a super long it is not affected. A minwidth would be good for the other way around though.

Ah, now I get what you need, I think - that would be something like a generic "scrollable", right? Specify a maximum width, and if it's wider than that, start scrolling?

I think that could be doable, if that's what you need.

martindoublem commented 4 years ago

It is more a want than a need but it would be indeed nice and also a none-scrollable if that is an option, just cut off the part, that is not too long .

tobi-wan-kenobi commented 4 years ago

@martindoublem Can you please check whether the last commit adds the functionality you're looking for:

bumblebee-status -m spacer -p spacer.text="this is a really really long text" spacer.scrolling=true spacer.scrolling.width=4 spacer.interval=1

works for me :)

tobi-wan-kenobi commented 4 years ago

just merged :fearful:

ghost commented 4 years ago

Neither 0fca0bb nor v1.10.4 aren't telling me that this is the last-before-merge version. While the release note is informative about this, I expect that after a while I'll just forget the labels above. If I were you, I would just make a new branch starting with said revision with a human-friendly name like "legacy". Then switching to it for eventual bugfixes/backports would be much simpler (to me at least).

tobi-wan-kenobi commented 4 years ago

@somospocos

https://bumblebee-status.readthedocs.io/en/master/FAQ.html#the-new-version-has-broken-my-setup :)

I didn't want to use something like "legacy", because I think 1.10.4 is totally fine for now - at least, until I've done the first real release from master (which is going to be 2.0.0, probably)

ghost commented 4 years ago

I am not insisting on this particular branch name if that's the problem. I'd just feel more comfortable with a branch with a word label that would make it obvious switching between pre-big-merge code and after-big-merge code that is the master branch now. To me this would look consistent with how it was before the merge - we had "master" and "development" branches and didn't have to remember any numbers. Now "development" became "master", so pre-merge "master" could be codenamed somehow else. Sure I can just do this in my fork, after all a branch is just a cheap pointer to a revision.

tobi-wan-kenobi commented 4 years ago

Good argument, and adding tags isn't an issue :-) I'll think about a good name and add that.

On May 20, 2020, 18:09, at 18:09, somospocos notifications@github.com wrote:

I am not insisting on this particular branch name if that's the problem. I'd just feel more comfortable with a branch with a word label that would make it obvious switching between pre-big-merge code and after-big-merge code that is the master branch now. To me this would look consistent with how it was before the merge - we had "master" and "development" branches and didn't have to remember any numbers. Now "development" became "master", so pre-merge "master" could be codenamed somehow else. Sure I can just do this in my fork, after all a branch is just a cheap pointer to a revision.

-- You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub: https://github.com/tobi-wan-kenobi/bumblebee-status/issues/606#issuecomment-631573128

ghost commented 4 years ago

Thanks, it's not just a random caprice, I'm thinking about having to deal with the bridges and their interaction with the bumblebee-status code after the merge. So while 0fca0bb and v1.10.4 make sense in context of this repository, I couldn't extrapolate this naming convention there. Having a human friendly label would allow me to keep the bridge repositories consistent, as in:

tobi-wan-kenobi commented 4 years ago

Got it, that makes sense.

After some thinking, I did make use of your suggestion of "legacy", the tag should now be there, pointing to the same commit as the tag v1.10.4

Cheers!