date:20170406

D3697: Fix progress bar color

2017-04-06 Thread Anton Anikin

This revision was automatically updated to reflect the committed changes.
Closed by commit R31:cdf79566d851: Fix progress bar color (authored by 
antonanikin).

REPOSITORY
  R31 Breeze

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D3697?vs=12053&id=13174

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

AFFECTED FILES
  kstyle/breezestyle.cpp

To: antonanikin, #breeze, hpereiradacosta
Cc: plasma-devel, andreaska, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol

Re: Complex text input in Plasma

2017-04-06 Thread Heinz Wiesinger

On Thursday, 6 April 2017 19:16:14 CEST Eike Hein wrote:
> Hi,
> 
> In the aftermath of D5301, Martin asked to compile a document on the
> requirements for complex text input in Plasma, especially with the
> opportunities provided by the Wayland transition. It makes sense to
> share this document with all of you, to share the knowledge more widely :)

I worked a lot recently on updating the IME support in Slackware so I'll add a 
couple points from my experience with that as well as from a packager 
perspective.

I evaluated both ibus and fcitx and found that, much like Eike already 
explained in his initial mail, initial setup is less than ideal. This is even 
more so the case on Slackware, since we do not have distro-specific tooling 
for the user to select a language or input method.

= Base setup =

I'll describe the raw setup of both ibus and fcitx on Slackware, as well as 
some of the "improvements" I made to make this a bit simpler for the user (I 
guess one could call that distro-specific tooling as well).

a) ibus

After login you execute "ibus-setup" which checks whether the ibus daemon is 
running and starts it otherwise before showing its configuration dialog. Once 
finished with the configuration it asks to add a couple entries to the user's 
.bashrc file:

export XMODIFIERS=@im=ibus
export GTK_IM_MODULE=ibus
export QT_IM_MODULE=ibus

After this the user still has to manually configure Qt4 to use "ibus" as the 
default input method (via qtconfig), as well as add some way to start ibus-
daemon automatically on login.

b) fcitx

fcitx is a bit userfriendlier in that it already provides xdg autostart 
support (though most distros disable this). So if fcitx is installed it will 
automatically run on login, even if the user doesn't need it. It still needs 
similar steps though as ibus. You configure your input methods via fcitx' 
configuration tool and add similar entries to .bashrc:

export XMODIFIERS="@im=fcitx"
export XIM=fcitx
export XIM_PROGRAM=fcitx
export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx

You also again have to set Qt4's default input method to "fcitx".

c) Modifications

This plain setup leaves us with some "papercuts" though. fcitx's autostart 
doesn't really play well with ibus. This is, if ibus is configured and used, 
and both ibus and fcitx are installed, both would be running. Worst case 
scenario this means the user has 3 input method indicators active in the 
system tray (ibus, fcitx and xkb)

I "fixed" this by making fcitx' autostart dependent on the user's .bashrc 
entries, so it only starts if fcitx is configured as input method using the 
before mentioned entries. I added a similar autostart script for ibus, with 
the effect that now at least only the one configured for the user is running 
and the user doesn't have to worry about the autostart part of the setup.

= Distro comparison =

While researching this initial setup routine I looked around at what other 
distros are doing, only to find that mostly all of them do something 
different.

- Debain uses im-switch, which seems to be this: https://github.com/pkg-ime/
im-switch
- Opensuse uses im-config. I couldn't really find the source for that, but it 
looks to work similar to Debian's im-switch
- Fedora uses some kind of mechanism with xinputrc and xinput.d in order to 
load input methods during startup. Couldn't really find too much documentation 
about this either though :-/

= Future =

Generally I'm very happy with this effort and I'm looking forward to an 
improved input method integration in Plasma 5. However, putting my distro-hat 
on, I really think that this is a problem that goes beyond Plasma 5. I 
understand that desktop specific solutions need to be found, but the same 
issue exists on other desktop environments and it would be a shame if they 
have to reinvent the wheel on their end again. Eike mentioned fragmentation in 
the input method field and I'd say this definitely adds to that fragmentation. 
If whatever solution is eventually picked leaves the door open for other 
desktop environments to provide the same kind of integration I think this 
would definitely be appreciated :)

