D11061: Migration request from IBusConfig to GSettings

[Takao Fujiwara]

fujiwara updated this revision to Diff 28920.

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11061?vs=28881=28920

REVISION DETAIL
  https://phabricator.kde.org/D11061

AFFECTED FILES
  applets/kimpanel/backend/ibus/ibus15/panel.cpp

To: fujiwara, #plasma, hein, xuetianweng
Cc: davidedmundson, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D11061: Migration request from IBusConfig to GSettings

[Takao Fujiwara]

fujiwara added a comment.


  In D11061#219841 , @davidedmundson 
wrote:
  
  > FWIW, there's a lovely Qt-GConf wrapper in plasma-pa/gconfitem
  
  
  I may drop gconf and dconf support in IBus 1.6. It would be nice if Qt API 
could read GSettings.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11061

To: fujiwara, #plasma, hein, xuetianweng
Cc: davidedmundson, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D11061: Migration request from IBusConfig to GSettings

[Takao Fujiwara]

fujiwara marked an inline comment as done.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11061

To: fujiwara, #plasma, hein, xuetianweng
Cc: davidedmundson, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D11061: Migration request from IBusConfig to GSettings

[Takao Fujiwara]

fujiwara updated this revision to Diff 28881.

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11061?vs=28793=28881

REVISION DETAIL
  https://phabricator.kde.org/D11061

AFFECTED FILES
  applets/kimpanel/backend/ibus/ibus15/panel.cpp

To: fujiwara, #plasma, hein, xuetianweng
Cc: davidedmundson, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D11061: Migration request from IBusConfig to GSettings

[Takao Fujiwara]

fujiwara requested review of this revision.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11061

To: fujiwara, #plasma, hein, xuetianweng
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D11061: Migration request from IBusConfig to GSettings

[Takao Fujiwara]

fujiwara updated this revision to Diff 28793.

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11061?vs=28722=28793

REVISION DETAIL
  https://phabricator.kde.org/D11061

AFFECTED FILES
  applets/kimpanel/backend/ibus/ibus15/panel.cpp

To: fujiwara, #plasma, hein, xuetianweng
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D11061: Migration request from IBusConfig to GSettings

[Takao Fujiwara]

fujiwara planned changes to this revision.
fujiwara marked 2 inline comments as done.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11061

To: fujiwara, #plasma, hein, xuetianweng
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D11061: Migration request from IBusConfig to GSettings

[Takao Fujiwara]

fujiwara added a comment.


  In D11061#219603 , @xuetianweng 
wrote:
  
  > May I ask when this gsettings is introduced? Is it required after certain 
ibus version? Is there any case that this will not work?
  >
  > If so I'd like to see a version check on ibus at compile time.
  
  
  GSettings has been supported in IBus 1.5.0 at least and you don't have to 
mind IBus.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11061

To: fujiwara, #plasma, hein, xuetianweng
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D11061: Migration request from IBusConfig to GSettings

[Takao Fujiwara]

fujiwara created this revision.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
fujiwara requested review of this revision.

REVISION SUMMARY
  kimpanel-ibus-panel uses IBusConfig and I'd ask to migrate it to GSettings 
and delete IBusConfig.
  
  https://groups.google.com/forum/#!topic/ibus-devel/Mu1IoFX-bKE

TEST PLAN
  Run ibus-setup and changes "Next input method" or IMEs and KIM panel works 
fine.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11061

AFFECTED FILES
  applets/kimpanel/backend/ibus/ibus15/panel.cpp

To: fujiwara
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

Re: Complex text input in Plasma

[Takao Fujiwara]

On 04/07/17 22:46, Martin Gräßlin-san wrote:

Am 2017-04-07 07:56, schrieb Takao Fujiwara:

Due to that: no chance for IM controlling part of our stack. We control the IM.


Probably I think this way would not work with IBus.
Each IBus IME are called by IBus dbus method. You hardly ask each IME
maintainer to change the protocol.
IBus daemon would be the controller of IBUs IMEs.


