Re: Request: remove libkactivites from kdelibs (in experimental/)
Hi, On Monday 14 November 2011, Aaron J. Seigo wrote: besides kde-core-devel, it was also blogged by a number of attendees, so planetkde.org readership was in the loop. there was a story on dot.kde.org, so dot.kde.org readership was in the loop. there's documentation on community.kde.org. hell, it even made it to slashdot (ok, that last one is NOT a good test ;) so we most certainly did communicate. you didn't catch it, and i agree that that sucks. but it is not because the communication didn't happen in all the most appropriate places. the only thing we could have done more for you is to track you down personally, and that's just not a realistic expectation. to throw in my two cents: I don't think the problem is the _amount_ of communication. But personally, I'm dearly missing a _central_ place with a plain summary of the most important status information about kdelibs. My main focus of development is on a KDE-based application, not kdelibs. But every once in a while, I find a bug in kdelibs, and I want to contribute a fix. And every once in a blue moon, I want to contribute a small feature. For such sporadic contributions, the ratio of time spent on producing a patch versus time spent on figuring out how to get the patch into kdelibs is not a good one. Back in the good old days, this basically meant reading up on any freezes in effect. With the move to git, and now with frameworks efforts, the complexity has increased, considerably. All relevant information is available somewhere, but having to search through half a dozen places (techbase.kde.org, community.kde.org, kde-core-devel, kde- cvs-announce, blogs, dot, ...) is downright painful. Esp., if some of those places are littered with outdated and misleading bits. So, what I would love to see is _one_ short up-to-date page with just the most relevant info along the lines of: - You want to contribute a bug fix with no API changes, and no string changes: Commit to branch X. Additionally, merging your commit into branch Y would [not] be helpful but/and is [not] necessary. - You want to contribute a bug fix with no API changes, but changes in i18n strings: Please wait until MM.DD. - You want to do X: Commit to branch Z - For non-trivial patches, please get your code reviewed, first: git.reviewboard.kde.org - Here are some links to current background information on plans and schedules: X, Y, Z, and here's a step-by-step guide on pushing patches to kdelibs with git. Ideally, this page would be linked from http://quickgit.kde.org/?p=kdelibs.gita=summary , if that is possible. Ideally, also, git would point we to it, when my push fails for some reason. Regards Thomas signature.asc Description: This is a digitally signed message part.
Review Request: Fix wrong whatsThis strings in proxy kcm
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103131/ --- Review request for KDE Base Apps and Dawit Alemayehu. Description --- Corrected whatsThis for HTTPS and SOCKS and common port for socks. Could not find any default/common ports for FTP proxy server, therefore removed that. Diffs - konqueror/settings/kio/kproxydlg.ui 2170e7d Diff: http://git.reviewboard.kde.org/r/103131/diff/diff Testing --- Thanks, Burkhard Lück
Re: Request: remove libkactivites from kdelibs (in experimental/)
On Monday, November 14, 2011 10:35:16 Thomas Friedrichsmeier wrote: My main focus of development is on a KDE-based application, not kdelibs. But every once in a while, I find a bug in kdelibs, and I want to contribute a fix. And every once in a blue moon, I want to contribute a small feature. For such sporadic contributions, the ratio of time spent on producing a patch versus time spent on figuring out how to get the patch into kdelibs is not a good one. Back in the good old days, this basically meant reading up on any freezes in effect. With the move to git, and now with frameworks efforts, the complexity has increased, considerably. the complexity will eventually subside. right now it's something like: * until further notice, if it is a bug fix, put it into KDE/4.7 and it will get merged forward into frameworks * if it is a feature, do it in a branch off of frameworks and when it is ready, it can be merged in it is complex because we currently have to juggle between 4.x freezes, frameworks progress and the evolving state of that effort in a branch. it's a transition period that we all want to be as _short_ as possible so we can get back to simple. in future it will be: * bug fixes can always be applied to the stable branch; these will get merged into master. * features can be opened at any time in a feature branch and merge into the testing branch when they are ready for testing by your fellow developers. when it is ready for merging, it'll get merged into master. notice the lack of discussion there about freezes. all you'll need to know as a casual contributor is where feature branches come off of and what the latest stable branch is, and whether your addition is a bug fix or a feature. for casual contributors, this should be very low-barrier-to-entry. you shouldn't even need to consult the release schedule for things like feature freezes :) All relevant information is available somewhere, but having to search through half a dozen places (techbase.kde.org, community.kde.org, kde-core-devel, kde- cvs-announce, blogs, dot, ...) is downright painful. Esp., if some of those places are littered with outdated and misleading bits. completely agreed. So, what I would love to see is _one_ short up-to-date page with just the most relevant info along the lines of: that is one of the primary reasons we're getting together on irc later this month. it is quite clear to everyone that this is sorely needed, and so we're going to make this thing along with some other supporting information for frameworks ... -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: Review Request: Update tab labels list after moving when using QTabWidget::setMovable()
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102628/#review8192 --- This review has been submitted with commit fc5f17480bd2d6b6708e4263d89cff7d3b7fc0c6 by Christoph Feck to branch KDE/4.7. - Commit Hook On Sept. 16, 2011, 1:14 a.m., Christoph Feck wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102628/ --- (Updated Sept. 16, 2011, 1:14 a.m.) Review request for kdelibs and Eike Hein. Description --- Not sure if (and how) we must handle indexes outside range. This addresses bug 282017. http://bugs.kde.org/show_bug.cgi?id=282017 Diffs - kdeui/widgets/ktabwidget.h c9964a6 kdeui/widgets/ktabwidget.cpp f8185e2 Diff: http://git.reviewboard.kde.org/r/102628/diff/diff Testing --- Tested okey with Konversation. Thanks, Christoph Feck
Re: Review Request: [KTextEdit] Handle actions depending on modes/flags
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102919/#review8195 --- This review has been submitted with commit 547efae3b79e39b02b64418626b28ac0e698f69b by Christoph Feck to branch KDE/4.7. - Commit Hook On Nov. 3, 2011, 9:19 p.m., Christoph Feck wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102919/ --- (Updated Nov. 3, 2011, 9:19 p.m.) Review request for kdelibs. Description --- Changes: * handle shortcuts for actions that modify the text only when not readOnly() * handle shortcuts for Find/Replace actions only when findReplaceEnabled() * show Find actions in context menu even if readOnly() Unsure if: * we can actually do this, or if we need to consume the shortcuts * this goes to KDE/4.7 or frameworks This addresses bug 284433. http://bugs.kde.org/show_bug.cgi?id=284433 Diffs - kdeui/widgets/ktextedit.cpp d9877b6 Diff: http://git.reviewboard.kde.org/r/102919/diff/diff Testing --- I am using this patch since two weeks, and haven't found any regression. Thanks, Christoph Feck
Re: Review Request: Fix wrong whatsThis strings in proxy kcm
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103131/#review8197 --- Ship it! There is no longer any default value set for any of them. Please remove anything that talks about default values from all and commit that. Thanks. - Dawit Alemayehu On Nov. 14, 2011, 10:24 a.m., Burkhard Lück wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103131/ --- (Updated Nov. 14, 2011, 10:24 a.m.) Review request for KDE Base Apps and Dawit Alemayehu. Description --- Corrected whatsThis for HTTPS and SOCKS and common port for socks. Could not find any default/common ports for FTP proxy server, therefore removed that. Diffs - konqueror/settings/kio/kproxydlg.ui 2170e7d Diff: http://git.reviewboard.kde.org/r/103131/diff/diff Testing --- Thanks, Burkhard Lück
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On Saturday 12 November 2011 11:35:22 Valentin Rusu wrote: On 11/12/2011 11:24 AM, Kevin Ottens wrote: So that was the intent of my previous email, now that the red flag got raised for inclusion in kdelibs master, why not going for a separate repository? That's exactly what I'm doing now. I'm only searching for the good location. At least contrary to inclusion in kdeutils it would avoid the circular dependency issue. Well, ksecrets is already a separate repository and it's located under the kdeutil parent classification. Right but I had more in mind the lib parts. And the circular dependency will be there as long as kdecore (where KCompositeJob lives) and kdeui (where KWallet lives) are tied together. Here is the schema : - KWallet legacy code *needs* KSecretsService API that *needs* KCompositeJob ; - if KSecretsServiceAPI is not present, then exclude KWallet specific code, so KSecretsService API should be compiled first, but that requires KCompositeJob. OK, so the only proper way out I see from here would be the following: * Reverting your changes in kdelibs 4.7 branch, the whole lot is definitely not material for 4.7.4 IMO; * Moving the libs part in your repository with the rest of ksecretservices to keep it all together; * Introducing a plugin loading approach inside of the KWallet convenience API * Make your current code for the KWallet convenience API a plugin for the above mechanism (seeing your code right now, it'll even map fairly well as in most places it's right now if (m_secretServices) else it uses the old code path) and have this plugin installed at the same time than your library. I know it's a bit of extra work now and I'm sorry about that. That said, this compromise comes with the longer term advantage that with such an organization you're pretty much ready for the KDE Frameworks time, it'll mainly be about extra QA from there, but you won't need to re-split later (which will be the case in the KDE Frameworks world). It also allows you to release along KDE SC 4.8 with kdeutils. Hope that helps solve the situation. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On Monday 14 November 2011 06:48:50 Aaron J. Seigo wrote: On Saturday, November 12, 2011 13:38:47 Valentin Rusu wrote: Ok, I'll then move it somewhere else. I'm very tempted by the kdecore module, the place where it's main dependency, KCompositeJob, lives. But I think the best place would be the *experimental* module. Ok for that? if this indeed goes into the kdelibs frameworks branch, then it should go into tier2/ksecretservice. (it depends on tier 1 libs, Yes, it'll likely depend on kcoreaddons in the end. so is a tier 2 lib.) Correct. It'll be a Tier 2 Integration Qt Addon (depends on Tier 1 library + runtime dependency). kdeui would be built after tier2/ksecretservice and link against the secret service lib. Right. Although I don't expect a kdeui to still exist in the end. The relevant KWallet code might end up in a kde4support I think. For that to happen we'd need a similar convenience API in libksecretservice itself if deemed appropriate (the whole KWallet API being synchronous it makes me feel a bit uneasy about it, could block on the other process, I'd rather keep that explicit on the API consumer with exec'ed jobs). this would give us zero circular dependencies, no excessive moving around of things and it would be easy to break it into its own repo when that time comes using git filter-branch. See my other email, I think it could and should be split right away so Valentin will be already in a very good position for KDE Frameworks. It's kinda odd to merge something in a repository we want to split anyway. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On Monday, 2011-11-14, Kevin Ottens wrote: Right. Although I don't expect a kdeui to still exist in the end. The relevant KWallet code might end up in a kde4support I think. For that to happen we'd need a similar convenience API in libksecretservice itself if deemed appropriate (the whole KWallet API being synchronous it makes me feel a bit uneasy about it, could block on the other process, I'd rather keep that explicit on the API consumer with exec'ed jobs). Definitely. But not because it could block but because it must block. And the only safe way to do that is to run the asynchronous call in a separate thread, blocking the calling thread with a semaphore or waitcondition. Loads of extra work for the maintainer of the synchronous wrapper for little extra convenience of the API using developer. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On Monday, November 14, 2011 18:04:08 Kevin Ottens wrote: * Introducing a plugin loading approach inside of the KWallet convenience API * Make your current code for the KWallet convenience API a plugin for the above mechanism (seeing your code right now, it'll even map fairly well as in most places it's right now if (m_secretServices) else it uses the old code path) and have this plugin installed at the same time than your library. as a mea culpa, if Valentin is OK with it, i volunteer to write the plugin support. Valentin: please let me know when ksecretservice is in its own repo, and i'll take care of the kwallet integration ... technically it's a new feature that'll be dropping into 4.8's kdelibs, but it's a reasonable compromise imho. i will commit it after the 4.7.4 release so as not to interfere with that. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On 11/14/2011 06:04 PM, Kevin Ottens wrote: On Saturday 12 November 2011 11:35:22 Valentin Rusu wrote: And the circular dependency will be there as long as kdecore (where KCompositeJob lives) and kdeui (where KWallet lives) are tied together. Here is the schema : - KWallet legacy code *needs* KSecretsService API that *needs* KCompositeJob ; - if KSecretsServiceAPI is not present, then exclude KWallet specific code, so KSecretsService API should be compiled first, but that requires KCompositeJob. OK, so the only proper way out I see from here would be the following: * Reverting your changes in kdelibs 4.7 branch, the whole lot is definitely not material for 4.7.4 IMO; * Moving the libs part in your repository with the rest of ksecretservices to keep it all together; The libs part would lead to a Tier2 library - I expected that and your other mail confirms it. May it contain the other ksecretsservice components such as the deamon and the sync tool (those who are already under kdeutils)? Depending on this answer, I'll either move the libs inside kdeutils/ksecrets or request a new git repo. * Introducing a plugin loading approach inside of the KWallet convenience API * Make your current code for the KWallet convenience API a plugin for the above mechanism (seeing your code right now, it'll even map fairly well as in most places it's right now if (m_secretServices) else it uses the old code path) and have this plugin installed at the same time than your library. I know it's a bit of extra work now and I'm sorry about that. No problem, I like the idea of a plug-in. It's better suited to this case and I should have thought of it from the start. That said, this compromise comes with the longer term advantage that with such an organization you're pretty much ready for the KDE Frameworks time, it'll mainly be about extra QA from there, but you won't need to re-split later (which will be the case in the KDE Frameworks world). It also allows you to release along KDE SC 4.8 with kdeutils. Indeed. Hope that helps solve the situation. Yes, it solves it quite right, thanks very much. -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On 11/14/2011 09:19 PM, Aaron J. Seigo wrote: On Monday, November 14, 2011 18:04:08 Kevin Ottens wrote: * Introducing a plugin loading approach inside of the KWallet convenience API * Make your current code for the KWallet convenience API a plugin for the above mechanism (seeing your code right now, it'll even map fairly well as in most places it's right now if (m_secretServices) else it uses the old code path) and have this plugin installed at the same time than your library. as a mea culpa, if Valentin is OK with it, i volunteer to write the plugin support. Ok, the mea culpa is enough for me :-) I prefer writing the plug-in myself, as I need to master this technique too. What would be the current beautiful plug-in implementation to take as an example? Valentin: please let me know when ksecretservice is in its own repo, and i'll take care of the kwallet integration ... technically it's a new feature that'll be dropping into 4.8's kdelibs, but it's a reasonable compromise imho. Ok, works for me. i will commit it after the 4.7.4 release so as not to interfere with that. Ok, I'll commit that after 4.7.4. -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Review Request: Fix KDateComboBox shrinking in size after a date is entered
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103133/ --- Review request for kdelibs and John Layt. Description --- After the user enters a date by means of the date picker or by up/down arrows, the edit field in KDateComboBox shrinks so that it is too small to display all the characters in the date. In addition, when first displayed, the widget visibly resizes, which doesn't look particularly good. This patch fixes these issues. Note that the patch is really a workaround for the issue - I haven't managed to find out exactly why the shrinkage occurs. However, it is a simple fix, so unless somebody else comes up with a better way, I think it's good enough. Diffs - kdeui/widgets/kdatecombobox.cpp fc239bc Diff: http://git.reviewboard.kde.org/r/103133/diff/diff Testing --- Tested successfully in KAlarm's alarm edit dialog. Thanks, David Jarvie
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On Monday 14 November 2011 21:42:27 Valentin Rusu wrote: The libs part would lead to a Tier2 library - I expected that and your other mail confirms it. May it contain the other ksecretsservice components such as the deamon and the sync tool (those who are already under kdeutils)? Depending on this answer, I'll either move the libs inside kdeutils/ksecrets or request a new git repo. Yes, you can reuse the same repository IMO. Hope that helps solve the situation. Yes, it solves it quite right, thanks very much. Excellent! Thanks for your patience! Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