Grs,
Heinz

signature.asc
Description: This is a digitally signed message part.

Re: Complex text input in Plasma

2017-04-06 Thread 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

2017-04-06 Thread Martin Gräßlin


Am 2017-04-06 21:50, schrieb Eike Hein:


Weng as both a fcitx and Plasma developer is at a critical
intersection here: You and Martin will need to work together on
how fcitx can fit into a kwin_wayland world.


may I suggest a name change here: please replace Martin by Eike :-)

I think you are a way better fit to work on it as I'm just not that 
familiar with the stack and to me input is still something new. I'm 
happy to have interested devs to take over this part in KWin.


Cheers
Martin

Re: Complex text input in Plasma

2017-04-06 Thread Martin Gräßlin


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.


Cheers
Martin

Re: Complex text input in Plasma

2017-04-06 Thread 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

Jenkins-kde-ci: plasma-tests master kf5-qt5 » Linux,gcc - Build # 909 - Unstable!

2017-04-06 Thread no-reply


GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-tests%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/909/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Fri, 07 Apr 2017 03:16:02 +
Build duration: 3 min 33 sec

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 2 test(s), Skipped: 0 test(s), Total: 3 
test(s)Failed: TestSuite.org.kde.plasma.kickoff-test

COBERTURA RESULTS

Cobertura Coverage Report
  

By packages

Jenkins-kde-ci: plasma-desktop Plasma-5.9 stable-kf5-qt5 » Linux,gcc - Build # 112 - Still Unstable!

2017-04-06 Thread no-reply


GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-desktop%20Plasma-5.9%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/112/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Fri, 07 Apr 2017 03:10:42 +
Build duration: 7 min 39 sec

CHANGE SET
Revision 26384cf5454fc5ddaf50847278caccd9edce4a41 by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit 
layout-templates/org.kde.plasma.desktop.appmenubar/metadata.desktop
  change: edit applets/icontasks/metadata.desktop
  change: edit applets/taskmanager/package/metadata.desktop


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 7 
test(s)Failed: TestSuite.appstreamtest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 7/7 (100%)FILES 36/39 (92%)CLASSES 36/39 (92%)LINE 2306/3420 
(67%)CONDITIONAL 1566/3802 (41%)

By packages
  
kcms.cursortheme.xcursor
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 99/192 (52%)CONDITIONAL 
22/98 (22%)
kcms.keyboard
FILES 20/23 (87%)CLASSES 20/23 (87%)LINE 743/1511 
(49%)CONDITIONAL 619/1711 (36%)
kcms.keyboard.preview
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 500/582 (86%)CONDITIONAL 
432/1112 (39%)
kcms.keyboard.tests
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 229/231 (99%)CONDITIONAL 
236/358 (66%)
kcms.krdb
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 348/401 (87%)CONDITIONAL 
108/196 (55%)
kcms.lookandfeel
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 282/398 (71%)CONDITIONAL 
95/219 (43%)
kcms.lookandfeel.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 105/105 
(100%)CONDITIONAL 54/108 (50%)

Jenkins-kde-ci: plasma-desktop master kf5-qt5 » Linux,gcc - Build # 702 - Still unstable!

2017-04-06 Thread no-reply


GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-desktop%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/702/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Fri, 07 Apr 2017 02:10:33 +
Build duration: 11 min

CHANGE SET
Revision 5374cf65da045c909f8c7d77b10c683415b76ad5 by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit applets/taskmanager/package/metadata.desktop
  change: edit applets/icontasks/metadata.desktop
  change: edit 
layout-templates/org.kde.plasma.desktop.appmenubar/metadata.desktop


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 7 
test(s)Failed: TestSuite.appstreamtest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 7/7 (100%)FILES 36/39 (92%)CLASSES 36/39 (92%)LINE 2306/3420 
(67%)CONDITIONAL 1546/3761 (41%)

By packages
  
kcms.cursortheme.xcursor
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 99/192 (52%)CONDITIONAL 
22/98 (22%)
kcms.keyboard
FILES 20/23 (87%)CLASSES 20/23 (87%)LINE 743/1511 
(49%)CONDITIONAL 600/1672 (36%)
kcms.keyboard.preview
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 500/582 (86%)CONDITIONAL 
431/1110 (39%)
kcms.keyboard.tests
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 229/231 (99%)CONDITIONAL 
236/358 (66%)
kcms.krdb
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 348/401 (87%)CONDITIONAL 
108/196 (55%)
kcms.lookandfeel
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 282/398 (71%)CONDITIONAL 
95/219 (43%)
kcms.lookandfeel.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 105/105 
(100%)CONDITIONAL 54/108 (50%)

D5034: Add support for x-gvfs style options in fstab

2017-04-06 Thread Stefan Brüns

bruns added inline comments.

INLINE COMMENTS

> fstabdevice.cpp:47
>  
> -m_description = m_vendor + " on " + m_product;
> +const QStringList &gvfsOptions = 
> FstabHandling::options(m_device).filter("x-gvfs-");
> +

Why QStringList& instead of QStringList?

> fstabdevice.cpp:51
> +if (option.startsWith(QLatin1String("x-gvfs-name="))) {
> +const QStringRef &encoded = 
> option.midRef(option.indexOf(QLatin1String("="), 11) + 1);
> +m_description = QUrl::fromPercentEncoding(encoded.toLatin1());

Useless &
use indexOf('=', 11) (i.e. QChar)

> fstabdevice.cpp:54
> +} else if (option.startsWith(QLatin1String("x-gvfs-icon="))) {
> +const QStringRef &encoded = 
> option.midRef(option.indexOf(QLatin1String("="), 11) + 1);
> +m_iconName = QUrl::fromPercentEncoding(encoded.toLatin1());

use indexOf('=', 11)

REPOSITORY
  R245 Solid

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

To: broulik, #plasma, dfaure, dhaumann
Cc: bruns, dhaumann, plasma-devel, #frameworks, progwolff, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol

D5309: Hoist the actions overlay out of the frame loader.

2017-04-06 Thread Eike Hein

hein added a comment.


  [10:14:07]  Sho_: listview mode in popup is broken in RTL in 
FolderView with your patch (didnt check if it's actually the patch but I recall 
it working)
  [10:18:26]  kbroulik: i saw that but i felt like i saw it in the past 
and it fixes itself if you keyboard nav so i chalked it up to the usual qt 
gridview rtl bugs
  [10:18:46]  are you sure it doesn't happen without the patch?
  [10:20:38]  no, let me try
  [10:21:06]  git stash'd my p-d and now it's working
  [10:21:28]  git stash apply, now it's broken again
  
  For me it happens with and without this patch, doesn't seem related.

REPOSITORY
  R119 Plasma Desktop

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

To: hein, #plasma, broulik
Cc: plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol

D5317: [Folder View] Position sub folder popup left-of visual parent in RTL layout

2017-04-06 Thread Eike Hein

hein accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R119 Plasma Desktop

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

To: broulik, #plasma, hein, safaalfulaij
Cc: plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol

Re: Complex text input in Plasma

2017-04-06 Thread 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.

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: Complex text input in Plasma

2017-04-06 Thread Weng Xuetian

On Thursday, 6 April 2017 10:27:40 PDT，Eike Hein wrote：
> > = Screenshots =
> 
> Here's an example of the emoji IME mentioned earlier:
> 
> https://fedoramagazine.org/using-favorite-emoji-fedora-25/
> 
> 
> Cheers,
> Eike

As a side note, I used to implment a ugly imchooser for KDE around KDE4 time, 
which helps to select which input method 

https://www.linux-apps.com/content/show.php/kcm+imchooser?content=146776

If we don't want to go the GNOME way (solely select one input method 
frameworks to work with), I guess one thing we can do is to add an additonal 
section in "default application" kcm, and provides necesary profile, so kwin 
will also be able to learn which im to start, and what need to be set up.

the profile may also provide a "none" which fallback to the old switcher.

Re: Complex text input in Plasma

2017-04-06 Thread Weng Xuetian

On Thursday, 6 April 2017 10:16:14 PDT，Eike Hein wrote：
> Hi,
> 
> In the aftermath of D5301, Martin asked to compile a document on the
> requirements for complex text input in Plasma, especially with the
> opportunities provided by the Wayland transition. It makes sense to
> share this document with all of you, to
> 
> 
> = I. What Input Methods do =
> 
> Basically, with simple text input (and skipping a few stack steps in
> this explanation), the user presses a key on the keyboard, it's
> interpreted according to the active layout, and results in a symbol
> on screen (modulo complicated ideas like dead keys and the Compose
> key, which also enter into input method territory as we'll see).
> 
> With some writing system, this isn't enough. They require multiple
> key presses or pick-and-choose selection steps to produce a symbol.
> The general idea is to disconnect the input from the output and
> introduce a conversion inbetween that's more complex than a mere
> keyboard layout. The conversion itself may have complex UI like
> temporary feedback in the textfield, popups positioned relative
> to the text field, or state visualization in shell chrome.
> 
> There are other ways to access input methods than just the keyboard
> these days, too. I'll briefly mention one of them later.
> 
> 
> = II. Practical examples of Input Method use =
> 
> a) Korean
> 
> Korean is written using an alphabet similar to German. It has about
> the same number of letters, with each letter representing a vowel,
> a consonant, or a diphtong.
> 
> On computers, each letter has its own key on the keyboard. As with
> German, there are multiple keyboard layouts for the Korean alphabet,
> although one is dominant and considered standard by far.
> 
> Unlike the German alphabet however, letters in the Korean alphabet
> are grouped together into (morpho-)syllabic blocks when written.
> Each block must start with a consonant and contain a vowel or
> diphtong. It may optionally end in one or two consonants.
> 
> Here are some letters and their corresponding Latin latterns (the
> sounds they most closely correspond to - theeir locations in the
> keyboard layout do not match QWERTY/QWERTZ):
> 
> ㅎ h
> ㅏ a
> ㄴ n
> 
> In linear order these form the syllable "han". When written
> properly, these are groupedtogether:
> 
> 한 han
> 
> In the UI, when pressing the keyboard keys for each letter, the
> text field contents cycle through these stages:
> 
> ㅎ
> 하
> 한
> 
> As you can see, the existing text is replaced two times, making
> the operation stateful. The Input Method Engine generates complex
> events with text payload, state hints, even formatting hints (some
> IMEs use text color, e.g. color inversion, to communicate state
> such as "this input is not finalized yet") that are delivered to
> the application. In Qt, a plugin corresponding to the Input Method
> (e.g. ibus or fcitx) translates these events into QInputMethodEvent
> objects that are delivered to widgets and processed there.
> 
> The rules of the Korean alphabet additionally have some
> implications for cursor movement/behavior. E.g. because it's not
> allowed to start a block with two consonants, and because the number
> of vowels and ending consonants is limited, as keys are pressed a
> block might implicitly finish composing and the cursor moves on.
> 
> b) Chinese
> 
> There are many different strategies for inputting Chinese
> characters. The most common actually makes use of the Latin
> alphabet, and keyboard layouts for the Latin alphabet. Chinese
> characters have assigned sound values (i.e., how a human actually
> pronounces a character), and there are rule systems to transcribe
> these using the Latin alphabet, e.g. Pinyin.
> 
> As users write some Pinyin using Latin characters, a selection
> popup will offer a list of Chinese characters matching the input.
> The user picks one and it's inserted into the text field.
> 
> Chinese input methods try to be very smart in what characters
> they offer, taking preceding input, common phrasings, etc. into
> account, making them highly stateful things.
> 
> c) Modes, Input Method overlap
> 
> Korean used to be written using Chinese characters (this simple
> statement is the tip of a large iceberg of complicated history
> and rulesets :), and especially Korean Academic writing still
> makes use of them. Korean input methods wherefore tend to also
> offer the ability to type Chinese characters, with a mode toggle
> between them.
> 
> Korean input methods also usually have a Hangul (the Korean
> alphabet) vs. Latin mode toggle.
> 
> Chinese input methods tend to have mode toggles for things like
> chosing between half-width and full-width characters, i.e. also
> offer control over typography.
> 
> Japanese is a mashup of all of these things, with Japanese users
> typing in two Japanese-specific syllabaries, Chinese characters
> and Latin during a typical session.
> 
> 
> = Other uses for input methods =
> 
> The ever more popular Emoji c

Re: Complex text input in Plasma

2017-04-06 Thread Eike Hein

On 04/07/2017 04:21 AM, Martin Gräßlin wrote:
> that's actually also a feature of the keyboard daemon we have on X11.
> Only on wayland KWin takes care of it.

Aye, I kind of used KWin as an insert for our whole amalgamation of
shell infra there.

> Ideally we would build up on this. We must not (!) specify an input
> plugin for Qt apps as that would break the virtual keyboard. And even if
> others give up on convergence I still think it's important to support it
> and have it as a target.
> 
> So for input methods KWin would have to provide the UI interaction. Of
> course I do not want to rebuild such a stack but would prefer to be able
> to hook into an existing - I hope that's possible. Maybe a similar
> approach as to how virtual keyboard works: kwin just emulates to the
> qtvirtualkeyboard like if it were in application. So maybe KWin could
> load one of the plugins and interact with them as a proxy for the
> application and just forward the result through the text input interface.

It's super imperative that we work together with the input method
community, then.

This space only has relatively few active developers unfortunately,
and the developer base is already spread thin over multiple
competing stacks. Additionally, much of the development activity
doesn't even happen in the core, but at the fringes, in the form
of IME plugins that are often developed by local communities in
isolation from the core - due to language barrier effects.

If KWin were to introduce another entirely new IME plugin API to
target, we'd further fragment the ecosystem, require IME developers
to duplicate much work, and potentially miss out on work that
continues to be done against other APIs.

(It's important to point out that IMEs are not "done". Emoji IMEs
are a recent development, and things how "How best to type Chinese
into a computer?" are still open questions that see active
experimentation, despite established solutions. Last but not least,
not every popular writing system is covered by free systems
already: There are still entire populations that basically can't
type text on a free desktop system. Bottom line, an important
requirement is future extensibility and trying to funnel work done
our way.)

This fragmentation has a big burden all around - most importantly
on users, because tons of IME plugins are single-person projects
with quality issues. As good platform shepards we should recognize
these systemic problems and try to heal them. The goal being
"bring high-quality text input to as many people as possible" and
any steps measured by that yardstick.

Fortunately the way the stack has stratified, we do control the
UI frontend (or rather we offer one of our own at least, as per
my longer overview). Input Method Panel's popup stuff may wander
into KWin along with other interaction bits - we're free to do
that.

Weng as both a fcitx and Plasma developer is at a critical
intersection here: You and Martin will need to work together on
how fcitx can fit into a kwin_wayland world.

We should also look beyond our borders and look at how ibus
on Gnome/Wayland is being done.

> What I could imagine is that we start with emoji support. Might sound
> weird but is a simplified use case to just "play" with it and
> experiment. We could setup a global shortcut (like the one in GNOME),
> pop up a UI with the emoji selection and go through the text input
> protocol to send the emoji into the application.

We could definitely use that to prototype interaction bits and
stub out the backend part for now. As mentioned ideally the business
logic for it would eventually come from a fcitx/ibus plugin.

Cheers,
Eike

D5252: Introduce dedicated actions for touch screen swipe gestures

2017-04-06 Thread Martin Gräßlin

graesslin added a comment.


  ping! As I have dependencies already accepted it would be nice to be able to 
push the complete set ;-)

REPOSITORY
  R108 KWin

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

To: graesslin, #kwin, #plasma
Cc: plasma-devel, kwin, progwolff, lesliezhai, ali-mohamed, hardening, 
jensreuterberg, abetts, sebas, apol

D5249: [RFC] New effect plugin - projector (keystone) correction

2017-04-06 Thread Martin Gräßlin

graesslin added a comment.


  In https://phabricator.kde.org/D5249#100193, @nowicki wrote:
  
  > The idea that I have in mind ATM is to redirect drawing the whole screen 
into a FBO and then draw it screen by screen applying transformation where 
necessary. This should be fairly easy thanks to the render target stack in 
KWin. Doing it this way would get rid of the ugly artifacts at window edges. 
The downside is that it introduces a requirement for maximum texture size to be 
at least the size of the virtual desktop (already imposed by the blur and 
backgroundcontrast effects). I'm planning to run this on an old Intel Pineview 
and I hope it would have enough juice to handle this.
  
  
  Out from past experience with that: using a full screen fbo and redirect the 
complete rendering to it results in about half the frame rate. Though the 
architecture through framebuffer blit improved.

REPOSITORY
  R108 KWin

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

To: nowicki, #plasma, graesslin
Cc: luebking, kwin, plasma-devel, #kwin, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol

Re: Complex text input in Plasma

2017-04-06 Thread Martin Gräßlin


Am 2017-04-06 19:16, schrieb Eike Hein:

Hi,

In the aftermath of D5301, Martin asked to compile a document on the
requirements for complex text input in Plasma, especially with the
opportunities provided by the Wayland transition. It makes sense to
share this document with all of you, to


Thanks for the nice write down.


* KWin is smart enough to do cool things like switch keyboard
  layouts automatically per virtual desktop or even window


that's actually also a feature of the keyboard daemon we have on X11. 
Only on wayland KWin takes care of it.



= The situation on Wayland =

Currently, only ibus works on Wayland. Input method popups are not
positioned correctly, but otherwise things work. The situation is
just as good or bad as on X11.


Sharing a bit more about state of Wayland:

