Re: CI Requirements - Lessons Not Learnt?

Am 2017-01-17 15:46, schrieb Adriaan de Groot: On Monday, January 16, 2017 05:32:12 PM Eike Hein wrote: I'll be working up a new draft today taking some of the comments so far into account, and giving sysadmin the latitude to remove projects from CI at their decision if the guidelines are

Re: CI Requirements - Lessons Not Learnt?

Am 2017-01-15 22:58, schrieb Alexander Neundorf: Hi Martin, just replying somewhere... On 2017 M01 15, Sun 14:52:30 CET Martin Gräßlin wrote: I think that is a reasonable suggestion. If distros patch our dependencies we need to consider this as a fork. And a fork should be called a fork

Re: CI Requirements - Lessons Not Learnt?

Am 2017-01-15 18:41, schrieb Kevin Kofler: Martin Gräßlin wrote: I think that is a reasonable suggestion. If distros patch our dependencies we need to consider this as a fork. And a fork should be called a fork. It needs to be clear that KDE is not responsible for any issues caused by the fork

Re: CI Requirements - Lessons Not Learnt?

Am 2017-01-14 21:14, schrieb Ben Cooksley: On Sat, Jan 14, 2017 at 5:23 AM, Martin Gräßlin <mgraess...@kde.org> wrote: Am 2017-01-13 13:21, schrieb Eike Hein: Ok, here we go. My draft of a formal policy for dep changes and the CI: https://community.kde.org/Po

Re: CI Requirements - Lessons Not Learnt?

Am 2017-01-14 11:42, schrieb Kai-Uwe: Am 14.01.2017 um 08:29 schrieb Martin Gräßlin: Am 14. Januar 2017 00:58:55 MEZ schrieb Kevin Kofler <kevin.kof...@chello.at>: The common case is that the new library version is used for an API addition, and that reverting the dependenc

Re: CI Requirements - Lessons Not Learnt?

Am 14. Januar 2017 00:58:55 MEZ schrieb Kevin Kofler : >Nicolás Alvarez wrote: >> It is not true that users will be no worse off. An application could >> increase the dependency of libfoo to 1.3 and add code using a feature >that >> was broken in 1.2. If you then revert

Re: CI Requirements - Lessons Not Learnt?

Am 2017-01-13 13:21, schrieb Eike Hein: Ok, here we go. My draft of a formal policy for dep changes and the CI: https://community.kde.org/Policies/Dependency_Changes_and_CI Compared to my earlier email, this draft contains some hard deadlines and an attempt to specify failure modes if the

Re: CI Requirements - Lessons Not Learnt?

Am 13. Januar 2017 07:42:21 MEZ schrieb Ben Cooksley <bcooks...@kde.org>: >On Fri, Jan 13, 2017 at 7:39 PM, Martin Gräßlin <mgraess...@kde.org> >wrote: >> Am 2017-01-13 03:10, schrieb Michael Pyne: >>> >>> On Thu, Jan 12, 2017 at 05:02:40PM +0100, Martin

Re: CI Requirements - Lessons Not Learnt?

Am 2017-01-12 17:13, schrieb Luca Beltrame: Il giorno Thu, 12 Jan 2017 16:53:18 +0100 Martin Gräßlin <mgraess...@kde.org> ha scritto: If you do nevertheless, my upstream position is GO FUCK YOURSELF! It will mean that I will directly close every bug report we get from Fedora with RE

Re: CI Requirements - Lessons Not Learnt?

Am 2017-01-12 08:32, schrieb Ben Cooksley: On Thu, Jan 12, 2017 at 4:54 AM, Martin Gräßlin <mgraess...@kde.org> wrote: Am 2017-01-11 10:46, schrieb Ben Cooksley: On Wed, Jan 11, 2017 at 6:57 PM, Martin Gräßlin <mgraess...@kde.org> wrote: Am 10. Januar 2017 22:42:35 MEZ

Re: CI Requirements - Lessons Not Learnt?

Am 2017-01-12 15:28, schrieb Kevin Kofler: Martin Gräßlin wrote: You know what happens when we ifdef the version of dependencies? Thinks break in distributions. They ignore the optional dependency and ship with the older one. Which results in issues we upstream developers have to care about

