Re: Splitting KGlobalAccel interface and runtime
Nevermind. rebuilt and everything seems to be working for now. On Mon, Mar 6, 2023 at 10:02 AM Jeremy Whiting wrote: > Was something decided about this? I ask because I went and built > frameworks kf6 over the weekend with kdesrc-build into /usr/local/ with my > existing arch packages in /usr, etc. and afterwards the kf5 version of > yakuake can no longer receive keyboard shortcuts (to hide/show, etc.) It's > entirely possible I messed something up in the process, but thought I'd ask > here in case kglobalaccel is still up in the air in regards to how it will > work with kf5 and kf6 applications (or maybe I need to run both > kglobalaccel5 and kglobalaccell6 or something during transition times?) > > thanks, > Jeremy > > On Tue, Feb 14, 2023 at 8:25 AM Aleix Pol wrote: > >> On Tue, Feb 14, 2023 at 10:13 AM Kevin Ottens wrote: >> > >> > Hello, >> > >> > On Monday, 13 February 2023 21:25:54 CET Vlad Zahorodnii wrote: >> > > On 2/13/23 22:05, Nicolas Fella wrote: >> > > > Hi, >> > > > >> > > > the kglobalaccel framework currently contains two pieces: >> kglobalacceld, >> > > > the runtime component that manages global shortcuts, and an >> > > > application-side library to interact with it. >> > > > >> > > > The two communicate with each other via DBus. On X11 there is a >> > > > standalone kglobalacceld5 process providing the interface, on >> Wayland >> > > > the runtime is linked into KWin and thus the kwin_wayland process >> > > > provides the interface. >> > > > >> > > > The current architecture has a number of downsides: >> > > > >> > > > - Any call to the KGlobalAccel library may DBus-activate the >> > > > kglobalacceld5 process, which may be undesired on Desktop other than >> > > > Plasma since it competes with their native shortcut system. We tried >> > > > fixing that by making such calls no-op on !Plasma, but that broke >> things >> > > > for people that did want it to run, for example people using KWin >> with >> > > > LXQt, because KWin relies on KGlobalAccel for shortcuts >> > > > >> > > > - We want to keep the dependencies of the interface library minimal, >> > > > which is inconvenient for the development of the runtime part. For >> > > > example we really want to use KIO::ApplicationLauncherJob in the >> > > > runtime, but currently can't, because that would introduce a >> dependency >> > > > cycle in Frameworks (KIO depends on KXmlGui, which depends on >> > > > KGlobalAccel, which would depend on KIO) >> > > > >> > > > - Coinstallability of KF5 and KF6. Conceptually there can only be >> one >> > > > kglobalacceld. If both KF5 KGlobalAccel and KF6 KGlobalAccel >> install a >> > > > kglobalacceld this is going to be problematic. This also means that >> a >> > > > KF6-based kglobalacceld must work with a KF5 interface library >> > > > >> > > > - Other shortcut daemon implementations. Since somewhat recently >> there >> > > > is an XDG Portal for global shortcuts. Platforms like Windows and >> macOS >> > > > also have ways for applications to register global shortcuts. While >> we >> > > > are currently not using any of these it's very well possible that we >> > > > would eventually want to use the KGlobalAccel interface library to >> > > > interact with those. Having the kglobalacceld runtime in the same >> > > > frameworks therefore doesn't feel right. >> > > > >> > > > To address these issues I suggest we split out the runtime part of >> > > > kglobalaccel into its own project, under the Plasma release group, >> > > > because that's primarily where it's used/supported. The interface >> > > > library would remain in frameworks. We have a similar situation with >> > > > activities, where the manager (kactivitymanagerd) is in Plasma and >> the >> > > > interface is in Frameworks. When doing this we'd also change the >> way how >> > > > kglobalacceld is started away from DBus activation towards >> explicitly >> > > > starting it as part of the Plasma startup. This avoids accidentally >> > > > launching it when it shouldn't be but still allows to exp
Re: Splitting KGlobalAccel interface and runtime
Was something decided about this? I ask because I went and built frameworks kf6 over the weekend with kdesrc-build into /usr/local/ with my existing arch packages in /usr, etc. and afterwards the kf5 version of yakuake can no longer receive keyboard shortcuts (to hide/show, etc.) It's entirely possible I messed something up in the process, but thought I'd ask here in case kglobalaccel is still up in the air in regards to how it will work with kf5 and kf6 applications (or maybe I need to run both kglobalaccel5 and kglobalaccell6 or something during transition times?) thanks, Jeremy On Tue, Feb 14, 2023 at 8:25 AM Aleix Pol wrote: > On Tue, Feb 14, 2023 at 10:13 AM Kevin Ottens wrote: > > > > Hello, > > > > On Monday, 13 February 2023 21:25:54 CET Vlad Zahorodnii wrote: > > > On 2/13/23 22:05, Nicolas Fella wrote: > > > > Hi, > > > > > > > > the kglobalaccel framework currently contains two pieces: > kglobalacceld, > > > > the runtime component that manages global shortcuts, and an > > > > application-side library to interact with it. > > > > > > > > The two communicate with each other via DBus. On X11 there is a > > > > standalone kglobalacceld5 process providing the interface, on Wayland > > > > the runtime is linked into KWin and thus the kwin_wayland process > > > > provides the interface. > > > > > > > > The current architecture has a number of downsides: > > > > > > > > - Any call to the KGlobalAccel library may DBus-activate the > > > > kglobalacceld5 process, which may be undesired on Desktop other than > > > > Plasma since it competes with their native shortcut system. We tried > > > > fixing that by making such calls no-op on !Plasma, but that broke > things > > > > for people that did want it to run, for example people using KWin > with > > > > LXQt, because KWin relies on KGlobalAccel for shortcuts > > > > > > > > - We want to keep the dependencies of the interface library minimal, > > > > which is inconvenient for the development of the runtime part. For > > > > example we really want to use KIO::ApplicationLauncherJob in the > > > > runtime, but currently can't, because that would introduce a > dependency > > > > cycle in Frameworks (KIO depends on KXmlGui, which depends on > > > > KGlobalAccel, which would depend on KIO) > > > > > > > > - Coinstallability of KF5 and KF6. Conceptually there can only be one > > > > kglobalacceld. If both KF5 KGlobalAccel and KF6 KGlobalAccel install > a > > > > kglobalacceld this is going to be problematic. This also means that a > > > > KF6-based kglobalacceld must work with a KF5 interface library > > > > > > > > - Other shortcut daemon implementations. Since somewhat recently > there > > > > is an XDG Portal for global shortcuts. Platforms like Windows and > macOS > > > > also have ways for applications to register global shortcuts. While > we > > > > are currently not using any of these it's very well possible that we > > > > would eventually want to use the KGlobalAccel interface library to > > > > interact with those. Having the kglobalacceld runtime in the same > > > > frameworks therefore doesn't feel right. > > > > > > > > To address these issues I suggest we split out the runtime part of > > > > kglobalaccel into its own project, under the Plasma release group, > > > > because that's primarily where it's used/supported. The interface > > > > library would remain in frameworks. We have a similar situation with > > > > activities, where the manager (kactivitymanagerd) is in Plasma and > the > > > > interface is in Frameworks. When doing this we'd also change the way > how > > > > kglobalacceld is started away from DBus activation towards explicitly > > > > starting it as part of the Plasma startup. This avoids accidentally > > > > launching it when it shouldn't be but still allows to explicitly > start > > > > outside of Plasma if really wanted. It would also allow for greater > > > > flexibility in the development of the runtime, especially around > > > > dependency constraints. > > > > > > > > It wouldn't automatically solve the coinstallability problem of KF5 > and > > > > KF6, because a kglobalacceld provided by KF5-KGlobalAccel would still > > > > conflict with a Plasma-provided kglobalacceld, but it's at least > > > > conceptually less messy since it's clear that the Plasma-provided one > > > > would be the preferred one to use. > > > > > > > > Thoughts about this? > > > > > > +1 > > > > > > There's one caveat though: given that the library and the runtime parts > > > will have different release schedules, we will have to be careful about > > > protocol changes. Perhaps we could borrow a thing or two from > activities? > > > > Or... move both runtime and API on the Plasma side? This way no problem > of > > different release schedules and it makes it clear that using it ties you > to a > > specific desktop anyway? > > > > With a quick grep it looks like most of the users are already shipped > with > > Plasma or desktop specific anyway. Granted
D15481: Fix 'Impossible to use knsrc file for uploads from non standard location'
whiting accepted this revision. whiting added a comment. This revision is now accepted and ready to land. Looks good to me. Thanks for doing that fix. REPOSITORY R304 KNewStuff BRANCH master REVISION DETAIL https://phabricator.kde.org/D15481 To: habacker, whiting Cc: whiting, kde-frameworks-devel, michaelh, ngraham, bruns
D7968: Forward QComboBox signals instead of QComboBox lineedit signals
whiting added a comment. Hey all, this change breaks Kompare https://bugs.kde.org/show_bug.cgi?id=390024 which watches a KUrlRequester's textChanged signal to update a button's enabled state. We are not seeing the textChanged signal on the KUrlRequester anymore when programatically setting the url with the KUrlComboBox we give to the KUrlRequester via it's setUrl method. Looking at KUrlComboBox::setUrl it's blocking signals in the body of setUrl and since we are not connecting to the QLineEdit anymore we never get that signal. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D7968 To: mwolff, apol, dfaure Cc: whiting, #frameworks, michaelh
Re: Review Request 129257: [KNewStuff] Make it possible to query installed entries
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129257/#review100273 --- Ship it! Ship It! - Jeremy Whiting On Oct. 24, 2016, 7:10 p.m., Aleix Pol Gonzalez wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/129257/ > --- > > (Updated Oct. 24, 2016, 7:10 p.m.) > > > Review request for KDE Frameworks and Jeremy Whiting. > > > Repository: knewstuff > > > Description > --- > > Much like with updates. It will be useful to be able to query for installed > packages without having to look them all up. > > > Diffs > - > > src/core/engine.cpp ab47405 > src/core/engine_p.h 11571bf > src/downloadmanager.h 39769f3 > src/downloadmanager.cpp 8ce813b > > Diff: https://git.reviewboard.kde.org/r/129257/diff/ > > > Testing > --- > > Works on my newbackends branch for discover where I refactored the internals > to be more async, there we can just fetch the installed packages at start > without having to fetch everything. > > > Thanks, > > Aleix Pol Gonzalez > >
Re: Review Request 128814: Add Qt5Network as a public dependency.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128814/#review98825
---
Ship it!
Ship It!
- Jeremy Whiting
On Sept. 1, 2016, 11:58 a.m., Michael Palimaka wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128814/
> ---
>
> (Updated Sept. 1, 2016, 11:58 a.m.)
>
>
> Review request for KDE Frameworks.
>
>
> Repository: attica
>
>
> Description
> ---
>
> Attica uses Qt5Network in its public API, so it must declare it as a public
> dependency otherwise consumers could fail to build if Qt5Network is not
> already
> found elsewhere in the dependency tree.
>
>
> Diffs
> -
>
> KF5AtticaConfig.cmake.in 078d03c416316fc446b40405cb35f23665f5ed86
>
> Diff: https://git.reviewboard.kde.org/r/128814/diff/
>
>
> Testing
> ---
>
> Consider this test case:
>
> ```cmake
> project(test)
> find_package(ECM 1.7.0 REQUIRED NO_MODULE)
> find_package(KF5Attica REQUIRED)
>
> set(test_SRCS test.cpp)
> add_executable(test ${test_SRCS})
> target_link_libraries(test KF5::Attica)
> ```
>
> Before the change it fails to build with ``ld: cannot find -lQt5::Network``,
> after the change it passes.
>
>
> Thanks,
>
> Michael Palimaka
>
>
Re: Review Request 128740: uncompress archives in subfolders
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128740/#review98570
---
Ship it!
Ship It!
- Jeremy Whiting
On Aug. 23, 2016, 8:43 a.m., Marco Martin wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128740/
> ---
>
> (Updated Aug. 23, 2016, 8:43 a.m.)
>
>
> Review request for KDE Frameworks, Sebastian Kügler and Jeremy Whiting.
>
>
> Repository: knewstuff
>
>
> Description
> ---
>
> if the archive downloaded by ghns has more than a file inside (either single
> file or a folder at the root), uncompress it in a folder called the same as
> the file name (without path or extension)
>
> this fixes downloading and installing plasma wallpaper packages (those that
> provide multiple resolutions).
> I don't know if this behavior would in turn break other applications, but i
> don't think so as it seems the behavior changed between kde4 and kf5.
> if needed i can make it do this only in the case of wallpapers (if
> (standardResourceDirectory == QLatin1String("wallpaper"))) but i think this
> should be the correct behavior
>
>
> Diffs
> -
>
> src/core/installation.cpp a027418
>
> Diff: https://git.reviewboard.kde.org/r/128740/diff/
>
>
> Testing
> ---
>
>
> Thanks,
>
> Marco Martin
>
>
Re: Review Request 128219: No longer allow installing to generic data folder because of security hole.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128219/ --- (Updated Aug. 15, 2016, 9:49 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, David Faure and Richard Moore. Changes --- Submitted with commit 9746ff5553db0f3e869b0a9970e1304554e6f7fe by Jeremy Whiting to branch master. Repository: knewstuff Description --- When an application uses TargetDir=/ or StandardResource=data give a warning on the terminal and don't use the chosen location. Diffs - src/core/installation.cpp a027418 Diff: https://git.reviewboard.kde.org/r/128219/diff/ Testing --- No testing done yet, will write a unit test of some kind if this is the right direction. Thanks, Jeremy Whiting
Re: Review Request 128219: No longer allow installing to generic data folder because of security hole.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128219/ --- (Updated Aug. 12, 2016, 12:58 p.m.) Review request for KDE Frameworks, David Faure and Richard Moore. Changes --- Removed StandardResource "data" altogether since it's not used anymore. Repository: knewstuff Description --- When an application uses TargetDir=/ or StandardResource=data give a warning on the terminal and don't use the chosen location. Diffs (updated) - src/core/installation.cpp a027418 Diff: https://git.reviewboard.kde.org/r/128219/diff/ Testing --- No testing done yet, will write a unit test of some kind if this is the right direction. Thanks, Jeremy Whiting
Re: Review Request 128451: KNewFileMenu: fix creating symlinks with a relative target.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128451/#review97731 --- Ship it! Ship It! - Jeremy Whiting On July 21, 2016, 3:30 p.m., David Faure wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128451/ > --- > > (Updated July 21, 2016, 3:30 p.m.) > > > Review request for KDE Frameworks, Chinmoy Ranjan Pradhan and Jeremy Whiting. > > > Repository: kio > > > Description > --- > > KNameAndUrlInputDialog::url() makes URLs absolute (which is useful in > general, for e.g. passing to KIO), so I added urlText() to retrieve > the text as is. > > This removes all the code about showing an error on remote URLs; we just > create symlinks to the requested target, whether it looks like "../foo" or > "a:/b" which could be a relative path too (although an unusual one). > > Bug misreported as a comment in bug 352927. > > > Diffs > - > > src/filewidgets/knameandurlinputdialog.h > c32745d02a1a7361ac35a836cf57d7b9952cc49f > src/filewidgets/knameandurlinputdialog.cpp > b7a6645874673e998e05ee73a2daef746ce39dd6 > src/filewidgets/knewfilemenu.cpp 2e613b19a98587c9a62c9cccf0f8695730798e89 > > Diff: https://git.reviewboard.kde.org/r/128451/diff/ > > > Testing > --- > > Created a symlink to "../anotherdir" in konqueror/dolphinpart using "Create > New" / "Basic link to file or directory...", the target now stays relative. > > I looked up who wrote that symlink creation code in order to add him as a > reviewer turns out the author of commit 8684162 in kde-baseapps is > me. > > > Thanks, > > David Faure > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 128494: KPropertiesDialog: simplify button box usage, fix behavior on Esc
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128494/#review97728 --- Ship it! Ship It! - Jeremy Whiting On July 21, 2016, 3:06 p.m., David Faure wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128494/ > --- > > (Updated July 21, 2016, 3:06 p.m.) > > > Review request for KDE Frameworks. > > > Repository: kio > > > Description > --- > > slotCancel() isn't called when pressing Esc or closing the window with > the window manager button. > > Doing this the more standard way (reimplementing accept() and reject()) > simplifies the code (since KPageDialog sets up the buttonbox this way already) > and will be useful for knewfilemenutest which calls accept() on all types of > dialog. > > > Diffs > - > > src/widgets/kpropertiesdialog.h b451a6ffcb248beb324ef612a0336148c96bccc2 > src/widgets/kpropertiesdialog.cpp 808765c706ded7f109719bb2d731692fca0163d8 > tests/kpropertiesdialogtest.cpp 7b180608716fa7de0bb2e5221330d0be958ef945 > > Diff: https://git.reviewboard.kde.org/r/128494/diff/ > > > Testing > --- > > Looking at the output from kpropertiesdialogtest, to ensure the signals are > emitted, and only once. > Tested OK, Cancel, Esc, Alt+F4. > > > Thanks, > > David Faure > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 128219: No longer allow installing to generic data folder because of security hole.
> On June 17, 2016, 1:36 a.m., David Faure wrote: > > src/core/installation.cpp, line 379 > > <https://git.reviewboard.kde.org/r/128219/diff/1/?file=469097#file469097line379> > > > > There are of course other values for targetDirectory which would create > > problems. > > - "//" > > - "./" > > - "../etc" > > - and so on > > > > But this is a setting written by the app developer, not by the person > > uploading knewstuff data, so we can assume no malicious intention, right? > > Jeremy Whiting wrote: > Yes only application developer. Or end user if they want to tweak the > .knsrc files by hand to introduce a security vulnerability. Though if they > wanted to do that there are much easier ways to do it. Heh, the apidocs for KNS3::DownloadDialog about knsrc files says: "StandardResource: not available in KF5, use XdgTargetDir instead." maybe we should remove all support for StandardResource=. Though some applications have StandardResource=tmp that I saw, are those all broken? or where did the text in the apidocs come from? Git blame just says it's from before the split into separate git repos. - Jeremy --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128219/#review96621 --- On June 16, 2016, 7:55 p.m., Jeremy Whiting wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128219/ > --- > > (Updated June 16, 2016, 7:55 p.m.) > > > Review request for KDE Frameworks, David Faure and Richard Moore. > > > Repository: knewstuff > > > Description > --- > > When an application uses TargetDir=/ or StandardResource=data give a warning > on the terminal and don't use the chosen location. > > > Diffs > - > > src/core/installation.cpp cbd0653 > > Diff: https://git.reviewboard.kde.org/r/128219/diff/ > > > Testing > --- > > No testing done yet, will write a unit test of some kind if this is the right > direction. > > > Thanks, > > Jeremy Whiting > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 128317: Make the download dialog fail when *all* categories are missing, not just one
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128317/#review96956 --- Ship it! Ship It! - Jeremy Whiting On June 29, 2016, 5:27 a.m., Marco Martin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128317/ > --- > > (Updated June 29, 2016, 5:27 a.m.) > > > Review request for KDE Frameworks and Aleix Pol Gonzalez. > > > Repository: knewstuff > > > Description > --- > > the recent change ed0a1be18ec5b421fc1319d2a28f118d9ea324b9 made the download > dialog fail if a category is not found. > > this fixes the dialog showing completely unrelated stuff, but it's too much. > if even just one category is available, the safest way is to show whatever of > the available categories was found. > the new server will have some category less (for instance most of the > categories like "KDE Wallpaper 800x600" will go, so in order to be compatible > with old clients, it needs to show content even if one of the categories are > available) > > > Diffs > - > > src/attica/atticaprovider.cpp ad506cd > > Diff: https://git.reviewboard.kde.org/r/128317/diff/ > > > Testing > --- > > > Thanks, > > Marco Martin > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 128219: No longer allow installing to generic data folder because of security hole.
> On June 17, 2016, 1:36 a.m., David Faure wrote: > > src/core/installation.cpp, line 365 > > <https://git.reviewboard.kde.org/r/128219/diff/1/?file=469097#file469097line365> > > > > Should this code get support for "appdata" then? > > (typically share/kmyapp) > > > > Otherwise I don't see where application data would get installed > > anymore. > > > > Am I right that there must be lots of apps using "data" right now, for > > lack of "appdata" support? > > Surely not every app using knewstuff, is using it for "tmp" or "config" > > files I have a build of most of the "official" kde applications here. Not all of the possible .knsrc files by any means, but a good selection most likely. Looking at what I have here all uses of StandardResource were either tmp or wallpapers. Most applications use TargetDir instead and specify a path within appdata. apps/kvtml, color-schemes, cantor/examples etc. I couldn't see any at all here that are using StandardResource=data directly. I guess I should do a more thorough search on lxr.kde.org though. Ok, doing that https://lxr.kde.org/search?_filestring=.knsrc&_string=StandardResource&_casesensitive=1 shows all StandardResource= being tmp or wallpaper. No uses of "data" at all. > On June 17, 2016, 1:36 a.m., David Faure wrote: > > src/core/installation.cpp, line 366 > > <https://git.reviewboard.kde.org/r/128219/diff/1/?file=469097#file469097line366> > > > > API misuse is normally rewarded with a q[C]Warning rather than a > > q[C]Debug. > > > > The message should also mention what to use instead (depending on the > > result of the discussion in the previous comment). Yep, I'll change to qCWarning, np and mention what to use instead. > On June 17, 2016, 1:36 a.m., David Faure wrote: > > src/core/installation.cpp, line 379 > > <https://git.reviewboard.kde.org/r/128219/diff/1/?file=469097#file469097line379> > > > > There are of course other values for targetDirectory which would create > > problems. > > - "//" > > - "./" > > - "../etc" > > - and so on > > > > But this is a setting written by the app developer, not by the person > > uploading knewstuff data, so we can assume no malicious intention, right? Yes only application developer. Or end user if they want to tweak the .knsrc files by hand to introduce a security vulnerability. Though if they wanted to do that there are much easier ways to do it. - Jeremy --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128219/#review96621 --- On June 16, 2016, 7:55 p.m., Jeremy Whiting wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128219/ > --- > > (Updated June 16, 2016, 7:55 p.m.) > > > Review request for KDE Frameworks, David Faure and Richard Moore. > > > Repository: knewstuff > > > Description > --- > > When an application uses TargetDir=/ or StandardResource=data give a warning > on the terminal and don't use the chosen location. > > > Diffs > - > > src/core/installation.cpp cbd0653 > > Diff: https://git.reviewboard.kde.org/r/128219/diff/ > > > Testing > --- > > No testing done yet, will write a unit test of some kind if this is the right > direction. > > > Thanks, > > Jeremy Whiting > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 128219: No longer allow installing to generic data folder because of security hole.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128219/ --- Review request for KDE Frameworks, David Faure and Richard Moore. Repository: knewstuff Description --- When an application uses TargetDir=/ or StandardResource=data give a warning on the terminal and don't use the chosen location. Diffs - src/core/installation.cpp cbd0653 Diff: https://git.reviewboard.kde.org/r/128219/diff/ Testing --- No testing done yet, will write a unit test of some kind if this is the right direction. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 128057: Don't initialize KNS3::DownloadManager with the wrong categories
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128057/#review96108 --- Ship it! Ship It! - Jeremy Whiting On May 30, 2016, 9:12 a.m., Aleix Pol Gonzalez wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128057/ > --- > > (Updated May 30, 2016, 9:12 a.m.) > > > Review request for KDE Frameworks and Jeremy Whiting. > > > Repository: knewstuff > > > Description > --- > > If we request some unexisting categories, we'll get basically a list of all > resources in the OCS server, which is not what we want. > For now, just emit an error instead so the front-end can react to it. > > > Diffs > - > > src/attica/atticaprovider.cpp 94f869e > src/downloadmanager.h 0441742 > src/downloadmanager.cpp 9eca302 > > Diff: https://git.reviewboard.kde.org/r/128057/diff/ > > > Testing > --- > > Tested with Plasma's comic.knsrc file and Discover, which triggers this > problem. > > > Thanks, > > Aleix Pol Gonzalez > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 127997: Extend KNS3::Entry public API
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127997/#review95866 --- Sorry I missed the initial review request somehow. This looks good to me except for homepage. Homepage sounds to me like a web site url that gives more information about the KNS::Entry. Is that what you're using it for, or is it the download url of the asset? If the latter I suggest renaming homepage to url or downloadUrl or something more fitting. If the former, it looks good to me ship it. - Jeremy Whiting On May 24, 2016, 5:25 a.m., Aleix Pol Gonzalez wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127997/ > --- > > (Updated May 24, 2016, 5:25 a.m.) > > > Review request for KDE Frameworks and Jeremy Whiting. > > > Repository: knewstuff > > > Description > --- > > Exposes some API present in either EntryInternal or in Attica::Contents. > > This allows Discover's KNS Backend to just use KNewStuff entries instead of > having to additionally fetch the information in Attica. > > > Diffs > - > > src/attica/atticaprovider.cpp 07508b0 > src/core/entryinternal.cpp b05fe24 > src/core/entryinternal_p.h 20f9b1b > src/entry.h 6603e97 > src/entry.cpp 09f9542 > > Diff: https://git.reviewboard.kde.org/r/127997/diff/ > > > Testing > --- > > Discover works as it used to, with many changes I have locally. > > > Thanks, > > Aleix Pol Gonzalez > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 127900: Fix redirection of absolut Urls
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127900/#review95440 --- Ship it! Ship It! - Jeremy Whiting On May 12, 2016, 11:17 a.m., Andreas Cord-Landwehr wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127900/ > --- > > (Updated May 12, 2016, 11:17 a.m.) > > > Review request for KDE Frameworks, Cornelius Schumacher and Kevin Funk. > > > Bugs: 354748 > http://bugs.kde.org/show_bug.cgi?id=354748 > > > Repository: attica > > > Description > --- > > Redirection only worked with relative urls. Yet, e.g. the http to https > redirection on KDE servers uses absolute paths, which resulted in an > empty url, since the reply attribute was not relative. > > This patch adds a case distinction for redirecting absolut and relative > paths. > > BUG: 354748 > > > Diffs > - > > src/atticabasejob.cpp f73cb432212be63cff2ae1118c602cc3bae6d615 > > Diff: https://git.reviewboard.kde.org/r/127900/diff/ > > > Testing > --- > > Manual testing with GHNS for documentation in KDevelop. > > > Thanks, > > Andreas Cord-Landwehr > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 127887: Improve usage of Qt APIs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127887/#review95428 --- The knewstuff (non moretools) side looks good to me. - Jeremy Whiting On May 11, 2016, 5:01 p.m., Aleix Pol Gonzalez wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127887/ > --- > > (Updated May 11, 2016, 5:01 p.m.) > > > Review request for KDE Frameworks and Jeremy Whiting. > > > Repository: knewstuff > > > Description > --- > > Mostly clazy fixes, few cleanups > > > Diffs > - > > src/core/installation.cpp 1887d0f > src/kmoretools/kmoretools.h 32da22c > src/kmoretools/kmoretools.cpp 8bd6751 > src/kmoretools/kmoretoolsconfigdialog_p.cpp 466b887 > src/kmoretools/kmoretoolsmenufactory.cpp aad3f00 > src/kmoretools/kmoretoolspresets.cpp 679e849 > src/staticxml/staticxmlprovider.cpp 541bf57 > src/ui/itemsviewdelegate.cpp 7001be2 > tests/kmoretools/kmoretoolstest_interactive.cpp b1cbdea > > Diff: https://git.reviewboard.kde.org/r/127887/diff/ > > > Testing > --- > > Builds, tests pass. > > > Thanks, > > Aleix Pol Gonzalez > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 126948: Simplify attica plugin look-up and initialization
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126948/#review91908 --- Ship it! Ship It! - Jeremy Whiting On Feb. 1, 2016, 12:37 p.m., Aleix Pol Gonzalez wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126948/ > --- > > (Updated Feb. 1, 2016, 12:37 p.m.) > > > Review request for KDE Frameworks. > > > Repository: attica > > > Description > --- > > Just use QPluginLoader instead of doing it locally (and with an awkward > blocking QProcess call) > > > Diffs > - > > src/providermanager.cpp 0536a1f > > Diff: https://git.reviewboard.kde.org/r/126948/diff/ > > > Testing > --- > > Test still passes, initializing attica still finds the right plugin on my > system. > > > Thanks, > > Aleix Pol Gonzalez > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 126039: When configfile is loaded from resource, do not issue file not found error
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126039/#review89265 --- Ship it! Works for me, sorry I missed this somehow. - Jeremy Whiting On Nov. 12, 2015, 4:15 p.m., Andrew McCann wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126039/ > --- > > (Updated Nov. 12, 2015, 4:15 p.m.) > > > Review request for KDE Frameworks, Christoph Cullmann and Jeremy Whiting. > > > Repository: knewstuff > > > Description > --- > > When configfile is loaded from resource, do not issue file not found error. > > Encountered this problem while attempting to make KDevelop work on OSX as an > app bundle. > > Concretely, the logic error here is that the file actually is loaded and is > aborting early. > > If the file were actually not found, the following code block that tests for > validity will error anyway. > > > Diffs > - > > src/core/engine.cpp 56912ddfa8312ea6233aecffda296f041b180237 > > Diff: https://git.reviewboard.kde.org/r/126039/diff/ > > > Testing > --- > > Verify that loading configfile from qt5's resource system ex > ":/kconfig/test.knsrc" now works and didn't before. > > > Thanks, > > Andrew McCann > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KNotifications filters
Yeah, that makes sense. Ok will do. On Sun, Dec 6, 2015 at 3:37 AM, David Faure wrote: > On Thursday 24 September 2015 20:35:24 Jeremy Whiting wrote: >> If so I guess the logical place for it would be a TTS group in >> kdeglobals, does that make sense? > > Stay away from kdeglobals :-) > It forces every app to parse that stuff even if they don't need it. > > Framework-specific config can go into a framework-specific config file, > it doesn't have to be kdeglobals. > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Maintenance of api.kde.org
Alex, Last time I checked api.kde.org was generated by scripts in the websites/quality-kde-org git repository. It includes instructions for installing it locally, though the instructions are a bit outdated. I think perl's setup scripts have changed since it was written since I needed to tweak the install script to get it to install here (when I was looking into it about 8 months ago or so). Poke me if you hit the same issues and I can put a patch up on reviewboard if it's still around my hard drive here somewhere... thanks, Jeremy On Thu, Nov 5, 2015 at 4:58 PM, Alex Merry wrote: > On 2015-11-05 09:22, Ben Cooksley wrote: >> >> Hi all, >> >> For some time it has been apparent that api.kde.org is experiencing >> some issues with maintenance. It doesn't really fall into sysadmin's >> domain, but developers often lack the knowledge on how to get Doxygen >> working as needed to build projects API documentation. This isn't >> helped by the setup not being simple for easy local testing. >> >> Any volunteers to look into it, fix some issues and generally make it >> easier to work with for the future? > > > This is my domain really, as maintainer of kapidox - kapidox was intended to > make this simpler and easier, but currently it's only run on frameworks. I > don't really know much about the automation on api.kde.org itself, though, > and we need to figure out how to choose whether to run kapidox, kdelibs4's > apidox generation scripts, or no apidox generation at all for a given > project. > > I'm willing to put some time into this, but I'd need to be able to at least > mirror api.kde.org's setup locally to try tweaking and testing things - > going through Allen Winter every time I want to test something out (and then > waiting for the cron jobs or whatever to run) is just too slow of a feedback > cycle. > > Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125884: Set default value for WheelScrollLines
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125884/#review87824 --- Ship it! Ship It! - Jeremy Whiting On Oct. 30, 2015, 3 p.m., David Rosca wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125884/ > --- > > (Updated Oct. 30, 2015, 3 p.m.) > > > Review request for KDE Frameworks. > > > Repository: frameworkintegration > > > Description > --- > > Use 3 (same as mouse kcm) as default value instead of > QApplication::wheelScrollLines(). > > > Diffs > - > > src/platformtheme/khintssettings.cpp e5c362a > > Diff: https://git.reviewboard.kde.org/r/125884/diff/ > > > Testing > --- > > No longer sets 0 lines when WheelScrollLines entry is not in kdeglobals. > > > Thanks, > > David Rosca > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125767: Make KConfigWidgets self contained, bundle the one global file in a resource
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125767/#review87363 --- Ship it! Ship It! - Jeremy Whiting On Oct. 23, 2015, 12:57 p.m., Christoph Cullmann wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125767/ > --- > > (Updated Oct. 23, 2015, 12:57 p.m.) > > > Review request for KDE Frameworks. > > > Repository: kconfigwidgets > > > Description > --- > > Make KConfigWidgets self contained, bundle the one global file in a resource > Mark as working on all opsys, does work OK on win & mac > > > Diffs > - > > metainfo.yaml 48cf5b6 > src/CMakeLists.txt 10862c6 > src/kconfigwidgets.qrc PRE-CREATION > src/ktipdialog.cpp 25559b6 > > Diff: https://git.reviewboard.kde.org/r/125767/diff/ > > > Testing > --- > > compiles, looks ok. > > > Thanks, > > Christoph Cullmann > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [KDE/Mac] Question about goal of Windows/Mac frameworks
Yeah, if we go that direction on mac it would be fine for bundled Qt, but not for shared Qt. It would make all applications that use qt5-mac or qt5-kde or whatnot use linuxy paths or not. It's a runtime switch, so not very helpful if you've installed stuff to linuxy paths and then let the user choose to toggle it and fail to find all the resources needed. It sounds like a good solution for embedding a copy of Qt next to each application for windows use (and maybe for osx use too if resources don't make it completely unneccessary), but not for the macports shared Qt case. On Thu, Oct 22, 2015 at 2:37 PM, René J.V. wrote: > On Thursday October 22 2015 22:05:59 Marko Käning wrote: > >> > https://bugreports.qt.io/browse/QTBUG-44473?focusedCommentId=272971&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-272971) >> > Because the proposal supports environment variables too, I guess this >> > would also cover the OS X needs (env XDG_CONFIG_DIRS). >> >> that actually slipped my attention back then! :-| >> >> OK, perhaps that is a way to go then also for MacPorts?! @René? > > I understood from Jeremy's reply at the time that it wasn't exactly what we'd > need. I'm not familiar with how qt.conf is to be used, but my 1st impression > is that neither a per-app-bundle qt.conf nor a central, shared one would be > the perfect solution. The per-application approach will be much more > maintenance-heavy, and a central, shared file would mean that all > applications depending on Qt5 use either the one or the other QSP "flavour". > > > R. > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125656: Drop empty files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125656/#review87199 --- Ship it! Ship It! - Jeremy Whiting On Oct. 21, 2015, 4:29 a.m., Maximiliano Curia wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125656/ > --- > > (Updated Oct. 21, 2015, 4:29 a.m.) > > > Review request for KDE Frameworks and Jeremy Whiting. > > > Repository: knewstuff > > > Description > --- > > Currently the file src/core/upload.cpp is under a LGPL-2 only license, and > shipping the corresponding full license is required. Which is incompatible > with the current frameworks policy. The mentioned file and the private header > src/core/upload_p.h are currently "empty", as they contain only commented out > functions. And these files are not part of the API, so it's safe to drop them. > > > Diffs > - > > src/core/upload.cpp 486129b55bb108f965050ecc25df7e6d98bebb9e > src/core/upload_p.h 4fa38689f64a0dec94666962a7541dd3d6086482 > > Diff: https://git.reviewboard.kde.org/r/125656/diff/ > > > Testing > --- > > > Thanks, > > Maximiliano Curia > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Question about goal of Windows/Mac frameworks
Christoph, I'm not trying to argue against having applications come in complete bundles at all. That is a worthy goal also actually, it's just not the direction I was headed in. You've made a lot more progress in this regard than I had though tbh. I see the kdewin installer as something that went away because it was tricky to set up, had a bus number of one (I think only Saro was creating repositories for it iirc), so it fell by the wayside at some point. I did use it to install my favorite kde utilities on windows whenever I was stuck on windows for various reasons though. It was useful to install ksnapshot, filelight, etc. and have them use the same copy of kdelibs. Maybe with frameworks it's not that important to share libraries between applications though. I'm not sure. I can understand arguments for both ways of doing things. Having each application have it's own copy of Qt, KF5, etc. makes it possible to know that those versions have been tested with the application code to make sure it runs well etc. If applications are sharing one copy of Qt and one of them upgrades it, it's not guaranteed to work the same way as an older version (it's supposed to work, but I've seen enough e-mail about Qt 5.x breaks plasma where it worked with Qt 5.x-1 to know this isn't always the case in reality.) Also, the work you're doing to make frameworks use bundled resources will help both of the above use cases, so that's definitely an improvement in my opinion. I can see advanced users either using macports, fink, homebrew or a download and install x,y,z and share libraries to install many of our applications. I can also see the same power users recommending individual applications to their relatives (moms, grandmothers, etc.) using single application installers as you described. "Here mom, download this one bundle to install kxstitch on your windows laptop." etc. So there are advantages to both/all ways of going forward I think. BR, Jeremy On Tue, Oct 20, 2015 at 1:19 PM, Alexander Neundorf wrote: > On Tuesday, October 20, 2015 20:23:00 Christoph Cullmann wrote: > >> Hi, > >> > >> > Christoph. > >> > > >> > I have had similar goals for a while, but haven't reached the point > >> > that I was having much success yet in that regard. One thing to keep > >> > in mind when developing installers, Qt Installer Framework. I did a > >> > quick test with attica on OS X I can put on reviewboard to see what > >> > you think. I added a few lines to CMakeLists.txt to make it so you can > >> > do make package, and it uses CPack and Qt Installer Framework to > >> > create an installer application which can be used to download both > >> > attica and attica-devel packages for OSX. I bet we could put together > >> > a "meta" package for at least KF5 and maybe more which would consist > >> > of a CMakeLists.txt and a bunch of git clones beneath it could be used > >> > to create one OSX or Windows installer that could then be used to > >> > download applications and all their dependencies. I wasn't sure how to > >> > add dependency information to the result of CPack's QIFW generator, > >> > but it should be doable. > >> > > >> > The result of all of that would be one tool for OS X and a similar one > >> > for Windows that work exactly like the Qt online installers. Qt's > >> > online installers are meant for developers though, not end users, so > >> > we may need to improve QIF itself to make the resulting installer more > >> > user friendly, we'll see. I meant to blog about all of this a week or > >> > so ago, but haven't gotten around to it. What do you think of the idea > >> > in general though? > >> > >> I am not really a fan of that idea, to be honest. > >> > >> I think that is more or less what we had in the past with the "kdewin" > >> installer, that is like the cygwin installer pulling in all stuff you need > >> and a set of applications in some common prefix. > >> > >> I am not sure that was such a success, compared to what e.g. Krita, >> Marble, > >> Digikam and others do: individual self-contained installers (or bundles). > >> > >> I really think we should focus on making frameworks fit for that and not > >> rebuilding some "micro-distro" with online installer for that operating > >> systems. > >> > >> But that is just my opinion, perhaps I am wrong with that. > > > > I fully agree with your POV. > > > > Alex > > > > > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Question about goal of Windows/Mac frameworks
Christoph. I have had similar goals for a while, but haven't reached the point that I was having much success yet in that regard. One thing to keep in mind when developing installers, Qt Installer Framework. I did a quick test with attica on OS X I can put on reviewboard to see what you think. I added a few lines to CMakeLists.txt to make it so you can do make package, and it uses CPack and Qt Installer Framework to create an installer application which can be used to download both attica and attica-devel packages for OSX. I bet we could put together a "meta" package for at least KF5 and maybe more which would consist of a CMakeLists.txt and a bunch of git clones beneath it could be used to create one OSX or Windows installer that could then be used to download applications and all their dependencies. I wasn't sure how to add dependency information to the result of CPack's QIFW generator, but it should be doable. The result of all of that would be one tool for OS X and a similar one for Windows that work exactly like the Qt online installers. Qt's online installers are meant for developers though, not end users, so we may need to improve QIF itself to make the resulting installer more user friendly, we'll see. I meant to blog about all of this a week or so ago, but haven't gotten around to it. What do you think of the idea in general though? thanks, Jeremy On Tue, Oct 20, 2015 at 12:04 PM, Christoph Cullmann wrote: > Hi, > >> Hi, >> With my Android hat on I very much welcome the initiative. Android is >> more limited in this regard, as you will mostly always want to have >> split packages there and it's how we've been working since the >> beginning. >> >> I think that for us Qt is a safe base in general. relying on other 3rd >> parties makes things a bit more complex. (e.g. dbus or gstreamer) It's >> always arguable that it is possible to run, but then it can be a >> burden. While on Linux it's preferable to leverage on the system >> infrastructure, we can't expect these to be available elsewhere. >> >> I can agree to the 3 goals you mentioned, but they feel fuzzy: >> 1) Fully agreed > 1) Stock Qt > >> 2) What's Global stuff? This could be phrased as: "Frameworks should >> only require resources that can be located with QStandardPaths and can >> be distributed in bundles." > Badly phrased, yes, I think 2) is more like: > > 2) Can be self-contained shipped in an application bundle (self-installer/mac > app bundle). > >> 3) non-existing stuff? really? Let's rephrase it as: "Frameworks will >> only be advertised as available on a platform if they are just require >> Qt or other available dependencies on the platform". For example, >> requiring libssh could be an acceptable dependency. >> >> Regarding dbus especifically, I see the problem in 2). You can bundle >> it, but then if it's already ran by another process the other one will >> have to be used, which is where the dbus mess starts. > Yeah, 3) is perhaps more like: > > 3) Frameworks shall require only libraries shipped with the target operating > system > per default (which is quiet well defined on Win/Mac, but not that well > defined on Linux). > > That additional stuff might be useful/recommended is clear, IMHO, like you > can have > nice git integration if you have libgit2 for KTextEditor, but it works > without. > > Greetings > Christoph > > -- > - Dr.-Ing. Christoph Cullmann - > AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com > Science Park 1 Tel: +49-681-38360-22 > 66123 Saarbrücken Fax: +49-681-38360-20 > GERMANYWWW: http://www.AbsInt.com > > Geschäftsführung: Dr.-Ing. Christian Ferdinand > Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
I'd like to weigh in a bit here too. I agree with Boud and Christoph, most users (developers of applications) of KF5 that aren't KDE community members will be building the frameworks themselves. At my last job we built Qt ourselves on all the platforms we targetted and shipped shared libraries with the application like Boud has said. We even had scripts that would set LD_LIBRARY_PATH to the application folder so our Qt was preferred over any system Qt for linux. I also agree with what Martin said a few emails ago. Applications we are distributing on non kde platforms (or maybe even when running them on GNOME?) should probably not use knotifications, etc. Though that would remove a bit of their functionality. Personally I'd like to see stuff like knewstuff working on windows/mac, but can't imagine it will since it uses kio heavily (and thus needs kdeinit, etc.). I think the more modular we can get the KDE Frameworks the better. BR, Jeremy On Wed, Oct 14, 2015 at 1:51 PM, Boudewijn Rempt wrote: > On Wed, 14 Oct 2015, Martin Klapetek wrote: > >> I have to agree with Harald here though, I would also expect >> the frameworks to be bunch of pre-built dlls you just install >> system-wide and build on top of that, not create your own >> custom builds of everything, for every app with different features >> combo. At which point this all wouldn't be so much of a problem >> I believe. > > > Erm... The very _idea_ that you'd install a bunch of dll's system-wide > on Windows or OSX or Android is... Words, at least, polite words, fail > me. It's not just not done, it's actively wrong. (Note that ministro's > way of doing shared Qt libraries no longer works in the most recent Android > either, it's not a counter example.) > > I've been trying to get this point across at least since the desktop > summit in berlin, and I guess I'm just congenitally incapable of stringing > words together into an intelligible narrative because I'm failing _hard_. > > Fink, macports, emerge, cygwin and all the other refuges for Linux > developers who have to use Windows or decide to defect to OSX are totally > and utterly irrelevant. If you want to make a library that's used for a > cross-platform application, that is. > > There is _one_ way to package your application for Windows, and that is > create an installer that packages everything, every dependency that the > application needs _including_ the msv c runtime dll. Everything else > will not get your application in your user's hands. > > There are _two_ ways to package your application for OSX: as an app bundle > in a disk image or as an app bundle in an installer. The app bundle > contains all dependencies, everything, except for the stuff Apple puts > on the system. Everything else will not get your application in your > user's hands. > > Any approach that dreams of sharing libraries, configuration locations or > _any_ other resource not provided by the OS among multiple applications > will not get that library used by applications that target Windows or OSX. > > Now, re-using and re-packaging pre-built dll's _is_ possible. It's > sometimes, as with fftw3, even the only realistic option. But it would > still put that dll in the exe dir of every application that uses it. And, > with complex libraries, it's still not going to work. I use a bunch of > cmake external projects to build all the deps, so I can cut down on what's > in there, for instance, and I should cut even more than I'm already doing. > > Boudewijn > > Ps: there are three ways of packaging an app on Linux: let the distribution > do it, and fight with your users because they cannot get the latest version, > package it yourself for each popular distro (in my case, *buntu, CentOS and > OpenSUSE) or make a distro-independent package, which every big open source > project does, like Blender or Firefox. In the last case, you'll again have > to package everything, like on Windows and OSX. > > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125521: Added KDropWidgetDecorator copied from DropWidget in kile sources. Relicensed from GPL 2+ to LGPL 2+ with author's permission.
> On Oct. 4, 2015, 2:22 p.m., David Edmundson wrote: > > src/kdropwidgetdecorator.h, line 37 > > <https://git.reviewboard.kde.org/r/125521/diff/2/?file=409641#file409641line37> > > > > This isn't really a decorator pattern. It's just a widget. > > > > A decorator would probably take a QTabBar as an argument and then > > create and show this widget as needed depending on how many tabs that > > tabbar had. Should we just rename it to KDropWidget? Or should I make it act like a decorator? > On Oct. 4, 2015, 2:22 p.m., David Edmundson wrote: > > src/kdropwidgetdecorator.cpp, line 41 > > <https://git.reviewboard.kde.org/r/125521/diff/2/?file=409642#file409642line41> > > > > if nothing is connected, or it's a queuedconnection then b is > > uninitialised. > > > > For what this is trying to do, a function pointer might work better. Yeah, the reason it's set up this way is because it can be a drop in replacement for the old KDELibs4Support KTabWidget. - Jeremy --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125521/#review86352 --- On Oct. 4, 2015, 1:43 p.m., Jeremy Whiting wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125521/ > --- > > (Updated Oct. 4, 2015, 1:43 p.m.) > > > Review request for KDE Frameworks and Christoph Feck. > > > Repository: kwidgetsaddons > > > Description > --- > > Added KDropWidgetDecorator copied from DropWidget in kile sources. Relicensed > from GPL 2+ to LGPL 2+ with author's permission. > > > Diffs > - > > src/CMakeLists.txt e03e9bbd6d73811873b0a465f86da269f4295138 > src/kdropwidgetdecorator.h PRE-CREATION > src/kdropwidgetdecorator.cpp PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/125521/diff/ > > > Testing > --- > > It builds, the headers I expect are in the right places, etc. I just noticed > I'm not exporting the class though, will fix that and reupload. > > > Thanks, > > Jeremy Whiting > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KTabWidget vs QTabWidget
Thanks, First patch here: https://git.reviewboard.kde.org/r/125521/. After that I'll try using it in Kile and Okular, see how that goes. On Thu, Sep 24, 2015 at 11:47 PM, Michel Ludwig wrote: > > On 09/25/2015 01:57 AM, Jeremy Whiting wrote: >> >> Michel, >> >> Would you mind if I move the DropWidget you wrote for kile into >> kwidgetsaddons and give it a name like KDropWidget and relicense it to >> LGPL v2+ ? >> > That's totally fine with me. > > Michel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125521: Added KDropWidgetDecorator copied from DropWidget in kile sources. Relicensed from GPL 2+ to LGPL 2+ with author's permission.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125521/ --- (Updated Oct. 4, 2015, 1:43 p.m.) Review request for KDE Frameworks and Christoph Feck. Changes --- Added exporting the class. Repository: kwidgetsaddons Description --- Added KDropWidgetDecorator copied from DropWidget in kile sources. Relicensed from GPL 2+ to LGPL 2+ with author's permission. Diffs (updated) - src/CMakeLists.txt e03e9bbd6d73811873b0a465f86da269f4295138 src/kdropwidgetdecorator.h PRE-CREATION src/kdropwidgetdecorator.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/125521/diff/ Testing --- It builds, the headers I expect are in the right places, etc. I just noticed I'm not exporting the class though, will fix that and reupload. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 125521: Added KDropWidgetDecorator copied from DropWidget in kile sources. Relicensed from GPL 2+ to LGPL 2+ with author's permission.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125521/ --- Review request for KDE Frameworks and Christoph Feck. Repository: kwidgetsaddons Description --- Added KDropWidgetDecorator copied from DropWidget in kile sources. Relicensed from GPL 2+ to LGPL 2+ with author's permission. Diffs - src/CMakeLists.txt e03e9bbd6d73811873b0a465f86da269f4295138 src/kdropwidgetdecorator.h PRE-CREATION src/kdropwidgetdecorator.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/125521/diff/ Testing --- It builds, the headers I expect are in the right places, etc. I just noticed I'm not exporting the class though, will fix that and reupload. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KNotifications filters
Hey all, I've discussed this a bit with Eike previously, but thought I'd try a wider audience to get some more ideas. When we used to have kttsd/jovie it had the concept of filters that it would use for different applications speech to normalize what gets sent to the synthesizer. In this way notifications from kopete/konversation/whatever would be changed from: 'PovAddict: why are you not here!' to Milian says: PovAddict: why are you not here! The Jovie git repository has some default filters that can be used for chat, chat-de, kmail, polish, qt2plaintext etc. that were useful for users to load that would do the filtering. I think this feature was very very hard to find though. Anyway, Jovie is dying, and I'd like to bring this feature back to all speech that goes through KNotifications to QtSpeech. KNotifications has src/notifybytts which sends notification text, or appname, or can even send eventId to QtSpeech, but I'd like to add filtering here. I think we should probably default to filtering with all sane filters but make them customizable of course in case anyone wants to tweak them. The problem is that KNotifications pass a KNotifyConfig for each notification, so each application's notifications have their own config for TTS entry. Should/could we use one global configuration for all filters and load it in NotifyByTTS::notify so all notifications are filtered the same way? If so I guess the logical place for it would be a TTS group in kdeglobals, does that make sense? thanks, Jeremy ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KTabWidget vs QTabWidget
Michel, Would you mind if I move the DropWidget you wrote for kile into kwidgetsaddons and give it a name like KDropWidget and relicense it to LGPL v2+ ? On Thu, Sep 24, 2015 at 2:09 AM, Andreas Cord-Landwehr wrote: > On Wednesday, September 23, 2015 4:12:01 PM CEST Jeremy Whiting wrote: > >> Yes, the two authors of that code are Michel Ludwig and Andreas > >> Cord-Landwehr who both are listed in relicensecheck.pl as giving > >> permission to change to lgpl+ So I think we should be fine to > >> move/copy that in and start using it in stead of the copy in kile. > > > > Hi, I hereby also grant permission for relicensing the named source code > from any GPL version to any LGPL+ version. Thanks Andreas. That should simplify things. thanks, Jeremy > > > > Cheers, > > Andreas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets
That does sound like a bit more interesting question. Browsing through http://lxr.kde.org/ident?_i=QStandardPaths&_remember=1 (quite a long list...) a couple of things come to mind. First anything that's using QStandardPaths isn't necessarily using any frameworks at all. Looking at http://agateau.com/2013/kf5-diagrams/kf5.png (which admittedly may not be up to date either) it seems KCoreAddons is a very commonly used framework. Also depended on by many other frameworks and used by many applications. It contains KAboutData which is used by pretty much any GUI application that we release, I'm not sure if it matters if it needs to be used by command-line tools also or not. I'm not sure how many if any command line tools or system daemons etc. are using QStandardPaths. Maybe try with KCoreAddons and see if that's a suitable enough place? BR, Jeremy On Thu, Sep 24, 2015 at 3:34 AM, René J.V. wrote: > In fact, let me ask a different question: is there a KF5 framework that is > guaranteed to be linked to by all KF5 applications that have reason (or are > likely) to query QStandardPaths for locations? > That would probably provide the cleanest and easiest solution to my quest: > that framework could be patched (on OS X or for MacPorts/Fink/...) to > activate the QSP mode switch. (And that could be either using an instance of > the dedicated class I described, or using an OS X framework initialisation > routine.) > > R. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KTabWidget vs QTabWidget
Yes, the two authors of that code are Michel Ludwig and Andreas Cord-Landwehr who both are listed in relicensecheck.pl as giving permission to change to lgpl+ So I think we should be fine to move/copy that in and start using it in stead of the copy in kile. On Tue, Sep 22, 2015 at 3:45 PM, Luigi Toscano wrote: > Jeremy Whiting ha scritto: >> In looking at what is using KTabWidget it seems there's a drop in >> replacement for what we are doing in >> http://lxr.kde.org/source/extragear/office/kile/src/kileviewmanager.h >> in DropWidget towards the bottom. Could/should we simply copy that to >> kwidgetsaddons and rename it KDropWidgetDecorator and use it where old >> code was using KTabWidget? > > If license or relicensing allow... > > Ciao > -- > Luigi > > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets
Rene, Back to your original question I don't think there is such a place, besides patching QtCore itself. Many of the frameworks and applications use KI18n, but some don't I don't think there's a common location that every application linking against KF5 libraries uses. BR, Jeremy On Wed, Sep 23, 2015 at 3:15 AM, René J.V. wrote: > Let me just add what me me come to KDE. > That was mostly out of unhappiness with changes in OS X applications and > development, and to find replacements for mail and IDE applications (and > because I'd seen on Linux that KDE4 was about ripe to be an alternative to > the OS X GUI, I was both blissfully and sadly unaware of KF5). > I also use digiKam and KDEnlive but my main applications are Kontact and > KDevelop. I could see myself use Karbon at some point when my PPC copy of > Illustrator really no longer cuts it, but for the rest I find myself reaching > for my older copy of Pages (and Numbers & Keynote) from back when Apple still > hadn't ripped out the interesting functionality, and to image processing > applications built purely on native APIs. > > Maybe this helps put my priorities in perspective ... and now, back to the > original question please! > > R. > ___ > kde-...@kde.org > List Information: https://mail.kde.org/mailman/listinfo/kde-mac > KDE/Mac Information: http://community.kde.org/Mac ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KTabWidget vs QTabWidget
In looking at what is using KTabWidget it seems there's a drop in
replacement for what we are doing in
http://lxr.kde.org/source/extragear/office/kile/src/kileviewmanager.h
in DropWidget towards the bottom. Could/should we simply copy that to
kwidgetsaddons and rename it KDropWidgetDecorator and use it where old
code was using KTabWidget?
BR,
Jeremy
On Tue, Sep 22, 2015 at 12:47 AM, David Faure wrote:
> On Monday 21 September 2015 20:16:01 Jeremy Whiting wrote:
>> David,
>>
>> I've been considering what you mean. I think I understand, but wanted
>> to check before I spend a bit of time trying to implement what you
>> described. Does the class below fit what you are considering?
>>
>> class KDropWidgetDecorator: public QObject {
>> Q_OBJECT
>> public:
>> void installEventFilter(QWidget *);
>
> installEventFilter is an existing QObject method, better just do it
> in the KDropWidgetDecorator constructor.
>
>> signals:
>> void receivedDropEvent (QDropEvent *);
>> void testCanDecode (const QDragMoveEvent *e, bool &accept);
>
> non-const refs in signals are an ugly hack.
> You don't know if there is going to be 0, 1 or N slots, and the ref only
> makes sense for 1.
>
> Instead I suggest:
> * a virtual method, but that means deriving from the decorator, not great
> * a virtual method in a separate interface class (so you can just make your
> main widget implement that interface)
> * a std::function, so the caller can pass a lambda or a static function
>
> Alternatively, call it KUrlDropWidgetDecorator and make it support urls
> out of the box. This is the most common use case all over KDE, isn't it?
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KTabWidget vs QTabWidget
David,
I've been considering what you mean. I think I understand, but wanted
to check before I spend a bit of time trying to implement what you
described. Does the class below fit what you are considering?
class KDropWidgetDecorator: public QObject {
Q_OBJECT
public:
void installEventFilter(QWidget *);
signals:
void receivedDropEvent (QDropEvent *);
void testCanDecode (const QDragMoveEvent *e, bool &accept);
};
then in the eventFilter function it would emit the old signals
accordingly and the slots connected to them can handle the QDropEvent
or QDragMoveEvent and such like they used to in KDELibs4 times.
BR,
Jeremy
On Sat, Sep 19, 2015 at 8:49 AM, David Faure wrote:
> On Friday 18 September 2015 18:46:24 Jeremy Whiting wrote:
>> Hey all,
>>
>> In looking into fixing the remaining issues in Okular's frameworks
>> branch I realized that in part of the effort to port it away from
>> KDELibs4Support it got some functionality removed. It was ported from
>> KTabWidget to QTabWidget but QTabWidget doesn't seem to support drag
>> and drop the way KTabWidget did. In looking at the KTabWidget
>> documentation on api.kde.org it still says that KTabWidget is
>> preferred over QTabWidget [1]. If that's the case why did it end up in
>> KDELibs4Support?
>
> Nobody took the time to update the documentation of all the classes
> that were moved to kdelibs4support.
> So as always: trust the code more than the documentation.
>
>> In reading Qt documentation about drag and drop [2] it seems that you
>> need to subclass widgets in order to specify any additional mime types
>> that should be handled by a drop event (which okular made use of so
>> you could drop documents on it's tab bar to open them). Without
>> KTabWidget we lose that feature completely unless we subclass
>> QTabWidget (which we have in KTabWidget... so why not just use it...).
>> Am I missing something? If not I suggest we reconsider and maybe
>> move/copy? KTabWidget into KF5::WidgetsAddons as it still provides
>> functionality we want/need in some cases. I'm not sure what would be
>> BC or SC in this case tbh (or maybe users of KTabWidget should just
>> keep using KDELibs4Support?)
>
> To be clear: QTabWidget supports dnd-to-reorder tabs, but that's not
> what you're after, you want DnD of URLs, right?
>
> It takes about 10 lines of code in a QTabWidget subclass, but of course
> I have no objection to this being provided by KF5 for convenience.
> However, *not* as a QTabWidget subclass then. We moved away from that design
> because it creates confusion (when to use QTabWidget and when to use
> KTabWidget)
> and makes things less flexible. Instead, I suggest that you want a decorator,
> much like KDragWidgetDecorator in kwidgetaddons, but for drops of URLs.
> The decorator would install event filters for DragEnter and Drop, check for
> URLs,
> decode on drop, emit a signal. The only problem is: how would we tell the
> decorator
> that we only want drops "in the empty area next to the tabbar" and not
> everywhere
> on the tabwidget... (I assume this is what you want, right?).
>
> (I'm keeping the CC to kde-core-devel so its readers can see this has been
> answered, but I suggest we now followup on kde-frameworks-devel only).
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KTabWidget vs QTabWidget
Hey all, In looking into fixing the remaining issues in Okular's frameworks branch I realized that in part of the effort to port it away from KDELibs4Support it got some functionality removed. It was ported from KTabWidget to QTabWidget but QTabWidget doesn't seem to support drag and drop the way KTabWidget did. In looking at the KTabWidget documentation on api.kde.org it still says that KTabWidget is preferred over QTabWidget [1]. If that's the case why did it end up in KDELibs4Support? In reading Qt documentation about drag and drop [2] it seems that you need to subclass widgets in order to specify any additional mime types that should be handled by a drop event (which okular made use of so you could drop documents on it's tab bar to open them). Without KTabWidget we lose that feature completely unless we subclass QTabWidget (which we have in KTabWidget... so why not just use it...). Am I missing something? If not I suggest we reconsider and maybe move/copy? KTabWidget into KF5::WidgetsAddons as it still provides functionality we want/need in some cases. I'm not sure what would be BC or SC in this case tbh (or maybe users of KTabWidget should just keep using KDELibs4Support?) BR, Jeremy 1. http://api.kde.org/frameworks-api/frameworks5-apidocs/kdelibs4support/html/classKTabWidget.html 2. http://doc.qt.io/qt-5/dnd.html ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: ksycoca and kbuildsycoca, the next step
That sounds like a good solution to all the problems you presented initially indeed. Nice work. On Sun, Sep 6, 2015 at 3:43 PM, David Faure wrote: > On Sunday 06 September 2015 13:52:37 David Faure wrote: >> >> Any idea on how to avoid cache-rebuild ping pong? >> >> I can only think of one cache per (lang, dirs) combination somehow, but that >> seems tricky >> (a config file to point to some randomly generated filename for each >> combination?). > > I had a better idea: naming the file sycoca5__ > > More precisely the last part could be the sha1 (? md5? does it matter?) > of QStandardPaths::standardLocations(QStandardPaths::GenericDataLocation), > which includes XDG_DATA_HOME too (on Unix). > > The order in that list matters so it should be a hash that is not just the > sum of the letters ;) > > I could also include the lang into the sha1, but I figure this is more > readable, > if you run one application in russian one day and you want to clean up some > disk > space later, you can delete ksycoca5_ru_* without hesitation ;) > > (That's the issue with this scheme of course, the caches will just keep > accumulating, > I don't see how we could ever delete automatically any of them, we can't know > if some > app with different settings is using them. But I guess that's a minor issue.) > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124872: Default to Breeze colors
> On Aug. 24, 2015, 12:13 a.m., Martin Gräßlin wrote: > > I must say I'm rather shocked at how this is implemented. Would it be > > possible to move the defaults into our QPT plugin, so that these defaults > > are only applied if running on a platform with our plugin, otherwise it > > picks Qt defaults? IMO it would also probably be good if we had some way of making the default based on the actual color scheme rather than having it have a copy of all the colors from the scheme. That way if Breeze.colors ever changes we don't either a) need to update this also or b) get mismatch between Default and Breeze in the colors kcm ui. - Jeremy --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124872/#review84241 --- On Aug. 21, 2015, 3:35 p.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124872/ > --- > > (Updated Aug. 21, 2015, 3:35 p.m.) > > > Review request for KDE Frameworks, Plasma and KDE Usability. > > > Bugs: 351530 > https://bugs.kde.org/show_bug.cgi?id=351530 > > > Repository: kconfigwidgets > > > Description > --- > > This makes KColorScheme return Breeze colors by default, ie. choosing > "Default" in Colors KCM is no longer Oxygen. > > > Diffs > - > > src/kcolorscheme.cpp f1ec1e3 > > Diff: https://git.reviewboard.kde.org/r/124872/diff/ > > > Testing > --- > > Seems to look right, typos reserved :) > > Only thing missing now is the window decoration which is set in the WM > section of kdeglobals by the breeze.colors but KWin defaults to highlight > colors, so it stays blue. > > > Thanks, > > Kai Uwe Broulik > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124872: Default to Breeze colors
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124872/#review84166 --- Ship it! Ship It! - Jeremy Whiting On Aug. 21, 2015, 3:35 p.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124872/ > --- > > (Updated Aug. 21, 2015, 3:35 p.m.) > > > Review request for KDE Frameworks, Plasma and KDE Usability. > > > Bugs: 351530 > https://bugs.kde.org/show_bug.cgi?id=351530 > > > Repository: kconfigwidgets > > > Description > --- > > This makes KColorScheme return Breeze colors by default, ie. choosing > "Default" in Colors KCM is no longer Oxygen. > > > Diffs > - > > src/kcolorscheme.cpp f1ec1e3 > > Diff: https://git.reviewboard.kde.org/r/124872/diff/ > > > Testing > --- > > Seems to look right, typos reserved :) > > Only thing missing now is the window decoration which is set in the WM > section of kdeglobals by the breeze.colors but KWin defaults to highlight > colors, so it stays blue. > > > Thanks, > > Kai Uwe Broulik > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: knotifications tier
It should be auto generated every evening. The code that generates it is in kde:websites/quality-kde-org git repo. I spent a bit of time looking into how it all works for a gardening project (that I never did blog about results, mostly because I didn't make any final conclusions). I set up a local copy of what should be running on the server, but wasn't able to get the generation of documents to work quickly and put it back on the shelf. I think Allen Winter runs the actual vm that api.kde.org is hosted on if I remember right. He should be able to update it if it hasn't auto updated like it's supposed to lately. BR, Jeremy On Tue, Aug 4, 2015 at 10:02 AM, Martin Klapetek wrote: > On Tue, Aug 4, 2015 at 5:49 PM, Aleix Pol wrote: >> >> >> Maybe this should be updated? >> >> http://api.kde.org/frameworks-api/frameworks5-apidocs/knotifications/html/knotifications-dependencies.html > > > Yeah, this is old. How does on update? Is it not autogenerated? > > Cheers > -- > Martin Klapetek | KDE Developer > > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124156: KItemModels: new proxy KRearrangeColumnsProxyModel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124156/#review81703 --- Ship it! Ship It! - Jeremy Whiting On June 23, 2015, 5:33 a.m., David Faure wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124156/ > --- > > (Updated June 23, 2015, 5:33 a.m.) > > > Review request for KDE Frameworks. > > > Repository: kitemmodels > > > Description > --- > > It supports reordering and hiding columns from the source model. > > > Diffs > - > > autotests/CMakeLists.txt 4e604eeb6bd64529ec1fba983e3f58e2f8d0bd2c > autotests/krearrangecolumnsproxymodeltest.cpp PRE-CREATION > autotests/test_model_helpers.h PRE-CREATION > src/CMakeLists.txt dc7d5f04c650f8d21784f16f8d7676e5c74c93e1 > src/krearrangecolumnsproxymodel.h PRE-CREATION > src/krearrangecolumnsproxymodel.cpp PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/124156/diff/ > > > Testing > --- > > Wrote it for a customer who allowed me to keep copyright and publish it under > the LGPL. > > Unit-tested, and used in two real projects. > > > Thanks, > > David Faure > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Notes to developers: what KAboutData::setApplicationData() is
Jaroslaw,
On Thu, Jun 18, 2015 at 3:20 AM, Jaroslaw Staniek wrote:
> Hi
> If you look at apps ported to KF5, KAboutData::setApplicationData() is
> used but there are also redundant lines in main(), at least these:
>
> app.setApplicationName(aboutData.componentName());
> app.setApplicationDisplayName(aboutData.displayName());
> app.setOrganizationDomain(aboutData.organizationDomain());
> app.setApplicationVersion(aboutData.version());
>
> Note, this is already performed by KAboutData::setApplicationData().
That may be, but if using QApplication instead of KApplication they
are needed. See the note at
https://community.kde.org/Frameworks/Porting_Notes#Application Maybe
KAboutData::setApplicationData is not needed anymore instead or can
get it's names and other values from QApplication's accessors?
>
> For example Kate --
> http://lxr.kde.org/source/kde/applications/kate/kate/src/main.cpp
>
> For the list see
> http://lxr.kde.org/search?_filestring=&_string=setApplicationDisplayName
>
> Sometimes there are even deeper duplication of names, e.g. despite of
> using KAboutData there's also:
>
> QApplication::setApplicationName("kanagram");
>
> -- http://lxr.kde.org/source/kde/applications/kate/kate/src/main.cpp
>
> If I am right, this is a note for developers to fix that -- KAboutData
> was designed to make main() easier but actually main() looks
> unnecessary complicated for a number of KDE apps. Looks like people
> take another app's code as a template and copy it :)
>
> No idea if more general improvement could be an addition to the
> apidocs of a crazy check.
BR,
Jeremy
>
> --
> regards, Jaroslaw Staniek
>
> KDE:
> : A world-wide network of software engineers, artists, writers, translators
> : and facilitators committed to Free Software development - http://kde.org
> Calligra Suite:
> : A graphic art and office suite - http://calligra.org
> Kexi:
> : A visual database apps builder - http://calligra.org/kexi
> Qt Certified Specialist:
> : http://www.linkedin.com/in/jstaniek
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123692: autotests: Use QTEST_GUILESS_MAIN
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123692/#review81446 --- Ship it! This is making it run without a gui on linux fine. I also tested on OS X here, but the tests don't run here for some reason. It could be because it's creating .app files rather than directly creating a binary. If I run the test autotests/knewstuffauthortest.app/Contents/MacoOS/knewstuffauthortest it passes fine (even over ssh), but make test fails. - Jeremy Whiting On May 8, 2015, 1:15 p.m., Heiko Becker wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123692/ > --- > > (Updated May 8, 2015, 1:15 p.m.) > > > Review request for KDE Frameworks and Jeremy Whiting. > > > Repository: knewstuff > > > Description > --- > > The tests still work fine with it, allowing them to run without a > display server. > > > Diffs > - > > autotests/knewstuffauthortest.cpp 5ca7c4903e90a5b8bf377c3c12d5bbe7c0623002 > autotests/knewstuffentrytest.cpp 7862ebbbf7c6a913cb4d6d0b70b2edf151ec6327 > > Diff: https://git.reviewboard.kde.org/r/123692/diff/ > > > Testing > --- > > Built and ran the tests successfully. > > > Thanks, > > Heiko Becker > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Proposal: move KWalletManager inside KWallet framework
Then do like the rest of the projects do and branch 14.04 if that hasn't happened already... No? On Tue, May 26, 2015 at 3:56 PM, Valentin Rusu wrote: > * Albert Astals Cid [2015-05-26 23:52:18 +0200]: > >> El Dimarts, 26 de maig de 2015, a les 23:31:38, Valentin Rusu va escriure: >> > * Albert Astals Cid [2015-05-26 21:42:25 +0200]: >> > > El Dimarts, 26 de maig de 2015, a les 08:52:13, Valentin Rusu va >> > > escriure: >> > > > Hello, >> > > > >> > > > Since the release 15.04 I see more and more users puzzled about their >> > > > KDE Wallet set-up. For example, see this [1]. They have existing KDE4 >> > > > wallets which get migrated by the KF5::KWallet::kwalletd5 migration >> > > > agent, but have no means to look into/configure their migrated wallet, >> > > > as KWalletManager5 was not released. >> > > > >> > > > KWalletManager is now currently located in kdeutils and one needs to >> > > > build the *frameworks* branch to get KWalletManager5 that manages >> > > > kwalletd5. Packagers (e.g. Luca) tell me that's no possible to release >> > > > KWalletManager5 from there. >> > > > >> > > > So, I'd like to resubmit my old proposal: would that be possible to >> > > > include KWalletManager in KF5::KWallet, in the runtime part, next to >> > > > kwalletd. Or, if that's not possible, how should we handle this >> > > > KWalletManager problem? >> > > >> > > What about doing the obvious thing and releasing kwalletmanager5? >> > >> > That would be awesome, but Luca said it's not easy to release it from a >> > branch (the frameworks branch) hence my demand. >> >> Just merge it to master and get it released with KDE Applications 15.08 ? > > If I merge to master, I'll jeopardize the 14.xx version. If we're to > maintain bothe 14.xx and 15.xx lines, then we need these two branches. > > > -- > Valentin Rusu > IRC: valir > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123794: Implement "find previous" in KTextEdit.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123794/#review80365 --- Ship it! Nice! cache the options, switch direction, findNext, then unswitch directions. Looks good. - Jeremy Whiting On May 14, 2015, 3:59 p.m., David Faure wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123794/ > --- > > (Updated May 14, 2015, 3:59 p.m.) > > > Review request for KDE Frameworks and Laurent Montel. > > > Repository: ktextwidgets > > > Description > --- > > Implement "find previous" in KTextEdit. > > > Diffs > - > > src/widgets/ktextedit.h 17d446ac2cb1f08adb298fd1f02d09429352b32e > src/widgets/ktextedit.cpp 6bc22064efee68934afd0988bebedc5cce7e0488 > > Diff: https://git.reviewboard.kde.org/r/123794/diff/ > > > Testing > --- > > Ctrl+F and F3/shift+F3 in ktextedittest. > > > Thanks, > > David Faure > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123742: knewstuff: Add verbose ecm message when ECM isn't found.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123742/ --- (Updated May 14, 2015, 12:47 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Jeremy Whiting. Changes --- Submitted with commit 01c3f36cf657e0e7e68631e14f884de9a3b3ebcd by Jeremy Whiting to branch master. Repository: knewstuff Description --- Make ECM missing message explain a) what ECM is, and b) where to find it. Diffs - CMakeLists.txt cb23ccb8a9b0421a554b41234c3d9ced3965d378 Diff: https://git.reviewboard.kde.org/r/123742/diff/ Testing --- KNewStuff (and any other framework we add these changes to) now reports the ECM url and name when it isn't found at cmake time. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123742: knewstuff: Add verbose ecm message when ECM isn't found.
> On May 13, 2015, 7:10 a.m., Aleix Pol Gonzalez wrote: > > CMakeLists.txt, line 8 > > <https://git.reviewboard.kde.org/r/123742/diff/3/?file=368712#file368712line8> > > > > I insist, feature_sumary goes at the bottom. (and is already there) Is > > it needed to have it twice? > > Jeremy Whiting wrote: > Yes, otherwise we only get the generic cmake failure. Actually, let me > check... Maybe it only means we get a bunch of failures for the include calls > in addition to the verbose ECM message. Nope. If we don't add the extra feature_summary before we start including other stuff it looks like this with ECM missing which defeats the purpose of this change imo: CMake Warning at CMakeLists.txt:7 (find_package): Could not find a package configuration file provided by "ECM" (requested version 5.10.0) with any of the following names: ECMConfig.cmake ecm-config.cmake Add the installation prefix of "ECM" to CMAKE_PREFIX_PATH or set "ECM_DIR" to a directory containing one of the above files. If "ECM" provides a separate development package or SDK, be sure it has been installed. CMake Error at CMakeLists.txt:12 (include): include could not find load file: ECMSetupVersion CMake Error at CMakeLists.txt:13 (include): include could not find load file: ECMGenerateHeaders CMake Error at CMakeLists.txt:14 (include): include could not find load file: ECMPackageConfigHelpers CMake Error at CMakeLists.txt:15 (include): include could not find load file: KDEInstallDirs CMake Error at CMakeLists.txt:16 (include): include could not find load file: KDEFrameworkCompilerSettings CMake Error at CMakeLists.txt:17 (include): include could not find load file: KDECMakeSettings CMake Error at CMakeLists.txt:21 (ecm_setup_version): Unknown CMake command "ecm_setup_version". -- Configuring incomplete, errors occurred! See also "/home/jeremy/attica/build/CMakeFiles/CMakeOutput.log". - Jeremy --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123742/#review80299 --- On May 13, 2015, 7 a.m., Jeremy Whiting wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123742/ > ------- > > (Updated May 13, 2015, 7 a.m.) > > > Review request for KDE Frameworks and Jeremy Whiting. > > > Repository: knewstuff > > > Description > --- > > Make ECM missing message explain a) what ECM is, and b) where to find it. > > > Diffs > - > > CMakeLists.txt cb23ccb8a9b0421a554b41234c3d9ced3965d378 > > Diff: https://git.reviewboard.kde.org/r/123742/diff/ > > > Testing > --- > > KNewStuff (and any other framework we add these changes to) now reports the > ECM url and name when it isn't found at cmake time. > > > Thanks, > > Jeremy Whiting > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123742: knewstuff: Add verbose ecm message when ECM isn't found.
> On May 13, 2015, 7:10 a.m., Aleix Pol Gonzalez wrote: > > CMakeLists.txt, line 8 > > <https://git.reviewboard.kde.org/r/123742/diff/3/?file=368712#file368712line8> > > > > I insist, feature_sumary goes at the bottom. (and is already there) Is > > it needed to have it twice? Yes, otherwise we only get the generic cmake failure. Actually, let me check... Maybe it only means we get a bunch of failures for the include calls in addition to the verbose ECM message. - Jeremy --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123742/#review80299 --- On May 13, 2015, 7 a.m., Jeremy Whiting wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123742/ > --- > > (Updated May 13, 2015, 7 a.m.) > > > Review request for KDE Frameworks and Jeremy Whiting. > > > Repository: knewstuff > > > Description > --- > > Make ECM missing message explain a) what ECM is, and b) where to find it. > > > Diffs > - > > CMakeLists.txt cb23ccb8a9b0421a554b41234c3d9ced3965d378 > > Diff: https://git.reviewboard.kde.org/r/123742/diff/ > > > Testing > --- > > KNewStuff (and any other framework we add these changes to) now reports the > ECM url and name when it isn't found at cmake time. > > > Thanks, > > Jeremy Whiting > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123742: knewstuff: Add verbose ecm message when ECM isn't found.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123742/ --- (Updated May 13, 2015, 7 a.m.) Review request for KDE Frameworks and Jeremy Whiting. Changes --- Reordered lines as per Kevin's suggestion. I agree this looks a bit better. Repository: knewstuff Description --- Make ECM missing message explain a) what ECM is, and b) where to find it. Diffs (updated) - CMakeLists.txt cb23ccb8a9b0421a554b41234c3d9ced3965d378 Diff: https://git.reviewboard.kde.org/r/123742/diff/ Testing --- KNewStuff (and any other framework we add these changes to) now reports the ECM url and name when it isn't found at cmake time. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123742: knewstuff: Add verbose ecm message when ECM isn't found.
> On May 12, 2015, 7:41 p.m., Aleix Pol Gonzalez wrote: > > +1 > > > > I'd like to know other people's opinion on this, as this should end up on > > most frameworks. > > Personally I'm unsure that showing the url will enlighten people, but it's > > better that than the terribly verbose and useless cmake errors. It also shows the description and Extra cmake modules is much easier to Google than ecm. I have a script here to do this for all frameworks if we get a few more +1's - Jeremy --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123742/#review80270 ----------- On May 12, 2015, 6:28 p.m., Jeremy Whiting wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123742/ > --- > > (Updated May 12, 2015, 6:28 p.m.) > > > Review request for KDE Frameworks and Jeremy Whiting. > > > Repository: knewstuff > > > Description > --- > > Make ECM missing message explain a) what ECM is, and b) where to find it. > > > Diffs > - > > CMakeLists.txt cb23ccb8a9b0421a554b41234c3d9ced3965d378 > > Diff: https://git.reviewboard.kde.org/r/123742/diff/ > > > Testing > --- > > KNewStuff (and any other framework we add these changes to) now reports the > ECM url and name when it isn't found at cmake time. > > > Thanks, > > Jeremy Whiting > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123742: knewstuff: Add verbose ecm message when ECM isn't found.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123742/ --- (Updated May 12, 2015, 6:28 p.m.) Review request for KDE Frameworks and Jeremy Whiting. Repository: knewstuff Description (updated) --- Make ECM missing message explain a) what ECM is, and b) where to find it. Diffs (updated) - CMakeLists.txt cb23ccb8a9b0421a554b41234c3d9ced3965d378 Diff: https://git.reviewboard.kde.org/r/123742/diff/ Testing --- KNewStuff (and any other framework we add these changes to) now reports the ECM url and name when it isn't found at cmake time. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123742: knewstuff: Add verbose ecm message when ECM isn't found.
> On May 12, 2015, 4:49 p.m., Aleix Pol Gonzalez wrote: > > CMakeLists.txt, line 32 > > <https://git.reviewboard.kde.org/r/123742/diff/1/?file=368438#file368438line32> > > > > Do you think this is needed? It's REQUIRED anyway. Oops, I did this wrong, I'll update the patch in a bit at home. the point of the early feature summary is to explain what ecm is when it is missing. - Jeremy --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123742/#review80264 ------- On May 12, 2015, 3:19 p.m., Jeremy Whiting wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123742/ > --- > > (Updated May 12, 2015, 3:19 p.m.) > > > Review request for KDE Frameworks and Jeremy Whiting. > > > Repository: knewstuff > > > Description > --- > > Add verbose ecm message when ECM isn't found. > > > Diffs > - > > CMakeLists.txt cb23ccb8a9b0421a554b41234c3d9ced3965d378 > > Diff: https://git.reviewboard.kde.org/r/123742/diff/ > > > Testing > --- > > KNewStuff (and any other framework we add these changes to) now reports the > ECM url and name when it isn't found at cmake time. > > > Thanks, > > Jeremy Whiting > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 123742: knewstuff: Add verbose ecm message when ECM isn't found.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123742/ --- Review request for KDE Frameworks and Jeremy Whiting. Repository: knewstuff Description --- Add verbose ecm message when ECM isn't found. Diffs - CMakeLists.txt cb23ccb8a9b0421a554b41234c3d9ced3965d378 Diff: https://git.reviewboard.kde.org/r/123742/diff/ Testing --- KNewStuff (and any other framework we add these changes to) now reports the ECM url and name when it isn't found at cmake time. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kbuildsycoca5 crashing
\o/ KService built with a downgraded (4.9.1) g++ works fine. Sorry for the noise. Should be able to detect this sort of problem quickly in the future though. I'll stick with non testing arch for the time being. On Sun, May 10, 2015 at 10:07 AM, Jeremy Whiting wrote: > I only built kf5/kde applications. Though I've no idea what compiler > was used to build the Qt packages. probably g++ 4.9 from arch stable I > bet. /me removes testing, downgrades the dozen packages from it and > will rebuild. Thanks for the tips both of you. Hopefully I can finish > the 15.04.1 release tuesday from within a plasma 5 session instead of > this fallback gnome session :) (and have konversation running again > also...) > > thanks, > Jeremy > > On Sun, May 10, 2015 at 9:46 AM, Albert Astals Cid wrote: >> El Diumenge, 10 de maig de 2015, a les 08:57:28, Jeremy Whiting va escriure: >>> Also, none of the recent patches on >>> https://projects.archlinux.org/svntogit/packages.git/log/trunk?h=packages/qt >>> 5 make me nervous, all seem to be pretty straightforward. Could it be lower >>> level as in my glibc is too new, or the compiler itself (GCC 5.1.0) >> >> I hear nothing else than scary stories about people mixing stuff compiled >> with >> the new gcc and older versions, there's supposedly a switch that makes the >> abi >> be compatible, but the switch seems to be failing at properly make things >> compatible. >> >> I'd suggest to either recompile everything or to downgrade to old gcc. >> >> Cheers, >> Albert >> >>> >>> On Sun, May 10, 2015 at 8:54 AM, Jeremy Whiting wrote: >>> > I see. Some kde applications segfault (klettres, okular) other's run >>> > ok (dolphin, khangman) I haven't tried others. As for qt binaries I >>> > checked the binaries that come with the arch package, and assistant, >>> > designer, qdbusviewer all work fine. Is there one in particular I >>> > should check? >>> > >>> > On Sun, May 10, 2015 at 8:45 AM, David Faure wrote: >>> >> On Sunday 10 May 2015 08:24:48 Jeremy Whiting wrote: >>> >>> Rebuilt kservice (and nuked my build folder and /usr/local just to be >>> >>> doubly sure.) kbuildsycoca5 still crashes with this same backtrace, no >>> >>> idea why. Could it be a bug in QtCore? Arch testing packages of Qt? >>> >> >>> >> I doubt it. More likely a compiler bug or a BIC or a miscompile. >>> >> >>> >> Try running a few Qt examples from your Qt build, to at least make sure >>> >> that works. >>> >> >>> >>> 0x is -1, no? did it get decreased one too many times somehow? >>> >> >>> >> You don't understand. This isn't the value of the refcount, it's the >>> >> address in memory of the variable holding the refcount. >>> >> >>> >> Which means a serious mixup somewhere lowlevel (e.g. compiler). >>> >> >>> >> -- >>> >> David Faure, fa...@kde.org, http://www.davidfaure.fr >>> >> Working on KDE Frameworks 5 >>> >>> ___ >>> Kde-frameworks-devel mailing list >>> Kde-frameworks-devel@kde.org >>> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel >> ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kbuildsycoca5 crashing
I only built kf5/kde applications. Though I've no idea what compiler was used to build the Qt packages. probably g++ 4.9 from arch stable I bet. /me removes testing, downgrades the dozen packages from it and will rebuild. Thanks for the tips both of you. Hopefully I can finish the 15.04.1 release tuesday from within a plasma 5 session instead of this fallback gnome session :) (and have konversation running again also...) thanks, Jeremy On Sun, May 10, 2015 at 9:46 AM, Albert Astals Cid wrote: > El Diumenge, 10 de maig de 2015, a les 08:57:28, Jeremy Whiting va escriure: >> Also, none of the recent patches on >> https://projects.archlinux.org/svntogit/packages.git/log/trunk?h=packages/qt >> 5 make me nervous, all seem to be pretty straightforward. Could it be lower >> level as in my glibc is too new, or the compiler itself (GCC 5.1.0) > > I hear nothing else than scary stories about people mixing stuff compiled with > the new gcc and older versions, there's supposedly a switch that makes the abi > be compatible, but the switch seems to be failing at properly make things > compatible. > > I'd suggest to either recompile everything or to downgrade to old gcc. > > Cheers, > Albert > >> >> On Sun, May 10, 2015 at 8:54 AM, Jeremy Whiting wrote: >> > I see. Some kde applications segfault (klettres, okular) other's run >> > ok (dolphin, khangman) I haven't tried others. As for qt binaries I >> > checked the binaries that come with the arch package, and assistant, >> > designer, qdbusviewer all work fine. Is there one in particular I >> > should check? >> > >> > On Sun, May 10, 2015 at 8:45 AM, David Faure wrote: >> >> On Sunday 10 May 2015 08:24:48 Jeremy Whiting wrote: >> >>> Rebuilt kservice (and nuked my build folder and /usr/local just to be >> >>> doubly sure.) kbuildsycoca5 still crashes with this same backtrace, no >> >>> idea why. Could it be a bug in QtCore? Arch testing packages of Qt? >> >> >> >> I doubt it. More likely a compiler bug or a BIC or a miscompile. >> >> >> >> Try running a few Qt examples from your Qt build, to at least make sure >> >> that works. >> >> >> >>> 0x is -1, no? did it get decreased one too many times somehow? >> >> >> >> You don't understand. This isn't the value of the refcount, it's the >> >> address in memory of the variable holding the refcount. >> >> >> >> Which means a serious mixup somewhere lowlevel (e.g. compiler). >> >> >> >> -- >> >> David Faure, fa...@kde.org, http://www.davidfaure.fr >> >> Working on KDE Frameworks 5 >> >> ___ >> Kde-frameworks-devel mailing list >> Kde-frameworks-devel@kde.org >> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kbuildsycoca5 crashing
Also, none of the recent patches on https://projects.archlinux.org/svntogit/packages.git/log/trunk?h=packages/qt5 make me nervous, all seem to be pretty straightforward. Could it be lower level as in my glibc is too new, or the compiler itself (GCC 5.1.0) On Sun, May 10, 2015 at 8:54 AM, Jeremy Whiting wrote: > I see. Some kde applications segfault (klettres, okular) other's run > ok (dolphin, khangman) I haven't tried others. As for qt binaries I > checked the binaries that come with the arch package, and assistant, > designer, qdbusviewer all work fine. Is there one in particular I > should check? > > On Sun, May 10, 2015 at 8:45 AM, David Faure wrote: >> On Sunday 10 May 2015 08:24:48 Jeremy Whiting wrote: >>> Rebuilt kservice (and nuked my build folder and /usr/local just to be >>> doubly sure.) kbuildsycoca5 still crashes with this same backtrace, no >>> idea why. Could it be a bug in QtCore? Arch testing packages of Qt? >> >> I doubt it. More likely a compiler bug or a BIC or a miscompile. >> >> Try running a few Qt examples from your Qt build, to at least make sure that >> works. >> >>> 0x is -1, no? did it get decreased one too many times somehow? >> >> You don't understand. This isn't the value of the refcount, it's the address >> in memory of the variable holding the refcount. >> >> Which means a serious mixup somewhere lowlevel (e.g. compiler). >> >> -- >> David Faure, fa...@kde.org, http://www.davidfaure.fr >> Working on KDE Frameworks 5 >> ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kbuildsycoca5 crashing
I see. Some kde applications segfault (klettres, okular) other's run ok (dolphin, khangman) I haven't tried others. As for qt binaries I checked the binaries that come with the arch package, and assistant, designer, qdbusviewer all work fine. Is there one in particular I should check? On Sun, May 10, 2015 at 8:45 AM, David Faure wrote: > On Sunday 10 May 2015 08:24:48 Jeremy Whiting wrote: >> Rebuilt kservice (and nuked my build folder and /usr/local just to be >> doubly sure.) kbuildsycoca5 still crashes with this same backtrace, no >> idea why. Could it be a bug in QtCore? Arch testing packages of Qt? > > I doubt it. More likely a compiler bug or a BIC or a miscompile. > > Try running a few Qt examples from your Qt build, to at least make sure that > works. > >> 0x is -1, no? did it get decreased one too many times somehow? > > You don't understand. This isn't the value of the refcount, it's the address > in memory of the variable holding the refcount. > > Which means a serious mixup somewhere lowlevel (e.g. compiler). > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kbuildsycoca5 crashing
Rebuilt kservice (and nuked my build folder and /usr/local just to be doubly sure.) kbuildsycoca5 still crashes with this same backtrace, no idea why. Could it be a bug in QtCore? Arch testing packages of Qt? 0x is -1, no? did it get decreased one too many times somehow? On Sun, May 10, 2015 at 8:04 AM, David Faure wrote: > On Sunday 10 May 2015 07:49:48 Jeremy Whiting wrote: >> ==2883== Address 0x is not stack'd, malloc'd or (recently) free'd > > This must be a miscompilation, I see no other reason for the refcount of a > QByteArray to be at address 0x. > Try rebuilding kservice from scratch. > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kbuildsycoca5 crashing
Also, while this is happening I did a package upgrade to see if it's a Qt packaging problem. I got another update of Qt packages from the arch repo (5.4.1-6 now) But I still get the same issues (kbuildsycoca5 crash and login dbus issue). I'll start a fresh rebuild and look later today I guess. BR, Jeremy On Sun, May 10, 2015 at 7:49 AM, Jeremy Whiting wrote: > Yep, it's Qt5. After rebuilding everything trying to log into a plasma > session I get "startkde: could not sync environment to dbus" in > .xsession-errors, not much before that besides a bad dbus call. Seems > very similar to https://bugzilla.redhat.com/show_bug.cgi?id=1191171 > > I've never thought valgrind would help much with a crashing > application, but here's the log of that. Nothing obvious jumping out > at me anyway: > > [jeremy@chrom ~]$ ldd /usr/local/bin/kbuildsycoca5 > linux-vdso.so.1 (0x7ffda46b) > libKF5Service.so.5 => /usr/local/lib/libKF5Service.so.5 (0x7f37ad81) > libKF5Crash.so.5 => /usr/local/lib/libKF5Crash.so.5 (0x7f37ad608000) > libKF5CoreAddons.so.5 => /usr/local/lib/libKF5CoreAddons.so.5 > (0x7f37ad367000) > libKF5I18n.so.5 => /usr/local/lib/libKF5I18n.so.5 (0x7f37ad11b000) > libQt5Xml.so.5 => /usr/lib/libQt5Xml.so.5 (0x7f37adc44000) > libKF5ConfigCore.so.5 => /usr/local/lib/libKF5ConfigCore.so.5 > (0x7f37acead000) > libQt5DBus.so.5 => /usr/lib/libQt5DBus.so.5 (0x7f37adbc2000) > libQt5Core.so.5 => /usr/lib/libQt5Core.so.5 (0x7f37ac9db000) > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f37ac659000) > libm.so.6 => /usr/lib/libm.so.6 (0x7f37ac355000) > libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f37ac13f000) > libc.so.6 => /usr/lib/libc.so.6 (0x7f37abd9d000) > libKF5DBusAddons.so.5 => /usr/local/lib/libKF5DBusAddons.so.5 > (0x7f37abb86000) > libKF5WindowSystem.so.5 => /usr/local/lib/libKF5WindowSystem.so.5 > (0x7f37ab916000) > libQt5X11Extras.so.5 => /usr/lib/libQt5X11Extras.so.5 (0x7f37adbbb000) > libSM.so.6 => /usr/lib/libSM.so.6 (0x7f37ab70e000) > libICE.so.6 => /usr/lib/libICE.so.6 (0x7f37ab4f1000) > libX11.so.6 => /usr/lib/libX11.so.6 (0x7f37ab1af000) > libXext.so.6 => /usr/lib/libXext.so.6 (0x7f37aaf9d000) > libQt5Widgets.so.5 => /usr/lib/libQt5Widgets.so.5 (0x7f37aa8fd000) > libQt5Gui.so.5 => /usr/lib/libQt5Gui.so.5 (0x7f37aa3b5000) > libfam.so.0 => /usr/lib/libfam.so.0 (0x7f37aa1ae000) > libpthread.so.0 => /usr/lib/libpthread.so.0 (0x7f37a9f91000) > libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x7f37a9d48000) > libz.so.1 => /usr/lib/libz.so.1 (0x7f37a9b32000) > libicui18n.so.55 => /usr/lib/libicui18n.so.55 (0x7f37a96cc000) > libicuuc.so.55 => /usr/lib/libicuuc.so.55 (0x7f37a9339000) > libpcre16.so.0 => /usr/lib/libpcre16.so.0 (0x7f37a90d4000) > libdl.so.2 => /usr/lib/libdl.so.2 (0x7f37a8ed) > libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x7f37a8bc2000) > librt.so.1 => /usr/lib/librt.so.1 (0x7f37a89ba000) > libsystemd.so.0 => /usr/lib/libsystemd.so.0 (0x7f37adb8c000) > /lib64/ld-linux-x86-64.so.2 (0x7f37ada9d000) > libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x7f37a87b4000) > libXrender.so.1 => /usr/lib/libXrender.so.1 (0x7f37a85aa000) > libxcb.so.1 => /usr/lib/libxcb.so.1 (0x7f37a8388000) > libxcb-keysyms.so.1 => /usr/lib/libxcb-keysyms.so.1 (0x7f37a8185000) > libuuid.so.1 => /usr/lib/libuuid.so.1 (0x7f37a7f8) > libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x7f37a7d2f000) > libpng16.so.16 => /usr/lib/libpng16.so.16 (0x7f37a7af9000) > libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0x7f37a789c000) > libGL.so.1 => /usr/lib/libGL.so.1 (0x7f37a760) > libicudata.so.55 => /usr/lib/libicudata.so.55 (0x7f37a5b4a000) > libpcre.so.1 => /usr/lib/libpcre.so.1 (0x7f37a58da000) > libcap.so.2 => /usr/lib/libcap.so.2 (0x7f37a56d6000) > liblzma.so.5 => /usr/lib/liblzma.so.5 (0x7f37a54b) > liblz4.so.1 => /usr/lib/liblz4.so.1 (0x7f37a52a5000) > libgcrypt.so.20 => /usr/lib/libgcrypt.so.20 (0x7f37a4fc4000) > libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x7f37a4db1000) > libresolv.so.2 => /usr/lib/libresolv.so.2 (0x7f37a4b9a000) > libXau.so.6 => /usr/lib/libXau.so.6 (0x7f37a4996000) > libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x7f37a479) > libffi.so.6 => /usr/lib/libffi.so.6 (0x7f37a4587000) > libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x7f37a42ca000) > libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0x7f37a40ac000) > libexpat.so.1 => /usr/lib/libexpat.so.1 (0x7
Re: kbuildsycoca5 crashing
Yep, it's Qt5. After rebuilding everything trying to log into a plasma session I get "startkde: could not sync environment to dbus" in .xsession-errors, not much before that besides a bad dbus call. Seems very similar to https://bugzilla.redhat.com/show_bug.cgi?id=1191171 I've never thought valgrind would help much with a crashing application, but here's the log of that. Nothing obvious jumping out at me anyway: [jeremy@chrom ~]$ ldd /usr/local/bin/kbuildsycoca5 linux-vdso.so.1 (0x7ffda46b) libKF5Service.so.5 => /usr/local/lib/libKF5Service.so.5 (0x7f37ad81) libKF5Crash.so.5 => /usr/local/lib/libKF5Crash.so.5 (0x7f37ad608000) libKF5CoreAddons.so.5 => /usr/local/lib/libKF5CoreAddons.so.5 (0x7f37ad367000) libKF5I18n.so.5 => /usr/local/lib/libKF5I18n.so.5 (0x7f37ad11b000) libQt5Xml.so.5 => /usr/lib/libQt5Xml.so.5 (0x7f37adc44000) libKF5ConfigCore.so.5 => /usr/local/lib/libKF5ConfigCore.so.5 (0x7f37acead000) libQt5DBus.so.5 => /usr/lib/libQt5DBus.so.5 (0x7f37adbc2000) libQt5Core.so.5 => /usr/lib/libQt5Core.so.5 (0x7f37ac9db000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f37ac659000) libm.so.6 => /usr/lib/libm.so.6 (0x7f37ac355000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f37ac13f000) libc.so.6 => /usr/lib/libc.so.6 (0x7f37abd9d000) libKF5DBusAddons.so.5 => /usr/local/lib/libKF5DBusAddons.so.5 (0x7f37abb86000) libKF5WindowSystem.so.5 => /usr/local/lib/libKF5WindowSystem.so.5 (0x7f37ab916000) libQt5X11Extras.so.5 => /usr/lib/libQt5X11Extras.so.5 (0x7f37adbbb000) libSM.so.6 => /usr/lib/libSM.so.6 (0x7f37ab70e000) libICE.so.6 => /usr/lib/libICE.so.6 (0x7f37ab4f1000) libX11.so.6 => /usr/lib/libX11.so.6 (0x7f37ab1af000) libXext.so.6 => /usr/lib/libXext.so.6 (0x7f37aaf9d000) libQt5Widgets.so.5 => /usr/lib/libQt5Widgets.so.5 (0x7f37aa8fd000) libQt5Gui.so.5 => /usr/lib/libQt5Gui.so.5 (0x7f37aa3b5000) libfam.so.0 => /usr/lib/libfam.so.0 (0x7f37aa1ae000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x7f37a9f91000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x7f37a9d48000) libz.so.1 => /usr/lib/libz.so.1 (0x7f37a9b32000) libicui18n.so.55 => /usr/lib/libicui18n.so.55 (0x7f37a96cc000) libicuuc.so.55 => /usr/lib/libicuuc.so.55 (0x7f37a9339000) libpcre16.so.0 => /usr/lib/libpcre16.so.0 (0x7f37a90d4000) libdl.so.2 => /usr/lib/libdl.so.2 (0x7f37a8ed) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x7f37a8bc2000) librt.so.1 => /usr/lib/librt.so.1 (0x7f37a89ba000) libsystemd.so.0 => /usr/lib/libsystemd.so.0 (0x7f37adb8c000) /lib64/ld-linux-x86-64.so.2 (0x7f37ada9d000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x7f37a87b4000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x7f37a85aa000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x7f37a8388000) libxcb-keysyms.so.1 => /usr/lib/libxcb-keysyms.so.1 (0x7f37a8185000) libuuid.so.1 => /usr/lib/libuuid.so.1 (0x7f37a7f8) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x7f37a7d2f000) libpng16.so.16 => /usr/lib/libpng16.so.16 (0x7f37a7af9000) libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0x7f37a789c000) libGL.so.1 => /usr/lib/libGL.so.1 (0x7f37a760) libicudata.so.55 => /usr/lib/libicudata.so.55 (0x7f37a5b4a000) libpcre.so.1 => /usr/lib/libpcre.so.1 (0x7f37a58da000) libcap.so.2 => /usr/lib/libcap.so.2 (0x7f37a56d6000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x7f37a54b) liblz4.so.1 => /usr/lib/liblz4.so.1 (0x7f37a52a5000) libgcrypt.so.20 => /usr/lib/libgcrypt.so.20 (0x7f37a4fc4000) libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x7f37a4db1000) libresolv.so.2 => /usr/lib/libresolv.so.2 (0x7f37a4b9a000) libXau.so.6 => /usr/lib/libXau.so.6 (0x7f37a4996000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x7f37a479) libffi.so.6 => /usr/lib/libffi.so.6 (0x7f37a4587000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x7f37a42ca000) libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0x7f37a40ac000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x7f37a3e82000) libglapi.so.0 => /usr/lib/libglapi.so.0 (0x7f37a3c57000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x7f37a3a54000) libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0x7f37a3852000) libxcb-glx.so.0 => /usr/lib/libxcb-glx.so.0 (0x7f37a3638000) libxcb-dri2.so.0 => /usr/lib/libxcb-dri2.so.0 (0x7f37a3433000) libxcb-dri3.so.0 => /usr/lib/libxcb-dri3.so.0 (0x7f37a323) libxcb-present.so.0 => /usr/lib/libxcb-present.so.0 (0x7f37a302d000) libxcb-randr.so.0 => /usr/lib/libxcb-randr.so.0 (0x7f37a2e1f000) libxcb-xfixes.so.0 => /usr/lib/libxcb-xfixes.so.0 (0x7f37a2c17000) libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0x7f37a2a0d000) libxcb-shape.so.0 => /usr/lib/libxcb-shape.so.0 (0x7f37a2809000) libxcb-sync.so.1 => /usr/lib/libxcb-sync.so.1 (0x7f37a2602000) libxshmfence.so.1 => /usr/lib/libxshmfence.so.1 (0x7f37a23ff000) libXxf86vm.so.1 => /usr/lib/libX
Re: kbuildsycoca5 crashing
It sure isn't. I've also tried nuking ~/.cache/ksycoca5* and such. Same result. ~/.cache is owned by me and has decent permissions also. On Sun, May 10, 2015 at 6:21 AM, Bhushan Shah wrote: > On Sun, May 10, 2015 at 5:43 PM, Jeremy Whiting wrote: >> Somehow kbuildsycoca5 is crashing here lately. I nuked my whole kde >> prefix (/usr/local) and rebuilt with packaged qt from my distro >> (arch). But kbuildsycoca5 is crashing every time I run it with some >> issue in QByteArray. Has anyone seen this lately/before or know how I >> can get past it? One of my config files broken or something? (I miss >> the days of ~/.kde where I could move that out of the way to figure >> out issues like this...) Here's a backtrace of the crash. Currently >> running in a gnome terminal in a gnome session to test and such while >> the rest of kde builds... > > > Is your /home/jeremy/.cache/ksycoca5 owned by root or something? > > -- > Bhushan Shah > > http://bhush9.github.io > IRC Nick : bshah on Freenode > >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
kbuildsycoca5 crashing
Hey all,
Somehow kbuildsycoca5 is crashing here lately. I nuked my whole kde
prefix (/usr/local) and rebuilt with packaged qt from my distro
(arch). But kbuildsycoca5 is crashing every time I run it with some
issue in QByteArray. Has anyone seen this lately/before or know how I
can get past it? One of my config files broken or something? (I miss
the days of ~/.kde where I could move that out of the way to figure
out issues like this...) Here's a backtrace of the crash. Currently
running in a gnome terminal in a gnome session to test and such while
the rest of kde builds...
[jeremy@chrom ~]$ kbuildsycoca5
Could not find drkonqi at /usr/local/lib/libexec/drkonqi
QDBusConnection: session D-Bus connection created before
QCoreApplication. Application may misbehave.
kbuildsycoca5 running...
kf5.kservice.sycoca: Trying to open ksycoca from "/home/jeremy/.cache/ksycoca5"
kf5.kservice.sycoca: Trying to open global ksycoca from
"/home/jeremy/.local/share/kservices5/ksycoca5"
kf5.kservice.sycoca: Trying to open ksycoca from "/home/jeremy/.cache/ksycoca5"
kf5.kservice.sycoca: Trying to open global ksycoca from
"/home/jeremy/.local/share/kservices5/ksycoca5"
kf5.kservice.sycoca: Trying to open ksycoca from "/home/jeremy/.cache/ksycoca5"
kf5.kservice.sycoca: Trying to open global ksycoca from
"/home/jeremy/.local/share/kservices5/ksycoca5"
Recreating ksycoca file ("/home/jeremy/.cache/ksycoca5", version 300)
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = kbuildsycoca5 path = /usr/local/bin pid = 30152
KCrash: Arguments: /usr/local/bin/kbuildsycoca5
Segmentation fault (core dumped)
[jeremy@chrom ~]$ gdb kbuildsycoca5
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Re: Versioning of Frameworks
Christian, David isn't the only one with these thoughts. I agree with everything he said, and was thinking about the dependency zoo also, but couldn't form the words until I read what he wrote. That's exactly what I was thinking. It would be like the old rpm dependency hell from early linux days all over again, but within our community only. BR, Jeremy On Wed, Apr 29, 2015 at 12:34 PM, David Faure wrote: > On Tuesday 28 April 2015 12:17:00 Christian Mollekopf wrote: >> Our dependency tree is now indeed reduced, but if we want to update a >> single library, we are forced to update all libraries, due to the >> version-lock caused by periodic bumping of dependencies. > > You say at the end of the mail that you are using (or you plan to use only) 6 > frameworks. Having to update 6 frameworks together doesn't seem like a huge > amount of work to me. > > OK, 11, when including the PIM modules which AFAIU aim at becoming frameworks. > >> Similarly, requirements are bumped as the requirements increase, making it >> entirely possible that some low-level libraries can remain the same while >> others are updated. > > This would lead to an awful "version zoo". > KIO 5.7 requires KXMLGui 5.5 and KCoreAddons 5.4, but actually KXMLGui 5.5 > requires KCoreAddons 5.5 so overall KCoreAddons 5.5 is required, etc. etc. > Multiply this by 64 frameworks and you have a horrible confusion for everyone > everywhere. > >> I think our requirements can be split into two parts: >> * No automatic version-bumping of dependencies: This harms us the most >> because it forces us to update everything when updating something. It's >> not a problem in Tier1 frameworks, but I've seen some doing it (khtml), >> so I hope it's not a policy and we can do it differently in PIM. > > Everything under frameworks/ is released together and with the same version > number. This includes any PIM-related frameworks. > On the other hand if you mean PIM-related stuff outside of frameworks/, then > they will have a different release schedule and therefore a different > versioning scheme I assume. > >> * A version number that follows changes and not time: As I understand >> version numbers are currently bumped periodically because we anyways >> lack the manpower for release-management, and since changes usually >> happen, the version is just periodically bumped before each release. >> This seems to prevent release-management to happen though, where the >> version number is a vital tool for planning what ends up in what >> version. So my question would be whether we could move certain >> frameworks from that time-boxing model to a feature-boxing model, >> allowing the releases to be somewhat planned. > > The whole point of the monthly release cycle is that bugfixes see the light of > day in the coming month, not 6 months later. > So if we cannot release a new version because no new feature happened (is this > what you mean?), it would break this concept. Or if you mean releasing but > with a different version number depending on whether there were only bugfixes > or also features, then I have to disagree for many reasons, including > - the version zoo mentionned above > - the lack of a clear-cut line between bugfixes and features > - the need for a manual decision in 62 frameworks > - the fact that the workflow for frameworks (master always stable and > releasable) does not require a distinction between bugfixes and features, like > the KDE4 workflow required. > >> I assume the current versioning is happening so noone has to maintain >> the individual version-numbers > > That is one reason, but not the only reason. Making the release dude's life > (i.e. my life) harder is one thing I'll fight against, but the other reason is > that a version zoo also makes things harder for everyone else: packagers, > developers and users. > >> Initially I'd like to stop the automatic dependency bumping, the rest >> can IMO wait some more, that's something that can be solved on the PIM >> side, but I need to know if there are policies regarding that, or if >> some frameworks just choose to do that out of laziness (aka lack of >> manpower). >> The release-management I'd try first on kimap, which is not yet a >> framework, and where I'm maintainer, so my question would be whether you >> somehow rely on all frameworks have the same version, and how we could >> fix that. > > I'm confused by what you're saying here. If it's not a framework, it's not a > framework, you can release whichever way you want. But once it's a framework, > it will be released like everything else, with automatic version number > increases. > >> If it goes well with kimap, I'd then just approach the >> individual maintainers. > > There is no point in doing that. They don't release the frameworks. > I do. I release them all. > >> * PIM (not yet part of frameworks) >> ** KCalendarCore >> ** KCalendarUtils >> ** KMIME >> ** KIMAP >> ** KContacts >> >> * Current Frameworks >> ** ECM >> ** KCoreAddons >> ** KC
Re: Review Request 123421: [KNewStuff] Use KDE_INSTALL_DATADIR_KF5 instead of DATA_INSTALL_DIR for future co-installability
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123421/#review79181 --- This looks right to me, but it's Gregor's stuff (KMoreTools) so I'll let him weigh in. It may require the users of KMoreTools to update their code I believe. - Jeremy Whiting On April 18, 2015, 1:45 p.m., Hrvoje Senjan wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123421/ > --- > > (Updated April 18, 2015, 1:45 p.m.) > > > Review request for KDE Frameworks, Gregor Mi and Jeremy Whiting. > > > Repository: knewstuff > > > Description > --- > > Like it's done with the rest of the frameworks. > > > Diffs > - > > data/CMakeLists.txt 32d39ab > src/kmoretools/kmoretools.h 89e75b5 > src/kmoretools/kmoretools.cpp 27a0f74 > > Diff: https://git.reviewboard.kde.org/r/123421/diff/ > > > Testing > --- > > > Thanks, > > Hrvoje Senjan > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123335: Fix native file dialogs from widgets QFileDialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123335/#review79085 --- Ship it! Ship It! - Jeremy Whiting On April 12, 2015, 3:20 a.m., David Rosca wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123335/ > --- > > (Updated April 12, 2015, 3:20 a.m.) > > > Review request for KDE Frameworks, David Faure and Lukáš Tinkl. > > > Repository: frameworkintegration > > > Description > --- > > 9814e4b773b2b34afafa0c5d242594bbb4f9a6ae fixed QML file dialogs but broke > QtWidgets dialogs. > > QFileDialog static functions - dialog would open, but any user interaction is > blocked (cannot select files or click on anything). > QFileDialog *d = new QFileDialog(parent); d->open(); - dialog would not open > at all > > The first issue occurs because exec() is called on already shown dialog. This > is fixed by explicit hide() before calling exec() - kind of hacky :/ > The second issue is fixed by always calling show(). > > > Diffs > - > > autotests/CMakeLists.txt 00e4a41 > autotests/kfiledialog_unittest.cpp 45a139a > autotests/kfiledialogqml_unittest.cpp PRE-CREATION > autotests/qml/filedialog_parentless.qml PRE-CREATION > autotests/qml/filedialog_withparent.qml PRE-CREATION > src/platformtheme/kdeplatformfiledialoghelper.cpp 92ab107 > > Diff: https://git.reviewboard.kde.org/r/123335/diff/ > > > Testing > --- > > QML dialogs: > example from bug 334963 works fine > file dialog from plasma desktop settings -> wallpapers works fine > > QtWidgets dialogs: > static dialogs from qtbase/examples/widgets/dialogs/standarddialogs works fine > QFileDialog *d = new QFileDialog(parent); d->open(); works fine > test app: https://paste.kde.org/psddcng5n > > I'm running Qt 5.4.1. > > Are there any other types of dialogs that I forgot (and possibly broke)? > > > Thanks, > > David Rosca > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122910: Introduce KMoreTools
> On April 15, 2015, 2:39 p.m., Jeremy Whiting wrote: > > Ship It! > > Gregor Mi wrote: > > As KMoreTools is going to be part of KNewStuff it should be using > KNEWSTUFF_EXPORT not KSERVICE_EXPORT. > > The install dir now looks like this: > http://wstaw.org/m/2015/04/15/plasma-desktopVd2099.png I wonder if this ok to > have a duplicate knewstuff_export.h? Or should the files go into the > "kns3/KNS3" subdirectory? Good point, using one knewstuff_export.h file would be ideal indeed. - Jeremy --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122910/#review78995 --- On April 15, 2015, 2:24 p.m., Gregor Mi wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122910/ > --- > > (Updated April 15, 2015, 2:24 p.m.) > > > Review request for KDE Frameworks and Jeremy Whiting. > > > Repository: knewstuff > > > Description > --- > > Moved from kservice (https://git.reviewboard.kde.org/r/122576/) to here > (knewstuff). > > Example usages: > - dolphin's SpaceInfoToolsMenu: https://git.reviewboard.kde.org/r/122911/ > - kate's project addin: https://git.reviewboard.kde.org/r/122374/ > - ksnapshot's SendTo menu: https://git.reviewboard.kde.org/r/123342/ - Note, > that here the "Not installed" functionality is not used at all. But this > use-case takes advantage of the built-in "Configure menu" feature. > > > Diffs > - > > docs/pics/kmoretools-kate-project-1-all-installed.png PRE-CREATION > docs/pics/kmoretools-kate-project-2-two-not-installed.png PRE-CREATION > docs/pics/kmoretools-kate-project-3-config-dialog-all-installed.png > PRE-CREATION > src/CMakeLists.txt 3b9a403eb473e0c3760506b2757c71d603b99775 > src/kmoretools/kmoretools.h PRE-CREATION > src/kmoretools/kmoretools.cpp PRE-CREATION > src/kmoretools/kmoretools_p.h PRE-CREATION > src/kmoretools/kmoretoolsconfigdialog_p.h PRE-CREATION > src/kmoretools/kmoretoolsconfigdialog_p.cpp PRE-CREATION > src/kmoretools/ui/kmoretoolsconfigwidget.ui PRE-CREATION > tests/CMakeLists.txt 103c5fc98deaf83288b843cc66a87f2d95ad9dfb > tests/kmoretools/1/a.desktop PRE-CREATION > tests/kmoretools/1/b.desktop PRE-CREATION > tests/kmoretools/1/c.desktop PRE-CREATION > tests/kmoretools/2/kate.desktop PRE-CREATION > tests/kmoretools/2/kate.png PRE-CREATION > tests/kmoretools/2/mynotinstalledapp.desktop PRE-CREATION > tests/kmoretools/2/mynotinstalledapp.png PRE-CREATION > tests/kmoretools/2/mynotinstapp2.desktop PRE-CREATION > tests/kmoretools/kmoretoolstest.cpp PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/122910/diff/ > > > Testing > --- > > > Thanks, > > Gregor Mi > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122910: Introduce KMoreTools
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122910/#review78995 --- Ship it! Ship It! - Jeremy Whiting On April 15, 2015, 2:24 p.m., Gregor Mi wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122910/ > --- > > (Updated April 15, 2015, 2:24 p.m.) > > > Review request for KDE Frameworks and Jeremy Whiting. > > > Repository: knewstuff > > > Description > --- > > Moved from kservice (https://git.reviewboard.kde.org/r/122576/) to here > (knewstuff). > > Example usages: > - dolphin's SpaceInfoToolsMenu: https://git.reviewboard.kde.org/r/122911/ > - kate's project addin: https://git.reviewboard.kde.org/r/122374/ > - ksnapshot's SendTo menu: https://git.reviewboard.kde.org/r/123342/ - Note, > that here the "Not installed" functionality is not used at all. But this > use-case takes advantage of the built-in "Configure menu" feature. > > > Diffs > - > > docs/pics/kmoretools-kate-project-1-all-installed.png PRE-CREATION > docs/pics/kmoretools-kate-project-2-two-not-installed.png PRE-CREATION > docs/pics/kmoretools-kate-project-3-config-dialog-all-installed.png > PRE-CREATION > src/CMakeLists.txt 3b9a403eb473e0c3760506b2757c71d603b99775 > src/kmoretools/kmoretools.h PRE-CREATION > src/kmoretools/kmoretools.cpp PRE-CREATION > src/kmoretools/kmoretools_p.h PRE-CREATION > src/kmoretools/kmoretoolsconfigdialog_p.h PRE-CREATION > src/kmoretools/kmoretoolsconfigdialog_p.cpp PRE-CREATION > src/kmoretools/ui/kmoretoolsconfigwidget.ui PRE-CREATION > tests/CMakeLists.txt 103c5fc98deaf83288b843cc66a87f2d95ad9dfb > tests/kmoretools/1/a.desktop PRE-CREATION > tests/kmoretools/1/b.desktop PRE-CREATION > tests/kmoretools/1/c.desktop PRE-CREATION > tests/kmoretools/2/kate.desktop PRE-CREATION > tests/kmoretools/2/kate.png PRE-CREATION > tests/kmoretools/2/mynotinstalledapp.desktop PRE-CREATION > tests/kmoretools/2/mynotinstalledapp.png PRE-CREATION > tests/kmoretools/2/mynotinstapp2.desktop PRE-CREATION > tests/kmoretools/kmoretoolstest.cpp PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/122910/diff/ > > > Testing > --- > > > Thanks, > > Gregor Mi > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122910: Introduce KMoreTools
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122910/#review78941 --- As KMoreTools is going to be part of KNewStuff it should be using KNEWSTUFF_EXPORT not KSERVICE_EXPORT. I'd also prefer the classes to be separated into their own header files, but that's a style thing, up to you. - Jeremy Whiting On April 12, 2015, 5:54 a.m., Gregor Mi wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122910/ > --- > > (Updated April 12, 2015, 5:54 a.m.) > > > Review request for KDE Frameworks and Jeremy Whiting. > > > Repository: knewstuff > > > Description > --- > > Moved from kservice (https://git.reviewboard.kde.org/r/122576/) to here > (knewstuff). > > Example usages: > - dolphin's SpaceInfoToolsMenu: https://git.reviewboard.kde.org/r/122911/ > - kate's project addin: https://git.reviewboard.kde.org/r/122374/ > - ksnapshot's SendTo menu: https://git.reviewboard.kde.org/r/123342/ - Note, > that here the "Not installed" functionality is not used at all. But this > use-case takes advantage of the built-in "Configure menu" feature. > > > Diffs > - > > docs/pics/kmoretools-kate-project-1-all-installed.png PRE-CREATION > docs/pics/kmoretools-kate-project-2-two-not-installed.png PRE-CREATION > docs/pics/kmoretools-kate-project-3-config-dialog-all-installed.png > PRE-CREATION > src/CMakeLists.txt 3b9a403eb473e0c3760506b2757c71d603b99775 > src/kmoretools/kmoretools.h PRE-CREATION > src/kmoretools/kmoretools.cpp PRE-CREATION > src/kmoretools/kmoretools_p.h PRE-CREATION > src/kmoretools/kmoretoolsconfigdialog_p.h PRE-CREATION > src/kmoretools/kmoretoolsconfigdialog_p.cpp PRE-CREATION > src/kmoretools/ui/kmoretoolsconfigwidget.ui PRE-CREATION > tests/CMakeLists.txt 103c5fc98deaf83288b843cc66a87f2d95ad9dfb > tests/kmoretools/1/a.desktop PRE-CREATION > tests/kmoretools/1/b.desktop PRE-CREATION > tests/kmoretools/1/c.desktop PRE-CREATION > tests/kmoretools/2/kate.desktop PRE-CREATION > tests/kmoretools/2/kate.png PRE-CREATION > tests/kmoretools/2/mynotinstalledapp.desktop PRE-CREATION > tests/kmoretools/2/mynotinstalledapp.png PRE-CREATION > tests/kmoretools/2/mynotinstapp2.desktop PRE-CREATION > tests/kmoretools/kmoretoolstest.cpp PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/122910/diff/ > > > Testing > --- > > > Thanks, > > Gregor Mi > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123335: Fix native file dialogs from widgets QFileDialog
> On April 12, 2015, 10:43 a.m., Jeremy Whiting wrote: > > Looks good to me. The explanation makes sense also. I did see most dialogs > > working after Lukas' fix, but the one launched from chromium via kdialog > > still hung after that. This should fix that (I'll test it later today) Yep, chromium's file upload is now at last interactive again \o/. It uses kdialog and hasn't been interactive since I switched to plasma 5 a while ago. Thanks for the fix. - Jeremy --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123335/#review78864 --- On April 12, 2015, 3:20 a.m., David Rosca wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123335/ > --- > > (Updated April 12, 2015, 3:20 a.m.) > > > Review request for KDE Frameworks, David Faure and Lukáš Tinkl. > > > Repository: frameworkintegration > > > Description > --- > > 9814e4b773b2b34afafa0c5d242594bbb4f9a6ae fixed QML file dialogs but broke > QtWidgets dialogs. > > QFileDialog static functions - dialog would open, but any user interaction is > blocked (cannot select files or click on anything). > QFileDialog *d = new QFileDialog(parent); d->open(); - dialog would not open > at all > > The first issue occurs because exec() is called on already shown dialog. This > is fixed by explicit hide() before calling exec() - kind of hacky :/ > The second issue is fixed by always calling show(). > > > Diffs > - > > autotests/CMakeLists.txt 00e4a41 > autotests/kfiledialog_unittest.cpp 45a139a > autotests/kfiledialogqml_unittest.cpp PRE-CREATION > autotests/qml/filedialog_parentless.qml PRE-CREATION > autotests/qml/filedialog_withparent.qml PRE-CREATION > src/platformtheme/kdeplatformfiledialoghelper.cpp 92ab107 > > Diff: https://git.reviewboard.kde.org/r/123335/diff/ > > > Testing > --- > > QML dialogs: > example from bug 334963 works fine > file dialog from plasma desktop settings -> wallpapers works fine > > QtWidgets dialogs: > static dialogs from qtbase/examples/widgets/dialogs/standarddialogs works fine > QFileDialog *d = new QFileDialog(parent); d->open(); works fine > test app: https://paste.kde.org/psddcng5n > > I'm running Qt 5.4.1. > > Are there any other types of dialogs that I forgot (and possibly broke)? > > > Thanks, > > David Rosca > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123335: Fix native file dialogs from widgets QFileDialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123335/#review78864 --- Looks good to me. The explanation makes sense also. I did see most dialogs working after Lukas' fix, but the one launched from chromium via kdialog still hung after that. This should fix that (I'll test it later today) - Jeremy Whiting On April 12, 2015, 3:20 a.m., David Rosca wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123335/ > --- > > (Updated April 12, 2015, 3:20 a.m.) > > > Review request for KDE Frameworks, David Faure and Lukáš Tinkl. > > > Repository: frameworkintegration > > > Description > --- > > 9814e4b773b2b34afafa0c5d242594bbb4f9a6ae fixed QML file dialogs but broke > QtWidgets dialogs. > > QFileDialog static functions - dialog would open, but any user interaction is > blocked (cannot select files or click on anything). > QFileDialog *d = new QFileDialog(parent); d->open(); - dialog would not open > at all > > The first issue occurs because exec() is called on already shown dialog. This > is fixed by explicit hide() before calling exec() - kind of hacky :/ > The second issue is fixed by always calling show(). > > > Diffs > - > > autotests/CMakeLists.txt 00e4a41 > autotests/kfiledialog_unittest.cpp 45a139a > autotests/kfiledialogqml_unittest.cpp PRE-CREATION > autotests/qml/filedialog_parentless.qml PRE-CREATION > autotests/qml/filedialog_withparent.qml PRE-CREATION > src/platformtheme/kdeplatformfiledialoghelper.cpp 92ab107 > > Diff: https://git.reviewboard.kde.org/r/123335/diff/ > > > Testing > --- > > QML dialogs: > example from bug 334963 works fine > file dialog from plasma desktop settings -> wallpapers works fine > > QtWidgets dialogs: > static dialogs from qtbase/examples/widgets/dialogs/standarddialogs works fine > QFileDialog *d = new QFileDialog(parent); d->open(); works fine > test app: https://paste.kde.org/psddcng5n > > I'm running Qt 5.4.1. > > Are there any other types of dialogs that I forgot (and possibly broke)? > > > Thanks, > > David Rosca > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Jenkins CI help for compile failures!
kspeech is deprecated, we need to remove it's use in knights looks like. It's interface file never got released with kf5. On Thu, Apr 9, 2015 at 12:29 PM, Scarlett Clark wrote: > KF5 knights fails to compile with: > 23:47:49 make[2]: *** No rule to make target > '/srv/jenkins/install/ubuntu/x86_64/g++/kf5- > > qt5/frameworks/kdelibs4support/inst/share/dbus-1/interfaces/org.kde.KSpeech.xml', > needed by 'src/kspeechinterface.cpp'. Stop. > 23:47:49 make[2]: *** Waiting for unfinished jobs > 23:47:49 [ 26%] [ 28%] [ 30%] [ 32%] Generating ui_popup.h > 23:47:49 Generating ui_enginesettings.h > 23:47:49 Generating ui_customdifficultydialog.h > 23:47:49 Generating settings.h, settings.cpp > 23:47:49 CMakeFiles/Makefile2:107: recipe for target > 'src/CMakeFiles/knights.dir/all' failed > 23:47:49 make[1]: *** [src/CMakeFiles/knights.dir/all] Error 2 > 23:47:49 Makefile:126: recipe for target 'all' failed > 23:47:49 make: *** [all] Error 2 > > Thoughts? ideas? > Thanks for your help, > Scarlett > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123075: do not require X11 on Mac OS X
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123075/#review3 --- Ship it! Ship It! - Jeremy Whiting On March 19, 2015, 4:59 p.m., Harald Fernengel wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123075/ > --- > > (Updated March 19, 2015, 4:59 p.m.) > > > Review request for KDE Frameworks and Michael Palimaka. > > > Repository: kdesu > > > Description > --- > > do not require X11 on Mac OS X > > > Diffs > - > > CMakeLists.txt 9623483d6f11f9cdb7d7dc19decfd7cf5e86d079 > > Diff: https://git.reviewboard.kde.org/r/123075/diff/ > > > Testing > --- > > > Thanks, > > Harald Fernengel > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Fwd: frameworkintegration QFileDialog bug
Adding frameworks list. -- Forwarded message -- From: Jeremy Whiting Date: Mon, Mar 16, 2015 at 8:57 PM Subject: frameworkintegration QFileDialog bug To: kdelibs Hey all, We have a strange bug in frameworkintegration https://bugs.kde.org/show_bug.cgi?id=334963 which really ought to get a solution sooner than later. People using the latest and greatest packages are hitting the issue https://bugs.kde.org/show_bug.cgi?id=344586 and more will if it doesn't get fixed. I've done a bit of testing and it boils down to this. In KDEFileDialogHelper show we need to call m_dialog->show() whether the dialog is modal or not. Currently we are only calling it if the dialog is not modal. Doing the above makes QDialog static methods somehow not interactive, I'm still not sure why. https://paste.kde.org/pdv7wlxpd <-- here's a backtrace of running the Qt 5 standarddialogs test and clicking on one of the file dialog tests. Interestingly, a backtrace of standarddialogs working with frameworkintegration as it is in git currently is exactly the same, and is interactive. Somehow moving the m_dialog->show() out of the if makes the exec() call not interactive anymore. Anyone have any idea what's going on here? thanks, Jeremy ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What's the point of tiers if we bend the definition of them?
+1 On Mon, Mar 16, 2015 at 4:16 PM, Albert Astals Cid wrote: > We have KPackage depending on kdoctools but since it's optional we pretend > it's not a real dependency and call KPackage tier2 > > What's in it for us other than lying to ourselves? What's so bad about > KPackage being tier 3? > > It'd still have only 3 dependencies and be totally usable, no? > > Cheers, > Albert > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122918: revert 2ee76f0 to fix QtQuickControls
> On March 15, 2015, 2:21 a.m., Frederik Gladhorn wrote: > > Without testing anything, I think that this will break QWidget's file > > dialog when set to modal. Iirc this breaks for example the open dialogs in > > qt creator. Yeah, that's the wrong approach, though I'm not sure what the right one is unfortunately. I tried to fix this bug with https://git.reviewboard.kde.org/r/121098/ but that change broke other things. It is very annoying and causes me issues almost daily since I can't upload anything from chromium currently (It's invocation of kdialog shows the open file dialog, but it's not interactive at all and has to be closed). Bug BUG:334963 has some information about the problem also. - Jeremy --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122918/#review77498 --- On March 12, 2015, 7:19 a.m., Marco Martin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122918/ > --- > > (Updated March 12, 2015, 7:19 a.m.) > > > Review request for KDE Frameworks and Frederik Gladhorn. > > > Bugs: 345002 > https://bugs.kde.org/show_bug.cgi?id=345002 > > > Repository: frameworkintegration > > > Description > --- > > Not sure it's the right approach, but right now, the FileDialog > QtQuickControls will be broken in the kde interqation if set as modal, see > https://bugs.kde.org/show_bug.cgi?id=345002 > > the commit 2ee76f0 makes show() not do anything in that case, and the > FileDialog QML bindings seems to assume to call only show() > > > Diffs > - > > src/platformtheme/kdeplatformfiledialoghelper.cpp 9ffb1d9 > > Diff: https://git.reviewboard.kde.org/r/122918/diff/ > > > Testing > --- > > > Thanks, > > Marco Martin > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122954: Let KNotifications be useable w/o searching for private deps
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122954/#review77479 --- Ship it! Ship It! - Jeremy Whiting On March 14, 2015, 1:06 p.m., Hrvoje Senjan wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122954/ > --- > > (Updated March 14, 2015, 1:06 p.m.) > > > Review request for KDE Frameworks and Martin Klapetek. > > > Repository: knotifications > > > Description > --- > > KF5WindowSystem isn't public dep, no need to find it as such > > > Diffs > - > > KF5NotificationsConfig.cmake.in 0466797 > > Diff: https://git.reviewboard.kde.org/r/122954/diff/ > > > Testing > --- > > > Thanks, > > Hrvoje Senjan > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122955: Let KNotifyConfig be useable w/o searching for private deps
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122955/#review77478 --- Ship it! Ship It! - Jeremy Whiting On March 14, 2015, 1:06 p.m., Hrvoje Senjan wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122955/ > --- > > (Updated March 14, 2015, 1:06 p.m.) > > > Review request for KDE Frameworks and David Edmundson. > > > Repository: knotifyconfig > > > Description > --- > > KF5KIO and KF5I18n are private deps, don't search for them in config > > > Diffs > - > > KF5NotifyConfigConfig.cmake.in e44bd62 > > Diff: https://git.reviewboard.kde.org/r/122955/diff/ > > > Testing > --- > > > Thanks, > > Hrvoje Senjan > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122953: Let KNewStuff be useable w/o searching for private deps
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122953/#review77476 --- Ship it! Ship It! - Jeremy Whiting On March 14, 2015, 1:06 p.m., Hrvoje Senjan wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122953/ > --- > > (Updated March 14, 2015, 1:06 p.m.) > > > Review request for KDE Frameworks and Jeremy Whiting. > > > Repository: knewstuff > > > Description > --- > > KF5Archive and KF5KIO are private deps, don't search for them in config > > > Diffs > - > > KF5NewStuffConfig.cmake.in bbbfdd0 > > Diff: https://git.reviewboard.kde.org/r/122953/diff/ > > > Testing > --- > > > Thanks, > > Hrvoje Senjan > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122953: Let KNewStuff be useable w/o searching for private deps
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122953/#review77472 --- I'm not sure I understand what this is for. If you try to build with knewstuff and kio and karchive aren't present, it wont run properly. Is this to make stuff that uses knewstuff build when the dependencies are there, but their headers are missing or something? - Jeremy Whiting On March 14, 2015, 1:06 p.m., Hrvoje Senjan wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122953/ > --- > > (Updated March 14, 2015, 1:06 p.m.) > > > Review request for KDE Frameworks and Jeremy Whiting. > > > Repository: knewstuff > > > Description > --- > > KF5Archive and KF5KIO are private deps, don't search for them in config > > > Diffs > - > > KF5NewStuffConfig.cmake.in bbbfdd0 > > Diff: https://git.reviewboard.kde.org/r/122953/diff/ > > > Testing > --- > > > Thanks, > > Hrvoje Senjan > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120648: Encode the URIs which end up in DTD files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120648/#review76782 --- Ship it! Ship It! - Jeremy Whiting On Oct. 19, 2014, 6:12 p.m., Luigi Toscano wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120648/ > --- > > (Updated Oct. 19, 2014, 6:12 p.m.) > > > Review request for Build System, KDE Software on Mac OS X, KDE Frameworks, > and kdewin. > > > Repository: kdoctools > > > Description > --- > > The URI need to be encoded, because some valid characters for > filenames are not valid according RFC 2396. > Easy way to trigger the issue: when the path contains spaces, > as it happens on MacOSX builds. > > See also https://git.reviewboard.kde.org/r/120649/ for the twin review on > kdelibs4support. > > > Diffs > - > > cmake/uriencode.cmake PRE-CREATION > src/CMakeLists.txt 341ecf4 > > Diff: https://git.reviewboard.kde.org/r/120648/diff/ > > > Testing > --- > > It compiles, but I can't properly test Mac and Windows scenarios > > > Thanks, > > Luigi Toscano > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120649: Encode the URIs which end up in DTD files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120649/#review76781 --- Ship it! Ship It! - Jeremy Whiting On Oct. 19, 2014, 6:13 p.m., Luigi Toscano wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120649/ > --- > > (Updated Oct. 19, 2014, 6:13 p.m.) > > > Review request for Build System, KDE Software on Mac OS X, KDE Frameworks, > and kdewin. > > > Repository: kdelibs4support > > > Description > --- > > The URI need to be encoded, because some valid characters for > filenames are not valid according RFC 2396. > Easy way to trigger the issue: when the path contains spaces, > as it happens on MacOSX builds. > > The function is duplicated from the matching functions in kdoctools > because: > - this module will go away in the not far future; > - the function is not generic enough to be used outside (yet) > > See also https://git.reviewboard.kde.org/r/120648/ for the twin review on > kdoctools. > > > Diffs > - > > cmake/uriencode.cmake PRE-CREATION > src/CMakeLists.txt 4a1d80d > > Diff: https://git.reviewboard.kde.org/r/120649/diff/ > > > Testing > --- > > It compiles, but I can't properly test Mac and Windows scenarios > > > Thanks, > > Luigi Toscano > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122751: Let ecm_configure_package_config_file manage path variables.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122751/#review76758 --- Ship it! Ship It! - Jeremy Whiting On Feb. 28, 2015, 3:23 a.m., Alex Merry wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122751/ > --- > > (Updated Feb. 28, 2015, 3:23 a.m.) > > > Review request for Documentation, KDE Frameworks, Luigi Toscano, and Jeremy > Whiting. > > > Repository: kdoctools > > > Description > --- > > This means that absolute data directory paths are handled correctly. > > > Diffs > - > > CMakeLists.txt 1b8d41415ce1043a6118a844d35ea99839693560 > KF5DocToolsConfig.cmake.in eff3d70ae2dcd8711e340306a7fbd1f2d6ca3ece > > Diff: https://git.reviewboard.kde.org/r/122751/diff/ > > > Testing > --- > > Ran cmake with and without absolute KDE_INSTALL_DATADIR path set. Checked > generated KF5DocToolsConfig.cmake by eye. > > > Thanks, > > Alex Merry > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122554: knotifyconfig: Add optional dependency on QtSpeech to reenable speaking notifications.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122554/ --- (Updated Feb. 17, 2015, 2 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Frederik Gladhorn. Repository: knotifyconfig Description --- Change config from KTTS to Speech. If QtSpeech is available when building return true from have_speech static method. Otherwise return false. Could also add a check to see if there are any backend errors later on. Diffs - CMakeLists.txt f5aa0e78d89a4c14c3acfd9384b100e507e30067 src/knotifyconfigactionswidget.h 88b341a909d466b8eaf065c5220ac05f8c963697 src/knotifyconfigactionswidget.cpp 27012e3b803ef0a99d5bafcebea270e2d7419d62 src/knotifyconfigactionswidgetbase.ui cbe647b70eb41ba540b7bf6d87f519b3246973a1 src/knotifyconfigelement.h 703952d23d1622e4b6214acc52461ea75b480254 src/knotifyconfigelement.cpp 5a1ac57fa5a4139682327d14c55a489450ea956b src/knotifyeventlist.cpp 148bca7d33c722a4aeecabac45286a5e501c81b3 Diff: https://git.reviewboard.kde.org/r/122554/diff/ Testing --- It builds, the config widget shows, the icon for speech is properly showing when that configuration is enabled. Speech from konversation's new message notifications are spoken. Something strange here: After enabling this notification, no messages are spoken until restarting the application with the notifications (konversation in my test case). Similarly, after disabling this notification, messages are still spoken until restarting the application. I checked and the konversation.notifyrc file is getting updated, but for some reason the changes aren't taking effect imediately yet. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122555: knotifications: Add optional dependency on Qt5TextToSpeech for speech notifications.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122555/ --- (Updated Feb. 17, 2015, 1:29 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Frederik Gladhorn. Repository: knotifications Description --- Add optional dependency on Qt5TextToSpeech for speech notifications. Diffs - CMakeLists.txt 208fd02153a0607e4cfbc02e4b289ef835cedbfd src/CMakeLists.txt 6a3d81707a0e27e2d7bbfbf7f3924852ab737bf9 src/knotification.h dc0c975e261f1a03b8b4875bc1069417cf8ea094 src/knotificationmanager.cpp affb6a673468bf6585cbda6fafdd008beb445cd9 src/knotifyconfig.cpp af6be92bd320eaa881d8420cadf175edf6bf41aa src/kstatusnotifieritem.h 74b97ba7c63d52cae8ee80326daa9f24ce03a331 src/notifybyktts.h 43756f776678bd7700a77a3357577363b36d2542 src/notifybyktts.cpp a2a15a9c77089527f54dfc63f13699d44336dda1 src/notifybytts.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/122555/diff/ Testing --- As I said in the knotifyconfig review something at runtime isn't refreshing/reloading the config when it is changed. Otherwise this works fine when QtSpeech is available. QtSpeech is still in development, so this change is added as an optional dependency. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122555: knotifications: Add optional dependency on Qt5TextToSpeech for speech notifications.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122555/ --- (Updated Feb. 13, 2015, 4:01 p.m.) Review request for KDE Frameworks and Frederik Gladhorn. Changes --- Fixed issues noted. Repository: knotifications Description --- Add optional dependency on Qt5TextToSpeech for speech notifications. Diffs (updated) - CMakeLists.txt 208fd02153a0607e4cfbc02e4b289ef835cedbfd src/CMakeLists.txt 6a3d81707a0e27e2d7bbfbf7f3924852ab737bf9 src/knotification.h dc0c975e261f1a03b8b4875bc1069417cf8ea094 src/knotificationmanager.cpp affb6a673468bf6585cbda6fafdd008beb445cd9 src/knotifyconfig.cpp af6be92bd320eaa881d8420cadf175edf6bf41aa src/kstatusnotifieritem.h 74b97ba7c63d52cae8ee80326daa9f24ce03a331 src/notifybyktts.h 43756f776678bd7700a77a3357577363b36d2542 src/notifybyktts.cpp a2a15a9c77089527f54dfc63f13699d44336dda1 src/notifybytts.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/122555/diff/ Testing --- As I said in the knotifyconfig review something at runtime isn't refreshing/reloading the config when it is changed. Otherwise this works fine when QtSpeech is available. QtSpeech is still in development, so this change is added as an optional dependency. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122554: knotifyconfig: Add optional dependency on QtSpeech to reenable speaking notifications.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122554/ --- (Updated Feb. 13, 2015, 12:42 p.m.) Review request for KDE Frameworks and Frederik Gladhorn. Changes --- Updated to use TTS name instead of Speech. Repository: knotifyconfig Description --- Change config from KTTS to Speech. If QtSpeech is available when building return true from have_speech static method. Otherwise return false. Could also add a check to see if there are any backend errors later on. Diffs (updated) - CMakeLists.txt f5aa0e78d89a4c14c3acfd9384b100e507e30067 src/knotifyconfigactionswidget.h 88b341a909d466b8eaf065c5220ac05f8c963697 src/knotifyconfigactionswidget.cpp 27012e3b803ef0a99d5bafcebea270e2d7419d62 src/knotifyconfigactionswidgetbase.ui cbe647b70eb41ba540b7bf6d87f519b3246973a1 src/knotifyconfigelement.h 703952d23d1622e4b6214acc52461ea75b480254 src/knotifyconfigelement.cpp 5a1ac57fa5a4139682327d14c55a489450ea956b src/knotifyeventlist.cpp 148bca7d33c722a4aeecabac45286a5e501c81b3 Diff: https://git.reviewboard.kde.org/r/122554/diff/ Testing --- It builds, the config widget shows, the icon for speech is properly showing when that configuration is enabled. Speech from konversation's new message notifications are spoken. Something strange here: After enabling this notification, no messages are spoken until restarting the application with the notifications (konversation in my test case). Similarly, after disabling this notification, messages are still spoken until restarting the application. I checked and the konversation.notifyrc file is getting updated, but for some reason the changes aren't taking effect imediately yet. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122554: knotifyconfig: Add optional dependency on QtSpeech to reenable speaking notifications.
> On Feb. 13, 2015, 4:49 a.m., Aleix Pol Gonzalez wrote: > > +1 > > > > What's the status of QtSpeech? I'll blog about it shortly. - Jeremy --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122554/#review75983 --- On Feb. 12, 2015, 8:06 p.m., Jeremy Whiting wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122554/ > --- > > (Updated Feb. 12, 2015, 8:06 p.m.) > > > Review request for KDE Frameworks and Frederik Gladhorn. > > > Repository: knotifyconfig > > > Description > --- > > Change config from KTTS to Speech. > If QtSpeech is available when building return true from have_speech static > method. > Otherwise return false. > Could also add a check to see if there are any backend errors later on. > > > Diffs > - > > CMakeLists.txt f5aa0e78d89a4c14c3acfd9384b100e507e30067 > src/knotifyconfigactionswidget.h 88b341a909d466b8eaf065c5220ac05f8c963697 > src/knotifyconfigactionswidget.cpp 27012e3b803ef0a99d5bafcebea270e2d7419d62 > src/knotifyconfigactionswidgetbase.ui > cbe647b70eb41ba540b7bf6d87f519b3246973a1 > src/knotifyconfigelement.h 703952d23d1622e4b6214acc52461ea75b480254 > src/knotifyconfigelement.cpp 5a1ac57fa5a4139682327d14c55a489450ea956b > src/knotifyeventlist.cpp 148bca7d33c722a4aeecabac45286a5e501c81b3 > > Diff: https://git.reviewboard.kde.org/r/122554/diff/ > > > Testing > --- > > It builds, the config widget shows, the icon for speech is properly showing > when that configuration is enabled. Speech from konversation's new message > notifications are spoken. > > Something strange here: > After enabling this notification, no messages are spoken until restarting the > application with the notifications (konversation in my test case). > Similarly, after disabling this notification, messages are still spoken until > restarting the application. > I checked and the konversation.notifyrc file is getting updated, but for some > reason the changes aren't taking effect imediately yet. > > > Thanks, > > Jeremy Whiting > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122555: knotifications: Add optional dependency on Qt5TextToSpeech for speech notifications.
> On Feb. 13, 2015, 5:11 a.m., Martin Klapetek wrote: > > src/notifybyspeech.cpp, line 65 > > <https://git.reviewboard.kde.org/r/122555/diff/1/?file=348637#file348637line65> > > > > Is there any way to know when the say() has finished? Because the > > finished() below will delete the notification object if it's the only > > plugin, which may just interrupt the speech in the middle We could watch the tts object for state change, but we wouldn't know which speech job it's finishing. Anyway, I don't think it matters, we pass the text to speak then the knotification object can get deleted with no effect on the speech itself from what I've heard (with my ears, not through the grape vine). - Jeremy --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122555/#review75986 ------- On Feb. 12, 2015, 8:11 p.m., Jeremy Whiting wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122555/ > --- > > (Updated Feb. 12, 2015, 8:11 p.m.) > > > Review request for KDE Frameworks and Frederik Gladhorn. > > > Repository: knotifications > > > Description > --- > > Add optional dependency on Qt5TextToSpeech for speech notifications. > > > Diffs > - > > CMakeLists.txt 208fd02153a0607e4cfbc02e4b289ef835cedbfd > src/CMakeLists.txt 6a3d81707a0e27e2d7bbfbf7f3924852ab737bf9 > src/knotification.h c85621699793436442090b7f94ea82ef10c45b89 > src/knotificationmanager.cpp affb6a673468bf6585cbda6fafdd008beb445cd9 > src/kstatusnotifieritem.h 113dad513c320ef97f59b221b3541ca2f388693e > src/notifybyktts.h 43756f776678bd7700a77a3357577363b36d2542 > src/notifybyktts.cpp a2a15a9c77089527f54dfc63f13699d44336dda1 > src/notifybyspeech.cpp PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/122555/diff/ > > > Testing > --- > > As I said in the knotifyconfig review something at runtime isn't > refreshing/reloading the config when it is changed. Otherwise this works fine > when QtSpeech is available. > > QtSpeech is still in development, so this change is added as an optional > dependency. > > > Thanks, > > Jeremy Whiting > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 122555: knotifications: Add optional dependency on Qt5TextToSpeech for speech notifications.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122555/ --- Review request for KDE Frameworks and Frederik Gladhorn. Repository: knotifications Description --- Add optional dependency on Qt5TextToSpeech for speech notifications. Diffs - CMakeLists.txt 208fd02153a0607e4cfbc02e4b289ef835cedbfd src/CMakeLists.txt 6a3d81707a0e27e2d7bbfbf7f3924852ab737bf9 src/knotification.h c85621699793436442090b7f94ea82ef10c45b89 src/knotificationmanager.cpp affb6a673468bf6585cbda6fafdd008beb445cd9 src/kstatusnotifieritem.h 113dad513c320ef97f59b221b3541ca2f388693e src/notifybyktts.h 43756f776678bd7700a77a3357577363b36d2542 src/notifybyktts.cpp a2a15a9c77089527f54dfc63f13699d44336dda1 src/notifybyspeech.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/122555/diff/ Testing --- As I said in the knotifyconfig review something at runtime isn't refreshing/reloading the config when it is changed. Otherwise this works fine when QtSpeech is available. QtSpeech is still in development, so this change is added as an optional dependency. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 122554: knotifyconfig: Add optional dependency on QtSpeech to reenable speaking notifications.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122554/ --- Review request for KDE Frameworks and Frederik Gladhorn. Repository: knotifyconfig Description --- Change config from KTTS to Speech. If QtSpeech is available when building return true from have_speech static method. Otherwise return false. Could also add a check to see if there are any backend errors later on. Diffs - CMakeLists.txt f5aa0e78d89a4c14c3acfd9384b100e507e30067 src/knotifyconfigactionswidget.h 88b341a909d466b8eaf065c5220ac05f8c963697 src/knotifyconfigactionswidget.cpp 27012e3b803ef0a99d5bafcebea270e2d7419d62 src/knotifyconfigactionswidgetbase.ui cbe647b70eb41ba540b7bf6d87f519b3246973a1 src/knotifyconfigelement.h 703952d23d1622e4b6214acc52461ea75b480254 src/knotifyconfigelement.cpp 5a1ac57fa5a4139682327d14c55a489450ea956b src/knotifyeventlist.cpp 148bca7d33c722a4aeecabac45286a5e501c81b3 Diff: https://git.reviewboard.kde.org/r/122554/diff/ Testing --- It builds, the config widget shows, the icon for speech is properly showing when that configuration is enabled. Speech from konversation's new message notifications are spoken. Something strange here: After enabling this notification, no messages are spoken until restarting the application with the notifications (konversation in my test case). Similarly, after disabling this notification, messages are still spoken until restarting the application. I checked and the konversation.notifyrc file is getting updated, but for some reason the changes aren't taking effect imediately yet. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: OSX/CI: kde-baseapps fails to build on branch frameworks
The offending commit was from Arjun AK, I've e-mailed him and cc'ed kde-core-devel to either bump kde-baseapps Qt requirement or revert/workaround that use of the enumeration that is new in Qt 5.4. On Wed, Feb 11, 2015 at 12:00 PM, Marko Käning wrote: > Hi Albert, > > On 10 Feb 2015, at 23:17 , Jeremy Whiting wrote: > > Exactly, whoever added that code either needs to find a Qt 5.3 way to do > the same, or bump the requirement. > > > who is in charge of kde-baseapps? > > I’d like to get this going on OSX with Qt 5.3.2 again, or at least see the > project set its requirements correctly… > > Greets, > Marko > > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: OSX/CI: kde-baseapps fails to build on branch frameworks
Exactly, whoever added that code either needs to find a Qt 5.3 way to do the same, or bump the requirement. On Tue, Feb 10, 2015 at 3:15 PM, Marko Käning wrote: > Hi Jeremy, > > On 10 Feb 2015, at 23:10 , Jeremy Whiting wrote: > > Seems that's from Qt 5.4 "This enum was introduced or modified in Qt > 5.4." in the QUrl::UserInputResolutionOptions documentation. > > > Shouldn’t the project then require Qt 5.4, which I’d like to see avoided > for now… > > Greets, > Marko > > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: OSX/CI: kde-baseapps fails to build on branch frameworks
Seems that's from Qt 5.4 "This enum was introduced or modified in Qt 5.4." in the QUrl::UserInputResolutionOptions documentation. On Tue, Feb 10, 2015 at 3:07 PM, Marko Käning wrote: > To make kde-baseapps build again on OSX/CI I have removed poppler from its > dependencies in config/base/kf5-qt5: > --- > +# KDE/Applications > +kde/applications/kde-baseapps: -kde/kdelibs/baloo > +kde/applications/kde-baseapps: -kde/kdelibs/baloo-widgets > +kde/applications/kde-baseapps: -general/poppler > --- > > > Yet, I am running in an unrelated problem, as it seems: > --- > [ 75%] Building CXX object > dolphin/src/CMakeFiles/kcm_dolphinviewmodes.dir/kcm_dolphinviewmodes_automoc.cpp.o > /Users/marko/WC/KDECI-builds/kf5-qt5/kde-baseapps/dolphin/src/main.cpp:108:68: > error: no member named 'AssumeLocalFile' in 'QUrl' > const QUrl url = QUrl::fromUserInput(str, QString(), > QUrl::AssumeLocalFile); > ~~^ > Scanning dependencies of target kitemlistselectionmanagertest > 1 error generated. > make[2]: *** [dolphin/src/CMakeFiles/kdeinit_dolphin.dir/main.cpp.o] Error > 1 > make[1]: *** [dolphin/src/CMakeFiles/kdeinit_dolphin.dir/all] Error 2 > --- > > Greets, > Marko > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fixing and regulating certain types of search fields across KF5 apps
Eike, On Mon, Feb 9, 2015 at 1:03 PM, Eike Hein wrote: > > Hi, > > we currently have numerous dynamic search fields across KDE > apps that, for performance reasons, disregard input shorter > than a particular QString::length(). Examples are KMail and > some things in KRunner. It's a common pattern. > > This is very English-centric behavior; many scripts are > more complex than this, in particular CJK ones. In Korean, > a single character may be composed of multiple letters and > form a complex syllable. Most Korean given names are two > characters, many useful words are only one character. > The situation in Japanese is similar - it's written using > a mix of syllabaries and ideograms. The check for 3 has > good intentions but breaks real use cases for these users, > such as finding mail by name. > > Addressing this algorithmically is not all that hard. When > normalizing to Unicode NFD, those complex Korean characters > turn into a sequence of combining characters for the indi- > vidual letters. Syllabic and ideographic code points are > assigned the character class Lo in Unicode, which is info > available via QChar. An NFD pass + counting Lo chars as 2 > would be simple and effective enough for this purpose. > > The way I'd like to see this fixed is placing an API like > isMinimumSearchableLength(QString) somewhere in KF5 and to > start using it everywhere. Realistically developers won't > find this on their own, but it means I could go around and > patch up all these places without copying code around. > That's a great idea imo. > > Which framework would be a good place for this? > Without giving it much thought I would think either KI18n or Sonnet. > > > Cheers, > Eike > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
