Keyboard Input Discussion
Email: <svu AT SPAMFREE gnome DOT org>
Email: <simos AT SPAMFREE gnome DOT org>
Here we discuss how input methods can work together with the graphical environment so that the end-user has a seamless experience.
There was a meeting on Friday, 07.07.2006, at 19:00 GMT, on Freenode, channel #xkbconfig. See below for the IRC log.
SergeyUdaltsov (svu) organised the meeting to discuss rather technical issues about keyboard layout support in GNOME (eventually the discussion was neutral on the graphical environment).
The initial agenda included:
GSwitchIt API as GNOME-oriented keyboard services. Including GTK widget, gconf configuration, DBUS server etc.
Whether gswitchit should go to separate project or become a real (non-virtual) part of some existing one.
IRC Log #1 - 2006.07.07 19:00 GMT Friday, Freenode, #xkbconfig
**** BEGIN LOGGING AT Fri Jul 7 19:59:35 2006
Jul 07 20:00:22 <simosx> Ok, the time is 1900 GMT, 2006.07.07. Let the discussion begin.
Jul 07 20:00:23 <svu> will we go ahead?
Jul 07 20:01:00 <simosx> yes
Jul 07 20:01:10 <juhp> good morning
Jul 07 20:01:20 <svu> juhp, hi
Jul 07 20:01:35 <svu> so, first let's talk about API
Jul 07 20:01:58 <svu> currently it sucks
Jul 07 20:01:59 * menthos (n=menthos@c83-249-198-235.bredband.comhem.se) has joined #xkbconfig
Jul 07 20:02:27 <svu> gswitchit API was ... "designed" as some hackish API for two purposes: configuration applet
and indicator
Jul 07 20:02:39 <svu> gnome-keyboard-properties and gnome-keyboard-indicator
Jul 07 20:03:07 <svu> at some point, part of g-k-i was moved to gnome-settings-daemon. But this did not change API really
Jul 07 20:03:28 <svu> the main functions are:
Jul 07 20:03:32 <svu> 1. storing configuration in GConf
Jul 07 20:03:40 <svu> 2. dealing with pluginis
Jul 07 20:04:23 <svu> Now, the gtk widget was added
Jul 07 20:04:35 <svu> also DBUS server for configuration
Jul 07 20:04:43 <svu> so, it is pretty much ad-hoc thing
Jul 07 20:04:51 <svu> "everything shared about keyboard"
Jul 07 20:05:15 <simosx> Are all these under http://cvs.gnome.org/viewcvs/gnome-applets/gswitchit/ ?
Jul 07 20:05:36 <svu> simosx, no, the module libgsiwthit in CVS
Jul 07 20:05:42 * Insount_away (n=Insount@unaffiliated/insount) has joined #xkbconfig
Jul 07 20:05:44 <svu> there is also another virtual module which might be a candidate for merge - libkbdraw
Jul 07 20:06:18 <behdad> what's the plugin thing there for in the first place?
Jul 07 20:06:34 * juhp was wondering too
Jul 07 20:06:38 <svu> behdad, good question. there are gswitchit_plugins on sf.net
Jul 07 20:06:47 * warren has questions about SCIM implications of this, but will wait until later to ask.
Jul 07 20:07:00 <svu> warren, yes, I remember
Jul 07 20:07:01 <behdad> svu: what kind of functionalities do they provid?
Jul 07 20:07:13 <svu> behdad, some extra "bounties", like:
Jul 07 20:07:17 <svu> 1. flags (hehe)
Jul 07 20:07:26 <svu> 2. custom color highlighting
Jul 07 20:07:41 <svu> 3. some bits of cairo animation
Jul 07 20:07:47 <svu> any crap actually
Jul 07 20:07:55 <svu> (except for flags)
Jul 07 20:08:17 * AlinuxOS thinks that removing flags (gswitchit_plugins) from central application was bad idea.
Jul 07 20:08:27 <svu> flags are actually supported by the indicator inself, it is matter of downloading them
and turning one gconf value on
Jul 07 20:08:29 <behdad> nice touch, but we really don't need it in the context menu
Jul 07 20:08:46 <behdad> yeah, flags were really useful
Jul 07 20:08:53 <svu> behdad, where then?
Jul 07 20:08:57 <behdad> although they are controversial in a minorities of states
Jul 07 20:09:05 <behdad> svu: just load whatever plugin there is
Jul 07 20:09:10 <juhp> nod
Jul 07 20:09:26 <svu> actually, I got sick explaining people where to put flags and where to modify gconf - so now
I just say "download plugins and be happy"
Jul 07 20:09:38 * TiCPU (n=TiCpu@216.218.53.118) has joined #xkbconfig
Jul 07 20:09:56 <Amaranth> the problem with flags is china, no?
Jul 07 20:09:59 <svu> behdad, well, the plugins are loaded all at once - and people would not want them ALL enabled
at the same time
Jul 07 20:10:06 * Insount_away is now known as Insount
Jul 07 20:10:51 <behdad> Amaranth: not china only
Jul 07 20:11:00 <behdad> Amaranth: all the emerging/desolving states
Jul 07 20:11:26 * svu enjoys the flag-related discussions every time:)
Jul 07 20:11:39 <Amaranth> hehe, they are fun to watch, no doubt
Jul 07 20:11:44 * svu has changed the topic to: The meeting is on. Please no political discussions here:)
Jul 07 20:12:01 <svu> so, basically:
Jul 07 20:12:05 <svu> 1. plugins are useful
Jul 07 20:12:18 <svu> 2. people would need to turn them on/off as they like
Jul 07 20:12:32 <svu> that is why plugin management dialog is in the popup menu
Jul 07 20:12:43 <Amaranth> 3. plugins in a keyboard manager are just weird
Jul 07 20:12:58 <Amaranth> i mean, behind the scenes, sure
Jul 07 20:13:05 <Amaranth> but having a UI for it is weird
Jul 07 20:13:18 <simosx> would it be better to "hide" the plugins option deep inside the the keyboard preferences?
Jul 07 20:13:19 <behdad> svu: just call it preferences?
Jul 07 20:13:45 <simosx> in usability terms, there are no plugins available and the general user would have
to compile and install in order to populate the list.
Jul 07 20:13:59 <svu> behdad, well, I can call them "preferences". though the only thing they would do it
enable/disable and configure plugins:)
Jul 07 20:14:11 <juhp> theming?
Jul 07 20:14:19 <behdad> heh
Jul 07 20:14:46 <behdad> ok, the plugin discussion is really a side point. lets get to the main stuff :)
Jul 07 20:14:51 <svu> well, what i could do is leave the binary in place and remove the menu item
Jul 07 20:15:02 <svu> so people would run the plugin manager from the command line
Jul 07 20:15:27 <svu> ok, let's back to the main point
Jul 07 20:15:31 <svu> the API
Jul 07 20:16:07 <svu> http://cvs.gnome.org/viewcvs/libgswitchit/
Jul 07 20:16:15 <svu> first part
Jul 07 20:16:26 <svu> http://cvs.gnome.org/viewcvs/libgswitchit/gswitchit-config.h?rev=1.1&view=markup
Jul 07 20:17:11 <svu> most of the stuff is really about gconf
Jul 07 20:17:34 <svu> second, gtk widget
Jul 07 20:17:51 <svu> http://cvs.gnome.org/viewcvs/libgswitchit/gnome-kbd-indicator.h?rev=1.3&view=markup
Jul 07 20:18:29 <warren> Sorry, but some of us are missing a LOT of context here. You're talking about
implementation details, when some of us are wondering "What is this?"
Jul 07 20:18:41 <warren> What is the goal of this entire framework?
Jul 07 20:18:56 <warren> What does it actually do?
Jul 07 20:19:58 <svu> warren, as I say - there was no real "design stage" here. The _initial_ purpose of the code
is to keep the keyboard-related settings in gconf (settings for both g-s-d and g-i).
Jul 07 20:20:13 <svu> s/is/was/
Jul 07 20:20:33 <svu> then the scope was blurred
Jul 07 20:20:39 <warren> These keyboard related settings, these are exclusively dealing with different keyboard
mappings that are around the world?
Jul 07 20:20:55 <warren> Thus the need for switching between these mappings?
Jul 07 20:21:11 <svu> warren, I am not sure I understand the question...
Jul 07 20:21:19 <svu> yes we keep the keyboard configuration
Jul 07 20:21:25 <svu> model, layout, options
Jul 07 20:21:29 <svu> that's part of the API
Jul 07 20:21:32 <warren> What does it currently do today
Jul 07 20:21:47 <svu> there are two group of settings:
Jul 07 20:22:17 <svu> 1. XKB settings. model/layouts/options - they are activated in g-s-d but used in indicator
and in the capplet
Jul 07 20:22:31 <svu> 2. Indicator settings - "how to display"
Jul 07 20:22:37 <warren> how to display what?
Jul 07 20:23:01 <svu> how to show the current configuration:
Jul 07 20:23:16 <svu> 1. whether to show flags (as I said, the function is actually in the indicator)
Jul 07 20:23:20 <warren> displaying status?
Jul 07 20:23:27 <warren> oh ok
Jul 07 20:23:28 <svu> 2. "secondary" groups (hidden gconf settings)
Jul 07 20:23:50 <svu> that is GSwitchItAppletConfig
Jul 07 20:25:04 <courtjester> As I understand it, gswitchit deals strictly with XKB. It does not support any other
input methods...
Jul 07 20:25:15 <warren> Here's my concern in hearing all this. I'm hearing implementation details like "having
everything in gconf" and everything being GNOME specific. Meanwhile we're here also trying
to explore merging the overlapping parts of SCIM's scope with this scope. SCIM however
must support GNOME, KDE and legacy XIM, thus this cannot be an exclusive relationship
with GNOME.
Jul 07 20:25:40 <warren> So I guess the question is, what are the implications of this API, and can this done in
a way that is consistent with the non-GNOME usage of SCIM.
Jul 07 20:25:49 <courtjester> I agree with Warren. It would be better to have some sort of XKB module in SCIM.
Jul 07 20:26:15 <juhp> hmm
Jul 07 20:26:21 <svu> courtjester, the answer is: below libgswitchit, there is ... relatively-well designed libxklavier.
Which can have different backends. Now it supports XKB and XMODMAP.
Jul 07 20:26:59 <svu> I could consider adding support for SCIM to libxklavier (or would prefer to help anyone to do it
- since I am not very familiar with SCIM)
Jul 07 20:26:59 <warren> We need a greater understanding of the current underlying architecture.
Jul 07 20:27:36 <warren> and how these peices currently interface between legacy XIM, qtimm and gtkimm
Jul 07 20:27:42 <warren> pieces*
Jul 07 20:28:13 <courtjester> It seems to me that gswitchit is providing similar functionality to scim-panel-gtk...
Jul 07 20:28:17 <juhp> svu: so if say scim supported libxklavier to might be able to do what gswitchit does now
for example?
Jul 07 20:28:39 <svu> juhp, what could be possible is:
Jul 07 20:28:39 <juhp> to->it
Jul 07 20:28:53 <warren> gswitchit is the UI to select a different keyboard map?
Jul 07 20:29:03 <svu> listing SCIM methods in the keyboard-configuration dialog
Jul 07 20:29:17 <warren> SCIM does seem to have options within it for choosing different keyboard maps...
Jul 07 20:29:32 <svu> warren, no, actually there is no gswitchit as such anymore. it was a codename of the independent
project which I started outside of gnome
Jul 07 20:29:57 <svu> then it was merged to gnome and split to g-s-d/g-k-p/g-k-i
Jul 07 20:30:07 <svu> (and shared part turned to libgswitchit)
Jul 07 20:30:07 <warren> ah, ok
Jul 07 20:30:37 <juhp> warren: well there is some scim config related to kbd layour, but currently it can switch
xkb layouts afaik
Jul 07 20:31:18 <svu> the problem IMHO is that SCIM and XKB are orthogonal frameworks AFAIK
Jul 07 20:31:21 <juhp> svu: sorry "g-s-d" and "g-k-i" are?
Jul 07 20:31:30 <warren> svu, nod
Jul 07 20:31:34 <svu> juhp, gnome-settings-daemon/gnome-keyboard-indicator
Jul 07 20:31:37 <liucougar_home> juhp, asaik, scim implements its own keyboard layout support
Jul 07 20:31:43 <liucougar_home> not related to X at all
Jul 07 20:31:49 <juhp> liucougar_home: right
Jul 07 20:32:18 <liucougar_home> (SCIM does not have any hard dependence on X)
Jul 07 20:32:41 <svu> liucougar_home, from X architecture POV, would you put SCIM on the server or client side?
Jul 07 20:34:05 <warren> svu, client
Jul 07 20:34:13 <warren> (right?)
Jul 07 20:34:19 <svu> just in case, libxklavier API: http://xlibs.freedesktop.org/xkbdesc/doc/. Libxklavier is
generic desktop-agnostic keyboard configuration and status monitoring library (the only G*
thing it is using is glib)
Jul 07 20:34:55 <svu> warren, so, if I have OpenOffice window on my machine, but actually it runs on yours -
where SCIM would be?
Jul 07 20:34:56 <warren> is glib emotionally upsetting to KDE these days? =)
Jul 07 20:35:38 <juhp> svu: normally scim runs on the desktop
Jul 07 20:36:01 <simosx> warren, (on KDE/glib): http://advogato.org/person/svu/diary.html?start=48
Jul 07 20:36:19 <courtjester> scim can run anywhere and provides input method services via sockets.
Jul 07 20:36:44 <juhp> simosx: cool
Jul 07 20:36:45 <warren> Through multiple interfaces, either gtkimm, qtimm or XIM currently.
Jul 07 20:37:09 <svu> juhp, ok, good. So it will be on my machine. But how would OOo application (process)
on remote machine would know about available on my machine layouts?
Jul 07 20:37:21 * svu reminds everybody that X is network-transparent
Jul 07 20:38:12 <svu> dalekiy_obriy, " is glib emotionally upsetting to KDE these days? =)" (c)
Jul 07 20:38:58 <warren> svu, generally the remote app scenario is less and less important these days,
and it doesn't work too nicely, partly because of the architecture, partly because
in reality few people actually need it.
Jul 07 20:39:04 <liucougar_home> svu, scim can both act as server, client
Jul 07 20:39:34 <juhp> svu: frankly I've never used scim over X transport, but it should be possible I suppose
Jul 07 20:40:01 <svu> warren, ghm. I was already once beaten for breaking network transparency (because XKB suxx
in some aspects). Now there is a plot to improve XKB. So it still matters. And I do not think
we can build reasonable architecture ignoring it?
Jul 07 20:40:21 <svu> liucougar_home, so, there is some protocol which scim is using for information xchange?
Jul 07 20:40:37 <liucougar_home> svu, socket based protocol
Jul 07 20:40:53 <warren> svu, it works in some ways today, it isn't broken intentionally, just the architecture
probably can't handle a mixed setup.
Jul 07 20:40:55 <liucougar_home> and scim is network transparent as well (well, in most cases)
Jul 07 20:41:02 * warren tests that...
Jul 07 20:41:31 <courtjester> from SCIM_TRANS_COMMANDS_H
Jul 07 20:41:38 <svu> liucougar_home, interesting! so running process would actually be able to manage scim
configuration on X server, wouldnt it?
Jul 07 20:41:44 <courtjester> * There are mainly four major protocols used in the communications among each part of SCIM:
Jul 07 20:41:44 <courtjester> * - between SocketFrontEnd and SocketIMEngine (SocketFrontEnd is server)
Jul 07 20:41:44 <courtjester> * - between SocketFrontEnd and SocketConfig (SocketFrontEnd is server)
Jul 07 20:41:45 <courtjester> * - between Panel and FrontEnds (eg. X11 FrontEnd, Gtk IMModule and QT IMModule. Panel
is server)
Jul 07 20:41:45 <courtjester> * - between Panel and Helper (Panel is server).
Jul 07 20:42:07 <courtjester> Panel is like the Keyboard indicator.
Jul 07 20:43:26 <svu> so, if things are that good, libxklavier could be hacked to add SCM support - so indicator
would transparently indicate both XKB and SCIM layouts, and in the configuration dialog,
people would be able to choose both XKB and SCIM layouts?
Jul 07 20:44:13 <svu> is there a way to ask over network "please provide me with the list of available layouts"?
Jul 07 20:44:33 * svu apologises for next-to-nothing knowledge about SCIM
Jul 07 20:44:44 <warren> It isn't "layouts"
Jul 07 20:45:03 <svu> well, "methods"
Jul 07 20:45:12 <courtjester> Right now, there are no commands in the SCIM protocol to enumerate SCIM keyboards,
nor to switch between SCIM keyboards from any apps except the panel (skim or gtk panel)
Jul 07 20:45:15 <warren> svu, SCIM is generally converting keyboard input into some other character set
using either tables or engines.
Jul 07 20:45:42 <svu> warren, yes, I tried this once. But there is a state to indicate, isn't it?
Jul 07 20:45:59 <warren> hm
Jul 07 20:46:21 <warren> i just tested remote X apps running as a different user on my X desktop
Jul 07 20:46:51 <warren> SCIM works, but it is running multiple copies and it is a little confused.
Jul 07 20:47:21 <svu> hehe
Jul 07 20:47:29 <warren> state as in current language?
Jul 07 20:47:36 <juhp> courtjester: I think it should be possible
Jul 07 20:47:46 <svu> warren, well, "current method"?
Jul 07 20:48:10 <warren> I'm not even sure if these things have unique identifiers.
Jul 07 20:48:26 <courtjester> juhp: It will be possible in the next release of SCIM. This is something I have
asked James to add.
Jul 07 20:48:29 <svu> ghm...
Jul 07 20:49:30 <svu> lame question again - the methods are switched using the keyboard, aren't they? if so,
how do you specify shortcuts?
Jul 07 20:49:40 <liucougar_home> with little efforts, skim can expose all scim actions in dcop
Jul 07 20:49:45 <svu> I am asking - should this all be in the g-k-p?
Jul 07 20:50:10 <courtjester> Right now, you can only communicate with SCIM to enumerate and switch between
input method if you are a panel, either skim or scim-panel-gtk.
Jul 07 20:51:27 * soumyadip (n=soumyadi@59.93.240.28) has joined #xkbconfig
Jul 07 20:51:38 <courtjester> svu: g-k-p is still tied to gnome? SCIM really needs to be framework agnostic.
Jul 07 20:51:44 <liucougar_home> another way around to the issue, is for scim to provide an imengine
to make use of libxklavier
Jul 07 20:52:12 <courtjester> luicougar: Yes, this is what I proposed earlier.
Jul 07 20:52:18 <liucougar_home> svu, it is possible to use mouse as well to select a method
Jul 07 20:52:24 <svu> just as a reminder of the protocol and agenda - we are talking about the low-level library
(libxklavier) which could (try) make the difference between XKB and SCIM as transparent as possible
Jul 07 20:52:38 <juhp> courtjester: it would be great to be able to integrate scim more tightly on the gnome/kde
desktop tops though
Jul 07 20:52:50 <svu> courtjester, ok, s/g-k-p/desktop-specific UI/
Jul 07 20:53:03 <warren> What about legacy XIM?
Jul 07 20:53:41 <svu> what would be great (if it is achievable) is to have all configuration and state monitoring in
libxklavier
Jul 07 20:53:47 <svu> for XIM/SCIM/XKB/...
Jul 07 20:54:00 <svu> so every desktop could use it
Jul 07 20:54:15 <liucougar_home> doesn't libxklavier depend on glib?
Jul 07 20:54:27 <courtjester> warren: XIM does not really support input method switch. Thus the need for
a framework like SCIM.
Jul 07 20:54:39 <svu> liucougar_home, it does. But even KDE seems to be ok with it AFAIK
Jul 07 20:54:52 <warren> courtjester, SCIM does bridge with XIM though
Jul 07 20:55:04 <liucougar_home> svu, does kde make use of libxklavier in some components?
Jul 07 20:55:46 <svu> liucougar_home, that's a plot for KDE4. You can ask dalekiy_obriy - he is "Mr. kxkb"
Jul 07 20:55:46 <courtjester> Yes. SCIM can communicate with X (and X apps) via XIM, but you cannot really
switch between multiple XIM input methods.
Jul 07 20:57:00 <liucougar_home> courtjester, XIM is designed to be a server, and only one server can be
used at a given time, but one server can support multiple input methods,
as SCIM does
Jul 07 20:57:25 <svu> so, first action for someone knowing SCIM - do a review of libxklavier API - where
it is good as some abstraction layer or not.
Jul 07 20:57:35 <svu> s/where/whether/
Jul 07 20:57:36 <courtjester> luicougar: Yes. I understand that about XIM.
Jul 07 20:57:37 <juhp> but in some sense xkb is lower level than IM, I mean scim basically relies on xkb
to set the underlying kbd layout
Jul 07 20:57:48 <liucougar_home> dalekiy_obriy, are you migrating kxkb to libxklavier?
Jul 07 20:58:23 <liucougar_home> juhp, does SCIM use xkb?
Jul 07 20:58:45 <juhp> liucougar_home: xkb affects scim, no :)
Jul 07 20:59:02 <svu> lads, who could take an hour or two and look at libxklavier API?
Jul 07 21:00:43 <liucougar_home> juhp, yeah, it definitely affects
Jul 07 21:01:05 <svu> what we need is clear understanding
Jul 07 21:01:12 <juhp> liucougar_home: right, sorry that is all I mean
Jul 07 21:01:15 <juhp> t
Jul 07 21:01:21 <courtjester> juhp is correct...xkb is part of the input chain.
Jul 07 21:01:32 <svu> whether various ways of dealing with keyboard (mapping input to characters) can be abstracted or not
Jul 07 21:01:38 <courtjester> and scim is further up the chain.
Jul 07 21:01:39 <dalekiy_obriy> sorry - was off - yes, in KDE4 kxkb will be using libxklavier
Jul 07 21:01:48 <dalekiy_obriy> ...at least if found on compile stage :)
Jul 07 21:01:50 <svu> dalekiy_obriy, thankgs:)
Jul 07 21:02:31 <liucougar_home> dalekiy_obriy, so you have another implementation if libxklavier
is not found, right?
Jul 07 21:02:36 <dalekiy_obriy> in the beginning it'll be configuration parsing but hopefully later there'll
be more common things
Jul 07 21:02:45 <juhp> svu: probably some of the scim developers will now be interested to examine libxklavier
Jul 07 21:02:47 <svu> liucougar_home, does SCIM deal with character input only - or also affects functional keys
of any kind?
Jul 07 21:03:02 <svu> juhp, I would really appreciated it.
Jul 07 21:03:11 <dalekiy_obriy> yes, if libxklavier not found I am using my "old" engine by talking to libxkbfile
Jul 07 21:03:24 <juhp> svu: it can affect any key really
Jul 07 21:03:32 <liucougar_home> svu, you can define any keys as shortcuts in scim
Jul 07 21:03:54 <warren> ALT-F4 is "commit" on my desktop. =)
Jul 07 21:04:19 <svu> liucougar_home, juhp, thanks. But I mean - can SCIM define things like "This key should
be used as PgUp"?
Jul 07 21:04:36 <juhp> and so can IM engines
Jul 07 21:04:57 <juhp> svu: ah, that is xkb domain, no?
Jul 07 21:05:09 <liucougar_home> svu, that's possible with SCIM, if you want
Jul 07 21:05:15 <svu> juhp, yes, it is. I am asking on how the XKB and SCIM domains overlap
Jul 07 21:05:32 <juhp> svu: ok, good point
Jul 07 21:05:35 <warren> liucougar_home, though is anyone actually using it that way? I've never seen it.
Jul 07 21:05:58 <liucougar_home> warren, I don't think so
Jul 07 21:06:21 <courtjester> xkb and scim are like two filters...keyboard scan codes pass through xkb and
then the output of xkb is sent to scim.
Jul 07 21:06:23 <svu> liucougar_home, well, in XKB a mapping would be just incomplete without this. Because
if XKB does not define some key - the key is simply not working
Jul 07 21:06:35 <courtjester> the output of scim is then passed onto the application.
Jul 07 21:06:40 <warren> The practical way to use SCIM is for it to take over certain keys while it
is 'active', which is used to control what characters are chosen for input.
Jul 07 21:06:46 * svu now sees why SCIM is considered as higher level
Jul 07 21:07:03 <juhp> :)
Jul 07 21:07:19 <warren> svu, what distro do you use? Perhaps we should set you up with a full demo system.
Jul 07 21:07:25 <warren> easiest to explain things by trying it
Jul 07 21:07:26 <svu> warren, dapper
Jul 07 21:07:32 <warren> hm
Jul 07 21:07:46 * chusslove just aptted skim and can't figure out what to do
Jul 07 21:08:20 <warren> the "How to turn it on by default" question is different between distributions,
so I don't know that on Ubuntu.
Jul 07 21:08:44 <juhp> chusslove: try #scim :)
Jul 07 21:08:55 <courtjester> the SCIM wiki has good information for different distros
Jul 07 21:08:59 <simosx> Ubuntu: System/Prefeferences/SCIM Input Method Setup
Jul 07 21:09:10 <dalekiy_obriy> sorry for stupid question: in gaim I have "Input methods" on right click -
is it somehow SCIM?
Jul 07 21:09:27 <juhp> dalekiy_obriy: that is gtk
Jul 07 21:09:29 <courtjester> dalekiy_obriy: yes.
Jul 07 21:09:31 <warren> juhp, sigh, we gotta convince notting to put im-chooser into the Preferences rather
than an "optional" thing.
Jul 07 21:09:36 <juhp> dalekiy_obriy: scim should be listed there
Jul 07 21:09:49 <courtjester> Then ctrl-space enables SCIM (normally).
Jul 07 21:09:51 <svu> simosx, thanks
Jul 07 21:09:51 <simosx> Ubuntu: you then, either need to restart, or simply right-click in a text box
and change the input method to SCIM. It brings up the SCIM Panel.
Jul 07 21:10:03 * Insount (n=Insount@unaffiliated/insount) has left #xkbconfig ("Quitting")
Jul 07 21:10:12 <warren> simosx, Ubuntu doesn't hide the Input Method context menu?
Jul 07 21:10:23 <warren> Fedora disabled that context menu a while ago.
Jul 07 21:10:31 <juhp> we're getting OT....
Jul 07 21:10:33 <courtjester> warren: nope.
Jul 07 21:10:34 <dalekiy_obriy> juhp, thanks
Jul 07 21:10:35 <warren> because it is utterly useless unles you're debugging
Jul 07 21:11:18 <simosx> warren, no. You can switch with Ctrl-Space. In general it looks messy if you are not used
to it.
Jul 07 21:11:26 <juhp> svu: though it would be cool if you had a chance to try out scim :)
Jul 07 21:11:47 <svu> juhp, just checked it. it "works for me"
Jul 07 21:11:54 <juhp> svu: great
Jul 07 21:12:13 <svu> though I am amused that someone is using IM for Russian input:)
Jul 07 21:12:33 <warren> scan codes -> XKB -> something -> SCIM -> input characters
Jul 07 21:13:00 <juhp> svu: well mixing xkb switching and scim is messy....
Jul 07 21:13:03 <warren> scan codes -> XKB -> something -> SCIM -> gtkimm or qtimm or XIM -> input characters
in an application
Jul 07 21:13:31 <juhp> currently anyway ;)
Jul 07 21:13:42 <juhp> which is why we're here :-)
Jul 07 21:13:50 <svu> juhp, I see... it is really irritating that there are two independent ways to do the same thing...
Jul 07 21:13:56 <liucougar_home> I think it should be scan codes -> XKB -> something -> gtkimm or qtimm or
XIM -> SCIM -> input characters
Jul 07 21:13:58 <juhp> yes
Jul 07 21:15:23 <svu> ghm... just a crazy thought if SCIM is so good. may be it would make sence to convert all
XKB layouts to SCIM and just just SCIM....
Jul 07 21:15:31 <svu> :)
Jul 07 21:15:35 <juhp> svu: I know some IM people who in the past at least have expressed an interest to get
rid of xkb... I'm not one of those thogh
Jul 07 21:15:58 * svu is not excited about XKB at all
Jul 07 21:16:05 <juhp> ok :)
Jul 07 21:16:16 <warren> we could just force the world to use the U.S. keyboard
Jul 07 21:16:18 <liucougar_home> svu, in principle, SCIM can do that
Jul 07 21:16:35 <courtjester> I think XKB needs to be there to handle different physical keyboard layouts.
SCIM does not handle that at all.
Jul 07 21:16:46 <juhp> svu: well that is also one approach - though currently some people would probably consider
scim a bit heavy still for that
Jul 07 21:16:50 <svu> warren, exactly, from XKB POV it will all be 'us'. But from SCIM POV...
Jul 07 21:17:18 <svu> courtjester, good point. Phisical layouts - through XKB. national - through SCIM
Jul 07 21:17:45 * svu is afraid to think how much his spare time it could take
Jul 07 21:17:52 <warren> juhp, mmmm when scim crashes, you can't type AT ALL =)
Jul 07 21:18:09 <juhp> warren: :P
Jul 07 21:18:09 <svu> warren, even ASCII ???
Jul 07 21:18:28 <warren> if you wanted scim to handle scan codes
Jul 07 21:18:32 <juhp> svu: warren means if we get rid of xkb...
Jul 07 21:18:36 <liucougar_home> warren, scim does not have habit of crashing ;)
Jul 07 21:18:46 <warren> liucougar_home, Fedora is special
Jul 07 21:18:58 <liucougar_home> warren, heh
Jul 07 21:19:08 <svu> juhp, well, on the low level there will be XKB with 'us' layout. As simple as that :)
Jul 07 21:19:27 <warren> to clarify
Jul 07 21:19:46 <juhp> svu: okay, then that would still work, but anyway
Jul 07 21:19:47 <warren> does SCIM actually implement a XKB-replacement in its keyboard layout chooser,
or does it only switch XKB?
Jul 07 21:20:07 <liucougar_home> warren, scim has its own
Jul 07 21:20:14 <warren> ok...
Jul 07 21:20:35 <svu> we should merge!:)
Jul 07 21:20:36 <warren> is XKB is a standard thing across all the Unixes, not just us?
Jul 07 21:20:43 <courtjester> luicougar: how do you mean? I thought SCIM switched XKB.
Jul 07 21:20:43 <liucougar_home> but I do not think it maps any none-ascii keys atm
Jul 07 21:20:58 <svu> warren, standard across most modern X implementations
Jul 07 21:21:14 <liucougar_home> courtjester, no, it doesn't
Jul 07 21:21:18 <svu> liucougar_home, does SCIM works with keycodes or keysyms (as input)?
Jul 07 21:21:36 <courtjester> svu: keysyms
Jul 07 21:21:36 * liucougar_home name is liucougar, not luicougar
Jul 07 21:21:57 <courtjester> sorry:(
Jul 07 21:22:07 <warren> I guess the next question is, does SCIM work with XKB only and not its own implementation?
Jul 07 21:22:24 <warren> That's the non-orthogonal part.
Jul 07 21:22:37 <liucougar_home> svu, that depends on different im module
Jul 07 21:23:10 <liucougar_home> svu, in XIM/gtk im/qt imm, it uses keycode (IIRC)
Jul 07 21:23:30 <liucougar_home> oops, I mean keysym
Jul 07 21:23:32 <dalekiy_obriy> sorry, another stupid question, taking libxklavier supports xmodmap now how SCIM
and modmap will relate in hierarchy?
Jul 07 21:23:34 <svu> liucougar_home, courtjester: please could you agree on this?:)
Jul 07 21:23:36 <svu> ok, I see:)
Jul 07 21:24:05 <liucougar_home> courtjester, it's ok
Jul 07 21:25:01 <svu> so it is using keysyms. So if someone would, say, use not 'us' but 'fr' XKB layout -
the SCIM layout would change correspondingly?
Jul 07 21:25:38 <svu> dalekiy_obriy, I would say, XKB and xmodmap are on the same level, SCIM is above them -
but does not cover entirely
Jul 07 21:26:00 * svu feels he would need a board to draw
Jul 07 21:26:13 <juhp> svu: if one sets "setxkbmap fr" then scim will see a fr layout
Jul 07 21:26:44 <courtjester> I thought that xmodmap was just a way of modifying the XKB layout.
Jul 07 21:26:55 <svu> juhp, sorry, do you mean "-layout fr" or "-symbols fr" ?
Jul 07 21:27:06 <svu> courtjester, no. It is much worse than that:)
Jul 07 21:27:34 <courtjester> Right, I was confusing xmodmap with setxkbmap
Jul 07 21:27:45 <juhp> svu: what is the default? ;) (layout I think)
Jul 07 21:28:27 <svu> juhp, no default. they are different things. The command line you provided would not work AFAIK
Jul 07 21:28:43 <svu> sorry, it would... my mistake
Jul 07 21:29:02 <juhp> :)
Jul 07 21:29:25 <svu> but they do not specify in "man" which way it works. hehe
Jul 07 21:29:28 <juhp> svu: sorry I don't use the applet to switch layout :)
Jul 07 21:29:29 <svu> I always used options
Jul 07 21:29:47 <juhp> svu: ok
Jul 07 21:30:03 <juhp> nm
Jul 07 21:30:41 <juhp> so we're going to have another meeting, later?
Jul 07 21:30:55 <svu> ok, who would volunteer for libxklavier review?
Jul 07 21:31:36 <liucougar_home> svu, I will ask James (suzhe) for that
Jul 07 21:31:48 <juhp> liucougar_home: thanks
Jul 07 21:31:56 <svu> liucougar_home, thanks
Jul 07 21:31:57 <liucougar_home> svu, probably SCIM could provide a UI for libxklavier as well
Jul 07 21:32:12 <svu> liucougar_home, wait a sec. there is NO UI in libxklavier
Jul 07 21:32:18 <svu> it is just information/control/...
Jul 07 21:32:29 <svu> (well, at least so far there was no UI)
Jul 07 21:32:35 <liucougar_home> so that those need SCIM do not need to have another icon sitting in systray
for keyboard layout switch
Jul 07 21:32:42 <liucougar_home> svu, no, I mean we SCIM provide UI for it
Jul 07 21:32:54 <liucougar_home> so users can configure it through SCIM
Jul 07 21:33:04 <juhp> well we can fight over that later ;-)
Jul 07 21:33:20 <svu> liucougar_home, well, UI would be a higher level. After we find how to generalize low level,
I would go to the UI issue
Jul 07 21:33:45 * svu would insist on splitting the functions and the UI - indication and configuration
Jul 07 21:33:46 <liucougar_home> right
Jul 07 21:33:54 <simosx> I believe the "Panel" in SCIM is the "gswitchit" applet in GNOME
(http://cvs.gnome.org/viewcvs/gnome-applets/gswitchit/)
Jul 07 21:34:10 <liucougar_home> svu, SCIM has that separation as well
Jul 07 21:34:22 <svu> simosx, yep
Jul 07 21:34:28 <svu> liucougar_home, good for us:)
Jul 07 21:34:42 <svu> simosx, but the binary is "gnome-keyboard-indicator" :)
Jul 07 21:36:32 <courtjester> svu: I do not seem to have gnome-keyboard-indicator on my systems
Jul 07 21:36:53 <simosx> courtjester, what distro?
Jul 07 21:37:38 <svu> courtjester, sorry, gnome-keyboard-applet
Jul 07 21:37:44 <courtjester> dapper/ suse 10.1. I do have gnome-keyboard-applet
Jul 07 21:37:50 <juhp> ah
Jul 07 21:37:58 <simosx> courtjester, in terms of UI, you typically right-click on the panel, then "Add to
panel..." and finally choose Keyboard Indicator.
Jul 07 21:38:37 <courtjester> simosx: yes I did have that running already.
Jul 07 21:38:48 <svu> yes. And in a future (well, after panel is going to get normal remote control) the applet
will appear automatically once >1 layouts are chosen
Jul 07 21:39:26 <juhp> svu: oh nice
Jul 07 21:39:30 <simosx> svu, that would be really great. the distro installer adds the layouts and the
indicator comes up automatically.
Jul 07 21:40:32 <svu> simosx, not today. not even tomorrow. I do not know when actually the panel is going
to be reviewed. But the main thing is that since now indicator is proper gtk widget -
there should not be any problem adding it to any place
Jul 07 21:41:49 <svu> which brings us back to the problem of gswitchit API:)
Jul 07 21:42:45 <juhp> svu: you mentioned dbus earlier for config - how is that used?
Jul 07 21:42:53 <svu> juhp, good question
Jul 07 21:43:38 <svu> basically, there is configuration registry
Jul 07 21:43:40 <svu> XKB file
Jul 07 21:43:44 <svu> rather large
Jul 07 21:43:53 <svu> containing all models/layouts/options
Jul 07 21:44:04 <svu> now (in 2.15) this file is loaded by g-s-d only
Jul 07 21:44:36 <svu> and indicator widget uses dbus to find the names (localized) of the currently selected layout(s)
- so it won't have to load this XML
Jul 07 21:45:02 <svu> initially XML was loaded by the applet - but there is a plot to use widget in several places,
so several copies of XML would not be nice
Jul 07 21:45:59 <juhp> aha
Jul 07 21:46:44 <svu> does it make sense?
Jul 07 21:47:02 <juhp> yep, mostly :)
Jul 07 21:47:14 * svu feels some tension:)
Jul 07 21:47:39 <juhp> so what is the widget talking to at the other end?
Jul 07 21:48:15 <svu> gnome-settings-daemon
Jul 07 21:48:26 <svu> containing loaded XML DOM
Jul 07 21:49:50 <juhp> gotcha
Jul 07 21:50:04 <juhp> thanks
Jul 07 21:50:31 * svu feels heavy burden of java architectural client-server background:)
Jul 07 21:50:49 <juhp> heh
Jul 07 21:52:46 <svu> so, would anyone have idea how to place code/API used by g-a and g-c-c for keyboard settings
and indication?
Jul 07 21:53:35 * svu thinks he will just put it all into CVS module/library and add dependencies - and once
people will see, they will start thinking and offering ideas:)
Jul 07 21:55:24 <courtjester> what functionality do you want the gswitchit API to have?
Jul 07 21:56:30 <courtjester> or what ever is going to replace it?
Jul 07 21:57:07 <svu> access to keyboard-related gconf settings, gtk widget - indicator, dbus client/server API.
MAYBY also libkbdraw (displaying the layout in the "Preview")
Jul 07 21:57:37 <svu> s/MAYBY/MAYBE/
Jul 07 21:59:42 <courtjester> is gconf the best place to hold this information? Is not gconf tied somewhat to gnome?
Jul 07 21:59:45 <svu> courtjester, it is not about "replacing". It is about moving from "virtual CVS module"
(included into 2 project) to normal share library with public API
Jul 07 22:00:13 <svu> courtjester, that is why I separated libgswitchit from libxklavier. libxklavier does not
depend on gnome. libgswitchit depends on gnome
Jul 07 22:01:08 * liucougar_home_ (n=liucouga@84-43-28-196.ppp.onetel.net.uk) has joined #xkbconfig
Jul 07 22:01:55 <svu> if I just move that model on the higher level, add configure.in/libgswitchit.pc - it will work
Jul 07 22:01:57 <courtjester> svu: I would hope that something as low level a the keyboard configuration would
not be tied to one framework.
Jul 07 22:02:16 <juhp> another thing that would be nice to share would be a common onscreen keyboard I think
Jul 07 22:02:39 <juhp> but maybe that is digressing too much
Jul 07 22:02:39 <svu> courtjester, everything which I could make desktop-agnostic - I put into libxklavier.
But the configuration (the way to save/load it) really depends on the desktop
Jul 07 22:02:57 <svu> juhp, well, I agree - but this is kinda beyoud the scope:)
Jul 07 22:03:03 <juhp> :)
Jul 07 22:04:32 <svu> it seems it is the only realistic WTG
Jul 07 22:05:11 <svu> start moving bits around and wait till people start complaining:)
Jul 07 22:06:47 <svu> ok, I think we could press the "Pause" button for today.
Jul 07 22:06:51 <svu> till next meeting
Jul 07 22:07:03 <juhp> sounds good
Jul 07 22:07:04 <courtjester> svu: I am not sure why the configuration depends on the desktop.
Jul 07 22:07:46 <svu> courtjester, every desktop has its own idea on how to store the configuration. In GNOME,
it is GConf (sorry, do not remember what it is in KDE)
Jul 07 22:08:48 <courtjester> But something as low level as keyboarding should have a universal way to store
its configuration. That is how SCIM does it.
Jul 07 22:09:28 <courtjester> SCIM has desktop dependent frontend (GTK/KDE) but the backend configuration does not care.
Jul 07 22:10:02 <svu> courtjester, so SCIM has to provide its own configuration storage mechanism, doesn't it?
Jul 07 22:10:09 <courtjester> Though I do suppose the SKIM can be setup to use kconfig.
Jul 07 22:10:09 <svu> own configuration files etc
Jul 07 22:10:38 <juhp> svu: it does, but frankly it does not work as well as gconf
Jul 07 22:11:02 <svu> juhp, sure. And the IMPORTANT thing about gconf which I use is notification
Jul 07 22:11:12 <svu> gnome-keyboard-properties changes configuration in gconf
Jul 07 22:11:26 <svu> g-s-d gets notified (by gconf) and reconfigures X server
Jul 07 22:11:28 <courtjester> svu: yes. SCIM can actually support multiple configuration modules. currently
it has simple, kconfig, socket, and dummy.
Jul 07 22:12:09 <juhp> no plans for a common desktop config framework i guess?
Jul 07 22:12:22 <svu> courtjester, well, you have your own abstraction layer. I did not want to invent one - so
I left to the higher level the ways to store/load the config
Jul 07 22:12:43 <svu> juhp, fd.o has some plans - but not there yet...
Jul 07 22:12:55 <juhp> ok right
Jul 07 22:12:56 <courtjester> juhp: that would be nice.
Jul 07 22:13:02 <juhp> yeah
Jul 07 22:13:48 <svu> so till fd.o does not have it - I leave it to the DE-specific code
Jul 07 22:14:22 <svu> (unless dalekiy_obriy would push me to create abstraction level for it)
Jul 07 22:14:53 <dalekiy_obriy> I'll think about it on weekend - thanks for suggestion :)
Jul 07 22:14:57 <juhp> svu, btw there are plans to rewrite scim for 2.0 to make it more modular - I think James Su
has a lot of ideas about that
Jul 07 22:15:18 <svu> juhp, extra modularity is USUALLY good:)
Jul 07 22:15:26 <svu> dalekiy_obriy, please nooooo :)
Jul 07 22:17:04 <dalekiy_obriy> svu, well if you create that set_local_charset method - I'll be busy for a while
before I invent somethign new for you :)
Jul 07 22:17:28 * AlinuxOS has quit ("https://launchpad.net/people/alinux")
Jul 07 22:18:54 <svu> dalekiy_obriy, :) I will try to do it this weekend
Jul 07 22:19:51 <dalekiy_obriy> thnx :)
Jul 07 22:20:43 <svu> ok, so at this point I declare the meeting (ghm, slightly chaotic, my fault) closed.
I hang on this channel anyway.
Jul 07 22:21:16 <juhp> svu, thanks for your time and interesting discussion
Jul 07 22:21:28 <juhp> let's continue the dialogue :)
Jul 07 22:21:42 * dalekiy_obriy (n=arysin@cpe-069-134-158-050.nc.res.rr.com) has left #xkbconfig
Jul 07 22:22:09 <svu> juhp, and thank you all lads, now I know a lot more about SCIM and IM in general
Jul 07 22:22:25 <juhp> great
Jul 07 22:22:25 <courtjester> Just to clarify...are you trying to come up with a universal API that will handle
enumerating and switching keyboards/input methods and storing settings for those input methods?
Jul 07 22:23:45 <svu> courtjester, " universal API that will handle enumerating and switching keyboards/input methods"
- yes. Also layouts /models/options etc etc
Jul 07 22:24:04 <svu> that is libxklavier
Jul 07 22:24:21 <svu> libgswitchit "storing settings for those input methods" and some more stuff
Jul 07 22:25:39 <courtjester> svu: thanks for the clarification. This is one area of Linux that really needs
to be sorted out. It will be interesting to see where this goes.
Jul 07 22:25:56 <juhp> courtjester: right
Jul 07 22:25:59 <svu> courtjester, I will be too :)))
Some Comments
The discussion was really interesting. First of all, people were positively understanding - everyone realized that knowing technology SCIM does not necessarily mean knowing technology XKB and vice versa - so there was significant cross-educational value, I'd say. Initially I expected more GNOME-specific talks - but I think it is good that we did not waste too much time on it (though I must admit, the DE-specific things were discussed).
On a technical side, the current aim is to look at the idea of using libxklavier as an abstraction layer hiding details of background keyboard configuration and state monitoring technologies (or more?). If SCIM folks find it possible, it could save a bit of headache to DE developers.
JamesSu â¶â¶ It's a very interesting discussion. However before getting into some details, I just want to learn something about the following points (maybe too naive):
1. What's the relationship between Linux keyboard mappings and X11 keyboard mappings?
- Will X11 honor the setting of linux keyboard mapping?
SergeyUdaltsov ⶠJames, AFAIK, X11 keyboard drivers (there are several of them) ignore console keyboard mapping. They use keyboard scancodes, produce keycodes (in X11 terms) which are mapped (using XKB configuration) to keysyms, actions etc. The mapping used in the console is ignored.
2. What's the relationship between xkb and xmodmap?
- Does xkb depend on xmodmap to work?
SergeyUdaltsov ⶠ"xmodmap" is name for a core X11 keyboard mapping technologies using basic keyboard features of X11 protocol. XKB is an extension to X11 protocol (backward compatible with xmodmap) which provides advances features (extending xlibc API). XKB depends on three things: X server has to support it, xlibc has to support it, the application should be XKB-aware. But since XKB is compatible with xmodmap, even in fully XKBized environment old applications should still work.
3. What's the relationship between libxklavier and xkb and xmodmap?
- Will libxklavier still work if there is no xkb at all? Such as when using evdev driver instead of kbd driver.
SergeyUdaltsov ⶠAFAIK evdev works with XKB (at least I got evdev keycode file contributed). But even without this note: libxklavier does its best to work in xmodmap environment. Though xmodmap is not very comfortable environment (lacks some important features) and some features has to be emulated - which might make user experience not as smooth as it is with XKB. The idea of backend somehow protects libxklavier API from the underlying technology. BTW, XKB is not ideal either, I have a long outstanding dream about new version of XKB.
4. Is there any platform independent hardware keycode or scancode standard?
- So that input method framework can just use such kind of keycode instead of key symbols to avoid interfering with X keyboard mapping setting.
SergeyUdaltsov ⶠBad news. The answer is no. For example, evdev keycodes are different from the standard X11 keyboard driver (look at the keycodes XKB directory). Though I know there are some works in ISO in this direction - but it is too early to talk about them.