Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On Jan. 26, 2015, 7: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 the functionality to kill a window, it
should implement it itself.
Martin Gräßlin wrote:
In addition: KWin's global shortcut action names are not public API. We
do not guarantee that we don't change them, we do not guarantee that they are
exposed at all (KWin handling shortcuts internally without kglobalaccel on
Wayland?). I do not want to run into situations that we cannot change our
code because external usage makes it impossible.
Thomas Lübking wrote:
In case there was larger demand for invoking such action (taskbar,
dedicated plasmoid, ...) one could move the xkill functionality into
KWindowSystem (option for portage) - invoking a kwin shortcut through a
kglobalaccel dbus call is a hack. Maybe sufficient for any downstream
solution, but easily broken feature.
Gregor Mi wrote:
First of all, a clarification of this RR's intentions:
1) The original End Process... tooltip says you can always use
Ctrl+Alt+Esc... which is wrong as soon as someone changes the keyboard
shortcut exposed by KWin. So this should be fixed.
2) Make the Kill Window feature more discoverable. It is a seldom used
feature which makes it harder to remember.
About invoking Kill Window:
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself. [Martin]
...one could move the xkill functionality into KWindowSystem...
[Thomas]
Without knowing the amount of xkill code I suspect that having a dbus
call that loosly couples libksysguard to KWin is probably easier to maintain
than 2 times the xkill code.
Having said that, what about moving the xkill code to a common location
as Thomas suggested?
We do not guarantee that we don't change them, we do not guarantee that
they are exposed at all ... I do not want to run into situations that we
cannot change our code because external usage makes it impossible.
Understood. But would it then be possible at all to get the current
shortcut to display it to the user?
Martin Gräßlin wrote:
Ok, so this addresses two issues using one solution: exposing KWin's
internal shortcut. This is bad as outlined above.
I agree that 1) needs fixing. This can be done in the way as approached
in this review request: check whether kwin is registered on kglobalaccel and
get the key command. If it's done that way the fault is with libksysguard in
case KWin changes the shortcut name or doesn't use kglobalaccel any more.
Another fix is of course to just hide the shortcut.
2) is a different issue. Whether it's needed to expose the functionality
in addition from libksysguard is probably questionable. A better approach to
do this would be through a method in KWindowSystem. This does not need to
duplicate the code, it could also just send a client message to the window
manager to start the kill window process. Through KWindowSystem we can check
whether the feature is supported by the window manager and could exclude if
not supported. But and that's a big but: the feature would not be able to
work if it's triggered from a (context) menu or drop down list (it needs to
grab mouse). Given that I'm hesistant to say that it should be added to
kwindowsystem at all.
Thomas Lübking wrote:
ad 2)
I'd have said to rather *move* the code to KWindowSystem and use it from
there by any client (incl. kwin)
This allows porting the solution (in case such is possible on other
systems at all) as well as to invoke the feature unconditionally (ie. instead
of is this kwin? yes? tell kwin to trigger xkill. just trigger the xkill
functionality)
About the popupmenu:
The issue is global, ie. as long as a popup (or other grabber) is
around, the kwin shortcut neither works.
It's kind of the client codes problem to deal w/ a false return (eg.
invoke a timer and/or timered retries)
ad 1) (shortcut)
I could live with adapting (or remove) the shortcut retrieval as soon as it
will not be possible anymore. As long as it is, I would show it. (I suspect as
long as the shortcut is not hard-coded there will be a some way to get it)
ad 2) (invoke window kill)
I looked a Kwin's source code. For reference, here are the two methods I found
to kill a window:
```
/*!
Kill Window feature, similar to xkill
*/
void Workspace::slotKillWindow()
{
if (m_windowKiller.isNull()) {
m_windowKiller.reset(new KillWindow());
}
m_windowKiller-start();
}
and
/**
* Kills the window via XKill
*/
void Client::killWindow()
{
qCDebug(KWIN_CORE) Client::killWindow(): caption();
killProcess(false);
Re: Review Request 122270: port kcminit away from kdelibs4support
On Січ. 27, 2015, 6:59 до полудня, 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 an xcb_connection_t - if that fails we don't have an X-Server. If it succeeds we can check the number of screens. understood, but the question remains: is kcminit the best place to do multihead-related stuff? - Nick --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122270/#review74806 --- On Січ. 27, 2015, 3:10 до полудня, Nick Shaforostoff wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122270/ --- (Updated Січ. 27, 2015, 3:10 до полудня) Review request for kde-workspace, Aleix Pol Gonzalez, Martin Gräßlin, and Lukáš Tinkl. Repository: plasma-workspace Description --- Now kcminit is linked with less libraries - startup time improved I also suggest always setting KDE_MULTIHEAD=true to eliminate ini file access during startup and to be able to stop linking against QtGui Diffs - startkde/kcminit/CMakeLists.txt ffae38c startkde/kcminit/main.h 1140b77 startkde/kcminit/main.cpp 4724323 Diff: https://git.reviewboard.kde.org/r/122270/diff/ Testing --- compiled, ran 'kcminit --list' and kcminit AAA Thanks, Nick Shaforostoff
Re: Sysadmin report on the modernization of our infrastructure
On Tuesday, 27 January 2015 09:51:46 CEST, Ben Cooksley wrote: Jenkins provides rich tracking of tests, code coverage and code quality (eg: cppcheck) in addition to checking if it builds. Zuul is designed to determine if it builds and if tests fail - providing a binary pass/fail response. This is not true. Please read Zuul's documentation at [1] (or the modernization proposal I'll be sending later today) for a short overview. I'll also note that Jenkins provides scheduling and can bring nodes up and down as needed (when equipped with access to a cloud/cluster). For this reason Openstack is still relying on Jenkins in part as Zuul can't do this. This is not true. - OpenStack uses Nodepool for node management (VM teardown bringing up new nodes, and image building), not Jenkins. - The reason why OpenStack uses Jenkins *with* Zuul rather than just Zuul + Turbo-Hipster is purely due to inertia and less work required due to their history. - OpenStack's use of Jenkins is limited to acting as a conduit for launching jobs. - Zuul knows how many resources are online at any time, so Nodepool can be (and is) used with it just fine. Jenkins also permits us to track jobs unrelated to our code reviews, So does Zuul; the OpenStack project is building release tarballs and have nightly QA processes on stable branches, all with Zuul. Please recall that no change of bug tracker or CI system is being planned at this time - such a change would be for future discussion. Fair enough, but then the argument of a fully integrated solution should not be advertised as Phabricator's advantage, IMHO. Cheers, Jan [1] http://ci.openstack.org/zuul/ -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: Sysadmin report on the modernization of our infrastructure
Hi all, Based on the feedback we'll now begin putting together a test instance so Phabricator can be seriously evaluated by the community. I've noted that the following projects have expressed interest in using it: - Calligra/Krita. - Zanshin. - KActivities. - Konversation. If any other projects would also like to evaluate it, please let us know - more are welcome to evaluate it as well. We'll be in touch with you all later in the week to make the preparations to begin the test. Once a sufficient period of testing has been completed with Phabricator we can then come back and make a final decision on what will be implemented. Thanks, Ben
Re: Sysadmin report on the modernization of our infrastructure
On Tuesday, January 27, 2015 03:30:48 Thomas Lübking wrote: On Samstag, 24. Januar 2015 15:24:28 CET, Thomas Friedrichsmeier wrote: But beyond review functionality, I think moving towards a more integrated solution is clearly a step in the right direction, and this is what makes the choice of Phabricator over Gerrit a clear case to me. I assume we all agree in wanting to have a more integrated solution than the status quo (which is basically not integrated at all), but keep in mind that integration does not require a vendor lock-in, eg. not two items in my HiFi system are from the same vendor. A fully integrated pre-solution might look nice on a glimpse, but the pre-integration does not necessarily compensate for defects in the components. So far, this entire thread has actually only ever addressed the review process or maybe SCM entirely (unless I missed something) and the pre-integration has been brought up as a benefit (and from sysadming POV, I do certainly understand why), but I wonder whether the other required components have been checked for feature completeness. Eg. I do not see the Phabricator Task tracker approach to be fundamentally different from (read: superior to) bugzilla (notably the comments seem to be just as linear and there also does not seem to be a summary comment to be edited by maintainers anytime - two things I would actually like in a bugtracker), but even a short research suggested it neither does suggest duplicates, not is there intention to add such. To me, this raises the question whether it's actually capable (or will ever be) of replacing (let alone surpassing) the current bugzilla solution. For another example (and vastly discussed) the integrated CI is when it's done, nobody has actually seen it in process, so we might end up with the patched-on Jenkins forever. Also the definitive blocker of scratching on-behalf-commit meta-info (for the SCM) has been brought up. I'm not familiar enough with either Jenkins nor Zuul to say which one's better and I cannot judge about the Phabricator bugtracker feature completeness, but if we end up with having to use external components because the pre-integrated ones do not fit our requirements (for an undefined time), the pre-integration argument is simply void. And this is of course the reason why the sysadmins have asked for projects that would volunteer as guinea pigs for the new system. And several have volunteered so we might soon know. Bottom line is: --- When you can well integrate the things you like, that's not necessarily inferior to some pre-integrated solution. Since one of the sysadmin's complaints of the competing solutions was that they didn't well integrate without lots of hacks, I suggest using the wording If you can... instead. And I think that this is the point that has gotten lost in the discussion at large. Gerrit may well be just as good as Phabricator or perhaps even better at code review; I simply don't know. But for overall integration with the rest of the infrastructure it's just one piece of the puzzle that needs to be interfaced to - again. The git hosting needs to be switched to something faster, the bug tracker needs to be integrated, projects would like to have their own mini-websites close to but not inside KDE. And so on. Can we please put a little more emphasis on this part of the issues too? And to asset the advance of the pre-integrated solution, that solution has to be evaluated in its completeness - as one has to presume that it might be much harder to replace components of a solution that is meant to run en bloc, than it would be to plug together components which provide a public API for that very designed purpose. Cheers, Thomas
Re: Sysadmin report on the modernization of our infrastructure
On Tue, Jan 27, 2015 at 3:30 PM, Thomas Lübking thomas.luebk...@gmail.com wrote: On Samstag, 24. Januar 2015 15:24:28 CET, Thomas Friedrichsmeier wrote: But beyond review functionality, I think moving towards a more integrated solution is clearly a step in the right direction, and this is what makes the choice of Phabricator over Gerrit a clear case to me. I assume we all agree in wanting to have a more integrated solution than the status quo (which is basically not integrated at all), but keep in mind that integration does not require a vendor lock-in, eg. not two items in my HiFi system are from the same vendor. Agreed and agreed. A fully integrated pre-solution might look nice on a glimpse, but the pre-integration does not necessarily compensate for defects in the components. So far, this entire thread has actually only ever addressed the review process or maybe SCM entirely (unless I missed something) and the pre-integration has been brought up as a benefit (and from sysadming POV, I do certainly understand why), but I wonder whether the other required components have been checked for feature completeness. Eg. I do not see the Phabricator Task tracker approach to be fundamentally different from (read: superior to) bugzilla (notably the comments seem to be just as linear and there also does not seem to be a summary comment to be edited by maintainers anytime - two things I would actually like in a You can't really compare Jenkins with Zuul as they're designed to achieve different goals. Jenkins provides rich tracking of tests, code coverage and code quality (eg: cppcheck) in addition to checking if it builds. Zuul is designed to determine if it builds and if tests fail - providing a binary pass/fail response. Harbormaster at this point at least looks like it will be similar in nature to Zuul. I'll also note that Jenkins provides scheduling and can bring nodes up and down as needed (when equipped with access to a cloud/cluster). For this reason Openstack is still relying on Jenkins in part as Zuul can't do this. Jenkins also permits us to track jobs unrelated to our code reviews, which is necessary for Hmm? It has a description section on tasks. See https://secure.phabricator.com/T1315 for an example. This can also be freely edited. I'm not aware of any threaded discussion issue tracker, but i'm happy to be corrected. bugtracker), but even a short research suggested it neither does suggest duplicates, not is there intention to add such. It is mainly intended as a task tracker rather than a bug tracker I believe, hence this position. The more suitable item to compare it to would therefore be todo.kde.org. To me, this raises the question whether it's actually capable (or will ever be) of replacing (let alone surpassing) the current bugzilla solution. For another example (and vastly discussed) the integrated CI is when it's done, nobody has actually seen it in process, so we might end up with the patched-on Jenkins forever. Also the definitive blocker of scratching on-behalf-commit meta-info (for the SCM) has been brought up. I'm not familiar enough with either Jenkins nor Zuul to say which one's better and I cannot judge about the Phabricator bugtracker feature completeness, but if we end up with having to use external components because the pre-integrated ones do not fit our requirements (for an undefined time), the pre-integration argument is simply void. I concur here that pre-integration is void if the pre-integrated components aren't useful. Bottom line is: --- When you can well integrate the things you like, that's not necessarily inferior to some pre-integrated solution. And to asset the advance of the pre-integrated solution, that solution has to be evaluated in its completeness - as one has to presume that it might be much harder to replace components of a solution that is meant to run en bloc, than it would be to plug together components which provide a public API for that very designed purpose. For those that are worried - people have integrated JIRA and Phabricator together, so it is more than possible to connect Phabricator with external task trackers. Please recall that no change of bug tracker or CI system is being planned at this time - such a change would be for future discussion. Cheers, Thomas Thanks, Ben
[kcalc][kcharselect][kcron] Merged frameworks branch to master, now KF5 based
Hi, I just merged the frameworks KF5 porting branches of the following applications to master branch: - kcalc - kcharselect - kcron These applications will be released as KF5 applications for the KDE Applications 15.03 release. Please check if everything went smooth, and report issues/regressions to bugs.kde.org. Also, I have no administrative powers to make the required changes to our infrastructures, so if not already done, please help with rewiring CI, translations, pko, etc. Thanks to Lukáš Tinkl and Laurent Montel for help with porting. I am still amazed how Laurent manages to find the time while busy with PIM. Christoph Feck (kdepepo)
Re: Review Request 122270: port kcminit away from kdelibs4support
On Jan. 27, 2015, 6:59 vorm., 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 an xcb_connection_t - if that fails we don't have an X-Server. If it succeeds we can check the number of screens. Nick Shaforostoff wrote: understood, but the question remains: is kcminit the best place to do multihead-related stuff? It's required by KApplication and while that's in kde4support, it's still there (as well as KDE4 clients) So yes, we need that everywhere - for now. Clients seem to default the env to false, so uncoditionally setting it true is wrong for sure. It'd rather be multihead = (screenCount 1); (ignoring the ini) what however would be a feature loss. = Proposal users should be able to pre-control the variable in eg. ~/.kde/env (or wherever the Plasma 2 equivalent is) If the variable is set to false, it remains like that. If not (ie. it's not set or set true resp. anything but 0/false) it becomes true if the screen count 1 Spares the ini lookup, but I don't think you get around xcb_connection_t *c; int screen_count = xcb_setup_roots_length(xcb_get_setup(c)); without risking to really break stuff (the suggested approach still causes a transitional break) - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122270/#review74806 --- On Jan. 28, 2015, 12:47 vorm., Nick Shaforostoff wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122270/ --- (Updated Jan. 28, 2015, 12:47 vorm.) Review request for kde-workspace, Aleix Pol Gonzalez, Martin Gräßlin, and Lukáš Tinkl. Repository: plasma-workspace Description --- Now kcminit is linked with less libraries - startup time improved I also suggest always setting KDE_MULTIHEAD=true to eliminate ini file access during startup and to be able to stop linking against QtGui Diffs - startkde/kcminit/CMakeLists.txt ffae38c startkde/kcminit/main.h 1140b77 startkde/kcminit/main.cpp 4724323 Diff: https://git.reviewboard.kde.org/r/122270/diff/ Testing --- compiled, ran 'kcminit --list' and kcminit AAA Thanks, Nick Shaforostoff
Re: Review Request 122270: port kcminit away from kdelibs4support
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122270/ --- (Updated Jan. 28, 2015, 12:47 a.m.) Review request for kde-workspace, Aleix Pol Gonzalez, Martin Gräßlin, and Lukáš Tinkl. Repository: plasma-workspace Description --- Now kcminit is linked with less libraries - startup time improved I also suggest always setting KDE_MULTIHEAD=true to eliminate ini file access during startup and to be able to stop linking against QtGui Diffs (updated) - startkde/kcminit/CMakeLists.txt ffae38c startkde/kcminit/main.h 1140b77 startkde/kcminit/main.cpp 4724323 Diff: https://git.reviewboard.kde.org/r/122270/diff/ Testing --- compiled, ran 'kcminit --list' and kcminit AAA Thanks, Nick Shaforostoff
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On Jan. 26, 2015, 7:05 vorm., 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 the functionality to kill a window, it should implement it itself. Martin Gräßlin wrote: In addition: KWin's global shortcut action names are not public API. We do not guarantee that we don't change them, we do not guarantee that they are exposed at all (KWin handling shortcuts internally without kglobalaccel on Wayland?). I do not want to run into situations that we cannot change our code because external usage makes it impossible. Thomas Lübking wrote: In case there was larger demand for invoking such action (taskbar, dedicated plasmoid, ...) one could move the xkill functionality into KWindowSystem (option for portage) - invoking a kwin shortcut through a kglobalaccel dbus call is a hack. Maybe sufficient for any downstream solution, but easily broken feature. Gregor Mi wrote: First of all, a clarification of this RR's intentions: 1) The original End Process... tooltip says you can always use Ctrl+Alt+Esc... which is wrong as soon as someone changes the keyboard shortcut exposed by KWin. So this should be fixed. 2) Make the Kill Window feature more discoverable. It is a seldom used feature which makes it harder to remember. About invoking Kill Window: If libksysguard wants to offer the functionality to kill a window, it should implement it itself. [Martin] ...one could move the xkill functionality into KWindowSystem... [Thomas] Without knowing the amount of xkill code I suspect that having a dbus call that loosly couples libksysguard to KWin is probably easier to maintain than 2 times the xkill code. Having said that, what about moving the xkill code to a common location as Thomas suggested? We do not guarantee that we don't change them, we do not guarantee that they are exposed at all ... I do not want to run into situations that we cannot change our code because external usage makes it impossible. Understood. But would it then be possible at all to get the current shortcut to display it to the user? Martin Gräßlin wrote: Ok, so this addresses two issues using one solution: exposing KWin's internal shortcut. This is bad as outlined above. I agree that 1) needs fixing. This can be done in the way as approached in this review request: check whether kwin is registered on kglobalaccel and get the key command. If it's done that way the fault is with libksysguard in case KWin changes the shortcut name or doesn't use kglobalaccel any more. Another fix is of course to just hide the shortcut. 2) is a different issue. Whether it's needed to expose the functionality in addition from libksysguard is probably questionable. A better approach to do this would be through a method in KWindowSystem. This does not need to duplicate the code, it could also just send a client message to the window manager to start the kill window process. Through KWindowSystem we can check whether the feature is supported by the window manager and could exclude if not supported. But and that's a big but: the feature would not be able to work if it's triggered from a (context) menu or drop down list (it needs to grab mouse). Given that I'm hesistant to say that it should be added to kwindowsystem at all. ad 2) I'd have said to rather *move* the code to KWindowSystem and use it from there by any client (incl. kwin) This allows porting the solution (in case such is possible on other systems at all) as well as to invoke the feature unconditionally (ie. instead of is this kwin? yes? tell kwin to trigger xkill. just trigger the xkill functionality) About the popupmenu: The issue is global, ie. as long as a popup (or other grabber) is around, the kwin shortcut neither works. It's kind of the client codes problem to deal w/ a false return (eg. invoke a timer and/or timered retries) - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review74740 --- On Jan. 25, 2015, 6:21 nachm., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated Jan. 25, 2015, 6:21 nachm.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. Repository: libksysguard Description --- Current situation: The End Process... button has a tooltip which says To target a specific window to
Re: Review Request 122267: ki18n: Make it build with msvc compilers again
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122267/ --- (Updated Jan. 27, 2015, 2:15 p.m.) Status -- This change has been marked as submitted. Review request for kdelibs, kdewin and Nicolás Alvarez. Repository: ki18n Description --- QStringLiteral documentation says: Concatenated string literals cannot be used with QStringLiteral. QString s = QStringLiteral(a b); which causes ki18n to not build on msvc 2013 here. This patch makes it build again. Diffs - src/kuitmarkup.cpp e2dda98 Diff: https://git.reviewboard.kde.org/r/122267/diff/ Testing --- Now ki18n builds with msvc2013 Thanks, Jeremy Whiting
Re: [kcalc][kcharselect][kcron] Merged frameworks branch to master, now KF5 based
El Dimecres, 28 de gener de 2015, a les 00:12:26, Christoph Feck va escriure: Hi, I just merged the frameworks KF5 porting branches of the following applications to master branch: - kcalc - kcharselect - kcron These applications will be released as KF5 applications for the KDE Applications 15.03 release. 15.04 :) https://techbase.kde.org/Schedules/Applications/15.04_Release_Schedule Cheers, Albert Please check if everything went smooth, and report issues/regressions to bugs.kde.org. Also, I have no administrative powers to make the required changes to our infrastructures, so if not already done, please help with rewiring CI, translations, pko, etc. Thanks to Lukáš Tinkl and Laurent Montel for help with porting. I am still amazed how Laurent manages to find the time while busy with PIM. Christoph Feck (kdepepo)
Re: [kcalc][kcharselect][kcron] Merged frameworks branch to master, now KF5 based
Christoph Feck ha scritto: Hi, I just merged the frameworks KF5 porting branches of the following applications to master branch: - kcalc - kcharselect - kcron These applications will be released as KF5 applications for the KDE Applications 15.03 release. Please check if everything went smooth, and report issues/regressions to bugs.kde.org. Also, I have no administrative powers to make the required changes to our infrastructures, so if not already done, please help with rewiring CI, translations, pko, etc. Translations moved, hopefully. Ciao -- Luigi
Re: Sysadmin report on the modernization of our infrastructure
Hi, On Tue, 27 Jan 2015 03:30:48 +0100 Thomas Lübking thomas.luebk...@gmail.com wrote: On Samstag, 24. Januar 2015 15:24:28 CET, Thomas Friedrichsmeier wrote: But beyond review functionality, I think moving towards a more integrated solution is clearly a step in the right direction, and this is what makes the choice of Phabricator over Gerrit a clear case to me. I assume we all agree in wanting to have a more integrated solution than the status quo (which is basically not integrated at all), but keep in mind that integration does not require a vendor lock-in, eg. not two items in my HiFi system are from the same vendor. I think vendor lock-in is just the wrong term, here. It's not like it's not possible to keep using bugzilla with phabricator, for instance. It's just that you don't get some integration features, or only at considerably more effort. Arguably, at this level, nothing has kept us from achieving similar integration with the current setup. A fully integrated pre-solution might look nice on a glimpse, but the pre-integration does not necessarily compensate for defects in the components. Naturally. And clearly a pick tool A from X, B from Y-kind of approach will - at least on paper - allow to satisfy more wishes. Unless you take integration and maintenance effort into account. (Which is still not actually saying that Gerrit would be the solution to satisfy all wishes in the review department; clearly there are defects of debatable severity to be found in this solution, too). So far, this entire thread has actually only ever addressed the review process or maybe SCM entirely (unless I missed something) and the pre-integration has been brought up as a benefit (and from sysadming POV, I do certainly understand why), but I wonder whether the other required components have been checked for feature completeness. Ideally that would be done in much more detail, true. There does seem to be a certain level of impatience about actually starting to move in some direction, though (and that may make a lot of sense). So the options are 1. spend some more months on open evaluation and testing 2. commit to solution X (barring real blockers to be discovered), and deal with issues as they come up 3. split the problem into smaller portions, by looking at one tool at a time. Sounds good on paper, but - again - adds unnecessary prejudice against any integrated solution. Eg. I do not see the Phabricator Task tracker approach to be fundamentally different from (read: superior to) bugzilla (notably the comments seem to be just as linear and there also does not seem to be a summary comment to be edited by maintainers anytime - two things I would actually like in a bugtracker), but even a short research suggested it neither does suggest duplicates, not is there intention to add such. To me, this raises the question whether it's actually capable (or will ever be) of replacing (let alone surpassing) the current bugzilla solution. Well, as far as I see it, the key points of superiority would be: - automatic cross-linking with review requests and tasks - cross-linking with project(s) (and actually, lack of this is the number one issue that keeps driving me mad with b.k.o, and its drop-down list of one-gazillion projects+subcomponents) I.e., once again: Not fundamentally different, but integrated. Regarding the dupes issue, the comment you refer to, is the developer's explanation, why the feature does not currently exist. The issue also has a patch for review. Regarding the summary comment: It's called description, in phabricator. For another example (and vastly discussed) the integrated CI is when it's done, nobody has actually seen it in process, so we might end up with the patched-on Jenkins forever. A risk sysadmins seem willing to take. Also the definitive blocker of scratching on-behalf-commit meta-info (for the SCM) has been brought up. To be honest, I think terms like definite blocker should be used with more care (on both sides of the argument, of course). Esp. as this is not available in reviewboard, either (for all I am aware), and there is a workaround available (requiring three commands instead of one). Bad: yes. Blocker: Come on, now. I'm not familiar enough with either Jenkins nor Zuul to say which one's better and I cannot judge about the Phabricator bugtracker feature completeness, but if we end up with having to use external components because the pre-integrated ones do not fit our requirements (for an undefined time), the pre-integration argument is simply void. True. And I can't give you answers to all your questions, either. But I actually do trust that sysadmins that done the _basic_ checking well enough. Bottom line is: --- When you can well integrate the things you like, that's not necessarily inferior to some pre-integrated solution. And to asset the advance of the pre-integrated solution, that solution has to be
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 should - do better is with where exactly we put them. If I look at my .config folder, I see mostly folders there, and then a lot of KDE files directly on the top level. If everyone would do that, .config would be a huge mess of files and it would be difficult to find the one you're looking for. We should not be the bad boy here. The question is: Where should we put the files? Putting them all in a .config/kde folder again would be possible and would clear up the top-level clutter, but I think we could go further. In fact, I don't see a reason why config files from otherwise completely unrelated applications that only have in common that they were made by KDE should all reside in the same folder, whereas other applications each have their own folder. What could make sense is having e.g. everything from Calligra in one folder, or everything from KDE Edu or KDE Games. And I'd put all Plasma stuff into one folder. Actually, there already is a plasma-workspace folder on my system, which contains an env and a shutdown folder. Why not put Plasma-related config files in there? I also have a KDE folder with Marble Virtual Globe.conf and Sonnet.conf in there, and a kde.org folder with libphonon.conf and marble.conf. This doesn't make us look very professional, as it shows that there is currently no guideline for where to put our config files. I think we should change that! So, for me there are three questions: 1. Should we come up with guidelines for config file placement? 2. Does my suggestion above make sense or if now how should it be done instead? 3. If we want guidelines, how do we make them known and maybe even enforce them via code checking or some such? There was a change to put config files into org.kde.foo, but that had to be reverted as it broke for setups like KWin where the configuration is not done in the same process. Given that at least for KWin I do not want to do any changes as a) the risk of breakage is too high b) it's too much work (all code needs to be hunted down for usage of kwinrc (git grep shows 46 usages just in kwin, no idea how spread out it is in other places to configure kwin) or KSharedConfig::openConfig and similar) c) I simply don't care whether users have a problem with ~/.config containing many files, it's a directory for applications, not for the user Cheers Martin signature.asc Description: This is a digitally signed message part.
Placement of config files for Plasma 5 and KF5-based applications
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 should - do better is with where exactly we put them. If I look at my .config folder, I see mostly folders there, and then a lot of KDE files directly on the top level. If everyone would do that, .config would be a huge mess of files and it would be difficult to find the one you're looking for. We should not be the bad boy here. The question is: Where should we put the files? Putting them all in a .config/kde folder again would be possible and would clear up the top-level clutter, but I think we could go further. In fact, I don't see a reason why config files from otherwise completely unrelated applications that only have in common that they were made by KDE should all reside in the same folder, whereas other applications each have their own folder. What could make sense is having e.g. everything from Calligra in one folder, or everything from KDE Edu or KDE Games. And I'd put all Plasma stuff into one folder. Actually, there already is a plasma-workspace folder on my system, which contains an env and a shutdown folder. Why not put Plasma-related config files in there? I also have a KDE folder with Marble Virtual Globe.conf and Sonnet.conf in there, and a kde.org folder with libphonon.conf and marble.conf. This doesn't make us look very professional, as it shows that there is currently no guideline for where to put our config files. I think we should change that! So, for me there are three questions: 1. Should we come up with guidelines for config file placement? 2. Does my suggestion above make sense or if now how should it be done instead? 3. If we want guidelines, how do we make them known and maybe even enforce them via code checking or some such? Looking forward to a fruitful discussion, Thomas
Re: Review Request 122270: port kcminit away from kdelibs4support
On Jan. 27, 2015, 6: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 an xcb_connection_t - if that fails we don't have an X-Server. If it succeeds we can check the number of screens. Nick Shaforostoff wrote: understood, but the question remains: is kcminit the best place to do multihead-related stuff? Thomas Lübking wrote: It's required by KApplication and while that's in kde4support, it's still there (as well as KDE4 clients) So yes, we need that everywhere - for now. Clients seem to default the env to false, so uncoditionally setting it true is wrong for sure. It'd rather be multihead = (screenCount 1); (ignoring the ini) what however would be a feature loss. = Proposal users should be able to pre-control the variable in eg. ~/.kde/env (or wherever the Plasma 2 equivalent is) If the variable is set to false, it remains like that. If not (ie. it's not set or set true resp. anything but 0/false) it becomes true if the screen count 1 Spares the ini lookup, but I don't think you get around xcb_connection_t *c; int screen_count = xcb_setup_roots_length(xcb_get_setup(c)); without risking to really break stuff (the suggested approach still causes a transitional break) reading ini file is not more than 0.5 second with 'cold cache'. getting rid of kdelibs4support for kcminit is 2 seconds gain. direct xcb request would require copying some 30 lines of code from xcp qpa plugin (= a no go). - Nick --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122270/#review74806 --- On Jan. 28, 2015, 12:47 a.m., Nick Shaforostoff wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122270/ --- (Updated Jan. 28, 2015, 12:47 a.m.) Review request for kde-workspace, Aleix Pol Gonzalez, Martin Gräßlin, and Lukáš Tinkl. Repository: plasma-workspace Description --- Now kcminit is linked with less libraries - startup time improved I also suggest always setting KDE_MULTIHEAD=true to eliminate ini file access during startup and to be able to stop linking against QtGui Diffs - startkde/kcminit/CMakeLists.txt ffae38c startkde/kcminit/main.h 1140b77 startkde/kcminit/main.cpp 4724323 Diff: https://git.reviewboard.kde.org/r/122270/diff/ Testing --- compiled, ran 'kcminit --list' and kcminit AAA Thanks, Nick Shaforostoff
