hotkeys for bl-exit - Githubissues

Zeitvertreib commented 8 years ago

in older version you had em line 40-43, a simple underscore in from of the label string, highly appreciate your work, pls reimplement, ty `

    self._add_button(label="_Log out", action=self._logout_action)
    self._add_button(label="_Suspend", action=self._suspend_action)
    self._add_button(label="_Reboot", action=self._reboot_action)
    self._add_button(label="_Power off", action=self._shutdown_action)

`

ghost commented 8 years ago

Maybe switch the R accel which conflicted with the Openbox hotkey to B instead so we have L, S, B, P?

capn-damo commented 8 years ago

That's what I originally suggested as well, for the bugfix for the hotkeys

xaosfiftytwo commented 8 years ago

While we are planning to apply changes, Is there a reason for us not having a hibernate button?

johnraff commented 8 years ago

^I think it was because hibernate was not well supported on some hardware in the past (CrunchBang era), and also had requirements for things like a swap partition of a certain size.

ghost commented 8 years ago

Well we could configure BL to use a swap file by default instead of a partition! https://wiki.debian.org/Hibernation/Hibernate_Without_Swap_Partition

Not sure how realiable this is however.

xaosfiftytwo commented 8 years ago

@I've no experience with using a swapfile either. If we do it, we should go for the maximum size (16GB?). That is a lot of wasted space if you don't ever use it.

Perhaps we could show the hibernate button depending on the existence of a swap partition? Users choice then to create a swap partition.

Hjdskes commented 8 years ago

We can also detect whether there is a swap partition (and/or swap file? If we can ask the kernel about any swap space it knows that should be enough) and inform the user when the button is clicked in case swap space isn't found. This would make users aware of why hibernation does not work, instead of simply never showing it.

Regarding swap files, isn't it possible to make it a sparse file?

xaosfiftytwo commented 8 years ago

From 'man swapon'

   You should not use swapon on a file with holes.  Swap over  NFS  may  not
   work.

And swapfile on btrfs may be problematic too. (Same resource)

We could parse output of

free -h