Re: CI Requirements - Lessons Not Learnt?

Am 2017-01-12 15:14, schrieb Kevin Kofler: Martin Gräßlin wrote: Everybody except I. I would have to maintain that mess. And I don't have time to maintain multiple compile time paths. I don't see how it would be any more work to maintain #if FEATURE as compared to #if 0. The difference

Re: CI Requirements - Lessons Not Learnt?

Am 2017-01-12 04:00, schrieb Kevin Kofler: Martin Gräßlin wrote: Email threads don't work to codify such requirements. What we need is something like an "announce new dependency to sysadmin freeze" prior to the dependency freeze in the release schedule. That's what I mean with

Re: CI Requirements - Lessons Not Learnt?

Am 2017-01-12 04:10, schrieb Kevin Kofler: Martin Gräßlin wrote: #if 0 // code already written, but not enabled as CI doesn't have it #endif If you already have this, then why don't you just write: #ifdef HAVE_FOO_1_23 or #if HAVE_FOO_1_23 with an appropriate #cmakedefine instead of #if 0

Re: CI Requirements - Lessons Not Learnt?

Am 2017-01-11 13:40, schrieb Jan Kundrát: On středa 11. ledna 2017 6:57:50 CET, Martin Gräßlin wrote: That doesn't work. Such inflexibility take away the advantage of having a CI. What base system(s) do you prefer to target as a developer, Martin? We release software which will be combined

Re: CI Requirements - Lessons Not Learnt?

Am 2017-01-11 11:10, schrieb Eike Hein: So my view of the situation is that we have a bunch of desires and needs, and we need to sort them. Here's a couple I can reasily identify: * We want to have a working CI that gives us useful results * We want to have developer flexibility in terms of

Re: CI Requirements - Lessons Not Learnt?

Am 2017-01-11 10:46, schrieb Ben Cooksley: On Wed, Jan 11, 2017 at 6:57 PM, Martin Gräßlin <mgraess...@kde.org> wrote: Am 10. Januar 2017 22:42:35 MEZ schrieb Ben Cooksley <bcooks...@kde.org>: On Mon, Jan 9, 2017 at 8:22 AM, Martin Gräßlin <mgraess...@kde.org> wrote: Am

Re: CI Requirements - Lessons Not Learnt?

Am 10. Januar 2017 22:42:35 MEZ schrieb Ben Cooksley <bcooks...@kde.org>: >On Mon, Jan 9, 2017 at 8:22 AM, Martin Gräßlin <mgraess...@kde.org> >wrote: >> >> >> Am 6. Januar 2017 17:46:30 MEZ schrieb Alexander Neundorf ><neund...@kde.org>: >>

Re: CI Requirements - Lessons Not Learnt?

Am 6. Januar 2017 17:46:30 MEZ schrieb Alexander Neundorf : >On 2017 M01 6, Fri 22:39:22 CET Ben Cooksley wrote: >> See my notes above re. why tying this to the dependency freeze date >is >> a bad idea and won't really work. >> >> Given that we potentially have to take into

Re: CI Requirements - Lessons Not Learnt?

Am 2017-01-06 05:57, schrieb Ben Cooksley: On Fri, Jan 6, 2017 at 12:38 AM, Martin Gräßlin <mgraess...@kde.org> wrote: Am 2017-01-05 11:20, schrieb Ben Cooksley: On Thu, Jan 5, 2017 at 10:28 PM, Martin Gräßlin <pri...@martin-graesslin.com> wrote: Am 2017-01-05 09:44, schrieb

Re: CI Requirements - Lessons Not Learnt?

know about beforehand. On Thursday 05 January 2017 21:49:52 Martin Gräßlin wrote: .. I think that this dependency is way more important to overall KWin than a few people having to manually build xkbcommon. Which is fairly trivial as David showed in his reply to the thread .. The impact is mostly because

Re: CI Requirements - Lessons Not Learnt?

Am 2017-01-05 21:13, schrieb Alexander Neundorf: On 2017 M01 5, Thu 16:11:43 CET Kevin Kofler wrote: Ben Cooksley wrote: > On Thu, Jan 5, 2017 at 10:28 PM, Martin Gräßlin wrote: >> It should be rather obvious that we don't introduce new dependencies >> because we like to.

