A Contact Us entry that points to the Community page might help more people to find us and communicate with us.

This would go in autokey/lib/autokey/common.py .

CONTACT_US = "https://github.com/autokey/autokey/wiki/Community"

But gtkui/configwindow.py and qtui/configwindow.py will need to be modified to use it and possibly a few of the other fields that are there, but appear unused.

gtkui/configwindow.py:
at lines 816 - 821, 1306 -1334

qtui/configwindow.py:
at lines 141 - 147, not seeing corresponding code I expected to find

I agree wholeheartedly and would like to add that I would love it if the notification that opens automatically when you have a script error would be on top of all other windows.

That's why I created this topic - so things like this don't get forgotten - like I just did.

Maybe we should add metadata into each API in the source code indicating the range of releases it applies to. I assume that if it's still generated into that document, it means that it's valid for the current release, so we may only need a minimum release number. This would be done on a "from now on" basis to avoid a bunch of research with very little benefit.

The one problem with that is that it would have to be actively maintained and not forgotten about on new releases, but it seems like it would be a small thing to do, so I'm all for it.

Yeah, but only when we add or modify an API call. Since the page is auto-generated the last release is always the current one because the whole function would be gone if it's not in the current code so the end version is implied and doesn't need to be stated. If a call is changed, it's also from now on. If a user needs a previous version then they have to go back and inspect that version's source code (which they have on their local disk) or save an old copy of the page before it gets updated. (From now on, they might be able to use the wayback machine too if it stored the page from someone looking it up there.)

I'm still not sure how GitHub works, but the page itself is probably in a GitHub repo with prior versions saved in git itself.

I created issue #772 with all of the files that need to be changed.

Good catch. I've added it to my list of files to change when updating versions.

It looks like #227 is related to this, but this particular goal should get its own issue, I think, since you mentioned many more changes.

#227 looks problematic. Aside from the code in the issue, it looks like figuring out what to do is harder than actually doing it. So I have not marked it for the release. Sam is still around, so maybe he could help figure out what to do.

Be extra diplomatic in any distro maintainer contact (not that I think you wouldn't be), because it seems like they're generally not used to being contacted by the unwashed ;) and we can't live without them.

No worries. This would be a brief query as to whether changing:

foo
^^^

or:

foo
+++

to:

foo
---

in the CHANGELOG.rst file would have an impact at their end or not.

@josephj11, a gem of a comment.

@ineuw Thanks. But in this spaghetti issue, I can't tell which comment you are referring to.

I am referring to being extra diplomatic.

I remembered the renaming links problem. What I am proposing is to create a 0.96.1 label. Add it to all issues specific to that release.

That sounds fine to me.

Some time after the release comes out (maybe after related issues die down, but before we start in earnest on a subsequent release), we should list all issues with that tag (easy). If there are any that are still open, we should add a new tag to them as appropriate. Then, we just delete the 0.96.1 tag because we're done with it.

It sounds like a good plan. Go for it.

No renaming involved.

That's perfect, although I still would like to see the renaming mentioned above done so that all the labels are easier to read.

Despite your assurances, I'm still a bit scared to use rename - even for case-only - because if it doesn't work as expected, there's no way to repair the affected issues.

Unfortunately, it looks like almost all of the mixed case labels are ones I created. :(

I'll see if one of them has very few tagged issues (so I can track them manually) and try that one first.

I lower cased them all.

I also renamed 0.94.0 to unsupported version. That knocked the label off of 3 issues, but I don't care because all of them were very old, two of them were closed, and I closed the third one.

I will create a 0.96.1 label shortly.

Oh, nice - they look so nice now. Thank you for doing that.

I'm also looking through all the ones you closed and I'm about to go and try and break my fork further or fix it, as the case may be.

I probably would have closed #647 as wontfix since that was a very odd non-issue.

That's probably because 0.96.1 is only a gleam in our eyes. The branch hasn't even been created yet, let alone implemented.

This is just preplanning because we were starting to have good ideas and I didn't want them to be scattered and lost.

There's also the small problem that we don't have an active lead developer (or anybody else) to code the Python parts of it now that Bluedrink9 has stepped back from that roll.

Elliria is starting to learn how to maintain the project and I'm following along, but that appears to involve a substantial learning curve and there's no indication that she even wants to be our lead developer.

I'm looking at the code a bit more and some of it looks deceptively simple, but I really don't know much Python let alone the specifics of AutoKey. Also, I already have more than enough to do supporting the project and our users.

I briefly looked up those two packages. PyNaCl is a very cleverly named package that interfaces to libsodium - which is about encryption. I have no idea why AutoKey would even need it. cffi, which it requires, is an interface that allows Python programs to call code written in C - which is done when things need to run fast or a program needs to use things that already exist in C, but not in Python. If I were you, I'd uninstall cffi for now.

Elliria is starting to learn how to maintain the project and I'm following along, but that appears to involve a substantial learning curve and there's no indication that she even wants to be our lead developer.

I'm not good enough to be your lead developer. I only know the basics of Python and have no advanced skills. I do, however, care very much about this project and am happy to jump in in the interim as your temporary "lead" developer (air quotes because I'm very uncomfortable with wearing that hat) who will sometimes need help to get things done and may not be at all capable of some of the things that will need to be done. I'm very grateful for all that you and the others have been doing so far as we try to figure this out.

I'm looking at the code a bit more and some of it looks deceptively simple, but I really don't know much Python let alone the specifics of AutoKey.

Python does look deceptively simple, but can be quite convoluted, especially when working with code that other people wrote, as is the case here. It doesn't take long before you get yourself all tangled up when trying to follow the logic of some part of the code.

Our love of this project must count for something, though, and should help us to remain motivated to just keep trying, so although we may not make significant progress on our own, I think we can still keep this moving ever-so-slowly forward until we can get more qualified help again or until we've climbed around inside the code so much that we become capable of everything the project needs. Anything is possible.

Much thanks for sharing all of this. I jumped at the article title. That's all. On the other hand, I would like to offer help in any way.

That's good news, @ineuw, and we will appreciate anything you can do to help. I'm slowly experimenting and learning how things need to be done and @josephj11 is providing all sorts of useful information by digging around in the code.

The way I have zim installed now, it's local to me/my notebook. We would need it setup in some collaborative mode for it to be useful to us as a project. IDK anything about how to do that - if it's even possible.

That would probably involve you having to host it in some way. The tools we already have are hosted for us, which is most likely a major advantage.

Installed ZIM. It's a very clean specialized offline database for organizing interlinked text files, much the same as Wikimedia uses for it's internal webpages where any case and space is accepted, etc. AFAIK If you plan to link these pages on the web, the main segment of the address, whatever case you write in, will be changed to lowercase until "/" termination.

It's intended as a personal wiki and that's how I use it. It's not suited for convenient sharing. Here's what its manual has to say about collaboration.

About Zim. It's an excellent idea.

https://www.contributor-covenant.org/

https://opensource.guide/code-of-conduct/