I think I need to describe in a better way how I envision the future 
architecture.

I want to have the IM daemon merged into the wayland compositor. So KWin would 
talk directly with the IM through library calls and the composed text
would be sent from KWin to the application through the Wayland text-input 
protocol.


Probably I'd think KWin does not have to merge IM daemon and I hope we can make 
DBus proceses more secure.
Also I think virtual keyboards does not need to implement IM and they can 
enable IM with the shortcuts outside IM implementations.

Probably you have to support copy & paste between applications and support 
protocols between processes.



I want to eliminate the IPC between applications and IM daemon.

If we are going to touch this code we can strive for the best solution and not 
keep stuck on the approach used on X11. And yes that might need
adjusting the IMEs. But they need to be adjusted anyway. We wouldn't have this 
discussion if it would just work on Wayland.


I guess just implementing Plasma Wayland with the current IM modules also will 
causes many regressions as GNOME did.

Thanks,
Fujiwara



Cheers
Martin

Re: Complex text input in Plasma

[Takao Fujiwara]

On 04/09/17 01:46, Martin Gräßlin-san wrote:

Am 2017-04-08 17:26, schrieb Weng Xuetian:


You're wrong about the QT_IM_MODULE stuff. To make application to use the
wayland protocol to type (text-input), the implementation must be done with
QT_IM_MODULE=wayland. I don't mind if it is set to certain application but set
it in general won't work. Also to have real virtual keyboard , you need to let
the input method daemon to provides a virtual keyboard implementation.


No you are wrong about that one :-) It might be that it used to be like that, 
but Wayland is the default if no QT_IM_MODULE is specified. See
https://code.qt.io/cgit/qt/qtwayland.git/tree/src/client/qwaylandintegration.cpp#n142



And also, merging more and more daemon into kwin is not always good even from
security point of view. The problem is, once it got merged, the whole memory
space is being exposed. Which means, if there's a single piece of code is
vulnerable, it will affect the whole compositor. We are not perfect people, and
that's why put more code together will make it more vulnerable to attacker. If
you consider that, your prevention of ptrace on kwin becomes nothing and so
does your effort to make kwin not loading some random plugin (prevent
ld_preload and qt_plugins_path?).


The security of the system breaks with the weakest link. Whether the IM daemon 
is insecure by running standalone or inside KWin isn't a difference.


I think the weakest link still can make more secure in the protocol.
I'd suggest to make Plasma Wayland with the current IM modules in the first 
stage since I guess there will be many regressions in Plasma Wayland.
Currently I'm also involved a discussion how to secure the DBus in the GNOME 
side and I also think it could be utilized for Plasma Wayland.

Otherwise I think it might be difficult to support Plasma in some distributions.

Wayland staffs has contributed in the IBus and GNOME connection for a long time 
ago.
https://github.com/ibus/ibus/tree/master/client/wayland
But it's not used in GNOME yet.

Re: Complex text input in Plasma

[Takao Fujiwara]

On 04/07/17 14:13, Martin Gräßlin-san wrote:

Am 2017-04-06 22:18, schrieb Eike Hein:

On 04/07/2017 04:58 AM, Weng Xuetian wrote:

gnome-shell's kimpanel equilvalent stuff is bundled in gnome-shell, which make
it be able to access the windows position. Input method server send the offset
received from client (which is not global), and the gnome-shell move the panel
to the (offset+current window location)


This seems to be roughly what Martin wants to do as well, except I think
he was probably envisioning the window being part of KWin somehow.


Yes GNOME Shell (Wayland compositor) and KWin (Wayland compositor) are the same 
layer in the stack.



My understanding is that it might be necessary to allow the IME to
provide the UI however, since one-list-popup-fits-all may not be true
across writing systems.



4. Let input method server controls the keyboard layout (which layout to use)
Keyboard layout is nothing special comparing with input method. Nowadays,
modern input method framework are trying to take over all this stuff. This is
essential for users to get best experience if they use multiple input method.
Because there's a concept called "input context", which is not essentially
one-to-one map to the window.


