Re: Review Request 118016: Fix wrong constructor resolution
On May 6, 2014, 1:30 p.m., Kevin Ottens wrote:
AFAICT it is BIC but no SIC, no brainer.
Martin Gräßlin wrote:
it's a SIC change as one could have used the variant specifying just
NET::Properties and screen. This would now have to be changed to use
NET::Properties2 before screen argument.
Thomas Lübking wrote:
It's SIC.
NETRootInfo(connection, properties, 1); would now cause an error, but
since it's been buggy anyway (enums are indeed not polymorphic, but for
int,... though gcc could have known better) that should hardly matter.
@Marco
got that with gcc or clang? And which version and what specific call?
The constructor is (theoretically) correctly resolvable and if it's an
ambiguous call, i'd expect a compiler error as well...
Kevin Ottens wrote:
Ah I see. Hm, is it very much used outside of the workspace?
Martin Gräßlin wrote:
is it very much used outside of the workspace?
probably not and ftr the ctors are SIC anyway compared to 4.x as it's now
based on xcb
Kevin Ottens wrote:
I stand by my ship it! then.
Marco Martin wrote:
@Thomas: gcc 4.7.2 on opensuse
the error happens for instance in the virtual desktop KCM
NETRootInfo info(QX11Info::connection(), NET::NumberOfDesktops |
NET::DesktopNames, NET::WM2DesktopLayout);
NET::WM2DesktopLayout gets passed as screen
Thomas Lübking wrote:
Ahh...
You're holding it wrongly™ ;-)
typeof(NET::NumberOfDesktops | NET::DesktopNames) == typeof(int)
NET::Property has no Q_DECLARE_OPERATORS_FOR_FLAGS (at least i don't see
them) and thus | is the integer operator and the result is - integer.
calling
NETRootInfo info(QX11Info::connection(),
static_castNET::Property(NET::NumberOfDesktops | NET::DesktopNames),
NET::WM2DesktopLayout);
should get you the correct result (but scratching the duplicated code is
oc. fine anyway =)
Marco Martin wrote:
yes, it does have Q_DECLARE_OPERATORS_FOR_FLAGS in the end of netwm_def.h
both Properties and Properties2
anyways, the problem is the last parameter, NET::WM2DesktopLayout that
even if not or-ed, it gets casted as int anyways
Thomas Lübking wrote:
It's actually seems a bug in Q_DECLARE_FLAGS / QFlags, for this does
*not* happen w/
---
#include stdio.h
enum Foo { Foo1, Foo2 };
enum Bar { Bar1, Bar2 };
void fooBar(Foo foo, Bar bar, int i = 5)
{
printf(foo bar int\n);
}
void fooBar(Foo foo, int i = 5)
{
printf(foo int\n);
}
int main(int, char **)
{
fooBar(Foo1, Bar1);
fooBar(Foo1, Bar1|Bar2);
}
---
which prints (as can be expected)
foo bar int
foo int
but it *does* happen w/
-
#include stdio.h
#include QFlags
enum Foo { Foo1, Foo2 };
enum Bar { Bar1, Bar2 };
Q_DECLARE_FLAGS(Foos, Foo)
Q_DECLARE_OPERATORS_FOR_FLAGS(Foos)
Q_DECLARE_FLAGS(Bars, Bar)
Q_DECLARE_OPERATORS_FOR_FLAGS(Bars)
void fooBar(Foos foo, Bars bar, int i = 5)
{
printf(foo bar int\n);
}
void fooBar(Foos foo, int i = 5)
{
printf(foo int\n);
}
int main(int, char **)
{
fooBar(Foo1, Bar1);
fooBar(Foo1, Bar1|Bar2);
}
which prints
foo int
foo bar int
IOW, QFlags maintains type safety for operated enums/flags, but *not* for
singleton ones.
Thomas Lübking wrote:
https://bugreports.qt-project.org/browse/QTBUG-38810
Marco Martin wrote:
So it seems is a known problem and there is nothing that can be done.
for now is pushed, if there are problems with it, can be changed/reverted
for an handful of days still
- i'm fine w/ the patch anyway (Qt fix or not, it was broken, so SIC doesn't
matter - plus it removes a bunch of LOC)
- nothing can be done does not exist in my language ;-)
- could frameworks already use c++11 strongly typed enums?
- Thomas
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118016/#review57407
---
On May 6, 2014, 8:08 p.m., Marco Martin wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118016/
---
(Updated May 6, 2014, 8:08 p.m.)
Review request for KDE Frameworks and kwin.
Repository: kwindowsystem
Description
---
when the constructor
NETRootInfo
Re: Launch Bug Report Wizard failing on Apple OS X (was ksycoca4)
On Samstag, 3. Mai 2014 23:38:22 CEST, mk-li...@email.de wrote: On 23 Mar 2014, at 19:18 , Thomas Lübking wrote: Another idea would be that OSX doesn't like the ! prefix (no idea why componentchooser writes it - here. Works fine w/o as well) Hmm, I think that’s indeed the problem! Many thanks for the update - let's see whether Jose can confirm this observation. The only odd thing is that some kio_client apps clutter up the dock, which I’ve also seen for kglobalaccel in konversation [1]. Actually this does match [2] where many [kioclient]defunct processes hang around - do you get them as well? (ps ax should also work under OSX) Cheers, Thomas [1] https://bugs.kde.org/show_bug.cgi?id=334174 [2] https://sourceforge.net/p/be-shell/tickets/21/ Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Review Request 117830: disable extended attributes support on windows
On April 28, 2014, 12:41 p.m., Vishesh Handa wrote: I'm a little surprised that NTFS doesn't support xattr, but sure! NTFS /does/ support xattr (on ntfs-3g), but WinNT does support infinite length xattr via ADS only, so basically xattr invocation would have to be ported for Windows. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117830/#review56737 --- On April 28, 2014, 9:58 a.m., Patrick Spendrin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117830/ --- (Updated April 28, 2014, 9:58 a.m.) Review request for Baloo and kdewin. Repository: baloo Description --- At the moment, there is no support available for extended attributes for Windows/NTFS. So we simply disable it. Diffs - src/file/lib/baloo_xattr_p.h fefc3d9 src/file/lib/xattrdetector.cpp 9bff838 Diff: https://git.reviewboard.kde.org/r/117830/diff/ Testing --- windows msvc 2010 Thanks, Patrick Spendrin Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Review Request 117779: fix crash when textureNode-texture() is null
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117779/#review56577 --- src/declarativeimports/core/windowthumbnail.cpp https://git.reviewboard.kde.org/r/117779/#comment39469 try before this call. - Thomas Lübking On April 25, 2014, 9:41 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117779/ --- (Updated April 25, 2014, 9:41 p.m.) Review request for kde-workspace and Plasma. Repository: plasma-framework Description --- fix crash when textureNode-texture() is null I get this crash very frequently on my system. This is probably only fixing the symptom and not the underlying issue, however at least plasma no longer crashes every few minutes Diffs - src/declarativeimports/core/windowthumbnail.cpp 59255f75994adb96b30fb503c759b2e9110ab708 Diff: https://git.reviewboard.kde.org/r/117779/diff/ Testing --- No longer crashes Thanks, Alexander Richardson
Re: Review Request 117779: fix crash when textureNode-texture() is null
On April 25, 2014, 9:44 p.m., Thomas Lübking wrote: src/declarativeimports/core/windowthumbnail.cpp, line 231 https://git.reviewboard.kde.org/r/117779/diff/1/?file=268344#file268344line231 try before this call. Alexander Richardson wrote: Okay, just thought I'd exit early in that case and not bother with the other stuff. However is this an appropriate fix, or should it be done somewhere else? No idea (don't know the code), but that'd apparently be the crash location while the texture might still be generated above - so it has to work here, not before. It would crash because the texture has never been set and just for the function name i'd assume that to be the bug. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117779/#review56577 --- On April 25, 2014, 9:41 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117779/ --- (Updated April 25, 2014, 9:41 p.m.) Review request for kde-workspace and Plasma. Repository: plasma-framework Description --- fix crash when textureNode-texture() is null I get this crash very frequently on my system. This is probably only fixing the symptom and not the underlying issue, however at least plasma no longer crashes every few minutes Diffs - src/declarativeimports/core/windowthumbnail.cpp 59255f75994adb96b30fb503c759b2e9110ab708 Diff: https://git.reviewboard.kde.org/r/117779/diff/ Testing --- No longer crashes Thanks, Alexander Richardson
Re: Review Request 117731: Improve KStartupInfo::Private::remove_startup_info_internal
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117731/#review56349 --- Ship it! Ship It! - Thomas Lübking On April 24, 2014, 5:46 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117731/ --- (Updated April 24, 2014, 5:46 a.m.) Review request for KDE Frameworks and Thomas Lübking. Repository: kwindowsystem Description --- Improve KStartupInfo::Private::remove_startup_info_internal Uses iterators to check whether startups, silent_startups or unintended_startups contains the id and erases the element. Method is renamed to removeAllStartupInfoInternal to point out the difference to the method which just removes from startups. Diffs - src/kstartupinfo.cpp 6a95ce2d2eb79abbfbd072fa922f458da30d37eb Diff: https://git.reviewboard.kde.org/r/117731/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117644: screenlocker: don't leave behind screensaver processes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117644/#review56416 --- and this as well then. - Thomas Lübking On April 24, 2014, 1:42 p.m., Wolfgang Bauer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117644/ --- (Updated April 24, 2014, 1:42 p.m.) Review request for kde-workspace and Plasma. Bugs: 224200 http://bugs.kde.org/show_bug.cgi?id=224200 Repository: kde-workspace Description --- Currently the screen locker just kills the greeter (kscreenlocker_greet) when the screen is unlocked by the user during the grace time. But apparently this can leave behind running screensaver processes launched by the greeter, see the bug report (which has the highest number of votes of all open bugs AFAICS). This patch changes this to only terminate the greeter, and adds a signal handler to the greeter to exit gracefully in this case. The signal handler exits with return code 1, so that it is not possible to circumvent the password input by just sending a SIGTERM. (the screen locker restarts the greeter in case it doesn't quit with exit code 0) Diffs - ksmserver/screenlocker/greeter/main.cpp d898734 ksmserver/screenlocker/ksldapp.cpp 3dfcc9e Diff: https://git.reviewboard.kde.org/r/117644/diff/ Testing --- Configure a legacy screensaver in Systemsettings-Display and Monitor-Screen Locker, be sure to leave Require Password after disabled. Wait for the screen locker to kick in. Unlock the screen by moving the mouse or pressing a key. Check the process list. Without this patch at least kswarm.kss and kblankscreen.kss reliably kept running after unlocking the screen on my system. With this patch they quit themselves. I'm using this patch for over two weeks now, and I haven't seen any left-over screen saver processes any more (and I even set the timeout to 1 minute). I also tried to terminate kscreenlocker_greet manually by running killall kscreenlocker_greet from a text console in case of a password required, and the locker didn't quit, you still have to enter the password. Thanks, Wolfgang Bauer
Re: Review Request 117091: Force the screen locker's greeter to show the password input field in case of immediateLock
On April 24, 2014, 8:01 p.m., Thomas Lübking wrote: ksmserver/screenlocker/greeter/main.cpp, line 94 https://git.reviewboard.kde.org/r/117091/diff/7/?file=268053#file268053line94 was there a problem with SA_RESTART? --- KDE Workspaces 4.11.9 tagging: Fr 25. Apr 01:59:00 CEST 2014 Would you be ok to give Martin until Fr 25. Apr 00:01:00 CEST 2014 and then push it (on my responsibility)? Wolfgang Bauer wrote: Haven't tried SA_RESTART. I will do so now. It's ok for me to push at Fr 25. Apr 00:01:00 CEST 2014, so I will at least wait until then. Wolfgang Bauer wrote: Changed it to SA_RESTART now, let the system automatically suspend/hibernate a few times, and also started kscreenlocker_greet manually and sent it SIGUSR1 a few times. This worked as expected too, I haven't experienced any problems. So I suppose SA_RESTART is ok as well. SA_RESTART seems the BSD default and used by legacy signal() Thus I was actually rather concerned that w/o SA_RESTART some EINTR could lead into an abort - though even in that case we'd just end up with a restarted greeter. Since you've been running it w/o so far, I'd sugest to push that version and keep testing SA_RESTART afterwards to change the behavior in master and eventual 4.11.10 to use SA_RESTART then. Ie. keep 0 for now as that's the better tested variant. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117091/#review56415 --- On April 24, 2014, 8:52 a.m., Wolfgang Bauer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117091/ --- (Updated April 24, 2014, 8:52 a.m.) Review request for kde-workspace, Plasma and Aaron J. Seigo. Bugs: 327947 and 329076 http://bugs.kde.org/show_bug.cgi?id=327947 http://bugs.kde.org/show_bug.cgi?id=329076 Repository: kde-workspace Description --- If the screen locker is set to not require a password to unlock, it will not show the password input field even when the powermanagement settings suspend the system and are set to require a password after resume (when it was already running at that point). This locks people out of their system. This patch adds a signal handler for SIGUSR1 that switches the running greeter to immediateLock mode. The locker sends that signal to make sure the greeter shows the password input field when necessary. Diffs - ksmserver/screenlocker/greeter/greeterapp.h 8b79188 ksmserver/screenlocker/greeter/greeterapp.cpp c5e2f85 ksmserver/screenlocker/greeter/main.cpp d898734 ksmserver/screenlocker/ksldapp.cpp 3dfcc9e Diff: https://git.reviewboard.kde.org/r/117091/diff/ Testing --- Disable Require password after in the screen locker settings (the default), set it to start after 1 min. (for easier testing). Enable Suspend session after and set it to 2 minutes. (set the action to Suspend, Hibernate, or Lock Screen, doesn't matter) Make sure Lock screen on resume is enabled in the powermanagements Advanced Options (it is by default). After 1 minute the screen locker kicks in, and doesn't require a password. After 2 minutes the session gets suspended, hibernated or locked, and requires a password to resume. Without this patch no password dialog is shown, the user cannot resume the session by entering the password. With this patch this works: there is a password input field, the session is unlocked when the user enters the password. Thanks, Wolfgang Bauer
Re: Review Request 117701: Fix crashers in KStartupInfo on remove while iterating
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117701/#review56269 --- src/kstartupinfo.cpp https://git.reviewboard.kde.org/r/117701/#comment39336 this function is so ugly that i wonder whether removal by value is actually required at all and in case it should try to find the iterator and use that in case of success - instead of the ugly ::operator[] ;-) src/kstartupinfo.cpp https://git.reviewboard.kde.org/r/117701/#comment39334 this is somehow not equivalent to the other variant (ignores silent/uninited) - the iterator should perhaps go with a map pointer/reference to stress this (and as a matching map usage is required anyway) src/kstartupinfo.cpp https://git.reviewboard.kde.org/r/117701/#comment39335 ahhh... this one's the (semi-)obvious crasher =) (I had first only seen the other loops, which looked pretty harmless) Though i had assumed that the non-const iterator would have detached the list anyway. - Thomas Lübking On April 23, 2014, 9:35 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117701/ --- (Updated April 23, 2014, 9:35 a.m.) Review request for KDE Frameworks, Àlex Fiestas and Bhushan Shah. Bugs: 332681 https://bugs.kde.org/show_bug.cgi?id=332681 Repository: kwindowsystem Description --- Fix crashers in KStartupInfo on remove while iterating This is similar to the change ... just for more cases. If the API was used with ::checkStartup it could happen that an item got removed from the startups while iterating the list of startups. Thus the data corrupted resulting in a crash when getting a similar crash. In this case the code now uses erase instead of remove to have a valid iterator. BUG: 332681 Diffs - autotests/kstartupinfo_unittest.cpp 29fa320bc2c82e7e04a7322111bcdba44b7078c6 src/kstartupinfo.cpp 6a95ce2d2eb79abbfbd072fa922f458da30d37eb Diff: https://git.reviewboard.kde.org/r/117701/diff/ Testing --- See new unit tests which crash without the change. For people wanting to run the test: be warned it has the power to crash plasma-shell and kwin. Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117701: Fix crashers in KStartupInfo on remove while iterating
On April 23, 2014, 1:03 p.m., Thomas Lübking wrote:
src/kstartupinfo.cpp, line 413
https://git.reviewboard.kde.org/r/117701/diff/1/?file=267866#file267866line413
this is somehow not equivalent to the other variant (ignores
silent/uninited) - the iterator should perhaps go with a map
pointer/reference to stress this (and as a matching map usage is required
anyway)
Martin Gräßlin wrote:
my understand is that silent/unintended was dead code for these cases as
it only iterated over the startups and that if it's in startups it's not in
silent or unintended. I'll re-check that.
Martin Gräßlin wrote:
yep, unintended and ignored do not matter in that case as it's either in
startups or in silent_startups or in unintended_startups:
if (update_P) { // change: without any new: first
//qDebug() adding uninited;
uninited_startups.insert(id_P, data_P);
} else if (data_P.silent() != Data::Yes || flags
AnnounceSilenceChanges) {
//qDebug() adding;
startups.insert(id_P, data_P);
emit q-gotNewStartup(id_P, data_P);
} else { // new silenced, and silent shouldn't be announced
//qDebug() adding silent;
silent_startups.insert(id_P, data_P);
}
Martin Gräßlin wrote:
But yes, it might be a good idea to either rename the new method or add
the map as a reference. Though I think rename is better.
I actually meant, whether it's in actual use at all (yes, is) or could fully be
replaced by a variant taking an iterator and a map (no, can't) - there's no
ignored in my copy ;-)
I'd then suggest to rename it to removeAllStartupInfoInternal() and fix it (to
operate on iterators) in another patch.
- Thomas
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117701/#review56269
---
On April 23, 2014, 9:35 a.m., Martin Gräßlin wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117701/
---
(Updated April 23, 2014, 9:35 a.m.)
Review request for KDE Frameworks, Àlex Fiestas and Bhushan Shah.
Bugs: 332681
https://bugs.kde.org/show_bug.cgi?id=332681
Repository: kwindowsystem
Description
---
Fix crashers in KStartupInfo on remove while iterating
This is similar to the change ... just for more cases. If the API was
used with ::checkStartup it could happen that an item got removed from
the startups while iterating the list of startups. Thus the data
corrupted resulting in a crash when getting a similar crash.
In this case the code now uses erase instead of remove to have a valid
iterator.
BUG: 332681
Diffs
-
autotests/kstartupinfo_unittest.cpp
29fa320bc2c82e7e04a7322111bcdba44b7078c6
src/kstartupinfo.cpp 6a95ce2d2eb79abbfbd072fa922f458da30d37eb
Diff: https://git.reviewboard.kde.org/r/117701/diff/
Testing
---
See new unit tests which crash without the change. For people wanting to run
the test: be warned it has the power to crash plasma-shell and kwin.
Thanks,
Martin Gräßlin
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117701: Fix crashers in KStartupInfo on remove while iterating
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117701/#review56333 --- Ship it! Ship It! - Thomas Lübking On April 23, 2014, 9:35 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117701/ --- (Updated April 23, 2014, 9:35 a.m.) Review request for KDE Frameworks, Àlex Fiestas and Bhushan Shah. Bugs: 332681 https://bugs.kde.org/show_bug.cgi?id=332681 Repository: kwindowsystem Description --- Fix crashers in KStartupInfo on remove while iterating This is similar to the change ... just for more cases. If the API was used with ::checkStartup it could happen that an item got removed from the startups while iterating the list of startups. Thus the data corrupted resulting in a crash when getting a similar crash. In this case the code now uses erase instead of remove to have a valid iterator. BUG: 332681 Diffs - autotests/kstartupinfo_unittest.cpp 29fa320bc2c82e7e04a7322111bcdba44b7078c6 src/kstartupinfo.cpp 6a95ce2d2eb79abbfbd072fa922f458da30d37eb Diff: https://git.reviewboard.kde.org/r/117701/diff/ Testing --- See new unit tests which crash without the change. For people wanting to run the test: be warned it has the power to crash plasma-shell and kwin. Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kronometer now in KDE Review
On Mittwoch, 23. April 2014 13:17:02 CEST, Elvis Angelaccio wrote: I don't understand. Since there are only numbers I think that your point is already accomplished. Nope. To get monospace glyphs for sure, you must select a monospace font - otherwise you're going by luck. At least on my system ;-) Have you found a particular font that doesn't look this way? Hundreds - it's pretty common and the more exotic the fonts get (script), the more obvious this becomes, but you may try Fontin [1], Bitstream Handel Gothic [2], Adobe Jenson or Linotype Frutiger (latter are commercial fonts, no link - sorry. I can send you screenshots of the fonts though and some resellers will likely provide some as well) for some reasonable choices. In addition, the hinter and font size/weight can have impact. Cheers, Thomas [1] http://www.exljbris.com/fontin.html [2] http://fontpark.net/de/schriftart/handel-gothic-bt/# Please don't ask me whether that's a legal offer.
Re: Review Request 117091: Force the screen locker's greeter to show the password input field in case of immediateLock
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117091/#review56190 --- see minor nitpicks, but in general the patch seems fine and required to me. shipIt! unless veto ;-) ksmserver/screenlocker/greeter/greeterapp.h https://git.reviewboard.kde.org/r/117091/#comment39254 lockImmediatedly()? ksmserver/screenlocker/greeter/main.cpp https://git.reviewboard.kde.org/r/117091/#comment39257 camelCase - signalHandler ksmserver/screenlocker/greeter/main.cpp https://git.reviewboard.kde.org/r/117091/#comment39255 it's nearly academical, but m_instance should be defaulted to NULL and tested here ksmserver/screenlocker/greeter/main.cpp https://git.reviewboard.kde.org/r/117091/#comment39256 ooc.: what's wrong about just: signal(SIGUSR1, signalHandler); ? - Thomas Lübking On April 22, 2014, 4:41 p.m., Wolfgang Bauer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117091/ --- (Updated April 22, 2014, 4:41 p.m.) Review request for kde-workspace, Plasma and Aaron J. Seigo. Bugs: 327947 and 329076 http://bugs.kde.org/show_bug.cgi?id=327947 http://bugs.kde.org/show_bug.cgi?id=329076 Repository: kde-workspace Description --- If the screen locker is set to not require a password to unlock, it will not show the password input field even when the powermanagement settings suspend the system and are set to require a password after resume (when it was already running at that point). This locks people out of their system. This patch adds a signal handler for SIGUSR1 that switches the running greeter to immediateLock mode. The locker sends that signal to make sure the greeter shows the password input field when necessary. Diffs - ksmserver/screenlocker/greeter/greeterapp.h 8b79188 ksmserver/screenlocker/greeter/greeterapp.cpp c5e2f85 ksmserver/screenlocker/greeter/main.cpp d898734 ksmserver/screenlocker/ksldapp.cpp 3dfcc9e Diff: https://git.reviewboard.kde.org/r/117091/diff/ Testing --- Disable Require password after in the screen locker settings (the default), set it to start after 1 min. (for easier testing). Enable Suspend session after and set it to 2 minutes. (set the action to Suspend, Hibernate, or Lock Screen, doesn't matter) Make sure Lock screen on resume is enabled in the powermanagements Advanced Options (it is by default). After 1 minute the screen locker kicks in, and doesn't require a password. After 2 minutes the session gets suspended, hibernated or locked, and requires a password to resume. Without this patch no password dialog is shown, the user cannot resume the session by entering the password. With this patch this works: there is a password input field, the session is unlocked when the user enters the password. Thanks, Wolfgang Bauer
Re: Review Request 117091: Force the screen locker's greeter to show the password input field in case of immediateLock
On April 22, 2014, 5:34 p.m., Thomas Lübking wrote: ksmserver/screenlocker/greeter/main.cpp, line 89 https://git.reviewboard.kde.org/r/117091/diff/2/?file=262501#file262501line89 ooc.: what's wrong about just: signal(SIGUSR1, signalHandler); ? Wolfgang Bauer wrote: signal() is deprecated, according to its manpage. man signal even says: The behavior of signal() varies across UNIX versions, and has also var- ied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. See Portability below. the posix manpage does of course not state that ... luckily it wraps around sigaction on BSD defaults on modern glibc systems - pfeew ;-) sigaction(SIGUSR1, sa, NULL); // for later nullptr i doubt that you'll need another update for that, though. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117091/#review56190 --- On April 22, 2014, 7:28 p.m., Wolfgang Bauer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117091/ --- (Updated April 22, 2014, 7:28 p.m.) Review request for kde-workspace, Plasma and Aaron J. Seigo. Bugs: 327947 and 329076 http://bugs.kde.org/show_bug.cgi?id=327947 http://bugs.kde.org/show_bug.cgi?id=329076 Repository: kde-workspace Description --- If the screen locker is set to not require a password to unlock, it will not show the password input field even when the powermanagement settings suspend the system and are set to require a password after resume (when it was already running at that point). This locks people out of their system. This patch adds a signal handler for SIGUSR1 that switches the running greeter to immediateLock mode. The locker sends that signal to make sure the greeter shows the password input field when necessary. Diffs - ksmserver/screenlocker/greeter/greeterapp.h 8b79188 ksmserver/screenlocker/greeter/greeterapp.cpp c5e2f85 ksmserver/screenlocker/greeter/main.cpp d898734 ksmserver/screenlocker/ksldapp.cpp 3dfcc9e Diff: https://git.reviewboard.kde.org/r/117091/diff/ Testing --- Disable Require password after in the screen locker settings (the default), set it to start after 1 min. (for easier testing). Enable Suspend session after and set it to 2 minutes. (set the action to Suspend, Hibernate, or Lock Screen, doesn't matter) Make sure Lock screen on resume is enabled in the powermanagements Advanced Options (it is by default). After 1 minute the screen locker kicks in, and doesn't require a password. After 2 minutes the session gets suspended, hibernated or locked, and requires a password to resume. Without this patch no password dialog is shown, the user cannot resume the session by entering the password. With this patch this works: there is a password input field, the session is unlocked when the user enters the password. Thanks, Wolfgang Bauer
Re: Review Request 117091: Force the screen locker's greeter to show the password input field in case of immediateLock
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117091/#review56209 --- ksmserver/screenlocker/greeter/main.cpp https://git.reviewboard.kde.org/r/117091/#comment39263 /me would not insist on newline, but there needs to be a blank after the if if (!m_instance) return; - Thomas Lübking On April 22, 2014, 7:28 p.m., Wolfgang Bauer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117091/ --- (Updated April 22, 2014, 7:28 p.m.) Review request for kde-workspace, Plasma and Aaron J. Seigo. Bugs: 327947 and 329076 http://bugs.kde.org/show_bug.cgi?id=327947 http://bugs.kde.org/show_bug.cgi?id=329076 Repository: kde-workspace Description --- If the screen locker is set to not require a password to unlock, it will not show the password input field even when the powermanagement settings suspend the system and are set to require a password after resume (when it was already running at that point). This locks people out of their system. This patch adds a signal handler for SIGUSR1 that switches the running greeter to immediateLock mode. The locker sends that signal to make sure the greeter shows the password input field when necessary. Diffs - ksmserver/screenlocker/greeter/greeterapp.h 8b79188 ksmserver/screenlocker/greeter/greeterapp.cpp c5e2f85 ksmserver/screenlocker/greeter/main.cpp d898734 ksmserver/screenlocker/ksldapp.cpp 3dfcc9e Diff: https://git.reviewboard.kde.org/r/117091/diff/ Testing --- Disable Require password after in the screen locker settings (the default), set it to start after 1 min. (for easier testing). Enable Suspend session after and set it to 2 minutes. (set the action to Suspend, Hibernate, or Lock Screen, doesn't matter) Make sure Lock screen on resume is enabled in the powermanagements Advanced Options (it is by default). After 1 minute the screen locker kicks in, and doesn't require a password. After 2 minutes the session gets suspended, hibernated or locked, and requires a password to resume. Without this patch no password dialog is shown, the user cannot resume the session by entering the password. With this patch this works: there is a password input field, the session is unlocked when the user enters the password. Thanks, Wolfgang Bauer
Re: Review Request 117091: Force the screen locker's greeter to show the password input field in case of immediateLock
On April 22, 2014, 5:34 p.m., Thomas Lübking wrote: ksmserver/screenlocker/greeter/main.cpp, line 89 https://git.reviewboard.kde.org/r/117091/diff/2/?file=262501#file262501line89 ooc.: what's wrong about just: signal(SIGUSR1, signalHandler); ? Wolfgang Bauer wrote: signal() is deprecated, according to its manpage. man signal even says: The behavior of signal() varies across UNIX versions, and has also var- ied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. See Portability below. Thomas Lübking wrote: the posix manpage does of course not state that ... luckily it wraps around sigaction on BSD defaults on modern glibc systems - pfeew ;-) sigaction(SIGUSR1, sa, NULL); // for later nullptr i doubt that you'll need another update for that, though. Wolfgang Bauer wrote: Well, should I change it? In kscreensaver/libkscreensaver/main.cpp they used sigaction() as well. 0 - NULL: yes. sigaction - signal: no. it just doesn't seem too much of a problem that I've constantly been using signal() whenever i needed it ;-) - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117091/#review56190 --- On April 22, 2014, 7:56 p.m., Wolfgang Bauer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117091/ --- (Updated April 22, 2014, 7:56 p.m.) Review request for kde-workspace, Plasma and Aaron J. Seigo. Bugs: 327947 and 329076 http://bugs.kde.org/show_bug.cgi?id=327947 http://bugs.kde.org/show_bug.cgi?id=329076 Repository: kde-workspace Description --- If the screen locker is set to not require a password to unlock, it will not show the password input field even when the powermanagement settings suspend the system and are set to require a password after resume (when it was already running at that point). This locks people out of their system. This patch adds a signal handler for SIGUSR1 that switches the running greeter to immediateLock mode. The locker sends that signal to make sure the greeter shows the password input field when necessary. Diffs - ksmserver/screenlocker/greeter/greeterapp.h 8b79188 ksmserver/screenlocker/greeter/greeterapp.cpp c5e2f85 ksmserver/screenlocker/greeter/main.cpp d898734 ksmserver/screenlocker/ksldapp.cpp 3dfcc9e Diff: https://git.reviewboard.kde.org/r/117091/diff/ Testing --- Disable Require password after in the screen locker settings (the default), set it to start after 1 min. (for easier testing). Enable Suspend session after and set it to 2 minutes. (set the action to Suspend, Hibernate, or Lock Screen, doesn't matter) Make sure Lock screen on resume is enabled in the powermanagements Advanced Options (it is by default). After 1 minute the screen locker kicks in, and doesn't require a password. After 2 minutes the session gets suspended, hibernated or locked, and requires a password to resume. Without this patch no password dialog is shown, the user cannot resume the session by entering the password. With this patch this works: there is a password input field, the session is unlocked when the user enters the password. Thanks, Wolfgang Bauer
Re: Review Request 117644: screenlocker: don't leave behind screensaver processes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117644/#review56219 --- Ship it! from here - see veto condition in the other RR (i do not maintain the screenlocker), but SIGTERM is oc. far better than SIGKILL - Thomas Lübking On April 22, 2014, 8:41 p.m., Wolfgang Bauer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117644/ --- (Updated April 22, 2014, 8:41 p.m.) Review request for kde-workspace and Plasma. Bugs: 224200 http://bugs.kde.org/show_bug.cgi?id=224200 Repository: kde-workspace Description --- Currently the screen locker just kills the greeter (kscreenlocker_greet) when the screen is unlocked by the user during the grace time. But apparently this can leave behind running screensaver processes launched by the greeter, see the bug report (which has the highest number of votes of all open bugs AFAICS). This patch changes this to only terminate the greeter, and adds a signal handler to the greeter to exit gracefully in this case. The signal handler exits with return code 1, so that it is not possible to circumvent the password input by just sending a SIGTERM. (the screen locker restarts the greeter in case it doesn't quit with exit code 0) Diffs - ksmserver/screenlocker/greeter/main.cpp d898734 ksmserver/screenlocker/ksldapp.cpp 3dfcc9e Diff: https://git.reviewboard.kde.org/r/117644/diff/ Testing --- Configure a legacy screensaver in Systemsettings-Display and Monitor-Screen Locker, be sure to leave Require Password after disabled. Wait for the screen locker to kick in. Unlock the screen by moving the mouse or pressing a key. Check the process list. Without this patch at least kswarm.kss and kblankscreen.kss reliably kept running after unlocking the screen on my system. With this patch they quit themselves. I'm using this patch for over two weeks now, and I haven't seen any left-over screen saver processes any more (and I even set the timeout to 1 minute). I also tried to terminate kscreenlocker_greet manually by running killall kscreenlocker_greet from a text console in case of a password required, and the locker didn't quit, you still have to enter the password. Thanks, Wolfgang Bauer
Re: Kronometer now in KDE Review
Am Freitag, 18. April 2014 schrieb Elvis Angelaccio : Final screenshot with all these changes: http://abload.de/img/kronometerdrkjq.png I think by right align, Ingo meant numerical, not pixelwise, ie the display should be 00 00 00 00 even if the left digit would be invisible It's actually that you probably best would fake a monospace font, so that the left digit stays in place while the right one iterates. You'd best drop QLabel and paint the widget yourself, but it's possible. Even using just more labels and custom layout management. Cheers, Thomas
Re: meinproc4 on Mac, KLocale (was Re: What to test for 4.13?)
On Donnerstag, 17. April 2014 20:32:17 CEST, Luigi Toscano wrote:
Ian Wadham ha scritto:
Sorry it has been such a while since you wrote. A lot of water has
flowed under the bridge since then, but this issue is still of the utmost
importance to MacPorts. See:
https://trac.macports.org/wiki/KDEProblems/KDETickets ...
Thanks for looking into it, just to question here:
- did you try to just disable that line? It's certainly less breaking than
try to rewrite a tool where locale support have been rewritten
in KF5.
If removing the KLocale() constructor avoids it, i'm fairly sure it will be the
bogus CFStringGetLength call, so to me it would seem more reasonable to protect
convert_CFString_to_QString
kdelibs/kdecore/kernel/kkernel_mac.cpp
---
QString convert_CFString_to_QString(CFStringRef str) {
+if (str == NULL) {
+return QString();
+}
eventually print a warning (while i've no idea what this condition implies,
like eg. a broken setup. It could be a bug in CFStringRef or CFLocaleGetValue
or either isn't re-entrant or whatever)
And no, forking the application seems the worst option (remeber Ian, you'd have
to maintain that fork ;-)
Cheers,
Thomas
Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Kronometer now in KDE Review
On Tue, Apr 15, 2014 at 10:27 PM, Albert Astals Cid aa...@kde.org wrote: I just don't see the need for the splitters, why would someone want to have them? I see a limited usage (and only) in case they're collapsible (and grow by char width) what would allow to set a target scale (if you measure hours, you likely don't care about seconds et vv.) - but I think that it's mostly just skeumorphism (imitating individually wrapping hardware labels). Scale adjustment could be done better (automatic, resp. radiobutton or slider driven or a semi-automatic hybrid or different font sizes, or ...) on a virtual tool. Cheers, Thomas
Re: Review Request 109892: introduce kconfig as replacement for kreadconfig and kwriteconfig
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/109892/
---
(Updated April 13, 2014, 12:58 p.m.)
Status
--
This change has been discarded.
Review request for KDE Runtime.
Repository: kde-runtime
Description
---
A CLI config tool.
It supports reading and writing of config entries.
Features beyond kread/writeconfig:
--
- regular expression matching
- key/group deletion
- regexp based (mass) replacement
- regexp based entry listing
Usecases:
-
a) kconfupdates:
Whenever you've got legacy settings and you need to update them you end up
either writing a cpp blackbox (to the user) or a complex ('bash' != 'sh' ...)
and slow script for it (latter sometimes not even being possible - original
reason to write this ;-)
b) user assistance:
it is much simpler to ask a user to kreadconfig --file kwinrc --group
Compositing --key MaxFPS than to explain the clickchain through the config GUI.
If you need more than one key, regexp driven maybe grouplisting can be very
convenient.
c) key deletion:
right now the tool of choice for that is called kwrite ...
Syntax:
---
kconfig component[/group[/subgroup[...]]] read|write|delete|list|replace
[key] [value]
Examples: (to get you an idea)
-
Let's say you want to show the configured MaxFPS of the compositor
$ kconfig kwinrc/Compositing read MaxFPS
MaxFPS: 60 (kwinrc/Compositing)
Unset it:
$ kconfig kwinrc/Compositing delete MaxFPS
Removed MaxFPS: 60
Add it:
$ kconfig kwinrc/Compositing write MaxFPS 60
New MaxFPS: 60
You got a 120Hz screen and want the compositor tick more?
$ kconfig kwinrc/Compositing write MaxFPS 120
MaxFPS: 60 - 120
You forgot the actual key?
$ kconfig kwinrc/Compositing list max
MaxFPS: 120
Isn't there too much output for script invocation? (No)
$ MAX_FPS=`kconfig kwinrc/Compositing read MaxFPS`; echo $MAX_FPS
120
You want to alter a present MaxFPS key to MaxFps?
$ kconfig kwinrc/Compositing replace 'MaxFPS=(.*)' 'MaxFps=\1'
MaxFPS: 120 - MaxFps: 120
List all electric borders - w/o knowing in what group they are:
$ kconfig 'kwinrc/.*' list electric
Diffs
-
kreadconfig/CMakeLists.txt c73c9ac
kreadconfig/Messages.sh 55b886c
kreadconfig/kconfig.cpp PRE-CREATION
Diff: https://git.reviewboard.kde.org/r/109892/diff/
Testing
---
Thanks,
Thomas Lübking
Re: Disabling baloo-integration possible?
Am Donnerstag, 10. April 2014 schrieb : So, I wonder what baloo would be doing on OSX to get its hands into the user’s emails… I hope Vishesh can clarify this! Sure one doesn’t want to see any collisions between OSX’ Spotlight indexer on one side and baloo on the other. i assume, ideally the api would just abstract spotlight on osx? would require someone developing an osx backend. cheers, thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Review Request 117157: Unlock session via DBus
On Freitag, 4. April 2014 02:42:32 CEST, Michael Pyne wrote: Of course if an attacker is running code they'd probably just find it easier to open the .kwl directly and read the folder and key names, since apparently those are stored unencrypted, if the API docs are to be believed. Apparently is is changed with KSS and I frankly would have hoped that only hashes are stored for this test? Cheers, Thomas
Re: Review Request 117091: Force the screen locker's greeter to show the password input field in case of immediateLock
On March 26, 2014, 10:07 p.m., Thomas Lübking wrote:
you could sighup or sigusr the greeter process and have it
setImmediateLock(true);
desktopResized();
in return
Wolfgang Bauer wrote:
I agree, this would be a bit nicer...
But I tried it and cannot get it to work.
My signal handler is called, and both setImmediateLock(true) and
desktopResized() are called, (I verified this with debug output statements)
but the password dialog still doesn't show.
Wolfgang Bauer wrote:
Oops, sorry. I just noticed that the signal handler is apparently only
called when I run kscreenlocker_greet manually (and do kill -USR1), but not
when the locker runs it.
Will have to investigate this.
Wolfgang Bauer wrote:
Forget my previous comment.
The signal handler was actually called all the time.
But setImmediateLock(true); followed by desktopResized(); DOES NOT
have any (visual) effect.
I have yet to find out what else to call to make that dialog appear. Any
idea maybe?
Calling exit(1) does work, but that's not much different to killing the
greeter I suppose... ;-)
Ahhh... me was too smart in the multiscreen code ;-)
the for loop in desktopResized() (which is relevant for the m_immediateLock
handling) won't be entered since no screen changed.
Instead you'd run
for (int i = 0; i desktop()-screenCount(); ++i) {
QDeclarativeProperty(m_views.at(i)-rootObject(), locked).write(true);
}
aside fixing the m_immediateLock value.
Sorry for the false information.
- Thomas
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117091/#review54247
---
On March 26, 2014, 4:58 p.m., Wolfgang Bauer wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117091/
---
(Updated March 26, 2014, 4:58 p.m.)
Review request for kde-workspace and Aaron J. Seigo.
Bugs: 327947 and 329076
http://bugs.kde.org/show_bug.cgi?id=327947
http://bugs.kde.org/show_bug.cgi?id=329076
Repository: kde-workspace
Description
---
If the screen locker is set to not require a password to unlock, it will not
show the password input field even when the powermanagement settings suspend
the system and are set to require a password after resume (when it was
already running at that point).
This locks people out of their system.
As there seems to be no way to switch the already running greeter to
immediateLock mode, it is killed in that case by this patch. It gets
restarted immediately with the --immediatelock option in
KSldApp::lockProcessFinished() and shows the password input field then.
Diffs
-
ksmserver/screenlocker/ksldapp.cpp 3dfcc9e
Diff: https://git.reviewboard.kde.org/r/117091/diff/
Testing
---
Disable Require password after in the screen locker settings (the default),
set it to start after 1 min. (for easier testing).
Enable Suspend session after and set it to 2 minutes. (set the action to
Suspend, Hibernate, or Lock Screen, doesn't matter)
Make sure Lock screen on resume is enabled in the powermanagements
Advanced Options (it is by default).
After 1 minute the screen locker kicks in, and doesn't require a password.
After 2 minutes the session gets suspended, hibernated or locked, and
requires a password to resume.
Without this patch no password dialog is shown, the user cannot resume the
session by entering the password.
With this patch this works: there is a password input field, the session is
unlocked when the user enters the password.
Other openSUSE users have tested this as well, see f.e.
https://bugzilla.novell.com/show_bug.cgi?id=864305#c4
Thanks,
Wolfgang Bauer
Re: Review Request 117157: Unlock session via DBus
On Sonntag, 30. März 2014 00:07:15 CEST, Martin Klapetek wrote: However many distros disable gdb attach to running processes by default; you have to either be root or echo 1 somewhere in /proc (for which you also need to be root). /proc/sys/kernel/yama/ptrace_scope On top of this, one could also have ksmserver PTRACE_ATTACH/SEIZE itself (at least on linux that used to be a singleton feature), but root access more or less implies game over in this context (you could simply replace ksmserver or the greeter app with a fixed variant and wait for the next incident) Cheers, Thomas
Re: Review Request 117157: Unlock session via DBus
On March 29, 2014, 12:05 p.m., Martin Gräßlin wrote: I also have problems imagining what a use case for this is and I consider this as a security issue. It basically means that the session can get unlocked without going through authentication. Kirill Elagin wrote: You have to authenticate anyway to access the DBus session bus. Martin Gräßlin wrote: and running applications? It would allow $evilsecretservice to unlock the screen when $agent needs to use the system after remote installing some software. Since Snowden this doesn't sound so far fetched any more (unfortunately). Thomas Lübking wrote: you need access to a random shell of that user (what does not imply you actively logged into it), but can expose another session that pot. allows access to other logins (mail, webservices, even banking) this should (by default) no way be possible. any way to circumvent authentication to this very session should be guarded by a special knowwhatido key or require active authentication (ie. passing the pass hash via dbus - what's insecure enough by itself) Kirill Elagin wrote: If you've installed your evil software you already have a thousand of ways of accessing the system. My point is: if you've got privileges to issue this DBus call, you already have privileges to bypass the lockscreen. This is just a _sane_ way of doing so, because if you're an $evilagent you don't care how many lines of shell code it will take you to bypass the lockscreen, but if you are the user, it starts to matter. Martin Gräßlin wrote: no, the lockscreen is secure. If you are logged in at a tty there is no way to unlock the screen - the only way to bypass the lock is to kill ksmserver which results in the session being killed. Kirill Elagin wrote: It seems to me that it's not secure actually. If you have a look at the bug I mentioned, you'll see a one-liner that unlocks the screen, right? Unfortunately I'm not really familiar with KDE internals, but I don't see any way to avoid this. (I should point out that, still, I don't see this as a security issue; once an $evilagent got your shell, you already lost, because now he can _modify memory_ of any of your processes, including ksmserver.) But if you still don't agree… well, will it be acceptable to have an option in `kscreensaverrc` or `ksmserverrc` that triggers this behaviour? Thomas Lübking wrote: It seems to me that it's not secure actually. As pointed out in the very first comment, i consider this a serious bug and security issue - yes. FTR: There's a difference between the ability to poke memory on the one hand and have a nice GUI access to your money accounts, an open ssl session or root shell of a running system. Accessing random shells/client conections of the current session is the pot. privilegue escalation here, open to an attacker how could eg. not manipulate the software stack. Martin Gräßlin wrote: you'll see a one-liner that unlocks the screen, right? this shouldn't be, and is clearly a bug. Will be the first thing I look into on Monday. will it be acceptable to have an option in `kscreensaverrc` or `ksmserverrc` that triggers this behaviour? That doesn't increase security. If you want such a functionality it must go into logind IMHO. Will be the first thing I look into on Monday. *cough* https://git.reviewboard.kde.org/r/117166/ un/locking depending on HW dongles (bluetooth, USB) is certainly a nice feature, but requires some sort of internal support (where you'd just configure the HW id to trigger this) Unlocking via a dbus command is imo very problematic. If we require a password, the user would be trapped into having it in his shell history or invited to store it (plaintext) on disk. If such tool would be required, it could work by having the user solve a captcha before reading the PW from stdin (to prevent automization) $ kscreenlocker unlock 9*8+3? 75 Password? $ - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/#review54538 --- On March 29, 2014, 11:58 a.m., Kirill Elagin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/ --- (Updated March 29, 2014, 11:58 a.m.) Review request for kde-workspace. Bugs: 314989 http://bugs.kde.org/show_bug.cgi?id=314989 Repository: kde-workspace Description --- Unlock session via DBus Make org.freedesktop.ScreenSaver.SetActive(false) unlock session. Diffs - plasma-workspace
Re: Review Request 117157: Unlock session via DBus
On Sonntag, 30. März 2014 19:14:32 CEST, Thiago Macieira wrote: /proc/sys/kernel/yama/ptrace_scope I'd never heard of Yama. https://www.kernel.org/doc/Documentation/security/Yama.txt Kinda new, but it's a stock kernel feature: http://kernelnewbies.org/Linux_3.4 On top of this, one could also have ksmserver PTRACE_ATTACH/SEIZE itself (at least on linux that used to be a singleton feature), but root access more or less implies game over in this context (you could simply replace ksmserver or the greeter app with a fixed variant and wait for the next incident) Usually, root access and same-user access imply game-over. Which is why I think this feature should be allowed in. There's actually also prctl(PR_SET_DUMPABLE, ...) that can protect against debugging (more reliable than ptracing oneself and available since 2.3.20 ... ie. ever) - protection against same-uid is lately been taken more seriously and the share of gdb users should be rather low. Also Ubuntu apparently recently set ptrace_scope to one by default lately (apparently caused some help requests on ubuntuforums =) I know that Arch has it set since a couple of month. Cheers, Thomas
Re: Review Request 117157: Unlock session via DBus
On Sonntag, 30. März 2014 19:26:21 CEST, Thiago Macieira wrote: Em dom 30 mar 2014, às 10:10:06, Thomas Lübking escreveu: Unlocking via a dbus command is imo very problematic. I disagree. The user already authenticated via their password I should have been more precise in the first sentence: Unlocking via a dbus command [that requires password authentication] is imo very problematic [because that will end up exposing the password on-disk] before they were able to send the D-Bus command in the first place. So why not allow them to unlock? Because we protect the session, not the shell. Occasional access will already be stopped by having to use gdb in the first place and even then it's possible to protect the process from manipulation by the same UID. If we require a password, the user would be trapped into having it in his shell history or invited to store it (plaintext) on disk. If such tool would be required, it could work by having the user solve a captcha before reading the PW from stdin (to prevent automization) $ kscreenlocker unlock ... Please don't invent authentication mechanisms. I didn't even remotely try - this was still about the password enriched dbus unlock (and how to prevent the PW from ending up on the disk) Cheers, Thomas
Re: Review Request 117157: Unlock session via DBus
On Sonntag, 30. März 2014 20:53:01 CEST, Thiago Macieira wrote: Em dom 30 mar 2014, às 19:38:14, Thomas Lübking escreveu: Unlocking via a dbus command [that requires password authentication] is imo very problematic [because that will end up exposing the password on-disk] How does the password end up on disk? One of the use-cases in the linked bug is to invoke this by pam_usb or some bluetooth script. If the dbus call would require a password, the script could end up looking like qdbus org.kde.kscreenlocker unlock 1ns3cur3 In the past, I could kill a process when I had improperly installed KDE and the greeter couldn't authenticate via PAM. Now I have to kill ksmserver or cause the session to exit via D-Bus. Actually the major reason (afaiu) behind moving the lock to ksmserver is to make crashing the locker process worthless. Iirc it happened after AllowClosedownGrabs was (accidentally) unconditionally turned on in Xorg (but that only qualifies as trigger and you'll have to ask Martin on direct motivations ;-) The development situation is special and actually what i had in mind when saying any way to circumvent authentication to this very session should be guarded by a special knowwhatido key [or require active authentication] I do certainly not think that the absolutely only way to open the lock should be the greeter GUI, but i do think that one should authenticate to the locker, what an open shell does not provide. Since you however implied that broken KDE ./. PAM might be a reason for a side entrance, that side entrace key must not rely on PAM. -- We could check the last login time of the user and compare that to either a) start time of the lock b) 3 minutes and accept an explicit dbus quit request if by this it's clear that the user has just authenticated to the system, implicating authentication to the locker. All processes by the same user should be trusted. Ever forgot an open VT1? Cheers, Thomas
Re: Review Request 117157: Unlock session via DBus
On Sonntag, 30. März 2014 23:25:58 CEST, Michael Pyne wrote: I'll note I've actually done this before, during the development process for the new QML-based screenlocker. Me fixed the issue in the greeter code (while doing multiscreen/input handling), installed the greeter and SIGTERM'd the present one =) Neither is fun, of course. With that in mind I'd love to have a more official way to tear down the screenlocker from a separate same-user login. I don't think there's fundamental disagreement on this (esp. not in the developing context) - just on what challenge is required to this side entrance. Eg. i'd personally not object unlocking if there's a login (of yours) which is more recent than the lock and/or recent enough. wait until you figure [...] KWallet That issue is known (to me at least). In a non trustworthy environment i simply close kwallet before leaving the system unwatched because of this. (If I was more paranoid, i'd keep it on a usb key) However, I'm sure you don't want to justify security issues by other security issues :P If they can gain access to a TTY login we are already screwed leaving aside the present issue (/MainApplication quit being exposed to dbus) and given ptrace (gdb solution) is denied: in how far? (beyond killing the session, ie. being a nasty little jerk ;-) Cheers, Thomas
Re: Review Request 117157: Unlock session via DBus
On Montag, 31. März 2014 00:36:29 CEST, Thiago Macieira wrote: They can already access all of the other applications depends on whether they actively suppress such. and the user's files. true. They can attach gdb to any of the user processes. depends on whether they actively suppress such. They can listen to all messages on D-Bus. They can attach to any IPC mechanism the user has access to. True. Question is whether applications expose secrets or access to other shells/services via dbus. Ie. can you highjack an open ssl connection, control banking software etc. They can also launch [...] a keylogger True and if you enter a password into anything that does not grab the keyboard, this is a general issue of X11 (and if you've physical access to the machine, that doesn't matter either, because you can add a cronjob/service to track the device nodes) Leaving access to an open shell is certainly bad enough - beyond question. The question is whether gaining direct access to a running session and random open clients (and leaving the stage untraced) is more valuable and thus worth pretection. And, oh, the attacker can change the user's password! Errhemmm... Without providing the present one? /That/ trick you gotta show me. =) Cheers, Thomas
Re: Systems Settings - Desktop Search
On Sonntag, 30. März 2014 23:21:18 CEST, Albert Astals Cid wrote: El Dissabte, 29 de març de 2014, a les 15:21:26, Thomas Lübking va escriure: On Samstag, 29. März 2014 15:09:10 CEST, Vishesh Handa wrote: I currently have no idea what is being indexed on my pc. I have no way of finding out. If I change my directory structure or add extra media mounts I just have to have faith that baloo does the right thing. It just seems a recipe for user angst and frustration. ... I'm not sure if this is the way you intended it, but to me this translates to - I have no trust in the software you have written and would like to check every thing it is doing, and I expect you to provide user interfaces so that I can monitor it every second To me it translates to the simple fact that I doubt that other people know what i want/need to be indexed and i'd like to know and control what is indexed on MY box, And you can configure what you want indexed in your box, can't you? Maybe read the thread again? What Lindsay wrote, Vishesh read and I then commented? If you want a personal comment: to me the config GUI is not providing positive knowledge (ie. what is ultimately indexed at the moment), no - but that wasn't the topic, i think. Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sonntag, 30. März 2014 23:46:01 CEST, Pablo Sanchez wrote: [ Comments below, in-line ] On 03/30/2014 05:43 PM, Albert Astals Cid wrote: I did that twice today already. I am sorry i failed your reading test. Will refrain for further commenting in this thread. I don't think you should get offended because perhaps there was a translation issue but your comments were a bit `barbed' ... I don't mind being addressed barbed - as long as there's sth. to address. Sum up: Vishesh apparently felt insulted, because he thought Lindsay would have implied that he could not do it right and I pointed out that to me Lindsay clearly meant that he (or anybody) could not know what is right to the user in this regard and it's also about giving the user the idea of control (because, frankly, w/o reading the code you're in nothing like that). She confirmed and stressed that this was not questioning Vishesh's skills, Vishesh accepted - item done. When, in the context of his mass reply, Albert picked a line from my translation and asked me about the presence of a feature on that, i was frankly under the impression that he was merely reacting on keywords and not following the line of a discussion that also finished some hours ago. Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Montag, 31. März 2014 00:20:39 CEST, Pablo Sanchez wrote: I wasn't suggesting you were getting offended ... I was suggesting Albert. Yupp, got that. No, didn't mean to. Yes, was irritated by Alberts (suggestive) question. Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Review Request 117157: Unlock session via DBus
On March 29, 2014, 12:05 p.m., Martin Gräßlin wrote: I also have problems imagining what a use case for this is and I consider this as a security issue. It basically means that the session can get unlocked without going through authentication. Kirill Elagin wrote: You have to authenticate anyway to access the DBus session bus. Martin Gräßlin wrote: and running applications? It would allow $evilsecretservice to unlock the screen when $agent needs to use the system after remote installing some software. Since Snowden this doesn't sound so far fetched any more (unfortunately). Thomas Lübking wrote: you need access to a random shell of that user (what does not imply you actively logged into it), but can expose another session that pot. allows access to other logins (mail, webservices, even banking) this should (by default) no way be possible. any way to circumvent authentication to this very session should be guarded by a special knowwhatido key or require active authentication (ie. passing the pass hash via dbus - what's insecure enough by itself) Kirill Elagin wrote: If you've installed your evil software you already have a thousand of ways of accessing the system. My point is: if you've got privileges to issue this DBus call, you already have privileges to bypass the lockscreen. This is just a _sane_ way of doing so, because if you're an $evilagent you don't care how many lines of shell code it will take you to bypass the lockscreen, but if you are the user, it starts to matter. Martin Gräßlin wrote: no, the lockscreen is secure. If you are logged in at a tty there is no way to unlock the screen - the only way to bypass the lock is to kill ksmserver which results in the session being killed. Kirill Elagin wrote: It seems to me that it's not secure actually. If you have a look at the bug I mentioned, you'll see a one-liner that unlocks the screen, right? Unfortunately I'm not really familiar with KDE internals, but I don't see any way to avoid this. (I should point out that, still, I don't see this as a security issue; once an $evilagent got your shell, you already lost, because now he can _modify memory_ of any of your processes, including ksmserver.) But if you still don't agree… well, will it be acceptable to have an option in `kscreensaverrc` or `ksmserverrc` that triggers this behaviour? It seems to me that it's not secure actually. As pointed out in the very first comment, i consider this a serious bug and security issue - yes. FTR: There's a difference between the ability to poke memory on the one hand and have a nice GUI access to your money accounts, an open ssl session or root shell of a running system. Accessing random shells/client conections of the current session is the pot. privilegue escalation here, open to an attacker how could eg. not manipulate the software stack. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/#review54538 --- On March 29, 2014, 11:58 a.m., Kirill Elagin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/ --- (Updated March 29, 2014, 11:58 a.m.) Review request for kde-workspace. Bugs: 314989 http://bugs.kde.org/show_bug.cgi?id=314989 Repository: kde-workspace Description --- Unlock session via DBus Make org.freedesktop.ScreenSaver.SetActive(false) unlock session. Diffs - plasma-workspace/ksmserver/screenlocker/interface.cpp ecb30a37b1a207cf9dab8c53b1b879108a99a45b plasma-workspace/ksmserver/screenlocker/ksldapp.h b292b62f4df073fff31bcbfd0e39f4c4fe04c92d plasma-workspace/ksmserver/screenlocker/ksldapp.cpp f2e5262524447e8ae1df1fbf6543297c3be3e6b8 Diff: https://git.reviewboard.kde.org/r/117157/diff/ Testing --- I've tested this with KDE 4.11.5 which I'm currently running. Rebasing to master was completely trivial; I've looked through the code and I believe all the assumptions I made are still valid in master. Thanks, Kirill Elagin
Re: Review Request 117166: remove /MainApplication object from screenlocker greeter interface
On March 29, 2014, 8:39 p.m., Kirill Elagin wrote: Why not simply add a parameter to KApplication constructor? Being? I'm not aware of such parameter, kdelibs is semi-frozen and the requirement is also pretty special to add such feature to KApplication, yesno? - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117166/#review54562 --- On March 29, 2014, 8:32 p.m., Thomas Lübking wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117166/ --- (Updated March 29, 2014, 8:32 p.m.) Review request for kde-workspace, Martin Gräßlin and Kirill Elagin. Repository: kde-workspace Description --- Turned out it's possible to kquitapp the greeter w/o having to provide the desktop. whatever is the final resolution to bug #314989 resp. review #117157, ignorantly exposing the /MainApplication object on this process is certainly a bug. (I considered turning it into a QApplication, but that would have turned a HUGE patch and also the KDebug interface might be a benefit) As the issue exists since 4.10, i don't think it's necessary to press this into 4.11.8 (and break the workaround in bug #314989, which then can be reasonably resolved before 4.11.9) Diffs - ksmserver/screenlocker/greeter/greeterapp.cpp c5e2f85 Diff: https://git.reviewboard.kde.org/r/117166/diff/ Testing --- locked screen, checked dbus interface of the greeter - MainApplication is gone. Thanks, Thomas Lübking
Re: Review Request 117166: remove /MainApplication object from screenlocker greeter interface
On March 29, 2014, 8:39 p.m., Kirill Elagin wrote: Why not simply add a parameter to KApplication constructor? Thomas Lübking wrote: Being? I'm not aware of such parameter, kdelibs is semi-frozen and the requirement is also pretty special to add such feature to KApplication, yesno? Kirill Elagin wrote: I've checked KApplication code and it seems that it creates a DBus service unconditionally. Which is pretty weird. Is that true that _every single_ application wants to be exposed via DBus? I guess, no. I wouldn't call this requirement “special” at all. I'm not sure about your freezing rules, but adding a parameter with a compatible default value shouldn't be a big deal, right? Is that true that _every single_ application wants to be exposed via DBus? No idea, but actually cannot think of other cases that don't want to. I do not expect a freeze exception for this at all, if you think it's reasonable you could propose it for KF5. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117166/#review54562 --- On March 29, 2014, 8:32 p.m., Thomas Lübking wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117166/ --- (Updated March 29, 2014, 8:32 p.m.) Review request for kde-workspace, Martin Gräßlin and Kirill Elagin. Repository: kde-workspace Description --- Turned out it's possible to kquitapp the greeter w/o having to provide the desktop. whatever is the final resolution to bug #314989 resp. review #117157, ignorantly exposing the /MainApplication object on this process is certainly a bug. (I considered turning it into a QApplication, but that would have turned a HUGE patch and also the KDebug interface might be a benefit) As the issue exists since 4.10, i don't think it's necessary to press this into 4.11.8 (and break the workaround in bug #314989, which then can be reasonably resolved before 4.11.9) Diffs - ksmserver/screenlocker/greeter/greeterapp.cpp c5e2f85 Diff: https://git.reviewboard.kde.org/r/117166/diff/ Testing --- locked screen, checked dbus interface of the greeter - MainApplication is gone. Thanks, Thomas Lübking
Re: Review Request 117166: remove /MainApplication object from screenlocker greeter interface
On March 29, 2014, 8:39 p.m., Kirill Elagin wrote: Why not simply add a parameter to KApplication constructor? Thomas Lübking wrote: Being? I'm not aware of such parameter, kdelibs is semi-frozen and the requirement is also pretty special to add such feature to KApplication, yesno? Kirill Elagin wrote: I've checked KApplication code and it seems that it creates a DBus service unconditionally. Which is pretty weird. Is that true that _every single_ application wants to be exposed via DBus? I guess, no. I wouldn't call this requirement “special” at all. I'm not sure about your freezing rules, but adding a parameter with a compatible default value shouldn't be a big deal, right? Thomas Lübking wrote: Is that true that _every single_ application wants to be exposed via DBus? No idea, but actually cannot think of other cases that don't want to. I do not expect a freeze exception for this at all, if you think it's reasonable you could propose it for KF5. inb4 you ask: - new feature - api change - uncertain usecase - can easily be gained w/o api change/feature addition (pure convenience) - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117166/#review54562 --- On March 29, 2014, 8:32 p.m., Thomas Lübking wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117166/ --- (Updated March 29, 2014, 8:32 p.m.) Review request for kde-workspace, Martin Gräßlin and Kirill Elagin. Repository: kde-workspace Description --- Turned out it's possible to kquitapp the greeter w/o having to provide the desktop. whatever is the final resolution to bug #314989 resp. review #117157, ignorantly exposing the /MainApplication object on this process is certainly a bug. (I considered turning it into a QApplication, but that would have turned a HUGE patch and also the KDebug interface might be a benefit) As the issue exists since 4.10, i don't think it's necessary to press this into 4.11.8 (and break the workaround in bug #314989, which then can be reasonably resolved before 4.11.9) Diffs - ksmserver/screenlocker/greeter/greeterapp.cpp c5e2f85 Diff: https://git.reviewboard.kde.org/r/117166/diff/ Testing --- locked screen, checked dbus interface of the greeter - MainApplication is gone. Thanks, Thomas Lübking
Re: Systems Settings - Desktop Search
On Samstag, 29. März 2014 15:09:10 CEST, Vishesh Handa wrote: I currently have no idea what is being indexed on my pc. I have no way of finding out. If I change my directory structure or add extra media mounts I just have to have faith that baloo does the right thing. It just seems a recipe for user angst and frustration. I'm not sure if this is the way you intended it, but to me this translates to - I have no trust in the software you have written and would like to check every thing it is doing, and I expect you to provide user interfaces so that I can monitor it every second To me it translates to the simple fact that I doubt that other people know what i want/need to be indexed and i'd like to know and control what is indexed on MY box, so don't try to turn it into a techinal insult, that's ridiculous. You /cannot/ do it right since you /cannot/ know what is right in the first place. That's not a technical issue. Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Review Request 117088: Rename kuiserver to kuiserver5 for co-installability with kdelibs4 kde-runtime
On March 26, 2014, 2:29 p.m., Hrvoje Senjan wrote: (dbus docs say the name of a .service file is arbitrary) it is. however, with this solution, user will never know (i.e. predict) will kuiserver, or kuiserver5 be started - unless you also change the name (not filename) of the service. that will however then need adjusting in 'downstream' consumers of kuiserver Jonathan Riddell wrote: But then it won't be compatible between uses in kdelibs4 land and users in kf5 land. kuiserver would have to be a proxy that detects the current environment and launch the proper variant (like qt-chooser)? - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117088/#review54206 --- On March 26, 2014, 2:03 p.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117088/ --- (Updated March 26, 2014, 2:03 p.m.) Review request for KDE Runtime and Aleix Pol Gonzalez. Repository: kde-runtime Description --- Rename kuiserver to kuiserver5 for co-installability with kdelibs4 kde-runtime (dbus docs say the name of a .service file is arbitrary) Diffs - kuiserver/CMakeLists.txt a724326 kuiserver/kf5_org.kde.kuiserver.service.in PRE-CREATION kuiserver/kuiserver.desktop 2d7a874 kuiserver/org.kde.kuiserver.service.in a900b64 Diff: https://git.reviewboard.kde.org/r/117088/diff/ Testing --- Thanks, Jonathan Riddell
Re: Review Request 117091: Force the screen locker's greeter to show the password input field in case of immediateLock
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117091/#review54247 --- you could sighup or sigusr the greeter process and have it setImmediateLock(true); desktopResized(); in return - Thomas Lübking On March 26, 2014, 4:58 p.m., Wolfgang Bauer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117091/ --- (Updated March 26, 2014, 4:58 p.m.) Review request for kde-workspace and Aaron J. Seigo. Bugs: 327947 and 329076 http://bugs.kde.org/show_bug.cgi?id=327947 http://bugs.kde.org/show_bug.cgi?id=329076 Repository: kde-workspace Description --- If the screen locker is set to not require a password to unlock, it will not show the password input field even when the powermanagement settings suspend the system and are set to require a password after resume (when it was already running at that point). This locks people out of their system. As there seems to be no way to switch the already running greeter to immediateLock mode, it is killed in that case by this patch. It gets restarted immediately with the --immediatelock option in KSldApp::lockProcessFinished() and shows the password input field then. Diffs - ksmserver/screenlocker/ksldapp.cpp 3dfcc9e Diff: https://git.reviewboard.kde.org/r/117091/diff/ Testing --- Disable Require password after in the screen locker settings (the default), set it to start after 1 min. (for easier testing). Enable Suspend session after and set it to 2 minutes. (set the action to Suspend, Hibernate, or Lock Screen, doesn't matter) Make sure Lock screen on resume is enabled in the powermanagements Advanced Options (it is by default). After 1 minute the screen locker kicks in, and doesn't require a password. After 2 minutes the session gets suspended, hibernated or locked, and requires a password to resume. Without this patch no password dialog is shown, the user cannot resume the session by entering the password. With this patch this works: there is a password input field, the session is unlocked when the user enters the password. Other openSUSE users have tested this as well, see f.e. https://bugzilla.novell.com/show_bug.cgi?id=864305#c4 Thanks, Wolfgang Bauer
Re: debuggind keypress event handling in the plasmoid
On Dienstag, 25. März 2014 14:31:05 CEST, Marek Kochanowicz wrote: entry field works but it is not quite functional yet. What bothers me right now, are segfaults triggered with any none alpha numeric key (for instance print-screen but also alt-gr). http://wklej.org/id/1311595 i'm not sure what is wrong here. Should i not pass all keys to the klineedit (mFilterWidget)? Can anybody give me a tip? Debugging is hard :( I'd bet on some recursion for the sendEvent, but w/o seeing the actual code or a backtrace, that's impossible to say. Notice that a popup will grab the keyboard and receive all input events - events sent somewhere will likely show up in the popup as well. Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Missing application icons of many KDE apps on MacPorts/OSX
On Montag, 24. März 2014 00:41:12 CEST, Ian Wadham wrote: I notice there are TWO kde4_add_app_icon() macro refs in that CMakeLists.txt. The other one has no _bin in it … seems odd ... No, kdevelop_bin_SRCS or kdevelop_SRCS or foo_bar_SRCS are just matter of the project name And, Marko, can you point me to something that will crack one of Apple's ICNS files? e.g. Linux (at least) tool: http://sourceforge.net/projects/icns/ Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Launch Bug Report Wizard failing on Apple OS X (was ksycoca4)
On Sonntag, 23. März 2014 11:55:02 CEST, Ian Wadham wrote: In all three cases, an icon appears in the Dock (task bar equivalent) and vanishes too soon to see what it is. Additionally, I am finding messages on the Apple OS X Console log (see attached). Can a KDE guy tell Marko and me what is going wrong here? And perhaps where else to look to narrow down the problem? Any ideas? There's probably no known URI filter or the filter points konqueror or so. kioclient exec 'http://www.kde.org/' Does this open kde.org in any browser? Do you get a dialog for kcmshell4 componentchooser and can you select a webbrowser (safari) there? (I frankly don't know what in an application based on the contents of the URL means) Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Launch Bug Report Wizard failing on Apple OS X (was ksycoca4)
On Sonntag, 23. März 2014 13:08:50 CEST, mk-li...@email.de wrote: Does this open kde.org in any browser? No, it didn’t open a browser. Do you get a dialog for kcmshell4 componentchooser $ kcmshell4 componentchooser -bash: kcmshell4: command not found Well, I seem to have to install some other port to get kcmshell4 into my system... and can you select a webbrowser (safari) there? Need to search now which port contains that kcmshell4. Is there perhaps another way to define the standard web browser at install time in such a way that Safari would be used as the initial default? try: kwriteconfig --group General --key BrowserApplication '!safari' To do that for every user, one could make use of kiosk (basically provide /usr/share/config/kdeglobals with appropriate entry in [General] - whether that works on MacOS, i don't know. Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: ksycoca4
On Samstag, 22. März 2014 18:52:14 CEST, Marko wrote: Hi, I just tried to start KDE's bug reporter from a little tutorial application on MacOSX, but I got this spat out at the console: — $ tutorial2.app/Contents/MacOS/tutorial2 tutorial2(1006)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open ksycoca from /private/var/tmp/kdecache-marko/ksycoca4” — and nothing happened. Define nothing - and what would you have expected? Do you return to the prompt or would you expect a window to show up? A link to the tutorial code would be helpful (to know what it's supposed to do) Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: meinproc4 on Mac, KLocale (was Re: What to test for 4.13?)
On Freitag, 21. März 2014 08:24:06 CEST, Ian Wadham wrote: That call to KGlobal::locale(); seems an odd one, KDE guys. That function is supposed to return a locale (KLocale *), but here it is executed as a procedure, ignoring the return result. I can only conclude that the code is being executed for its side-effects: It will likely be to call protected KLocale::initInstance(), eventually to intantiate it from the main thread for sure. Not sure if it's required at all - look at the date of the commit! commit 693da1d1df4876d7c898f3035beead76288872d5 Author: Stephan Kulow ..@kde.org Date: Fri Jul 6 15:19:46 2001 + update to docbook-xsl 1.40 [] -KGlobal::locale()-setMainCatalogue(kio_help); +KLocale::setMainCatalogue(kio_help); KInstance ins(meinproc); +KGlobal::locale(); [] Cheers, Tomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: meinproc4 on Mac, KLocale (was Re: What to test for 4.13?)
On Mittwoch, 19. März 2014 22:24:13 CEST, mk-li...@email.de wrote: On 19 Mar 2014, at 21:50 , Luigi Toscano luigi.tosc...@tiscali.it wrote: The crash described in that stack trace happens in a part of code which is executed *before* initializing livxml. OK, and what do we learn from that? That the libxml2 bug is not related to the bug #261509 backtrace (doesn't change anything since i anticipated that for social reasons ;-) Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: MacPorts: Running KDE ports on Apple OS X
On Samstag, 15. März 2014 12:07:46 CEST, René JV Bertin wrote: and who knows maybe even support KWin for those of us using X11 apps ... What's your concern here? X11 on OSX should be provided by XQuartz which should provide native OSX titlebars (and integration into the OSX WM) I do not see how it would be ever possible (or reasonable) to have a second WM (let alone compositor) run on OSX (or Windows) - what would you expect it to do? Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: MacPorts: Running KDE ports on Apple OS X
On Samstag, 15. März 2014 14:35:15 CEST, mk-li...@email.de wrote: On 15 Mar 2014, at 13:35 , Thomas Lübking thomas.luebk...@gmail.com wrote: On Samstag, 15. März 2014 12:07:46 CEST, René JV Bertin wrote: and who knows maybe even support KWin for those of us using X11 apps ... What's your concern here? X11 on OSX should be provided by XQuartz which should provide native OSX titlebars (and integration into the OSX WM) Actually Qt4 gets installed in its native version as port qt4-mac these days. This means that XQuartz (X11.app) isn’t started at all to run KDE apps, if I am not mistaken. I guess he was referring to actual X11 clients (xeyes ;-) Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Review Request 116787: Always create NETEventFilter (a QWidget subclass) in the main application thread
On March 13, 2014, 10:40 p.m., Thomas Lübking wrote:
You'll need a drawable, clients will require XInitThreads if that is
accessed from a different than the GUI thread, but it might be possible to
use an internal Window and move the QObject to the GUI thread on
construction.
Martin Gräßlin wrote:
clients will require XInitThreads
Qt does that
My Qt broken?
// gcc -fPIC -o qapplication `pkg-config --libs --cflags Qt5Widgets` -lstdc++
qapplication.cpp
#include QApplication
#include QWidget
#include QtDebug
class Widget : public QWidget {
public:
Widget() : QWidget() {}
protected:
virtual void showEvent(QShowEvent *ev) {
qDebug() QCoreApplication::testAttribute(Qt::AA_X11InitThreads);
QWidget::showEvent(ev);
}
};
int main(int argc, char **argv)
{
QApplication a(argc, argv);
Widget w;
w.show();
return a.exec();
}
Prints false (as i frankly expected ...)
- Thomas
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116787/#review52915
---
On March 14, 2014, 10:36 a.m., Aaron J. Seigo wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116787/
---
(Updated March 14, 2014, 10:36 a.m.)
Review request for KDE Frameworks, kwin and Martin Gräßlin.
Repository: kwindowsystem
Description
---
When using KWindowInfo from a thread other than the main application thread,
the application fails on an assert triggered by creating a QWidget in another
thread. This is due to NETEventFilter being a QWidget. This patch addresses
the issue by using a QObject to create the NETEventFilter, which is itself
first moved to the main application thread.
Diffs
-
src/kwindowsystem.cpp 4c17baa
src/kwindowsystem_p_x11.h 75f3028
src/kwindowsystem_x11.cpp 95c396b
Diff: https://git.reviewboard.kde.org/r/116787/diff/
Testing
---
Used in the Sprinter Windows plugin and works lovely to find desktops,
windows, etc.
Thanks,
Aaron J. Seigo
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116787: Always create NETEventFilter (a QWidget subclass) in the main application thread
On March 13, 2014, 10:40 p.m., Thomas Lübking wrote:
You'll need a drawable, clients will require XInitThreads if that is
accessed from a different than the GUI thread, but it might be possible to
use an internal Window and move the QObject to the GUI thread on
construction.
Martin Gräßlin wrote:
clients will require XInitThreads
Qt does that
Thomas Lübking wrote:
My Qt broken?
// gcc -fPIC -o qapplication `pkg-config --libs --cflags Qt5Widgets`
-lstdc++ qapplication.cpp
#include QApplication
#include QWidget
#include QtDebug
class Widget : public QWidget {
public:
Widget() : QWidget() {}
protected:
virtual void showEvent(QShowEvent *ev) {
qDebug()
QCoreApplication::testAttribute(Qt::AA_X11InitThreads);
QWidget::showEvent(ev);
}
};
int main(int argc, char **argv)
{
QApplication a(argc, argv);
Widget w;
w.show();
return a.exec();
}
Prints false (as i frankly expected ...)
Martin Gräßlin wrote:
might be the attribute is broken. Look at
https://qt.gitorious.org/qt/qtbase/source/45f264b682e0b2ad7a162bd75b702837fe04c06a:src/plugins/platforms/xcb/qxcbintegration.cpp#L131
- it's clearly called
Seems to be Qt4 stuff only (and not marked deprecated in the API doc... tss) -
at least according to lxr.kde.org it's only in the namespace header of Qt5, but
it's clearly invoked as condition in qapplication_x11.cpp on Qt4
So yes - as long as xcb has xlib support (;-) XInitThreads is called for every
Qt5 application.
- Thomas
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116787/#review52915
---
On March 14, 2014, 10:36 a.m., Aaron J. Seigo wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116787/
---
(Updated March 14, 2014, 10:36 a.m.)
Review request for KDE Frameworks, kwin and Martin Gräßlin.
Repository: kwindowsystem
Description
---
When using KWindowInfo from a thread other than the main application thread,
the application fails on an assert triggered by creating a QWidget in another
thread. This is due to NETEventFilter being a QWidget. This patch addresses
the issue by using a QObject to create the NETEventFilter, which is itself
first moved to the main application thread.
Diffs
-
src/kwindowsystem.cpp 4c17baa
src/kwindowsystem_p_x11.h 75f3028
src/kwindowsystem_x11.cpp 95c396b
Diff: https://git.reviewboard.kde.org/r/116787/diff/
Testing
---
Used in the Sprinter Windows plugin and works lovely to find desktops,
windows, etc.
Thanks,
Aaron J. Seigo
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116787: Always create NETEventFilter (a QWidget subclass) in the main application thread
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116787/#review52915 --- You'll need a drawable, clients will require XInitThreads if that is accessed from a different than the GUI thread, but it might be possible to use an internal Window and move the QObject to the GUI thread on construction. src/kwindowsystem_x11.cpp https://git.reviewboard.kde.org/r/116787/#comment37245 QWidget::winId() src/kwindowsystem_x11.cpp https://git.reviewboard.kde.org/r/116787/#comment37246 QWidget::winId() - Thomas Lübking On March 13, 2014, 6:44 p.m., Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116787/ --- (Updated March 13, 2014, 6:44 p.m.) Review request for KDE Frameworks, kwin and Martin Gräßlin. Repository: kwindowsystem Description --- When using KWindowInfo from a thread other than the main application thread, the application fails on an assert triggered by creating a QWidget in another thread. This is due to NETEventFilter being a QWidget. This patch addresses the issue by using a QObject to create the NETEventFilter, which is itself first moved to the main application thread. Diffs - src/kwindowsystem_p_x11.h 75f3028 src/kwindowsystem_x11.cpp 95c396b Diff: https://git.reviewboard.kde.org/r/116787/diff/ Testing --- Used in the Sprinter Windows plugin and works lovely to find desktops, windows, etc. Thanks, Aaron J. Seigo ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115137: Provide information about the active screen in KWindowSystem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115137/#review51954 --- src/kwindowsystem_x11.cpp https://git.reviewboard.kde.org/r/115137/#comment36936 Brainstorm. Assuming this is of rare interest and we would want to limit X11 roundtrips and pointer tracking. The WM could then simply set the strategy (mouse/active window) and ::activeOutput() could check that to calculate the reult on request. KWindowSystem could (on connect notify) track the mouse/active window to emit the signal. This way tracking would only be required if/while some client is really interested. Downside is that 2 or more clients could be tracking simultanously. Benefit would be that other WMs can adapt this very easily and we don't rely on XI2 support (what will probably also not work if the mouse is navigated by the keyboard?) src/netwm.cpp https://git.reviewboard.kde.org/r/115137/#comment36930 The API says the parameter can be NULL, nstrdup will then return a casted nullptr and this will segfault. (Or I missed something?) - Thomas Lübking On Jan. 31, 2014, 1:01 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115137/ --- (Updated Jan. 31, 2014, 1:01 p.m.) Review request for KDE Frameworks, kdewin and kwin. Repository: kwindowsystem Description --- The rational for these changes is based on the discussion in http://article.gmane.org/gmane.comp.kde.devel.plasma/27579/ Plasma needs to know which is the active screen and so far only KWin knows it, so we need to make everybody aware of it. --- Add convenient wrapper for active screen to KWindowSystem A method is added to get the identifier of the active screen as a QString and a signal whenever the active screen changes. This method is only provided for X11, on Windows and Mac a null QString is returned as the identifier. Add an active screen property to NETRootInfo The active screen is intended to be set by KWin to the active screen it's using. This can be used by a Client to manually position e.g. override redirect windows on the active screen. It's intended as a help for multi-screen setups where a Client can only do guesses on where to position e.g. a notification window. It's a KDE specific extension as property _KDE_NET_ACTIVE_SCREEN and announced in the supported properties. Diffs - tests/activeoutputtest.cpp PRE-CREATION tests/CMakeLists.txt ce68cc505a69ea9a3cf645e9ae587bd89abe1648 src/netwm_p.h 41792b330f7405034f4d51fb31a4de5dd674b6d0 src/netwm_def.h 8b1ccb8bd731aefb9559c8f2b450337b0312ed4d src/netwm.cpp 84eb137492e0afaaac80e8d26561fd8f8aff9c27 src/netwm.h 393a29de3153a8b291b9fb249bd3eaeb1ba4e7d5 src/kwindowsystem_x11.cpp 01c78c1debf95d5a176e2153139da19abf383c41 src/kwindowsystem_win.cpp 96148b2d808396a3046204e55fd19d767db017c5 autotests/netrootinfotestwm.cpp 120fbee92d0b22862d8ce746b3b30891ecd9f056 src/kwindowsystem.h 3de0fea179dd468a78a265808fc64704027ec30d src/kwindowsystem_mac.cpp 8bd2ac763fa26ba49e7733fc3ba93e755383928c Diff: https://git.reviewboard.kde.org/r/115137/diff/ Testing --- * wm part of NETWM is unit tested * KWindowSystem is only compile tested (unit testing is difficult as we need a window manager which supports this property which is at the moment of this writing: none) * Windows and Mac is not even compile tested, that's why kdewin is included in the review. If you have the time for it, please do a compile test. Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Lokalization for KDE AppStream AppData files
Notice that I don't care much about i18n at all (so i don't intend nor could argue), just curious: On Dienstag, 25. Februar 2014 15:13:07 CEST, Matthias Klumpp wrote: Hi again! I talked to some people, and it looks like merging the translation back into one file using existing tools is not possible. From what i understood the issue is that intltool needs a _prefixed tag to separate translatable from untranslatable elements. Would not p lang=x (assuming x to be some invalid lang ID - i do not care about i18n...) be sufficient in that regard? Is intltool really incapable of selecting a specialized lang as translation source? Cheers, Thomas
Re: Lokalization for KDE AppStream AppData files
On Dienstag, 25. Februar 2014 22:22:36 CEST, Matthias Klumpp wrote: 2014-02-25 21:51 GMT+01:00 Kevin Krammer kram...@kde.org: On Tuesday, 2014-02-25, 21:36:27, Albert Astals Cid wrote: ... If that is your final statement, I will write the AppData recommendation without any translation support for KDE. There is no tool available which does what you want, and I can't take the task to write one (I also consider it useless, but that's unrelated). Recap: the desired action is to have file.xml - p lang=xfoo bar/p and turn that into file.xml - p lang=xfoo bar/p p lang=enfoo bar/p p lang=deföö bär/p p lang=frle fó et la bàr/p p lang=esel fobarro/p intltool/itstool /can/ select p lang=xfoo bar/p as translation source, correct? It creates a .po file for the translators and can write back an xml file (from the .po), but only /extend/ p lang=xfoo bar/p, not merge with existing translations - correct? So the outstanding task would be to kick all pre-translated p lang=!x elements before running the pass which writes the translated xml file? That frankly sounds like an xmlstarlet one-liner... is that the problem? Cheers, Thomas PS: Having untranslated AppData is better than no AppData. *LOL* - i'll bring that argument next time i want to introduce a visual string in a minor release ... :-P
Re: Lokalization for KDE AppStream AppData files
On Dienstag, 25. Februar 2014 23:20:18 CEST, Matthias Klumpp wrote: No, it takes pfoo bar/p and turns that into pfoo bar/p p lang=enfoo bar/p p lang=deföö bär/p p lang=frle fó et la bàr/p p lang=esel fobarro/p I thought, plain p would *not* to be translated? However, same procedure. That frankly sounds like an xmlstarlet one-liner... is that the problem? How would that look like? That would be really cool :-) (I never worked with xmlstarlet) $ xml ed -d //*/p[@lang!='x'] /path/to/appdata.xml resp. (matches all elements, not just p) $ xml ed -d //*[@lang!='x'] /path/to/appdata.xml This will delete all (p) elements that have a lang attribute which is not x $ xml ed -d //*[@lang] /path/to/appdata.xml deletes all elements with a lang attribute You can also select subpaths (//* globs) $ xml ed -d //*/div[@align!='center']/*[@lang] /path/to/appdata.xml -- OT Given that Fedora wants to kick out all apps without AppData from their software center You mean I should simply stress my point with a gun? Seriously, i'd just ignore such attempts to threaten by we will ship a crippled package manager that does not show your software. It's not a very scary threat (they'll probably get bug reports), inacceptable style and certainly no base to start any discussion. Cheers, Thomas
Re: Lokalization for KDE AppStream AppData files
On Dienstag, 25. Februar 2014 23:45:59 CEST, Matthias Klumpp wrote: Well, it's not a threat. That's my point ;-) I am no Fedora guy I didn't mean to imply that or that you were trying to threat anyone - just that If you don't do this, i'll get myself bugreports is certainly nothing that would cause me to act at all, let alone acting hasty. Cheers, Thomas
Re: Moving Baloo forward
On Samstag, 22. Februar 2014 10:37:04 CEST, GEO wrote: You could a share a document not containing any personal information (a third party document stored on your hdd), but the comments or tags could contain information you do not want to share with others. And you might just as well want to share/store them - there's just no proper auto-solution. The filemanger/kio will have to ask about what to do with the metadata and then it's just as easy to drop them. It should actually do so with *any* document type that contains metadata (docuement history telling, that says your boss is a complete tool...) but that would require knowledge of this metadata existence/format in the first place, so operating on the FS layer and using xattr or sidecars is far better then document specific metadata (an issue that could only be mitigated by eg. kio metadata plugins) Also I assume that for increased xattr support, dolphin would likely indicate them with an overlay and provide rw access through a rmb entry? That way you'd also see that you just copied a file including some metadata. Cheers, Thomas
Re: Downgrade KDE SC Version 4.12.2
On Sonntag, 23. Februar 2014 09:22:22 CEST, Kanjana wrote: Thanks for responding. Yes, I tried several pertinent n/g's and fora. I'd better prepare to reinstall the distro. a) You can ask such questions at http://forum.kde.org b) something very much likely overrode your ~/.kde[4]/share/config/plasma*rc files - c) Re-installing is *never* a reasonable solution to any problem (but windows) and in this case *very* much likely will at best make things not worse, but not restore your former settings. Check whether the distro changed the KDEDIR settings (ie. whether you now eg. have ~/.kde AND ~/.kde4) If not and you don't have a backup of your configuration, it's very most likely lost and you'll have to recreate it, sorry. Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: KWindowSystem
On Mittwoch, 19. Februar 2014 23:19:00 CEST, Damian Ivanov wrote: Usecase: Well in kwindowsystem.h you already have stuff like minimizeWindow,unminize, raise,lower, so it would just be logical to look for it there. Convenience access to certain properties and features of the window manager. The class KWindowSystem provides information about the state of the window manager and allows asking the window manager to change them using a more high-level interface than the NETWinInfo/NETRootInfo lowlevel classes. I guess it was left out since closed is not a state of the window - the window's just gone. @Martin Since NETWinInfo and NETRootInfo only deal with NETWM, abstracting more functions into KWindowSystem (thus shifting its meaning a bit) might be necessary reg. Wayland (and as it seems that GNOME just completeley abandoned the NETWM spec...) Also in kwindowsystem I pass the window to minimize/lower/raise as int. In netwm.* it doesn't take the int as argument for me. NETRootInfo(QX11Info::display(), NET::CloseWindow).closeWindowRequest(wId); Window in NETRootInfo is (on X11!) just an alias for WId which is NOT integer (though effectively 32bit on X11, but that does not hold for all systems) Maybe (https://mail.gnome.org/archives/commits-list/2013-March/msg07200.html) is related? No, but this: However with the icon property being unused anywhere else in GNOME3, applications have started to not set any window icon at all. pretty much explains it. The window likely just sets no icon (but hopefully some gnome specific hint?) at all. - Can you please post the output of xprop for the window? Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Review Request 115878: File: Add a thin wrapper around different xattr implementations.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115878/#review50183
---
src/file/lib/baloo_xattr_p.h
https://git.reviewboard.kde.org/r/115878/#comment35288
I've to admit that i'm not sure how various compilers or the xattr headers
will react to this, but you might want to try:
namespace BalooXattrInternal {
#if defined(Q_OS_LINUX)
#include sys/xattr.h
...
#endif
}
namespace Baloo {
inline ssize_t getxattr(const char* path, const char* name, void* value,
size_t size)
{
#if defined(Q_OS_LINUX)
return BalooXattrInternal::getxattr(path, name, value, size);
}
using namespace BalooXattrInternal;
using Baloo::getxattr;
using Baloo::setxattr;
---
getxattr setxattr should then always be in scope and refer to the Baloo
variants (ie. the wrappers)
- Thomas Lübking
On Feb. 18, 2014, 10:51 p.m., Raphael Kubo da Costa wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115878/
---
(Updated Feb. 18, 2014, 10:51 p.m.)
Review request for Baloo and Vishesh Handa.
Repository: baloo
Description
---
File: Add a thin wrapper around different xattr implementations.
OS X, Linux and some BSDs all support extended file attributes in a way or
another, but the API differs among the operating systems.
Introduce baloo_getxattr() and baloo_setxattr(), named after the OS X and
Linux APIs for getting and setting extended attributes, to perform the right
calls depending on the operating system.
These functions accept as parameters the arguments that are common across
all xattr implementations -- this means one cannot pass custom |flags| on
Linux or |options| on OS X, but that should be fine for now as the code was
not doing that anyway.
Diffs
-
src/file/lib/autotests/filefetchjobtest.cpp
a738c62a58d29ca092e53702d4852a48634d4315
src/file/lib/autotests/filemodifyjobtest.cpp
4ad1a6d2138d9754356a573eaf5f2487fcbe220f
src/file/lib/baloo_xattr_p.h PRE-CREATION
src/file/lib/filecustommetadata.cpp
3a01520947a324dc1674f304e44eca1ae4a19ed7
src/file/lib/xattrdetector.cpp e05984e611e8582d0e18d08f93b325381222d280
Diff: https://git.reviewboard.kde.org/r/115878/diff/
Testing
---
baloo finally builds on FreeBSD. filefetchjobtest and filemodifyjobtest fail
just like they do on Linux :-)
Thanks,
Raphael Kubo da Costa
Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Review Request 115408: Fix alignment for mime icon in kpropertiesdialog
On Feb. 8, 2014, 2:34 p.m., Thomas Lübking wrote: Here's my vote then. Unless there's concern, push it in some days™ (ie. tuesday or so, should leave enough time to cry out) kdeuser56 kdeuser56 wrote: push it sounds like I should push it, however I can't do it, as I do not have a dev account. Could you push it for me? Pushing in frameworks/kio would also be nice (diff can be found here: http://pastebin.kde.org/p7eahjnoq)! kdeuser56 kdeuser56 wrote: Thomas: Would you mind shipping it for me? I'd have to setup a frameworks build first. I'll push it then if that didn't happen otherwise, but Frank might want to push it before. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115408/#review49252 --- On Feb. 8, 2014, 10:02 a.m., kdeuser56 kdeuser56 wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115408/ --- (Updated Feb. 8, 2014, 10:02 a.m.) Review request for kdelibs and Frank Reininghaus. Repository: kdelibs Description --- The iconbutton and the iconlabel were clearly aligned using the old style, when everything was left aligned. In my interpretation of the KDE HIG guidelines, the iconbutton/label should also be right aligned. Especially with bigger font sizes, the visual issue becomes obvious. Idea: see kproperties-dolphin-1.png Before: see before-1.png and before-2.png After: see after-1.png and after-2.png Diff for kio (frameworks) can be found here: http://pastebin.kde.org/p4ojv6a1w Diffs - kio/kfile/kpropertiesdialog.cpp 6611ee7 Diff: https://git.reviewboard.kde.org/r/115408/diff/ Testing --- Compiled and installed. Works as expected. File Attachments idea https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/91648ead-a248-4c42-b45c-8741d1291955__kproperties-dolphin-1.png before1 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/f9b5bba2-f810-4de5-b292-da66e0cf60ac__before-1.png before2 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/516dbfec-597f-4f95-bb83-797d10ddebfc__before-2.png after1 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/03fdb43f-6f67-407f-be27-e6afad906340__after-1.png after2 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/06455bef-a229-4a1a-b9c0-cb1de61f7fa0__after-2.png center-center https://git.reviewboard.kde.org/media/uploaded/files/2014/01/31/ab93b637-e914-4521-a9c5-025515c97790__widget-center-icon-center.png left-left https://git.reviewboard.kde.org/media/uploaded/files/2014/01/31/38cd56fb-c411-4876-bebe-bc9923855751__widget-left-icon-leftunpatched.png right-center https://git.reviewboard.kde.org/media/uploaded/files/2014/01/31/80672290-b6fb-4fe3-b2ab-5ea5f0c6ed53__widget-right-icon-center.png right-right https://git.reviewboard.kde.org/media/uploaded/files/2014/01/31/8dec5429-021a-49a0-a34f-1a2e77d7aeef__widget-right-icon-right.png Thanks, kdeuser56 kdeuser56
Re: Keyboard shortcut enhancement.
Am Freitag, 14. Februar 2014 schrieb Andreas Pakulat : In particular I'm using it to start my preferred browser and to control my preferred mp3 player. The latter is a cli-tool so it has no global shortcuts support but it has invocations which talk to the running instance and can do play, pause etc. That part of khotkeys has been working for me from KDE 4.2 up until now (4.11 here), so no idea why it is considered to be 'broken'. I think, the only part severely broken is triggering random input events. On non non-focused windows that requires xsendevent (for kbd input at least) which noeadays seem largely ignored by clients. This might be different with wayland (ability to discriminate a synthetic event in general?), but i guess it's a security concern.?. An alternative might be a GUI for xbindkeys and a resp. wayland pendant (if such exists), but i guess kglobalaccel would have to be moved to such backend in general. Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Keyboard shortcut enhancement.
On Samstag, 15. Februar 2014 00:48:26 CEST, p.kubik...@gmail.com wrote: On Friday 14 of February 2014 17:20:44 Michael Jansen wrote: Window Trigger Action == This is more or less broken since kde4 afaik (never used it myself). This is the first candidate to go. Does edge snapping depend on Window Trigger Action or it's done without this mechanism? Also I don't understand why does it belong to the khotkeys. Of course it's connected but I not that much. Window Trigger Action allows you to bind de/activation and un/mapping of windows to random commands resp. to dbus calls or sending keyboard input. At least sending keyboard input virtually broken (no matter how it's triggered) This has nothing to do with window movement or active screen edges. Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Keyboard shortcut enhancement.
On Freitag, 14. Februar 2014 01:22:19 CEST, Christoph Feck wrote: On Friday 14 February 2014 01:07:10 p.kubik...@gmail.com wrote: The mechanism behind that feature is quite strict. There are always some mod keys + ONE other keys (such as letters). There is no way to create a shortcut with two other keys. I just tried it in Kate I think he points kglobalaccel (kcmshell4 keys/khotkeys) - it should be possible (on X11, might require Xtst), but rather not trivial as inside a focused client. kglobalaccel could only grab the first modified key, would use it to grab the entire keyboard, wait for the next key and see whether it's some global shortcut. If not, or the modifier changed, the first key event /has/ to be repeated and the second one passed on. No idea whether that's possible on OSX or Windows at all. FYI: That's emacs style shortcuts and RMS is probably upset enough that MS dared to add it to VS 2005 - but he will certainly not like that people now associate it there ;-) Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Review Request 115408: Fix alignment for mime icon in kpropertiesdialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115408/#review49252 --- Ship it! Here's my vote then. Unless there's concern, push it in some days™ (ie. tuesday or so, should leave enough time to cry out) - Thomas Lübking On Feb. 8, 2014, 10:02 a.m., kdeuser56 kdeuser56 wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115408/ --- (Updated Feb. 8, 2014, 10:02 a.m.) Review request for kdelibs and Frank Reininghaus. Repository: kdelibs Description --- The iconbutton and the iconlabel were clearly aligned using the old style, when everything was left aligned. In my interpretation of the KDE HIG guidelines, the iconbutton/label should also be right aligned. Especially with bigger font sizes, the visual issue becomes obvious. Idea: see kproperties-dolphin-1.png Before: see before-1.png and before-2.png After: see after-1.png and after-2.png Diff for kio (frameworks) can be found here: http://pastebin.kde.org/p4ojv6a1w Diffs - kio/kfile/kpropertiesdialog.cpp 6611ee7 Diff: https://git.reviewboard.kde.org/r/115408/diff/ Testing --- Compiled and installed. Works as expected. File Attachments idea https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/91648ead-a248-4c42-b45c-8741d1291955__kproperties-dolphin-1.png before1 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/f9b5bba2-f810-4de5-b292-da66e0cf60ac__before-1.png before2 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/516dbfec-597f-4f95-bb83-797d10ddebfc__before-2.png after1 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/03fdb43f-6f67-407f-be27-e6afad906340__after-1.png after2 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/06455bef-a229-4a1a-b9c0-cb1de61f7fa0__after-2.png center-center https://git.reviewboard.kde.org/media/uploaded/files/2014/01/31/ab93b637-e914-4521-a9c5-025515c97790__widget-center-icon-center.png left-left https://git.reviewboard.kde.org/media/uploaded/files/2014/01/31/38cd56fb-c411-4876-bebe-bc9923855751__widget-left-icon-leftunpatched.png right-center https://git.reviewboard.kde.org/media/uploaded/files/2014/01/31/80672290-b6fb-4fe3-b2ab-5ea5f0c6ed53__widget-right-icon-center.png right-right https://git.reviewboard.kde.org/media/uploaded/files/2014/01/31/8dec5429-021a-49a0-a34f-1a2e77d7aeef__widget-right-icon-right.png Thanks, kdeuser56 kdeuser56
Re: Review Request 115137: Provide information about the active screen in KWindowSystem
On Jan. 20, 2014, 5 p.m., Thomas Lübking wrote: given the ratio by this property is set (often) and read (rarely), i wonder whether we could establish a semi-async functionality, where the client sends a message to have the property updated, then syncs, reads and returns the updated property? reg. screen ./. output terminology: we've active screen everywhere and we can probably not expose the screen/output problem to end users. Also Qt talks of screen in this regard. I'd suggest to keep activeScreen and specify the meaning in the comment. Martin Gräßlin wrote: i wonder whether we could establish a semi-async functionality, where the client sends a message to have the property updated, then syncs, reads and returns the updated property? That would be different to how all the other methods in KWindowSystem works. What could be considered is not having a signal to not wake up the clients or only emit the signal if connect-notify is called. Also Qt talks of screen in this regard. This was the reason why I went with screen in the first place. The class is called QScreen and not QOutput. Calling it output didn't occur to me at all. I don't mind how it is called and from a technical perspective (especially considering XRandR) I agree with Fredrik. But from a user point of view I think screen is the better name due to the QScreen anology. What could be done is using output in the NET class to be closer to the X11 world, but keep the name screen in the abstraction. I don't know whether output makes sense on Windows or Mac (in case they ever implement it). Thomas Lübking wrote: That would be different to how all the other methods in KWindowSystem works. My major concern would be the mouse driven active screen. Right now, when the active screen is required, kwin just checks the current mouse position. When we need to keep the info updated (signal or not), that means that kwin has to poll the mouse all the time (even if we would smoothen the update by a timer so the active screen isn't updated a 1000 times when moving the cursor around a screen edge). And while knowing the active screen is certainly nice, our main concern right now is the occasional raiseOrLower taskbar case. A 2-pass query would nicely circumvent this as the data only needs to be updated when really and likely rarely required. Fredrik Höglund wrote: kwin should be using XI2 instead of polling. We already have properties that are updated every time the stacking order changes and every time the active window changes. Given that, I don't think the update frequency for this property is going to be a problem. So with regards to the terminology, this is what we're looking at: X | Qt +- Output | Screen Screen | Virtual desktop Virtual desktop | ? Which is just really unfortunate. It's bound to cause confusion no matter which name we pick, and it doesn't help that the QScreen documentation doesn't explain the terminology. Windows and Wayland also use output, while I think Mac OS uses display. kwin should be using XI2 instead of polling yes, should - https://git.reviewboard.kde.org/r/111875/ - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115137/#review47824 --- On Jan. 20, 2014, 1:14 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115137/ --- (Updated Jan. 20, 2014, 1:14 p.m.) Review request for KDE Frameworks, kdewin and kwin. Repository: kwindowsystem Description --- The rational for these changes is based on the discussion in http://article.gmane.org/gmane.comp.kde.devel.plasma/27579/ Plasma needs to know which is the active screen and so far only KWin knows it, so we need to make everybody aware of it. --- Add convenient wrapper for active screen to KWindowSystem A method is added to get the identifier of the active screen as a QString and a signal whenever the active screen changes. This method is only provided for X11, on Windows and Mac a null QString is returned as the identifier. Add an active screen property to NETRootInfo The active screen is intended to be set by KWin to the active screen it's using. This can be used by a Client to manually position e.g. override redirect windows on the active screen. It's intended as a help for multi-screen setups where a Client can only do guesses on where
Re: Review Request 115408: Right align mime icon in kpropertiesdialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115408/#review48658 --- tried to center align it? - Thomas Lübking On Jan. 30, 2014, 9:07 p.m., kdeuser56 kdeuser56 wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115408/ --- (Updated Jan. 30, 2014, 9:07 p.m.) Review request for kdelibs. Repository: kdelibs Description --- The iconbutton and the iconlabel were clearly aligned using the old style, when everything was left aligned. In my interpretation of the KDE HIG guidelines, the iconbutton/label should also be right aligned. Especially with bigger font sizes, the visual issue becomes obvious. Idea: see kproperties-dolphin-1.png Before: see before-1.png and before-2.png After: see after-1.png and after-2.png Diff for kio (frameworks) can be found here: http://pastebin.kde.org/p4ojv6a1w Diffs - kio/kfile/kpropertiesdialog.cpp 6611ee7 Diff: https://git.reviewboard.kde.org/r/115408/diff/ Testing --- Compiled and installed. Works as expected. File Attachments idea https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/91648ead-a248-4c42-b45c-8741d1291955__kproperties-dolphin-1.png before1 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/f9b5bba2-f810-4de5-b292-da66e0cf60ac__before-1.png before2 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/516dbfec-597f-4f95-bb83-797d10ddebfc__before-2.png after1 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/03fdb43f-6f67-407f-be27-e6afad906340__after-1.png after2 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/06455bef-a229-4a1a-b9c0-cb1de61f7fa0__after-2.png Thanks, kdeuser56 kdeuser56
Re: Review Request 115408: Right align mime icon in kpropertiesdialog
On Jan. 30, 2014, 9:20 p.m., Thomas Lübking wrote: tried to center align it? kdeuser56 kdeuser56 wrote: Center what? The widget or the iconlabel? I think in case of the widget it makes no sense. In case of the iconlabel the icon itself would be on the exact same position as the icon of the icon button. I tried both, but I find right aligned prettier and more logical considering the text under it. Either. Reason is that due to the arbitrary shape (shadow, padding), rightaligning the icon/button does not really line up with the text - thus looks buggy (failed approach) Otoh, left alingning looks unbalanced mostly due to the vertical tab border (ie. it's less an issue in eg. bespin, which has no vertical tabborder) - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115408/#review48658 --- On Jan. 30, 2014, 9:07 p.m., kdeuser56 kdeuser56 wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115408/ --- (Updated Jan. 30, 2014, 9:07 p.m.) Review request for kdelibs. Repository: kdelibs Description --- The iconbutton and the iconlabel were clearly aligned using the old style, when everything was left aligned. In my interpretation of the KDE HIG guidelines, the iconbutton/label should also be right aligned. Especially with bigger font sizes, the visual issue becomes obvious. Idea: see kproperties-dolphin-1.png Before: see before-1.png and before-2.png After: see after-1.png and after-2.png Diff for kio (frameworks) can be found here: http://pastebin.kde.org/p4ojv6a1w Diffs - kio/kfile/kpropertiesdialog.cpp 6611ee7 Diff: https://git.reviewboard.kde.org/r/115408/diff/ Testing --- Compiled and installed. Works as expected. File Attachments idea https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/91648ead-a248-4c42-b45c-8741d1291955__kproperties-dolphin-1.png before1 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/f9b5bba2-f810-4de5-b292-da66e0cf60ac__before-1.png before2 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/516dbfec-597f-4f95-bb83-797d10ddebfc__before-2.png after1 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/03fdb43f-6f67-407f-be27-e6afad906340__after-1.png after2 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/06455bef-a229-4a1a-b9c0-cb1de61f7fa0__after-2.png Thanks, kdeuser56 kdeuser56
Re: Review Request 115408: Right align mime icon in kpropertiesdialog
On Jan. 30, 2014, 9:20 p.m., Thomas Lübking wrote: tried to center align it? kdeuser56 kdeuser56 wrote: Center what? The widget or the iconlabel? I think in case of the widget it makes no sense. In case of the iconlabel the icon itself would be on the exact same position as the icon of the icon button. I tried both, but I find right aligned prettier and more logical considering the text under it. Thomas Lübking wrote: Either. Reason is that due to the arbitrary shape (shadow, padding), rightaligning the icon/button does not really line up with the text - thus looks buggy (failed approach) Otoh, left alingning looks unbalanced mostly due to the vertical tab border (ie. it's less an issue in eg. bespin, which has no vertical tabborder) kdeuser56 kdeuser56 wrote: I am not sure I understand your point. Could explain me the arbitrary shape problem? I do not think the visual problem is caused by the vertical tab border. Even if I remove that, it still looks bad and the bigger the font gets, the uglier it looks. (Some words are longer in other languages, so this could also be triggered by different language settings). So in my opinion it looks bad, regardless of the theme. Do you have another idea? kdeuser56 kdeuser56 wrote: I would be okay with centering the iconlabel. Centering the widget too would be still better than left aligning, but I would prefer to keep it right. Should I change the diff to center the iconlabel, or should I provide screenshots first? Could explain me the arbitrary shape problem? The icons do not have a defined border as the text. They'll visually end some pixels before the logical end (would even get worse for icons that do not contain a sheet, but even that is visually 2px off) Ugly is subjective. Fact is, that the vertical border creates a distinct border that the left aligned version is closer to than to the implicit right border, thus it's unbalanced (left overweight) If you remove that border, the label visually moves more to the center between window frame and implicit right border (the lineedit), what implies local symmetry, thus stability. (Actually, you might even get a golden mean positioning) Granted: for long texts and huge fonts the part left of the tab certainly becomes neglectable and that effect is lost. - I'd simply center align the icon. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115408/#review48658 --- On Jan. 30, 2014, 9:07 p.m., kdeuser56 kdeuser56 wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115408/ --- (Updated Jan. 30, 2014, 9:07 p.m.) Review request for kdelibs. Repository: kdelibs Description --- The iconbutton and the iconlabel were clearly aligned using the old style, when everything was left aligned. In my interpretation of the KDE HIG guidelines, the iconbutton/label should also be right aligned. Especially with bigger font sizes, the visual issue becomes obvious. Idea: see kproperties-dolphin-1.png Before: see before-1.png and before-2.png After: see after-1.png and after-2.png Diff for kio (frameworks) can be found here: http://pastebin.kde.org/p4ojv6a1w Diffs - kio/kfile/kpropertiesdialog.cpp 6611ee7 Diff: https://git.reviewboard.kde.org/r/115408/diff/ Testing --- Compiled and installed. Works as expected. File Attachments idea https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/91648ead-a248-4c42-b45c-8741d1291955__kproperties-dolphin-1.png before1 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/f9b5bba2-f810-4de5-b292-da66e0cf60ac__before-1.png before2 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/516dbfec-597f-4f95-bb83-797d10ddebfc__before-2.png after1 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/03fdb43f-6f67-407f-be27-e6afad906340__after-1.png after2 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/06455bef-a229-4a1a-b9c0-cb1de61f7fa0__after-2.png Thanks, kdeuser56 kdeuser56
Re: Review Request 115408: Right align mime icon in kpropertiesdialog
On Jan. 30, 2014, 9:20 p.m., Thomas Lübking wrote: tried to center align it? kdeuser56 kdeuser56 wrote: Center what? The widget or the iconlabel? I think in case of the widget it makes no sense. In case of the iconlabel the icon itself would be on the exact same position as the icon of the icon button. I tried both, but I find right aligned prettier and more logical considering the text under it. Thomas Lübking wrote: Either. Reason is that due to the arbitrary shape (shadow, padding), rightaligning the icon/button does not really line up with the text - thus looks buggy (failed approach) Otoh, left alingning looks unbalanced mostly due to the vertical tab border (ie. it's less an issue in eg. bespin, which has no vertical tabborder) kdeuser56 kdeuser56 wrote: I am not sure I understand your point. Could explain me the arbitrary shape problem? I do not think the visual problem is caused by the vertical tab border. Even if I remove that, it still looks bad and the bigger the font gets, the uglier it looks. (Some words are longer in other languages, so this could also be triggered by different language settings). So in my opinion it looks bad, regardless of the theme. Do you have another idea? kdeuser56 kdeuser56 wrote: I would be okay with centering the iconlabel. Centering the widget too would be still better than left aligning, but I would prefer to keep it right. Should I change the diff to center the iconlabel, or should I provide screenshots first? Thomas Lübking wrote: Could explain me the arbitrary shape problem? The icons do not have a defined border as the text. They'll visually end some pixels before the logical end (would even get worse for icons that do not contain a sheet, but even that is visually 2px off) Ugly is subjective. Fact is, that the vertical border creates a distinct border that the left aligned version is closer to than to the implicit right border, thus it's unbalanced (left overweight) If you remove that border, the label visually moves more to the center between window frame and implicit right border (the lineedit), what implies local symmetry, thus stability. (Actually, you might even get a golden mean positioning) Granted: for long texts and huge fonts the part left of the tab certainly becomes neglectable and that effect is lost. - I'd simply center align the icon. I'd suggest to have screenshots and wait for some more opinions then. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115408/#review48658 --- On Jan. 30, 2014, 9:07 p.m., kdeuser56 kdeuser56 wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115408/ --- (Updated Jan. 30, 2014, 9:07 p.m.) Review request for kdelibs. Repository: kdelibs Description --- The iconbutton and the iconlabel were clearly aligned using the old style, when everything was left aligned. In my interpretation of the KDE HIG guidelines, the iconbutton/label should also be right aligned. Especially with bigger font sizes, the visual issue becomes obvious. Idea: see kproperties-dolphin-1.png Before: see before-1.png and before-2.png After: see after-1.png and after-2.png Diff for kio (frameworks) can be found here: http://pastebin.kde.org/p4ojv6a1w Diffs - kio/kfile/kpropertiesdialog.cpp 6611ee7 Diff: https://git.reviewboard.kde.org/r/115408/diff/ Testing --- Compiled and installed. Works as expected. File Attachments idea https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/91648ead-a248-4c42-b45c-8741d1291955__kproperties-dolphin-1.png before1 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/f9b5bba2-f810-4de5-b292-da66e0cf60ac__before-1.png before2 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/516dbfec-597f-4f95-bb83-797d10ddebfc__before-2.png after1 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/03fdb43f-6f67-407f-be27-e6afad906340__after-1.png after2 https://git.reviewboard.kde.org/media/uploaded/files/2014/01/30/06455bef-a229-4a1a-b9c0-cb1de61f7fa0__after-2.png Thanks, kdeuser56 kdeuser56
Re: Moving Baloo forward
On Freitag, 24. Januar 2014 12:59:12 CEST, Vadim Zhukov wrote: It's doubtful at least whether xattr support is a good thing, because it's too easily gets misused: for example, there were viruses on Windows which effectively hidden themselves in NTFS streams. IOW: It's doubtful at least whether using Windows is a good thing, because it's full of viruses. ...That's seriously no argument - viruses can hide themselve everywhere. And there are personal data leaking issues I've pointed out earlier. You're right in that at least kio/dolphin should be xattr aware and present you attributes and ask what to do on effectively copying them. However, *many* files leak private data, carried in their own metadata formats. The problem is simply extended to ASCII, but otoh, that metadata is at least standardized. The worst case is Nepomuk becoming a crashy resource hog again Playing that game on, the worst case would be if your computer overheats, explodes, kills you and your family and burns down your house which will lead to burning down the entire city what will feed global warming to exterminate mankind. Therefore humans cannot develop a way to protect the galaxy from a mega black hole that ultimately sucks away the entire universe. So better stick with the topic of best/worst case scenario of utilizing xattrs where some basically dead code is indeed the worst case - certainly not the best. Cheers, Thomas
Re: Moving Baloo forward
On Samstag, 25. Januar 2014 21:03:44 CEST, Matthew Dawson wrote: At least for ext4, xattrs are the default mode Indeed - removed user_xattr and they're still there. Do you happen to know when this happened? (google got me a patch suggest from mid 2011 but i found no hey heads up: xattr now default on ext4) Sorry for the dated information and thanks for the info), Thomas
Re: Review Request 115311: [kwin] Don't call into GL without a context
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115311/#review48254 --- Looks fine (and required) - thanks. In case you do not have commit rights (nor do intend to ask for), please upload a git format-patch variant (to maintain the commit metadata, namely your identity) For potential future patches (welcome ;-) please set the group to kwin, the KWin maintainer is graesslin. - Thomas Lübking On Jan. 25, 2014, 1:57 a.m., James Jones wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115311/ --- (Updated Jan. 25, 2014, 1:57 a.m.) Review request for kde-workspace, Thomas Lübking and Marco Martin. Repository: kde-workspace Description --- [kwin] Don't call into GL without a context After losing current from the EGL or GLX context, calls to the GL or GLES functions have undefined behavior. Perform all cleanup that may touch OpenGL and check for GL errors before losing current from the context. Diffs - kwin/egl_wayland_backend.cpp b229cdd84161a64d5cd93c189514067867773e7f kwin/eglonxbackend.cpp dd41da55b94821802f2d1464794db39bd636088a kwin/glxbackend.cpp 73f463e9df43c2cd71836ce3f48da84fb4df35ed kwin/scene_opengl.cpp 961e81fbcc39940bc49179899e034ad8a9e802cd Diff: https://git.reviewboard.kde.org/r/115311/diff/ Testing --- Compiled/Installed kde-workspace on x86 kwin_gles (EGL+X11) - Tested mode switching kwin (GLX) - Tested mode switching Thanks, James Jones
Re: Review Request 115137: Provide information about the active screen in KWindowSystem
On Jan. 20, 2014, 5 p.m., Thomas Lübking wrote: given the ratio by this property is set (often) and read (rarely), i wonder whether we could establish a semi-async functionality, where the client sends a message to have the property updated, then syncs, reads and returns the updated property? reg. screen ./. output terminology: we've active screen everywhere and we can probably not expose the screen/output problem to end users. Also Qt talks of screen in this regard. I'd suggest to keep activeScreen and specify the meaning in the comment. Martin Gräßlin wrote: i wonder whether we could establish a semi-async functionality, where the client sends a message to have the property updated, then syncs, reads and returns the updated property? That would be different to how all the other methods in KWindowSystem works. What could be considered is not having a signal to not wake up the clients or only emit the signal if connect-notify is called. Also Qt talks of screen in this regard. This was the reason why I went with screen in the first place. The class is called QScreen and not QOutput. Calling it output didn't occur to me at all. I don't mind how it is called and from a technical perspective (especially considering XRandR) I agree with Fredrik. But from a user point of view I think screen is the better name due to the QScreen anology. What could be done is using output in the NET class to be closer to the X11 world, but keep the name screen in the abstraction. I don't know whether output makes sense on Windows or Mac (in case they ever implement it). That would be different to how all the other methods in KWindowSystem works. My major concern would be the mouse driven active screen. Right now, when the active screen is required, kwin just checks the current mouse position. When we need to keep the info updated (signal or not), that means that kwin has to poll the mouse all the time (even if we would smoothen the update by a timer so the active screen isn't updated a 1000 times when moving the cursor around a screen edge). And while knowing the active screen is certainly nice, our main concern right now is the occasional raiseOrLower taskbar case. A 2-pass query would nicely circumvent this as the data only needs to be updated when really and likely rarely required. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115137/#review47824 --- On Jan. 20, 2014, 1:14 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115137/ --- (Updated Jan. 20, 2014, 1:14 p.m.) Review request for KDE Frameworks, kdewin and kwin. Repository: kwindowsystem Description --- The rational for these changes is based on the discussion in http://article.gmane.org/gmane.comp.kde.devel.plasma/27579/ Plasma needs to know which is the active screen and so far only KWin knows it, so we need to make everybody aware of it. --- Add convenient wrapper for active screen to KWindowSystem A method is added to get the identifier of the active screen as a QString and a signal whenever the active screen changes. This method is only provided for X11, on Windows and Mac a null QString is returned as the identifier. Add an active screen property to NETRootInfo The active screen is intended to be set by KWin to the active screen it's using. This can be used by a Client to manually position e.g. override redirect windows on the active screen. It's intended as a help for multi-screen setups where a Client can only do guesses on where to position e.g. a notification window. It's a KDE specific extension as property _KDE_NET_ACTIVE_SCREEN and announced in the supported properties. Diffs - autotests/netrootinfotestwm.cpp 120fbee92d0b22862d8ce746b3b30891ecd9f056 src/kwindowsystem.h 5bcfd062dcca42d282b70d0683d4ee1da88cc814 src/kwindowsystem_mac.cpp 8bd2ac763fa26ba49e7733fc3ba93e755383928c src/kwindowsystem_win.cpp 96148b2d808396a3046204e55fd19d767db017c5 src/kwindowsystem_x11.cpp 8634240cabc708a608277b34f21c41cee295e48a src/netwm.h aee6cea5e3b65cf6252b50515e4920cb9c96f240 src/netwm.cpp 266afccaf111e6707493b18dad1d9c03dde1d912 src/netwm_def.h 8b1ccb8bd731aefb9559c8f2b450337b0312ed4d src/netwm_p.h 41792b330f7405034f4d51fb31a4de5dd674b6d0 Diff: https://git.reviewboard.kde.org/r/115137/diff/ Testing --- * wm part of NETWM is unit tested * KWindowSystem is only compile tested (unit testing is difficult as we need a window manager which supports this property which is at the moment
Re: Review Request 115079: don't install dbus interface files in kglobalaccel
On Jan. 21, 2014, 1:16 p.m., Martin Gräßlin wrote: I guess it's obvious from the matching review request for kgloballacel: I consider copying the files to every user as the wrong solution. In Qt terms I would give it a -2. esp. since that means to keep them sync'd all the time... again: what is the problem about having a common data package dependency downstream? (I've not much experience on distro packaging, so this is a serious question - even if it might sound dumb) - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115079/#review47868 --- On Jan. 21, 2014, 12:48 p.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115079/ --- (Updated Jan. 21, 2014, 12:48 p.m.) Review request for kde-workspace and Martin Gräßlin. Repository: kde-workspace Description --- to go with https://git.reviewboard.kde.org/r/115078/ use local dbus interface files Diffs - kcontrol/keys/org.kde.kglobalaccel.Component.xml PRE-CREATION kcontrol/keys/org.kde.KGlobalAccel.xml PRE-CREATION kcontrol/keys/CMakeLists.txt 072e614 Diff: https://git.reviewboard.kde.org/r/115079/diff/ Testing --- Thanks, Jonathan Riddell
Re: Moving Baloo forward
On Dienstag, 21. Januar 2014 13:37:29 CEST, viv...@gmail.com wrote: And windows? HPFS/NTFS has xattr support (through alternative data streams) and WINNT supports handling xattr on FAT as well. The problem about xattr is rather that 99% of all ext3/4 users will atm get setfattr: filename: Operation not supported ie. xattr nowhere being activated. This would have to change dramatically in order to make a xattr implementation useful. Next thing is global xattr awareness, ie. one has to consider that even if kio/dolphin would have great xattr support and cp aliasing -a by default etc., the user might move/copy the data using nautilus or some other lousy filemanager :-P I *do* consider xattr the BY FAR more sane approach to the problem, but currently do frankly not see this on end user desktops :-( Linux/Desktop has to become a xattr OS before relying on it - thus imo xattr support could only be explicitly optional to get there. Otherwise ubuntusers™ will complain loosing their metadata all the time. Unfortunately this isn't MacOS where SJ. just said: do or you're fired, you censored! Keeping metadata in id3v2/xmp/iptc unfortunately only covers few filetypes (w/o invoking sidecars, ie. what __MACOSX does when entering the outer world) - directories could be stored in .directory Cheers, Thomas
Re: Qt 5.3 to log all debug/warning/error messages to journald on systemd systems
On Dienstag, 21. Januar 2014 13:55:15 CEST, Sebastian Kügler wrote: One thing that may concern me is how to clean the system from debugging messages then. Sometimes applications go rogue on qDebug() What - from multiple bug reports and personal observation - can make journald going rogue itself anybody knows whether it's fixed in this regard (esp. compressing equal messages into one and a counter?) Cheers, Thomas
Re: Review Request 115137: Provide information about the active screen in KWindowSystem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115137/#review47824 --- given the ratio by this property is set (often) and read (rarely), i wonder whether we could establish a semi-async functionality, where the client sends a message to have the property updated, then syncs, reads and returns the updated property? reg. screen ./. output terminology: we've active screen everywhere and we can probably not expose the screen/output problem to end users. Also Qt talks of screen in this regard. I'd suggest to keep activeScreen and specify the meaning in the comment. - Thomas Lübking On Jan. 20, 2014, 1:14 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115137/ --- (Updated Jan. 20, 2014, 1:14 p.m.) Review request for KDE Frameworks, kdewin and kwin. Repository: kwindowsystem Description --- The rational for these changes is based on the discussion in http://article.gmane.org/gmane.comp.kde.devel.plasma/27579/ Plasma needs to know which is the active screen and so far only KWin knows it, so we need to make everybody aware of it. --- Add convenient wrapper for active screen to KWindowSystem A method is added to get the identifier of the active screen as a QString and a signal whenever the active screen changes. This method is only provided for X11, on Windows and Mac a null QString is returned as the identifier. Add an active screen property to NETRootInfo The active screen is intended to be set by KWin to the active screen it's using. This can be used by a Client to manually position e.g. override redirect windows on the active screen. It's intended as a help for multi-screen setups where a Client can only do guesses on where to position e.g. a notification window. It's a KDE specific extension as property _KDE_NET_ACTIVE_SCREEN and announced in the supported properties. Diffs - autotests/netrootinfotestwm.cpp 120fbee92d0b22862d8ce746b3b30891ecd9f056 src/kwindowsystem.h 5bcfd062dcca42d282b70d0683d4ee1da88cc814 src/kwindowsystem_mac.cpp 8bd2ac763fa26ba49e7733fc3ba93e755383928c src/kwindowsystem_win.cpp 96148b2d808396a3046204e55fd19d767db017c5 src/kwindowsystem_x11.cpp 8634240cabc708a608277b34f21c41cee295e48a src/netwm.h aee6cea5e3b65cf6252b50515e4920cb9c96f240 src/netwm.cpp 266afccaf111e6707493b18dad1d9c03dde1d912 src/netwm_def.h 8b1ccb8bd731aefb9559c8f2b450337b0312ed4d src/netwm_p.h 41792b330f7405034f4d51fb31a4de5dd674b6d0 Diff: https://git.reviewboard.kde.org/r/115137/diff/ Testing --- * wm part of NETWM is unit tested * KWindowSystem is only compile tested (unit testing is difficult as we need a window manager which supports this property which is at the moment of this writing: none) * Windows and Mac is not even compile tested, that's why kdewin is included in the review. If you have the time for it, please do a compile test. Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115078: don't install dbus interface files in kglobalaccel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115078/#review47587 --- and what if kdelibs (really, not kde-runtime?) from SC4 is not installed? KF/5 would be broken then, would it not? What about having a common data package downstream? - Thomas Lübking On Jan. 17, 2014, 4:07 p.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115078/ --- (Updated Jan. 17, 2014, 4:07 p.m.) Review request for KDE Frameworks and Martin Gräßlin. Repository: kglobalaccel Description --- don't install dbus interface files in kglobalaccel, these overlap with the equivalent files in kdelibs4 which causes problems for some distributions Diffs - KF5GlobalAccelConfig.cmake.in 5f069d3 src/CMakeLists.txt d48e92e Diff: https://git.reviewboard.kde.org/r/115078/diff/ Testing --- Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115079: don't install dbus interface files in kglobalaccel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115079/#review47586 --- there's no diff - should there be? - Thomas Lübking On Jan. 17, 2014, 4:09 p.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115079/ --- (Updated Jan. 17, 2014, 4:09 p.m.) Review request for kde-workspace and Martin Gräßlin. Repository: kde-workspace Description --- to go with https://git.reviewboard.kde.org/r/115078/ use local dbus interface files Diffs - Diff: https://git.reviewboard.kde.org/r/115079/diff/ Testing --- Thanks, Jonathan Riddell
Re: Review Request 114999: Add KF5 namespace to dbus interface
On Jan. 14, 2014, 7:22 p.m., Martin Gräßlin wrote: like with the other patch I'm not sure whether that's a good idea as that breaks any communication with the kdelibs4. is there a functional incompitibility between SC4 and KF5 that requires such disambiguation or is this merely a package installation conflict resolution? - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114999/#review47390 --- On Jan. 14, 2014, 3:21 p.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114999/ --- (Updated Jan. 14, 2014, 3:21 p.m.) Review request for KDE Runtime, David Faure and Martin Klapetek. Repository: kglobalaccel Description --- Rename the dbus interfaces from org.kde.kglobalaccel.Component to org.kde.kf5kglobalaccel.Component and org.kde.kglobalaccel to org.kde.kf5kglobalaccel this prevents files overlapping with equivalents in kdelibs4 and prevents an overlap of the dbus interface Diffs - src/CMakeLists.txt d48e92e src/kglobalaccel.h d11881c src/kglobalaccel.cpp 54d18ec src/kglobalaccel_p.h b1528dc src/kglobalshortcutinfo.h 7f0e18a src/org.kde.KF5KGlobalAccel.xml PRE-CREATION src/org.kde.KGlobalAccel.xml 8746551 src/org.kde.kf5kglobalaccel.Component.xml PRE-CREATION src/org.kde.kglobalaccel.Component.xml ec21201 Diff: https://git.reviewboard.kde.org/r/114999/diff/ Testing --- Thanks, Jonathan Riddell
Re: Review Request 114999: Add KF5 namespace to dbus interface
On Jan. 14, 2014, 7:22 p.m., Martin Gräßlin wrote: like with the other patch I'm not sure whether that's a good idea as that breaks any communication with the kdelibs4. Thomas Lübking wrote: is there a functional incompitibility between SC4 and KF5 that requires such disambiguation or is this merely a package installation conflict resolution? Martin Gräßlin wrote: I did the port of kglobalacceld and had no problem at all. Also running KWin/5 linked against kglobalaccel talking to kglobalacceld/4 was no problem. So from that I *assume* that there are no functional incompatibilities. If this is only an installation problem for distros that want to ship 4 5 together, i'd suggest to rather have some kde-workspace-transition package that is dependency for KDE SC4 and PW/2 and provides shared data for non-distinguishable target paths (eg. /usr/share/dbus-1/ in this case) - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114999/#review47390 --- On Jan. 14, 2014, 3:21 p.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114999/ --- (Updated Jan. 14, 2014, 3:21 p.m.) Review request for KDE Runtime, David Faure and Martin Klapetek. Repository: kglobalaccel Description --- Rename the dbus interfaces from org.kde.kglobalaccel.Component to org.kde.kf5kglobalaccel.Component and org.kde.kglobalaccel to org.kde.kf5kglobalaccel this prevents files overlapping with equivalents in kdelibs4 and prevents an overlap of the dbus interface Diffs - src/CMakeLists.txt d48e92e src/kglobalaccel.h d11881c src/kglobalaccel.cpp 54d18ec src/kglobalaccel_p.h b1528dc src/kglobalshortcutinfo.h 7f0e18a src/org.kde.KF5KGlobalAccel.xml PRE-CREATION src/org.kde.KGlobalAccel.xml 8746551 src/org.kde.kf5kglobalaccel.Component.xml PRE-CREATION src/org.kde.kglobalaccel.Component.xml ec21201 Diff: https://git.reviewboard.kde.org/r/114999/diff/ Testing --- Thanks, Jonathan Riddell
Re: Review Request 115001: add kf5 namespace to kglobalaccel dbus interface
On Jan. 13, 2014, 6:03 p.m., Martin Gräßlin wrote: Wouldn't that break KDElibs4 applications talking to kglobalacceld from KF5? On Montag, 13. Januar 2014 19:24:12 CEST, Michael Jansen wrote: Yes it would. There can be only one kglobalaccel. If its from kde4 or kde4 shouldn't matter so it HAS to keep dbus compatibility. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115001/#review47339 --- On Jan. 13, 2014, 3:51 p.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115001/ --- (Updated Jan. 13, 2014, 3:51 p.m.) Review request for kde-workspace and Martin Klapetek. Repository: kde-workspace Description --- add kf5 namespace to kglobalaccel dbus interface to prevent files and runtime interfaces overlapping with kdelibs 4 Goes with these reviews for kf5 and kde-runtime https://git.reviewboard.kde.org/r/114999/ https://git.reviewboard.kde.org/r/115000/ Diffs - kcontrol/keys/CMakeLists.txt 072e614 kcontrol/keys/kglobalshortcutseditor.cpp ca11fcd Diff: https://git.reviewboard.kde.org/r/115001/diff/ Testing --- Thanks, Jonathan Riddell
Re: Moving Baloo and Baloo-widgets into KDE SC
On Sonntag, 12. Januar 2014 12:28:09 CEST, Vishesh Handa wrote: How should one go about this? Dot article? An article on dot will help, but it's not important where the information is hosted. What is important is that it has the character of an official press release. a) It has to show up in mainstream media (slashdot friends) *now* - not when things happened. b) It must *not* come along like KDE developer Vishesh Handa wants... but as KDE will... This implies media control, ie. pointing authors of false reports to the one and only official statement instead of assuming sth. out of the meta-information (article/s or blogs about baloo ./. nepomuk etc.) (As KDE won't be paying a PR agency - i guess - that means by us) Once a decision has been settled, it's time to contact kde-pr...@kde.org on this topic. To shape an official note and get it out. http://community.kde.org/Baloo/NepomukPort Dolphin The port is in progress. Check the feature/baloo branch I assume this will say done before any transition happens? Amarok has a separate Nepomuk collection. Porting this is going to be next to impossible as it creates huge sparql queries. There should be at least a link to further information. atm. it reads like: We're gonna remove nepomuk and then amarok is broken and unfixable. Informations on whether things are actually in progress (prevent nobody seems to care? panic) would be nice. Cheers, Thomas
Re: Review Request 114910: Patch for bug 317066 (systray leaves garbage on the panel when resizing )
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114910/#review47049 --- briefly looking at the bug - wouldn't it be better to only cause a full parent repaint when adding/removing an (fdo) icon? - Thomas Lübking On Jan. 8, 2014, 8:59 a.m., Dmitry Ivanov wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114910/ --- (Updated Jan. 8, 2014, 8:59 a.m.) Review request for kde-workspace and Plasma. Bugs: 317066 http://bugs.kde.org/show_bug.cgi?id=317066 Repository: kde-workspace Description --- It is a proposed fix for bug 317066. The fix is a very simple one-liner setting FullViewportUpdate mode for FdoGraphicsWidget. I'm aware FullViewportUpdate has negative performance impact but I also know it efficiently leaves out any graphical glitches happening due to no repaint of widget when necessary (which is what the bug is about). I have tested my solution for a couple of days: the bug no longer reproduced and I also didn't see any noticeable performance problems. I'm still not sure what I propose is acceptable since it may seem like a hack to more experienced developers, however I just didn't want my patch attempt to get lost and forgotten in the bugzilla. Please have a look and decide whether the patch is good enough to be applied to the next bugfixing release of KDE 4.x series, thank you. Diffs - plasma/generic/applets/systemtray/protocols/fdo/fdographicswidget.cpp 1baa23daa5abd5deaab986dc65cec7b9d1031e6c Diff: https://git.reviewboard.kde.org/r/114910/diff/ Testing --- I rebuilt plasma_applet_systemtray.so with the patch and replaced the package version with it (I'm on Linux Mint 16 KDE, x86_64, KDE 4.11.3). So far I can no longer reproduce bug 317066 and I don't see any noticeable performance problems of system tray applet. Thanks, Dmitry Ivanov
Re: Review Request 114841: Screenlocker: don't set the mouse cursor when grabbing the mouse
On Jan. 7, 2014, 8:51 a.m., Martin Gräßlin wrote: how does that behave with the normal locker (that is no screensaver)? None is not blank - the patch is correct. If a cursor is specified, it is displayed regardless of what window the pointer is in. If None is specified, the normal cursor for that window is displayed when the pointer is in grab_window or one of its subwindows; otherwise, the cursor for grab_window is displayed. --- http://tronche.com/gui/x/xlib/input/XGrabPointer.html Since the screenlocker qml window (nor the batterysucking fancy show) is not the grab_window, both will initially get the default cursor of the grab_window (atm. the left_arrow) and not receive mouse events (so w/ or w/o the patch, the qml locker will not display an I-beam when hovering the lineedit - at least not here, one would have to poll the mouse for this and don't you dare* ;-) W/o an explicit grab_cursor, it however should be possible (never tested, but seems the case given the patch) to alter the cursor shape from other clients at any time (because it's not important for the grabbing client) * unless we make use of http://keithp.com/blogs/Cursor_tracking/ for PW/2 - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114841/#review46960 --- On Jan. 5, 2014, 8:55 a.m., Wolfgang Bauer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114841/ --- (Updated Jan. 5, 2014, 8:55 a.m.) Review request for kde-workspace and Martin Gräßlin. Bugs: 311571 and 316459 http://bugs.kde.org/show_bug.cgi?id=311571 http://bugs.kde.org/show_bug.cgi?id=316459 Repository: kde-workspace Description --- Setting the cursor to ArrowCursor when calling XGrabPointer() prevents the Screen savers from blanking the mouse cursor. I don't know why this has been done in the first place, but I couldn't see any negative effect by setting it to None. Now the mouse cursor even changes to the IBeam again when over the password field, which I find more intuitive. Diffs - ksmserver/screenlocker/ksldapp.cpp f0526cf Diff: https://git.reviewboard.kde.org/r/114841/diff/ Testing --- Configure a Screen saver in systemsettings and wait for it to kick in (or lock the screen manually). Previously (since 4.10) the mouse cursor stayed visible, now it is blanked like it was the case before 4.10. Moving the mouse/pressing a key (to quit the Screen saver) makes the mouse cursor appear again as it should, regardless of whether the screen is locked or not. Thanks, Wolfgang Bauer
Re: Review Request 114632: Improve pdf title extraction
On Dec. 26, 2013, 1:57 a.m., Christoph Feck wrote: Hm, you broke the comment :) Luis Silva wrote: What do you mean? It all works fine here. Christoph Feck wrote: Yes, because the compiler does not read comments. Thomas Lübking wrote: Aside this, the approach seems too naive? DOIs have a defined structure, leading doi: 10 (ignoring the case and making colon and whitespace optional) and in general the problematic tokens will have a massive digit overhead - so this could be used as additional test ( 25 looksLikeIndex()) Luis Silva wrote: @Christoph: Just (finally) understood what you meant with breaking the comment. I uploaded a new patch that (hopefully) fixes the issue in the correct way. @Thomas: The approach was meant to be naive. In this simple form, this patch takes care of all index-like cases as well as most other short garbage titles without further parsing. What would be the point of actually knowing if a very short title was actually a doi or an index? echo The Lord of the Rings | wc -m 22 And that's not a short title - not to mention the typical Stephen King (It) or other languages that use hanzi, kanji or hanja and will never met your arbitrary 25 glyph requirement. Though many academic papers (in western cultures at least) in fact have clumsy long titles, that doesn't hold for other document types. OTOH, if the title (=index) is some (md5, sha*) hash of the text, that will easily outnumber 25 glyphs. So the more honest solution seems to just omit the title field altogether. The alternative (don't know how expensive the document scan is) would be to check whether the title field seems like reasonable text, what could invoke the digit ratio, the longest non-digit sequence (0x12a21f56ea5) and maybe whether there's any digitless word at all. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114632/#review46156 --- On Jan. 6, 2014, 5:47 p.m., Luis Silva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114632/ --- (Updated Jan. 6, 2014, 5:47 p.m.) Review request for Baloo and Vishesh Handa. Repository: kfilemetadata Description --- A good portion of scientific papers in my collection had a doi or an index number in the title. These are in general short string chains, shorter than the real title. I improve extraction of titles from pdf's by setting a minimum size below which parsing of the first page is forced. The cut-off size is arbitrarily set to 25 characters (three big words). Diffs - src/extractors/popplerextractor.cpp b056581f51d10b632799586eed3cc15ac539fe80 Diff: https://git.reviewboard.kde.org/r/114632/diff/ Testing --- This improved the title extraction on my pdf collection of scientific papers by quite a lot. Thanks, Luis Silva Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Moving Baloo and Baloo-widgets into KDE SC
On Mittwoch, 25. Dezember 2013 21:06:56 CEST, David Edmundson wrote: With the planned slow transition of apps from kdelibs4 to frameworks we are going to have a point where we have apps on either side. I expect Dolphin to port very soon, KMail isn't planned for a long time as KDE PIM libs are to be split. So you're saying KMail will have broken/no semantic desktop support for about a year or so Are you somehow *trying* to get bad press? :-P Waiting for Plasma 2 will still result in exactly the same situation that you want to avoid. Yes, but no. Unported (kdelibs4) apps will be foreigners in a frameworks environment - it's expectable for them to be not fully functional. Though, if you prospect eg. KDE PIM to remain operating on (non operative..) nepomuk for a long time even after P-W/2 release, some wrapper seems inevitable anyway. Users can continue to use KDE4 until at least their showstopper kdelibs4/nepomuk client has been ported. If you however break things in KDE4 branch, users will have to stop updating (and will also not use baloo because of that...) KDE4, which would effectively be dropped into unmaintained mode (at least if you care about semantic desktop support in an unported client) So unless nepomuk is considered broken so badly that nobody uses it anyway, you can expect a whole bunch of regression complaints. IMHO the safest course of action is to port everything to baloo before they start being frozen for moving KF5. Then we can have kdelibs4 and KF5 apps both using baloo without any runtime problems. If everything is ported then everything can use baloo w/o runtime problems ... But the problem is the transition time and whether it's visible to users, not the time when everything is ported. What about adding hybrid runtime support, ie. check whether baloo is running, if not, check whether nepomuk is running and use the resp. API/functionality (or none if neither is), ie. keep backward compatibility in ported clients and allow users to keep a virtuoso tainted but working setup on nepomuk or decide to drop that and rely on baloo (because they don't care about kmail/nepomuk because they use trojitá) Cheers, Thomas
Re: Moving Baloo and Baloo-widgets into KDE SC
On Dienstag, 24. Dezember 2013 19:29:11 CEST, Vishesh Handa wrote: On Tuesday 24 Dec 2013 13:06:55 Christoph Feck wrote: How does Baloo cooperate with Nepomuk? Note that we have ABI guarantees, so if the metadata is not shared between running instances of two services, but applications would have to be ported to the new ABI, then you cannot introduce Baloo in KDE 4.x, but only for KF5. I'm confused on how not sharing metadata = ABI break? Could you please elaborate? If baloo can neither coexist with and talk to nepomuk, nor is 100% ABI compatible on clientlib (wrapper?) side, it cannot just replace nepomuk. Cheers, Thomas
Re: Moving Baloo and Baloo-widgets into KDE SC
On Dienstag, 24. Dezember 2013 22:03:28 CEST, Àlex Fiestas wrote: On Tuesday 24 December 2013 21:25:37 Ivan Čukić wrote: I would like baloo to be available in 4.x, with no API stability guarantees, ... As I see it, the nepomuk maintainer says it works better than Nepomuk for all cases covered by SC. I don't see any reason not to move forward then. Since actual ABI is not affected (in terms of things start to crash), you /can/ do whatever you want, but it still has consequences. The point is, that you virtually cannot make a release that breaks half the former nepomuk clients. You'd get thousands of bug reports about feature x in application y broken/not available all over the place. So either nepomuk and baloo can run (and sync) side by side or there eventually needs to be some sort of API wrapper and a very LOUD heads-up! to distros to relink everything that's not been ported, so to have baloo *completely* replace nepomuk - or baloo can still be added to allow devs migrate to it, but in general we stick with nepomuk until P-W/2. This is not about the quality or sheer sanity advance of Baloo, but the bare necessities (yes ;-) of release management. Albert will unleash Shir Khan if we f*** the (for workspace: minor) release - or just revert breaking commits =) Cheers, Thomas (To leave no question: the sooner virtuoso leaves my desktop system, the better)
Re: background plasma crash
the linked issue is dead old - it's more likely that you're using an abi incompatible decoration plugin (qtcurve? any 3rd party one, though) since debian/ubuntu has (had?) falsepositive abi management. however and once more: you got a crash - you show the backtrace, since otherwise this is all just uninformed guessing around. Am Sonntag, 22. Dezember 2013 schrieb Dr.-Ing. Edgar Alwers edgaralw...@gmx.de: On Friday 20 December 2013 15:54:04 you wrote: Please try at least the latest version before asking for a patch. -- Hi Martin, I follow your hint and I upgraded KDE to 4.11.2, according to the BLFS book. This means, I rebuilt every KDE program as well as the dependencies which were not accepted from my earlier 4.10.2. The result is, that I am now able to change my background plasma. However, I got the worst problem of Kwin unstable : I quote from http://www.linuxforums.org/forum/ubuntu-linux/152472-kwin-unstable.html; quote If I boot it up with the default window manager I get a message saying that kwin is unstable and it gives me the option to change window manager. If I don’t change it I lose the ability to resize, move and tab between windows. The windows also lose their title bar, which means I have to either have to use File-Quit or right click on the task bar to close the window. unquote Well, exactly this is also my new problem. I think, somewhere in the building chain, there are incompatibilities which lead to this problems. As a consequence, I shall downgrade my partition to the well known KDE-4.8.2 and wait until KDE-5 shows up, to start then from the scratch. As I said, the problem is not critical. Anyway, thank you very much for your comments. And: I am learning a lot ! :-) Edgar Dr.-Ing. Edgar Alwers edgaralw...@gmx.de GPG Key ID:AD5C6F70 Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: background plasma crash
and don't forget to attach a backtrace to the bug in case you want to know whether it's related or have it fixed ;-) 2013/12/20, Martin Graesslin mgraess...@kde.org: Hi Edgar, thanks for your mail. Please be aware that we use bugzilla for managing bugs. It doesn't scale if everybody sends his questions to the mailing list. In your case I must point out that there are minor release updates to 4.10 and also a major release update to 4.11. Please try at least the latest version before asking for a patch. Best Regards Martin Gräßlin On Friday 20 December 2013 15:38:56 Dr.-Ing. Edgar Alwers wrote: Hi, I am using KDE-4.10.2 with linux from scratch 8.4, self compiled. When I try to change a picture background plasma ( default desktop settings ) I get a crash and an automatic restart with the previous background setting. This happens on three units ( PC's, Laptop ). However, it does not happen on my old partitions running KDE-4.8.2. I am aware about Bug reports like Bug 277036, but in this case weather widgets were concerned ( gps ? ). I am only trying to change photos in jpg format. According to the report, a solution cannot be expected before KDE-5: Any Plasma developer is aware of this problem. However we cannot change it until KDE 5.0 Two questions: 1.) is my problem included in the mentioned bug or is it a new problem ? 2.) Could I have a patch for the time until KDE-5 ? Thank you very much for any advice. I know, the problem is not critical. Edgar Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Review Request 114484: Fix KMainWindow size management, esp. on asymmetric multiscreens
the maximized is screenSize + 1 kludge is gone in KMainWindow, we could remove it from KWin in addition. Thank you for reading until this point ;-) Diffs - kdeui/widgets/kmainwindow.cpp 85beacc Diff: http://git.reviewboard.kde.org/r/114484/diff/ Testing --- KWin + Metacity; glib + unix event dispatcher. Thanks, Thomas Lübking
Re: Send a custom key sequence to konsole
On Montag, 16. Dezember 2013 09:08:22 CEST, Jörg Ehrichs wrote: Basically I want to clear t Which internal function should I call? Is it as simple as passing a QString Seems you are looking for QProcess here. To do what? @Aaron: do you want to operate on a konsole part in your own process or on the window of a foreign process and what is the context and target goal in either case? to remote-control a window on X11 you can simply use xdotool. In a similar way khotkeys *should* allow event sending. From an xlib/xcb application you can simply send events to any window (what xdotool does) But since what konsole runs will usually be some bash derivate - why do you remote-control the window in the first place rather than dealing with that in bash in the first place (and why would you need a terminal shell instead a script shell)? Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Review Request 114484: Fix KMainWindow size management, esp. on asymmetric multiscreens
this point ;-) Diffs - kdeui/widgets/kmainwindow.cpp 85beacc Diff: http://git.reviewboard.kde.org/r/114484/diff/ Testing --- KWin + Metacity; glib + unix event dispatcher. Thanks, Thomas Lübking
Re: Review Request 114484: Fix KMainWindow size management, esp. on asymmetric multiscreens
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114484/#review45741 --- kdeui/widgets/kmainwindow.cpp http://git.reviewboard.kde.org/r/114484/#comment32677 i can not recall this would have ever been NULL for me, but i cannot say anything about Windows or MacOS either kdeui/widgets/kmainwindow.cpp http://git.reviewboard.kde.org/r/114484/#comment32678 This may have been the case, but is not. It would also have had any impact on the unspecified special handling in KWin - Thomas Lübking On Dec. 15, 2013, 11:28 p.m., Thomas Lübking wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114484/ --- (Updated Dec. 15, 2013, 11:28 p.m.) Review request for kdelibs, Christoph Feck and Martin Gräßlin. Bugs: 286146, 317760 and 324957 http://bugs.kde.org/show_bug.cgi?id=286146 http://bugs.kde.org/show_bug.cgi?id=317760 http://bugs.kde.org/show_bug.cgi?id=324957 Repository: kdelibs Description --- Due to the many patches arriving to kdelibs, i just thought to give it a try ;-) Notice that i did not align the non unix/x11 preproc branches, but will in case it's accepted. tl; dr == situation now: -- - on multiscreen setups with different sizes * KMainWindow may open with the wrong size (286146) * KMainWindow may open on the wrong (not active) screen - maximized KMainWindow re-opens maximized, but lost its unmaximized state - windows that randomly cover the maximum width of height will falsely open maximized in that direction (317760) situation after: - on multiscreen setups with different sizes * KMainWindow will open with the last size * KMainWindow will (usually, see details) open on the active screen - maximized KMainWindow re-opens maximized, unmaximizing will restore the previous maximized size - we should be able to remove the kludge that causes bug #317760 from KWin (KMainWindow is explicitly referenced there and the behavior is unspecified and undocumented) -- En Detail = I started out by seeking a fix for bug #286146 The issue here is that KMainWindow handles the size in relation to the current screen resolution. The current screen resolution is the one of the screen where the window is. This happens *before* the WM places the window (eventually selecting another screen) If the screen changes or if you just closed it on the other screen before, you'll not get the size you'd expect (because it had a different size when you closed it and/or even does not match the size stored for the screen it opened on) In addition to that, the size may be too big for the active screen (in which case kwin will place it on the fitting screen rather than dropping borders) There're 5 possible solutions to this: 1. KWin does not alter the screen (ie. move the window to the active screen) for the window 2. KMainWindow knows the target screen 3. KMainWindow anticipates the target screen 4. KMainWindow restores its size *after* being mapped and placed by the WM 5. KMainWindow treats the combined screens of the multiscreen as one for the size management ad 1) No. :) Plus, there'd be no guarantee for the behavior on other WMs ad 2) Unfortunately NETWM is completely multiscreen unaware, so there's no protocol in place, so it could be a KMainWindow KWin related solution only ad 3) KMainWindow would have to read kwinrc settings, plus same issue again: KMainWindow KWin related solution only ad 4) Possible, but will cause visible flicker (user sees the window mapped with original size and then resized) - we might hide that in the compositor, but that would delay all window showing and be a KWin only solution again. ad 5) proposed solution =) This is acceptable if users rather care about the size in relation to the window than to the screen (window shall open at size that I left behind, no matter on which screen) and we can assume WMs to keep windows in workarea bounds (like KWin does and a diminished issue to to the changed handling of maximized windows, see next) Unfortunately that fix trapped me into bug #317760 on steroids. So far the maximization state was stored by storing screenSize + 1, what, for the change and a multiscreen setup like [1024x768+0+0; 1920x1200+1024+0] means that the (formerly maximized on the XGA screen) window was restored to 2944+1200, what KWin would thankfully punch into 1920x1200 and place it on the WUXGA screen, so this approach had to go. Using screenSize(n) + 1 was equally not an option since
Re: Review Request 114436: Set WindowModality of all KIO message box to Qt::WindowModal
On Dec. 13, 2013, 2:27 p.m., Frank Reininghaus wrote: Thanks for looking into this, Dawit! I greatly appreciate this effort. Two questions come to my mind: 1. Why should these dialogs be modal at all? Everything that KIO does is asynchronous, so it could very well be that the window isn't even showing the directory (where the action took place that triggered the dialog) any more. 2. Since every little change can have unexpected side effects, and the modality issue is not causing a lot of trouble for users right now (please correct me if I'm wrong), maybe this change should better be done in master? Currently, the only situation in which a single process can have multiple windows that can perform file management actions is that there are two Konqueror windows, one of which was opened from the other one with Open New Window, I think (but I might be overlooking some other possibilities). Some background for people who have not followed the modality discussion in the past: some time ago, Thomas raised the question why Dolphin is not a KUniqueApplication any more. This was done mostly because Strigi made Dolphin crash a lot, and it was quite annoying for users to see all their Dolphin windows disappear if one of them crashed (this is not a big problem any more), but also because it was a bit irritating that KIO dialogs would freeze all Dolphin windows. Some more information can be found in these threads: http://lists.kde.org/?t=13752968312r=1w=2 http://lists.kde.org/?t=13753723594r=1w=2 1. Why should these dialogs be modal at all? Unless anybody has a better explanation I assume it was done because of either a) the wrong assumption that modal equals transient b) the assumption of (a) actually may hold on some systems? A modal window is used if sequential action is mandatory, eg. if you open a file you can not edit it before you opened it - the modal dialog makes sense to enforce the workflow and assert() it in the code. This is obviously not the case here: the system MUST be prepared to filesystem changes during the nested eventloop of the modal dilaog, eg. while the dialog asks do you really want to delete foo/bar.txt this could just happen in another dolphin window, in konsole, VT1 or through a script or cron job. On top of this, I do not even think the dialog should be transient. Eg. I often start a longer (network, crap USB stick) copy job and close dolphin immediately. Popping up questions (override) arrive for the copy job and not the causing process (long closed dolphin) The user must get aware that this action is currently halted and requires interaction to continue, but that isn't related to a particular other window. Some system interaction spot would be nice but it had to significantly differ from the common i don't care notification that pops up because phonon thinks it lost a resource or so. Alternatively the process indicator in the notification area could just start blinking or show a interaction required! message/icon/whatsoever. This is however probably beyond KDE4. The fallback (non-plasma context) solution could simply be a keep above on all desktops dialog (it doesn't have to get the focus, but must show up visible) what might be a usable approach even for KDE4 - Thomas --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114436/#review45646 --- On Dec. 13, 2013, 1:53 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114436/ --- (Updated Dec. 13, 2013, 1:53 p.m.) Review request for kdelibs, David Faure and Frank Reininghaus. Repository: kdelibs Description --- The attached patch changes the WindowModality of all the message/information boxes displayed by KIO::JobUiDelegate to Qt::WindowModal instead of Qt::ApplicationModal. This prevents a message box in one window from blocking all other windows. Diffs - kio/kio/jobuidelegate.cpp 8534863 Diff: http://git.reviewboard.kde.org/r/114436/diff/ Testing --- Thanks, Dawit Alemayehu
Re: Debug messages
Am Donnerstag, 12. Dezember 2013 schrieb Kevin Krammer kram...@kde.org: That will get all Akonadi output, including that of resources, in that shell. You can then use kdebugdialog to turn on/off whatever you want. or you run kdebugdialog --fullmode and log messages to a dedicated file which you then also can just tail -f in case. Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