Re: CI Requirements - Lessons Not Learnt?

Am 2017-01-05 16:11, schrieb Kevin Kofler: Ben Cooksley wrote: On Thu, Jan 5, 2017 at 10:28 PM, Martin Gräßlin wrote: It should be rather obvious that we don't introduce new dependencies because we like to. There is a very important software reason to it. That's the case for the xkbcommon

Re: CI Requirements - Lessons Not Learnt?

Am 2017-01-05 11:20, schrieb Ben Cooksley: On Thu, Jan 5, 2017 at 10:28 PM, Martin Gräßlin <pri...@martin-graesslin.com> wrote: Am 2017-01-05 09:44, schrieb Ben Cooksley: Hi all, It seems that my previous vocal complaints about system level / serious impact dependency bumps on the CI

Re: CI Requirements - Lessons Not Learnt?

Sorry picked wrong from address Am 2017-01-05 10:28, schrieb Martin Gräßlin: Am 2017-01-05 09:44, schrieb Ben Cooksley: Hi all, It seems that my previous vocal complaints about system level / serious impact dependency bumps on the CI system have gone completely unnoticed by (some) members

Re: Review Request 129233: [kdelibs] Make Qt4 WebKit optional (default on)

. - Martin Gräßlin On Oct. 20, 2016, 10:50 p.m., Andreas Sturmlechner wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.

Re: Review Request 127944: KDE Platform Theme: set file dialog overwrite option appropriately for saving

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127944/#review96149 --- Ship it! Do you have commit rights? - Martin Gräßlin

Re: Review Request 127944: KDE Platform Theme: set file dialog overwrite option appropriately for saving

> On May 17, 2016, 4:29 p.m., Martin Gräßlin wrote: > > The test does not verify the problem. I just pulled the patch, undid your > > change, but the test passed nevertheless. > > Martin Gräßlin wrote: > ah now I see. You adjusted the test application, but not the

Re: Review Request 127944: KDE Platform Theme: set file dialog overwrite option appropriately for saving

> On May 17, 2016, 4:29 p.m., Martin Gräßlin wrote: > > The test does not verify the problem. I just pulled the patch, undid your > > change, but the test passed nevertheless. ah now I see. You adjusted the test application, but not the autot

Re: Review Request 127944: KDE Platform Theme: set file dialog overwrite option appropriately for saving

the patch, undid your change, but the test passed nevertheless. - Martin Gräßlin On May 17, 2016, 4:20 p.m., Jonathan Marten wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.

Re: Review Request 127944: KDE Platform Theme: set file dialog overwrite option appropriately for saving

a test case for it. There are already some tests for the file dialog, so it should be easy to extend. - Martin Gräßlin On May 17, 2016, 3:29 p.m., Jonathan Marten wrote: > > --- > This is an automatically generated e-mail. To rep

Re: remove khelpcenter from next Plasma release?

Am 2016-03-09 16:43, schrieb Yuri Chornoivan: написане Wed, 09 Mar 2016 17:29:28 +0200, Sebastian Kügler : Hi all, [For the sake of sanity, please reply to both list, this topic affects applications and Plasma.] One of the topics we are discussing at the current Plasma sprint

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

pecially if the "Kill a window by clicking on it" optiopn would actually do > that. Though we should first decide on Thomas Lübking's proposal. > > > would you prefer the feature to be exposed in ksysguard or would you > prefer a KWin SysTray/Statusnotifier item? (Or neither ;-) > > Giving acce

Re: PSA: KAccounts now requires two env vars set

Am 2016-01-18 21:06, schrieb Martin Klapetek: Because of a co-installability issue with other DEs [1] that use the accounts-sso tech, I had to change the location of the provider and service files we ship. This was decided after discussing with upstream. To make KAccounts/libaccounts actually

Re: Adding further modules to api.kde.org

Am 2015-09-10 21:50, schrieb Allen Winter: On Thursday, September 10, 2015 10:57:10 AM Martin Graesslin wrote: Hi all, back in KDE4 days the workspace libraries were listed on api.kde.org [1]. But for the current version we don't have any API docs available. The section "Other KDE Software"

