D7766: make krunner accessible
davidedmundson added inline comments.
INLINE COMMENTS
> ResultDelegate.qml:50
> +Accessible.name: displayLabel.text
> +Accessible.description: i18n("%1, in category %2",
> subtextLabel.text.length > 0 ? subtextLabel.text : " ", ListView.section)
> property bool __pressed: false
This ends up in a different .pot file to the translation domain of krunner
which is using this lib, I think you need to i18nd
REPOSITORY
R112 Milou
REVISION DETAIL
https://phabricator.kde.org/D7766
To: mart, #plasma, davidedmundson, broulik
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg,
abetts, sebas, apol, mart
D7766: make krunner accessible
mart updated this revision to Diff 19429. mart added a comment. - Accessible.ListItem as role REPOSITORY R112 Milou CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D7766?vs=19426&id=19429 BRANCH accessiblekrunner REVISION DETAIL https://phabricator.kde.org/D7766 AFFECTED FILES lib/qml/ResultDelegate.qml lib/qml/ResultsView.qml To: mart, #plasma, davidedmundson, broulik Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D7765: make krunner accessible
mart updated this revision to Diff 19427. mart added a comment. - remove dead code REPOSITORY R120 Plasma Workspace CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D7765?vs=19424&id=19427 BRANCH accessiblekrunner REVISION DETAIL https://phabricator.kde.org/D7765 AFFECTED FILES krunner/view.cpp lookandfeel/contents/runcommand/RunCommand.qml To: mart, #plasma, davidedmundson, broulik Cc: gladhorn, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D7766: make krunner accessible
mart updated this revision to Diff 19426. mart added a comment. - better syntax on i18n REPOSITORY R112 Milou CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D7766?vs=19402&id=19426 BRANCH accessiblekrunner REVISION DETAIL https://phabricator.kde.org/D7766 AFFECTED FILES lib/qml/ResultDelegate.qml lib/qml/ResultsView.qml To: mart, #plasma, davidedmundson, broulik Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D7765: make krunner accessible
gladhorn added a comment.
Lovely! Just a bit of nit-picking.
INLINE COMMENTS
> view.cpp:65
>
> +//used only by on screen readers
> +setTitle(i18n("KRunner"));
I'd remove the "on" :)
> RunCommand.qml:120
> }
> -Keys.forwardTo: [listView, results]
> +//Keys.forwardTo: [listView, results]
> }
Left over comment?
REPOSITORY
R120 Plasma Workspace
REVISION DETAIL
https://phabricator.kde.org/D7765
To: mart, #plasma, davidedmundson, broulik
Cc: gladhorn, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed,
jensreuterberg, abetts, sebas, apol, mart
D7766: make krunner accessible
mart added inline comments. INLINE COMMENTS > broulik wrote in ResultsView.qml:140 > Can we perhaps bind the "isCurrentItem" to activeFocus instead of doing this > in addition to incrementing/decrementing the index? what i'm trying to do here is to focus the next item when cycling items with tabs arrives to the last item, so yeah, it's a bit hacky but works REPOSITORY R112 Milou REVISION DETAIL https://phabricator.kde.org/D7766 To: mart, #plasma, davidedmundson, broulik Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D7766: make krunner accessible
mart added inline comments. INLINE COMMENTS > broulik wrote in ResultDelegate.qml:50 > So we end up with " , in category foo" if subtextLabel is empty? pretty much, i can make 2 different strings at all, the oddity if if it's a null string, i18n thinks it's a single patameter and complains about wrong parameters number > broulik wrote in ResultsView.qml:140 > Can we perhaps bind the "isCurrentItem" to activeFocus instead of doing this > in addition to incrementing/decrementing the index? will give a try REPOSITORY R112 Milou REVISION DETAIL https://phabricator.kde.org/D7766 To: mart, #plasma, davidedmundson, broulik Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D7765: make krunner accessible
mart updated this revision to Diff 19424. mart added a comment. - run current result on enter REPOSITORY R120 Plasma Workspace CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D7765?vs=19403&id=19424 BRANCH accessiblekrunner REVISION DETAIL https://phabricator.kde.org/D7765 AFFECTED FILES krunner/view.cpp lookandfeel/contents/runcommand/RunCommand.qml To: mart, #plasma, davidedmundson, broulik Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
Re: kwin_wayland and setWindowIcon()
>From a KDE side we can't use that as we don't have it. There is no icon name part of the specification in either of the shell protocols. The only relevant event is AppId. Qt could base the appId off the window icon but it wouldn't make any sense; (code for this and it's fallbacks if the .desktopfile are not set are in qwaylandwindow.cpp:163->183) I very very much doubt the sent data would be any different in weston. You can run WAYLAND_DEBUG=1 qtcreator and grep for the icon name if you like. If you see no output it means you're running in xwayland, which would also be a reason it works. The only other thing that might be different is their appId -> desktop file -> icon resolution; You can show find out what Qt sends for QtCreator using that debug line, and then see there's a reason we don't find the relevant .desktop file.
kwin_wayland and setWindowIcon()
Hi, kwin_wayland currently sets the application icon only if it can retrieve the .desktop filename of the application. Is there a reason why it doesn't use the icon passed to setWindowIcon() as fallback? This seems to work with weston, so I guess it should be possible with kwin as well? I'm asking this because we can't fix all third-party applications. Even when we can, sometimes it's just hard to figure out the name of the .desktop file. For example, see https://codereview.qt-project.org/#/c/205003/1//ALL Cheers, Elvis
D7774: [solid/fstab] Add support for x-gvfs style options in fstab
bruns added a dependency: D7773: [solid/fstab] Swap vendor and product properties, allow i18n of description. REPOSITORY R245 Solid REVISION DETAIL https://phabricator.kde.org/D7774 To: bruns, #plasma Cc: plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D7773: [solid/fstab] Swap vendor and product properties, allow i18n of description
bruns added a dependent revision: D7774: [solid/fstab] Add support for x-gvfs style options in fstab. REPOSITORY R245 Solid REVISION DETAIL https://phabricator.kde.org/D7773 To: bruns, #plasma Cc: plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D7774: [solid/fstab] Add support for x-gvfs style options in fstab
bruns created this revision. bruns added projects: Plasma, Frameworks. REVISION SUMMARY This fstab options allows an administrator to specify names and icons intended for the user, shown in a GUI For details, see https://git.gnome.org/browse/gvfs/tree/monitor/udisks2/what-is-shown.txt REPOSITORY R245 Solid BRANCH master REVISION DETAIL https://phabricator.kde.org/D7774 AFFECTED FILES src/solid/devices/backends/fstab/fstabdevice.cpp src/solid/devices/backends/fstab/fstabdevice.h src/solid/devices/backends/fstab/fstabhandling.cpp src/solid/devices/backends/fstab/fstabhandling.h src/solid/devices/backends/fstab/fstabstorageaccess.cpp src/solid/devices/backends/fstab/fstabstorageaccess.h To: bruns, #plasma Cc: plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D7772: [solid/fstab] Swap vendor and product properties, allow i18n of description
bruns removed a dependency: D7773: [solid/fstab] Swap vendor and product properties, allow i18n of description. REPOSITORY R245 Solid REVISION DETAIL https://phabricator.kde.org/D7772 To: bruns, #plasma Cc: plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D7773: [solid/fstab] Swap vendor and product properties, allow i18n of description
bruns removed a dependent revision: D7772: [solid/fstab] Swap vendor and product properties, allow i18n of description. REPOSITORY R245 Solid REVISION DETAIL https://phabricator.kde.org/D7773 To: bruns, #plasma Cc: plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D7773: [solid/fstab] Swap vendor and product properties, allow i18n of description
bruns added a dependent revision: D7772: [solid/fstab] Swap vendor and product properties, allow i18n of description. REPOSITORY R245 Solid REVISION DETAIL https://phabricator.kde.org/D7773 To: bruns, #plasma Cc: plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D7772: [solid/fstab] Swap vendor and product properties, allow i18n of description
bruns added a dependency: D7773: [solid/fstab] Swap vendor and product properties, allow i18n of description. REPOSITORY R245 Solid REVISION DETAIL https://phabricator.kde.org/D7772 To: bruns, #plasma Cc: plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D7773: [solid/fstab] Swap vendor and product properties, allow i18n of description
bruns created this revision. bruns added projects: Plasma, Frameworks. Restricted Application added subscribers: Frameworks, plasma-devel. REVISION SUMMARY The fstab backend exposes server and sharename as product and vendor properties, but had the meaning backwards (the product is subordinate to the vendor, as is the sharename to the server). Also allow translation of the description property. REPOSITORY R245 Solid BRANCH arc1 REVISION DETAIL https://phabricator.kde.org/D7773 AFFECTED FILES src/solid/devices/backends/fstab/fstabdevice.cpp src/solid/devices/backends/fstab/fstabnetworkshare.cpp To: bruns, #plasma Cc: plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D7772: [solid/fstab] Swap vendor and product properties, allow i18n of description
bruns abandoned this revision. REPOSITORY R245 Solid REVISION DETAIL https://phabricator.kde.org/D7772 To: bruns, #plasma Cc: plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D7772: [solid/fstab] Swap vendor and product properties, allow i18n of description
bruns created this revision. bruns added projects: Plasma, Frameworks. Restricted Application added subscribers: Frameworks, plasma-devel. REVISION SUMMARY The fstab backend exposes server and sharename as product and vendor properties, but had the meaning backwards (the product is subordinate to the vendor, as is the sharename to the server). Also allow translation of the description property. [solid/fstab] Add support for x-gvfs style options in fstab This fstab options allows an administrator to specify names and icons intended for the user, shown in a GUI For details, see https://git.gnome.org/browse/gvfs/tree/monitor/udisks2/what-is-shown.txt REPOSITORY R245 Solid BRANCH master REVISION DETAIL https://phabricator.kde.org/D7772 AFFECTED FILES src/solid/devices/backends/fstab/fstabdevice.cpp src/solid/devices/backends/fstab/fstabdevice.h src/solid/devices/backends/fstab/fstabhandling.cpp src/solid/devices/backends/fstab/fstabhandling.h src/solid/devices/backends/fstab/fstabnetworkshare.cpp src/solid/devices/backends/fstab/fstabstorageaccess.cpp src/solid/devices/backends/fstab/fstabstorageaccess.h To: bruns, #plasma Cc: plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D7740: Move SceneOpenGL into a dedicated plugin
graesslin added a comment. In https://phabricator.kde.org/D7740#144854, @bshah wrote: > In https://phabricator.kde.org/D7740#144814, @graesslin wrote: > > > done: https://commits.kde.org/kwin/e0f7f58397a613a34312e93b53ade2c72ebc202b > > > Tested this branch, and seems to build and work completely fine wonderful, thanks a lot! REPOSITORY R108 KWin REVISION DETAIL https://phabricator.kde.org/D7740 To: graesslin, #kwin, #plasma Cc: bshah, plasma-devel, kwin, bwowk, ZrenBot, progwolff, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, mart
Re: [RFC] kscreen and touchscreen rotation
Am 2017-09-11 17:11, schrieb Sebastian Kügler: On Monday, September 11, 2017 4:49:58 PM CEST Martin Flöser wrote: So go for the simple way and change Wayland first. Do you think the architecture / API approach is sound? I think your API idea covers all cases. What might be important is to especially focus on the case of: * internal display with touch screen * attaching external display This is a common use case which currently has it's problems as the touchscreen coordinates are not properly translated. This is something we need to get right no matter whether we want to rotate the screen or not. Given that it would be important to have some meta information about how the touch screen relates to a physical screen, e.g. the layout in the virtual display. So add a pointer back from the touchscreen to the physical screen. For the Wayland case we hopefully don't need any of the API. KWin should do a sane thing without needing KScreen for it. If we have the link between physical screen and touch screen KWin should do the only sane thing when rotating the physical screen. Btw. on Wayland KWin has all relevant information about the devices exposed through DBus and you can use that from KScreen side. If something is not yet exposed, just yell, it's easy to add. org.kde.KWin /org/kde/KWin/InputDevice/eventXX and then check the properties. Most important for you should be: * bool touch * QSize size * QString outputName * bool supportsCalibrationMatrix * bool enabled This is mostly just forwarding of libinput device configuration state. For more information about these: https://wayland.freedesktop.org/libinput/doc/latest/group__config.html#ga09a798f58cc601edd2797780096e9804 The link is directly for set calibration matrix, which would be the way to go for rotating a touch screen. Cheers Martin
D7766: make krunner accessible
broulik added inline comments.
INLINE COMMENTS
> ResultDelegate.qml:50
> +Accessible.name: displayLabel.text
> +Accessible.description: i18n("%1, in category %2",
> subtextLabel.text.length > 0 ? subtextLabel.text : " ", ListView.section)
> property bool __pressed: false
So we end up with " , in category foo" if subtextLabel is empty?
> ResultDelegate.qml:246
> +Accessible.name: modelData.text
> +Accessible.description: ""
> checkable: checked
Not needed?
> ResultDelegate.qml:249
> checked: resultDelegate.activeAction === index
> +focus: resultDelegate.activeAction === index
>
I don't understand this focus stuff at all but if it works..
> ResultsView.qml:140
> +if (currentIndex == 0) {
> +listView.nextItemInFocusChain(false).forceActiveFocus();
> +return;
Can we perhaps bind the "isCurrentItem" to activeFocus instead of doing this in
addition to incrementing/decrementing the index?
REPOSITORY
R112 Milou
REVISION DETAIL
https://phabricator.kde.org/D7766
To: mart, #plasma, davidedmundson, broulik
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg,
abetts, sebas, apol, mart
D7740: Move SceneOpenGL into a dedicated plugin
bshah added a comment. In https://phabricator.kde.org/D7740#144814, @graesslin wrote: > done: https://commits.kde.org/kwin/e0f7f58397a613a34312e93b53ade2c72ebc202b Tested this branch, and seems to build and work completely fine REPOSITORY R108 KWin REVISION DETAIL https://phabricator.kde.org/D7740 To: graesslin, #kwin, #plasma Cc: bshah, plasma-devel, kwin, bwowk, ZrenBot, progwolff, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, mart
D7769: [Task Manager] Use Grid for grouped and single tooltips
subdiff added a dependency: D7768: [Task Manager] On containsMouse change always reset toolTipDelegate data. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D7769 To: subdiff, #plasma Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D7768: [Task Manager] On containsMouse change always reset toolTipDelegate data
subdiff added a dependent revision: D7769: [Task Manager] Use Grid for grouped and single tooltips. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D7768 To: subdiff, #plasma Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D7770: [lookandfeel] Fix GLES incompatibilities in UserDelegate shader code
bruns created this revision. bruns added a project: Plasma. Restricted Application added a subscriber: plasma-devel. REVISION SUMMARY BUG: 382668 The shader compilation currently fails on GLES with errors like: "0:6(2): error: No precision specified in this scope for type `vec4'" GLES requires variable qualifiers like highp/lowp, whereas desktop OpenGL does not. As QGlShaderProgram adds suitable defines on desktop OpenGL for these qualifiers, it is safe to add these to a declarations, see: http://doc.qt.io/qt-5/qglshaderprogram.html#writing-portable-shaders REPOSITORY R120 Plasma Workspace BRANCH master REVISION DETAIL https://phabricator.kde.org/D7770 AFFECTED FILES lookandfeel/contents/components/UserDelegate.qml To: bruns, #plasma Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D7769: [Task Manager] Use Grid for grouped and single tooltips
subdiff created this revision. subdiff added a project: Plasma. Restricted Application added a subscriber: plasma-devel. REVISION SUMMARY This fixes the bug that the first tooltip shown after plasmashell launch is larger than needed. Also simplifies the code. BUG: 384600 REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D7769 AFFECTED FILES applets/taskmanager/package/contents/ui/ToolTipDelegate.qml To: subdiff, #plasma Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D7768: [Task Manager] On containsMouse change always reset toolTipDelegate data
subdiff edited the summary of this revision. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D7768 To: subdiff, #plasma Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D7768: [Task Manager] On containsMouse change always reset toolTipDelegate data
subdiff created this revision. subdiff added a project: Plasma. Restricted Application added a subscriber: plasma-devel. REVISION SUMMARY Manually moving grouped tool tips together with single ones could mess up the mapping of their data. This patch makes sure that the correct information is provided by forcing reset of data on every containsMouse change. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D7768 AFFECTED FILES applets/taskmanager/package/contents/ui/Task.qml To: subdiff, #plasma Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
Re: [RFC] kscreen and touchscreen rotation
On Monday, September 11, 2017 4:49:58 PM CEST Martin Flöser wrote: > So go for the simple way and change Wayland first. Do you think the architecture / API approach is sound? -- sebas http://www.kde.org | http://vizZzion.org
Re: qqc2-desktop-style as framework
On Monday, 11 September 2017 16:18:40 CEST Jonathan Riddell wrote: > I've moved qqc2-desktop-style to frameworks from kde/workspace, please > move the translations to follow No translations to move. Ciao -- Luigi
Re: [RFC] kscreen and touchscreen rotation
Am 2017-09-11 12:56, schrieb David Edmundson: On Mon, Sep 11, 2017 at 11:58 AM, Sebastian Kügler wrote: Hi all, One of the things we talked about during Akademy was better support for convertible hardware. I've played around a bit with my Thinkpad X1 Yoga and screen rotation. I can of course rotate the screen "manually" through XRandR (Wayland is another story on that altogether), but that will screw up the touchscreen. Doing some research, I found out that: - touchscreen and display are completely separate things, the system doesn't know they're sitting on top of each other - They need to be rotated separately - rotation in X goes through XInput2, on Wayland, I don't know on wayland touch is libinput->kwin->app (protocol is wl_touch) But AFAIK actual screen rotation itself needs to be added to kwin wayland, before we can be looking at fixing touch events. It's mutual exclusive. We can make touch rotation work without needing visual rotation and vice versa. Rotating visual should be quite simple in fact. I'm not 100% sure the input needs transforming when rotated. If you look at QtWaylandWindow when the screen rotates, the surface rotates too, so if co-ordinates are surface local we shouldn't be changing it? Yep it needs to be transformed in KWin otherwise things like touch on windeco would not work ;-) Cheers Martin
Re: [RFC] kscreen and touchscreen rotation
Am 2017-09-11 11:58, schrieb Sebastian Kügler: Hi all, One of the things we talked about during Akademy was better support for convertible hardware. I've played around a bit with my Thinkpad X1 Yoga and screen rotation. I can of course rotate the screen "manually" through XRandR (Wayland is another story on that altogether), but that will screw up the touchscreen. Doing some research, I found out that: - touchscreen and display are completely separate things, the system doesn't know they're sitting on top of each other It does know, it's just not properly exposed. Libinput does have the output information, it's just not set through udev in general, so in practice we don't have it. But it's in general a fixable problem which might need some work together with upstream and downstream. We need to figure out whether that is never set or just in all distros except Fedora (which is what I would expect). Anyway for your design planning you should be able to assume that there is a link between output and touchscreen. - They need to be rotated separately - rotation in X goes through XInput2, on Wayland, I don't know KWin through libinput. It's just an idea for now, but I'd like to get some feedback about it at this point. My feedback would be: ignore X11, concentrate on Wayland. Once Wayland works, add it to X or ignore it. Why: 1) Wayland is easier, we control the stack 2) We agreed that anything new should be Wayland first 3) Going X11 first or considering X11 at all might make the work on Wayland more difficult So go for the simple way and change Wayland first. Cheers Martin
D7740: Move SceneOpenGL into a dedicated plugin
graesslin added a comment. In https://phabricator.kde.org/D7740#144574, @bshah wrote: > In https://phabricator.kde.org/D7740#144077, @graesslin wrote: > > > @bshah could you please try this patch on hwcomposer platform? I tried to get all required changes into it, but I currently don't have a compiler to verify. > > > Can you commit them in one branch? makes easier for me to CI build this change, as patch is massive. done: https://commits.kde.org/kwin/e0f7f58397a613a34312e93b53ade2c72ebc202b REPOSITORY R108 KWin REVISION DETAIL https://phabricator.kde.org/D7740 To: graesslin, #kwin, #plasma Cc: bshah, plasma-devel, kwin, bwowk, ZrenBot, progwolff, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, mart
qqc2-desktop-style as framework
I've moved qqc2-desktop-style to frameworks from kde/workspace, please move the translations to follow Jonathan
D7765: make krunner accessible
mart updated this revision to Diff 19403. mart added a comment. - better navigation REPOSITORY R120 Plasma Workspace CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D7765?vs=19398&id=19403 BRANCH accessiblekrunner REVISION DETAIL https://phabricator.kde.org/D7765 AFFECTED FILES krunner/view.cpp lookandfeel/contents/runcommand/RunCommand.qml To: mart, #plasma, davidedmundson, broulik Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D7766: make krunner accessible
mart updated this revision to Diff 19402. mart added a comment. - reset list position on focus loss REPOSITORY R112 Milou CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D7766?vs=19399&id=19402 BRANCH accessiblekrunner REVISION DETAIL https://phabricator.kde.org/D7766 AFFECTED FILES lib/qml/ResultDelegate.qml lib/qml/ResultsView.qml To: mart, #plasma, davidedmundson, broulik Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
Re: [RFC] kscreen and touchscreen rotation
On Monday, September 11, 2017 12:56:09 PM CEST David Edmundson wrote:
> On Mon, Sep 11, 2017 at 11:58 AM, Sebastian Kügler
> wrote:
> > Hi all,
> >
> > One of the things we talked about during Akademy was better support
> > for convertible hardware. I've played around a bit with my Thinkpad
> > X1 Yoga and screen rotation. I can of course rotate the screen
> > "manually" through XRandR (Wayland is another story on that
> > altogether), but that will screw up the touchscreen. Doing some
> > research, I found out that:
> >
> > - touchscreen and display are completely separate things, the system
> >
> > doesn't know they're sitting on top of each other
> >
> > - They need to be rotated separately
> > - rotation in X goes through XInput2, on Wayland, I don't know
>
> on wayland
> touch is libinput->kwin->app (protocol is wl_touch)
>
> But AFAIK actual screen rotation itself needs to be added to kwin
> wayland, before we can be looking at fixing touch events.
>
> I'm not 100% sure the input needs transforming when rotated. If you
> look at QtWaylandWindow when the screen rotates, the surface rotates
> too, so if co-ordinates are surface local we shouldn't be changing it?
> It's quite confusing.
>
> > I'm working on some code that does the rotation from KScreen right
> > now. My idea is to add this to KScreen's API and allow the KScreen
> > user to also rotate the display.
> >
> > On X, this happens async, and this bears the risk that input ends
> > up on different coordinates during switching (display has already
> > rotated, touchscreen still in process, or some race condition like
> > that -- I don't think we can really prevent that), on Wayland, we
> > should be able to prevent that from happening as we hopefully can
> > make input rotation atomic along with the rotation itself, the
> > protocol and API of screen management in Wayland allow that.
> >
> > We probably will need to guess which display has a touchscreen
> > attached, but for some cases, I think we can make some pretty
> > reasonable guesses
> > - one display, one touchscreen seems like a the most common case,
> > and is clear
> > - one touchscreen and multiple displays: touchscreen may be on the
> > internal display
> > The mapping heuristic is kept internally, and we can work on that
> > later, once we got the basics in place.
> >
> > Architecture / API design: My idea right now is to add a new
> > relatively simple type class to the KScreen API, TouchScreen, that
> > can be received from an Output, something like
> >
> > output->setRotation(Output::Left);
> > TouchscreenList *touchscreens = output->touchscreens();
> > for (auto touchscreen : touchscreens) {
> >
> > touchscreens.at(0)->setRotation(Output::Left);
> >
> > }
> > // ... then setting the new config as usual through
> > SetConfigOperation()
>
> I don't undertand what this help with?
Changing both, input and display at the same time. This will then go
through either, xrandr or kwayland backends and use xinput or wl_touch
(as you note) to set the input rotation.
Also, the mapping will be in kscreen then.
> That will store a value, but you haven't said who's going to do
> anything with it, which is the important part.
>
> If we're going to set it to be the same as the screen we may as well
> just have the code that handles input to read the screen rotation.
On X, that's the X server, we're expected to set it through xinput.
On Wayland, that's different, that's why I'm thinking it would have to
be backend-specific, which brings in kscreen which has the backends
already.
--
sebas
http://www.kde.org | http://vizZzion.org
D7766: make krunner accessible
mart created this revision. Restricted Application added a project: Plasma. Restricted Application added a subscriber: plasma-devel. REVISION SUMMARY this is the milou part: refine keyboard navigation and semantically mark the entries with the correct text to be read by orca TEST PLAN tested keyboard navigation and made sure orca reads the correct meaningful text REPOSITORY R112 Milou BRANCH accessiblekrunner REVISION DETAIL https://phabricator.kde.org/D7766 AFFECTED FILES lib/qml/ResultDelegate.qml lib/qml/ResultsView.qml To: mart, #plasma, davidedmundson, broulik Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
Re: [RFC] kscreen and touchscreen rotation
On Mon, Sep 11, 2017 at 11:58 AM, Sebastian Kügler wrote:
> Hi all,
>
> One of the things we talked about during Akademy was better support for
> convertible hardware. I've played around a bit with my Thinkpad X1 Yoga
> and screen rotation. I can of course rotate the screen "manually"
> through XRandR (Wayland is another story on that altogether), but that
> will screw up the touchscreen. Doing some research, I found out that:
>
> - touchscreen and display are completely separate things, the system
> doesn't know they're sitting on top of each other
> - They need to be rotated separately
> - rotation in X goes through XInput2, on Wayland, I don't know
>
on wayland
touch is libinput->kwin->app (protocol is wl_touch)
But AFAIK actual screen rotation itself needs to be added to kwin wayland,
before we can be looking at fixing touch events.
I'm not 100% sure the input needs transforming when rotated. If you look at
QtWaylandWindow when the screen rotates, the surface rotates too, so if
co-ordinates are surface local we shouldn't be changing it?
It's quite confusing.
> I'm working on some code that does the rotation from KScreen right now.
> My idea is to add this to KScreen's API and allow the KScreen user to
> also rotate the display.
>
> On X, this happens async, and this bears the risk that input ends up on
> different coordinates during switching (display has already rotated,
> touchscreen still in process, or some race condition like that -- I
> don't think we can really prevent that), on Wayland, we should be able
> to prevent that from happening as we hopefully can make input rotation
> atomic along with the rotation itself, the protocol and API of screen
> management in Wayland allow that.
>
> We probably will need to guess which display has a touchscreen
> attached, but for some cases, I think we can make some pretty
> reasonable guesses
> - one display, one touchscreen seems like a the most common case, and
> is clear
> - one touchscreen and multiple displays: touchscreen may be on the
> internal display
> The mapping heuristic is kept internally, and we can work on that
> later, once we got the basics in place.
>
> Architecture / API design: My idea right now is to add a new relatively
> simple type class to the KScreen API, TouchScreen, that can be received
> from an Output, something like
>
> output->setRotation(Output::Left);
> TouchscreenList *touchscreens = output->touchscreens();
> for (auto touchscreen : touchscreens) {
> touchscreens.at(0)->setRotation(Output::Left);
> }
> // ... then setting the new config as usual through SetConfigOperation()
>
I don't undertand what this help with?
That will store a value, but you haven't said who's going to do anything
with it, which is the important part.
If we're going to set it to be the same as the screen we may as well just
have the code that handles input to read the screen rotation.
D7765: make krunner accessible
mart created this revision. Restricted Application added a project: Plasma. Restricted Application added a subscriber: plasma-devel. REVISION SUMMARY enable actual keyboard navigation, as the previous completely manual keyboard navigation in krunner completely broke the screen reader support, rendering it inaccessible (while potentially krunner is one of the most useful apps for blind users) TEST PLAN tested to navigate with keyboard (still similar behavior as before) while having orca running, which correctly read the result entries REPOSITORY R120 Plasma Workspace BRANCH accessiblekrunner REVISION DETAIL https://phabricator.kde.org/D7765 AFFECTED FILES lookandfeel/contents/runcommand/RunCommand.qml To: mart, #plasma, davidedmundson, broulik Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
Minutes Monday Plasma Hangout
Most of the team is in Randa probably high (physically, but also on swiss chocolate). Let's forgive them. ;) Cheers! -- sebas http://www.kde.org | http://vizZzion.orgPlasma Meeting 11 Sept 2017 jensreut: Yeah I am doing visuals for PM so that we can actually reproduce our designs in imagery and give Alex L a head start when it comes to design work So nothing much. Fabian is working on the HIG and it would help to have some devs in with him Sho: pretty light notes too, my plasma code throughput is not good this month because of all the talky todos which makes me feel a bid bad/stressed tbh * At least hacking on some TM bugfixes again * KAStats-based favs finally merged after many rounds of testing and talking * Tried to work out on the WE why my Wayland session is so broken, other than bug tickets my Plasma plate is fairly empty so I want to get back to it * QtWS coordination stuff, see update on kde-community * Konvi/Kirigami stuff (Flatpak recipe work, trying out the Kirigami colorscope stuff, text view hacking) currently on bug 384548 KDE bug 384548 in plasmashell (Task Manager) "Unminimizing a shaded window should not unshade this window" [minor,] https://bugs.kde.org/show_bug.cgi?id=384548 sebas: - working on kscreen touchscreen rotation this week, broken laptop allowing (see email to plasma-devel) - had a meeting last week with purism, they're interested to ship Plasma Mobile on their phone: to do a joint campaign (in progress) - have been working on a Plasma Mobile roadmap after last week's meeting: https://community.kde.org/Plasma/Mobile/Roadmap - installed Plasma on the pinebook, playing around with it: aside from a cursor rendering (known) bug, it's really good, albeit a bit slow
[RFC] kscreen and touchscreen rotation
Hi all,
One of the things we talked about during Akademy was better support for
convertible hardware. I've played around a bit with my Thinkpad X1 Yoga
and screen rotation. I can of course rotate the screen "manually"
through XRandR (Wayland is another story on that altogether), but that
will screw up the touchscreen. Doing some research, I found out that:
- touchscreen and display are completely separate things, the system
doesn't know they're sitting on top of each other
- They need to be rotated separately
- rotation in X goes through XInput2, on Wayland, I don't know
I'm working on some code that does the rotation from KScreen right now.
My idea is to add this to KScreen's API and allow the KScreen user to
also rotate the display.
On X, this happens async, and this bears the risk that input ends up on
different coordinates during switching (display has already rotated,
touchscreen still in process, or some race condition like that -- I
don't think we can really prevent that), on Wayland, we should be able
to prevent that from happening as we hopefully can make input rotation
atomic along with the rotation itself, the protocol and API of screen
management in Wayland allow that.
We probably will need to guess which display has a touchscreen
attached, but for some cases, I think we can make some pretty
reasonable guesses
- one display, one touchscreen seems like a the most common case, and
is clear
- one touchscreen and multiple displays: touchscreen may be on the
internal display
The mapping heuristic is kept internally, and we can work on that
later, once we got the basics in place.
Architecture / API design: My idea right now is to add a new relatively
simple type class to the KScreen API, TouchScreen, that can be received
from an Output, something like
output->setRotation(Output::Left);
TouchscreenList *touchscreens = output->touchscreens();
for (auto touchscreen : touchscreens) {
touchscreens.at(0)->setRotation(Output::Left);
}
// ... then setting the new config as usual through SetConfigOperation()
This would have to also be implemented in the specific backends in
KScreen.
It's just an idea for now, but I'd like to get some feedback about it
at this point.
--
sebas
http://www.kde.org | http://vizZzion.org
D6591: XdgV6 - Kwin side
mart updated this revision to Diff 19394. mart added a comment. Restricted Application edited projects, added Plasma; removed KWin. - Redo popup grab handling - don't ping a window before killing setActive works also for wl_shell - move Ping Reason in own class REPOSITORY R108 KWin CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D6591?vs=19373&id=19394 BRANCH xdgv6 REVISION DETAIL https://phabricator.kde.org/D6591 AFFECTED FILES shell_client.cpp shell_client.h wayland_server.cpp wayland_server.h To: mart, #plasma, graesslin, davidedmundson Cc: mart, graesslin, kwin, plasma-devel, #kwin, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
