Re: Review board is partly broken?
Hi all, Reviewboard is currently experiencing some problems as a result of a defective update. The maintainer of our Reviewboard instance is investigating the cause and a possible solution. The issue is apparently similar to that described here - https://groups.google.com/forum/m/#!msg/reviewboard/rlQi-oXWEhU/raNrWFDPRbgJ An update will be posted once the issue has been corrected. Regards, Ben Cooksley KDE Sysadmin
Re: Fwd: looking for phonon gstreamer maintainer
I looked at the QtGstreamer git recently and there is still work going on, but the focus seemed to be on splitting out QtGlib and the Qt5 port. It looks like that should be a release with those changes ready soon. I assume the gstreamer 1 port well be next, although I think some work in that area is already done. On Sep 30, 2013 10:17 AM, Weng Xuetian wen...@gmail.com wrote: Another question, gstreamer is not parallel linkable, and ktp-call-ui is currently using QtGstreamer (which also seems unmaintained for quite some time) and it's using gstreamer 0.10. So if phonon-gstreamer is ported to gstreamer then QtGstreamer also must be ported to 1.0 (Though phonon-gstreamer and QtGstreamer doesn't use each other but they could end up in same application which will cause some problem..). Would it be easier to make phonon-gstreamer to use QtGstreamer and hence also make someone to maintain QtGstreamer? On Wed, Sep 25, 2013 at 5:08 PM, Harald Sitter sit...@kde.org wrote: On Wed, Sep 25, 2013 at 9:53 PM, Aaron J. Seigo ase...@kde.org wrote: thanks for the swift and excellent response! muchly appreciated ... On Wednesday, September 25, 2013 15:00:43 Harald Sitter wrote: d) at some point port to phonon5 would it at all make sense to see if we can resuscitate this backend by just going straight to (d)? does it make sense to port the existing code, or would a start from scratch make sense? Starting from scratch is certainly a viable option. Going straight to d would not solve the problem for Phonon4, or Qt4 for that matter as Phonon5 is supposed to be exclusively Qt5. However from a backend POV there is not going to be a whole lot difference between the two versions as Phonon5's key element is getting rid of pointless API dynamics and through that simplifying the frontend API (like not having a mediagraph where in theory one could order nodes in any order and something reasonable should come out at the end). The heavy lifting code of setting a source, building a pipeline and making it create output should be largely the same. I personally would go for a rewrite but at the same time I am also very confident that starting from the existing code base would yield success. Torrie Fischer already rewrote a lot of the pipeline building and control logic a while ago, so it is most certainly not as bad as it used to be. At the very least there is stuff that can be salvaged for a possible rewrite. given all the downsides to not having a *good* gstreamer 1.0 backend in your report, this seems like a pretty important item. particularly for those of us looking to bring software to mobile devices where having multiple media middleware is not an awesome solution. There definitely are solid reasons for having a GStreamer backend, otherwise it would have gotten the boot like all the other broken backends years ago. While I had not originally thought of mobile devices, it certainly has even greater importance there. Regardless of the device though it would be a shame to loose the backend, so I really hope someone who enjoys HD videos steps up and volunteers to make software to play them (better) :) HS
Re: kde-workspace master becomes Qt5-based
Sebastian Kügler wrote: We're planning to merge the frameworks-scratch branch of kde-workspace into master next Monday. I tried building the branch. It requires qimageblitz, which I didn't see a Qt 5 version for, and soprano which has a non-building qt5_port branch. Do you have local working branches of those? Thanks, Steve.
Re: kde-workspace master becomes Qt5-based
On Tuesday, October 01, 2013 15:11:51 Stephen Kelly wrote: We're planning to merge the frameworks-scratch branch of kde-workspace into master next Monday. I tried building the branch. It requires qimageblitz, which I didn't see a Qt 5 version for, and soprano which has a non-building qt5_port branch. Do you have local working branches of those? They're optional. I don't need them to build. They have not been ported yet. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Review board is partly broken?
Hello, a few minutes I come across to another issue. In one of my reviews I have created a new file which doesn't exist in the remote tree, a few days ago I was able to create the review request but now I can't update the review. I receive this error `The file server/lib/db/forum.js (revision d4dde01) was not found in the repository` Regards, Giorgos -- Giorgos Tsiapaliokas (terietor) terietor.org
Re: Review Request 112880: Added KColorSchemeToken class.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/#review41068 --- I'm not a huge fan of using Q_INVOKABLE for something that actually looks more like a property. There's something to be said for keeping this object static, as otherwise it could grow a bit big, so I wouldn't regard this as a showstopper. (As we don't have really dynamic properties, we'd likely to a lot of work and keep too much things in memory.) kdeui/colors/kcolorschemetoken.h http://git.reviewboard.kde.org/r/112880/#comment30145 Maybe add example calls for this, easy to copy (and still get right). I totally see people getting it wrong. :) kdeui/colors/kcolorschemetoken.h http://git.reviewboard.kde.org/r/112880/#comment30144 using int here loses the type-safety. Why no use the corresponding enums? It would also make the code more readable. (Same issue for all the other methods.) - Sebastian Kügler On Sept. 29, 2013, 4:27 p.m., Denis Kuplyakov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/ --- (Updated Sept. 29, 2013, 4:27 p.m.) Review request for KDE Frameworks and kdelibs. Repository: kdelibs Description --- It is wrapper to access KColorScheme's methods from QML code. Also added Q_GADGET to KColorScheme to enable Q_ENUMS using, to make them accessible from QML code. As it will be accepted, QML-clone of KgPopupItem will be posted for review to libkdegames, as it uses it to access KDE's color theme. More info: * search for KDE theme colors API for QML thread at kdelibs and kdegames mailinglists * Diffs - includes/CMakeLists.txt cdf0143 includes/KColorSchemeToken PRE-CREATION kdeui/CMakeLists.txt b439e04 kdeui/colors/kcolorscheme.h 17570fd kdeui/colors/kcolorscheme.cpp a6650ac kdeui/colors/kcolorschemetoken.h PRE-CREATION kdeui/colors/kcolorschemetoken.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112880/diff/ Testing --- I've tested it with KReversi's deniskup/gsoc2013/newdesign branch. Thanks, Denis Kuplyakov
Re: kde-workspace master becomes Qt5-based
On Tuesday 01 October 2013 15:25:27 Sebastian Kügler wrote: On Tuesday, October 01, 2013 15:11:51 Stephen Kelly wrote: We're planning to merge the frameworks-scratch branch of kde-workspace into master next Monday. I tried building the branch. It requires qimageblitz, which I didn't see a Qt 5 version for, and soprano which has a non-building qt5_port branch. Do you have local working branches of those? They're optional. I don't need them to build. They have not been ported yet. http://websvn.kde.org/trunk/kdesupport/qimageblitz/?view=log
Acquiring Google Mock libraries for tests
Hey, Recent changes of Google Mock package in Kubuntu (precompiled libraries are no longer shipped) have sparked a discussion on amarok-devel mailing list [1] on how should we proceed without readily available libraries to link to. Simply compiling sources from distro-provided package is not an option as not all distros ship them (e.g. Arch, Suse); that leaves us with options of pushing distros to provide such packages, or providing sources ourselves (in repository or otherwise). I was having a hard time searching for examples of Google Mock usage on projects.kde.org, so my question is: how do other KDE projects deal with acquiring Google Mock? Konrad [1] http://mail.kde.org/pipermail/amarok-devel/2013-October/012718.html
Re: Acquiring Google Mock libraries for tests
Hi Konrad, On Tuesday, October 01, 2013 17:45:54 Konrad Zemek wrote: Recent changes of Google Mock package in Kubuntu (precompiled libraries are no longer shipped) have sparked a discussion on amarok-devel mailing list [1] on how should we proceed without readily available libraries to link to. Simply compiling sources from distro-provided package is not an option as not all distros ship them (e.g. Arch, Suse); that leaves us with options of pushing distros to provide such packages, or providing sources ourselves (in repository or otherwise). If they're optional dependencies, that's not a technical problem. It might be a licensing one. Otherwise, not every distro ships every single feature some KDE software supports. It raises complexity, but it's not a showstopper perse. I was having a hard time searching for examples of Google Mock usage on projects.kde.org, so my question is: how do other KDE projects deal with acquiring Google Mock? What is Google Mock and what's the deal about it? Your email describe a concrete issue, without giving a problem description. For me, it's hard to make sense of it, not knowing Google Mock. I understand you're talking about a general problem with precompiled libraries? Another example is libspotify, if I understand correctly? I think this thread doesn't need cross-posting to kde-core-devel, really. Too much cross-posting makes baby-buddha cry. :P Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Review Request 112852: Proposed patch to enable compilation of nepomuk-core on Mac
On Sept. 23, 2013, 4:18 p.m., Sune Vuorela wrote: Ship It! Nicolas, do you have or want to obtain commit rights? If not, Nepomuk developers can commit it for you. - Christoph --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112852/#review40588 --- On Sept. 21, 2013, 7:53 a.m., Nicolas Pavillon wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112852/ --- (Updated Sept. 21, 2013, 7:53 a.m.) Review request for kdelibs and Nepomuk. Bugs: https://bugs.kde.org/show_bug.cgi?id=325058 http://bugs.kde.org/show_bug.cgi?id=https://bugs.kde.org/show_bug.cgi?id=325058 Repository: nepomuk-core Description --- Patch to solve the bug reported at https://bugs.kde.org/show_bug.cgi?id=325058. Diffs - tools/nepomukctl/main.cpp 9d350ea Diff: http://git.reviewboard.kde.org/r/112852/diff/ Testing --- Applied the patch on several OS X platforms to ensure that compilation does not crash. See https://trac.macports.org/ticket/40498 for details. Thanks, Nicolas Pavillon
Re: Review Request 112258: ksysguard process list: better keyboard navigation
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112258/ --- (Updated Oct. 2, 2013, 6:30 a.m.) Review request for kde-workspace. Repository: kde-workspace Description (updated) --- ksysguard has good keyboard handling, but it can be better. For example, it has annoyed me that I cannot use the del/shift-del shortcuts or get the context menu unless I explicitly tab my way down to the treeview (even though pressing up/down with the text field focused gives the false impression that the rows have focus). This diff makes this keyboard navigation more efficient. While the comments in the code should describe the behavior well enough, here they are listed: * Search field ** Pressing enter moves to first item in treeview and opens context menu ** Pressing down/pgdown will move actual focus to the treeview ** Focusing the text field clears the treeview selection. This emphasises that only one visual element is focused at a time, as well as that you can not interact with the items in the view until they have been selected. * Treeview ** Pressing up when on the first entry will move focus to the text field ** If you start typing, the focus will immediately be moved to the text field ** When focus is received, select first row in the treeview After bumping this twice already without responses, I'm thinking about pushing it as it is unlikely to cause much (if any) trouble. Diffs - libs/ksysguard/processui/ksysguardprocesslist.cpp ed2c1ff4e93041e4b1911e2643bfda6888d171bd Diff: http://git.reviewboard.kde.org/r/112258/diff/ Testing --- Thanks, Harald Hvaal