I saw this one coming and it's the reason I originally spoke up in
https://phabricator.kde.org/D5301 - there's ongoing work on bringing
keyboard layout switching policies to kwin_wayland right now, in a
system that isn't integrated with the input method systems. This
shows the need for coordination.


Important note here: IM is not able to control the keyboard layout. That must 
be in the Wayland compositor.


A downside with the "input method always on" approach can be
performance: We don't want to send events through layers of IPC
for input scenarios we don't want to.


This is just another reason to have it in KWin which would completely eliminate 
the IPC.
Also from a security perspective way better. There is no chance for an 
integration of a system where every key event is sent through an IPC. That
wouldn't pass my security review.




This reads on things like the work in D5301. Scenarios:

* If the input method is always on, then there maybe doesn't need
  to be a fallback to complex, redundant policy systems in KWin.

* If the input method continues to be an optional add-on, then
  KWin still needs those policy systems.

* The input method could be rearchitected to drive KWin's built-in
  policy systems via public API.


I dislike all three options. The base keyboard layout handling must be in KWin. 
KWin has to control the IM stack, not the other way around.

I'm not giving away control over such fundamental aspects of the stack any 
more. I want that these things function correctly and I'm not trusting 3rd
party software to do the right things. KWin can do the right thing in all 
situations. KWin is the only element in the stack having a global view: is
the screen locked, is virtual keyboard on, is a fullscreen effect in place, is 
a popup menu open, is a game being played? Only KWin knows that. Only
KWin can ensure that the right thing is done all the time.

Due to that: no chance for IM controlling part of our stack. We control the IM.


Probably I think this way would not work with IBus.
Each IBus IME are called by IBus dbus method. You hardly ask each IME 
maintainer to change the protocol.
IBus daemon would be the controller of IBUs IMEs.

Thanks,
Fujiwara



Cheers
Martin

Re: Complex text input in Plasma

[Takao Fujiwara]

IBus emoji typing is updated day by day.
IBus 1.5.15 moved the emoji function in IBus XKB engine to IBus panel, which means the UI is now available from pane GUI menu and the shortcut key can 
be customizable with ibus-setup:

https://desktopi18n.wordpress.com/2017/03/15/ibus-1-5-15-is-released/

Also 'ibus emoji' CLI can launch the same GUI and it does not require to run 
ibus-daemon.

The emoji tying has two goals:
 - available with an extended lookup window likes an input method's lookup 
window without mouse operations for input method users
 - available from panel menu by mouse only for GUI users

Thanks,
Fujiwara

On 04/07/17 05:18, Eike Hein-san wrote:



On 04/07/2017 04:58 AM, Weng Xuetian wrote:

gnome-shell's kimpanel equilvalent stuff is bundled in gnome-shell, which make
it be able to access the windows position. Input method server send the offset
received from client (which is not global), and the gnome-shell move the panel
to the (offset+current window location)


This seems to be roughly what Martin wants to do as well, except I think
he was probably envisioning the window being part of KWin somehow.

My understanding is that it might be necessary to allow the IME to
provide the UI however, since one-list-popup-fits-all may not be true
across writing systems.



4. Let input method server controls the keyboard layout (which layout to use)
Keyboard layout is nothing special comparing with input method. Nowadays,
modern input method framework are trying to take over all this stuff. This is
essential for users to get best experience if they use multiple input method.
Because there's a concept called "input context", which is not essentially
one-to-one map to the window.


I saw this one coming and it's the reason I originally spoke up in
https://phabricator.kde.org/D5301 - there's ongoing work on bringing
keyboard layout switching policies to kwin_wayland right now, in a
system that isn't integrated with the input method systems. This
shows the need for coordination.


Taking a step back, there's a couple of ways to go on the system
architecture. Right now, an input method system is kind of an
"after market add-on" - it's something you install only if you
need to, and if you do, it replaces parts of your system with its
own stuff.