Yep. The freeCodeCamp page also links to the second one, which links to the first one, so apparently great minds think alike (can you tell I'm a big fan of freeCodeCamp?).

https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-code-of-conduct-to-your-project

These steps look straightforward and shouldn't take long. They show it being done to the master branch. Is that something we would want to do as well? I realize that all new code should be done in the develop branch, but this might be an exception. Thoughts?

https://github.com/auth0/open-source-template/blob/master/CODE-OF-CONDUCT.md

It looks good, but beware that the version in that one is outdated (they're up to version 2.1 now), so we'd want to grab the fresh file from https://www.contributor-covenant.org so that we'll have the most recent changes included.

It probably wasn't necessary at the time, but that freeCodeCamp page mentioned above makes it a requirement for anyone looking for a project to join (in the Must have elements in all OS projects section of the page, so it might not be a bad idea to have one to make ourselves that much more attractive to potential coders.

By the way, that signature was very cute, @ineuw.

@Elliria, about my "cute" signature, Linux Mint removed it. :-)

Aw, I'm sorry.

I'm going to add Pull Request Roulette as an interesting free service that gives users the chance to review your pull requests for you to help you decide whether to merge them or not. Their server is currently down (503 status), but they have a GitHub page and we might want to keep an eye on them to see if their site comes back up in case it's something that would be of interest at some point.

Just did codetriage

https://www.codetriage.com/autokey/autokey

They have a badge icon there that we can add to our web pages somehow if we want to later...

https://www.codetriage.com/autokey/autokey/badges/users.svg

Very cool. How did you subscribe to it? By the way, I just created an issue that reminds us to add that badge to the project.

I don't remember. I think I got the offer when I tried to add our repo and it said I had to sign in to do it. Maybe if you select an issue and offer to work on it, it will ask you to sign in.

It's not working right yet. I just got my first offer of an issue to work on and it was #375 - which is a really hard, unsolved one.

Yep. Apparently, triaging is what gets you subscribed. I did it and they sent me a bug that's listed as easyfix, but not for me. Maybe the next one will be.

I suppose it wouldn't do any harm to put it into both, right?

Yeah, it's a nice mess and if we occasionally get any of the posts mixed up, that's okay, too.

@ineuw I'll just defer to George Washington: "Avoid foreign entanglements." ;)

Just verified my pypi account still works and I have maintainer status for AutoKey.

Excellent.

It says that updating setup.py will take care of dependencies, etc., but only does anything when anew release is added.

Good to know. I've added that to my growing developer notes personal wiki page that will eventually go somewhere where we can all use it.

Instead, we could add a note to CHANGELOG.rst in master... and on the Installing page of the wiki...

I'll take care of that. It's trivial and could easily be done right away. Can I do PRs at the moment or do we need to sort out the errors that you're still getting on PR merges first?

Project description and sidebar To set the 'autokey' description, author, links, classifiers, and other details for your next release, use the setup() arguments in your setup.py file. Updating these fields will not change the metadata for past releases.

Good to know and I've also made a note of it. Our Development Status in that metadata also needs to be updated. I'll take care of it.

Additionally, you must use Twine to upload your files in order to get full support for these fields.

That's new to me. Instructions are in our wiki.

Okay, I've done a few today. They all have green check-marks, so hopefully it all goes smoothly at your end.

Whenever you're ready, I can also make you a maintainer (if I can remember how to do it) so you can do these operations yourself.

That should happen when you feel it's wise to do so. I'm still learning and may yet make some spectacular mistakes.

It's not an "advantage" to me if you make a "spectacular" mistake and my name goes on the merge command.

True.

Much of the time, I'm not going to know if your changes are good or bad, so I'm not much of a safety net.

You're definitely a source of comfort, though, because you're an additional set of eyes and a voice of reason.

However, you can always discuss changes with me before doing them and get good at reverting changes.

That's true, and I plan on doing that for any change that I'm at all unsure of or that would simply benefit from additional input (like updating wording of documentation or something like that).

You should probably add some comments that don't do anything to something and PR and revert them on a test branch. If we do something wrong on master (or on develop when you're not the only one accessing it), that's not the time to research how to undo it.

I'm already on it in my dummy repository. I created a directory with a file in it today and renamed the directory. I also created another directory with a file in it and deleted it. I also figured out how to configure git so that I could use it from the command line. Up until now, the only stuff I had done locally was cloning and then experimentation on those files without pulls or pushes. It's all slowly starting to make sense.

If you already have the whole project as folders and files on your computer, it would take only a few seconds to get it onto GitHub. I've currently got a Zim wiki GitHub/git cheat sheet going and can either share that with you or turn it into a Gist. I'm thinking of turning it into a Gist to make it accessible at any time from anywhere.

TY Cool. I have to get the latest version from soureforge for a base and then apply the very few changes I've made since then. I don't think I'll do anything with prior versions.

Ah, you mean Zim? You don't have to grab it for this. I'll be converting it all to a Gist anyway.

Ah, okay. Well, if you have it in files and folders, it can go onto GitHub.

Hopefully you'll be able to add those. I'm still using AutoKey 0.95.10, so I haven't tried them.

We can put the ninja site behind us. It's failing a Firefox security scan, so I'm not going to go there and check it. As for the other loose ends, I'll keep this page in mind if I ever get bored, but as you said, it's a monster.