From fuyuki@jurassic-x4600.sfbay.sun.com Thu Sep 17 03:54:13 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8HAsDUw002950 for ; Thu, 17 Sep 2009 03:54:13 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n8HAsCdm017423; Thu, 17 Sep 2009 03:54:12 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQ400F0B3MCZM00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 17 Sep 2009 03:54:12 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQ4008H53MABL70@nwk-avmta-1.sfbay.Sun.COM>; Thu, 17 Sep 2009 03:54:10 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n8HAsArn380051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Sep 2009 03:54:10 -0700 (PDT) Received: (from fuyuki@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n8HAsA8g380045; Thu, 17 Sep 2009 03:54:10 -0700 (PDT) Date: Thu, 17 Sep 2009 03:54:10 -0700 (PDT) From: Fuyuki Hasegawa Subject: iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009] To: PSARC-ext@sun.com Cc: gto@sun.com Message-id: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 8675 I'm submitting this fast-track for myself (IM group), scheduled to timeout at 09/24/2009. Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: iBus integration 1.2. Name of Document Author/Supplier: Author: Fuyuki Hasegawa 1.3 Date of This Document: 17 September, 2009 2. Project Summary 2.1. Project Description: This project is to integrate next generation Input Method framework, iBus and its various IMEs (Input Method Engines). Release binding is Micro/Patch and initial integration is OpenSolaris (Nevada). COMPONENT VERSION LICENSE LANGUAGES ------------------------------------------------------------------------ ibus: 1.1.0 LGPLv2.1 IM framework Available IMEs: ibus-anthy: 1.1.0 GPLv2 Japanese ibus-pinyin: 1.1.0 GPLv2 Simplified Chinese ibus-chewing: 1.1.0 GPLv2 Traditional Chinese ibus-hangul: 1.1.0 GPLv2 Korean ibus-m17n: 1.1.0 GPLv2 libm17n[4] Umbrella Engine ibus-table: 1.1.0 GPLv2 code-table Umbrella Engine Codetables for ibus-table ibus-table-array30 1.2.0 GPLv2 Traditional Chinese ibus-table-cangjie 1.1.0 GPLv2 Traditional Chinese ibus-table-erbi 1.1.0 GPLv2 Simplified Chinese ibus-table-quick 1.1.0 GPLv2 Simplified Chinese ibus-table-translit 1.1.0 GPLv2 Cyrillic ibus-table-wubi 1.1.0 GPLv2 Simplified Chinese ibus-table-xinhua 1.1.0 GPLv2 Simplified Chinese ibus-table-yong 1.1.0 GPLv2 Simplified Chinese ibus-table-zhengma 1.1.0 GPLv2 Simplified Chinese 2.2. Risks and Assumptions: iBus requires python 2.5+ in runtime, but currently opensolaris still uses python 2.4 as default. We need python2.6 to be the default in OpenSolaris. 4. Technical Description 4.1. Details: 4.1.1 iBus Overview: iBus (http://code.google.com/p/ibus) leverages many design ideas and principles in the CJK input method SPI specification conference, which many experienced IM developers (among iiimf, scim communities and us) joined and contributed. It's mainly developed by Peng Huang, who works for Redhat. And it's a very active community, much more active than iiimf and scim. ibus delivered 1.1.0 stable release on July 2009. It had been adopted as default IM framework on Fedora 11, and it will also be used as the default on next Ubuntu release Karmic (https://wiki.ubuntu.com/desktop- karmic-input-methods). It's already in Debian/Ubuntu package repo. Integrating ibus does not mean to obsolete iiimf or scim, but we would put them in maintenance state. +------------+ +--------+ +-----------+ | GtkApp | | X11App | | QtApp | +------------+ +--------+ +-----------+ |ibus-gtk-imm| |ximcp.so| |ibus-qt-imm| +----^-------+ +----^---+ +-----^-----+ | | | | +-------V---------+ | | |ibus-xim-frontend| | | +-------^---------+ | | | | /---V----------------V--------------V-------\ / ibus message bus \ \ daemon in C / \---^--------^-----------^------------^-----/ | | | | +--V--- +--V--+ +-----V-----+ +---V----+ |IME A| |IME B| | panel GUI | | config | +-----+ +-----+ +-----------+ +--------+ This 'bus-centric' architecture is introduced to resolve the following weakness in 'server-centric' architecture. * There's usually only 1 server per desktop session, which loads all IMEs as shared objects. So one buggy IME would crash the entire server. * IMEs are developed with either C or C++, it's difficult to add other language bindings. Adding a binding basically means plugging an interpreter into server's process space. * IMEs are not able to be loaded or unloaded on the fly. All components in above diagram uses DBus as IPC. And iBus largely uses python, such as panel GUI, config backend, or even IMEs. 4.1.2 Switching between iBus, SCIM and IIIMF iBus services are started by gnome-session(1). User could simply enable or disable the service via gnome-session-properties(1). With the help of startup scripts shipped with iiimf and scim, user could set GTK_IM_MODULE environment variable in $HOME/.profile to select iBus, IIIMF or SCIM. We plan to change default IM framework from iiimf to ibus in Solaris Next. 4.4. Out of Scope: KDE/Qt support through ibus-qt-imm is out of scope this time. Qt applications will be connected through XIM frontend. 4.5. Interfaces: INTERFACE NAME STABILITY NOTE ----------------------------------------------------------------------- /usr/bin/ibus-daemon Uncommitted message bus daemon /usr/bin/ibus-setup Uncommitted setup launcher /usr/libexec/ibus-x11 Uncommitted ibus XIM fontend/agend /usr/libexec/ibus-gconf Uncommitted config backend by gconf-python /usr/libexec/ibus-ui-gtk Uncommitted panel GUI by pygtk /usr/lib/libibus.so Uncommitted ibus C binding SDK library /usr/include/ibus-1.0/* Uncommitted ibus C binding header files /usr/share/gtk-doc/html/ Uncommitted ibus developor documents ibus/* /usr/lib/python2.6/ Uncommitted ibus Python binding site-packages/ibus/* /usr/lib/gtk-2.0/2.10.0/ Uncommitted ibus gtk-im-module immodules/im-ibus*.so /usr/lib/{amd64,sparcv9}/ Uncommitted 64bits version of ibus gtk-2.0/2.10.0/immodules/ gtk-im-module im-ibus*.so /usr/share/ibus/setup/* Uncommitted ibus-setup modules /usr/share/ibus/ui/gtk/* Uncommitted panel GUI by pygtk /usr/share/ibus/ Uncommitted ibus components registry components/* like ibus-gconf, ibus-ui-gtk and IMEs /usr/libexec/ Uncommitted IME launcher ibus-engine- /usr/libexec/ Uncommitted IME setup launcher ibus-setup- /usr/share/ibus- Uncommitted IME modules *IME_NAME is among [anthy, chewing, hangul, m17n, pinyin, table] /usr/share/ibus-table/* Uncommitted ibus-table engine and code-tables 4.10. Packaging & Delivery: SUNWibus SUNWibus-root SUNWibus-devel SUNWibus-chewing SUNWibus-chewing-root SUNWibus-anthy SUNWibus-pinyin SUNWibus-hangul SUNWibus-m17n SUNWibus-table SUNWibus-table-devel SUNWibus-table-data-cangjie SUNWibus-table-data-erbi SUNWibus-table-data-quick SUNWibus-table-data-translit SUNWibus-table-data-wubi SUNWibus-table-data-xinhua SUNWibus-table-data-yong SUNWibus-table-data-zhengma SUNWibus-table-extraphrase SUNWibus-table-extraphrase-devel 4.12. Dependencies: We need python2.6 to be the default in OpenSolaris. 5. Reference Documents: 1). IIIMF project http://www.openi18n.org/iiimf PSARC 2005/525 IIIMF upgrade to revision 12 2). SCIM project http://www.scim-im.org PSARC 2008/418 Integrate SCIM to Solaris 3). Server-Centric vs. Bus-Centric Architectures http://docs.google.com/present/view?id=ahtgvwdt62tk_24ftz4nsft 4). Supported Input Methods in libm17n http://www.m17n.org/m17n-lib-en/support_input_sum.html PSARC 2008/624 Integrate libm17n and scim-m17n to Solaris 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: G11N 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From ro@techfak.uni-bielefeld.de Fri Sep 18 04:51:30 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8IBpTLd023375 for ; Fri, 18 Sep 2009 04:51:30 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n8IBpThB007720 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 18 Sep 2009 04:51:29 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQ600M0B0XR6M00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 18 Sep 2009 04:51:27 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQ600FJM0XPBT40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 18 Sep 2009 04:51:25 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8IBp7H9005795 for ; Fri, 18 Sep 2009 11:51:25 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay13i.sun.com with ESMTP id BT-MMP-2067772; Fri, 18 Sep 2009 11:51:24 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-18537015; Fri, 18 Sep 2009 11:51:24 +0000 (Z) Received: from smarthost.TechFak.Uni-Bielefeld.DE ([129.70.137.17] [129.70.137.17]) by relay1i.sun.com with ESMTP id BT-MMP-17776389; Fri, 18 Sep 2009 11:51:24 +0000 (Z) Received: from komagatake.TechFak.Uni-Bielefeld.DE (komagatake.TechFak.Uni-Bielefeld.DE [129.70.137.126]) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTP id 7F6637C; Fri, 18 Sep 2009 13:51:23 +0200 (CEST) Received: (from ro@localhost) by komagatake.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) id n8IBpNm22447; Fri, 18 Sep 2009 13:51:23 +0200 (MEST) Date: Fri, 18 Sep 2009 13:51:22 +0200 From: Rainer Orth Subject: Re: iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009] In-reply-to: Fuyuki Hasegawa's message of "Thu, 17 Sep 2009 03:54:10 -0700 (PDT)" Sender: ro@techfak.uni-bielefeld.de To: Fuyuki Hasegawa Cc: PSARC-ext@sun.com, gto@sun.com Message-id: MIME-version: 1.0 X-Mailer: Gnus v5.6.44/Emacs 19.34 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== Lines: 51 References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> Status: RO Content-Length: 1905 Fuyuki Hasegawa writes: > 4.5. Interfaces: > > INTERFACE NAME STABILITY NOTE > ----------------------------------------------------------------------- > /usr/bin/ibus-daemon Uncommitted message bus daemon How is this started? Via SMF at boot? If so, we need FMRI etc. Can it ever be invoked manually be a regular user? If not, it belongs into /usr/sbin (if manually invoked by sysadmins) of /usr/lib. > /usr/bin/ibus-setup Uncommitted setup launcher Same here: who invokes this? > /usr/libexec/ibus-x11 Uncommitted ibus XIM fontend/agend > > /usr/libexec/ibus-gconf Uncommitted config backend by gconf-python > /usr/libexec/ibus-ui-gtk Uncommitted panel GUI by pygtk There is no /usr/libexec in Solaris: either belongs into /usr/lib (or /usr/lib/ibus) or /usr/share/ibus if architecture independent. > /usr/lib/libibus.so Uncommitted ibus C binding SDK library That's only the compilation symlink. What's the real filename and SONAME? > /usr/libexec/ Uncommitted IME launcher > ibus-engine- > /usr/libexec/ Uncommitted IME setup launcher > ibus-setup- Same as above: no /usr/libexec. > /usr/share/ibus- Uncommitted IME modules > *IME_NAME is among [anthy, chewing, hangul, m17n, pinyin, table] Why the mess: better move this to /usr/share/ibus/ to avoid cluttering /usr/share even more. > /usr/share/ibus-table/* Uncommitted ibus-table engine and > code-tables Same here: better /usr/share/ibus/table or some such. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University From Fuyuki.Hasegawa@sun.com Fri Sep 18 07:32:42 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8IEWeL4025562 for ; Fri, 18 Sep 2009 07:32:40 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n8IEWDno005841; Fri, 18 Sep 2009 22:32:39 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQ6003098ECGR00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 18 Sep 2009 07:32:36 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQ6002S18E7D520@nwk-avmta-1.sfbay.Sun.COM>; Fri, 18 Sep 2009 07:32:35 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8IEWVtq014652; Fri, 18 Sep 2009 14:32:31 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQ60020088VVM00@mail-apac.sun.com>; Fri, 18 Sep 2009 22:32:31 +0800 (SGT) Received: from [129.158.28.135] ([unknown] [129.158.28.135]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQ6001E58E6OVA0@mail-apac.sun.com>; Fri, 18 Sep 2009 22:32:31 +0800 (SGT) Date: Fri, 18 Sep 2009 23:32:26 +0900 From: Fuyuki Hasegawa - Sun Microsystems Subject: Re: iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009] In-reply-to: Sender: Fuyuki.Hasegawa@sun.com To: Rainer Orth Cc: PSARC-ext@sun.com, gto@sun.com Message-id: <4AB399FA.4060406@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 2692 Rainer, thank you for your review. Rainer Orth wrote: > Fuyuki Hasegawa writes: > >> 4.5. Interfaces: >> >> INTERFACE NAME STABILITY NOTE >> ----------------------------------------------------------------------- >> /usr/bin/ibus-daemon Uncommitted message bus daemon > > How is this started? Via SMF at boot? If so, we need FMRI etc. Can it > ever be invoked manually be a regular user? If not, it belongs into > /usr/sbin (if manually invoked by sysadmins) of /usr/lib. It's user process started via gnome-session(1). > >> /usr/bin/ibus-setup Uncommitted setup launcher > > Same here: who invokes this? It's invoked via System->Preference->iBus Setup or by manual. > >> /usr/libexec/ibus-x11 Uncommitted ibus XIM fontend/agend >> >> /usr/libexec/ibus-gconf Uncommitted config backend by gconf-python >> /usr/libexec/ibus-ui-gtk Uncommitted panel GUI by pygtk > > There is no /usr/libexec in Solaris: either belongs into /usr/lib (or > /usr/lib/ibus) or /usr/share/ibus if architecture independent. In order to reduce Solaris patches, we followed the original directories. If /usr/libexec/ is not allowed, we will change them to /usr/lib/ibus/ibus-*. >> /usr/lib/libibus.so Uncommitted ibus C binding SDK library > > That's only the compilation symlink. What's the real filename and SONAME? /usr/lib/libibus.so.0.0.0 will update the material. > >> /usr/libexec/ Uncommitted IME launcher >> ibus-engine- >> /usr/libexec/ Uncommitted IME setup launcher >> ibus-setup- > > Same as above: no /usr/libexec. If /usr/libexec/ is not allowed, we will change them to /usr/lib/ibus/ibus-engine- (I know this is better) /usr/lib/ibus/ibus-setup- (I know this is better) or /usr/lib/ibus-engine- /usr/lib/ibus-setup- > >> /usr/share/ibus- Uncommitted IME modules >> *IME_NAME is among [anthy, chewing, hangul, m17n, pinyin, table] > > Why the mess: better move this to /usr/share/ibus/ to avoid > cluttering /usr/share even more. > >> /usr/share/ibus-table/* Uncommitted ibus-table engine and >> code-tables > > Same here: better /usr/share/ibus/table or some such. In fact I've been feeling the same way, but again, we followed the original directories to reduce Solaris patches. I understand these changes are not mandatory, but better to have. I'll discuss with the project team and come back. Thanks, Fuyuki From ro@techfak.uni-bielefeld.de Fri Sep 18 08:04:37 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8IF4bru026168 for ; Fri, 18 Sep 2009 08:04:37 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8IF4YTH023082; Fri, 18 Sep 2009 16:04:34 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQ6007039VLBS00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 18 Sep 2009 08:04:33 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQ6002MX9VLD6B0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 18 Sep 2009 08:04:33 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8IF1HLI028362; Fri, 18 Sep 2009 15:04:33 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay41i.sun.com with ESMTP id BT-MMP-1483573; Fri, 18 Sep 2009 15:04:33 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-14207647; Fri, 18 Sep 2009 15:04:30 +0000 (Z) Received: from smarthost.TechFak.Uni-Bielefeld.DE ([129.70.137.17] [129.70.137.17]) by relay4i.sun.com with ESMTP id BT-MMP-6580643; Fri, 18 Sep 2009 15:04:30 +0000 (Z) Received: from komagatake.TechFak.Uni-Bielefeld.DE (komagatake.TechFak.Uni-Bielefeld.DE [129.70.137.126]) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTP id 42C4692; Fri, 18 Sep 2009 17:04:29 +0200 (CEST) Received: (from ro@localhost) by komagatake.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) id n8IF4TA01802; Fri, 18 Sep 2009 17:04:29 +0200 (MEST) Date: Fri, 18 Sep 2009 17:04:27 +0200 (MEST) From: Rainer Orth Subject: Re: iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009] In-reply-to: <4AB399FA.4060406@sun.com> To: Fuyuki Hasegawa - Sun Microsystems Cc: PSARC-ext@sun.com, gto@sun.com Message-id: <19123.41339.606980.304455@komagatake.TechFak.Uni-Bielefeld.DE> MIME-version: 1.0 X-Mailer: VM 6.62 under Emacs 19.34.1 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-1.1/5.0, scanned in 2.338sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> <4AB399FA.4060406@sun.com> Status: RO Content-Length: 3524 Fuyuki, > >> 4.5. Interfaces: > >> > >> INTERFACE NAME STABILITY NOTE > >> ----------------------------------------------------------------------- > >> /usr/bin/ibus-daemon Uncommitted message bus daemon > > > > How is this started? Via SMF at boot? If so, we need FMRI etc. Can it > > ever be invoked manually be a regular user? If not, it belongs into > > /usr/sbin (if manually invoked by sysadmins) of /usr/lib. > > It's user process started via gnome-session(1). but if there is no reason to start this manually, it's probably better located in /usr/lib/ibus. > >> /usr/bin/ibus-setup Uncommitted setup launcher > > > > Same here: who invokes this? > > It's invoked via System->Preference->iBus Setup or by manual. Ok, if manual invokation is an option, the location is fine. > >> /usr/libexec/ibus-x11 Uncommitted ibus XIM fontend/agend > >> > >> /usr/libexec/ibus-gconf Uncommitted config backend by gconf-python > >> /usr/libexec/ibus-ui-gtk Uncommitted panel GUI by pygtk > > > > There is no /usr/libexec in Solaris: either belongs into /usr/lib (or > > /usr/lib/ibus) or /usr/share/ibus if architecture independent. > > In order to reduce Solaris patches, we followed the original directories. > If /usr/libexec/ is not allowed, we will change them to /usr/lib/ibus/ibus-*. Fine, thanks. > >> /usr/lib/libibus.so Uncommitted ibus C binding SDK library > > > > That's only the compilation symlink. What's the real filename and SONAME? > > /usr/lib/libibus.so.0.0.0 > will update the material. The SONAME will more likely be libibus.so.0 in this case. Please check with dump -Lv. > >> /usr/libexec/ Uncommitted IME launcher > >> ibus-engine- > >> /usr/libexec/ Uncommitted IME setup launcher > >> ibus-setup- > > > > Same as above: no /usr/libexec. > > If /usr/libexec/ is not allowed, we will change them to > > /usr/lib/ibus/ibus-engine- (I know this is better) > /usr/lib/ibus/ibus-setup- (I know this is better) > or > /usr/lib/ibus-engine- > /usr/lib/ibus-setup- Please use the first variant to avoid needlessly cluttering /usr/lib. > >> /usr/share/ibus- Uncommitted IME modules > >> *IME_NAME is among [anthy, chewing, hangul, m17n, pinyin, table] > > > > Why the mess: better move this to /usr/share/ibus/ to avoid > > cluttering /usr/share even more. > > > >> /usr/share/ibus-table/* Uncommitted ibus-table engine and > >> code-tables > > > > Same here: better /usr/share/ibus/table or some such. > > In fact I've been feeling the same way, but again, we followed the > original directories to reduce Solaris patches. Understood, but perhaps the changes can even be fed upstream? At least in Solaris, there seems to be a strong preference to have exactly one directory in /usr/share for each application, otherwise the directory quickly becomes almost impossible to browse. > I understand these changes are not mandatory, but better to have. Some of them might be optional, but at the change away from /usr/libexec is mandatory. > I'll discuss with the project team and come back. Excellent, thanks. Rainer ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University From Alan.Coopersmith@sun.com Fri Sep 18 08:16:31 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8IFGUKM026243 for ; Fri, 18 Sep 2009 08:16:30 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8IFGFcQ000826; Fri, 18 Sep 2009 16:16:29 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQ600801AFHT400@nwk-avmta-1.sfbay.Sun.COM>; Fri, 18 Sep 2009 08:16:29 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQ6008F4AFGBS00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 18 Sep 2009 08:16:28 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8IFGR0H007701; Fri, 18 Sep 2009 08:16:27 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQ600H00A8R1B00@fe-sfbay-09.sun.com>; Fri, 18 Sep 2009 08:16:27 -0700 (PDT) Received: from [129.145.155.53] ([unknown] [129.145.155.53]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQ600JPVAFFTD80@fe-sfbay-09.sun.com>; Fri, 18 Sep 2009 08:16:27 -0700 (PDT) Date: Fri, 18 Sep 2009 08:16:27 -0700 From: Alan Coopersmith Subject: Re: iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009] In-reply-to: <4AB399FA.4060406@sun.com> Sender: Alan.Coopersmith@sun.com To: Fuyuki Hasegawa - Sun Microsystems Cc: Rainer Orth , PSARC-ext@sun.com, gto@sun.com Message-id: <4AB3A44B.4090809@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> <4AB399FA.4060406@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 515 Fuyuki Hasegawa - Sun Microsystems wrote: > In order to reduce Solaris patches, we followed the original directories. Do you really have to patch it to change the path? Doesn't it offer ./configure flags for directory paths like most desktop open source software? (If not, that would seem a patch most upstreams would be happy to take, so that each distro doesn't have to patch it themselves.) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Joerg.Barfurth@Sun.COM Tue Sep 22 01:46:17 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8M8kGVD019458 for ; Tue, 22 Sep 2009 01:46:17 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n8M8k74h025367; Tue, 22 Sep 2009 16:46:15 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQD0000F712DM00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 22 Sep 2009 01:46:14 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQD001JV710MMC0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 22 Sep 2009 01:46:13 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8M8k9Rq007443; Tue, 22 Sep 2009 08:46:12 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQD00L006K43700@fe-emea-10.sun.com>; Tue, 22 Sep 2009 09:46:08 +0100 (BST) Received: from [10.16.66.63] ([unknown] [10.16.66.63]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQD00BL570NQS10@fe-emea-10.sun.com>; Tue, 22 Sep 2009 09:46:00 +0100 (BST) Date: Tue, 22 Sep 2009 10:45:59 +0200 From: Joerg Barfurth Subject: Re: iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009] In-reply-to: <19123.41339.606980.304455@komagatake.TechFak.Uni-Bielefeld.DE> Sender: Joerg.Barfurth@Sun.COM To: Rainer Orth Cc: Fuyuki Hasegawa - Sun Microsystems , gto@Sun.COM, PSARC-ext@Sun.COM Message-id: <4AB88EC7.1010409@sun.com> Organization: Sun Microsystem - Desktop MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> <4AB399FA.4060406@sun.com> <19123.41339.606980.304455@komagatake.TechFak.Uni-Bielefeld.DE> User-Agent: Thunderbird 2.0.0.17 (X11/20081014) Status: RO Content-Length: 1144 Rainer Orth schrieb: >>>> 4.5. Interfaces: >>>> >>>> INTERFACE NAME STABILITY NOTE >>>> ----------------------------------------------------------------------- >>>> /usr/bin/ibus-daemon Uncommitted message bus daemon >>> How is this started? Via SMF at boot? If so, we need FMRI etc. Can it >>> ever be invoked manually be a regular user? If not, it belongs into >>> /usr/sbin (if manually invoked by sysadmins) of /usr/lib. >> It's user process started via gnome-session(1). > > but if there is no reason to start this manually, it's probably better > located in /usr/lib/ibus. > Do users that don't use GNOME and use a custom WM or a desktop that is not aware of ibus need to launch this manually? Is that sufficient justification to place it in /usr/bin? - Jörg -- Joerg Barfurth phone: +49 40 23646662 / x66662 Software Engineer mailto:joerg.barfurth@sun.com Desktop Technology http://reserv.ireland/twiki/bin/view/Argus/ Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/ From Fuyuki.Hasegawa@sun.com Thu Sep 24 05:16:48 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8OCGl12021976 for ; Thu, 24 Sep 2009 05:16:48 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n8OCGT5M001874; Thu, 24 Sep 2009 20:16:46 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQH0000363XKK00@brm-avmta-1.central.sun.com>; Thu, 24 Sep 2009 06:16:45 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQH00EVI63SMP30@brm-avmta-1.central.sun.com>; Thu, 24 Sep 2009 06:16:44 -0600 (MDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8OCGdgi001833; Thu, 24 Sep 2009 12:16:39 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQH00M005UGS200@mail-apac.sun.com>; Thu, 24 Sep 2009 20:16:39 +0800 (SGT) Received: from [129.158.28.135] ([unknown] [129.158.28.135]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQH000NE63QG0B0@mail-apac.sun.com>; Thu, 24 Sep 2009 20:16:39 +0800 (SGT) Date: Thu, 24 Sep 2009 21:16:34 +0900 From: Fuyuki Hasegawa - Sun Microsystems Subject: Re: iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009] In-reply-to: <4AB3A44B.4090809@sun.com> Sender: Fuyuki.Hasegawa@sun.com To: Alan Coopersmith Cc: Rainer Orth , PSARC-ext@sun.com, gto@sun.com Message-id: <4ABB6322.7060409@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> <4AB399FA.4060406@sun.com> <4AB3A44B.4090809@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 551 Alan Coopersmith wrote: > Fuyuki Hasegawa - Sun Microsystems wrote: >> In order to reduce Solaris patches, we followed the original directories. > > Do you really have to patch it to change the path? Doesn't it offer > ./configure flags for directory paths like most desktop open source > software? (If not, that would seem a patch most upstreams would be > happy to take, so that each distro doesn't have to patch it themselves.) Thanks for your comment. You are right. We could change /usr/libexec to /usr/lib/ibus in the SPEC file. Fuyuki From Fuyuki.Hasegawa@sun.com Thu Sep 24 05:24:00 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8OCO0Gx022011 for ; Thu, 24 Sep 2009 05:24:00 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n8OCNxbu013639; Thu, 24 Sep 2009 05:23:59 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQH00D016FZOH00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 24 Sep 2009 05:23:59 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQH00BN46FYU800@nwk-avmta-1.sfbay.Sun.COM>; Thu, 24 Sep 2009 05:23:59 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8OCNwjj029530; Thu, 24 Sep 2009 12:23:58 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQH003006FXYN00@mail-apac.sun.com>; Thu, 24 Sep 2009 20:23:58 +0800 (SGT) Received: from [129.158.28.135] ([unknown] [129.158.28.135]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQH000QT6FWG0B0@mail-apac.sun.com>; Thu, 24 Sep 2009 20:23:57 +0800 (SGT) Date: Thu, 24 Sep 2009 21:23:53 +0900 From: Fuyuki Hasegawa - Sun Microsystems Subject: Re: iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009] In-reply-to: <4AB88EC7.1010409@sun.com> Sender: Fuyuki.Hasegawa@sun.com To: Joerg Barfurth Cc: Rainer Orth , gto@sun.com, PSARC-ext@sun.com Message-id: <4ABB64D9.7080600@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> <4AB399FA.4060406@sun.com> <19123.41339.606980.304455@komagatake.TechFak.Uni-Bielefeld.DE> <4AB88EC7.1010409@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 980 Joerg Barfurth wrote: > Rainer Orth schrieb: > >>>>> 4.5. Interfaces: >>>>> >>>>> INTERFACE NAME STABILITY NOTE >>>>> >>>>> ----------------------------------------------------------------------- >>>>> >>>>> /usr/bin/ibus-daemon Uncommitted message bus daemon >>>> How is this started? Via SMF at boot? If so, we need FMRI etc. >>>> Can it >>>> ever be invoked manually be a regular user? If not, it belongs into >>>> /usr/sbin (if manually invoked by sysadmins) of /usr/lib. >>> It's user process started via gnome-session(1). >> >> but if there is no reason to start this manually, it's probably better >> located in /usr/lib/ibus. > > Do users that don't use GNOME and use a custom WM or a desktop that is > not aware of ibus need to launch this manually? Is that sufficient > justification to place it in /usr/bin? Yes, ibus-daemon need to launch manually in non GNOME env. I think /usr/bin/ibus-daemon is OK. Fuyuki From Fuyuki.Hasegawa@sun.com Thu Sep 24 06:13:46 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8ODDjri022832 for ; Thu, 24 Sep 2009 06:13:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n8ODDgGa002352; Thu, 24 Sep 2009 06:13:44 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQH0061H8QWC800@brm-avmta-1.central.sun.com>; Thu, 24 Sep 2009 07:13:44 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQH00EBE8QUN660@brm-avmta-1.central.sun.com>; Thu, 24 Sep 2009 07:13:43 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8ODDgQ8003405; Thu, 24 Sep 2009 13:13:42 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQH005008KGZ700@mail-apac.sun.com>; Thu, 24 Sep 2009 21:13:41 +0800 (SGT) Received: from [129.158.28.135] ([unknown] [129.158.28.135]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQH00EBA8QSVUC0@mail-apac.sun.com>; Thu, 24 Sep 2009 21:13:41 +0800 (SGT) Date: Thu, 24 Sep 2009 22:13:37 +0900 From: Fuyuki Hasegawa - Sun Microsystems Subject: Re: iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009] In-reply-to: <19123.41339.606980.304455@komagatake.TechFak.Uni-Bielefeld.DE> Sender: Fuyuki.Hasegawa@sun.com To: Rainer Orth Cc: PSARC-ext@sun.com, gto@sun.com Message-id: <4ABB7081.4030406@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> <4AB399FA.4060406@sun.com> <19123.41339.606980.304455@komagatake.TechFak.Uni-Bielefeld.DE> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 4122 Rainer Orth wrote: > Fuyuki, > >>>> 4.5. Interfaces: >>>> >>>> INTERFACE NAME STABILITY NOTE >>>> ----------------------------------------------------------------------- >>>> /usr/bin/ibus-daemon Uncommitted message bus daemon >>> How is this started? Via SMF at boot? If so, we need FMRI etc. Can it >>> ever be invoked manually be a regular user? If not, it belongs into >>> /usr/sbin (if manually invoked by sysadmins) of /usr/lib. >> It's user process started via gnome-session(1). > > but if there is no reason to start this manually, it's probably better > located in /usr/lib/ibus. As I replied to Joerg, we'd like to keep /usr/bin/ibus-daemon. (FYI, iiim daemons also have been located in /usr/bin) > >>>> /usr/bin/ibus-setup Uncommitted setup launcher >>> Same here: who invokes this? >> It's invoked via System->Preference->iBus Setup or by manual. > > Ok, if manual invokation is an option, the location is fine. > >>>> /usr/libexec/ibus-x11 Uncommitted ibus XIM fontend/agend >>>> >>>> /usr/libexec/ibus-gconf Uncommitted config backend by gconf-python >>>> /usr/libexec/ibus-ui-gtk Uncommitted panel GUI by pygtk >>> There is no /usr/libexec in Solaris: either belongs into /usr/lib (or >>> /usr/lib/ibus) or /usr/share/ibus if architecture independent. >> In order to reduce Solaris patches, we followed the original directories. >> If /usr/libexec/ is not allowed, we will change them to /usr/lib/ibus/ibus-*. > > Fine, thanks. I've updated the material. > >>>> /usr/lib/libibus.so Uncommitted ibus C binding SDK library >>> That's only the compilation symlink. What's the real filename and SONAME? >> /usr/lib/libibus.so.0.0.0 >> will update the material. > > The SONAME will more likely be libibus.so.0 in this case. Please check > with dump -Lv. The SONAME was libibus.so.0. I've updated the material. > >>>> /usr/libexec/ Uncommitted IME launcher >>>> ibus-engine- >>>> /usr/libexec/ Uncommitted IME setup launcher >>>> ibus-setup- >>> Same as above: no /usr/libexec. >> If /usr/libexec/ is not allowed, we will change them to >> >> /usr/lib/ibus/ibus-engine- (I know this is better) >> /usr/lib/ibus/ibus-setup- (I know this is better) >> or >> /usr/lib/ibus-engine- >> /usr/lib/ibus-setup- > > Please use the first variant to avoid needlessly cluttering /usr/lib. OK. I've updated the material. > >>>> /usr/share/ibus- Uncommitted IME modules >>>> *IME_NAME is among [anthy, chewing, hangul, m17n, pinyin, table] >>> Why the mess: better move this to /usr/share/ibus/ to avoid >>> cluttering /usr/share even more. >>> >>>> /usr/share/ibus-table/* Uncommitted ibus-table engine and >>>> code-tables >>> Same here: better /usr/share/ibus/table or some such. >> In fact I've been feeling the same way, but again, we followed the >> original directories to reduce Solaris patches. > > Understood, but perhaps the changes can even be fed upstream? At least in > Solaris, there seems to be a strong preference to have exactly one > directory in /usr/share for each application, otherwise the directory > quickly becomes almost impossible to browse. > >> I understand these changes are not mandatory, but better to have. > > Some of them might be optional, but at the change away from /usr/libexec is > mandatory. > >> I'll discuss with the project team and come back. > > Excellent, thanks. /usr/share/ibus/ has been used for ibus core files. We examined /usr/share/ibus-IME/, but unlike /usr/libexe change it's not easy. It seems we need to create several patches for each IME and ibus core. The project team would like to keep the current directories at least for this time. Thanks, Fuyuki > > Rainer > > ----------------------------------------------------------------------------- > Rainer Orth, Center for Biotechnology, Bielefeld University From ro@techfak.uni-bielefeld.de Fri Sep 25 06:40:48 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8PDemQ4004656 for ; Fri, 25 Sep 2009 06:40:48 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n8PDekTO002392; Fri, 25 Sep 2009 06:40:46 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQJ00L014NYNB00@nwk-avmta-2.sfbay.sun.com>; Fri, 25 Sep 2009 06:40:46 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQJ00LBC4NXE400@nwk-avmta-2.sfbay.sun.com>; Fri, 25 Sep 2009 06:40:45 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8PDdCco021620; Fri, 25 Sep 2009 13:40:45 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay13i.sun.com with ESMTP id BT-MMP-2625916; Fri, 25 Sep 2009 13:40:44 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-35348899; Fri, 25 Sep 2009 13:40:44 +0000 (Z) Received: from smarthost.TechFak.Uni-Bielefeld.DE ([129.70.137.17] [129.70.137.17]) by relay1i.sun.com with ESMTP id BT-MMP-11806339; Fri, 25 Sep 2009 13:40:44 +0000 (Z) Received: from komagatake.TechFak.Uni-Bielefeld.DE (komagatake.TechFak.Uni-Bielefeld.DE [129.70.137.126]) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTP id 533B8B1; Fri, 25 Sep 2009 15:40:43 +0200 (CEST) Received: (from ro@localhost) by komagatake.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) id n8PDehU01096; Fri, 25 Sep 2009 15:40:43 +0200 (MEST) Date: Fri, 25 Sep 2009 15:40:42 +0200 (MEST) From: Rainer Orth Subject: Re: iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009] In-reply-to: <4ABB7081.4030406@sun.com> To: Fuyuki Hasegawa - Sun Microsystems Cc: PSARC-ext@sun.com, gto@sun.com Message-id: <19132.51290.54211.316482@komagatake.TechFak.Uni-Bielefeld.DE> MIME-version: 1.0 X-Mailer: VM 6.62 under Emacs 19.34.1 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> <4AB399FA.4060406@sun.com> <19123.41339.606980.304455@komagatake.TechFak.Uni-Bielefeld.DE> <4ABB7081.4030406@sun.com> Status: RO Content-Length: 2841 Fuyuki Hasegawa - Sun Microsystems writes: > Rainer Orth wrote: > > Fuyuki, > > > >>>> 4.5. Interfaces: > >>>> > >>>> INTERFACE NAME STABILITY NOTE > >>>> ----------------------------------------------------------------------- > >>>> /usr/bin/ibus-daemon Uncommitted message bus daemon > >>> How is this started? Via SMF at boot? If so, we need FMRI etc. Can it > >>> ever be invoked manually be a regular user? If not, it belongs into > >>> /usr/sbin (if manually invoked by sysadmins) of /usr/lib. > >> It's user process started via gnome-session(1). > > > > but if there is no reason to start this manually, it's probably better > > located in /usr/lib/ibus. > > As I replied to Joerg, we'd like to keep /usr/bin/ibus-daemon. ok. > (FYI, iiim daemons also have been located in /usr/bin) Which isn't necessarily a good reason. It may just be an error gone unnoticed :-) > >>>> /usr/share/ibus- Uncommitted IME modules > >>>> *IME_NAME is among [anthy, chewing, hangul, m17n, pinyin, table] > >>> Why the mess: better move this to /usr/share/ibus/ to avoid > >>> cluttering /usr/share even more. > >>> > >>>> /usr/share/ibus-table/* Uncommitted ibus-table engine and > >>>> code-tables > >>> Same here: better /usr/share/ibus/table or some such. > >> In fact I've been feeling the same way, but again, we followed the > >> original directories to reduce Solaris patches. > > > > Understood, but perhaps the changes can even be fed upstream? At least in > > Solaris, there seems to be a strong preference to have exactly one > > directory in /usr/share for each application, otherwise the directory > > quickly becomes almost impossible to browse. > > > >> I understand these changes are not mandatory, but better to have. > > > > Some of them might be optional, but at the change away from /usr/libexec is > > mandatory. > > > >> I'll discuss with the project team and come back. > > > > Excellent, thanks. > > /usr/share/ibus/ has been used for ibus core files. > We examined /usr/share/ibus-IME/, but unlike /usr/libexe change > it's not easy. It seems we need to create several patches for > each IME and ibus core. It seems to me that this structure violates the GNU Coding Standards, so an appropriate patch may well be acceptable upstream. > The project team would like to keep the current directories > at least for this time. It's not for me to decide, but perhaps discuss this with upstream. If there's a chance that patches to effect that would be accepted, it would be good to change this before integration. Thanks. Rainer ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University From Fuyuki.Hasegawa@sun.com Mon Sep 28 19:44:54 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8T2irjw007357 for ; Mon, 28 Sep 2009 19:44:53 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n8T2ipGj018039; Tue, 29 Sep 2009 10:44:52 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQP00901OYRA500@nwk-avmta-1.sfbay.Sun.COM>; Mon, 28 Sep 2009 19:44:51 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQP003KFOYK6590@nwk-avmta-1.sfbay.Sun.COM>; Mon, 28 Sep 2009 19:44:50 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8T2iiGn019253; Tue, 29 Sep 2009 02:44:44 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQP00200OSL5L00@mail-apac.sun.com>; Tue, 29 Sep 2009 10:44:44 +0800 (SGT) Received: from [129.158.28.135] ([unknown] [129.158.28.135]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQP00AVVOYI3LC0@mail-apac.sun.com>; Tue, 29 Sep 2009 10:44:44 +0800 (SGT) Date: Tue, 29 Sep 2009 11:44:38 +0900 From: Fuyuki Hasegawa - Sun Microsystems Subject: Re: iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009] In-reply-to: <19132.51290.54211.316482@komagatake.TechFak.Uni-Bielefeld.DE> Sender: Fuyuki.Hasegawa@sun.com To: Rainer Orth Cc: PSARC-ext@sun.com, gto@sun.com Message-id: <4AC17496.1020800@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> <4AB399FA.4060406@sun.com> <19123.41339.606980.304455@komagatake.TechFak.Uni-Bielefeld.DE> <4ABB7081.4030406@sun.com> <19132.51290.54211.316482@komagatake.TechFak.Uni-Bielefeld.DE> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 837 Rainer Orth wrote: >> /usr/share/ibus/ has been used for ibus core files. >> We examined /usr/share/ibus-IME/, but unlike /usr/libexe change >> it's not easy. It seems we need to create several patches for >> each IME and ibus core. > > It seems to me that this structure violates the GNU Coding Standards, so an > appropriate patch may well be acceptable upstream. > >> The project team would like to keep the current directories >> at least for this time. > > It's not for me to decide, but perhaps discuss this with upstream. If > there's a chance that patches to effect that would be accepted, it would be > good to change this before integration. The upstream says configurable IME directory will be examined in the newer version, ibus1.2~. For this ibus1.1 integration, we would like to keep the current dirs. Thanks, Fuyuki From ro@techfak.uni-bielefeld.de Tue Sep 29 06:09:38 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8TD9aED028629 for ; Tue, 29 Sep 2009 06:09:37 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8TD9Nn7022025; Tue, 29 Sep 2009 14:09:34 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQQ00G2RHVWLP00@nwk-avmta-2.sfbay.sun.com>; Tue, 29 Sep 2009 06:09:32 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQQ008EQHVV4IB0@nwk-avmta-2.sfbay.sun.com>; Tue, 29 Sep 2009 06:09:31 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8TCa82w028395; Tue, 29 Sep 2009 13:09:31 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay44i.sun.com with ESMTP id BT-MMP-457761; Tue, 29 Sep 2009 13:09:28 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-6505186; Tue, 29 Sep 2009 13:09:28 +0000 (Z) Received: from smarthost.TechFak.Uni-Bielefeld.DE ([129.70.137.17] [129.70.137.17]) by relay4i.sun.com with ESMTP id BT-MMP-1940479; Tue, 29 Sep 2009 13:09:27 +0000 (Z) Received: from komagatake.TechFak.Uni-Bielefeld.DE (komagatake.TechFak.Uni-Bielefeld.DE [129.70.137.126]) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTP id 52E1A8E; Tue, 29 Sep 2009 15:09:27 +0200 (CEST) Received: (from ro@localhost) by komagatake.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) id n8TD9RC06330; Tue, 29 Sep 2009 15:09:27 +0200 (MEST) Date: Tue, 29 Sep 2009 15:09:25 +0200 (MEST) From: Rainer Orth Subject: Re: iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009] In-reply-to: <4AC17496.1020800@sun.com> To: Fuyuki Hasegawa - Sun Microsystems Cc: PSARC-ext@sun.com, gto@sun.com Message-id: <19138.1797.849273.206276@komagatake.TechFak.Uni-Bielefeld.DE> MIME-version: 1.0 X-Mailer: VM 6.62 under Emacs 19.34.1 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.304sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> <4AB399FA.4060406@sun.com> <19123.41339.606980.304455@komagatake.TechFak.Uni-Bielefeld.DE> <4ABB7081.4030406@sun.com> <19132.51290.54211.316482@komagatake.TechFak.Uni-Bielefeld.DE> <4AC17496.1020800@sun.com> Status: RO Content-Length: 1089 Fuyuki Hasegawa - Sun Microsystems writes: > Rainer Orth wrote: > >> /usr/share/ibus/ has been used for ibus core files. > >> We examined /usr/share/ibus-IME/, but unlike /usr/libexe change > >> it's not easy. It seems we need to create several patches for > >> each IME and ibus core. > > > > It seems to me that this structure violates the GNU Coding Standards, so an > > appropriate patch may well be acceptable upstream. > > > >> The project team would like to keep the current directories > >> at least for this time. > > > > It's not for me to decide, but perhaps discuss this with upstream. If > > there's a chance that patches to effect that would be accepted, it would be > > good to change this before integration. > > The upstream says configurable IME directory will be examined in the newer > version, ibus1.2~. For this ibus1.1 integration, we would like to keep > the current dirs. ok, thanks for following up on this. Rainer ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University From Sebastien.Roy@sun.com Wed Sep 30 07:40:45 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8UEei1S016043 for ; Wed, 30 Sep 2009 07:40:45 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8UEefFX029250; Wed, 30 Sep 2009 15:40:43 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQS00E05GRVRT00@nwk-avmta-2.sfbay.sun.com>; Wed, 30 Sep 2009 07:40:43 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQS0071IGRUG3A0@nwk-avmta-2.sfbay.sun.com>; Wed, 30 Sep 2009 07:40:42 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8UEeg0x029351; Wed, 30 Sep 2009 14:40:42 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQS00J00GJTKO00@mail-amer.sun.com>; Wed, 30 Sep 2009 08:40:42 -0600 (MDT) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQS001Q4GRNVP90@mail-amer.sun.com>; Wed, 30 Sep 2009 08:40:35 -0600 (MDT) Date: Wed, 30 Sep 2009 10:38:20 -0400 From: Sebastien Roy Subject: Re: iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009] In-reply-to: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> Sender: Sebastien.Roy@sun.com To: Fuyuki Hasegawa Cc: PSARC-ext@sun.com, gto@sun.com Message-id: <1254321500.19199.34.camel@strat> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> Status: RO Content-Length: 3695 On Thu, 2009-09-17 at 03:54 -0700, Fuyuki Hasegawa wrote: > Integrating ibus does not mean to obsolete iiimf or scim, but we would > put them in maintenance state. What is "maintenance state"? If you mean that they will remain supported but that ibus is the preferred method, then making them "Obsolete" in the ARC sense would seem like the right thing to do. Is that what you intend? See http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/. > 4.1.2 Switching between iBus, SCIM and IIIMF > iBus services are started by gnome-session(1). User could > simply enable > or disable the service via gnome-session-properties(1). With > the help of > startup scripts shipped with iiimf and scim, user could set > GTK_IM_MODULE > environment variable in $HOME/.profile to select iBus, IIIMF or > SCIM. Is the GTK_IM_MODULE variable an interface exported by this case, or was it part of a previous case? > We plan to change default IM framework from iiimf to ibus in Solaris > Next. So this case does not change the default IM framework. A future case will do that. Is that accurate? > 4.5. Interfaces: > > INTERFACE NAME STABILITY NOTE > ----------------------------------------------------------------------- > /usr/bin/ibus-daemon Uncommitted message bus daemon > /usr/bin/ibus-setup Uncommitted setup launcher > /usr/libexec/ibus-x11 Uncommitted ibus XIM fontend/agend > > /usr/libexec/ibus-gconf Uncommitted config backend by gconf-python > /usr/libexec/ibus-ui-gtk Uncommitted panel GUI by pygtk > > /usr/lib/libibus.so Uncommitted ibus C binding SDK library > /usr/include/ibus-1.0/* Uncommitted ibus C binding header files > > /usr/share/gtk-doc/html/ Uncommitted ibus developor documents > ibus/* > > /usr/lib/python2.6/ Uncommitted ibus Python binding > site-packages/ibus/* > > /usr/lib/gtk-2.0/2.10.0/ Uncommitted ibus gtk-im-module > immodules/im-ibus*.so > /usr/lib/{amd64,sparcv9}/ Uncommitted 64bits version of ibus > gtk-2.0/2.10.0/immodules/ gtk-im-module > im-ibus*.so > > /usr/share/ibus/setup/* Uncommitted ibus-setup modules > /usr/share/ibus/ui/gtk/* Uncommitted panel GUI by pygtk > > /usr/share/ibus/ Uncommitted ibus components registry > components/* like ibus-gconf, ibus-ui-gtk > and IMEs > > /usr/libexec/ Uncommitted IME launcher > ibus-engine- > /usr/libexec/ Uncommitted IME setup launcher > ibus-setup- > /usr/share/ibus- Uncommitted IME modules > *IME_NAME is among [anthy, chewing, hangul, m17n, pinyin, table] > > /usr/share/ibus-table/* Uncommitted ibus-table engine and > code-tables I suspect that many of the above are not actually interfaces at all, but rather internal components of the implementation. No user or application should be using most of these things directly, so Uncommitted seems inappropriate. Can you clarify which interfaces you expect users and applications to interact with directly and give those appropriate stabilities. Everything else should probably be some kind of private or not an interface at all. > 4.12. Dependencies: > We need python2.6 to be the default in OpenSolaris. What is the specific case dependency? -Seb From Sebastien.Roy@sun.com Wed Sep 30 12:45:45 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8UJjiQ2029068 for ; Wed, 30 Sep 2009 12:45:45 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8UJjN5H015057; Wed, 30 Sep 2009 20:45:43 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQS00711UW5QJ00@nwk-avmta-2.sfbay.sun.com>; Wed, 30 Sep 2009 12:45:41 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQS005W3UW3IM80@nwk-avmta-2.sfbay.sun.com>; Wed, 30 Sep 2009 12:45:39 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8UJjdCi018794; Wed, 30 Sep 2009 19:45:39 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQS00K00UMX2K00@mail-amer.sun.com>; Wed, 30 Sep 2009 13:45:39 -0600 (MDT) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQS004YRUVOSF60@mail-amer.sun.com>; Wed, 30 Sep 2009 13:45:25 -0600 (MDT) Date: Wed, 30 Sep 2009 15:43:08 -0400 From: Sebastien Roy Subject: Re: iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009] In-reply-to: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> Sender: Sebastien.Roy@sun.com To: Fuyuki Hasegawa Cc: PSARC-ext@sun.com, gto@sun.com Message-id: <1254339788.19199.116.camel@strat> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> Status: RO Content-Length: 462 On Thu, 2009-09-17 at 03:54 -0700, Fuyuki Hasegawa wrote: > I'm submitting this fast-track for myself (IM group), scheduled to timeout > at 09/24/2009. FYI, I requested more time on this case during today's PSARC meeting as it had yet to receive a +1 from an ARC member. I've posted some questions based on my review. Please extend the timer for another few days to accommodate for for the resolution of those issues (which are all relatively minor). -Seb From Fuyuki.Hasegawa@sun.com Thu Oct 1 03:47:10 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n91Al9k4001898 for ; Thu, 1 Oct 2009 03:47:09 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n91Al3Lv025190; Thu, 1 Oct 2009 04:47:09 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQU00H050MK8B00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 01 Oct 2009 03:47:08 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQU005JG0MJU890@nwk-avmta-1.sfbay.Sun.COM>; Thu, 01 Oct 2009 03:47:08 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n91Al7Wg020021; Thu, 01 Oct 2009 10:47:07 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQU00H000GUTB00@mail-apac.sun.com>; Thu, 01 Oct 2009 18:47:07 +0800 (SGT) Received: from [129.158.28.135] ([unknown] [129.158.28.135]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQU001OC0MH9P30@mail-apac.sun.com>; Thu, 01 Oct 2009 18:47:06 +0800 (SGT) Date: Thu, 01 Oct 2009 19:47:02 +0900 From: Fuyuki Hasegawa - Sun Microsystems Subject: Re: iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009] In-reply-to: <1254321500.19199.34.camel@strat> Sender: Fuyuki.Hasegawa@sun.com To: Sebastien Roy Cc: Fuyuki Hasegawa , PSARC-ext@sun.com, gto@sun.com Message-id: <4AC488A6.7000507@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> <1254321500.19199.34.camel@strat> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 4904 Sebastien Roy wrote: > On Thu, 2009-09-17 at 03:54 -0700, Fuyuki Hasegawa wrote: >> Integrating ibus does not mean to obsolete iiimf or scim, but we would >> put them in maintenance state. > > What is "maintenance state"? If you mean that they will remain > supported but that ibus is the preferred method, then making them > "Obsolete" in the ARC sense would seem like the right thing to do. Is > that what you intend? See > http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/. The "maintenance state" means that we will stop feature work and unlikely to fix low priority bugs. iiimf is still default IM for OpenSolaris 2010.02. It seems we should change iiimf or scim interfaces to Obsolete when we switch default IM to ibus for Solaris Next. >> 4.1.2 Switching between iBus, SCIM and IIIMF >> iBus services are started by gnome-session(1). User could >> simply enable >> or disable the service via gnome-session-properties(1). With >> the help of >> startup scripts shipped with iiimf and scim, user could set >> GTK_IM_MODULE >> environment variable in $HOME/.profile to select iBus, IIIMF or >> SCIM. > > Is the GTK_IM_MODULE variable an interface exported by this case, or was > it part of a previous case? GTK_IM_MODULE variable comes from GNOME itself. It's mentioned in gtk-query-immodules-2.0(1) manpage. I looked at GNOME 2.14 ARC materials in /shared/sac/LSARC/2006/202/, but couldn't find out the interface taxonomy. > >> We plan to change default IM framework from iiimf to ibus in Solaris >> Next. > > So this case does not change the default IM framework. A future case > will do that. Is that accurate? Yes. > >> 4.5. Interfaces: >> >> INTERFACE NAME STABILITY NOTE >> ----------------------------------------------------------------------- >> /usr/bin/ibus-daemon Uncommitted message bus daemon >> /usr/bin/ibus-setup Uncommitted setup launcher >> /usr/libexec/ibus-x11 Uncommitted ibus XIM fontend/agend >> >> /usr/libexec/ibus-gconf Uncommitted config backend by gconf-python >> /usr/libexec/ibus-ui-gtk Uncommitted panel GUI by pygtk >> >> /usr/lib/libibus.so Uncommitted ibus C binding SDK library >> /usr/include/ibus-1.0/* Uncommitted ibus C binding header files >> >> /usr/share/gtk-doc/html/ Uncommitted ibus developor documents >> ibus/* >> >> /usr/lib/python2.6/ Uncommitted ibus Python binding >> site-packages/ibus/* >> >> /usr/lib/gtk-2.0/2.10.0/ Uncommitted ibus gtk-im-module >> immodules/im-ibus*.so >> /usr/lib/{amd64,sparcv9}/ Uncommitted 64bits version of ibus >> gtk-2.0/2.10.0/immodules/ gtk-im-module >> im-ibus*.so >> >> /usr/share/ibus/setup/* Uncommitted ibus-setup modules >> /usr/share/ibus/ui/gtk/* Uncommitted panel GUI by pygtk >> >> /usr/share/ibus/ Uncommitted ibus components registry >> components/* like ibus-gconf, ibus-ui-gtk >> and IMEs >> >> /usr/libexec/ Uncommitted IME launcher >> ibus-engine- >> /usr/libexec/ Uncommitted IME setup launcher >> ibus-setup- >> /usr/share/ibus- Uncommitted IME modules >> *IME_NAME is among [anthy, chewing, hangul, m17n, pinyin, table] >> >> /usr/share/ibus-table/* Uncommitted ibus-table engine and >> code-tables > > I suspect that many of the above are not actually interfaces at all, but > rather internal components of the implementation. No user or > application should be using most of these things directly, so > Uncommitted seems inappropriate. Can you clarify which interfaces you > expect users and applications to interact with directly and give those > appropriate stabilities. Everything else should probably be some kind > of private or not an interface at all. I see. It seems Project Private is more appropriate for all of them except the following. >> /usr/bin/ibus-daemon Uncommitted message bus daemon >> /usr/bin/ibus-setup Uncommitted setup launcher Since ibus is fairly new software and being actively developed/enhanced by the community. I think Volatile would be more appropriate for the two interfaces. I've updated the material. > >> 4.12. Dependencies: >> We need python2.6 to be the default in OpenSolaris. > > What is the specific case dependency? I don't know what python2.6 API ibus depends on. We heard the python default will be changed from 2.4 to 2.6 in near future, but don't know the actual target at this point. Thanks, Fuyuki From Fuyuki.Hasegawa@sun.com Thu Oct 1 04:35:23 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n91BZM2A002673 for ; Thu, 1 Oct 2009 04:35:22 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n91BZKO6010315; Thu, 1 Oct 2009 12:35:21 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQU00H012UW4600@brm-avmta-1.central.sun.com>; Thu, 01 Oct 2009 05:35:20 -0600 (MDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQU00BWS2UV0N40@brm-avmta-1.central.sun.com>; Thu, 01 Oct 2009 05:35:20 -0600 (MDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n91BZJjg021209; Thu, 01 Oct 2009 11:35:19 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQU00A002NYAV00@mail-apac.sun.com>; Thu, 01 Oct 2009 19:35:18 +0800 (SGT) Received: from [129.158.28.135] ([unknown] [129.158.28.135]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQU001G32UU9P40@mail-apac.sun.com>; Thu, 01 Oct 2009 19:35:18 +0800 (SGT) Date: Thu, 01 Oct 2009 20:35:14 +0900 From: Fuyuki Hasegawa - Sun Microsystems Subject: Re: iBus integration [PSARC/2009/499] FastTrack timeout 10/02/2009 In-reply-to: <1254339788.19199.116.camel@strat> Sender: Fuyuki.Hasegawa@sun.com To: Sebastien Roy Cc: PSARC-ext@sun.com, gto@sun.com Message-id: <4AC493F2.6000308@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> <1254339788.19199.116.camel@strat> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1298 Sebastien Roy wrote: > On Thu, 2009-09-17 at 03:54 -0700, Fuyuki Hasegawa wrote: >> I'm submitting this fast-track for myself (IM group), scheduled to timeout >> at 09/24/2009. > > FYI, I requested more time on this case during today's PSARC meeting as > it had yet to receive a +1 from an ARC member. I've posted some > questions based on my review. Please extend the timer for another few > days to accommodate for for the resolution of those issues (which are > all relatively minor). Hi Sebastien, I thought fast-track will automatically be approved without explicit +1 if there is no objection during review period, usually 1 week. Anyway from the last meeting minutes, I knew the timer of this case was extended till 09/30. Since we didn't receive further questions/comments other than Rainer until now, I expected the case would be approved today. We have been planning to integrate ibus into snv_125 where last build before the limited contents builds. The delivery due for a new pkg was today. I've requested to WOS RE to delay the integration till 10/5 where final delivery deadline for all pkgs. To meet the snv_125 delivery due and also since the issues were relatively minor, I would like to extend the timer till 10/02/2009 (although it extends only two days). Thanks, Fuyuki From Sebastien.Roy@SUN.COM Thu Oct 1 04:44:44 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n91BihY6002750 for ; Thu, 1 Oct 2009 04:44:43 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n91Bif13015049; Thu, 1 Oct 2009 12:44:42 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQU00I073AH1300@brm-avmta-1.central.sun.com>; Thu, 01 Oct 2009 05:44:41 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQU00BRN3AH0N50@brm-avmta-1.central.sun.com>; Thu, 01 Oct 2009 05:44:41 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n91Bifg7007309; Thu, 01 Oct 2009 11:44:41 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQU00I0037B3700@mail-amer.sun.com>; Thu, 01 Oct 2009 05:44:40 -0600 (MDT) Received: from [192.168.1.2] ([unknown] [173.76.19.212]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQU00HKW3AGKI00@mail-amer.sun.com>; Thu, 01 Oct 2009 05:44:40 -0600 (MDT) Date: Thu, 01 Oct 2009 07:44:39 -0400 From: Sebastien Roy Subject: Re: iBus integration [PSARC/2009/499] FastTrack timeout 10/02/2009 In-reply-to: <4AC493F2.6000308@sun.com> Sender: Sebastien.Roy@SUN.COM To: Fuyuki Hasegawa - Sun Microsystems Cc: PSARC-ext@SUN.COM, gto@SUN.COM Message-id: <1254397479.12502.6.camel@seb> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> <1254339788.19199.116.camel@strat> <4AC493F2.6000308@sun.com> Status: RO Content-Length: 1895 On Thu, 2009-10-01 at 20:35 +0900, Fuyuki Hasegawa - Sun Microsystems wrote: > Sebastien Roy wrote: > > On Thu, 2009-09-17 at 03:54 -0700, Fuyuki Hasegawa wrote: > >> I'm submitting this fast-track for myself (IM group), scheduled to timeout > >> at 09/24/2009. > > > > FYI, I requested more time on this case during today's PSARC meeting as > > it had yet to receive a +1 from an ARC member. I've posted some > > questions based on my review. Please extend the timer for another few > > days to accommodate for for the resolution of those issues (which are > > all relatively minor). > > Hi Sebastien, > > I thought fast-track will automatically be approved without explicit +1 > if there is no objection during review period, usually 1 week. Fast-tracks require a member review within the 1 week timer, otherwise the case is automatically rejected as not reviewed. At least, that's the defined process. A +1 is required. In this case, I had noticed that the one week timer had expired without the required +1, but I'm offering my review in order to prevent this case from being automatically rejected. > Anyway from the last meeting minutes, I knew the timer of this case was > extended till 09/30. Since we didn't receive further questions/comments > other than Rainer until now, I expected the case would be approved today. > > We have been planning to integrate ibus into snv_125 where last build > before the limited contents builds. The delivery due for a new pkg > was today. I've requested to WOS RE to delay the integration till > 10/5 where final delivery deadline for all pkgs. > > To meet the snv_125 delivery due and also since the issues were > relatively minor, I would like to extend the timer till 10/02/2009 > (although it extends only two days). Yes, that's fine. I'll follow-up on your response to my comments. This shouldn't last past 10/02. Thanks, -Seb From Sebastien.Roy@sun.com Thu Oct 1 05:00:59 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n91C0xbv003223 for ; Thu, 1 Oct 2009 05:00:59 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n91C0wcA019680; Thu, 1 Oct 2009 05:00:59 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQU00M0141M1F00@nwk-avmta-2.sfbay.sun.com>; Thu, 01 Oct 2009 05:00:58 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQU00JUA41IRA20@nwk-avmta-2.sfbay.sun.com>; Thu, 01 Oct 2009 05:00:54 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n91C0sex027174; Thu, 01 Oct 2009 12:00:54 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQU003003SPRJ00@mail-amer.sun.com>; Thu, 01 Oct 2009 06:00:53 -0600 (MDT) Received: from [192.168.1.2] ([unknown] [173.76.19.212]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQU00HLB41BKI40@mail-amer.sun.com>; Thu, 01 Oct 2009 06:00:48 -0600 (MDT) Date: Thu, 01 Oct 2009 08:00:47 -0400 From: Sebastien Roy Subject: Re: iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009] In-reply-to: <4AC488A6.7000507@sun.com> Sender: Sebastien.Roy@sun.com To: Fuyuki Hasegawa - Sun Microsystems Cc: Fuyuki Hasegawa , PSARC-ext@sun.com, gto@sun.com Message-id: <1254398447.12502.19.camel@seb> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> <1254321500.19199.34.camel@strat> <4AC488A6.7000507@sun.com> Status: RO Content-Length: 5743 On Thu, 2009-10-01 at 19:47 +0900, Fuyuki Hasegawa - Sun Microsystems wrote: > Sebastien Roy wrote: > > On Thu, 2009-09-17 at 03:54 -0700, Fuyuki Hasegawa wrote: > >> Integrating ibus does not mean to obsolete iiimf or scim, but we would > >> put them in maintenance state. > > > > What is "maintenance state"? If you mean that they will remain > > supported but that ibus is the preferred method, then making them > > "Obsolete" in the ARC sense would seem like the right thing to do. Is > > that what you intend? See > > http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/. > > The "maintenance state" means that we will stop feature work > and unlikely to fix low priority bugs. > iiimf is still default IM for OpenSolaris 2010.02. > It seems we should change iiimf or scim interfaces to Obsolete > when we switch default IM to ibus for Solaris Next. I see, that works for me. > >> 4.1.2 Switching between iBus, SCIM and IIIMF > >> iBus services are started by gnome-session(1). User could > >> simply enable > >> or disable the service via gnome-session-properties(1). With > >> the help of > >> startup scripts shipped with iiimf and scim, user could set > >> GTK_IM_MODULE > >> environment variable in $HOME/.profile to select iBus, IIIMF or > >> SCIM. > > > > Is the GTK_IM_MODULE variable an interface exported by this case, or was > > it part of a previous case? > > GTK_IM_MODULE variable comes from GNOME itself. > It's mentioned in gtk-query-immodules-2.0(1) manpage. > I looked at GNOME 2.14 ARC materials in /shared/sac/LSARC/2006/202/, > but couldn't find out the interface taxonomy. Okay, that's fine. > > > >> 4.5. Interfaces: > >> > >> INTERFACE NAME STABILITY NOTE > >> ----------------------------------------------------------------------- > >> /usr/bin/ibus-daemon Uncommitted message bus daemon > >> /usr/bin/ibus-setup Uncommitted setup launcher > >> /usr/libexec/ibus-x11 Uncommitted ibus XIM fontend/agend > >> > >> /usr/libexec/ibus-gconf Uncommitted config backend by gconf-python > >> /usr/libexec/ibus-ui-gtk Uncommitted panel GUI by pygtk > >> > >> /usr/lib/libibus.so Uncommitted ibus C binding SDK library > >> /usr/include/ibus-1.0/* Uncommitted ibus C binding header files > >> > >> /usr/share/gtk-doc/html/ Uncommitted ibus developor documents > >> ibus/* > >> > >> /usr/lib/python2.6/ Uncommitted ibus Python binding > >> site-packages/ibus/* > >> > >> /usr/lib/gtk-2.0/2.10.0/ Uncommitted ibus gtk-im-module > >> immodules/im-ibus*.so > >> /usr/lib/{amd64,sparcv9}/ Uncommitted 64bits version of ibus > >> gtk-2.0/2.10.0/immodules/ gtk-im-module > >> im-ibus*.so > >> > >> /usr/share/ibus/setup/* Uncommitted ibus-setup modules > >> /usr/share/ibus/ui/gtk/* Uncommitted panel GUI by pygtk > >> > >> /usr/share/ibus/ Uncommitted ibus components registry > >> components/* like ibus-gconf, ibus-ui-gtk > >> and IMEs > >> > >> /usr/libexec/ Uncommitted IME launcher > >> ibus-engine- > >> /usr/libexec/ Uncommitted IME setup launcher > >> ibus-setup- > >> /usr/share/ibus- Uncommitted IME modules > >> *IME_NAME is among [anthy, chewing, hangul, m17n, pinyin, table] > >> > >> /usr/share/ibus-table/* Uncommitted ibus-table engine and > >> code-tables > > > > I suspect that many of the above are not actually interfaces at all, but > > rather internal components of the implementation. No user or > > application should be using most of these things directly, so > > Uncommitted seems inappropriate. Can you clarify which interfaces you > > expect users and applications to interact with directly and give those > > appropriate stabilities. Everything else should probably be some kind > > of private or not an interface at all. > > I see. It seems Project Private is more appropriate for all of them > except the following. > > >> /usr/bin/ibus-daemon Uncommitted message bus daemon > >> /usr/bin/ibus-setup Uncommitted setup launcher > > Since ibus is fairly new software and being actively developed/enhanced > by the community. I think Volatile would be more appropriate for the > two interfaces. Do you expect users to call /usr/bin/ibus-daemon directly, or do you only ever expect it to be started from private scripts indirectly by gnome-session? If it's the former, then what you have is fine. If it's the latter, then it probably belongs in /usr/lib along with the other private executables, and it should be Project Private along with the others. Otherwise, I agree with your assessment of the other interfaces. > > > >> 4.12. Dependencies: > >> We need python2.6 to be the default in OpenSolaris. > > > > What is the specific case dependency? > > I don't know what python2.6 API ibus depends on. > We heard the python default will be changed from 2.4 to 2.6 > in near future, but don't know the actual target at this point. According to PSARC/2009/043, you must not depend on the default version in /usr/bin, but rather on a specific version (e.g., /usr/bin/python2.6). That would relieve any dependency on a particular version becoming the default, and would prevent breakage of your feature if the default version changes and introduced incompatibilities. -Seb From Fuyuki.Hasegawa@sun.com Thu Oct 1 05:40:17 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n91CeHiY003415 for ; Thu, 1 Oct 2009 05:40:17 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n91CeFLR016628; Thu, 1 Oct 2009 05:40:16 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQU0000J5V3EJ00@brm-avmta-1.central.sun.com>; Thu, 01 Oct 2009 06:40:15 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQU00BD15V2FNE0@brm-avmta-1.central.sun.com>; Thu, 01 Oct 2009 06:40:15 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n91CeDd5027467; Thu, 01 Oct 2009 12:40:13 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQU009005NN4X00@mail-apac.sun.com>; Thu, 01 Oct 2009 20:40:13 +0800 (SGT) Received: from [129.158.28.135] ([unknown] [129.158.28.135]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQU002CB5V01D00@mail-apac.sun.com>; Thu, 01 Oct 2009 20:40:13 +0800 (SGT) Date: Thu, 01 Oct 2009 21:40:08 +0900 From: Fuyuki Hasegawa - Sun Microsystems Subject: Re: iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009] In-reply-to: <1254398447.12502.19.camel@seb> Sender: Fuyuki.Hasegawa@sun.com To: Sebastien Roy Cc: Fuyuki Hasegawa , PSARC-ext@sun.com, gto@sun.com Message-id: <4AC4A328.3000509@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> <1254321500.19199.34.camel@strat> <4AC488A6.7000507@sun.com> <1254398447.12502.19.camel@seb> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1320 Thanks for your prompt reply. :) Sebastien Roy wrote: > Do you expect users to call /usr/bin/ibus-daemon directly, or do you > only ever expect it to be started from private scripts indirectly by > gnome-session? If it's the former, then what you have is fine. If it's > the latter, then it probably belongs in /usr/lib along with the other > private executables, and it should be Project Private along with the > others. Otherwise, I agree with your assessment of the other > interfaces. ibus-daemon would be called from a custom WM or a desktop other than Gnome. >>>> 4.12. Dependencies: >>>> We need python2.6 to be the default in OpenSolaris. >>> What is the specific case dependency? >> I don't know what python2.6 API ibus depends on. >> We heard the python default will be changed from 2.4 to 2.6 >> in near future, but don't know the actual target at this point. > > According to PSARC/2009/043, you must not depend on the default version > in /usr/bin, but rather on a specific version > (e.g., /usr/bin/python2.6). That would relieve any dependency on a > particular version becoming the default, and would prevent breakage of > your feature if the default version changes and introduced > incompatibilities. OK, we will make ibus independent on the python default version. Thanks, Fuyuki From Sebastien.Roy@Sun.COM Thu Oct 1 06:25:44 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n91DPhuO004080 for ; Thu, 1 Oct 2009 06:25:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n91DPeir017203; Thu, 1 Oct 2009 14:25:42 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQU0020V7YTT300@nwk-avmta-2.sfbay.sun.com>; Thu, 01 Oct 2009 06:25:41 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQU00JI07YRRE90@nwk-avmta-2.sfbay.sun.com>; Thu, 01 Oct 2009 06:25:39 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n91DPd0w010771; Thu, 01 Oct 2009 13:25:39 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQU00M007PODF00@mail-amer.sun.com>; Thu, 01 Oct 2009 07:25:39 -0600 (MDT) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQU00HMF7YQ0J90@mail-amer.sun.com>; Thu, 01 Oct 2009 07:25:39 -0600 (MDT) Date: Thu, 01 Oct 2009 09:23:22 -0400 From: Sebastien Roy Subject: Re: iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009] In-reply-to: <4AC4A328.3000509@sun.com> Sender: Sebastien.Roy@Sun.COM To: Fuyuki Hasegawa - Sun Microsystems Cc: Fuyuki Hasegawa , PSARC-ext@Sun.COM, gto@Sun.COM Message-id: <1254403402.5887.1.camel@strat> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> <1254321500.19199.34.camel@strat> <4AC488A6.7000507@sun.com> <1254398447.12502.19.camel@seb> <4AC4A328.3000509@sun.com> Status: RO Content-Length: 1632 On Thu, 2009-10-01 at 21:40 +0900, Fuyuki Hasegawa - Sun Microsystems wrote: > Thanks for your prompt reply. :) > > Sebastien Roy wrote: > > Do you expect users to call /usr/bin/ibus-daemon directly, or do you > > only ever expect it to be started from private scripts indirectly by > > gnome-session? If it's the former, then what you have is fine. If it's > > the latter, then it probably belongs in /usr/lib along with the other > > private executables, and it should be Project Private along with the > > others. Otherwise, I agree with your assessment of the other > > interfaces. > > ibus-daemon would be called from a custom WM or a desktop other than Gnome. Okay. In that case, the stability stated is fine with me. > >>>> 4.12. Dependencies: > >>>> We need python2.6 to be the default in OpenSolaris. > >>> What is the specific case dependency? > >> I don't know what python2.6 API ibus depends on. > >> We heard the python default will be changed from 2.4 to 2.6 > >> in near future, but don't know the actual target at this point. > > > > According to PSARC/2009/043, you must not depend on the default version > > in /usr/bin, but rather on a specific version > > (e.g., /usr/bin/python2.6). That would relieve any dependency on a > > particular version becoming the default, and would prevent breakage of > > your feature if the default version changes and introduced > > incompatibilities. > > OK, we will make ibus independent on the python default version. Great. To be clear, this case depends on PSARC/2009/043 in that it specifically depends on python 2.6. I give this case my +1. -Seb From jub@sun.com Fri Oct 2 01:13:37 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n928Daqv011370 for ; Fri, 2 Oct 2009 01:13:37 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n928DQ5f020336; Fri, 2 Oct 2009 02:13:36 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQV00205O6J5P00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 02 Oct 2009 01:13:32 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQV00HFXO6IRK30@nwk-avmta-1.sfbay.Sun.COM>; Fri, 02 Oct 2009 01:13:31 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n928DUMR019308; Fri, 02 Oct 2009 08:13:30 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQV00E00MPLKB00@fe-emea-09.sun.com>; Fri, 02 Oct 2009 09:13:24 +0100 (BST) Received: from [10.16.66.63] ([unknown] [10.16.66.63]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQV007SUO5QW0A0@fe-emea-09.sun.com>; Fri, 02 Oct 2009 09:13:02 +0100 (BST) Date: Fri, 02 Oct 2009 10:13:02 +0200 From: Joerg Barfurth Subject: Re: iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009] In-reply-to: <4AC488A6.7000507@sun.com> Sender: Joerg.Barfurth@sun.com To: Fuyuki Hasegawa - Sun Microsystems Cc: Sebastien Roy , gto@sun.com, PSARC-ext@sun.com Message-id: <4AC5B60E.1090604@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> <1254321500.19199.34.camel@strat> <4AC488A6.7000507@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081014) Status: RO Content-Length: 3047 Fuyuki Hasegawa - Sun Microsystems schrieb: > Sebastien Roy wrote: >> On Thu, 2009-09-17 at 03:54 -0700, Fuyuki Hasegawa wrote: >>> Integrating ibus does not mean to obsolete iiimf or scim, but >>> we would put them in maintenance state. >> >> What is "maintenance state"? If you mean that they will remain >> supported but that ibus is the preferred method, then making them >> "Obsolete" in the ARC sense would seem like the right thing to do. Is >> that what you intend? See >> http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/. > > The "maintenance state" means that we will stop feature work > and unlikely to fix low priority bugs. > iiimf is still default IM for OpenSolaris 2010.02. > It seems we should change iiimf or scim interfaces to Obsolete > when we switch default IM to ibus for Solaris Next. > [...] >>> We plan to change default IM framework from iiimf to ibus in >>> Solaris Next. >> >> So this case does not change the default IM framework. A future case >> will do that. Is that accurate? > > Yes. > Such a future case would need to call out the feature differences between ibus and iiimf. I just learned that ibus does not (currently) support the keyboard layout switching functionality for European languages that iiimf has. Is there any long-term architectural direction for that area? - First we had keyboard switcher based on libxklavier. Then that was dropped, because of some fundamental brokenness - Now we had to relearn that keyboard switching may be found in input method configuration. (And some people who need it never found it, as input methods are perceived to be for asian languages.) I'm not sure what, if any, are the limitations here. Does this require applications to be input-method-aware? - Then keyboard-switcher/libxklavier comes back for 'familiarity' - including the known brokenness. Apparently we now find it acceptable to pretend that Xserver == Xorg. - But we still have iiimf. I don't really want to know what happens when both methods are used at the same time. And as neither method is Obsolete, I don't know what customers should prefer. I'd assume that when there is a risk of running into the libxklavier limitations, iiimf can still work?! - Now along comes ibus, which takes this function back out of input methods, so if someone has learned that, they'll have to relearn again. ("Ah, but there never was a real product release of this intermediate state, only the SXCE and OpenSolaris non-releases.") Do we have a clear picture of where we want to go with this, or are we going to keep providing an everchanging method of the day? And is that the only thing where ibus has less functionality than iiimf and depends on a different project to make up for that. While all that only needs to be addressed in a 'make ibus default, obsolete iiimf' case, it would have been good to expose the underlying architectural direction now (assuming there is one other than following the crowd). - Jörg From Fuyuki.Hasegawa@Sun.COM Mon Oct 5 01:07:44 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9587iDc016468 for ; Mon, 5 Oct 2009 01:07:44 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9587hTX016996; Mon, 5 Oct 2009 01:07:43 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR100F057WS3200@nwk-avmta-1.sfbay.Sun.COM>; Mon, 05 Oct 2009 01:07:40 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR100BB37WRB2F0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 05 Oct 2009 01:07:40 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9587dwp025509; Mon, 05 Oct 2009 08:07:39 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KR100M007VB3000@mail-apac.sun.com>; Mon, 05 Oct 2009 16:07:39 +0800 (SGT) Received: from [129.158.28.135] ([unknown] [129.158.28.135]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KR100ACS7WOTIE0@mail-apac.sun.com>; Mon, 05 Oct 2009 16:07:39 +0800 (SGT) Date: Mon, 05 Oct 2009 17:07:32 +0900 From: Fuyuki Hasegawa - Sun Microsystems Subject: Re: iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009] In-reply-to: <4AC5B60E.1090604@sun.com> Sender: Fuyuki.Hasegawa@Sun.COM To: Joerg Barfurth Cc: Sebastien Roy , gto@Sun.COM, PSARC-ext@Sun.COM Message-id: <4AC9A944.6030306@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 X-PMX-Version: 5.4.1.325704 References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> <1254321500.19199.34.camel@strat> <4AC488A6.7000507@sun.com> <4AC5B60E.1090604@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sac.sfbay.sun.com id n9587iDc016468 Status: RO Content-Length: 4300 Joerg Barfurth wrote: > Fuyuki Hasegawa - Sun Microsystems schrieb: >> Sebastien Roy wrote: >>> On Thu, 2009-09-17 at 03:54 -0700, Fuyuki Hasegawa wrote: >>>> Integrating ibus does not mean to obsolete iiimf or scim, but >>>> we would put them in maintenance state. >>> >>> What is "maintenance state"? If you mean that they will remain >>> supported but that ibus is the preferred method, then making them >>> "Obsolete" in the ARC sense would seem like the right thing to do. Is >>> that what you intend? See >>> http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/. >>> >> >> The "maintenance state" means that we will stop feature work >> and unlikely to fix low priority bugs. >> iiimf is still default IM for OpenSolaris 2010.02. >> It seems we should change iiimf or scim interfaces to Obsolete >> when we switch default IM to ibus for Solaris Next. >> > > [...] > >>>> We plan to change default IM framework from iiimf to ibus in >>>> Solaris Next. >>> >>> So this case does not change the default IM framework. A future case >>> will do that. Is that accurate? >> >> Yes. >> > > Such a future case would need to call out the feature differences > between ibus and iiimf. It should be addressed in the future case. > > I just learned that ibus does not (currently) support the keyboard > layout switching functionality for European languages that iiimf has. > > Is there any long-term architectural direction for that area? One of the reasons iiimf is still default IM, is that ibus has not the keyboard layout emulation feature (iiimf has) yet while ibus already supports several keyboard input for European languages by utilizing m17n (MultilingualizatioN) library. We have been planning to add the keyboard layout emulation feature into ibus for Solaris Next. > > - First we had keyboard switcher based on libxklavier. Then that was > dropped, because of some fundamental brokenness > > - Now we had to relearn that keyboard switching may be found in input > method configuration. (And some people who need it never found it, as > input methods are perceived to be for asian languages.) I'm not sure > what, if any, are the limitations here. Does this require applications > to be input-method-aware? Yes if need to use keyboard switching function provided by Input Method. Since GTK or java apps are already input-method-aware, such apps are also input-method-aware by default. > > - Then keyboard-switcher/libxklavier comes back for 'familiarity' - > including the known brokenness. Apparently we now find it acceptable to > pretend that Xserver == Xorg. > > - But we still have iiimf. I don't really want to know what happens when > both methods are used at the same time. And as neither method is > Obsolete, I don't know what customers should prefer. I'd assume that > when there is a risk of running into the libxklavier limitations, iiimf > can still work?! (While this is not make sense, if both methods are uses at the same time, IM will get the output of libxklavier and should work as expected as far as the current libxklavier's KB layout is informed to IM via IM config tool.) User should use either keyboard-switcher+libxklavier or the iiim/ibus's KB emulation in his/her preference. Probably most EMEA users would prefer the former. For the users running into the libxklavier limitations, yes, iiimf/ibus are also available. I hope the aboves would also answer the followings. Fuyuki > > - Now along comes ibus, which takes this function back out of input > methods, so if someone has learned that, they'll have to relearn again. > ("Ah, but there never was a real product release of this intermediate > state, only the SXCE and OpenSolaris non-releases.") > > Do we have a clear picture of where we want to go with this, or are we > going to keep providing an everchanging method of the day? > > And is that the only thing where ibus has less functionality than iiimf > and depends on a different project to make up for that. > > While all that only needs to be addressed in a 'make ibus default, > obsolete iiimf' case, it would have been good to expose the underlying > architectural direction now (assuming there is one other than following > the crowd). > - Jörg From Fuyuki.Hasegawa@sun.com Mon Oct 5 01:26:09 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n958Q9ub016535 for ; Mon, 5 Oct 2009 01:26:09 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n958Q5kQ020673; Mon, 5 Oct 2009 09:26:08 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR100H198RHJ000@nwk-avmta-1.sfbay.Sun.COM>; Mon, 05 Oct 2009 01:26:05 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR100FYJ8RG3B80@nwk-avmta-1.sfbay.Sun.COM>; Mon, 05 Oct 2009 01:26:05 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n958Q4MY003881; Mon, 05 Oct 2009 08:26:04 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KR100K008GG8E00@mail-apac.sun.com>; Mon, 05 Oct 2009 16:26:04 +0800 (SGT) Received: from [129.158.28.135] ([unknown] [129.158.28.135]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KR1003JK8RFT1E0@mail-apac.sun.com>; Mon, 05 Oct 2009 16:26:04 +0800 (SGT) Date: Mon, 05 Oct 2009 17:25:59 +0900 From: Fuyuki Hasegawa - Sun Microsystems Subject: Re: iBus integration [PSARC/2009/499 FastTrack timeout 10/02/2009] In-reply-to: <1254403402.5887.1.camel@strat> Sender: Fuyuki.Hasegawa@sun.com To: Sebastien Roy Cc: PSARC-ext@sun.com, gto@sun.com Message-id: <4AC9AD97.80400@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909171054.n8HAsA8g380045@jurassic-x4600.sfbay.sun.com> <1254321500.19199.34.camel@strat> <4AC488A6.7000507@sun.com> <1254398447.12502.19.camel@seb> <4AC4A328.3000509@sun.com> <1254403402.5887.1.camel@strat> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 9241 The case has been approved as the timer has been expired with +1 (thanks, Sebastien). Fuyuki Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: iBus integration 1.2. Name of Document Author/Supplier: Author: Fuyuki Hasegawa 1.3 Date of This Document: 17 September, 2009 2. Project Summary 2.1. Project Description: This project is to integrate next generation Input Method framework, iBus and its various IMEs (Input Method Engines). Release binding is Micro/Patch and initial integration is OpenSolaris (Nevada). COMPONENT VERSION LICENSE LANGUAGES ------------------------------------------------------------------------ ibus: 1.1.0 LGPLv2.1 IM framework Available IMEs: ibus-anthy: 1.1.0 GPLv2 Japanese ibus-pinyin: 1.1.0 GPLv2 Simplified Chinese ibus-chewing: 1.1.0 GPLv2 Traditional Chinese ibus-hangul: 1.1.0 GPLv2 Korean ibus-m17n: 1.1.0 GPLv2 libm17n[4] Umbrella Engine ibus-table: 1.1.0 GPLv2 code-table Umbrella Engine Codetables for ibus-table ibus-table-array30 1.2.0 GPLv2 Traditional Chinese ibus-table-cangjie 1.1.0 GPLv2 Traditional Chinese ibus-table-erbi 1.1.0 GPLv2 Simplified Chinese ibus-table-quick 1.1.0 GPLv2 Simplified Chinese ibus-table-translit 1.1.0 GPLv2 Cyrillic ibus-table-wubi 1.1.0 GPLv2 Simplified Chinese ibus-table-xinhua 1.1.0 GPLv2 Simplified Chinese ibus-table-yong 1.1.0 GPLv2 Simplified Chinese ibus-table-zhengma 1.1.0 GPLv2 Simplified Chinese 2.2. Risks and Assumptions: iBus requires python 2.5+ in runtime, but currently opensolaris still uses python 2.4 as default. We need python2.6 to be the default in OpenSolaris. 4. Technical Description 4.1. Details: 4.1.1 iBus Overview: iBus (http://code.google.com/p/ibus) leverages many design ideas and principles in the CJK input method SPI specification conference, which many experienced IM developers (among iiimf, scim communities and us) joined and contributed. It's mainly developed by Peng Huang, who works for Redhat. And it's a very active community, much more active than iiimf and scim. ibus delivered 1.1.0 stable release on July 2009. It had been adopted as default IM framework on Fedora 11, and it will also be used as the default on next Ubuntu release Karmic (https://wiki.ubuntu.com/desktop- karmic-input-methods). It's already in Debian/Ubuntu package repo. Integrating ibus does not mean to obsolete iiimf or scim, but we would put them in maintenance state. +------------+ +--------+ +-----------+ | GtkApp | | X11App | | QtApp | +------------+ +--------+ +-----------+ |ibus-gtk-imm| |ximcp.so| |ibus-qt-imm| +----^-------+ +----^---+ +-----^-----+ | | | | +-------V---------+ | | |ibus-xim-frontend| | | +-------^---------+ | | | | /---V----------------V--------------V-------\ / ibus message bus \ \ daemon in C / \---^--------^-----------^------------^-----/ | | | | +--V--- +--V--+ +-----V-----+ +---V----+ |IME A| |IME B| | panel GUI | | config | +-----+ +-----+ +-----------+ +--------+ This 'bus-centric' architecture is introduced to resolve the following weakness in 'server-centric' architecture. * There's usually only 1 server per desktop session, which loads all IMEs as shared objects. So one buggy IME would crash the entire server. * IMEs are developed with either C or C++, it's difficult to add other language bindings. Adding a binding basically means plugging an interpreter into server's process space. * IMEs are not able to be loaded or unloaded on the fly. All components in above diagram uses DBus as IPC. And iBus largely uses python, such as panel GUI, config backend, or even IMEs. 4.1.2 Switching between iBus, SCIM and IIIMF iBus services are started by gnome-session(1). User could simply enable or disable the service via gnome-session-properties(1). With the help of startup scripts shipped with iiimf and scim, user could set GTK_IM_MODULE environment variable in $HOME/.profile to select iBus, IIIMF or SCIM. We plan to change default IM framework from iiimf to ibus in Solaris Next. 4.4. Out of Scope: KDE/Qt support through ibus-qt-imm is out of scope this time. Qt applications will be connected through XIM frontend. 4.5. Interfaces: INTERFACE NAME STABILITY NOTE ----------------------------------------------------------------------- /usr/bin/ibus-daemon Volatile message bus daemon /usr/bin/ibus-setup Volatile setup launcher The following are all Project Private. INTERFACE NAME STABILITY NOTE ----------------------------------------------------------------------- /usr/lib/ibus/ibus-x11 Private ibus XIM fontend/agend /usr/lib/ibus/ibus-gconf Private config backend by gconf-python /usr/lib/ibus/ibus-ui-gtk Private panel GUI by pygtk /usr/lib/libibus.so.0 Private ibus C binding SDK library /usr/include/ibus-1.0/* Private ibus C binding header files /usr/share/gtk-doc/html/ Private ibus developor documents ibus/* /usr/lib/python2.6/ Private ibus Python binding site-packages/ibus/* /usr/lib/gtk-2.0/2.10.0/ Private ibus gtk-im-module immodules/im-ibus*.so /usr/lib/{amd64,sparcv9}/ Private 64bits version of ibus gtk-2.0/2.10.0/immodules/ gtk-im-module im-ibus*.so /usr/share/ibus/setup/* Private ibus-setup modules /usr/share/ibus/ui/gtk/* Private panel GUI by pygtk /usr/share/ibus/ Private ibus components registry components/* like ibus-gconf, ibus-ui-gtk and IMEs /usr/lib/ibus/ Private IME launcher ibus-engine- /usr/lib/ibus/ Private IME setup launcher ibus-setup- /usr/share/ibus- Private IME modules *IME_NAME is among [anthy, chewing, hangul, m17n, pinyin, table] /usr/share/ibus-table/* Private ibus-table engine and code-tables -> It was suggested to move ibus- under /usr/share/ibus. The community will examine it in future ibus version (1.2~). 4.10. Packaging & Delivery: SUNWibus SUNWibus-root SUNWibus-devel SUNWibus-chewing SUNWibus-chewing-root SUNWibus-anthy SUNWibus-pinyin SUNWibus-hangul SUNWibus-m17n SUNWibus-table SUNWibus-table-devel SUNWibus-table-data-cangjie SUNWibus-table-data-erbi SUNWibus-table-data-quick SUNWibus-table-data-translit SUNWibus-table-data-wubi SUNWibus-table-data-xinhua SUNWibus-table-data-yong SUNWibus-table-data-zhengma SUNWibus-table-extraphrase SUNWibus-table-extraphrase-devel 4.12. Dependencies: We need python2.6 to be the default in OpenSolaris. -> It was suggested to make ibus independent on python default version. Project team has agreed it. 5. Reference Documents: 1). IIIMF project http://www.openi18n.org/iiimf PSARC 2005/525 IIIMF upgrade to revision 12 2). SCIM project http://www.scim-im.org PSARC 2008/418 Integrate SCIM to Solaris 3). Server-Centric vs. Bus-Centric Architectures http://docs.google.com/present/view?id=ahtgvwdt62tk_24ftz4nsft 4). Supported Input Methods in libm17n http://www.m17n.org/m17n-lib-en/support_input_sum.html PSARC 2008/624 Integrate libm17n and scim-m17n to Solaris 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: G11N 6.5. ARC review type: FastTrack 6.6. ARC Exposure: approved