to detect presence of swap space.`

Zeitvertreib commented 8 years ago

i dont need a swapfile, nor hibernate, i like the way suspend works just fine. but the hotkeys... nvm, i fix em my self on my b-labs.

Hjdskes commented 8 years ago

Why close this issue? Discussion is still ongoing.

Zeitvertreib commented 8 years ago

I felt like its going in a broader subject. I thought of an easy fix. Now its more going into a feature request (hibernate). Also it seems to be about overlapping shortcuts I thought it should be separated.

On the shortcuts part, I for my self found a vanilla hjkl configuration for openbox. Unfortunately it conflicts with with lockscreen and the clipboard shortcuts. (random reassignment happens..) ..but it feels so offtopic.

capn-damo commented 8 years ago

Well, we removed the accelerators because of a clash with Openbox, and now some would like them back, so the discussion is what to do about it. The fix is very easy, but if it is going to be done it would be better to include any other changes at the same time.

xaosfiftytwo commented 8 years ago

Or we could show the hibernate button always, but show a error message when we detect the absence of swap space. We could capture the error message produced by the hibernate action, which would be necessary perhaps when swap space exists, but size is not adequate, or any other error condition the hibernate action produces, i.e. we don't validate the hibernate action ourselves, but leave that up the hibernate implementation itself.

xaosfiftytwo commented 8 years ago

@2ion Please rebuild bunsen-utilities version 8.6.6-1 to re-enable accelerations in bl-exit. Thanks

johnraff commented 8 years ago

Has bunsen-utilities been version bumped again? After all that work to get it back to 8.6.5-1...

Actually, as the package maintainer, I would like to know about edits to debian/changelog, even if I don't make them myself. Sometimes there are other changes to a package in the pipeline which can be incorporated in the same version jump.

xaosfiftytwo commented 8 years ago

I appreciate the work you did very much, John.

Getting back to 8.6.5-1 did leave us with the bl-exit accelerators removed again. So I wanted to restore them first. Plus Alt+b reboot accelerator in stead of Alt+r.

I did publish a PR first. Jente approved of the changes and merged the PR. After which I thought it would be OK to create a new tag, getting everything ready for a package update.

What procedure do you suggest for the future? A one day delay for team members to revise a PR and for the package maintainer to react? Even for simple changes like this one?

johnraff commented 8 years ago

@xaosfiftytwo needless to say, all your input on this issue and everywhere else in the project is highly valued. My question here is not about the worth of the changes you pushed, but about the work flow we should be following.

I have been trying to do things "by the book" to date, to make it as easy as possible for other people to take over in the future. My understanding at this point is that the procedure should be:

Developer(s) push new code to the repository. Whether this needs peer review or not depends on the case. (I expanded my ideas below (*), to keep this flow simple.) If they feel a new package version is called for they contact the package maintainer.
If the package maintainer agrees the version should be pushed, (s)he chooses a new version number and appropriate urgency level, edits debian/changelog and informs the repository maintainer (or adds a tag)
The repository maintainer builds the new binary package(s) and puts them in the repository.

I would say the one case where (2) can be bypassed is if the package maintainer is temporarily unavailable and the change is an urgent bugfix. In such cases I would suggest that the repository maintainer should do a Non-Maintainer Upload, but there might be a case that it could be the person who wrote the patch.

A big part of the mess we got into with bunsen-utilities was because the changelog was edited. Without that it would have been quite easy to revert the code in bl-exit, but once the version number has been increased, it's difficult to bring it down again, in fact impossible if the package has been built and uploaded. I don't think debian/changelog should be edited by any member of the dev team whenever they feel like it.

Of course our system is not exactly like Debian, but the Debian developers' reference is clear that normally package maintainers should handle the version bump and transfer to the repo, and explains exceptions to that principle: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu

Pushing code: when modifying one's own code then I don't think it's necessary to branch, PR and wait for a response - just push the changes, unless you want a second opinion. If it's a patch to someone else's code then it would be polite to ask them first, maybe in an "issue". To be honest, I'm not sure if PRs are appropriate for use inside the dev team. I may be wrong on this, but my feeling is that they're more suitable for non-members who want to send us a suggestion.

So, in cases like this small restoration of a feature that had been taken out, my current feeling is that it could have been: Just push the change. Let me know. I push the version number, add a tag and contact @2ion .

But, @xaosfiftytwo if you feel any of this is over-pedantic then I'm happy to discuss any aspects of how we do things here with you and the other team members.

Packages can have more than one maintainer. Most of the BL packages are maintained by me at the moment for the historical reason that I was familiar with the CrunchBang packages (from the "Wally" project) and - with a lot of assistance from @2ion at first - got them into debian quilt format at the beginning. It's possible that other maintainers could be added to some/all of them.
At the moment our changes are going straight into the "master" branches. Perhaps we should do all our work on "dev" branches - which might not even have changelog files - and merge "dev" into "master" as necessary, editing changelog in master at that time?

capn-damo commented 8 years ago

At the moment our changes are going straight into the "master" branches. Perhaps we should do all our work on "dev" branches - which might not even have changelog files - and merge "dev" into "master" as necessary, editing changelog in master at that time?

That is the easy and safe way of doing it, IMO.

ghost commented 8 years ago

On Sat, Apr 09, 2016 at 02:55:18AM -0700, damo wrote:

At the moment our changes are going straight into the "master" branches.
Perhaps we should do all our work on "dev" branches - which might not even
have changelog files - and merge "dev" into "master" as necessary, editing
changelog in master at that time?

That is the easy and safe way of doing it, IMO.

Actually, doing the exact opposite is IMO a more practical approach: Do all changes in master, and then branch off the releases. For example, mpv1 used(?) to do this.

M		work

o-----> Release branch: 0.1; debian/changelog is edited here; the commit is	tagged "0.1-1"
more work

o-----> Release branch: 0.; debian/changelog is adapted again; commit is | tagged "0.2-1" ...

xaosfiftytwo commented 8 years ago

OK. Not being up to par with you guys (where using github is concerned), I will happily abide by any procedure you suggest. Sorry for pushing more work your way John, but, once again, I highly appreciate your extensive write-up.

johnraff commented 8 years ago

@2ion what is the advantage of making a new branch for every new version of a package? Is it because you can have a cleaner debian/changelog that way? Would any further changes be pushed to those branches? That sounds to me more like something appropriate for more complicated repos than our simple BL deb packages, to be honest.

The main reason I suggested a "dev" branch to work on is that it insulates the stable code from mistakes. (A messed-up "dev" can be deleted, a new branch made from "master", and start over.)

Another point is that, without separate release branches, at any time someone can go to the repo and build from "master" (or possibly another branch called "current" or "stable") to get the latest stable version of the package, without having to know the version number.

ghost commented 8 years ago

^ I agree that considering the scope of our little projects, introducing this kind of practice would probably be overkill. However there are even some Debian git packaging tools that work this way IIRC.

But I suppose it's time to get this issue back on topic.

Zeitvertreib commented 8 years ago

Apparently the accelerator keys seem to work on the current release. I close this issue on good behalf :)

..and might open another one in the forum about my need to have 'hjkl' shortcut-free/ assignable %P

Zeitvertreib commented 7 years ago

After updating, es far as I understand, did the bl-exit get a huge facelift. (nice look) However, hotkeys don't work for me. So I hopefully gracefully reopen the issue.

Would be nice, if someone could confirm, that its not only me.

regards and ty

johnraff commented 7 years ago

Confirmed. Arrow keys work, but not Alt+Letter hotkeys as before.

To revert to the old theme, with hotkey support, you can set theme = classic in bl-exitrc. https://forums.bunsenlabs.org/viewtopic.php?pid=44184#p44184

As to restoring hotkeys in the new theme, that will have to wait till the return of the developer, @xaosfiftytwo

Zeitvertreib commented 7 years ago

Thanks johnraff! I followed your instructions on the forum, and it works like a charm, nice. (Suspending is for me by far the usual use case, also instead of 'lock screen'. So its crucial for me to to do that on easy keystrokes.)

Since its only a workaround (to have shortcuts, but not the neat full thing) I'll let this open until its reimplemented. c ya

tknomanzr commented 6 years ago

Closing since I fixed this for the Helium release.

BunsenLabs / bunsen-utilities

hotkeys for bl-exit #34

^ I agree that considering the scope of our little projects, introducing this kind of practice would probably be overkill. However there are even some Debian git packaging tools that work this way IIRC.