Re: Review Request 125081: Fix build on OS X

low-level - valid users are KWin and Plasma and KWindowsystem itself and that's it. So I am relatively sure that the usage of NETWM in Konqueror is just wrong and can be replaced by an abstracting API in KWindowsystem. - Martin Gräßlin On Sept. 8, 2015, 12:08 a.m., Samuel Gaist wrote

Re: Review Request 125081: Fix build on OS X

tps://git.reviewboard.kde.org/r/125081/#comment58789> Please don't use the KWINDOWSYSTEM_HAVE_X11 but instead find XCB yourself and define your own HAVE_X11. KWIND)WSYSTEM_HAVE_X11 is not public API. - Martin Gräßlin On Sept. 8, 2015, 12:08 a.m., Samuel Gaist

Re: Review Request 125043: expose the WheelMouseZooms global setting through the input ("mouse") KCM

feature for a repository that has been feature frozen for years? Given that I think this should not and never be merged. If you want to keep the repo going for OSX I suggest to create a branch for your patches. - Martin Gräßlin On Sept. 4, 2015, 1:51 p.m., René J.V. Bertin wrote

Re: RFC: KDE Bugzilla Bugs Expiration

On Friday, July 31, 2015 11:02:44 AM Dominik Haumann wrote: Comments? Strong objections? ;) +1 - I think it's a sensible strategy and something we kind of implemented with introducing a new product for Plasma: thus getting rid of the old cruft. Fun note: I set a bug as RESOLVED FIXED

Re: KScreenGenie moved to KDE Review

On Tuesday 16 June 2015 02:45:56 Boudhayan Gupta wrote: The other thing I'd like to mention here is that there was talk on IRC and the kde-community list a few months back that if KScreenGenie does end up passing review and replacing KSnapshot, that it should take the KSnapshot name and just

Re: Re: KScreenGenie moved to KDE Review

On Sunday 28 June 2015 16:37:31 you wrote: 2) I'm home for the holidays and practically free with nothing else to do until the first week of August. Even after college starts again, the workload isn't so much that I'm unable to fix bugs within hours or at most 1-2 days (in rare circumstances)

Re: Re: Frameworks compiler and Qt requirements after Qt 5.7?

On Friday 26 June 2015 16:30:25 Luigi Toscano wrote: On Friday 26 of June 2015 16:24:50 Mark Gaiser wrote: Hi, If Qt's plans progress according to what they post on the mailinglist then Qt 5.6 will be LTS, 5.7 will up the compiler requirements to the following: GCC 4.7 Clang 3.2

Re: Review Request 123806: [klipper] Ignore empty / blank entries

. Although Allow whitespace entries is not checked I was able to get an entry with three new lines into the history. - Martin Gräßlin On May 22, 2015, 10:47 p.m., Patrick Eigensatz wrote: --- This is an automatically generated e-mail. To reply

Re: Review Request 123806: [klipper] Ignore empty / blank entries

://git.reviewboard.kde.org/r/123806/#comment55399 you don't need to cast here, just do like in line 104: return HistoryItemPtr() - Martin Gräßlin On May 22, 2015, 10:47 p.m., Patrick Eigensatz wrote: --- This is an automatically generated e-mail

Re: Review Request 123806: [klipper] Ignore empty / blank entries

one option to simplfy the text or two options (simplify + allow blank entries)? Martin Gräßlin wrote: I'm for an option to allow blank entries, but I'm strictly against a simplify option. I do not think that klipper should apply magic to copied strings. Given the way how I interact

Re: Review Request 123806: [klipper] Ignore empty / blank entries

On May 17, 2015, 8:22 p.m., Martin Gräßlin wrote: klipper/generalconfig.ui, lines 36-45 https://git.reviewboard.kde.org/r/123806/diff/5/?file=369604#file369604line36 unrelated to the discussion about how to call the entries: I would call the config option differently as the code

Re: Review Request 123806: [klipper] Ignore empty / blank entries

On May 17, 2015, 8:22 p.m., Martin Gräßlin wrote: klipper/generalconfig.ui, lines 36-45 https://git.reviewboard.kde.org/r/123806/diff/5/?file=369604#file369604line36 unrelated to the discussion about how to call the entries: I would call the config option differently as the code

