About Autokey GTK and QT, in Linux Mint Cinnamon 21.1 and Kubuntu 22.04

[ineuw]

Installed Kubuntu to compare it with Linux Mint Cinnamon, as well as learn about Autokey-gtk vs Autokey-qt. My first surprise was that Kubuntu came with gtk installed as well. But, I was interested in Autokey-qt.

Soon after I mentioned the built in ak-qt editor's weakness, an update repaired the editor. It now functions as the gtk editor. The gtk version has the same panel menu problem as gtk in the LMC version. The cause is commented by someone in one of the Kubuntu forums that it's an outdated component that affects Autokey-gtk.

[josephj11]

The cause is commented by someone in one of the Kubuntu forums that it's an outdated component that affects Autokey-gtk.

Link please.

Kubuntu undoubtedly uses a number of GTK packages, so the GTK libraries are installed as automatic dependencies of these packages.

The real strength of KDE is that it offers very extensive customization options. Most other DTEs are the way they are and that's it.

If you just wanted to install AutoKey's Qt front end, you could do that in most distros. You don't need kubuntu or the KDE DTE. Installing autokey-qt (from a prebuilt package such as a deb should cause the Qt libraries to be automatically installed if no other application on the system has already done so. I have no idea what hoops you would have to jump through if you installed with pip.

If you installed it with dpkg, then the dependencies would not be installed and you would get some installation error messages. This is fixed by subsequently running sudo apt install -f or something similar if your distro uses a different packaging system.

While you're in kubuntu, check out the kate text editor. Out of the box, it's pretty nice, but like most things KDE, it is highly customizable and very powerful. Notably, it offers sessions. You can save your current session with a name and reopen it later. This will restore any tabs you had open and most of the display settings that you may have changed. Sessions are a bit tricky, but I have a couple that I use all the time.

[ineuw]

I like when you keep me on the straight and narrow. From now on, I will bookmark everything for reference before creating a post. I am still smarting from the IBM ASCII issue. Not that I am wrong, but because I question my memory.

1st reference. - This first post was my own, which you may about because I usually crosspost related topics

2nd reference: A post in one of the many Kubuntu forums I glanced at, while searching for an unrelated issue, also mentioned the AyatanaAppIndicator problem in panel/taskbar, and that made me create this post.

Like Raskolnikov, "I will return to the scene of the "crime" and will find the article. It's only time.

[Elliria]

My Qt editor is still a mess, but that may be because I'm still using AutoKey 0.95.10. I get around that by just using the GTK version all the time unless testing is needed in the Qt version. What's the panel menu problem?

[josephj11]

Left clicking on the Qt panel icon opens the AutoKey menu. Right clicking on it opens the context menu.

Left or right cliking on the GTK panel icon opens the context menu. Apparently, getting it to work the same as the Qt panel icon does is difficult or impossible.

[Elliria]

Ah, yes, although in my case, the QT panel icon opens the context menu on right-click and opens the AutoKey main window on left-click. That's kind of interesting. It would take me a while to get used to if it were also done to the GTK front-end, but it sure would make it easier to make edits to scripts or view error messages.

[ineuw]

This is a longstanding problem by the Ayatana panel control which GTK uses. This is the issue that crops up with other apps as well. You can find GTK/Ayatana issues in the Kubuntu forums.

[josephj11]

I believe you, but I don't see anything in that link that appears to relate to the clipboard at all.

[ineuw]

@josephj11, posted in the wrong conversation perhaps?

[ineuw]

I bring up these observations, but I don't see this as a major issue. It's the novelty of discovery in Kubuntu that made me post this. I never used QT in Linux Mint Cinnamon which is everything else but KDE and Qt, which I avoided because of past experience.

Aside from this AK 96.0 always works well in either format, but I need additional understanding of app/clipboard/keyboard/mouse interaction.

[josephj11]

Reading the answer you linked to seems to indicate that with some small changes to autokey-gtk we could get the main window to open up from middle clicking the panel icon. That's better than nothing and would be worth an enhancement issue. It's theoretically possible to get a middle click on my touchpad, but I've never tried it.

I thought you already knew everything about the clipboard after all the work you've done.

Somewhat unrelated: I just reviewed a PR from Sam and he has added a clipboard macro for phrases. It's only in develop for now. I'm not sure how to use it in practice, but it seems like it could be quite useful.

[ineuw]

As I may have mentioned, for me, knowing the quirks of a software is a major advancement because knowledge liberates by providing contextualization, which resolves issues of relevancy. Once understood, I am OK with it and it's up to me to deal with it.

As for clipboard issues, they are not caused by Autokey, have nothing to do with Autokey. It is about how some apps use the X-clipboard features.

Another promise: The next time this occurs, I will post screen shots and details for the record

I will also check out Sam's contribution.

[ineuw]

Reopened this to thank @Elliria and @josephj11, for suggesting to try Kubuntu with Autokey.

I started this post after my first Kubuntu installation because of unexpected glitches related to Qt in both OS. Reinstalling them triggered the installation of the missing libraries, and Qt and Gtk work perfectly well in both OS. Using autokey-qt for the first time in Kubuntu, I finally had a chance to compare them because I only use Gtk in Linux Mint.

After days of comparing Kubuntu with Linux Mint and recognizing their underlying familiarity, I learned that Linux Mint is originally based on Kubuntu from this article.

My ongoing issues with the clipboard copy and paste have nothing to do with Autokey.

I was expecting the MS-Windows experience where [Ctrl-c, Ctrl-Ins,] and [Ctrl-v, Shift-Ins] are synonymous (to the user). Using Parcellite, I am able to replicate this feature by synchronizing the CLIPBOARD and PRIMARY contents. Otherwise, I ended up pasting data, copied and abandoned from an open app in another window. Selecting this option doesn't affect Autokey copy & paste of selections.

Thus, I removed all 'focus' and 'clipboard cleaning' code snippets because they are unnecessary.

I plan to reply in context, to each of the issues I raised in past posts.

Finally, like Icarus of Greek mythology, I flew too close to the sun, the wax melted, and I crashed. My attempts to learn and test everything all at once (in two languages), resulted in destroying the motherboard with the CPU, an empty 1TB SATA Seagate, and a 128GB SSD, so now working on a laptop.

[josephj11]

I bought a can of compressed air long ago. Haven't really needed it since then.

Check out the script I just posted on Gitter. It uses the clipboard and the selection at the same time and it works.

[Elliria]

@Elliria, thanks for asking, everything is backed up. On the other hand, I sort of expected it. The fried equipment was 7-8 years old but worked well. The cause was a couple displacements of the HDMI cable from the display, as it hit the wall. It induced a short while the boot SSD was in write mode. I had extra 128Gb SSD just for boot. That is how I was testing different OS.

From now on, don't hit the wall with your HDMI cable. Use your fist instead.

Do the keyboard commands depend on the app, or another app executing prior to the app?

Are you talking about the Shift-Delete and Shift+Insert? Those are my preferred way of doing cut and paste.

[Elliria]

I also suspect that when two subsequent copy commands are received without a paste, the clipboard data is moved into the PRIMARY memory area and this is what causes two different paste contents in my case.

AutoKey relies on a live clipboard that responds instantly to what's selected/copied or not selected/copied at any given moment. I suspect that what's happening here is that the data isn't being moved at all, but that you have the "Prevent empty clipboard" option enabled in your clipboard manager. When that's not disabled, the clipboard manager will offer up the previous entry from its history rather than an empty clipboard. It's maddening and it's enabled by default for some reason - at least in KDE.

[josephj11]

@Elliria I never really noticed (or understood) the prevent empty clipboard option.I just turned it off on my system and I'll see if I notice any difference.

One thing I have noticed before is that if I press Ctrl+c twice in a row (E.g. when I'm not sure if I pressed it the first time), it doesn't add the entry a second time to the clipboard history - at least with klipper.

This whole thing is a delicate dance of interprocess communication which "explains" why pressing Ctrl+c works in most applications, but doesn't work in terminals because they choose to use it for something else. The application (usually through some common utility library functionality) has to decide what to do with any keystrokes or signals it receives.

[Elliria]

I guess I don't understand the Prevent empty clipboard option, either.

I didn't know that about the ctrl+c being pressed twice not adding two entries to the clipboard history, but that makes sense, since the data is already there, so it's probably that way by design.

You're right that the application ultimately determines how to use what's on the clipboard, so we're at the mercy of the individual developers and can see behavior variations from one application to another.

[josephj11]

Since I was working with AutoKey, I "assume" clipboard means "Clipbord" and selection means Primary selection.

@Elliria and @sebastiansam55 : Looking at the API docs to answer this, I got more confused. fill_clipboard says "selection" and get_selection says "mouse selection". Neither of those seem right. It looks like the GTK documentation is the same. Aren't these descriptions wrong, or at best, misleading? And shouldn't the actual selection ones say "primary selection", not just "selection"? The old version of the documentation seems like it was slightly better than this.

I have a programming followup question about this that I will post to Gitter shortly. I answered it myself and posted the resulting script on Gitter.

[ineuw]

Since I was working with AutoKey, I "assume" clipboard means "Clipboard" and selection means Primary selection.

Sorry, but that is wrong. The Kubuntu generic Clipboard app found pre-installed, explains the difference when pointing to the options mentioned in my post. Accordingly, keyboard keys of Control C and V use the CLIPBOARD and the mouse copy and paste is assigned the PRIMARY.

I selected synchronization to simplify the process of elimination and analyze what happens to the clipboards' contents between manual copy and paste, and Autokey. Then, test the same without synchronization. However, at this moment this is theoretical, since I have no access to Kubuntu, but plan to install it on an external USB drive soon.

[josephj11]

I'm not seeing the difference between what I said and what you refer to. I think we may just be hung up on terminology. PRIMARY also gets set using keyboard selection such as shift+left or shift plus other movement keys (right, tab, back tab, home, end).

"Communication is the problem to the answer." (10CC - The Things We Do For Love) One of my all time favorite quotes. I'd bet almost no one even noticed it in the song or stopped to think about it and realized how amazing/concise/funny/ironic it is. It directly illustrates the point it's trying to make.

[Elliria]

@Elliria and @sebastiansam55 : Looking at the API docs to answer this, I got more confused. fill_clipboard says "selection" and get_selection says "mouse selection". Neither of those seem right. It looks like the GTK documentation is the same. Aren't these descriptions wrong, or at best, misleading? And shouldn't the actual selection ones say "primary selection", not just "selection"? The old version of the documentation seems like it was slightly better than this.

Yep, that needs to be fixed. It looks like a case of copy-paste gone wild. We've all done it a time or two. We actually need to go over every inch of that documentation, but this will be a nice start to see what it's like to make the edits. I'll see what I can do to get that going.

[sebastiansam55]

I think it's fine, if anything "mouse selection" (ie the text that you have selected with your mouse) makes it more clear what "selection" means to people who aren't familiar with linux copy/paste

[Elliria]

I think they're both inaccurate. The duplicate "string to be placed in the selection" entries can lead to confusion since the clipboard one should really be "string to be placed onto the clipboard" to make it clear where it will be. The "mouse selection" part should just be "selection" since text doesn't have to be (and often isn't) selected with a mouse and leaving it like that could be especially confusing for newcomers who have learned to do keyboard selections. Either way, these are quick fixes. Where to make the fixes is the question, though. On develop or master?

[Elliria]

I believe that Parcellite is Ubuntu MATE's clipboard manager.

[ineuw]

I tried all of the known names, but Klipper is not in the LMC software repository, in spite of many other KDE apps.

I just completed the installation of Kubuntu on an external drive, but it will take me awhile to configure it.

[Elliria]

It's the default clipboard manager in Kubuntu.

[ineuw]

I forgot to check the "About" tab because I focused on the features. I assume that this is the clipboard that appears on the taskbar only when it contains data?

[josephj11]

It's probably set to "Auto" so it hides when it isn't active. That can be set to Hide or always visible in Notifications.

[Elliria]

Yep. That's what I see whenever I put something onto the CLIPBOARD. Note that the icon will not appear in the taskbar/panel/tray if you put something onto PRIMARY or SECONDARY (possible bug?), but not onto the CLIPBOARD.

[Elliria]

I bought a compressed-air machine so that I'd only have to pay for it once. It's amazing how much dust it will remove from a computer even after you've wiped out the inside and think it looks good. Wearing an industrial face mask specifically made to handle dust is advised. Better yet would be doing the job outdoors.

[Elliria]

I did blow mine at my speakers, but from a distance. I'm not sure if that was a bad idea or not, but so far so good.

[ineuw]

Received the dust blower. It's charged by USB and works well, but it isn't an Atlas-Copco compressor. It has 3 speeds, 50,75, and 100000 rpm and seems solidly built. Came with several nozzle sizes and some cleaning brushes.

@josephj11, I can't find your email address and my old accounts were disabled by request because of a scam targeted me managed to penetrate google somehow.

If you have a Wikipedia account and log in, search for User:Ineuw and you can email me from a link in the left column menu of my home page, and I will reply.

[Elliria]

That's good news, @ineuw. Were you "blown away" by how much yuck it managed to remove from your computer? I'm constantly surprised by how much stuff accumulates inside of keyboards, especially.

[ineuw]

Pretty much used the same method with the addition of the vacuum cleaner nozzle as close as possible to trap the dust.

[Elliria]

Please don't use the vacuum cleaner near the computer. It can cause static electricity and destroy some of the components inside the computer. Better yet is to take the computer outside, wear an N95 mask to protect yourself from breathing in any of the dust particles, and use just the compressed air to clean out the inside of the computer.

[Elliria]

If it helps any, these are my notes on the clipboard after looking into it and running some tests:

• CLIPBOARD:
  • This contains copied data.
  • Copy data to the clipboard by selecting text (double-clicking it or lassoing it) and pressing Ctrl+c or right-clicking and choosing copy from the context menu.
    Paste data from the clipboard by pressing Ctrl+v or pressing Shift+Insert or right-clicking and choosing paste to paste.
  • Use AutoKey's clipboard.get_clipboard() and clipboard.fill_clipboard() to access this.
• PRIMARY:
  • This contains selected data.
  • Select data by double-clicking or lassoing text with the mouse or holding down the Shift key while pressing any of the arrow keys.
  • Paste selected data by pressing the middle mouse button.
  • Use AutoKey's clipboard.get_selection() and clipboard.fill_selection() to access this.
• SECONDARY:
  • Very few programs use this. This contains specific in-app data.
  • Copy data to the clipboard by holding down the meta or alt key while selecting text (double-clicking it or lassoing text with the mouse or holding down the Shift key while pressing any of the arrow keys) and pressing Ctrl+c or right-clicking and choosing copy from the context menu.
  • Paste data from the clipboard by pressing the middle mouse button.
  • As far as I know, Autokey cannot access this type of data.

Important: Make sure that "Prevent empty clipboard" is disabled in your clipboard manager.

[josephj11]

@Elliria nice documentation. Maybe it should end up in our wiki. Never saw the term " lassoing text" before.

A few notes:

Using Home, End, PgUp, PgDn also work when selecting text.

It would be good to say why "Prevent empty clipboard" should be disabled. I think I understand it, but I'm not sure. I'm not clear on what the use case for ever having it enabled would be.

I'm not sure about "Very few programs use this. This contains specific in-app data."

Maybe it should be "Very few programs honor this." Since each program has to decide what to do when it receives these key events (usually by the choice of i/o libraries they link to), I would expect that lots of programs might ignore them. Since all these "clipboards" are somewhere external to any applications, I'm not sure why it relates to ''specific in-app data" although that terminology sounds vaguely familiar.

[Elliria]

Thanks, and sorry about the strange term. I'm a very visual person and lasso seemed to capture best what I envision when surrounding text with the mouse in order to grab a block of text. I didn't know about home, end, pg up and pg dn and have added those now. There may even be more that we don't know about yet.

The whole thing has been reworded and the information about selecting text has been given its own section because of how huge it's become. Each of the sections then references it.

I've also done some more research on the SECONDARY section after you mentioned about the "Very few programs" and "specific in-app data" parts. It turned out that my understanding of how SECONDARY works was wrong, so that's been completely updated and is no longer exclusionary.

Last, but not least, I've removed the note about the Prevent empty clipboard since I can't duplicate the misbehavior I had thought I'd seen (so it must be unrelated) and can't think of any AutoKey-specific reason for disabling that.

The updated version is in this Gist for review and comments and, once it's polished, could be added to the wiki. We already have the More than you ever wanted to know about X clipboards wiki page that it could perhaps be bolted onto.

[josephj11]

Just because it's new doesn't make it bad. I like the analogy of "lassoing".

Strong opinion: There don't seem to be standard key cap notations for page up and down, so choose whatever existing version you like, but use the same notation everywhere in our docs.

[Elliria]

Okay, will leave lassoing in. I like it, too. And, yeah, I got the case and spacing for the pg up and pg dn keys from my Razer BlackWidow keyboard. I've noticed that, too, that there's no standard. The keyboard I had before this had all upper-case letters except for the A, which was lower-case. No idea why. Anyway, I'll look through our wiki and use whatever we tend to use there. Edit: I took a look and we don't have a standard for that, so I guess I'll go with PgUp and PgDn.

[Elliria]

I've now looked into editing the new documentation and have come to the conclusion that it's a bit convoluted. Clicking the Edit on GitHub link in the upper-right corner of any page lets you edit the heading of the page, but not the page contents, which makes it pretty well useless for the kinds of things we tend to do, unless we happened to find a heading that we wanted to change.

I did notice, however, that the Edit on GitHub link takes me onto the master branch, so that's where edits will obviously need to be done. I went into the source code of the repository and found the location where the edits need to be done:

• https://github.com/autokey/autokey/blob/master/lib/autokey/scripting/clipboard_gtk.py#L101
• https://github.com/autokey/autokey/blob/master/lib/autokey/scripting/clipboard_qt.py#L89

What do you think about editing those files on the master branch?

[sebastiansam55]

Yes, tho note that (if you're not aware) there are separate Qt/GTK documentation pages for dialog and clipboard scripting APIs and python files

[Elliria]

Yep, and my example was of the GTK edit and here's the Qt one. This will be a quick fix.

[josephj11]

@sebastiansam55 The idea is that the documentation reflects the master branch, if the master branch's documentation is incorrect or out of date it should be updated and then we can get the documentation site regenerated.

If we allow updates to the master branch between releases, then this would document changes in the code that have not been "released" yet. This seems like a problem to me.

[sebastiansam55]

if the master branch's documentation is incorrect or out of date

I think I qualified my statement enough here, documentation implies the commented out portions of the code which literally have no effect on how the code operates.

If there are factual errors or it does not accurately describe the functionality it should be updated

[Elliria]

Also, new changes that are for future versions of AutoKey would go onto the develop and/or beta branches rather than onto the master branch, so there would still be a distinguishable difference between them while using our current branching scheme, with the master branch always being either exactly or closest to the current release and the other two shooting forward.

[josephj11]

As long as we're careful, everything should be fine.

[ineuw]

I am curious what services do clipboards offer naturally without viewers? This is where we should place our focus, at the basics.

I bookmarked this link when it appeared, (smiling at the time), as @josephj11 describing a mysterious clipboard experience,

Clipboard behavior of copy and paste has been my concern going back to 95.xx and later. I should have also mentioned that Linux Mint Cinnamon does not install a default clipboard viewer, and my clipboard viewer installations were temporary. Installed them for a few hours to join the conversation, and then removed them when I realized that can't know whether the data I am looking at is stored in the CLIPBOARD, or in the PRIMARY storage areas. Developers can, and do write to either.

I also mistakenly identified features as Klipper's, instead of Parcellite.

I came to realize that I shouldn't comment on two different versions of Linux, because it's confusing for all concerned. Thus, I will keep on focusing on Linux Mint Cinnamon and gtk, as my primary OS and interest, and Kubuntu as the secondary.

My desktop is waiting for the CPU. With luck I will be functioning normally by Sunday, if Intel's replacement chip is not defective, like the first I received days ago. In the meanwhile, I use the laptop Linux Mint, with a 24" monitor and Kubuntu plugged in a external USB port.

[josephj11]

@ineuw

A clipboard viewer should only be a viewer of the two memory areas and not manipulate them.

That's a valid preference/opinion, but I'm quite fond of klipper's option that allows me to edit entries in the clipboard history (usually to eliminate part of the entry) and I frequently use klipper like a stack where I copy three things into it from one window, switch to another window and then manually paste each of them one by one in separate places so I can do the whole thing without switching windows back and forth several times. That would be impossible without clipboard history. (I'm eventually going to write an AutoKey script to do that with an actual stack for my own clipboard where using the top one pops it off the the stack making the next one available for the next paste operation. That won't use klipper at all.)

I already have a single entry clipboard (written in AutoKey as three simple scripts - copy, paste, clear). It would be easy to extend it to do something similar with another saved value that would be similar to the PRIMARY selection.

I use it frequently when I need something more than once, but klipper keeps changing in the mean time from other copy/pastes I'm doing. It works great with kcalc as a conversion factor if I have to convert a number of values from one unit to another one, but I have to copy/paste those values in and out of kcalc, so klipper keeps changing.

You are welcome to it if you would like to have your own clipboard that you can customize to work exactly the way you want it to.

[ineuw]

I stand corrected. It's not the editing that I am concerned about, it's about the effect of options which I know nothing about. Our universal problem is that none of us have the additional "time" to understand the programmer's intent and research the features just to make an informed decision.

@josephj11, thanks for the info about Klipper and please post the scripts when you have the time.

At this point of our conversation I use both Qt or Gtk problem free in both Linux Mint and Kubuntu, using the same scripts. The rule for me is to log out or reboot when switching.

As for editing in browsers, that's the only thing I do. My raw text is in a Wikipedia text editor and I use AK to clean and format it.

The only AK script I use everywhere is to date stamp documents with the window title and the editor used like this:

# 2023-05-03 19:11 - About Autokey GTK and QT, in Linux Mint Cinnamon 21.1 and Kubuntu 22.04· autokey/autokey · Discussion #822 — Mozilla Firefox

I use AK-gtk in Chrome and Vivaldi as well. Just installed Brave and will try it.

If users need to test a particular issue with either version in a particular browser, I can try it and learn something as well.

[josephj11]

@ineuw I haven't had time to add things to our wiki lately, so I put my clipboard stuff on the cloud. I have been using the free version of Mega for a while, but this is the first link I have shared. It should give you access to the whole folder of scripts (and their JSON files - which you can take or leave). Let me know if you can access the files.

The whole thing is roughly modeled after the Memory Store/Recall/Clear buttons found on calculators.
It uses a single AutoKey global variable. The store function gets the value from the system clipboard, but that's easy to change if you want it to work differently.

In addition to using it with kcalc (which does not have a memory feature), I occasionally also use it to store a password for a financial app that asks for it for each operation. Since it's Python, almost any object could be stored in this "clipboard".

[Elliria]

A clipboard viewer should only be a viewer of the two memory areas and not manipulate them.

I didn't realize that, but I suppose that's up to the developers and/or the communities they code for.

I mentioned elsewhere that Linux Mint as is packaged, does not include a clipboard manager. While Kubuntu does, it's non-removable, but can be disabled. (https://askubuntu.com/questions/1032985/remove-klipper-from-kubuntu).

Strange. I hadn't realized this, either. Thanks for the heads-up on how to disable it. I would have banged my head against a wall as soon as I couldn't find it anywhere in the K-menu.

So, I installed every GUI clipboard in Linux Mint to see if I can disable a viewer without uninstalling. The KDE/Qt clipboard tool "Qlipper" meets this criteria. It has a lot of features all of which can be enabled/disabled. I haven't yet tested it with/without Autokey, and copy and paste with both.

I remember being able to shut down the clipboard program in Ubuntu MATE. It also had a entry in the main menu so that you could bring it back up again afterwards if you like.

Please use the various copy and paste keys we discussed earlier and paste the results of these possibilities:

Copy and paste the one and two from one area to another within the same window, and then copy and paste the same between two windows and share the results.

With the Klipper enabled, and then disabled, test which copy and paste key combination works and which not.

Both work fine for me with one exception in both cases: If you click or navigate in any way within the same window before middle-clicking to paste the selection, the selection will be empty. The right-click paste, however, works flawlessly in both circumstances.

[Elliria]

I'm quite fond of klipper's option that allows me to edit entries in the clipboard history (usually to eliminate part of the entry) and I frequently use klipper like a stack where I copy three things into it from one window, switch to another window and then manually paste each of them one by one in separate places so I can do the whole thing without switching windows back and forth several times. That would be impossible without clipboard history.

Oh, very nice. Now, why didn't I think of that? I so often have multiple things that I want to copy and I put them into a text file or into the Sticky Note widget on the panel (but the widget doesn't stay open when it loses focus, which is frustrating for those types of purposes). It would be so much easier to simply know they're on the clipboard, edit them if necessary, and access them from there.

[Elliria]

I think the primary service provided by clipboard programs is quick/easy access to the history. I wouldn't worry about referring to various operating systems, @ineuw, since if it's available in them, it's fair game.

I'm a bit confused by the reference to PERMANENT, though. That's one that I hadn't come across before in reference to things that we copy in various ways. If that part is in reference to the data shown in the clipboard programs, I believe that's always CLIPBOARD only. At least it is in Klipper. Neither PRIMARY nor SECONDARY show up there.

A quick way to test is to have two different words to copy, like one and two, for instance. Then select, right-click, and copy one followed by just selecting two without right-clicking or copying it. That puts one onto the CLIPBOARD and two into the PRIMARY selection. You can verify that by opening a text editor and middle-clicking to be given two or right-clicking and pasting to be given one. Now if you look in your clipboard program, chances are that you'll see one, but not two.

[ineuw]

I keep referring to the PRIMARY as PERMANENT, Sorry.

[Elliria]

No worries. That's what I figured.

[josephj11]

@Elliria Actually, klipper has an option to also honor selections and add them to the clipboard history. I turned it off on my system (it's probably off by default) because it's not something I want. It's called Ignore selection.

[Elliria]

Ah, it does, indeed. Interesting. Thanks. It was disabled in my settings, too. I've since enabled it and am liking it so far. I suppose I'll change my mind if it makes the Klipper icon appear in the tray too often.

[josephj11]

My clipboard history is almost never empty, so the icon is just about always there.

[josephj11]

When I use my clipboard, I often copy something into it and then select something else I want to replace with what's in the clipboard. That won't work with selections enabled because the selection immediately becomes the top of history and that makes me have to manually open that history and select the next entry down - or worse if I have selected more than once before I'm ready to paste.

[Elliria]

My clipboard is usually also there, but I tend to get rid of it when I notice it or when I don't want its history to possibly interfere with what I'm doing.

I see what you mean about the selection. I enabled mine and tried it that way, but didn't like it for the same reason, so it's on Ignore selection again.

[ineuw]

The discussion on clipboard behavior is such a crucial topic for Autokey that I want to collect all discussions. How to do that, would be best if I ask in the Github forum.

Everyone has important comments about the subject and I want to organize them by date and categorize them. It's important for me to understand how users utilize Autokey, and in what environment. I haven't noticed any discussions about autokey-gtk, unless it was in issues. I only understand Linux Mint Cinnamon well, and comfortable with Kubuntu in the context of Autokey and browsers. I installed Brave and I am impressed at it's simplicity for the new user. I haven't had a chance to test it with Autokey and my Wikisource editing.

[Elliria]

Agreed. One way in which a program can run into trouble, though, is if it assumes the CLIPBOARD or PRIMARY or SECONDARY is empty because it hasn't contributed to it yet. It would be perfectly reasonable for it to make such an assumption if it could know that it would always be run in an environment that doesn't have a clipboard-managing program running on it. Alas, many of us do use such programs, so programs or scripts that assume there's no initial data may fall over when there is.

I've run into such scenarios a couple of times with AutoKey and non-AutoKey scripts and had to solve it by starting those scripts by clearing the data if it exists or, for a more hard-core (but potentially more wasteful) approach, clearing it whether it exists or not.

[josephj11]

@ineuw has been dealing with this forever and has posted about it many times.

To my mind, this is very similar to many other programming problems that result from not assuring that "assumed" initial conditions are in fact valid. That's why many languages fail when an undefined variable is referenced and some even include an assert statement that should never fail. Programmers use it anyway because it catches algorithm design flaws and enviromental changes before they can propagate to other other errors which can be hard to trace back to this initial cause.

The computer system I learned to program on had a command (preset=trap) that you could select. It set all unused memory to a particular (hardware dependent) value that would break almost anything that tried to use it. I used it frequently to catch problems in my code.

IMHO, the only reasonable way to address such problems is to promote "good practices". Many fields have these and that's for a reason.

[Elliria]

True. Since we can't control all the other programs out there, our main weapon against this will probably be to let users know that if they need the clipboard to be empty for their script to work, they'll want to check its state and empty it if it's full at the beginning of their script.

[ineuw]

I am following these conversations intently because I want to help on a number of "Issues", but can't because the "Issue" Form is missing the distro and the version number questions. Some users include it in their post, but it should be asked because without it, is more difficult to provide useful help.

[josephj11]

I am following these conversations intently because I want to help on a number of "Issues", but can't because the "Issue" Form is missing the distro and the version number questions. Some users include it in their post, but it should be asked because without it, is more difficult to provide useful help.

Do what we do: Ask the OP. If you're really annoyed at them, refer them to this. :)

[josephj11]

Maybe a generic scripiting advice topic would be useful. This sort of advice applies to everything, not just this particular problem. "Always verify your assumptions."

[Elliria]

The issue report does ask for that information right after it asks for terms that describe the issue. This is what it says in that section:

Should we word it differently? We're always open to suggestions and improvements.

[ineuw]

I would consider it to move it up as part of the primary info. The more I read about the issues, this seems to matter more and more.
Nice arrowhead. :-)

[Elliria]

Thanks on the arrowhead, but I can't take the credit. That was done by the Pinta program, which I adore.

Now on to the possible rearrangement of the issue template. These are its current sections:

AutoKey is a Xorg application and will not function in a Wayland session. Do you use Xorg (X11) or Wayland?
Has this issue already been reported?
Is this a question rather than an issue?
What type of issue is this?
Choose one or more terms that describe this issue:
Other terms that describe this issue if not provided above:
Which Linux distribution did you use?
Which AutoKey GUI did you use?
Which AutoKey version did you use?
How did you install AutoKey?
Can you briefly describe the issue?
Can the issue be reproduced?
What are the steps to reproduce the issue?
What should have happened?
What actually happened?
Do you have screenshots?
Can you provide the output of the AutoKey command?
Anything else?

They sections are roughly broken up into related groupings that could be rearranged. What do you think of this arrangement, in which I moved around sections 2 through 9 and tried to still keep related groupings together?

AutoKey is a Xorg application and will not function in a Wayland session. Do you use Xorg (X11) or Wayland?
Which Linux distribution did you use?
Which AutoKey GUI did you use?
Which AutoKey version did you use?
How did you install AutoKey?
Is this a question rather than an issue?
Has this issue already been reported?
What type of issue is this?
Choose one or more terms that describe this issue:
Other terms that describe this issue if not provided above:
Can you briefly describe the issue?
Can the issue be reproduced?
What are the steps to reproduce the issue?
What should have happened?
What actually happened?
Do you have screenshots?
Can you provide the output of the AutoKey command?
Anything else?

[josephj11]

I'm not firm, but I think I like it better the way it is now.

[ineuw]

@josephj11, what do you have against moving the OS question closer to the top? I suggested it because it was one of the first questions that kept popping into my mind when I looked at the open issues. It certainly is not very important, but I am also following the frequency of updates being installed to correct minor errors. I watched last week the update list file names relating to GTK in both LMC and Ku. They are the same except that the Ku version of the Ayatana panel indicators work, while LMC version of the same doesn't. I live happily with it ever since I discovered Autokey some five years ago.

I stopped posting issues for minor errors and wait for repeat occurrences before reporting them. I keep screenshots of questions, and possible bugs. I've been observing ongoing failures of Cinnamon trying to manage the same GTK Ayatana indicator for Xfce4-notes. The app indicator disappears on a regular basis. :-)

[josephj11]

@ineuw I often don't like change itself. I like stability. In this case it's not terribly important.

The first couple of questions make you consider whether you should be filing a report at all. It's good to get them out of the way before asking about details that won't matter if the issue is invalid to start with. And I'm sure people lose concentration as they go down a list like this. I want to make sure these get answered while we still have their full attention and impatience hasn't taken over.

[josephj11]

@ineuw It's good to write the questions right away, but then let them age a bit before posting them. Sometimes being forced to be clear about a problem (so someone else will understand what you are asking) gets your mind to see a solution. And sometimes your mind keeps working on it in the background and will provide some inspiration a little while later.

[Elliria]

If you're still thinking of rearranging them, one thing I noticed is that some of them group together because of how they relate to one another. As a result, the groups should be kept together, so you may have to move the "friends" of any one that you move.

[ineuw]

Grouping is most important and it should not be disturbed. We should not make a change just for the sake of change.

Since most of my issues are done on Linux Mint, I returned to it to see the differences. I realized what it is. They separated the Issues to Issues and Enhancement requests. Enhancement leads the user back to their Discussions page.

[ineuw]

I also have a question but, before asking, I must visit and get reacquainted with our Help pages.

[Elliria]

This issue is probably more about human nature than it is about the order of the questions. It's natural for us to want to get to the part of an issue report that interests us and to either gloss over or skip the parts that don't. I've done it and I've seen lots of other people do it. In the end, the best we can probably do is what @josephj11 suggested, which is to ask the OP for the missing information. Another possibility is that we could make the environment question required.

By the way, I just took a look at that Linux Mint issue template and I love the STOP! section at the top. We should maybe do something like that with our issue template, @josephj11. That would get the distracting hugeness of the Wayland question out of the beginning of every posted issue report and put it, instead, into introductory text that issue-reporters see first thing.

[josephj11]

@Elliria I like the idea of the "stop" section. But I still want people to assert that they searched and that they're not using Wayland. Then I can be justifiably impatient with them if we find that they answered these questions incorrectly. :) I love helping people, but I really don't want lazy users wasting my time. Just keeping up with all your wonderful efforts lately is hard enough.

[Elliria]

I like the idea of the STOP! section, too. What I'm thinking, for the Wayland issue, is to put the bulk of the Wayland message into it, with something like this, perhaps:

STOP! AutoKey is a Xorg (X11) application and will not function in a Wayland session. Etc...

Then, the issue report could simply ask Do you use Xorg or Wayland? as its first question. That way, when we're reading the emailed issue reports, we're only looking at that short question instead of the whole warning followed by the question. The only one who would see the warning would be the person creating the issue. I really like the idea of that.

We could also put other information into there the way that the Linux Mint team did. For instance, I could easily envision putting the information from the Has this issue already been reported? and the Is this a question rather than an issue? entries into the STOP! section, too, and not having them as questions at all.

Note: We may want to rethink the wording on the Wayland warning since Wayland users report that it functions somewhat, but not fully.

[josephj11]

I like your proposal - especially since issue tooltips currently show only generic info from our "preamble".

I would say something like "will not fullly function" or "is not supported under".

[Elliria]

This is definitely something we'll want to mess around with. I'll do it in my dummy repository first. That way we can see it and use it and know exactly what it will be like for issue-reporters and in email before we ever do it in the AutoKey project.

[ineuw]

@Elliria, I also created a repository some weeks ago to blog conversations of topics of mutual but peripheral interest to Autokey, like high powered air blowers for keyboards, etc. I didn't think that Autokey was the right forum, and using the repository as a discussion platform seems to be acceptable by Github rules. Though it's still private because the lack of the intro, and a full commitment.

[Elliria]

That's an interesting idea. It's a shame we lost the original Gitter. We didn't realize the value of what we had until we lost it and couldn't replace it with something equivalent.