richardgv / skippy-xd

A full-screen Exposé-style standalone task switcher for X11.
GNU General Public License v2.0
340 stars 76 forks source link

[request] Maintainership / issues tracker #78

Open dreamcat4 opened 5 years ago

dreamcat4 commented 5 years ago

Hello Richard, I have been implementing certain new features into skippy. It now has:

My reason for doing this was to get a decent alt-tab solution for a newer linux desktop environment (Budgie desktop). Since their own graphical alt-tab faeture simply was not even started yet. It was [least amount of work] for me to update and tweak skippy's existing codebase. Rather than make something entirely from scratch (in Vala language) for the Budgie Desktop only.

These features are pretty useful, and will benefit other people who don't have a graphical alt-tab switcher either... For example, those using the compton compositor, MATE, or i3. And whatever else. These features have been implemented to work in a way generic to X. And not depend on the assumption of any specific WM.

The other main alt-tab feature I have been considering is to keep a window activation history. So that alt-tab re-orders the displayed sequence in a manner that is more effecient for keyboard users. This is all whilst retaining the traditional mouse based modes of skippy.

Feel free to look at my recent commit history in the network graph to see what I have already done...

===

Hopefully that ^^ explains where I am coming from / my motivations.

At this point it would also be helpful to take over the issues tracker. At least for the time being. That is: if you don't have any strong or fundamental objections to that. Moving the issues database onto my branch for skippy-xd would help new users more easily discovery where the current activity is taking place. Amongst all of the possible branches. And not assume it's a dead project at this point. Hopefully that would also further help to encourage more contributions. It would allow me update and close those specific issues which I have already fixed myself. Or will otherwise be fixing soon, as I seem to continue to make further improvements. Rather than have 2 different issue trackers and duplicated issues flying around everywhere.

I can also close (or link together) certain duplicated issues (where applicable). And keep a better track of remaining parts of such issues, which still are not fixed yet. Because it seems like (quite often) a user has put forwards multiple suggestions within a single issue.

Finally, I could continue to watch out for new issues raised. And manage new / recent bugs regarding those specific new features and functionality. Which was added by myself. All in a central place.

Since improvements from other contributors also pop up occasionally. I can see them in other people's forks (in the network graph. I intend to go though them all. For example (including but not limited to): debian packaging files, and systemd service file. There are 7 other forks which I can check over. To scavenge for potential extra added value in addition to my own commits. My overal goal is not to discard any contributions out-of-hand. However I will also be reverting anything that subsequently ends up being too be troublesome / causes new bugs or unforseen errors. This new activity will bring them all together into one lineage. Rather than just be spread around everywhere, and keep them from being missed out on entirely.

My main goal (in terms of maintainership aspect) is not to hold onto skippy for a very long time. But rather - just try to clean it up a bit. Update it to be the best it can currently be, and fulfil my short term goals. Consolidate these updates all together into a single place, single release. This will then put skippy into better shape, for the next maintainer. Rather then have it seem falling into disrepair. Hopefully this will also encourage another developer will come along after me, who is better equipped than myself in terms of X / has more experience / can fix more of the bugs, etc... Since my very long term goal is not actually to hang onto skippy forever.

My other remaining short term goal (being on ubuntu here) is to make a packaging release for debian / ubuntu. Which won't happen until I have finished making more updates to skippy in the meantime. For the remaining smaller improvements and bug fixes. It's nothing too drastic actually. I shall also need to defer to you for the very intensive X specific stuff. Like drawing / graphics side / etc. Which I really don't wish to meddle around with too much myself. My main personal reason for trying to avoid those parts of skippy is wayland, it seams a waste of my time to learn so much X.

SO Richard: would you be able to pass the issue tracker over to me for a while? It would make my job a lot easier. & many thanks for your previous work on the skippy codebase. And if you ever come back (time permitting) to working on skippy in the future. (But hopefully... that would be after / ontop of my other pending commits ! ) Kind regards.

revast commented 5 years ago

Wow! Thank you for taking care of skippy-xd! It's just a too good piece of software to be falling into disrepair. I will try to help testing it & more (not really a coder, though)

dreamcat4 commented 5 years ago

No problems guys. Still waiting to hear from Richard about this. In the meantime I have got another recent slot opened up in my time. To work on skippy a bit more. Fix some more little bugs and things like that.

colonelpanic8 commented 5 years ago

@dreamcat4 Where areyou keeping the changes you have made?

colonelpanic8 commented 5 years ago

@dreamcat4 Ping. Where are you keeping these changes?

dreamcat4 commented 5 years ago

In my fork. And also there are some other changes I never finished / uploaded.

https://github.com/dreamcat4/skippy-xd

And anything new will appear there.

However I just inevitably got distracted again, before finishing what I had on the table. Will be coming back around to it again at the next opportunity. It's more a sporadic type of development since getting into this code takes some time to get into that zone again. Spending less time than that has not proven to be very productive.

In the meantime if you have any other bug reports to file that's absolutely fine and I will try to look at those next time I get back to this. Alternatively if you want to make some kind of an initial beta release of distro package(s). Without being held up. Then that's absolutely fine also. The latest source is always going to be my fork there. And that location isn't going to ever change. Other than that? Well if you want to have a crack at the code yourself for any features or bugs then by all means. And I will review / merge changes fairly promptly (few days). Without needing to wait for me to get another large block of time back. Kind Regards.