AutoKey 0.96.1 goals, ideas, and known issues...

[josephj11]

This is a general discussion to keep track of what has to be done and/or resolved for the next maintenance release of AutoKey.

When tasks/requirements firm up, they should be converted to issues and linked back to here.

This an informal discussion. Things that don't have consensus agreement are fine. The main purposes are to make sure things don't slip through the cracks and to get us thinking about what we want now and what can wait until later.

Keep in mind that our developer resources are extremely limited at the moment, so this release probably should be fairly minimal and we don't know when it can be accomplished.

[josephj11]

I would like to see #600 - display an error message or even fail if Wayland is running to be included. A lot of people are wasting a lot of time trying to figure out why AutoKey doesn't work and then asking us. We can avoid almost all of this with a simple test and an error message.

[josephj11]

The help function of the GUI needs work in both front ends.

The API link has to point to the new API docs.

The main/manual link has to point somewhere better than the troubleshooting page. It could point to the root of the new auto-generated documentation, to the root of our wiki, or to somewhere new.

Do we want any other entries in this menu? They should be easy to add.

This involves almost no coding, so it will be easy to implement without expert developers.

[Elliria]

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

[josephj11]

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

[josephj11]

I think there may already be an issue for this, but I would like the script error menu entry promoted to the main menu so it's available in one click. It would be great if it turned red or was otherwise highlighted when an error has been detected.

This is nice, but not necessary. It's worth it if it's easy to do. I think it would be a big UX improvement for a small amount of effort.

[Elliria]

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.

[Elliria]

As you had mentioned elsewhere, @josephj11, it might also be a good idea to put a "This is old," notice in the old API with an explanation of which versions it's for and a link to the new one and which version it's for. I'll add that it might also be a good idea to put a similar notice in the new API pointing back to the older one for those of us who still use earlier versions of AutoKey.

[josephj11]

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.

[Elliria]

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.

[josephj11]

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.

[josephj11]

We need a tag for issues that identifies them as related to the next (point) release - not sure if it should be "0.96.1" or something more generic. If it's something more generic, all issues with that tag would have to be reviewed when the release comes out and the tag removed or replaced to start with a clean slate.

This is a generic concern shared by all active projects, so best practices undoubtedly already exist. We just have to find them.

[Elliria]

Modify debian/build.sh and INSTALL to use apt-get instead of apt to get rid of the warning. This satisfies part of #769.

[Elliria]

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

[josephj11]

Look at and possibly modify autokey/debian/rules to use a newer version of Python. It's currently set to 3.8 and I don't know if that needs to be bumped or not.

[Elliria]

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

[josephj11]

Forgot the most obvious ones:

update the AutoKey version to 0.96.1.
autokey/autokey.spec - this still says 0.94.1 so IDK what it's used for
autokey/PKG-INFO - still says 0.96.0-beta.7 so ...
autokey/lib/autokey.common.py
VERSION = "0.96.1"
MAINTAINER = "AutoKey Project"
MAINTAINER_EMAIL = "https://groups.google.com/forum/#!forum/autokey-users"
BUG_EMAIL = "autokey-users@googlegroups.com"
API_URL - "https://github.com/autokey/autokey/wiki/API-Examples/"
HELP_URL = "https://github.com/autokey/autokey/wiki"

Fill in and update CHANGELOG.rst

[Elliria]

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.

[josephj11]

#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.

[josephj11]

Update autokey/new_features.rst - remove most of it to trash or wiki as appropriate. It's really old.

[josephj11]

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.

[Elliria]

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.

[ineuw]

@josephj11, a gem of a comment.

[josephj11]

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

[ineuw]

I am referring to being extra diplomatic.

[Elliria]

This page is turning into a monster. It's going to be difficult to keep it all sorted out and to tell what's done and what still needs to be done.

What do you say we transfer each of these to separate issues and label them with the "help-wanted" label that we already have? We could create specific additional labels, too, like "goal-0.96.1" or something like that.

That would have the added advantage of providing great satisfaction when one of us can close each of them as they're completed and I believe they would remain in the history, making them easy to look up if we ever needed to.

[Elliria]

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.

[josephj11]

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.

[josephj11]

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.

[Elliria]

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.

[Elliria]

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

[ineuw]

What's missing for users, is knowing about various installation sources and methods. With previous versions, I used pip3 install --user https://github.com/autokey/autokey/archive/v0.96.0.zip but this no longer works with 0.96.1.

pip3 check https://github.com/autokey/autokey/archive/v0.96.1.zip
pynacl 1.5.0 requires cffi, which is not installed.

After installing cffi, all conditions were met but the package doesn't exist.

[josephj11]

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]

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.

[ineuw]

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.

[Elliria]

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.

[ineuw]

