Re: KDE/4.8.x is gone
El Dilluns, 2 de juliol de 2012, a les 22:29:59, Vishesh Handa va escriure: On Mon, Jul 2, 2012 at 10:06 PM, todd rme toddrme2...@gmail.com wrote: On Mon, Jul 2, 2012 at 6:01 PM, Albert Astals Cid aa...@kde.org wrote: After talking with David and Vishesh we decided to kill the KDE/4.8.x and bring its improvements to work with the old sopranos to KDE/4.8 So in summary: KDE/4.9 is where 4.9 bugfixing happens, needs soprano 2.8 KDE/4.8 is where 4.8 bugfixing happens (and if we ever release a 4.8.5 will be tagged from here), needs stable soprano 2.7 (will crash with soprano = 2.7.56) Cheers, Albert So KDE 4.8 will not work with soprano 2.8? It will :) Oh, right, my e-mail may have been wrong about the crashiness of KDE/4.8 with newer sopranos, Vishesh knows more than me. Sorry if the summary was wrong. Cheers, Albert -Todd
Re: Using userbase for manuals
On Sunday 1 July 2012 09:49:11 Kevin Ottens wrote: [...] My opinion is that I would love to go for it, and if over time that turns out to be a problem, we could ship a dump of the relevant wiki content along the application. It'd be used as fallback if the wiki cannot be reached online. Actually, after sleeping on it, it made me realize that this point above renders the discussion moot from a KDE Frameworks standpoint. On my side I was trying to determine if we had a way out from invokeHelp(). But as soon as you need this type of extra behavior, you need to have something like invokeHelp(), so our solution doesn't lie with the wiki or docbook discussion. Anyway, thanks everyone involved for the input provided. It was also a good opportunity to evaluate how our current doc team perceive userbase use for manuals (although that was just a fringe interest from KDE Frameworks perspective), I think the outcome there is pretty clear. :-) 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: About Writing Documentation in KDE (was: Using userbase for manuals)
[: Albert Astals Cid :] [...] I also want to note that developers that do not write documentation in docbook and that do not translate manuals are suggesting to switch to wiki (even if they agree they won't write documentation anyway) [...] Well, that is an elephant in the room. I too suspect that some simply don't like writing *and* maintaining documentation, so that no technical foundation will help there, and then Docbook bad serves as self- justification. But, I also know for a fact that there are people who do like to maintain documentation but hate Docbook. So I simply propose that people experiment with formats, so long as they keep documentation tight to their code, inside repository. From the i18n side, I will rather myself work to support translation of these new formats as they come by, than waste time translating outdated and information-free[1] Docbook. I should also probably mention that I too tried with wiki, and had an opposite experience to what some people in this thread report. I thought, well this wiki is a bit too visual for my taste and maybe a bit too HTML centric, but lets give it a shot, maybe it would even induce some serious cooperation. The cooperation thing never happened, and for me personally it was exceedingly problematic to keep wiki pages in sync with code changes. I was forgetting what's where, forgetting that something even exists, and I couldn't use mighty search facilities (a.k.a. grep) to check for that. So, after a few years, I folded everything to single in-repository directory (in Docbook). Now I keep documentation files always open in my Kate session for the given project, right there in my face, and commits/merges of user- visible changes always go in with the documentation update. [1] Information-free I consider when documentation states no more than what is stated by tooltips and whatsthis within the program. Please, please, drop the requirement that every KDE SC program should have documentation. If a program does not have documenation, and you the willing documentation writer don't use it on a regular basis, just ignore it. -- Chusslove Illich (Часлав Илић) signature.asc Description: This is a digitally signed message part.
Re: Using userbase for manuals
Le lundi 2 juillet 2012 07:01:06 Inge Wallin a écrit : Now, the suggestion was to move to a wiki instead Advantages: 1. Easier to find the documentation for potential writers. 2. (Supposedly) easier to edit [Personally I'm not sure that editing advanced wiki markup is easier than docbook] Disadvantages: 1. Difficult to maintain different versions of the documentation for different versions of the software. 2. Users need to be online to view the documentation. I think that calling this problem vanishingly rare is a very northern Europe centric view. And even I who have excellent broadband often still do work offline sometimes. Have it been considered to use a git-based wiki? Such a solution could make it possible to: - keep documentation within the code (or close enough) - web editing for people who are not familiar with git, offline editing for advanced users (or for when you want to write documentation offline) - branching the documentation to follow versions One could probably produce offline KHelpCenter-compatible documentation from it. I know at least one wiki which is git-based: Ikiwiki [1][2]. I have no idea if it can be adapted to our needs, but I think it is an approach worth looking at. [1]: http://ikiwiki.info/ [2]: https://en.wikipedia.org/wiki/Ikiwiki
Re: Review Request: Move KdepimLibs dependency to DrKonqi
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105402/#review15336 --- Was this actually asked by packagers? I am no expert, but the feedback I had from a Debian packager working on CMake projects was that he preferred to have all dependencies listed in the top-level CMakeLists.txt. The reason he gave were: - It is easier to list all dependencies this way - It avoids the situation where A/CMakeLists.txt has an optional dependency on package Foo and B/CMakeLists.txt has a mandatory dependency on Foo (possibly added later). - Aurélien Gâteau On July 1, 2012, 4:23 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105402/ --- (Updated July 1, 2012, 4:23 p.m.) Review request for KDE Runtime and George Kiagiadakis. Description --- This patch moves the dependency on KdepimLibs to /drkonqi, since that's the program requiring it. This is done to assist downstream packaging. Diffs - CMakeLists.txt 5091890a0768fd553f972a9b113f7f826d63f356 drkonqi/CMakeLists.txt 102185ac52f558fba78cf2da80a1e8a0fe870e18 Diff: http://git.reviewboard.kde.org/r/105402/diff/ Testing --- Thanks, Michael Palimaka
Re: Review Request: Move KdepimLibs dependency to DrKonqi
On July 3, 2012, 12:07 p.m., Aurélien Gâteau wrote: Was this actually asked by packagers? I am no expert, but the feedback I had from a Debian packager working on CMake projects was that he preferred to have all dependencies listed in the top-level CMakeLists.txt. The reason he gave were: - It is easier to list all dependencies this way - It avoids the situation where A/CMakeLists.txt has an optional dependency on package Foo and B/CMakeLists.txt has a mandatory dependency on Foo (possibly added later). Mmm... I didn't notice you were working on Gentoo. You most likely know more than I do, but still I would be interested to know how this change helps you. - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105402/#review15336 --- On July 1, 2012, 4:23 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105402/ --- (Updated July 1, 2012, 4:23 p.m.) Review request for KDE Runtime and George Kiagiadakis. Description --- This patch moves the dependency on KdepimLibs to /drkonqi, since that's the program requiring it. This is done to assist downstream packaging. Diffs - CMakeLists.txt 5091890a0768fd553f972a9b113f7f826d63f356 drkonqi/CMakeLists.txt 102185ac52f558fba78cf2da80a1e8a0fe870e18 Diff: http://git.reviewboard.kde.org/r/105402/diff/ Testing --- Thanks, Michael Palimaka
Re: Using userbase for manuals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 03.07.2012 14:00, schrieb Aurélien Gâteau: Le lundi 2 juillet 2012 07:01:06 Inge Wallin a écrit : Now, the suggestion was to move to a wiki instead Advantages: 1. Easier to find the documentation for potential writers. 2. (Supposedly) easier to edit [Personally I'm not sure that editing advanced wiki markup is easier than docbook] Disadvantages: 1. Difficult to maintain different versions of the documentation for different versions of the software. 2. Users need to be online to view the documentation. I think that calling this problem vanishingly rare is a very northern Europe centric view. And even I who have excellent broadband often still do work offline sometimes. Have it been considered to use a git-based wiki? Such a solution could make it possible to: - keep documentation within the code (or close enough) - web editing for people who are not familiar with git, offline editing for advanced users (or for when you want to write documentation offline) - branching the documentation to follow versions One could probably produce offline KHelpCenter-compatible documentation from it. I know at least one wiki which is git-based: Ikiwiki [1][2]. I have no idea if it can be adapted to our needs, but I think it is an approach worth looking at. [1]: http://ikiwiki.info/ [2]: https://en.wikipedia.org/wiki/Ikiwiki There is also gitit. But from what i can tell, they don't provide a way to import content from mediawiki. And looking at the number of pages our wikis have at this stage, this is a major drawback. Additionally we will loose support for quite some plugins, most notably the translate extension, which is integral part of this entire discussion. So we would be back at manually copying the english original and translating an entire page without being notified of further changes to the original. All that for the sake of using a commandline tool instead of a browser? - -- Ingo Malchow (neverendingo) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/y8S0ACgkQgFDgF4YW7se/iwCePyJqWPKlpcNU0AvRK7MaaMww jt4AoKasW+DmSp7EmDWzSzpc1XQVQNiL =qjP3 -END PGP SIGNATURE-
Re: Using userbase for manuals
Le mardi 3 juillet 2012 15:18:37 Ingo Malchow a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 03.07.2012 14:00, schrieb Aurélien Gâteau: Le lundi 2 juillet 2012 07:01:06 Inge Wallin a écrit : Now, the suggestion was to move to a wiki instead Advantages: 1. Easier to find the documentation for potential writers. 2. (Supposedly) easier to edit [Personally I'm not sure that editing advanced wiki markup is easier than docbook] Disadvantages: 1. Difficult to maintain different versions of the documentation for different versions of the software. 2. Users need to be online to view the documentation. I think that calling this problem vanishingly rare is a very northern Europe centric view. And even I who have excellent broadband often still do work offline sometimes. Have it been considered to use a git-based wiki? Such a solution could make it possible to: - keep documentation within the code (or close enough) - web editing for people who are not familiar with git, offline editing for advanced users (or for when you want to write documentation offline) - branching the documentation to follow versions One could probably produce offline KHelpCenter-compatible documentation from it. I know at least one wiki which is git-based: Ikiwiki [1][2]. I have no idea if it can be adapted to our needs, but I think it is an approach worth looking at. [1]: http://ikiwiki.info/ [2]: https://en.wikipedia.org/wiki/Ikiwiki There is also gitit. But from what i can tell, they don't provide a way to import content from mediawiki. And looking at the number of pages our wikis have at this stage, this is a major drawback. Additionally we will loose support for quite some plugins, most notably the translate extension, which is integral part of this entire discussion. So we would be back at manually copying the english original and translating an entire page without being notified of further changes to the original. I don't think one need to have all wiki content transfered to a git-based wiki. I see this as a new tool to collaboratively write documentation which happens to be a wiki, but not necessarily as a replacement for our existing wikis. But then, having different wikis can (will) lead to problems... All that for the sake of using a commandline tool instead of a browser? Being able to use a commandline tool is just a (nice) side-effect. The main advantage of a git-based wiki is being able to branch the wiki for releases. Aurélien
Re: Using userbase for manuals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 03.07.2012 18:07, schrieb Aurélien Gâteau: Le mardi 3 juillet 2012 15:18:37 Ingo Malchow a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 03.07.2012 14:00, schrieb Aurélien Gâteau: Le lundi 2 juillet 2012 07:01:06 Inge Wallin a écrit : Now, the suggestion was to move to a wiki instead Advantages: 1. Easier to find the documentation for potential writers. 2. (Supposedly) easier to edit [Personally I'm not sure that editing advanced wiki markup is easier than docbook] Disadvantages: 1. Difficult to maintain different versions of the documentation for different versions of the software. 2. Users need to be online to view the documentation. I think that calling this problem vanishingly rare is a very northern Europe centric view. And even I who have excellent broadband often still do work offline sometimes. Have it been considered to use a git-based wiki? Such a solution could make it possible to: - keep documentation within the code (or close enough) - web editing for people who are not familiar with git, offline editing for advanced users (or for when you want to write documentation offline) - branching the documentation to follow versions One could probably produce offline KHelpCenter-compatible documentation from it. I know at least one wiki which is git-based: Ikiwiki [1][2]. I have no idea if it can be adapted to our needs, but I think it is an approach worth looking at. [1]: http://ikiwiki.info/ [2]: https://en.wikipedia.org/wiki/Ikiwiki There is also gitit. But from what i can tell, they don't provide a way to import content from mediawiki. And looking at the number of pages our wikis have at this stage, this is a major drawback. Additionally we will loose support for quite some plugins, most notably the translate extension, which is integral part of this entire discussion. So we would be back at manually copying the english original and translating an entire page without being notified of further changes to the original. I don't think one need to have all wiki content transfered to a git-based wiki. I see this as a new tool to collaboratively write documentation which happens to be a wiki, but not necessarily as a replacement for our existing wikis. But then, having different wikis can (will) lead to problems... Indeed, and probably one of the times where diversity is not necessarily improving the situation. It might only lead to just another tool, which is a) not used or b) used and reduces quality of existing other wikis due to missing motivation, which are - if i understood correctly - not supposed to be closed. All that for the sake of using a commandline tool instead of a browser? Being able to use a commandline tool is just a (nice) side-effect. The main advantage of a git-based wiki is being able to branch the wiki for releases. Aurélien In an ideal world we could really work around such issues with some semi-automated ways. Just an idea: Those who do like the idea of doing a manual in a online wiki could just teach their respective users how to properly format their manual. This reduces the overhead on developers, but also improves the integration of user contribution. Once a release is about to happen the page can be closed (protected from further editing) and exported to docbook and put into some git/svn repo. This needs some adjustments on the docbook export, but those are technical details, so i skip that here. At the same time our group leaders for languages can be poked to review their translations on the current state of it. Which is AFAIR the workflow on the offline translations as well. Now you can easily translate on- or offline in the usual way and it can finally be merged in the final manual release. As sidenote for those without internet, we can also produce a pdf at release dates, not sure everybody is aware of that. Much of it needs some admin being around, but that is not a problem anymore these days, response time is usually less than a day. This is just an idea which could improve the combination of both workflows, as i see benefits in both of them (vcs vs. web) Cheerio, - -- Ingo Malchow (neverendingo) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/zHMkACgkQgFDgF4YW7se18ACfT6U91LaFVRwXk7R+5mgxEYTS 0XIAoKsBKJVMKhLi3XJB7Ijs3kM0EZkk =UNU0 -END PGP SIGNATURE-
Re: Using userbase for manuals
Le mardi 3 juillet 2012 18:24:41 Ingo Malchow a écrit : In an ideal world we could really work around such issues with some semi-automated ways. Just an idea: Those who do like the idea of doing a manual in a online wiki could just teach their respective users how to properly format their manual. This reduces the overhead on developers, but also improves the integration of user contribution. Once a release is about to happen the page can be closed (protected from further editing) and exported to docbook and put into some git/svn repo. This needs some adjustments on the docbook export, but those are technical details, so i skip that here. At the same time our group leaders for languages can be poked to review their translations on the current state of it. Which is AFAIR the workflow on the offline translations as well. Now you can easily translate on- or offline in the usual way and it can finally be merged in the final manual release. As sidenote for those without internet, we can also produce a pdf at release dates, not sure everybody is aware of that. I like your idea: it let users collaboratively write documentation on the wiki, while still making it possible to produce formal offline-usable manual at release time. The only thing which worries me is updates of stable versions of the manual: is it possible to maintain stable and master versions of the documentation in the wiki? Aurélien
Review Request: kjs: Implement html5 HTMLSelectCollectionProtoFunc::remove
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105430/ --- Review request for kdelibs. Description --- kjs: Implement html5 HTMLSelectCollectionProtoFunc::remove with this getElementById(mySELECT).options.remove(index) getElementById(mySELECT).remove(index) works as described in http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#dom-htmloptionscollection-remove Diffs - khtml/ecma/kjs_html.h 089b550 khtml/ecma/kjs_html.cpp d64e07c Diff: http://git.reviewboard.kde.org/r/105430/diff/ Testing --- Thanks, Bernd Buschinski
Re: Review Request: Don't append 0- when dragging and dropping from trash
On June 19, 2012, 5:55 a.m., David Faure wrote: Good idea, but it seems to break the case where nested dirs exist in the directory being restored. Everything gets flattened out. Probably a bug in CopyJob though, in the handling of fileNameUsedForCopying=DisplayName Michael Reeves wrote: From what I can tell when moveAs or copyAs is called CopyJob doesn't use the UDSEntry information to determine the destination path. Why I don't know. I found a possible solution if the trash id could some how be determined without having it in the URL. I have this setup working with the trashId hard coded to 0 and fileNameUsedForCopying=Name. Obviously not suitable for general use I only have one trash folder so I this works for me. Who would have more information on CopyJob? I would prefer not to mess with the URL if it can be avoided. - Michael --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105078/#review14874 --- On June 18, 2012, 5:39 p.m., Michael Reeves wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105078/ --- (Updated June 18, 2012, 5:39 p.m.) Review request for KDE Runtime. Description --- This patch makes drag-and-drop and cut/paste from trash preserve the orginal filename instead of appending 0-. This addresses bug 183403. http://bugs.kde.org/show_bug.cgi?id=183403 Diffs - kioslave/trash/kio_trash.cpp 4187f45 kioslave/trash/trash.protocol f96d4a1 Diff: http://git.reviewboard.kde.org/r/105078/diff/ Testing --- I have used the modified io_trash module on my machine since before the KDE 4.8 release and still use it under KDE 4.8.3. Thanks, Michael Reeves
