[SOLVED] CL 6.1 on Ubuntu 14.10, loses many keystrokes

[DavidGH]

OK, so nothing that I'm doing different here, except for the keyboard/locale, I don't suppose either of you has a US or UK keyboard available to experiment with?

When you lose keystrokes, are they always the same keys e.g. always q, w, e, r and t but never y, u, i, o, p? Or is it random, with each key sometimes working, sometimes not?

If there is any other test I can perform, I would be glad to help.

Thanks . What happens if you start CodeLite without its plugins? In a terminal, do:
codelite -p

[DavidGH]

Same Ubuntu 14.10 64bit desktop as stock Live ISO in VMware Player does not suffer the issue (always US English language and Italian keyboard).

I'm sorry, but I don't understand that. Do you mean that, if you install CodeLite in a Live ISO guest, it doesn't lose keystrokes?

[piebru57]

Code: Select all

Do you mean that, if you install CodeLite in a Live ISO guest, it doesn't lose keystrokes?

Yes, but I was fooled by the workspace status, in the VM I did not create a workspace so all worked OK.
By creating a workspace, then a project, then editing main.c the issue confirms even in the Live original ISO guest.

So I did this test, hope you can simulate it using the exact same procedure.
1. Start a VM (VMware Player 6.0.4 build-2249910) with the standard Ubuntu 14.10 64bit desktop ISO (md5sum = 08494b448aa5b1de963731c21344f803 ubuntu-14.10-desktop-amd64.iso)
2. Let expire the boot timeout. Once on the desktop click "Try Ubuntu".
3. Set the screen resolution to 1440x900 (Tray menu / System settings / Display), click keep configuration. Don't modify the keyboard layout, here I manually adapt for differences in typing.
4. Open firefox to get the CL61-64 deb address.
5. CTRL+ALT+T to open a shell.
6. $ wget http://repos.codelite.org/ubuntu/pool/u ... _amd64.deb
7. $ sudo dpkg --ignore-depends=codelite -i codelite_6.1-1.utopic_amd64.deb
8. Execute codelite from the Unity dash, confirm GCC.
9. Workspace / New workspace (temp1, OK)
10. Workspace / New project / Console (Simple executable GCC, next, temp2, next, finish)
11. Double click over main.c
12. Insert a line before #include, saying some silly things
13. Issue reproduced, lot of keystrokes lost.
14. Workspace / Close workspace
15. File / New / New empty file
16. Issue not reproduced now.

Hope this can help.
Thank you David.
Piero

[DavidGH]

So I did this test, hope you can simulate it using the exact same procedure.

Not exact, as I already have a (virtualbox) guest utopic. Otherwise it's the same as yours.

Thank you for the detailed instructions. I did exactly the same thing as you, and the keyboard here worked perfectly :/

Is it that certain keys always fail and others never, or is it variable and/or random?

[Alix]

I don't suppose either of you has a US or UK keyboard available to experiment with?

Sorry, I have no other keyboard. But when I tell Ubuntu that my keyboard is an English-US keyboard, the same problem persists (except that the displayed keystrokes correspond to an English-US keyboard, of course).

When you lose keystrokes, are they always the same keys e.g. always q, w, e, r and t but never y, u, i, o, p? Or is it random, with each key sometimes working, sometimes not?

It seems random. It is not always the same key(s) that are dropped, sometimes they are taken, sometimes they are dropped. Also, there seems to be no pattern in the dropping; it is not like every third key would be dropped. Sometimes several keys are dropped consecutively, sometimes several keys appear without any one dropped. Apparently also nothing to do with word boundaries. Also, the frequency with which keys are dropped seems to vary in bursts: when I start typing, most of the keys are displayed, then the number of dropped keys increases, but after a while it drops less keys, then starts dropping more.

What happens if you start CodeLite without its plugins? In a terminal, do:
codelite -p

Starting Codelite without plugins has no influence; the problem persists.

[piebru57]

Code: Select all

Is it that certain keys always fail and others never, or is it variable and/or random?

I confirm Alix behaviour, random keys, random loss.
However, backspace and cancel has always no effect in the Project Settings / Execution / Program arguments (and other similar input fields).
Piero

[piebru57]

Cursor movements are never affected.

[DavidGH]

Good news/bad news. The good news is that I've started to see the typing problem here, and I can certainly reproduce the backspace-in-settings one.

Backspace first: this is a problem between the wxWidgets toolkit (that CodeLite uses) and ubuntu utopic itself. I can make it happen very easily in the appropriate wxWidgets sample; in fact lots of backspaces can make the sample crash. This doesn't happen in ubuntu trusty, nor in debian or fedora. So this issue isn't really a CodeLite one, and I don't have a solution for you. If it's fixed in ubuntu itself CodeLite should work normally; if it gets fixed in wxWidgets, it will probably be possible to backport the fix into a replacement CodeLite package.

The ordinary typing problem may be a mild form of the same thing, but I can't make it happen in a wxWidgets sample; and it's interesting that it only happens inside a workspace. I'm still looking into this.

At least we now know that it's not a keyboard/locale issue.

[piebru57]

Not affected: CTRL+F (find) input box during edit of a source file even within an open workspace.

[DavidGH]

Some progress. The CodeLite package is built against the official wx3.0.1. Eran noticed that the latest wx release, 3.0.2, doesn't have the many-keystrokes issue, though the backspace one is still present. So I've rebuilt CodeLite against an unofficial wx3.0.2 package

I've temporarily uploaded a CodeLite deb and a wxCrafter deb and I'd be grateful if you'd test them (install using dpkg) to check they work for you, before I update the repo. Note that, if you use wxCrafter, you must update that too, or else remove the current package, otherwise CodeLite will crash on starting.