My knowledge and experience is with text databases. Installed ZIM and will explore it. I know a lot about how to manage text and how to find uniqueness to perform text operations, but on code I used it only on limited times, But, Python is not difficult and can easily relate to it.

[josephj11]

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.

[Elliria]

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.

[ineuw]

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.

[Elliria]

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.

[ineuw]

About Zim. It's an excellent idea.

[Elliria]

It occurred to me that we might be able to ask for help from some folks who are learning Python at freeCodeCamp. It turns out you can't just ask for that, but they do have the How to Contribute to Open Source Projects – A Beginner's Guide page that contains the the How to find an Open Source Project to Contribute to section that lists a bunch of sites where projects can list themselves as being in need of developers.

If you read the pointers they provide to freeCodeCamp members who are looking for projects to contribute to, the only thing we're missing is a Code of Conduct and when I followed the link on that page to see what's involved in creating one, it looks pretty simple. They've got a drop-in one that we can use. With that, we should be nice and appealing to anyone looking for a project to work on. Once we have that, we could list ourselves on all of those sites and see if we can't reel in some developers.

[Elliria]

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.

[Elliria]

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.

[Elliria]

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

[ineuw]

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

[Elliria]

Aw, I'm sorry.

[josephj11]

Places to register

https://ovio.org/submit

https://www.codetriage.com/repos/new

https://up-for-grabs.net/#/ all the way at the bottom

[Elliria]

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.

[josephj11]

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

[Elliria]

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.

[josephj11]

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.

[Elliria]

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.

[josephj11]

TL;DR: it goes in main and we should probably do it, but ...

I'm not sure we "need" a code of conduct because we have so few active contributors, but having one can't hurt anything. If it makes visitors feel warm and fuzzy ...

If we put it (only) in develop, nobody would see it, so that's self defeating. IDK exactly how develop gets to be main eventually. It's some kind of merge.

If you put something in main, but not in develop, then you get these weird messages that parts of main are ahead of parts of develop and, that may be fine, but it's confusing and makes you think twice before doing the merge for the next release. But, if we're actually changing something, we don't want to have to do it twice every time - once for each branch.

So, whatever way you're most comfortable with is the way to go.

Once we're happy with any changes to the code, you can do PR(s) to one or both branches and I will merge it.

[Elliria]

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

[josephj11]

TIhat would be my preference. Then, we can update it in develop if necessary so everything in develop will be identical to or newer than main which is simpler to think about.

I woud wait to do it until we have a draft that looks good to start with - to make things simpler and because main is public facing/official and we don't want to be unnessisarily wrong about something in public.

[ineuw]

@josephj11 @Elliria, spaghetti or not, I can sort out the topics, though from now on I will reference my comments. Then, the spaghetti is manageable (with or without tomato sauce).

[Elliria]

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

[josephj11]

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

[josephj11]

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

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

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

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. Additionally, you must use Twine to upload your files in order to get full support for these fields. See the Python Packaging User Guide for more help.

[Elliria]

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.

[josephj11]

PRs: Apparently they work, but when you merge them into master, it tries to do a release (I tihink that's what's going on.)

If it fails to do a release, it's fine witih me as long as it gets fixed eventually.

So, you can do whatever PRs you want to and, if they stay clean, I will merge them whenever you explicitly tell me to.

[Elliria]

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

[josephj11]

I don't do merges - especially to master - without an explicit request to do so.

I don't want to be jumping the gun or accepting responsibility for changes I didn't make myself.

Something like "Please merge (this list of PRs)." is all I want.

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.

[Elliria]

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.

[josephj11]

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

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.

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

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.

[Elliria]

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.

[josephj11]

I hope you can teach me and maybe help me get my project up on git/GitHub. It's all written in bash, so it's way simpler than all this Python stuff.

[Elliria]

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.

[josephj11]

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.

[Elliria]

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

[josephj11]

Nope. The latest released version of Duplexpr. I already have zim, but haven't used it much yet.

[Elliria]

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

[josephj11]

Just noticed that our API Examples wiki is missing new things added with 0.96.0. There are a bunch of new mouse API calls that have no examples.

We might want to add a note to the wiki:

See mouse API calls for additional mouse API calls which have no examples here yet.

I don't know if there are other new calls that also need examples.

The engine API has only one example. That could also use a similar note. I'm not sure we need examples for the calls that create scripts and phrases because only very advanced users are likely to use those.

This has no direct impact on releasing 0.96.1. It's something to fix eventually.

[Elliria]

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

[josephj11]

@Elliria I just reread this monster discussion. Unfortunately, I didn't take notes.

If you ever get bored, there are a bunch of loose ends here that need addressing. A couple that I remember are about adding a code of conduct and seeing if code ninja has a way to add a Python category yet.

[Elliria]

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.