Re: FindKActivities.cmake missing from kdelibs KDE/4.7 ?
On Tuesday, October 18, 2011 21:58:45 Alexander Neundorf wrote: On Tuesday 18 October 2011, todd rme wrote: On Mon, Oct 17, 2011 at 7:58 PM, Andreas Pakulat ap...@gmx.de wrote: On 17.10.11 19:45:07, Friedrich W. H. Kossebau wrote: Lundi, le 17 octobre 2011, à 19:35, Alex Merry a écrit: On 17/10/11 18:10, Friedrich W. H. Kossebau wrote: kde-workspace trunk is supposed to be compiled against kdelibs KDE/4.7, right? For me it seems that FindKActivities.cmake is missing then in kdelibs KDE/4.7 or kde-workspace trunk. Because kde-workspace/CMakeLists.txt has the line find_package(KActivities REQUIRED) But there is nowhere a FindKActivities.cmake for me: FindKActivities is provided by libkactivities (the kactivities module on git.kde.org). If you don't have it, there won't be such a file. Hm, but kdelibs KDE/4.7 has (and builds+installs for me by default) experimental/libkactivities, isn't that the official version of libkactivities to use? Apparently not, but last I checked everybody disagreed about the 'correct' solution since some do not want such changes in 4.7 but others don't want to wait for 5.x. Basically the whole development process is in limbo - unfortunately. Alright, so there are three versions it seems: 1. The version that comes with kdelibs 4.7.x 2. The git active/1.0 version 3. The master version Which version should distributions be shipping? I notice that plasma active has patched their spec file to exclude the version in kdelibs and use their own, but is that the solution distributions should be using as well? So, kactivities developers, which one to use ? master or Active/1.0 (they should be the same). Should I update the copy in kdelibs with this, so we can avoid confusion in the future? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Qt 4.8 QUrl.toLocalFile behavior change, impacts to KUrl (and friends)
See also, http://bugs.kde.org/285028 ( and https://bugreports.qt.nokia.com/browse/QTBUG-22382 ) In Qt 4.8, QUrl.toLocalFile now seems, by design, to return NULL for urls lacking any scheme. Discovered this the hard way figuring out why all my audio knotifications were quiet. Since audio event sources are simple filenames, e.g. KDE-K3B-Finish-Success.ogg, and QString soundFile = soundFileURL.toLocalFile(); no longer works. Any suggestions or advice on how best to deal with this? -- rex
Re: Qt 4.8 QUrl.toLocalFile behavior change, impacts to KUrl (and friends)
On Thursday, 27 de October de 2011 13:32:51 Rex Dieter wrote: See also, http://bugs.kde.org/285028 ( and https://bugreports.qt.nokia.com/browse/QTBUG-22382 ) In Qt 4.8, QUrl.toLocalFile now seems, by design, to return NULL for urls lacking any scheme. Discovered this the hard way figuring out why all my audio knotifications were quiet. Since audio event sources are simple filenames, e.g. KDE-K3B-Finish-Success.ogg, and QString soundFile = soundFileURL.toLocalFile(); no longer works. Any suggestions or advice on how best to deal with this? As we discussed on IRC, any string source must be properly labelled whether they are a URL or they are a local file. They cannot be both. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Qt 4.8 QUrl.toLocalFile behavior change, impacts to KUrl (and friends)
Thiago Macieira wrote: On Thursday, 27 de October de 2011 13:32:51 Rex Dieter wrote: See also, http://bugs.kde.org/285028 ( and https://bugreports.qt.nokia.com/browse/QTBUG-22382 ) In Qt 4.8, QUrl.toLocalFile now seems, by design, to return NULL for urls lacking any scheme. Discovered this the hard way figuring out why all my audio knotifications were quiet. Since audio event sources are simple filenames, e.g. KDE-K3B-Finish-Success.ogg, and QString soundFile = soundFileURL.toLocalFile(); no longer works. Any suggestions or advice on how best to deal with this? As we discussed on IRC, any string source must be properly labelled whether they are a URL or they are a local file. They cannot be both. I understand that (and I agree, fwiw). However, KDE has seemingly many cases where this is not followed wrt string source, knotify audio event sources (in notification defaults or even users' existing config files) and kynotifyconfigactionswidget.cpp's use of KUrlRequester class are examples. -- rex
Re: Re: Qt 4.8 QUrl.toLocalFile behavior change, impacts to KUrl (and friends)
A Dijous, 27 d'octubre de 2011, Thiago Macieira vàreu escriure: On Thursday, 27 de October de 2011 13:32:51 Rex Dieter wrote: See also, http://bugs.kde.org/285028 ( and https://bugreports.qt.nokia.com/browse/QTBUG-22382 ) In Qt 4.8, QUrl.toLocalFile now seems, by design, to return NULL for urls lacking any scheme. Discovered this the hard way figuring out why all my audio knotifications were quiet. Since audio event sources are simple filenames, e.g. KDE-K3B-Finish-Success.ogg, and QString soundFile = soundFileURL.toLocalFile(); no longer works. Any suggestions or advice on how best to deal with this? As we discussed on IRC, any string source must be properly labelled whether they are a URL or they are a local file. They cannot be both. Personally i find it another joke in the history of Qt, saying you maintain API and ABI (that you do) but then making functions behave totally different from one version to another is just plain useless. Albert -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Qt 4.8 QUrl.toLocalFile behavior change, impacts to KUrl (and friends)
On Thursday, 27 de October de 2011 22:31:15 Albert Astals Cid wrote: Personally i find it another joke in the history of Qt, saying you maintain API and ABI (that you do) but then making functions behave totally different from one version to another is just plain useless. Right. So we should just not release updates, because fixing bugs changes behaviour. Good thinking. Call me when you get to make such decisions. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Re: Qt 4.8 QUrl.toLocalFile behavior change, impacts to KUrl (and friends)
A Dijous, 27 d'octubre de 2011, Thiago Macieira vàreu escriure: On Thursday, 27 de October de 2011 22:31:15 Albert Astals Cid wrote: Personally i find it another joke in the history of Qt, saying you maintain API and ABI (that you do) but then making functions behave totally different from one version to another is just plain useless. Right. So we should just not release updates, because fixing bugs changes behaviour. This is not what i meant, and you know it. But as it is obvious you do not want to have a constructive discussion, let's end it here. Albert Good thinking. Call me when you get to make such decisions. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Qt 4.8 QUrl.toLocalFile behavior change, impacts to KUrl (and friends)
On Thursday 27 October 2011 21:11:11 Thiago Macieira wrote: On Thursday, 27 de October de 2011 13:32:51 Rex Dieter wrote: See also, http://bugs.kde.org/285028 ( and https://bugreports.qt.nokia.com/browse/QTBUG-22382 ) In Qt 4.8, QUrl.toLocalFile now seems, by design, to return NULL for urls lacking any scheme. Discovered this the hard way figuring out why all my audio knotifications were quiet. Since audio event sources are simple filenames, e.g. KDE-K3B-Finish-Success.ogg, and QString soundFile = soundFileURL.toLocalFile(); no longer works. Any suggestions or advice on how best to deal with this? As we discussed on IRC, any string source must be properly labelled whether they are a URL or they are a local file. They cannot be both. is there at least a qWarning emitted in such a case, so we can find these problems with QT_FATAL_WARNINGS=1 ? bye, Milian - who fears lots of issues in the huge KDevelop codebase... -- Milian Wolff m...@milianw.de http://milianw.de
Re: Qt 4.8 QUrl.toLocalFile behavior change, impacts to KUrl (and friends)
On Thursday, 27 de October de 2011 23:17:49 Milian Wolff wrote: On Thursday 27 October 2011 21:11:11 Thiago Macieira wrote: On Thursday, 27 de October de 2011 13:32:51 Rex Dieter wrote: See also, http://bugs.kde.org/285028 ( and https://bugreports.qt.nokia.com/browse/QTBUG-22382 ) In Qt 4.8, QUrl.toLocalFile now seems, by design, to return NULL for urls lacking any scheme. Discovered this the hard way figuring out why all my audio knotifications were quiet. Since audio event sources are simple filenames, e.g. KDE-K3B-Finish-Success.ogg, and QString soundFile = soundFileURL.toLocalFile(); no longer works. Any suggestions or advice on how best to deal with this? As we discussed on IRC, any string source must be properly labelled whether they are a URL or they are a local file. They cannot be both. is there at least a qWarning emitted in such a case, so we can find these problems with QT_FATAL_WARNINGS=1 ? No, but there's something better: #define QURL_NO_CAST_FROM_QSTRING Your code will not compile when you're auto-casting. You'll need to select what to do: QUrl::fromEncoded() - if it's a URL, with the file scheme QUrl::fromLocalFile() - if it's a file name This option remains in Qt 5, but there there's going to be a new method to convert from QString to QUrl without passing through QByteArray. This is extremely important to get right because a filename and a URL are NOT the same. Certain characters in the string are interpreted differently depending on what the string is: %, # and ? in particular. So, to be honest, the bug *already* *existed* in your code if you're finding these problems now. I just made it blatantly clear, and it's been there for a year for people to see. I'm also calling right now KUrl's fromPathOrUrl a fatally flawed design. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Review Request: Add Activity Awareness to KFilePlaces* Widget (OnlyInActivity)
On Oct. 25, 2011, 10:05 a.m., Kai Uwe Broulik wrote: Is there any progress on this? I’d propose you enhance the feature to make the individual activities selectable, i.e. you can choose in which particular activities an entry should appear, similar to KWin’s Activity menu in the window title where you can assign a window to multiple activities. Aaron J. Seigo wrote: unfortunately, this can't only be done in the frameworks branch, and even then not quite yet. kactivities has already been broken out, and while it should be a valid dependency for the kfile library, kdelibs is not yet broken up so it would create a circular build dependency at the moment (as kactivities relies on libkdecore). when it does go in, however, i agree with Jeff that adding a specific activity chooser would be ungainly. it also would not fit in with the rest of this dialog which has entries like only in this application (rather than in the following applications...) Thank you for the info, Aaron. School (and life) have prevented me from doing much of anything for the last several months, so if somebody else wants to pick this up, please feel free. I don't know when I'll have time again. - Jeffery --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101348/#review7592 --- On June 1, 2011, 6:07 a.m., Jeffery MacEachern wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101348/ --- (Updated June 1, 2011, 6:07 a.m.) Review request for kdelibs, Ivan Čukić, Kevin Ottens, and David Faure. Description --- Adds an Only show in this Activity option to the KFilePlaces Widget and support in the underlying model code. Currently only one activity/all activities are supported as choices; I think this should be sufficient, and anything more complicated would be hard to make usable. Diffs - kfile/CMakeLists.txt ceae140 kfile/kfileplaceeditdialog.h d5b030a kfile/kfileplaceeditdialog.cpp d798b4d kfile/kfileplacesmodel.h b3dd821 kfile/kfileplacesmodel.cpp b037084 kfile/kfileplacesview.cpp 6a343b3 Diff: http://git.reviewboard.kde.org/r/101348/diff/diff Testing --- Tested on Project Neon/Kubuntu Natty. Created several activities, added Place bookmarks, set them to only show in the current activity, and switched activities. Everything worked as intended. EDIT: one small known issue - the OnlyInActivity setting doesn't take when the bookmark is first created; you have to hit Edit and re-check the box. Thanks, Jeffery MacEachern
Re: Review Request: Support passing an argument to the Locale KCM tab to specify which tab to activate at load.
On Oct. 23, 2011, 5:49 p.m., John Layt wrote: Hi Dave, as maintainer of the Locale KCM I'm happy for this to go in, but we do need to make the command line option consistent for all the KCM's. I suggest checking with Ben Cooksley who is overall maintainer of System Settings as to what he prefers. Personally, I don't like --tab= as the option as the visual implementation may change from a tabbed widget, perhaps section or category or something similar would be better. Thanks for doing this! John. David Edmundson wrote: Feedback from Ben: I don't have an opinion as such, but whatever is implemented absolutely needs to be consistent across all modules which implement this functionality. Given that one module already uses --tab, it is probably best to use that. I'll make that change unless you have any further comments? I'm happy to change kcm_keyboard to support two different arguments if you wanted to move forward with --section (or equivalent) Parker Coates wrote: Maybe --page would work? Even if the tabwidget is replaced the different sections must be on different pages (otherwise, we wouldn't need this option). They don't have to be on different pages, you could have a long scrolling widget that you want to jump to a section/category/group on, e.g. on mobile or tablet platforms. I'm sure Dave will find a suitable name :-) - John --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102947/#review7560 --- On Oct. 23, 2011, 10:36 a.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102947/ --- (Updated Oct. 23, 2011, 10:36 a.m.) Review request for KDE Runtime. Description --- Part 1/2 of fixing https://bugs.kde.org/show_bug.cgi?id=284755 Allows programs opening the locale KCM tab to specify which tab the KCM should open on. If no arguments are passed then behaviour is as normal. Diffs - kcontrol/locale/kcmlocale.cpp 7eb6353 Diff: http://git.reviewboard.kde.org/r/102947/diff/diff Testing --- Thanks, David Edmundson
detection if applet is running
I need to detect if keyboard layout indicator applet is running and show
the keyboard layout button in the screen lock dialog (bug 276692
https://bugs.kde.org/show_bug.cgi?id=276692). Currently it only checks
if indicator option is on which turns on systray icon but user can
bypass that option by just dragging applet on the screen.
I did a quick research and I see two ways to solve this in
keyboard_layout_widget (embedded component used in lockdlg):
1) link plasma libs and do something like (in pseudo-code)
foreach(containment, new Corona()-containments()) {
foreach(applet, containment-applets()) {
if( applet-pluginName() == ... ) {
// show indicator
}
}
}
2) make keyboard layout applet exposes some dbus to make it detectable
when running (feels a bit too heavy)
It felt like there must be a way currently to use dbus on plasma to
query running applets (which would the easiest way to implement what I
need) but could not find anything like that in org.kde.plasma-desktop
I would appreciate any help on this
Thanks
Andriy