There is the text-input protocol which KWin supports and uses for 
virtual keyboard. This means we already have the possibility to do 
things like text input, text prediction, cursor moving, styling hints 
(not yet implemented as virt keyboard doesn't support it), etc. etc. out 
of the box with Qt applications. We know whether the application 
supports it. We know the position of the text field and much more. For 
those interested: relevant code is in KWin/virtualkeyboard.cpp


Ideally we would build up on this. We must not (!) specify an input 
plugin for Qt apps as that would break the virtual keyboard. And even if 
others give up on convergence I still think it's important to support it 
and have it as a target.


So for input methods KWin would have to provide the UI interaction. Of 
course I do not want to rebuild such a stack but would prefer to be able 
to hook into an existing - I hope that's possible. Maybe a similar 
approach as to how virtual keyboard works: kwin just emulates to the 
qtvirtualkeyboard like if it were in application. So maybe KWin could 
load one of the plugins and interact with them as a proxy for the 
application and just forward the result through the text input 
interface.


What I could imagine is that we start with emoji support. Might sound 
weird but is a simplified use case to just "play" with it and 
experiment. We could setup a global shortcut (like the one in GNOME), 
pop up a UI with the emoji selection and go through the text input 
protocol to send the emoji into the application.


Unfortunately text input in Wayland is weird as there are two competing 
protocol versions and Qt has one of them. There is the zwp_text_input_v1 
which is part of Wayland-protocols and zwp_text_input_v2 which is part 
of Qt. It is not upstreamed, but uses upstream naming conventions. Which 
will result in a horrible mess once upstream introduces a 
zwp_text_input_v2. KWin supports both versions at the same time, but it 
makes everything more complex and we currently can only assume that it 
works correctly with Qt apps. The GTK version we support on Wayland 
neither supports v1 nor v2. For the newer GTK versions which we do not 
support yet I do not know. Also it leaves out Xwayland application but 
there a bridge to one of the existing X11 solutions is thinkable.


Cheers
Martin

D5324: Revert "[calendar] Use ui language for getting the month name"

2017-04-06 Thread David Rosca

drosca abandoned this revision.
drosca added a comment.


  > However, if your UI language is all Spanish and you want to use the US date 
formatting, the month name labels would suddenly be in English while they 
should remain Spanish (and this is what the code you're removing does).
  
  Well, that's probably what you would want, but it's definitely not what you 
actually get in the current state. The whole calendar applet is in Czech for me 
(my UI language is English) - month and day names, only this one label is in 
English because it uses the string from C++ part (that was fixed).
  
  Alright, I'll work on the QML fix instead.

REPOSITORY
  R242 Plasma Framework (Library)

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

To: drosca, #plasma, mck182
Cc: plasma-devel, #frameworks, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol

D5324: Revert "[calendar] Use ui language for getting the month name"

2017-04-06 Thread Martin Klapetek

mck182 added a comment.


  I disagree with this because we currently don't have any
  easy and/or sensible way to change date formats and so
  we simply suggest using different locales for the different
  formats. However, if your UI language is all Spanish and
  you want to use the US date formatting, the month name
  labels would suddenly be in English while they should
  remain Spanish (and this is what the code you're removing
  does).
  
  This should probably be fixed in the QML side to use the
  same approach so that all month and day names are using
  the same language, which should follow LANG, not LC_DATE.

REPOSITORY
  R242 Plasma Framework (Library)

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

To: drosca, #plasma, mck182
Cc: plasma-devel, #frameworks, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol

[kio-extras] [Bug 376344] cant write to smb shares which has write access

2017-04-06 Thread Brett Keller

https://bugs.kde.org/show_bug.cgi?id=376344

Brett Keller  changed:

   What|Removed |Added

 CC||blkel...@comcast.net

--- Comment #8 from Brett Keller  ---
Seeing this as well on a fresh install of KDE Neon User LTS.

-- 
You are receiving this mail because:
You are the assignee for the bug.

D5324: Revert "[calendar] Use ui language for getting the month name"

2017-04-06 Thread David Rosca

drosca created this revision.
Restricted Application added projects: Plasma, Frameworks.
Restricted Application added subscribers: Frameworks, plasma-devel.

REVISION SUMMARY
  Qt.locale().standaloneMonthName() is used from QML side in MonthView,
  so using the same code on C++ part again makes the month name in DaysView
  have the same language.
  
  This reverts commit 
https://phabricator.kde.org/R242:6f3fed77d59227a9b3ec85d343ffb2443086f7fa.

TEST PLAN
  I use Czech for numbers, time, currency, units and English for everything
  else. Now the calendar applet have all dates correctly in Czech.

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  master

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

AFFECTED FILES
  src/declarativeimports/calendar/calendar.cpp

To: drosca, #plasma, mck182
Cc: plasma-devel, #frameworks, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol

D5249: [RFC] New effect plugin - projector (keystone) correction

2017-04-06 Thread Krzysztof Nowicki

nowicki added a comment.


  The idea that I have in mind ATM is to redirect drawing the whole screen into 
a FBO and then draw it screen by screen applying transformation where 
necessary. This should be fairly easy thanks to the render target stack in 
KWin. Doing it this way would get rid of the ugly artifacts at window edges. 
The downside is that it introduces a requirement for maximum texture size to be 
at least the size of the virtual desktop (already imposed by the blur and 
backgroundcontrast effects). I'm planning to run this on an old Intel Pineview 
and I hope it would have enough juice to handle this.

REPOSITORY
  R108 KWin

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

To: nowicki, #plasma, graesslin
Cc: luebking, kwin, plasma-devel, #kwin, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol

Re: Complex text input in Plasma

2017-04-06 Thread Eike Hein


> = Screenshots =

Here's an example of the emoji IME mentioned earlier:

https://fedoramagazine.org/using-favorite-emoji-fedora-25/


Cheers,
Eike

Re: Complex text input in Plasma

2017-04-06 Thread Eike Hein



On 04/07/2017 02:16 AM, Eike Hein wrote:
> 
> Hi,
> 
> In the aftermath of D5301, Martin asked to compile a document on the
> requirements for complex text input in Plasma, especially with the
> opportunities provided by the Wayland transition. It makes sense to
> share this document with all of you, to

*to share the knowledge more widely :)


Cheers,
Eike

Complex text input in Plasma

2017-04-06 Thread Eike Hein


Hi,

In the aftermath of D5301, Martin asked to compile a document on the
requirements for complex text input in Plasma, especially with the
opportunities provided by the Wayland transition. It makes sense to
share this document with all of you, to


= I. What Input Methods do =

Basically, with simple text input (and skipping a few stack steps in
this explanation), the user presses a key on the keyboard, it's
interpreted according to the active layout, and results in a symbol
on screen (modulo complicated ideas like dead keys and the Compose
key, which also enter into input method territory as we'll see).

With some writing system, this isn't enough. They require multiple
key presses or pick-and-choose selection steps to produce a symbol.
The general idea is to disconnect the input from the output and
introduce a conversion inbetween that's more complex than a mere
keyboard layout. The conversion itself may have complex UI like
temporary feedback in the textfield, popups positioned relative
to the text field, or state visualization in shell chrome.

There are other ways to access input methods than just the keyboard
these days, too. I'll briefly mention one of them later.


= II. Practical examples of Input Method use =

a) Korean

Korean is written using an alphabet similar to German. It has about
the same number of letters, with each letter representing a vowel,
a consonant, or a diphtong.

On computers, each letter has its own key on the keyboard. As with
German, there are multiple keyboard layouts for the Korean alphabet,
although one is dominant and considered standard by far.

Unlike the German alphabet however, letters in the Korean alphabet
are grouped together into (morpho-)syllabic blocks when written.
Each block must start with a consonant and contain a vowel or
diphtong. It may optionally end in one or two consonants.

Here are some letters and their corresponding Latin latterns (the
sounds they most closely correspond to - theeir locations in the
keyboard layout do not match QWERTY/QWERTZ):

ㅎ h
ㅏ a
ㄴ n

In linear order these form the syllable "han". When written
properly, these are groupedtogether:

한 han

In the UI, when pressing the keyboard keys for each letter, the
text field contents cycle through these stages:

ㅎ
하
한

As you can see, the existing text is replaced two times, making
the operation stateful. The Input Method Engine generates complex
events with text payload, state hints, even formatting hints (some
IMEs use text color, e.g. color inversion, to communicate state
such as "this input is not finalized yet") that are delivered to
the application. In Qt, a plugin corresponding to the Input Method
(e.g. ibus or fcitx) translates these events into QInputMethodEvent
objects that are delivered to widgets and processed there.

The rules of the Korean alphabet additionally have some
implications for cursor movement/behavior. E.g. because it's not
allowed to start a block with two consonants, and because the number
of vowels and ending consonants is limited, as keys are pressed a
block might implicitly finish composing and the cursor moves on.

b) Chinese

