Re: Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active
On Juli 31, 2015, 10:24 vorm., Oswald Buddenhagen wrote: the description makes a good commit message, so please make sure you use that (apart from adding the BUG lines). Yes, of course. It's not my first commit to kde-workspace and I always handled it like that, i.e. using my description as commit message and adding the BUG lines. (I'm actually using the kdelibs template for my git commits...) ;-) - Wolfgang --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121755/#review83215 --- On Juli 29, 2015, 11:39 vorm., Wolfgang Bauer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121755/ --- (Updated Juli 29, 2015, 11:39 vorm.) Review request for kde-workspace, Thomas Lübking and Oswald Buddenhagen. Bugs: 268988 and 338018 http://bugs.kde.org/show_bug.cgi?id=268988 http://bugs.kde.org/show_bug.cgi?id=338018 Repository: kde-workspace Description --- [Commit d03df616](https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/d03df6169ecb291318e87099a346488c961fe1d6) made input grabbing optional in KDM. But without it, input dialogs do not correctly get focus and keyboard shortcuts don't work. KDM does call activateWindow() on opened dialogs, but this doesn't seem to have the desired effect without a window manager running. And if you hover the mouse over a widget, it visually looks like it has focus, but often it doesn't accept input anyway. This patch sets the input focus via XSetInputFocus() instead, this also has the positive side-effect that a widget retains the focus if you move the mouse away. Diffs - kdm/kfrontend/kfdialog.cpp 3f6fa84 Diff: https://git.reviewboard.kde.org/r/121755/diff/ Testing --- Tried all things mentioned in the bug reports, keyboard input and shortcuts work now in all cases. I also tested with onboard keyboards (xvkbd and kvkbd), both work fine. Before, kvkbd didn't work at all (the text input widget lost focus as soon as you moved the mouse to the OSK) and xvkbd only works if you forced the focus to the text input widget via its Focus button (from which this patch was inspired actually ;-) ). Other openSUSE users have tested this as well, and the patch is even part of openSUSE's official package since January. See also https://bugzilla.opensuse.org/show_bug.cgi?id=772344 Thanks, Wolfgang Bauer
Re: Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active
On Juli 30, 2015, 12:05 nachm., Thomas Lübking wrote: This is Qt4, right? ::activateWindow() should be equivalent to XSetInputFocus(display, winId(), XRevertToParent, X11-time); unless a) _NET_ACTIVE_WINDOW is listed in _NET_SUPPORTED on the root window (supposed to be set and withdrawn by window managers, crash on exit?) AND b) Qt::X11BypassWindowManagerHint is NOT set on the toplevel window OR c) the window is not mapped/waiting for a mapping notification = If the problem occurs, login aside (VT1 or ssh) and export DISPLAY=:0 xprop -root | grep _NET_ACTIVE_WINDOW If that's emtpy, focus setting fails on either qt_widget_private(tlw)-topData()-waitingForMapNotify (qt bug in event handling? missing XSync(dpy, false)? events are being processed after show) or X11-time being superseded by a more recent/future XSetInputFocus call (fixed by passing CurrentTime) If the feature /is/ listed, that's a bug caused by a crashing WM = setting Qt::X11BypassWindowManagerHint will likely be sufficient. Wolfgang Bauer wrote: This is Qt4, right? Yes. = If the problem occurs, login aside (VT1 or ssh) and export DISPLAY=:0 xprop -root | grep _NET_ACTIVE_WINDOW Hm, I don't seem to be able to get the properties of kdm's root window. After opening a new login session: ``` # export DISPLAY=:1 # xprop -root No protocol specified. xprop: unable to open display ':1' ``` On fresh boot: ``` # export DISPLAY=:0 # xprop -root Invalid MIT-MAGIC-COOKIE-1 keyxprop: unable to open display ':0' ``` If I kill kwin in a running KDE4 session, the feature is listed. But that's to be expected I suppose, if I understand you correctly. And focus changes when you move the mouse, which I think is undesirable at the login screen anyway (there are not really multiple windows, just modal dialogs). If the feature /is/ listed, that's a bug caused by a crashing WM = setting Qt::X11BypassWindowManagerHint will likely be sufficient. I will try if that helps. But just to avoid a misunderstanding here: this is about kdm's login greeter. There's no window manager running at all. Thomas Lübking wrote: There's no window manager running at all. Yeah, got that ;-) xprop: unable to open display ':1' Ah, that's likely because the superuser has the X11 authority - try from a su login. And focus changes when you move the mouse That's the default X11 behavior, it will always behave like that (while unmanaged; and iirc it's suppressable by a config key/X switch) There's no window manager running at all. Yeah, got that ;-) I thought so, but I still wanted to mention it because you were talking about a crashing WM... ;-) xprop: unable to open display ':1' Ah, that's likely because the superuser has the X11 authority - try from a su login. Well, that was in fact a su login. But meanwhile I modified kdm to run xprop (at the same place that this patch modifies...). _NET_ACTIVE_WINDOW is *not* set, and _NET_SUPPORTED(ATOM) was not even mentioned in xprop's output. And focus changes when you move the mouse That's the default X11 behavior, it will always behave like that (while unmanaged; and iirc it's suppressable by a config key/X switch) I know, I even mentioned that in the openSUSE bugreport (I have to admit that I used wrong terms though...) So, is this patch ok for you? I think it should be, as Qt itself just calls XSetInputFocus(). The actual bug seems to be in Qt4, but that's unlikely to be fixed any more, isn't? - Wolfgang --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121755/#review83168 --- On Juli 29, 2015, 11:39 vorm., Wolfgang Bauer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121755/ --- (Updated Juli 29, 2015, 11:39 vorm.) Review request for kde-workspace, Thomas Lübking and Oswald Buddenhagen. Bugs: 268988 and 338018 http://bugs.kde.org/show_bug.cgi?id=268988 http://bugs.kde.org/show_bug.cgi?id=338018 Repository: kde-workspace Description --- [Commit d03df616](https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/d03df6169ecb291318e87099a346488c961fe1d6) made input grabbing optional in KDM. But without it, input dialogs do not correctly get focus and keyboard shortcuts don't work. KDM does call activateWindow() on opened dialogs, but this doesn't seem to have the desired effect without a window manager
Re: Replacement for KDateTime
On Tuesday 04 August 2015 17:52:18 Ben Cooksley wrote: I'm assuming QLocale isn't routed through the platform plugin like other parts of Qt do in these cases, so we can't manipulate things there? Right. If a LC_TIME solution isn't possible, we could consider a QSystemLocale configuration that allowed the GUI platform plugin to set some details. Obviously this would not apply to non-GUI apps. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active
On Juli 30, 2015, 10:05 vorm., Thomas Lübking wrote: This is Qt4, right? ::activateWindow() should be equivalent to XSetInputFocus(display, winId(), XRevertToParent, X11-time); unless a) _NET_ACTIVE_WINDOW is listed in _NET_SUPPORTED on the root window (supposed to be set and withdrawn by window managers, crash on exit?) AND b) Qt::X11BypassWindowManagerHint is NOT set on the toplevel window OR c) the window is not mapped/waiting for a mapping notification = If the problem occurs, login aside (VT1 or ssh) and export DISPLAY=:0 xprop -root | grep _NET_ACTIVE_WINDOW If that's emtpy, focus setting fails on either qt_widget_private(tlw)-topData()-waitingForMapNotify (qt bug in event handling? missing XSync(dpy, false)? events are being processed after show) or X11-time being superseded by a more recent/future XSetInputFocus call (fixed by passing CurrentTime) If the feature /is/ listed, that's a bug caused by a crashing WM = setting Qt::X11BypassWindowManagerHint will likely be sufficient. Wolfgang Bauer wrote: This is Qt4, right? Yes. = If the problem occurs, login aside (VT1 or ssh) and export DISPLAY=:0 xprop -root | grep _NET_ACTIVE_WINDOW Hm, I don't seem to be able to get the properties of kdm's root window. After opening a new login session: ``` # export DISPLAY=:1 # xprop -root No protocol specified. xprop: unable to open display ':1' ``` On fresh boot: ``` # export DISPLAY=:0 # xprop -root Invalid MIT-MAGIC-COOKIE-1 keyxprop: unable to open display ':0' ``` If I kill kwin in a running KDE4 session, the feature is listed. But that's to be expected I suppose, if I understand you correctly. And focus changes when you move the mouse, which I think is undesirable at the login screen anyway (there are not really multiple windows, just modal dialogs). If the feature /is/ listed, that's a bug caused by a crashing WM = setting Qt::X11BypassWindowManagerHint will likely be sufficient. I will try if that helps. But just to avoid a misunderstanding here: this is about kdm's login greeter. There's no window manager running at all. Thomas Lübking wrote: There's no window manager running at all. Yeah, got that ;-) xprop: unable to open display ':1' Ah, that's likely because the superuser has the X11 authority - try from a su login. And focus changes when you move the mouse That's the default X11 behavior, it will always behave like that (while unmanaged; and iirc it's suppressable by a config key/X switch) Wolfgang Bauer wrote: There's no window manager running at all. Yeah, got that ;-) I thought so, but I still wanted to mention it because you were talking about a crashing WM... ;-) xprop: unable to open display ':1' Ah, that's likely because the superuser has the X11 authority - try from a su login. Well, that was in fact a su login. But meanwhile I modified kdm to run xprop (at the same place that this patch modifies...). _NET_ACTIVE_WINDOW is *not* set, and _NET_SUPPORTED(ATOM) was not even mentioned in xprop's output. And focus changes when you move the mouse That's the default X11 behavior, it will always behave like that (while unmanaged; and iirc it's suppressable by a config key/X switch) I know, I even mentioned that in the openSUSE bugreport (I have to admit that I used wrong terms though...) So, is this patch ok for you? I think it should be, as Qt itself just calls XSetInputFocus(). The actual bug seems to be in Qt4, but that's unlikely to be fixed any more, isn't? The patch is certainly correct since it does the right thing, I'm rather worried *why* it's required in the first place, ie. why the Qt code doesn't work as expected here. Either the mapping condition flag is broken or there's trouble with timestamp handling. If you want to do another test on the causes, check whether you patch still works with QX11Info::appTime() instead of CurrentTime (but that's just for understanding, there's no problem with the patch itself, esp. not on local X11 servers) - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121755/#review83168 --- On Juli 29, 2015, 9:39 vorm., Wolfgang Bauer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121755/ --- (Updated Juli 29, 2015, 9:39 vorm.)
Re: Replacement for KDateTime
On 4 August 2015 at 10:45, John Layt jl...@kde.org wrote: Most of this discussion is very very off-topic, it belongs on the Qt development list, can we get back to the main topic of KCalCore and QDateTime? I have limited time to spare and I'd rather use it to solve the immediate problems that we can fix. OK, I stole some time from work to look at KCalCore and uses of dateOnly. There are 16 calls to isDateOnly() or setDateOnly(), 7 of which can be removed with no effect. Of the remaining 9, 6 are used internally in private iCal parsing and while slightly messy can be worked around OK with a flag or enum or struct. The remaining 3 uses are inside the IncidenceBase::setDtStart() and Recurrence::setStartDateTime() public methods, if the passed in datetime is dateOnly() then the allDay() incidence flag gets set. We can either add an extra parm to the methods to take a flag, or just require the calling of setAllDay() in addition. There are about 21 calls to setDtStart() inside KCalCore that would need to be analysed for impact. Given the size of the other changes required around KDateTime (time spec / time zone especially), this part is rather small. The implications are bigger, as you have to think about all the code outside KCalCore that calls setDtStart() and dtStart(), but the change from KDT to QDT will affect them all anyway and we will have masses of testing to do anyway to cover everything. John.
Re: Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active
On Juli 30, 2015, 12:05 nachm., Thomas Lübking wrote: This is Qt4, right? ::activateWindow() should be equivalent to XSetInputFocus(display, winId(), XRevertToParent, X11-time); unless a) _NET_ACTIVE_WINDOW is listed in _NET_SUPPORTED on the root window (supposed to be set and withdrawn by window managers, crash on exit?) AND b) Qt::X11BypassWindowManagerHint is NOT set on the toplevel window OR c) the window is not mapped/waiting for a mapping notification = If the problem occurs, login aside (VT1 or ssh) and export DISPLAY=:0 xprop -root | grep _NET_ACTIVE_WINDOW If that's emtpy, focus setting fails on either qt_widget_private(tlw)-topData()-waitingForMapNotify (qt bug in event handling? missing XSync(dpy, false)? events are being processed after show) or X11-time being superseded by a more recent/future XSetInputFocus call (fixed by passing CurrentTime) If the feature /is/ listed, that's a bug caused by a crashing WM = setting Qt::X11BypassWindowManagerHint will likely be sufficient. Wolfgang Bauer wrote: This is Qt4, right? Yes. = If the problem occurs, login aside (VT1 or ssh) and export DISPLAY=:0 xprop -root | grep _NET_ACTIVE_WINDOW Hm, I don't seem to be able to get the properties of kdm's root window. After opening a new login session: ``` # export DISPLAY=:1 # xprop -root No protocol specified. xprop: unable to open display ':1' ``` On fresh boot: ``` # export DISPLAY=:0 # xprop -root Invalid MIT-MAGIC-COOKIE-1 keyxprop: unable to open display ':0' ``` If I kill kwin in a running KDE4 session, the feature is listed. But that's to be expected I suppose, if I understand you correctly. And focus changes when you move the mouse, which I think is undesirable at the login screen anyway (there are not really multiple windows, just modal dialogs). If the feature /is/ listed, that's a bug caused by a crashing WM = setting Qt::X11BypassWindowManagerHint will likely be sufficient. I will try if that helps. But just to avoid a misunderstanding here: this is about kdm's login greeter. There's no window manager running at all. Thomas Lübking wrote: There's no window manager running at all. Yeah, got that ;-) xprop: unable to open display ':1' Ah, that's likely because the superuser has the X11 authority - try from a su login. And focus changes when you move the mouse That's the default X11 behavior, it will always behave like that (while unmanaged; and iirc it's suppressable by a config key/X switch) Wolfgang Bauer wrote: There's no window manager running at all. Yeah, got that ;-) I thought so, but I still wanted to mention it because you were talking about a crashing WM... ;-) xprop: unable to open display ':1' Ah, that's likely because the superuser has the X11 authority - try from a su login. Well, that was in fact a su login. But meanwhile I modified kdm to run xprop (at the same place that this patch modifies...). _NET_ACTIVE_WINDOW is *not* set, and _NET_SUPPORTED(ATOM) was not even mentioned in xprop's output. And focus changes when you move the mouse That's the default X11 behavior, it will always behave like that (while unmanaged; and iirc it's suppressable by a config key/X switch) I know, I even mentioned that in the openSUSE bugreport (I have to admit that I used wrong terms though...) So, is this patch ok for you? I think it should be, as Qt itself just calls XSetInputFocus(). The actual bug seems to be in Qt4, but that's unlikely to be fixed any more, isn't? Thomas Lübking wrote: The patch is certainly correct since it does the right thing, I'm rather worried *why* it's required in the first place, ie. why the Qt code doesn't work as expected here. Either the mapping condition flag is broken or there's trouble with timestamp handling. If you want to do another test on the causes, check whether you patch still works with QX11Info::appTime() instead of CurrentTime (but that's just for understanding, there's no problem with the patch itself, esp. not on local X11 servers) If you want to do another test on the causes, check whether you patch still works with QX11Info::appTime() instead of CurrentTime Yes, that seems to work. - Wolfgang --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121755/#review83168 --- On Juli 29, 2015, 11:39 vorm., Wolfgang Bauer wrote:
Re: Replacement for KDateTime
On Tuesday 04 August 2015 10:03:20 John Layt wrote: One problem would be to update running processes (QLocale to track the locale file and emit some signal on changes) This is one of the areas Qt doesn't do well, on Windows and Mac soon as the underlying locale is change you get different results from QLocale, leading to inconsistent looking UI and weird bugs. On Linux it doesn't respond to changes at all until the app restarts, a more consistent approach. The best approach would be to have a QEvent that the app can catch and know to refresh everything when it is ready to do so. Again, something on the plan but a longer term issue to solve, as monitoring locale files or envvars or a registry for changes across multiple platforms in Qt would take some work. The problem with that is a thundering herd. All applications suddenly start updating, even if they haven't got anything to show. It's the same problem and requires the same solution as the language itself. There are mechanisms, but they're neither very well-used and they cause thundering herd. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Replacement for KDateTime
On Tuesday 04 August 2015 10:03:20 John Layt wrote: Nor do we want to use the data in the POSIX file as it has too many shortcomings and lacks features and simply uses a different set of format codes to CLDR. That POSIX file can only ever really be used to tell non-Qt POSIX locale using apps what settings to use under Plasma (i.e. Gtk/glibc stuff). If we're going to use a locale file for Qt internally we'd be better looking to load the CLDR json format instead. Indeed, it's an option I had been thinking of to replace Qt's custom locale feature once we stop shipping our internal CLDR data, or to allow embedded platforms to choose what supported locales to ship, but there are issues there and I'm not sure it's something Thiago would buy into. Ugh... If the date/time format in the POSIX locale is different, there are probably other differences too. I withdraw my requirement to make /bin/ls work then. What's your suggestion to make this work for a KDE environment and applications, John? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Replacement for KDateTime
On Montag, 3. August 2015 23:17:04 CEST, John Layt wrote: Not nonsense, exactly my long-term plan to get Gtk and other apps to use the right Plasma locale settings when running under Plasma. It 'just' requires the kcm to learn how to write and compile a POSIX locale file. That actually doesn't seem to be a really big deal - one would keep a set of adjustments and merge them into a copy of the base-de-toujours from /usr/share/i18n/locales/ Compilation could (should?!) then be done by localedef and I figured (and tested ;-) the relevant env vars to operate on local definitions are I18NPATH and LOCPATH. One problem would be to update running processes (QLocale to track the locale file and emit some signal on changes) One problem is Qt completely ignores the contents of that file, and indeed I'm not sure it would even manage to extract the correct locale name even so you'd end up with some default. Humm? QLocale::name() should please return KDE in this case (where we may be a little smarter and name it en_KDE or de_KDE etc.) Where would that fail? Cheers, Thomas
Re: Replacement for KDateTime
On 4 August 2015 at 03:03, Thiago Macieira thi...@kde.org wrote: On Monday 03 August 2015 21:57:36 John Layt wrote: The problem actually is that Plasma is not considered a system platform by QLocale, it doesn't go looking for what Plasma wants, it just uses the underlying GNU/Linux system settings. Convince Qt to hard-code in a lookup of some Plasma config file with user overrides to be applied whenever Qt apps run under Plasma and then you can get what you need. I had plans somewhere for how that would work, and how we could also make Gtk apps use our settings too by manipulating the LC_* settings. That's not going to happen. The only solution I'm going to accept is one that also applies to /bin/ls. So far, the idea of setting LC_TIME to a file containing the rules is the only solution I've seen to accomplish that. Reading the contents of a POSIX format file and then converting the POSIX format to CLDR format seems broken to me given the difference in features supported and the different format codes that do not exactly map one-to-one. Reading a CLDR json file seems less work with a more reliable result and long-term may be a way to offer the custom locale feature or minimised embedded platform support without our shipping all the data internally. The fundamental mis-match between POSIX and CLDR/ICU is at the heart of many locale issues on Linux. The failure to keep POSIX up to date with new features while still keeping it at the core of much of the underlying Linux infrastructure is frustrating. In an ideal world CLDR would become the sole source of data files and things like glibc would at least switch to using the shared data resources or better yet a single specialised localization library (preferably someone would pay for it not to be ICU!). Anyway, that's all a pipe-dream, it's defeated greater minds than mine, we just have to accept that some scenarios will always be broken and try to make the rest look as good as possible. Most of this discussion is very very off-topic, it belongs on the Qt development list, can we get back to the main topic of KCalCore and QDateTime? I have limited time to spare and I'd rather use it to solve the immediate problems that we can fix. John.
Re: Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active
On Juli 30, 2015, 10:05 vorm., Thomas Lübking wrote: This is Qt4, right? ::activateWindow() should be equivalent to XSetInputFocus(display, winId(), XRevertToParent, X11-time); unless a) _NET_ACTIVE_WINDOW is listed in _NET_SUPPORTED on the root window (supposed to be set and withdrawn by window managers, crash on exit?) AND b) Qt::X11BypassWindowManagerHint is NOT set on the toplevel window OR c) the window is not mapped/waiting for a mapping notification = If the problem occurs, login aside (VT1 or ssh) and export DISPLAY=:0 xprop -root | grep _NET_ACTIVE_WINDOW If that's emtpy, focus setting fails on either qt_widget_private(tlw)-topData()-waitingForMapNotify (qt bug in event handling? missing XSync(dpy, false)? events are being processed after show) or X11-time being superseded by a more recent/future XSetInputFocus call (fixed by passing CurrentTime) If the feature /is/ listed, that's a bug caused by a crashing WM = setting Qt::X11BypassWindowManagerHint will likely be sufficient. Wolfgang Bauer wrote: This is Qt4, right? Yes. = If the problem occurs, login aside (VT1 or ssh) and export DISPLAY=:0 xprop -root | grep _NET_ACTIVE_WINDOW Hm, I don't seem to be able to get the properties of kdm's root window. After opening a new login session: ``` # export DISPLAY=:1 # xprop -root No protocol specified. xprop: unable to open display ':1' ``` On fresh boot: ``` # export DISPLAY=:0 # xprop -root Invalid MIT-MAGIC-COOKIE-1 keyxprop: unable to open display ':0' ``` If I kill kwin in a running KDE4 session, the feature is listed. But that's to be expected I suppose, if I understand you correctly. And focus changes when you move the mouse, which I think is undesirable at the login screen anyway (there are not really multiple windows, just modal dialogs). If the feature /is/ listed, that's a bug caused by a crashing WM = setting Qt::X11BypassWindowManagerHint will likely be sufficient. I will try if that helps. But just to avoid a misunderstanding here: this is about kdm's login greeter. There's no window manager running at all. Thomas Lübking wrote: There's no window manager running at all. Yeah, got that ;-) xprop: unable to open display ':1' Ah, that's likely because the superuser has the X11 authority - try from a su login. And focus changes when you move the mouse That's the default X11 behavior, it will always behave like that (while unmanaged; and iirc it's suppressable by a config key/X switch) Wolfgang Bauer wrote: There's no window manager running at all. Yeah, got that ;-) I thought so, but I still wanted to mention it because you were talking about a crashing WM... ;-) xprop: unable to open display ':1' Ah, that's likely because the superuser has the X11 authority - try from a su login. Well, that was in fact a su login. But meanwhile I modified kdm to run xprop (at the same place that this patch modifies...). _NET_ACTIVE_WINDOW is *not* set, and _NET_SUPPORTED(ATOM) was not even mentioned in xprop's output. And focus changes when you move the mouse That's the default X11 behavior, it will always behave like that (while unmanaged; and iirc it's suppressable by a config key/X switch) I know, I even mentioned that in the openSUSE bugreport (I have to admit that I used wrong terms though...) So, is this patch ok for you? I think it should be, as Qt itself just calls XSetInputFocus(). The actual bug seems to be in Qt4, but that's unlikely to be fixed any more, isn't? Thomas Lübking wrote: The patch is certainly correct since it does the right thing, I'm rather worried *why* it's required in the first place, ie. why the Qt code doesn't work as expected here. Either the mapping condition flag is broken or there's trouble with timestamp handling. If you want to do another test on the causes, check whether you patch still works with QX11Info::appTime() instead of CurrentTime (but that's just for understanding, there's no problem with the patch itself, esp. not on local X11 servers) Wolfgang Bauer wrote: If you want to do another test on the causes, check whether you patch still works with QX11Info::appTime() instead of CurrentTime Yes, that seems to work. Thomas Lübking wrote: Ok, then it seems QWidget believes it's not mapped while it is - or it's only mapped by a sync triggered by XSetInputFocus (what then might become a problem when/if kdm is ported to xcb) Wolfgang Bauer wrote: I think that's becoming theoretical now. Who's going to port
Re: Replacement for KDateTime
On 2 August 2015 at 14:26, John Layt j...@layt.net wrote: On 1 August 2015 at 19:47, Sandro Knauß b...@sandroknauss.de wrote: * indivual timezone support, this is something that we need when parsing ical and have no known timezone information. I havn't looked into it, but I think this can make it eventually into QDateTime. This is the real problem and the biggest stumbling block,and I'm sorry I haven't had the time to come up with a solution as promised. I'll try sort it out in the next week or so. It was something I wanted in QTimeZone but it was far to complex to get in the first version., or indeed maybe ever. I need to see if there's a way we can derive our own support separate to Qt. OK, I had a quick look at this and to do it in Qt and it wasn't actually that hard. You can see the result at: https://codereview.qt-project.org/#/c/122750/ This should support the full set of VTIMEZONE rules, have a look and let me know if not. I'm not sure if it will be ready for 5.6 feature freeze on Friday, or if Thiago will approve of it, but clearly it's not going to be available when KCalCore is released. I'm still thinking about work-arounds, but it's going to be messy internally at the very least, and may not be do-able. John.
Re: Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121755/ --- (Updated Aug. 4, 2015, 5:53 p.m.) Status -- This change has been marked as submitted. Review request for kde-workspace, Thomas Lübking and Oswald Buddenhagen. Changes --- Submitted with commit 46f1055ffdcd2e068296576a7824012f42e9b9a8 by Wolfgang Bauer to branch KDE/4.11. Bugs: 268988 and 338018 http://bugs.kde.org/show_bug.cgi?id=268988 http://bugs.kde.org/show_bug.cgi?id=338018 Repository: kde-workspace Description --- [Commit d03df616](https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/d03df6169ecb291318e87099a346488c961fe1d6) made input grabbing optional in KDM. But without it, input dialogs do not correctly get focus and keyboard shortcuts don't work. KDM does call activateWindow() on opened dialogs, but this doesn't seem to have the desired effect without a window manager running. And if you hover the mouse over a widget, it visually looks like it has focus, but often it doesn't accept input anyway. This patch sets the input focus via XSetInputFocus() instead, this also has the positive side-effect that a widget retains the focus if you move the mouse away. Diffs - kdm/kfrontend/kfdialog.cpp 3f6fa84 Diff: https://git.reviewboard.kde.org/r/121755/diff/ Testing --- Tried all things mentioned in the bug reports, keyboard input and shortcuts work now in all cases. I also tested with onboard keyboards (xvkbd and kvkbd), both work fine. Before, kvkbd didn't work at all (the text input widget lost focus as soon as you moved the mouse to the OSK) and xvkbd only works if you forced the focus to the text input widget via its Focus button (from which this patch was inspired actually ;-) ). Other openSUSE users have tested this as well, and the patch is even part of openSUSE's official package since January. See also https://bugzilla.opensuse.org/show_bug.cgi?id=772344 Thanks, Wolfgang Bauer
Re: Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active
On Juli 30, 2015, 12:05 nachm., Thomas Lübking wrote: This is Qt4, right? ::activateWindow() should be equivalent to XSetInputFocus(display, winId(), XRevertToParent, X11-time); unless a) _NET_ACTIVE_WINDOW is listed in _NET_SUPPORTED on the root window (supposed to be set and withdrawn by window managers, crash on exit?) AND b) Qt::X11BypassWindowManagerHint is NOT set on the toplevel window OR c) the window is not mapped/waiting for a mapping notification = If the problem occurs, login aside (VT1 or ssh) and export DISPLAY=:0 xprop -root | grep _NET_ACTIVE_WINDOW If that's emtpy, focus setting fails on either qt_widget_private(tlw)-topData()-waitingForMapNotify (qt bug in event handling? missing XSync(dpy, false)? events are being processed after show) or X11-time being superseded by a more recent/future XSetInputFocus call (fixed by passing CurrentTime) If the feature /is/ listed, that's a bug caused by a crashing WM = setting Qt::X11BypassWindowManagerHint will likely be sufficient. Wolfgang Bauer wrote: This is Qt4, right? Yes. = If the problem occurs, login aside (VT1 or ssh) and export DISPLAY=:0 xprop -root | grep _NET_ACTIVE_WINDOW Hm, I don't seem to be able to get the properties of kdm's root window. After opening a new login session: ``` # export DISPLAY=:1 # xprop -root No protocol specified. xprop: unable to open display ':1' ``` On fresh boot: ``` # export DISPLAY=:0 # xprop -root Invalid MIT-MAGIC-COOKIE-1 keyxprop: unable to open display ':0' ``` If I kill kwin in a running KDE4 session, the feature is listed. But that's to be expected I suppose, if I understand you correctly. And focus changes when you move the mouse, which I think is undesirable at the login screen anyway (there are not really multiple windows, just modal dialogs). If the feature /is/ listed, that's a bug caused by a crashing WM = setting Qt::X11BypassWindowManagerHint will likely be sufficient. I will try if that helps. But just to avoid a misunderstanding here: this is about kdm's login greeter. There's no window manager running at all. Thomas Lübking wrote: There's no window manager running at all. Yeah, got that ;-) xprop: unable to open display ':1' Ah, that's likely because the superuser has the X11 authority - try from a su login. And focus changes when you move the mouse That's the default X11 behavior, it will always behave like that (while unmanaged; and iirc it's suppressable by a config key/X switch) Wolfgang Bauer wrote: There's no window manager running at all. Yeah, got that ;-) I thought so, but I still wanted to mention it because you were talking about a crashing WM... ;-) xprop: unable to open display ':1' Ah, that's likely because the superuser has the X11 authority - try from a su login. Well, that was in fact a su login. But meanwhile I modified kdm to run xprop (at the same place that this patch modifies...). _NET_ACTIVE_WINDOW is *not* set, and _NET_SUPPORTED(ATOM) was not even mentioned in xprop's output. And focus changes when you move the mouse That's the default X11 behavior, it will always behave like that (while unmanaged; and iirc it's suppressable by a config key/X switch) I know, I even mentioned that in the openSUSE bugreport (I have to admit that I used wrong terms though...) So, is this patch ok for you? I think it should be, as Qt itself just calls XSetInputFocus(). The actual bug seems to be in Qt4, but that's unlikely to be fixed any more, isn't? Thomas Lübking wrote: The patch is certainly correct since it does the right thing, I'm rather worried *why* it's required in the first place, ie. why the Qt code doesn't work as expected here. Either the mapping condition flag is broken or there's trouble with timestamp handling. If you want to do another test on the causes, check whether you patch still works with QX11Info::appTime() instead of CurrentTime (but that's just for understanding, there's no problem with the patch itself, esp. not on local X11 servers) Wolfgang Bauer wrote: If you want to do another test on the causes, check whether you patch still works with QX11Info::appTime() instead of CurrentTime Yes, that seems to work. Thomas Lübking wrote: Ok, then it seems QWidget believes it's not mapped while it is - or it's only mapped by a sync triggered by XSetInputFocus (what then might become a problem when/if kdm is ported to xcb) Wolfgang Bauer wrote: I think that's becoming theoretical now. Who's going to port
