Note : I prepared the following response after reading Harshula's bug
first report and Osamu's reply (messages marked #5 and #10
respectively) . I haven't still read fully the next 3 messages
(#15,#22 and #27 yet) which I saw only now.
With Harshula's proposed reversal of order (in first message), the
relevant lines in /etc/X11/Xsession.d/80im-switch would be:
for f in "$HOME/.xinput.d/all_ALL" \
"$HOME/.xinput.d/${LNG}" \
"/etc/X11/xinit/xinput.d/all_ALL" \
"/etc/X11/xinit/xinput.d/${LNG}" \
"/etc/X11/xinit/xinput.d/default" ; do
"/etc/X11/xinit/xinput.d/all_ALL" above
"/etc/X11/xinit/xinput.d/${LNG}" - Well, that upsets the apple cart
for those users who
now have the luxury of relying on system-wide configurations alone
for having their preferred keymap up and running out-of-box. I
am referring to system-wide defaults for locale "th_TH" provisioned by
postinst of "im-switch" package itself and for CJK locales
provisioned by postinst of "scim" package.
Un-reversing the order for only those two lines for system-wide
configurations is not a solution since that would not allow us one
common
definition for the scope of "all_ALL". Having difference in its
meaning for user's and system-wide configurations may well cause more
confusions.
An alternative I thought of is to restrict the use of all_ALL for
user's configurations only and not have for system-wide. If
"/etc/X11/xinit/xinput.d/all_ALL" is removed in above revered order
proposed by Harshula then the configuration file in the last line
("/etc/X11/xinit/xinput.d/default") will be the fall back default for
all locales. And also those th_TH and CJK locale users will
continue to have out-of-box ready defaults.
However the deprecation of all_ALL for system-wide configuration would
require the postinst of different IME packages as well as of im-switch
pacakge, not writing to or creating anew an alternatives registry
file /var/lib/dpkg/alternatives/x-input-all_ALL. Presently postinst
of "scim" (in Debian Lenny but *not* in Ubuntu 8.xx) and "uim" (both
in Ubuntu-8.xx and Lenny) write into that file and so does postinst of
im-switch. So removing all_ALL from system-wide configurations may not
be feasible unless convention gets accepted by all parties.
Osamu wrote (in Message marked #10):
> By the way, what do you tell user if they want to remove all_ALL
> feature. There is no easy way other than using "rm" command. This is
> the real problem. Maybe if we have way to remove link via im-switch
> command, people will not be confused. Setting all_ALL while removing
> everything else will get you what you want with current order.
>
>
> I think action items are:
> * improve documentation
> * add new option -d which reset inputmethod link for that link, if run
> without -z ll_ZZ, then it should reset for all locales.
By "reset" I assume you mean "remove" from ~/.xinput.d/ only and not
from system-wide configuration. Because if a feature of removing from
system-wide by way of "sudo im-switch [ -z ll_LL] -d " is also
envisioned then it would mean the use of "update-alternatives
--remove-all" to remove teh relevant from registry - a futile step
because scim and / or uim packages would recreate registry entries if
installed (or reinstalled) after this step.
>
>
> Basically, -d is oposit of -a, -c, -s does.
>
Yes. "im-switch -a" removes only ~/.xinput.d/ll_CC where ll_CC is
locale of the session logged-in whereas "im-switch -d" would do a full
rm ~/.xinput.d/* - an inconsistency that needs to be avoided in my
opinion.
An alternative I could think of is to preserve the existing order of
precedences and all existing command syntax features. But Introduce
two more command features for *user's configuration* only as follows:
1. im-switch [v] -e
This is to"empty" out ~/.xinput.d/ . i.e., rm ~/.xinput.d/* . (May
call it "-p" meaning "purging" or anything else you consider more
appropraite).
On the execution of the command by user if there is no links or
backedups in ~/.xinput.d/ then command simply exits without any error
stae
If one or more links and/or backedups are there in ~/.xinput.d/ then,
there should be an alert that all those in ~/.xinput.d/ will be
removed and user to confirm with "y" + "enter" or cancel with
"n"+"enter". (If only "enter" is pressed without "y" or "n" it should
be also taken as a "n" becuase for in other im-switch commands
"enter" without a chioce means "no change".
If the user enters the same command with sudo, then the user should be
alerted that this usage is not provided for system-wide configuration
and exit.
This is feature is like reverting to factory setting for user's
configuration - well not exactly factory setting because that would
mean "rmdir ~/.xinput.d" which step is not really necessary.
2. im-switch [v] [z -ll_CC] -r inputmethodname
"r" for re-initalise - (may be you can think of better alternative for
"r" - like for example "i") . This is to carry out following two
commands:
i). the above im-switch [v] -e
If there are no pre exisiting links / backeups in ~/.xinput.d/ then go
to next command ii)
if there exists links and/or backedups in ~/.xinput.s/ . And when the
user affirms deleting all those existing, delete them and then carry
out the next command ii):
ii. im-switch [v] [z -ll_CC] -s inputmethodname
So this is to re-initilaize user's configuration from whatevert it was
before to a desied one.
To do the same things as i) and ii) above with usage of "-c" instead
of -s we may introduce a 3rd command with soemthing else for "-r").
While this (command 2 above) provides for a single line command usage
suitable for enablers to include in their installation guides (like in
http://sinhala.sourceforge.net/) without recourse to "rm", there are
still two issues:
a. The meaning of all_ALL will continue to be "all the rest" only
(since specific locale configuration links can still be made in
~/.xinput.d)
b. Whether the alert I suggested for the user to be asked ( to confirm
deleting all exisiting links from ~/.xinput.d/) is considered as
additional encumberance for their target users by the enabler.
Would like to see your both opinions on these
~Sethu
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
