Re: Another proposal for modernization of our infrastructure

On Thursday 29 January 2015 17:22:45 Thomas Lübking wrote: > Maybe it's possible to borrow or upstream the Qt mod? See the repository "qtqa/gerrit" in the Qt infrastructure (Gitorious, Gerrit, etc.). See commits 6f3d74b7bda9d86a16d33ed16a0806b74482d57c, f6ec276bbd6980e4619e85abd3b3d62f7156fbfc,

Re: Another proposal for modernization of our infrastructure

On Friday 30 January 2015 10:04:01 Martin Graesslin wrote: > Also I don't think it can be improved, this looks really fundamental in > gerrit. I am not the only one who notices the problem and AFAIU Qt even > patches around the issues. Given that I'm not confident that we can improve > the softw

Re: Review Request 122320: use xcb-screen count instead of qguiapplication.screens

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122320/#review75061 --- startkde/kcminit/main.cpp

Re: Review Request 121831: libksysguard: process.h: encapsulate private fields

> On Jan. 21, 2015, 10:10 a.m., Dominik Haumann wrote: > > processcore/processes_linux_p.cpp, line 171 > > > > > > Don't you change behavior here? > > > > Before, we just wrote into the varialbes. > >

Re: Feature matrix for future infrastructure

On Thursday 29 January 2015 22:02:15 Thomas Lübking wrote: > On Donnerstag, 29. Januar 2015 12:54:25 CET, Jan Kundrát wrote: > > On Thursday, 29 January 2015 12:49:17 CEST, Christoph Feck wrote: > >> If it even allows to edit a change request from a different > >> person online, then I *want that*.

Re: Review Request 121831: libksysguard: process.h: encapsulate private fields

> On Jan. 21, 2015, 10:10 a.m., Dominik Haumann wrote: > > processcore/processes_linux_p.cpp, line 159 > > > > > > In theorey, if we wanted to avoid the local varialbes here, we could > > add reference-getters,

Re: Oxygen Icon usage terms

On Sat, Jan 31, 2015 at 12:07 AM, Kevin Krammer wrote: > Hi all, Hi Kevin, > > I've just seen a question on using Oxygen icons on a forum and the poster was > wondering about the status of http://www.oxygen-icons.org/ > > The terms in the wiki https://techbase.kde.org/Projects/Oxygen/Licensing s

Re: make uninstall

On Friday 30 January 2015 10:47:22 Alex Merry wrote: > On Friday 30 January 2015 10:44:23 Alex Merry wrote: > > Over on kde-frameworks-devel, there have been several requests to bring > > back `make uninstall` for KF5 and KF5-based projects. > > > > KDELibs4 used to define this for any dependent p

Oxygen Icon usage terms

Hi all, I've just seen a question on using Oxygen icons on a forum and the poster was wondering about the status of http://www.oxygen-icons.org/ The terms in the wiki https://techbase.kde.org/Projects/Oxygen/Licensing say that one should link to the above site, but there is no content there. A

Re: make uninstall

On Friday 30 January 2015 10:44:23 Alex Merry wrote: > Over on kde-frameworks-devel, there have been several requests to bring back > `make uninstall` for KF5 and KF5-based projects. > > KDELibs4 used to define this for any dependent projects (it's essentially > `xargs rm < install_manifest.txt` u

make uninstall

Over on kde-frameworks-devel, there have been several requests to bring back `make uninstall` for KF5 and KF5-based projects. KDELibs4 used to define this for any dependent projects (it's essentially `xargs rm < install_manifest.txt` under the hood), and we could easily add it to KDECMakeSettin

Re: libkgeomap

Gilles Caulier wrote: [backports from libs] > false. When it's possible we do it, when time permit. Speaking with my distro hat on, I argue that when we have to do that ourselves the process is made more complicated because most digikam-related repos don't have tags for releases (or betas): $

Re: libkgeomap

2015-01-30 11:18 GMT+01:00 Pino Toscano : > On Friday 30 January 2015 09:16:47 Raymond Wooninck wrote: >> But as that >> Digikam is moving more and more to a Qt5 application, then a Frameworks based >> one I wonder if the maintainers will go for this separation. > > I don't see how things will chan

Re: libkgeomap

On Friday 30 January 2015 09:16:47 Raymond Wooninck wrote: > But as that > Digikam is moving more and more to a Qt5 application, then a Frameworks based > one I wonder if the maintainers will go for this separation. I don't see how things will change because of this. Currently, the kdegraphics l

Re: Another proposal for modernization of our infrastructure

On Thursday, 29 January 2015 12:25:57 CEST, Jan Kundrát wrote: Hi Martin, thanks for an excellent idea, sorting headers before actual code changes makes a lot of sense. I have a quick'n'dirty patch at [1]. The patch has been merged upstream and will be released in next version (2.11). I'll al

Re: Another proposal for modernization of our infrastructure

On Thursday 29 January 2015 12:25:57 Jan Kundrát wrote: > On Wednesday, 28 January 2015 13:14:14 CEST, Martin Gräßlin wrote: > > Navigation through the code is difficult, you cannot see the > > complete change in one, but have to go through each file. This > > is something I consider as unfortunate

Re: libkgeomap

On Friday 30 January 2015 01:38:57 Kevin Kofler wrote: > > libkgeomap (just like all the other libraries used by digikam) has been > > built as standalone on build.kde.org for years, and digikam (and now > > kphotoalbum as well) are able to use it fine as "separate" library. > > +1, this "Digikam