Re: Review Request 123806: [klipper] Ignore empty / blank entries

On May 17, 2015, 8:22 p.m., Martin Gräßlin wrote: klipper/generalconfig.ui, lines 36-45 https://git.reviewboard.kde.org/r/123806/diff/5/?file=369604#file369604line36 unrelated to the discussion about how to call the entries: I would call the config option differently as the code

Re: Review Request 123806: [klipper] Ignore empty / blank entries

On May 16, 2015, 11:37 p.m., Patrick Eigensatz wrote: klipper/historyitem.cpp, line 91 https://git.reviewboard.kde.org/r/123806/diff/5/?file=369605#file369605line91 I'm not sure if I can access Klipper from here. If I have a look at how this is done at other options then I see

Re: Review Request 123806: [klipper] Ignore empty / blank entries

://git.reviewboard.kde.org/r/123806/#comment55217 unrelated to the discussion about how to call the entries: I would call the config option differently as the code is not trimming whitespaces but rather ignoring whitespace entries. - Martin Gräßlin On May 16, 2015, 11:31 p.m., Patrick Eigensatz wrote

Re: Review Request 123806: [klipper] Ignore empty / blank entries

On May 15, 2015, 9:31 p.m., Martin Gräßlin wrote: thanks for rebasing! I just had a look at the bug report and have to agree with comment #1: I do from time to time copy on purpose whitespaces (yes I'm weird). I also tend to copy newlines and I do want to have them in the history

Re: Review Request 123806: [klipper] Ignore empty / blank entries

we want to break that feature or whether we want to create a config option for it. - Martin Gräßlin On May 15, 2015, 8:50 p.m., Patrick Eigensatz wrote: --- This is an automatically generated e-mail. To reply, visit: https

Re: Review Request 123797: [PATCH] klipper: Ignore blank entries

On May 15, 2015, 8:01 p.m., Martin Gräßlin wrote: This patch is against kde-workspace, but the development happens in plasma-workspace nowadays. Could you please rebase against the newer repository? Patrick Eigensatz wrote: Sorry, I saw your comment a bît too late. Can you tell

Re: Review Request 123797: [PATCH] klipper: Ignore blank entries

happens in plasma-workspace nowadays. Could you please rebase against the newer repository? - Martin Gräßlin On May 15, 2015, 4:56 p.m., Patrick Eigensatz wrote: --- This is an automatically generated e-mail. To reply, visit: https

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated April 21, 2015, 12:24 a.m.) Review request for KDE Base Apps, Martin Gräßlin, John Tapsell, and Thomas Pfeiffer. Repository: libksysguard

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

you please add Thomas Pfeiffer from Usability team to the review to get him comment on it? - Martin Gräßlin On April 17, 2015, 9:25 a.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

/ksysguardprocesslist.cpp (line 1521) https://git.reviewboard.kde.org/r/122249/#comment54027 nitpick: added empty line - Martin Gräßlin On April 10, 2015, 1:23 p.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit

Re: Jenkins CI build help please

On Thursday 09 April 2015 10:37:03 Scarlett Clark wrote: Anyone have a clue what I need to install on *ubuntu system to achieve this depend? CC'd my fellow packagers @ kubuntu-devel as well, they are much smarter than I am. sure I have a clue, but you won't like it: xcb-input simply doesn't

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

On March 2, 2015, 8:47 a.m., Martin Gräßlin wrote: processui/keyboardshortcututil.cpp, line 46 https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46 This looks to complicated. It should be much easier to do with the KGlobalAccel API: * create

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

On March 2, 2015, 8:47 a.m., Martin Gräßlin wrote: processui/keyboardshortcututil.cpp, line 46 https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46 This looks to complicated. It should be much easier to do with the KGlobalAccel API: * create

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

On March 2, 2015, 8:47 a.m., Martin Gräßlin wrote: processui/keyboardshortcututil.cpp, line 46 https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46 This looks to complicated. It should be much easier to do with the KGlobalAccel API: * create

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

On March 2, 2015, 8:47 a.m., Martin Gräßlin wrote: processui/keyboardshortcututil.cpp, line 46 https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46 This looks to complicated. It should be much easier to do with the KGlobalAccel API: * create

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