Thoughts:

a) The "replaces part of your system with its own stuff" is what
gets us the unintegrated config mess, where your System Settings
becomes useless if the input method is around.

b) Historically a input method is used by non-Latin-based
   language users, but with Emoji input and things like word
   completion, this is changing.

I think a and b together mean that an input method is now better
positioned as a core dependency of the system, not a special case.

A downside with the "input method always on" approach can be
performance: We don't want to send events through layers of IPC
for input scenarios we don't want to.


This reads on things like the work in D5301. Scenarios:

* If the input method is always on, then there maybe doesn't need
  to be a fallback to complex, redundant policy systems in KWin.

* If the input method continues to be an optional add-on, then
  KWin still needs those policy systems.

* The input method could be rearchitected to drive KWin's built-in
  policy systems via public API.



Cheers,
Eike

Re: timing of KDE5 panel in login

[Takao Fujiwara]

I don't think the kimpanel-ibus-panel resolves this problem.
And I think now ibus has the better panel icon for KDE5 than it.

On 03/27/15 23:47, Eike Hein-san wrote:


Just a side note: KDE ships an ibus/fcitx/scim GUI frontend
in kdeplasma-addons that's implemented as a panel widget (+
popups).



Cheers,
Eike
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: timing of KDE5 panel in login

[Takao Fujiwara]

Thank you for forwarding the e-mail.

I try to get the desktop size from _NET_WORKAREA and _NET_CURRENT_DESKTOP.

After KDE panel runs, the height of root window != the height of _NET_WORKAREA 
because KDE5 panel is allocated.
I wish to move my panel to (the width of root window, the height of 
_NET_WORKAREA)
But When I try to get the the height of _NET_WORKAREA during the login, the height of root window == the height of _NET_WORKAREA because KDE5 panel is 
not allocated yet. So the position of my panel and one of the KDE panel is duplicated.


This is the expected result.

+--- plasma-desktop 5 -+
|  |
| +---+|
| | my panel  ||
| +---+|
|++|
||  KDE5 panel||
|++|
+--+

But actual result at login time is duplicated because KDE5 panel is not 
allocated:

++---+
|  KDE5 panel| My panel  |
++---+

After KDE5 panel runs, my panel gets the right position because the height of 
_NET_WORKAREA returns the right value.

I'm finding how to listen the changes in the property.
But I don't have to listen the change in GNOME and XFCE. I can get the right 
value of _NET_WORKAREA at login.
I guess KDE5 panel might be slow to be launched.

Probably I can use notify::size signal for GtkStatusIcon to listen the panel 
size.
But I don't know how to get the change of the panel size in KNotifications.
I migrated GtkStatusIcon to KNotifications recently since KDE5 does not enable 
notification area by default.
I use both the custom panel and panel icon of KNotifications now.

On 03/27/15 20:28, Luigi Toscano-san wrote:

On Friday 27 of March 2015 19:21:35 Takao Fujiwara wrote:

I'd like to run a custom panel at bottom right in KDE5 for
ibus(propertypanel.vala): https://github.com/ibus/ibus/tree/master/ui/gtk3


Hi, this is a Plasma 5 related question, try to ask on the plasma-devel list
(now in CC, I don't remember if it requires a subscription). Question quoted
below (I'm just the messenger):



Since KDE5 allocates the owned panel at bottom, I try to get the desktop
height using _NET_CURRENT_DESKTOP atom. My custom panel runs at login time
and tries to get the desktop height using _NET_CURRENT_DESKTOP atom but
KDE5 panel still is not launched. How can I get when the KDE5 panel is
launched at login time?

Actually I use both the custom panel and KNotifications icon.
When I get the callback of org.kde.StatusNotifierWatcher of The
KNotifications icon, KDE5 panel still is not allocated. I also checked the
atoms with xlsatoms command but I have no idea to get KDE panel.


Ciao



___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel