Jenkins-kde-ci: plasma-desktop Plasma-5.9 stable-kf5-qt5 » Linux,gcc - Build # 114 - Still Unstable!
GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/plasma-desktop%20Plasma-5.9%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/114/ Project: PLATFORM=Linux,compiler=gcc Date of build: Sun, 09 Apr 2017 03:15:34 + Build duration: 6 min 38 sec CHANGE SET Revision 94f796749a33a4e6015b04d1c58b0685531aeb0b by scripty: (SVN_SILENT made messages (.desktop file) - always resolve ours) change: edit kcms/colors/colors.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-workspace master kf5-qt5 » Linux,gcc - Build # 845 - Still Unstable!
GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/plasma-workspace%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/845/ Project: PLATFORM=Linux,compiler=gcc Date of build: Sun, 09 Apr 2017 02:09:22 + Build duration: 22 min CHANGE SET Revision b67d989399037c5b11d492e52f34dfef70480403 by scripty: (SVN_SILENT made messages (.desktop file) - always resolve ours) change: edit runners/appstream/appstreamrunner.desktop JUNIT RESULTS Name: (root) Failed: 1 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 11 test(s)Failed: TestSuite.appstreamtest COBERTURA RESULTS Cobertura Coverage Report PACKAGES 15/15 (100%)FILES 55/76 (72%)CLASSES 55/76 (72%)LINE 2336/5973 (39%)CONDITIONAL 1648/5946 (28%) By packages drkonqi.parser FILES 6/10 (60%)CLASSES 6/10 (60%)LINE 303/423 (72%)CONDITIONAL 478/616 (78%) drkonqi.tests.backtraceparsertest FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 74/74 (100%)CONDITIONAL 33/50 (66%) kioslave.desktop FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 110/144 (76%)CONDITIONAL 56/90 (62%) kioslave.desktop.tests FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 84/84 (100%)CONDITIONAL 37/72 (51%) klipper FILES 12/13 (92%)CLASSES 12/13 (92%)LINE 256/384 (67%)CONDITIONAL 109/210 (52%) klipper.autotests FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 630/693 (91%)CONDITIONAL 377/820 (46%) libtaskmanager FILES 6/21 (29%)CLASSES 6/21 (29%)LINE 196/3304 (6%)CONDITIONAL 122/3251 (4%) libtaskmanager.autotests FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 151/151 (100%)CONDITIONAL 85/170 (50%) runners.bookmarks FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 87/157 (55%)CONDITIONAL 34/96 (35%) runners.bookmarks.browsers FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 88/93 (95%)CONDITIONAL 84/107 (79%) runners.bookmarks.tests FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 65/65 (100%)CONDITIONAL 31/62 (50%) runners.services FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 128/201 (64%)CONDITIONAL 117/206 (57%) runners.services.autotests FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 67/70 (96%)CONDITIONAL 50/90 (56%) shell FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 57/90 (63%)CONDITIONAL 20/76 (26%) shell.autotests FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 40/40 (100%)CONDITIONAL 15/30 (50%)
Jenkins-kde-ci: plasma-desktop master kf5-qt5 » Linux,gcc - Build # 705 - Still Unstable!
GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/plasma-desktop%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/705/ Project: PLATFORM=Linux,compiler=gcc Date of build: Sun, 09 Apr 2017 02:08:52 + Build duration: 6 min 59 sec CHANGE SET Revision c5911b52a6b8fd57f2a53239102dcab60e25 by scripty: (SVN_SILENT made messages (.desktop file) - always resolve ours) change: edit kcms/colors/colors.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%)
Re: Complex text input in Plasma
On Saturday, 8 April 2017 12:43:54 PDT，Martin Gräßlin wrote： > Am 2017-04-08 21:21, schrieb Weng Xuetian: > > On Saturday, 8 April 2017 09:46:17 PDT，Martin Gräßlin 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/qwaylandintegrat > >> ion .cpp#n142 > > > > What I want to say is, if you set QT_IM_MODULE to qtvirtualkeyboard, > > that app > > can't talk to im daemon via the wayland protocol. The automatic > > selection > > procedure is not really a problem there. > > And that's not the case. Our virtual keyboard is using the Wayland text > input protocol and does not require setting the QT_IM_MODULE at all. > > Please believe a little bit in what I'm writing. I coded this stuff. > > > Also, running it inside kwin could still be problematic. It'll also > > need to > > display UI. From what I heard about, to run a qml window inside kwin > > could > > even be a problem. > > I don't know what you have heard but all our UI in KWin is written in > Qml nowadays. > > > The races you pointed about is not really a problem. Weston has already > > done > > it well. Unless you want to reinvent a new protocol, using the current > > wayland > > protocol essentially does what I said. And if such a thing would > > interfere > > with kwin's rendering procedure, then probably kwin should refactor > > about > > that. > > Just because Weston doesn't think of this problem doesn't mean it > doesn't exist. Weston is not perfect and I found several bugs in the way > they implemented the protocols they developed and Weston is the > reference for. > > > And let me give you some number here, a modern input method for Chinese > > could > > takes about 30ms to handle one single key (it is THAT complex and we > > are all > > limited by the complexity, though I measured it about 5 years ago). You > > really > > want to have kwin block on that and wait for such a long time? And just > > because it is such a slow thing, the IPC latency is not even > > comparable. If > > you want good prediction or handwriting, it will be slow. There's no im > > use > > neural network on linux right now, but iOS's virtual keyboard is > > already doing > > that. Which might be the future, but also mean the im processing time > > might > > not slow down. > > I don't want to base any decisions on 5 year old numbers. 30 msec would > be bad, but if it is with modern hardware just 10 it wouldn't be that > bad. 30ms is almost the maximum time that I found it would be accepted by the user. But it also means that if it is ok, we could put more computation into it to achieve better result. Also, I do feel that synchronously wait for input method result would be bad. In our customized im module era, we are also moving to synchronous wait to key event processing result to asynchronous. As you said their exists same problem, but overall it improves the responsivieness when something does go wrong (when it's not a bug it could be memory or disk io). > > > Also the "input method always on" idea is not saying that every single > > key > > will be send to input method, it just mean whenever user need type > > text, it > > will be forwarded to input method. > > > > I don't know whether I could persuade you, but please look around the > > world, > > iOS, android, sailfish (also use wayland), mac OS , (windows used to > > run im > > directly inside application.. but now they also have a service for that > > ), no > > one would run a im daemon inside the compositor. Are they all ignore > > the ipc > > overhead? > > I'm using sailfish and Android and both keyboards suck bad times. > Sailfish is really bad, well it's maliit so no surprise there. With both > systems I see problems in UI positioning because it's not in the > compositor. Both don't feel perfect especially not in the "every frame > perfect sense" we are aiming for on Wayland. > But afterall, running fcitx as a library is possible since it is how it is implemented. Technically there's no such difficulty prevent us to do so. And I have been using fcitx as a library for testing purpose. But I guess the story is different for ibus, ibus is multi-process and its engine always running in different process, and it will always need to pass some ipc to its own engine. On the bright side, I could bypass the ugly zwp_input_method_v1
Akademy 2017 Call for Papers deadline is this Monday!
I'm sure you're working on some amazing things you want to let the community know about, so head to https://akademy.kde.org/2017/cfp And submit your proposal! Cheers, Albert
D5144: Change the volume icon/mute button into a ToolButton
This revision was automatically updated to reflect the committed changes. Closed by commit R115:2ac365e96b70: Change the volume icon/mute button into a ToolButton (authored by Zren). REPOSITORY R115 Plasma Audio Volume Applet CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D5144?vs=13070=13242 REVISION DETAIL https://phabricator.kde.org/D5144 AFFECTED FILES applet/contents/ui/ListItemBase.qml applet/contents/ui/SmallToolButton.qml To: Zren, #plasma, subdiff, drosca Cc: mart, subdiff, drosca, plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
Re: Default touch screen edge gestures
Am 2017-04-08 19:40, schrieb Ivan Čukić: Hi Martin, I think this needs more in-depth investigation. That's exactly why I put up this thread! From my point of view, window switching, present windows and the desktop grid are essentially the same thing. The best solution IMO would be to combine them all, Wishful thinking :-) I wanted to have that for years: https://blog.martin-graesslin.com/blog/2013/04/hitting-walls-a-story-of-present-windows-2/ and the UI should not be the same for all devices. For example, on a medium screen, for devices that are handheld, window switcher is perfect since the window list is reachable with the finger the user swiped with. For small screens, that is on the phones, the whole screens should be coverable by 'the finger', so a whole screen could be used for the switching (like present windows). On larger devices that are not handhelds, but are still touch-enabled, we could have a desktop grid, or some present windows + present virtual desktops switcher. I wasn't exactly clear on for what I want to have the gestures. The gestures should be for notebooks which have touch screens. Plasma phone needs completely different gestures and giving the design it should just disable all. For convertables (e.g. Lenovo Yoga) the same gestures as for notebooks might make sense but it would also be possible to consider different gestures once it's in "tablet" mode. But we currently aren't able to detect that at all, so for the moment we only need to consider what we support: notebooks with touch screens. Personally I think that this will be a feature which we will advertise in the release announcement and we must define some default gestures, otherwise we just look unpolished. We should assign a gesture even if we would want a better fitting UI - we don't have that and we won't get that any time soon. So better trigger Alt+Tab than no window switching at all. Cheers Martin
Re: Complex text input in Plasma
Am 2017-04-08 21:21, schrieb Weng Xuetian: On Saturday, 8 April 2017 09:46:17 PDT，Martin Gräßlin 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 What I want to say is, if you set QT_IM_MODULE to qtvirtualkeyboard, that app can't talk to im daemon via the wayland protocol. The automatic selection procedure is not really a problem there. And that's not the case. Our virtual keyboard is using the Wayland text input protocol and does not require setting the QT_IM_MODULE at all. Please believe a little bit in what I'm writing. I coded this stuff. Also, running it inside kwin could still be problematic. It'll also need to display UI. From what I heard about, to run a qml window inside kwin could even be a problem. I don't know what you have heard but all our UI in KWin is written in Qml nowadays. The races you pointed about is not really a problem. Weston has already done it well. Unless you want to reinvent a new protocol, using the current wayland protocol essentially does what I said. And if such a thing would interfere with kwin's rendering procedure, then probably kwin should refactor about that. Just because Weston doesn't think of this problem doesn't mean it doesn't exist. Weston is not perfect and I found several bugs in the way they implemented the protocols they developed and Weston is the reference for. And let me give you some number here, a modern input method for Chinese could takes about 30ms to handle one single key (it is THAT complex and we are all limited by the complexity, though I measured it about 5 years ago). You really want to have kwin block on that and wait for such a long time? And just because it is such a slow thing, the IPC latency is not even comparable. If you want good prediction or handwriting, it will be slow. There's no im use neural network on linux right now, but iOS's virtual keyboard is already doing that. Which might be the future, but also mean the im processing time might not slow down. I don't want to base any decisions on 5 year old numbers. 30 msec would be bad, but if it is with modern hardware just 10 it wouldn't be that bad. Also the "input method always on" idea is not saying that every single key will be send to input method, it just mean whenever user need type text, it will be forwarded to input method. I don't know whether I could persuade you, but please look around the world, iOS, android, sailfish (also use wayland), mac OS , (windows used to run im directly inside application.. but now they also have a service for that ), no one would run a im daemon inside the compositor. Are they all ignore the ipc overhead? I'm using sailfish and Android and both keyboards suck bad times. Sailfish is really bad, well it's maliit so no surprise there. With both systems I see problems in UI positioning because it's not in the compositor. Both don't feel perfect especially not in the "every frame perfect sense" we are aiming for on Wayland. Cheers Martin
Re: Complex text input in Plasma
On Saturday, 8 April 2017 09:46:17 PDT，Martin Gräßlin 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 What I want to say is, if you set QT_IM_MODULE to qtvirtualkeyboard, that app can't talk to im daemon via the wayland protocol. The automatic selection procedure is not really a problem there. > > 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. > > > So, my proposal to this will be: > > im daemon <-> kwin <-> application, and the communication is done with > > some > > wayland protocol. > > > > and imho that would be best option to all people. Here's the reason > > > > Pros > > - less code to run within kwin process > > - less change needed to existing im daemon (we just need an extra > > frontend) > > and kwin > > - no hard dependency > > > > Cons: > > more ipc latency, but this only happens if user need to type. > > The IPC latency is a huge problem here. If we want to have a good > experience KWin needs to decide whether to send a key event to the IM > daemon or through wl_keyboard interface to the application. This means > possibly a roundtrip in the event handling code. This code is currently > the most crucial part of KWin. It opens a can of worms if we go IPC > there and given your suggestion it needs IPC. > > And even if we handle it without roundtrip we run into timing issues. > Consider: > * KWin gets key event > * KWin decides it goes to IM for window foo > * IM does something with it > * window foo closes > * IM sends the composed text for window foo to KWin > > Now what? In case we would eliminate the IPC by making KWin link the IM > module it becomes: > > * KWin gets key event > * KWin decides it goes to IM for window foo > * IM returns the composed text for window foo > * KWin forwards the composed text to window foo > * window foo closes > > So from KWin perspective everything becomes cleaner if there is no IPC > involved towards the IM daemon. In that case KWin needs to adjust way > less as we don't need a dedicated protocol. > > I understand your concerns with linking stuff and loading plugins but I > don't share them. Yes I also see this as a problem but I think it's less > of a problem than IPC in this crucial area. Then why IPC exists in the first place? The whole wayland stuff IS IPC. Why there ARE processes?.. Also, running it inside kwin could still be problematic. It'll also need to display UI. From what I heard about, to run a qml window inside kwin could even be a problem. The races you pointed about is not really a problem. Weston has already done it well. Unless you want to reinvent a new protocol, using the current wayland protocol essentially does what I said. And if such a thing would interfere with kwin's rendering procedure, then probably kwin should refactor about that. And let me give you some number here, a modern input method for Chinese could takes about 30ms to handle one single key (it is THAT complex and we are all limited by the complexity, though I measured it about 5 years ago). You really want to have kwin block on that and wait for such a long time? And just because it is such a slow thing, the IPC latency is not even comparable. If you want good prediction or handwriting, it will be slow. There's no im use neural network on linux right now, but iOS's virtual keyboard is already doing that. Which might be the future, but also mean the im processing time might not slow down. Also the "input method always on" idea is not saying that every single key will be send to input method, it just mean whenever user need type text, it will be forwarded to
Re: Default touch screen edge gestures
Hi Martin, I think this needs more in-depth investigation. We've had a couple of, I'd say, knee jerk shortcuts pushed to master without much thought about them (Alt+Space for KRunner, Meta+number for tasks). >From my point of view, window switching, present windows and the desktop grid are essentially the same thing. The best solution IMO would be to combine them all, and the UI should not be the same for all devices. For example, on a medium screen, for devices that are handheld, window switcher is perfect since the window list is reachable with the finger the user swiped with. For small screens, that is on the phones, the whole screens should be coverable by 'the finger', so a whole screen could be used for the switching (like present windows). On larger devices that are not handhelds, but are still touch-enabled, we could have a desktop grid, or some present windows + present virtual desktops switcher. Cheers, Ivan
D5355: Fix query for available modules
aacid created this revision. Restricted Application added a project: Plasma. Restricted Application added a subscriber: plasma-devel. REVISION SUMMARY The old query was bad because two reasons: - it didn't use the same query systemsettings uses fo - it didn't use exist so if the first property did not exist the second one was not evaluated since the parser bailed out TEST PLAN Ran kcmshell5 --list, it's better now REPOSITORY R126 KDE CLI Utilities BRANCH Plasma/5.8 REVISION DETAIL https://phabricator.kde.org/D5355 AFFECTED FILES kcmshell/main.cpp To: aacid Cc: plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
Re: Complex text input in Plasma
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. So, my proposal to this will be: im daemon <-> kwin <-> application, and the communication is done with some wayland protocol. and imho that would be best option to all people. Here's the reason Pros - less code to run within kwin process - less change needed to existing im daemon (we just need an extra frontend) and kwin - no hard dependency Cons: more ipc latency, but this only happens if user need to type. The IPC latency is a huge problem here. If we want to have a good experience KWin needs to decide whether to send a key event to the IM daemon or through wl_keyboard interface to the application. This means possibly a roundtrip in the event handling code. This code is currently the most crucial part of KWin. It opens a can of worms if we go IPC there and given your suggestion it needs IPC. And even if we handle it without roundtrip we run into timing issues. Consider: * KWin gets key event * KWin decides it goes to IM for window foo * IM does something with it * window foo closes * IM sends the composed text for window foo to KWin Now what? In case we would eliminate the IPC by making KWin link the IM module it becomes: * KWin gets key event * KWin decides it goes to IM for window foo * IM returns the composed text for window foo * KWin forwards the composed text to window foo * window foo closes So from KWin perspective everything becomes cleaner if there is no IPC involved towards the IM daemon. In that case KWin needs to adjust way less as we don't need a dedicated protocol. I understand your concerns with linking stuff and loading plugins but I don't share them. Yes I also see this as a problem but I think it's less of a problem than IPC in this crucial area. Cheers Martin
Re: Complex text input in Plasma
On Friday, 7 April 2017 23:18:37 PDT，Martin Gräßlin wrote： > Am 2017-04-08 01:04, schrieb Weng Xuetian: > > On Friday, 7 April 2017 06:46:03 PDT，Martin Gräßlin 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. > >> > >> 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. > >> > >> Cheers > >> Martin > > > > I'm sorry to point out this won't really works. The Xwayland client > > will have > > to use XIM anyway. > > Let's please completely ignore the legacy world in the planning for the > future. We setup the perfect world and then look how we can make > Xwayland work. Even ignoring X11 might be an option as Wayland will now > get a massive push thanks to Mir finally being dead. > > > From security point of view, I'm ok if the daemon doesn't directly > > connect to > > application. But I don't want kwin to run the daemon within kwin's > > process. It > > would impose too much complication and I will not be comfortable about > > that. > > I don't mind the IM daemon being part of KWin. > > > People will need to load certain concrete input method as a plugin, I > > don't > > think kwin itself want to include yet another plugin complex system to > > be > > running inside kwin. > > I don't mind that either. > > > Just think it something similar, will kwin merge plasma? I don't think > > you > > really want to that. > > Well we merged: > * kglobalaccel > * screenlocker > * keyboard kded > * virtual keyboard > * multi screen functionality > * Everything that X-Server does > * ... > > No I wouldn't mind merging plasma if it would make sense and improve the > overall experience. That's what I care for: offering the best possible > and secure experience. If that requires merging yet another daemon I > don't mind. There are no sacred cows to me. We are changing the complete > architecture of the display management, so I don't have a problem with > rethinking everything. > > > So the best solution IMHO, is to let kwin to expose certain feature > > that will > > only be allowed to be accessed the im daemon that kwin starts, which > > means > > user any not arbitrary launch a daemon and do whatever they want. And > > that IS > > what current wayland's im protocol is doing. > > > > Also, talking about the layout, I don't think you really want to write > > the > > layout control code. I have never seen a developer who only use > > keyboard > > layout stuff knows what kind of feature that input method could > > achieve. > > Please note that only the Wayland compositor is able to set the keyboard > layout. That is a technical restriction of the Wayland protocol. So yes > KWin must (!) manage the keyboard layout no matter what IM devs think > about it. It just must be in KWin. > > > Compositor should really give this kind of freedom to input method > > daemon. It > > doesn't expose extra security issue if you think about it. kwin would > > just > > works like a router that talks with input method via wayland protocol. > > And > > kwin will not talk with some random input method daemon that it > > unprivileged. > > I don't mind giving IM some freedom, but at the center of the > interaction there is KWin. > > So for me the requirements are: > * no key events are sent via DBus > * applications do not talk to IM daemon > * QT_IM_MODULE must not be used as that breaks virtual keyboard > handling > * No IPC in the key event handling code of KWin > > I don't mind whether the IM daemon is a separate process only KWin > interacts with or a library KWin links. I think a library would be > better as that removes the need for IPC and allows to directly involve > the IM from keyboard handling code. Please compare in that point to > kglobalaccel. > > On X11 kglobalaccel only listens to the key events which would trigger > the shortcut and it's restricted by things like keyboard grab. On > Wayland KWin can send any key event through kglobalaccel as it's linked > directly. This allows us to make
D5343: applet: Reset height of item label
drosca added inline comments. INLINE COMMENTS > anthonyfieroni wrote in ListItemBase.qml:104 > maximumLineCount: 1 should be added or elide will stop to work > http://doc.qt.io/qt-5/qml-qtquick-text.html#elide-prop Eliding still works though. REVISION DETAIL https://phabricator.kde.org/D5343 To: drosca, #plasma Cc: anthonyfieroni, plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
D5343: applet: Reset height of item label
anthonyfieroni added inline comments. INLINE COMMENTS > ListItemBase.qml:104 > Layout.fillWidth: true > +height: undefined > level: 5 maximumLineCount: 1 should be added or elide will stop to work http://doc.qt.io/qt-5/qml-qtquick-text.html#elide-prop REVISION DETAIL https://phabricator.kde.org/D5343 To: drosca, #plasma Cc: anthonyfieroni, plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
D5351: kcm_baloofile: Add option to disable file content indexing
fvogt updated this revision to Diff 13233. fvogt added a comment. Obviously for master only. REPOSITORY R119 Plasma Desktop CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D5351?vs=13232=13233 BRANCH master REVISION DETAIL https://phabricator.kde.org/D5351 AFFECTED FILES CMakeLists.txt kcms/baloo/configwidget.ui kcms/baloo/kcm.cpp kcms/baloo/kcm.h To: fvogt, #plasma Cc: plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
D5351: kcm_baloofile: Add option to disable file content indexing
fvogt created this revision. Restricted Application added a project: Plasma. REVISION SUMMARY Baloo supports "only basic indexing" since version 5.15, which causes it to only store file names into the database: https://community.kde.org/Baloo/Configuration TEST PLAN Ran "balooctl config show contentIndexing" after changing the option. REPOSITORY R119 Plasma Desktop BRANCH Plasma/5.9 REVISION DETAIL https://phabricator.kde.org/D5351 AFFECTED FILES CMakeLists.txt kcms/baloo/configwidget.ui kcms/baloo/kcm.cpp kcms/baloo/kcm.h To: fvogt, #plasma Cc: plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
D5339: Include a bottom toolbar for the application page
jensreuterberg added a comment. I think both are good (but man those colours Aleix :D also the text should be white) The logic behind the alternatives for posterity: 1. Buttons on bottom of Detail view - the install button in the detail view is there for those who will want to read information about the application. The goal being that all applications should have a wealth of meta data (we're not there yet but "one day" etc) and since a user can install from the middle column as well the assumption is that a user in the detail view will be interested in the information within. So the bottom right is in that case (and in the case of left-to-right reading of course) is the naturall place for such a button. 2. Buttons on the top of Detail view - the back button is in this case slightly more natural as it resembles a breadcrumb its a page system and that is where its often expected, that being said the downside is that it camoflages the install button. Since we don't have coloured buttons and can't make the install button pop out that makes it slightly more tricky. 3. Coloured areas instead of buttons - this is the tack-and-paste solution to #2's problem. By making strikingly coloured areas instead of buttons we can essentially put the install button wherever we like since it will scream for attention no matter what. REPOSITORY R134 Discover Software Store REVISION DETAIL https://phabricator.kde.org/D5339 To: apol, leinir, colomar, jensreuterberg Cc: plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
D5222: Make the applet DBus activated
This revision was automatically updated to reflect the committed changes. Closed by commit R115:50157cc0de87: Make the applet DBus activated (authored by drosca). REPOSITORY R115 Plasma Audio Volume Applet CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D5222?vs=12922=13224 REVISION DETAIL https://phabricator.kde.org/D5222 AFFECTED FILES applet/metadata.desktop To: drosca, #plasma, apol Cc: plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
Default touch screen edge gestures
Hi Plasmates, now that we have touch screen edge swipe gesture support both on X11 and Wayland we could define which actions to put on each edge. My suggestion would be to put a sensible action on each of the four actions. Personal proposal: *Left Edge:* Window Switching as the default alt+tab theme is on the left side. Also on Windows 10 this happens on the left edge. *Top Edge:* Present Windows as 4 finger swipe downwards on touchpad triggers present windows. *Bottom Edge:* Desktop Grid as 4 finger swipe upwards on touchpad triggers desktop grid. *Right Edge:* Application launcher What I dislike about the proposal is: Present Windows and Alt+Tab are kind of redundant. Given that a better default edge would be nice for top edge. KRunner would be a nice fit as it's also on top, but it's rather useless on touch. The application launcher is rather disconnected in the default setup if we swipe in from left screen. What I personally would prefer if we could trigger the application dashboard. Of course we still don't have working touch support in the application launchers, so if we go for that we need fixing (same applies for alt+tab btw.). So please comment and propose your own ideas. Cheers Martin
D5346: DigitalClock: Use correct language for month and day names
drosca created this revision. Restricted Application added a project: Plasma. Restricted Application added a subscriber: plasma-devel. REVISION SUMMARY Same as https://phabricator.kde.org/D5345 TEST PLAN I have English ui language + Czech time format. Months and days are now in English and not Czech. REPOSITORY R120 Plasma Workspace BRANCH master REVISION DETAIL https://phabricator.kde.org/D5346 AFFECTED FILES applets/digital-clock/package/contents/ui/CalendarView.qml To: drosca, #plasma, mck182 Cc: plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
D5339: Include a bottom toolbar for the application page
colomar added a comment. Version 2 (top toolbar, no colors) looks the best to me, with the downside that the install button does not stick out. If we go without colors, we'd probably at least need an icon for the install button to not make it totally blend with the rest. REPOSITORY R134 Discover Software Store REVISION DETAIL https://phabricator.kde.org/D5339 To: apol, leinir, jensreuterberg, colomar Cc: plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
D5345: Calendar: Use correct language for month and day names
drosca created this revision. Restricted Application added projects: Plasma, Frameworks. Restricted Application added subscribers: Frameworks, plasma-devel. REVISION SUMMARY Apply fix for bug 353715 also on QML side. TEST PLAN I have English ui language + Czech time format. Months and days are now in English and not Czech. REPOSITORY R242 Plasma Framework (Library) BRANCH master REVISION DETAIL https://phabricator.kde.org/D5345 AFFECTED FILES src/declarativeimports/calendar/qml/DaysCalendar.qml src/declarativeimports/calendar/qml/MonthMenu.qml src/declarativeimports/calendar/qml/MonthView.qml To: drosca, #plasma, mck182 Cc: plasma-devel, #frameworks, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
D5343: applet: Reset height of item label
drosca created this revision. Restricted Application added a project: Plasma. Restricted Application added a subscriber: plasma-devel. REVISION SUMMARY Fixes item label text jumping up and down when resizing applet or the text changes. TEST PLAN Issue fixed BRANCH master REVISION DETAIL https://phabricator.kde.org/D5343 AFFECTED FILES applet/contents/ui/ListItemBase.qml To: drosca, #plasma Cc: plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
D5144: Change the volume icon/mute button into a ToolButton
drosca accepted this revision. drosca added a comment. This revision is now accepted and ready to land. > My theory is that clicking the button will change the ToolButton's svg, which probably causes the naturalHeight to be set, causing the ColumnLayout to recalculate the height of the rows. Whatever is loading wrong at initialization is corrected, causes the reflow, which makes the text shift. No, it's a bug in PlasmaComponents.Label, it sets: height: Math.round(Math.max(paintedHeight, theme.mSize(theme.defaultFont).height*1.6)) If you do `height: paintedHeight` in our code, the issue is fixed. > Should I go ahead and commit this? Yes, thanks. REPOSITORY R115 Plasma Audio Volume Applet REVISION DETAIL https://phabricator.kde.org/D5144 To: Zren, #plasma, subdiff, drosca Cc: mart, subdiff, drosca, plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
Re: Complex text input in Plasma
Am 2017-04-08 01:04, schrieb Weng Xuetian: On Friday, 7 April 2017 06:46:03 PDT，Martin Gräßlin 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. 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. Cheers Martin I'm sorry to point out this won't really works. The Xwayland client will have to use XIM anyway. Let's please completely ignore the legacy world in the planning for the future. We setup the perfect world and then look how we can make Xwayland work. Even ignoring X11 might be an option as Wayland will now get a massive push thanks to Mir finally being dead. From security point of view, I'm ok if the daemon doesn't directly connect to application. But I don't want kwin to run the daemon within kwin's process. It would impose too much complication and I will not be comfortable about that. I don't mind the IM daemon being part of KWin. People will need to load certain concrete input method as a plugin, I don't think kwin itself want to include yet another plugin complex system to be running inside kwin. I don't mind that either. Just think it something similar, will kwin merge plasma? I don't think you really want to that. Well we merged: * kglobalaccel * screenlocker * keyboard kded * virtual keyboard * multi screen functionality * Everything that X-Server does * ... No I wouldn't mind merging plasma if it would make sense and improve the overall experience. That's what I care for: offering the best possible and secure experience. If that requires merging yet another daemon I don't mind. There are no sacred cows to me. We are changing the complete architecture of the display management, so I don't have a problem with rethinking everything. So the best solution IMHO, is to let kwin to expose certain feature that will only be allowed to be accessed the im daemon that kwin starts, which means user any not arbitrary launch a daemon and do whatever they want. And that IS what current wayland's im protocol is doing. Also, talking about the layout, I don't think you really want to write the layout control code. I have never seen a developer who only use keyboard layout stuff knows what kind of feature that input method could achieve. Please note that only the Wayland compositor is able to set the keyboard layout. That is a technical restriction of the Wayland protocol. So yes KWin must (!) manage the keyboard layout no matter what IM devs think about it. It just must be in KWin. Compositor should really give this kind of freedom to input method daemon. It doesn't expose extra security issue if you think about it. kwin would just works like a router that talks with input method via wayland protocol. And kwin will not talk with some random input method daemon that it unprivileged. I don't mind giving IM some freedom, but at the center of the interaction there is KWin. So for me the requirements are: * no key events are sent via DBus * applications do not talk to IM daemon * QT_IM_MODULE must not be used as that breaks virtual keyboard handling * No IPC in the key event handling code of KWin I don't mind whether the IM daemon is a separate process only KWin interacts with or a library KWin links. I think a library would be better as that removes the need for IPC and allows to directly involve the IM from keyboard handling code. Please compare in that point to kglobalaccel. On X11 kglobalaccel only listens to the key events which would trigger the shortcut and it's restricted by things like keyboard grab. On Wayland KWin can send any key event through kglobalaccel as it's linked directly. This allows us to make way better decisions as we have a global view. We can decide whether right now a global shortcut makes sense or not and then not send it in. Please note that I look at this from an absolute engineer perspective. I don't care how it was in the past and only look at how it should be in the future. Especially given that the situation on X11 is bad. I don't want users to have to configure anything. If we add this to KWin
