The ë character…

109 views
Skip to first unread message

Johnny Rosenberg

unread,
Jun 6, 2010, 12:32:46 PM6/6/10
to autoke...@googlegroups.com
I have the following short phase:
ct ⇨ Citroën

However this works only once (per session I think). First time I use
it, it types ”Citroën” and after that it types ”Citron” (which by the
way means ”lemon” in Swedish…). Have anyone else seen this?

Thanks.

Christiaan Dekter

unread,
Jun 6, 2010, 7:59:50 PM6/6/10
to autoke...@googlegroups.com
Is that character in the keyboard map you are using?

Johnny Rosenberg

unread,
Jun 7, 2010, 11:28:26 AM6/7/10
to autoke...@googlegroups.com
2010/6/7 Christiaan Dekter <cde...@gmail.com>:

> Is that character in the keyboard map you are using?

Indirectly… I first hit ¨, then e. ¨ is configured as a ”dead” key
(and that's the default behaviour of the standard Swedish layout).

Well, never mind. I just wanted to know if I am the only one who have
this problem. Seems like I am.

Johnny Rosenberg

Chris Dekter

unread,
Jun 23, 2010, 2:29:32 AM6/23/10
to autokey-users
I'm looking at doing a release soon as I have a fix for window titles
in KDE. Can you possibly post a sample phrase that produces the
problem you mentioned? And also, include information on your keyboard
layout so I can duplicate your setup exactly.

Thanks,
Christiaan

On Jun 8, 1:28 am, Johnny Rosenberg <gurus.knu...@gmail.com> wrote:
> 2010/6/7 Christiaan Dekter <cdek...@gmail.com>:

Johnny Rosenberg

unread,
Jun 23, 2010, 11:36:51 AM6/23/10
to autoke...@googlegroups.com
2010/6/23 Chris Dekter <cde...@gmail.com>:

> I'm looking at doing a release soon as I have a fix for window titles
> in KDE. Can you possibly post a sample phrase that produces the
> problem you mentioned? And also, include information on your keyboard
> layout so I can duplicate your setup exactly.
>
> Thanks,
> Christiaan

Well, as you might remember I have my own keyboard layout, but I
tested it with the default Swedish layout and had the same problem. I
also installed Autokey from your PPA on my wife's computer and she
never touched the layout so she has always had the default Swedish
layout. Same problem on her machine. All tested machines has Ubuntu
10.04.

Here's the phrase:

Name: Citroën

Abbreviation: ct

I didn't check or uncheck anything in the abbreviation dialogue, so
”Remove typed abbreviation” is the only checkbox that is checked.

Output phrase: Citroën

This is what happens for us (on both computers):

First time I type ct it's replaced by Citroën. Second time nothing
happens for several seconds until ct is replaced by Citron (which by
the way means lemon in Swedish…). Third time ct is immediately
replaced by Citron. Sometimes Autokey seems to crash, but I am not
sure those crashes are related to the same problem.

To get the original Citroën phrase working again (still only once,
though), I need to cancel Autokey, wait for a while (several seconds)
and then start Autokey.

Hope this helps.

Johnny Rosenberg

Christiaan Dekter

unread,
Jul 5, 2010, 3:31:02 AM7/5/10
to autoke...@googlegroups.com
The next version of AutoKey, which I will be releasing in the next few days, fixes this bug.

Unfortunately, fixing it meant that I had to disable detection of keyboard map changes in AutoKey. So from this version onwards, you will need to restart AutoKey whenever you change keyboard maps. Unfortunately this was unavoidable as there seems to be a bug in the X server where the keymap gets muddled under certain conditions. Not handling keymap changes dynamically works around this bug.

If anyone wants to test the changes, here is a diff that can be applied to /usr/share/pyshared/autokey/interface.py:

Index: interface.py
===================================================================
--- interface.py    (revision 285)
+++ interface.py    (working copy)
@@ -538,15 +538,13 @@
         if self.localDisplay in r:
             for x in range(self.localDisplay.pending_events()):
                 event = self.localDisplay.next_event()
-                if event.type == X.MappingNotify:
-                    self.__updateMapping(event)
-                elif event.type == X.MapNotify:
+                if event.type == X.MapNotify:
                     logger.debug("New window mapped, grabbing hotkeys")
                     try:
                         self.__grabHotkeysForWindow(event.window)
                     except:
                         logging.exception("Window destroyed during hotkey grab")
-       
+
     def _handleKeyPress(self, keyCode):
         self.lock.acquire()

Johnny Rosenberg

unread,
Jul 5, 2010, 11:00:25 AM7/5/10
to autoke...@googlegroups.com
2010/7/5 Christiaan Dekter <cde...@gmail.com>:

> The next version of AutoKey, which I will be releasing in the next few days,
> fixes this bug.
>
> Unfortunately, fixing it meant that I had to disable detection of keyboard
> map changes in AutoKey. So from this version onwards, you will need to
> restart AutoKey whenever you change keyboard maps. Unfortunately this was
> unavoidable as there seems to be a bug in the X server where the keymap gets
> muddled under certain conditions. Not handling keymap changes dynamically
> works around this bug.

Do you know if anyone has filed a bug report about this X server bug?

Johnny Rosenberg

Christiaan Dekter

unread,
Jul 5, 2010, 11:15:08 AM7/5/10
to autoke...@googlegroups.com
 I haven't tried looking for a bug report. It's an extremely obscure part of X so I doubt many applications are using it - hence the existence of the bug. If I have the time I might look into it further and file a bug. I wouldn't hold your breath though, X bugs, especially obscure ones like this take an extremely long time to get fixed.

Johnny Rosenberg

unread,
Jul 6, 2010, 11:57:52 AM7/6/10
to autoke...@googlegroups.com
2010/7/5 Christiaan Dekter <cde...@gmail.com>:

>  I haven't tried looking for a bug report. It's an extremely obscure part of
> X so I doubt many applications are using it - hence the existence of the
> bug. If I have the time I might look into it further and file a bug. I
> wouldn't hold your breath though, X bugs, especially obscure ones like this
> take an extremely long time to get fixed.

Maybe, but it takes even more time if nobody reports it… :)

Johnny Rosenberg

Reply all
Reply to author
Forward
0 new messages