On March 2, 2015, 8:47 a.m., Martin Gräßlin wrote: processui/keyboardshortcututil.cpp, line 46 https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46 This looks to complicated. It should be much easier to do with the KGlobalAccel API: * create

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

On Jan. 26, 2015, 8:05 a.m., Martin Gräßlin wrote: My opinion is that this is a feature which should not be exposed in libksysguard. It actually ties libksysguard to KWin, while libksysguard was in the past also used in e.g. kdevelop. If libksysguard wants to offer

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

On Jan. 26, 2015, 8:05 a.m., Martin Gräßlin wrote: My opinion is that this is a feature which should not be exposed in libksysguard. It actually ties libksysguard to KWin, while libksysguard was in the past also used in e.g. kdevelop. If libksysguard wants to offer

Re: Review Request 122556: Bump Qt version to 5.4

should first ensure the CI system is prepared for building with the new dependency. - Martin Gräßlin On Feb. 13, 2015, 9:06 a.m., Arjun AK wrote: --- This is an automatically generated e-mail. To reply, visit: https

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

://git.reviewboard.kde.org/r/122320/#comment52123 you forgot to git add the config-xcb.h.cmake - Martin Gräßlin On Feb. 4, 2015, 1:31 a.m., Nick Shaforostoff wrote: --- This is an automatically generated e-mail. To reply, visit: https

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

On Feb. 4, 2015, 10:16 a.m., Martin Gräßlin wrote: startkde/kcminit/CMakeLists.txt, line 6 https://git.reviewboard.kde.org/r/122320/diff/4/?file=346734#file346734line6 you forgot to git add the config-xcb.h.cmake Nick Shaforostoff wrote: i know. its contents is the following

Re: Re: Another proposal for modernization of our infrastructure

On Monday 02 February 2015 13:17:21 Milian Wolff wrote: On Saturday 31 January 2015 20:56:41 Martin Graesslin wrote: On Saturday 31 January 2015 20:37:31 Christoph Feck wrote: On Saturday 31 January 2015 20:07:42 Eike Hein wrote: [...] Qt is using gerrit and we intend to remain a major

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

is defined as 1 if Xlib is found. It doesn't say anything about whether XCB is found. Please introduce a dedicated ifdef for it. - Martin Gräßlin On Feb. 2, 2015, 10:15 p.m., Nick Shaforostoff wrote: --- This is an automatically generated e

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

://git.reviewboard.kde.org/r/122320/#comment51998 as you are still using an QGuiApplication I suggest to introduce a test for the platform name. The reason: on e.g. Wayland you don't want to check the xcb connection - which would succeed in the case of XWayland. - Martin Gräßlin On Feb. 1, 2015, 12:07

Re: Review Request 122270: port kcminit away from kdelibs4support

://git.reviewboard.kde.org/r/122270/#comment51928 drop the else case and move the variable definition outside the ifdef block? - Martin Gräßlin On Jan. 29, 2015, 2:19 a.m., Nick Shaforostoff wrote: --- This is an automatically generated e-mail. To reply

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

On Jan. 26, 2015, 8:05 a.m., Martin Gräßlin wrote: My opinion is that this is a feature which should not be exposed in libksysguard. It actually ties libksysguard to KWin, while libksysguard was in the past also used in e.g. kdevelop. If libksysguard wants to offer

Re: Review Request 122270: port kcminit away from kdelibs4support

was not finished and you hadn't a shipit on any of the versions. - Martin Gräßlin On Jan. 29, 2015, 12:58 p.m., Nick Shaforostoff wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r

Re: Review Request 122270: port kcminit away from kdelibs4support

On Jan. 27, 2015, 7:59 a.m., Martin Gräßlin wrote: startkde/kcminit/main.cpp, lines 250-254 https://git.reviewboard.kde.org/r/122270/diff/1/?file=345342#file345342line250 I do not like this. If the only need is to check whether it's X11 multi-head, it should open

Re: Review Request 122270: port kcminit away from kdelibs4support

/122270/#comment51890 this is still unconditionally executed on all platforms. It's missing a qpa plugin check. - Martin Gräßlin On Jan. 28, 2015, 1:47 a.m., Nick Shaforostoff wrote: --- This is an automatically generated e-mail