There are many different strategies for inputting Chinese
characters. The most common actually makes use of the Latin
alphabet, and keyboard layouts for the Latin alphabet. Chinese
characters have assigned sound values (i.e., how a human actually
pronounces a character), and there are rule systems to transcribe
these using the Latin alphabet, e.g. Pinyin.

As users write some Pinyin using Latin characters, a selection
popup will offer a list of Chinese characters matching the input.
The user picks one and it's inserted into the text field.

Chinese input methods try to be very smart in what characters
they offer, taking preceding input, common phrasings, etc. into
account, making them highly stateful things.

c) Modes, Input Method overlap

Korean used to be written using Chinese characters (this simple
statement is the tip of a large iceberg of complicated history
and rulesets :), and especially Korean Academic writing still
makes use of them. Korean input methods wherefore tend to also
offer the ability to type Chinese characters, with a mode toggle
between them.

Korean input methods also usually have a Hangul (the Korean
alphabet) vs. Latin mode toggle.

Chinese input methods tend to have mode toggles for things like
chosing between half-width and full-width characters, i.e. also
offer control over typography.

Japanese is a mashup of all of these things, with Japanese users
typing in two Japanese-specific syllabaries, Chinese characters
and Latin during a typical session.


= Other uses for input methods =

The ever more popular Emoji character set may turn writers of
languages which typically do not require an input method into
input method users.

On Fedora/Gnome systems, pressing Ctrl+Shift+e inserts a @
character into the text field, and typing a string such as
"heart" will select among suitable emoji (shown in a popup
akin

53 matches

Mail list logo