Replace kimpanel in kdeplasma-addons with a rewrite version

Weng Xuetian wengxt at gmail.com
Tue Oct 4 16:31:21 UTC 2011


在 2011年10月4日 Tuesday 17:19:40,Aaron J. Seigo 写道:
> On Monday, September 19, 2011 20:39:11 Weng Xuetian wrote:
> > So I rewrite kimpanel (Use the same dbus protocol), and use dataengine
> 
> *resurrects and old thread* :)
> 
> so this is now in git .. and we need to decide what we are going to do with
> it. my suggestion is this, and i'd like comments on it as it would mean some
> moderately large changes:
> 
> * we remove kimpanel from kdeplasma-addons
> * the new kimpanel takes its place, and we communicate this to packagers
> * we roll a release of the kimpanel along with every SC release if there
> were changes since the last SC release
> * we roll new releases of the new kimpanel whenever justified regardless of
> SC schedule so people don't have to wait :)
> 
> so far, probably nothing SHOCKING, right? :)
> 
> let's fix that ... :P
> 
> we have the keyboard container and the keyboard widget in two other
> repositories. the plasmoid is in addons, the container shell is in plasma-
> mobile.
> 
> i propose that we take the kimpanel repository, call it
> "plasma-intputmethods" (or something similar) and put ALL of our input
> method related code there. that would include:
> 
> * kimpanel
> * keyboard container shell
> * on-screen keyboard widget
> * anything else?
For me that's what I exactly want to do in the futre: try to get them merge if 
necessary. And I'm also a input method developer (named fcitx, which is not a 
part of KDE and only for chinese currently though, but I'm trying to drive it 
to more language support.), so actually I can provides more support not only 
from the UI part, like something really get implemented but not only a design.
> 
> if we were to get REALLY dramatic we could put kxkb or even klipper in
> there, but i'm still debating with myself as to how far to take this new
> module. what i do know is i'd like all our input stuff in one place instead
> of spread out all over the place. these components seem to develop at their
> own pace and are related to each other topically ...
> 
Keyboard layout(xkb for X11) is also something should also get here in my 
mind.
> thoughts?
For desktop PC, I'm not sure what we should do for something new, but merge 
the keyboard layout with kimpanel is something comes to my mind, since 
keyboard layout is something that very similar to inputmethod (which get 
separated with input method in x11 linux due to historical reason), but for 
instance, like windows, keyboard layout is only represent as single input 
method.

For tablet or something else, kimpanel maybe should merge with on-screen 
keyboard like what most mobile phone does: provides input method if required. 
Not sure whether the on-screen keyboard is related to the keyboard layout yet. 
But also it would be great if input method want to provides it's own on screen 
keyboard layout when input method get enabled.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20111005/f4bc5922/attachment.sig>


More information about the Plasma-devel mailing list