Re: Review Request 122270: port kcminit away from kdelibs4support

On Jan. 27, 2015, 7:59 a.m., Martin Gräßlin wrote: startkde/kcminit/main.cpp, lines 250-254 https://git.reviewboard.kde.org/r/122270/diff/1/?file=345342#file345342line250 I do not like this. If the only need is to check whether it's X11 multi-head, it should open

Re: Re: Another proposal for modernization of our infrastructure

On Wednesday 28 January 2015 11:52:17 Martin Klapetek wrote: Hey, On Tue, Jan 27, 2015 at 11:08 AM, Jan Kundrát j...@kde.org wrote: Hi, as promised, here is a proposal on how our infrastructure can be improved, with emphasis on service integration. There are screenshots inside.

Re: Placement of config files for Plasma 5 and KF5-based applications

On Tuesday 27 January 2015 01:01:27 Thomas Pfeiffer wrote: Hi everyone, first of all, I think it's a great step in the right direction that we're now putting our config files in ~/.config instead of ~/.kde(4), we're now finally standard-compliant. However, where we still could - and imho

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

On Jan. 26, 2015, 8:05 a.m., Martin Gräßlin wrote: My opinion is that this is a feature which should not be exposed in libksysguard. It actually ties libksysguard to KWin, while libksysguard was in the past also used in e.g. kdevelop. If libksysguard wants to offer

Re: Review Request 122270: port kcminit away from kdelibs4support

this. If the only need is to check whether it's X11 multi-head, it should open an xcb_connection_t - if that fails we don't have an X-Server. If it succeeds we can check the number of screens. - Martin Gräßlin On Jan. 27, 2015, 4:10 a.m., Nick Shaforostoff wrote

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

On Jan. 26, 2015, 8:05 a.m., Martin Gräßlin wrote: My opinion is that this is a feature which should not be exposed in libksysguard. It actually ties libksysguard to KWin, while libksysguard was in the past also used in e.g. kdevelop. If libksysguard wants to offer

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

not be exposed in libksysguard. It actually ties libksysguard to KWin, while libksysguard was in the past also used in e.g. kdevelop. If libksysguard wants to offer the functionality to kill a window, it should implement it itself. - Martin Gräßlin On Jan. 25, 2015, 7:21 p.m., Gregor Mi wrote

Re: Re: Changes to our Git infrastructure

On Tuesday 06 January 2015 12:48:41 Jan Kundrát wrote: On Tuesday, 6 January 2015 07:40:01 CEST, Ian Wadham wrote: a) I do not know anything about Dr K, but I will try and find someone who does. b) Unfortunately there is nobody available any more who knows anything about

Re: Re: Ksshaskpass ?

On Sunday 14 December 2014 15:33:27 Thomas Lübking wrote: On Sonntag, 14. Dezember 2014 13:52:51 CEST, Jeremy Whiting wrote: Martin, Thomas, Is the implementation of InputGuard at https://github.com/luebking/qarma/commit/b568dd14d6e1f661791c4d67245c614f1 dc1986f with

Re: Re: Ksshaskpass ?

On Friday 12 December 2014 16:11:25 Thomas Lübking wrote: On Freitag, 12. Dezember 2014 08:00:45 CEST, Martin Gräßlin wrote: I'd suggest to do a platform check as on Wayland it cannot work (grab keyboard fails). You're certainly right in that the guarding is entirely superfluous

Re: Re: Review Request for KDecoration

On Thursday 11 December 2014 00:05:52 Albert Astals Cid wrote: El Dimecres, 10 de desembre de 2014, a les 15:44:02, Thomas Lübking va escriure: On Mittwoch, 10. Dezember 2014 13:11:07 CEST, Christoph Feck wrote: Every interactive on-screen element must have a text, either as a label,

Re: Re: Ksshaskpass ?

On Thursday 11 December 2014 08:33:48 Jeremy Whiting wrote: ksshaskspass has been in kdereview and has been improved since it got there. Is it ready to be moved to kde/workspace ? Sorry for being late for the review. I just cloned the repo and did a quick look for a common problem on X11: the

Re: Re: Re: Ksshaskpass ?

, Martin Gräßlin mgraess...@kde.org wrote: On Thursday 11 December 2014 08:33:48 Jeremy Whiting wrote: ksshaskspass has been in kdereview and has been improved since it got there. Is it ready to be moved to kde/workspace ? Sorry for being late for the review. I just cloned the repo and did

Re: Re: Ksshaskpass ?

On Thursday 11 December 2014 23:25:55 Thomas Lübking wrote: https://github.com/luebking/qarma/commit/b568dd14d6e1f661791c4d67245c614f1dc 1986f The InputGuard class should handle everything. In case you need it for QGraphicsWidget's, you may have to adjust the test functions, but in general

Re: Re: Review Request for KDecoration

On Wednesday 10 December 2014 00:21:38 Albert Astals Cid wrote: El Divendres, 28 de novembre de 2014, a les 15:30:23, Martin Gräßlin va escriure: On Friday 28 November 2014 15:25:03 Thomas Lübking wrote: On Freitag, 28. November 2014 14:55:43 CEST, Martin Gräßlin wrote: Both signals

Re: Re: Review Request for KDecoration

On Wednesday 10 December 2014 00:31:03 Thomas Lübking wrote: On Mittwoch, 10. Dezember 2014 00:21:38 CEST, Albert Astals Cid wrote: Where did the strings such as Not on all desktops They were/are not part of KDecoration, but KCommonDecoration - an optional simplifying wrapper class.

Re: Review Request 121390: make Qt5 theme build on Linux again

on how to do it properly. In the end it should be: #if HAVE_X11 // x11 specific stuff #endif obviously it also needs a runtime check: if (QX11Info::isPlatformX11()) as we no longer should assume that X11 is the only platform on Unix(non OSX). - Martin Gräßlin On Dec. 8, 2014, 2:38 p.m., René J.V

Re: Review Request 121390: make Qt5 theme build on Linux again

On Dec. 8, 2014, 3:07 p.m., Martin Gräßlin wrote: this is wrong - please have a look at various frameworks on how to do it properly. In the end it should be: #if HAVE_X11 // x11 specific stuff #endif obviously it also needs a runtime check: if (QX11Info::isPlatformX11

Re: Review Request 121390: make Qt5 theme build on Linux again

On Dec. 8, 2014, 3:07 p.m., Martin Gräßlin wrote: this is wrong - please have a look at various frameworks on how to do it properly. In the end it should be: #if HAVE_X11 // x11 specific stuff #endif obviously it also needs a runtime check: if (QX11Info::isPlatformX11

Re: Review Request 121390: make Qt5 theme build on Linux again

On Dec. 8, 2014, 3:07 p.m., Martin Gräßlin wrote: this is wrong - please have a look at various frameworks on how to do it properly. In the end it should be: #if HAVE_X11 // x11 specific stuff #endif obviously it also needs a runtime check: if (QX11Info::isPlatformX11

Re: KFind

On Friday 05 December 2014 10:00:24 laurent Montel wrote: Hi, I think that we can use Dolphin to search files. I want to remove Kfind from kde-baseapps. It was not ported and there is not maintainer. If nobody has an objection I will remove it at before christmas. I don't think that

Re: Re: decoration.h | [was: Review Request for KDecoration]

On Wednesday 12 November 2014 15:27:00 Thomas Lübking wrote: On Mittwoch, 12. November 2014 08:19:54 CEST, Martin Gräßlin wrote: My thought was that it's going to be * rect for top * rect for left * rect for right * rect for bottom leaving out the center element. Thus a QRegion

Re: Re: Review Request for KDecoration

On Sunday 16 November 2014 23:30:35 Christoph Feck wrote: On Friday 31 October 2014 08:22:53 Martin Gräßlin wrote: today I want to start the review process for the new KDecoration Hi Martin, thanks for the work, here are some random comments from my side. I hope I am not too late

Re: Re: Review Request for KDecoration

On Friday 28 November 2014 13:53:07 Sebastian Kügler wrote: On Friday, November 28, 2014 12:00:43 Martin Gräßlin wrote: Given that you call it fundamental, I suggest to allow qreal here. A millimeter is really small, and if you only allow integer values, the precision might be too coarse

  1   2   3   4   >