boot to uefi action represented by check box
Hi, in System Settings -> Startup and Shutdown -> Desktop Session we have a check box labelled After next restart: [ ] Enter UEFI Setup screen (see attached screen shot) Is there a reason we do not use a button for this? How it currently works is, if I set the check box, a button appears which I then have to click. Additionally the Apply button of that page activates and I can apply the "settings change" ... which is not applied, because it resets on boot. So what is the reason behind this rather exotic work flow? Cheers, Frederik
Re: Re : KApiDox move from dedicated server to Jenkins
Hi, On 9/10/21 21:17, Ben Cooksley wrote: On Sat, Sep 11, 2021 at 5:40 AM Carl Schwan wrote: We also are losing the krita/kmymoney/other app private api generation, but that maybe can be generated in another ci pipeline later. Not sure how much thses apps' developers are using it. This can likely be rectified if needed by including them within https://invent.kde.org/sysadmin/binary-factory-tooling/-/blob/master/apidocs/repos-to-process So, we would need to decide whether we want to have applications that only have private APIs documented? Where do we draw the line currently? In general I would say, just generate everything that has a Doxyfile ... but there might be good reasons against that regarding processing power? Cheers, Frederik
Re: Re : KApiDox move from dedicated server to Jenkins
Hi, On 9/10/21 19:39, Carl Schwan wrote: I see on an issue that I would qualify as blocking and it's the lack of the ECM generated doc: https://api-dev.kde.org/ecm. We are also losing the kube/sink doc (located at api.kde.org/doc/sink) but it's also available in readthedocs and ihmo it should be in Doxygen format. We also are losing the krita/kmymoney/other app private api generation, but that maybe can be generated in another ci pipeline later. Not sure how much thses apps' developers are using it. Thanks for the list. I will look into those. On the upside, I see that mauikit doc is finally correctly generated using qdoc. Yeah \o/ mauikit produces some warnings, in case someone wants to fix those (or tone down the warning level): https://binary-factory.kde.org/job/Generate_API_Documentation/13/consoleFull There are also other warnings and errors, I will look at soon. Those are secondary though, as in they have been there before. Cheers, Frederik
Re: KApiDox move from dedicated server to Jenkins
Hi, On 9/11/21 00:30, Ben Cooksley wrote: I've now completed transferring a copy of all of the Older API Documentation to https://api-dev.kde.org/legacy/ This is aliased in from elsewhere on the server, so it's contents won't be disturbed by the automatic generation process we have for new KApiDox based documentation. I also included the legacy CMake documentation when setting that up. If we could please update the front page to point there that should resolve this point. For me it makes more sense to keep the link to api.kde.org because once we switch to the new system, we would have to change that link again. Now with all the files in place (thanks for that :)) the links will just continue to work. Cheers, Frederik
KApiDox move from dedicated server to Jenkins
Hi, we have been working on getting KApiDox to run on Jenkins. This work has been taken way longer than I expected but has now reached a state close to finished. :) So I would like to invite you to check https://api-dev.kde.org/ for any show stoppers. Known issues (not show stoppers): - For now the Maintainers field defaults to "KDE Developers" for potential GDPR violation reasons, which needs to be figured out later. - Some modules contain formatting issues regarding markdown code blocks. These are also there in the current system and need to be checked at some point. - The "Older versions" links are broken. Since those docs are not generated anymore, we need to figure out a way to have them available statically. If we do not see any bigger issues, I would like to go live with the new system in a week or two. Thanks for your help. CHeers, Frederik
Re: Noteworthy changes when porting to C++17
On 7/19/21 5:52 PM, David Faure wrote: On dimanche 18 juillet 2021 02:34:24 CEST Frederik Schwarzer wrote: So the question is: did you notice things that have been removed from the C++ standard since C++11 that were used in our applications? I found a list of things that were removed from C++11 in C++17: http://www.cplusplus2017.info/removed-features-from-c17/ Maybe you can simply link to this document? Thanks for the link. :) Yes, it was my plan to link to such kind of information but I was also thinking of going into a bit more detail on one or two of those in case they were quite common in KDE land. But apparently this is not the case. Cheers, Frederik
Re: Noteworthy changes when porting to C++17
Hi, Thanks for the links. I know about those papers but I do not think we should point KF6 application porters there because the vast majority of the stuff mentioned is very unlikely to affect them. For now I will go with some general remarks here. Cheers, Frederik On 7/18/21 10:22 AM, David Redondo wrote: Hi I found these two papers http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1319r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0636r1.html Regards, David
Noteworthy changes when porting to C++17
Hi, since we are increasing the C++ standard requirement from 11 to 17 with KF6 and there were a few deprecations/removals in between, I wonder if any of those are noteworthy for people developing applications based on KDE Frameworks. What I mean by "noteworthy" is features that are commonly used or at least known to be used sometimes in our ecosystem. Things like the "register" keyword for example might not be found in high-level applications so pointing KDE developers to its removal might get you shrugs in return. What I have seen is that std::mem_fun was used within KIO and has been replaced by std::mem_fn. Not sure if that counts as "commonly used", though. Compiler vendors seem to be handling those removalss differently. The libstdc++ devs have not had deprecation warnings for at least some of the stuff that was deprecated in C++11, so they will not remove those any time soon. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91383#c1 In libc++, the deprecation warnings were shown since C++11 and now with C++17 they removed some stuff. On Linux you will have to build with the -stdlib=libc++ option for clang to notice. See e.g. https://godbolt.org/z/6Y1eE3z4P for playing with it. But I digress ... So the question is: did you notice things that have been removed from the C++ standard since C++11 that were used in our applications? Cheers, Frederik
Re: Porting notes / deprecation docs
On 7/12/21 8:43 PM, Friedrich W. H. Kossebau wrote: Am Montag, 12. Juli 2021, 20:22:30 CEST schrieb Frederik Schwarzer: On 7/12/21 7:38 PM, Friedrich W. H. Kossebau wrote: Now what is meant by "clickable links to replacements" exactly? Any example for what you have in mind? (Just in case, Doxygen usually itself already generated automatic links to the functions (just needs complete signature, incl. const), see also https://www.doxygen.nl/manual/autolink.html but then I would guess you know that) Yes, that's what I meant. api.k.o does have clickable links (if done properly) but compiler warnings do not. That's why it would be good to keep the KF5 api docs. Ah, so html pages on a server/local docs in QCH vs. compiler log, I see :) If we put URLs in the messages, we could click them in Konsole. ;) Any insight on how you kept the KDE 2-4 apidocs alive? Mainly defending against admin wanting to clean up dead stuff and just wiping the current freak setup behind api.kde.org ;) (which is https:// invent.kde.org/websites/quality-kde-org) Right now the kdelibs 2-4 docs are no longer regenerated (at the time when I got involved only the 4 one still was, but now also no longer is, and just is static files on the web server. I did some URL updates e.g. for trolltech.com- qt.io using mass regexp replacements on them). IIRC main file of the generation is https://invent.kde.org/websites/quality-kde-org/-/blob/master/apidox/src/ gendox.sh But I dropped out when there were people talking about their progress in writing a replacement and put my hopes & bet on them. But seems life got in then it seems... I cannot check what is used on the server but I was told https://invent.kde.org/frameworks/kapidox/-/blob/master/src/kapidox_generate would be the script that generates apidocs on the server. Maybe someone can clarify? CHeers, Frederik
Re: Porting notes / deprecation docs
On 7/12/21 7:38 PM, Friedrich W. H. Kossebau wrote: Some hopefully helpful quick comments from couch: Am Montag, 12. Juli 2021, 19:14:17 CEST schrieb Frederik Schwarzer: - If not documented separately, should existing deprecation messages be improved? "no known users" might not be enough for the "unknown users" in 3rd-party applications who get that message Yes, ideally that should be backed up by some web page perhaps, informing anyone how to get in touch with whom to make a user and their needs known, for finding a solution. - Is it possible/desirable to keep the latest KF5 API docs as it is generated on api.k.o to have deprecation messages with clickable links to replacements? When doing my own little contributions to keep api.kde.org alive last year, I also made sure to have the so far existing kdelibs 2-4 API still available, see https://api.kde.org/history.php (reached via "Old KDE Versions" from api.kde.org mainpage). The same hopefully can be done for KF5 (and other libraries who would need versioned docs). Now what is meant by "clickable links to replacements" exactly? Any example for what you have in mind? (Just in case, Doxygen usually itself already generated automatic links to the functions (just needs complete signature, incl. const), see also https://www.doxygen.nl/manual/autolink.html but then I would guess you know that) Yes, that's what I meant. api.k.o does have clickable links (if done properly) but compiler warnings do not. That's why it would be good to keep the KF5 api docs. Any insight on how you kept the KDE 2-4 apidocs alive? Cheers, Frederik
Re: Porting notes / deprecation docs
Hi, so there has been a bit more discussion in today's KF6 weekly meeting about how to proceed with porting docs. - Porting documentation needs an entry page pointing to the several resources like C++ deprecations, Qt6 porting guides, KF6 porting notes - KF6 porting notes should follow a similar approach like Qt6 porting (first compile with the latest KF5 version, which will be part of distros for quite some time and get rid of all deprecation warnings and then make it compile against KF6) - Might it be a good idea to document a selected set of API deprecations to have them in a readable format? Candidates are ones where it needs more that one or two lines of explanation - If not documented separately, should existing deprecation messages be improved? "no known users" might not be enough for the "unknown users" in 3rd-party applications who get that message - Is it possible/desirable to keep the latest KF5 API docs as it is generated on api.k.o to have deprecation messages with clickable links to replacements? Opinions/additions? Cheers, Frederik On 7/11/21 2:24 PM, Frederik Schwarzer wrote: Hi, On 7/10/21 11:54 PM, Friedrich W. H. Kossebau wrote: Am Samstag, 10. Juli 2021, 22:47:58 CEST schrieb Frederik Schwarzer: Hi, On 7/10/21 7:38 PM, Friedrich W. H. Kossebau wrote: Am Samstag, 10. Juli 2021, 18:00:13 CEST schrieb Frederik Schwarzer: as mentioned earlier Any pointers? :) It was discussed in the weekly BBB meetings a few weeks ago. I see. As contributor on occasions only myself, please refer to the respective meeting notes some thankfully write, so one can read up on more background, and such a planned task ideally would be backed up by a task board entry on phabricator, so people can coordinate and track things about it in an async manner. https://mail.kde.org/pipermail/kde-frameworks-devel/2021-June/117653.html Of course that out-of-context sentence at the end does not represent properly what has been said by people then. Some follow-up discussion lead to the "just grep it and put it somewhere first" approach. What I take out of this now is that I need to be more phony about what I am planning on doing. I would like to document classes/methods/etc that are going to be deprecated during KF6 development. Can you help confused-on-first-read people by explaining what "deprecated during KF6 development" is referring to? Deprecated during KF5 development and no longer be available in KF6? Not yet deprecated due to no existing replacement, but with replacement planned in KF6? Everything that is marked deprecated when KF6 sees the light of day. Okay. Not a good idea IMHO. There should be a single place of information, and we have that already with the current KF5 API docs. I hope no-one plans to just remove them from the website, though, Well, then there are also the offline docs in QCH format as backup generated during the builds and packaged by good distributions ;) The idea is to have the APIs that are being deprecated now documented when those APIs (and with it the API docs) are removed. The audience is everyone who is starting the porting work when KF6 is already there for some time. Ideally that audience should get the recommendation to first port away from deprecated API using the last released version of KF5 and Qt6. That way they are able to do a big chunk of the work while being able to maintain a fully working state of their software, without serious regressions. Once that checkpoint is reached, then go for porting all those things which disappeared/ changed in KF6 & Qt6 without any preparations in KF5 & Qt5. Remember that this is not just KF 5 -> 6, but also Qt 5 -> 6. And perhaps even C++11 -> C++17. IMHO only those would recommend to port directly from one set of APIs to an other one without any intermediate checkppints for the working sate of the software who want to secure their job for a while, because it will take ages to fix all the regressions introduced during the port. Unless the company/community goes down in the meantime, because the ported software does not get done. BTW, even the Qt Company recommends that step-by-step approach, and they surely do want to have their customers be successful in a short time ;) -> https://doc.qt.io/qt-6/portingguide.html That is also why some of us invested so much of our time into properly tagging API with deprecations warning macros and visibility guards, so porting can be done step by step away from the old AP assisted by the compiler, always having a working software. Because we have been through some porting in KDE and learned our lessons, haven't we... ;) Yes it is manual work. However, since the documentation does not remove stuff that has been removed from the API, it's a thing of adding newer deprecation markers, which seems manageable. While perhaps it might be a nice thing to
Re: Porting notes / deprecation docs
Hi, On 7/10/21 11:54 PM, Friedrich W. H. Kossebau wrote: Am Samstag, 10. Juli 2021, 22:47:58 CEST schrieb Frederik Schwarzer: Hi, On 7/10/21 7:38 PM, Friedrich W. H. Kossebau wrote: Am Samstag, 10. Juli 2021, 18:00:13 CEST schrieb Frederik Schwarzer: as mentioned earlier Any pointers? :) It was discussed in the weekly BBB meetings a few weeks ago. I see. As contributor on occasions only myself, please refer to the respective meeting notes some thankfully write, so one can read up on more background, and such a planned task ideally would be backed up by a task board entry on phabricator, so people can coordinate and track things about it in an async manner. https://mail.kde.org/pipermail/kde-frameworks-devel/2021-June/117653.html Of course that out-of-context sentence at the end does not represent properly what has been said by people then. Some follow-up discussion lead to the "just grep it and put it somewhere first" approach. What I take out of this now is that I need to be more phony about what I am planning on doing. I would like to document classes/methods/etc that are going to be deprecated during KF6 development. Can you help confused-on-first-read people by explaining what "deprecated during KF6 development" is referring to? Deprecated during KF5 development and no longer be available in KF6? Not yet deprecated due to no existing replacement, but with replacement planned in KF6? Everything that is marked deprecated when KF6 sees the light of day. Okay. Not a good idea IMHO. There should be a single place of information, and we have that already with the current KF5 API docs. I hope no-one plans to just remove them from the website, though, Well, then there are also the offline docs in QCH format as backup generated during the builds and packaged by good distributions ;) The idea is to have the APIs that are being deprecated now documented when those APIs (and with it the API docs) are removed. The audience is everyone who is starting the porting work when KF6 is already there for some time. Ideally that audience should get the recommendation to first port away from deprecated API using the last released version of KF5 and Qt6. That way they are able to do a big chunk of the work while being able to maintain a fully working state of their software, without serious regressions. Once that checkpoint is reached, then go for porting all those things which disappeared/ changed in KF6 & Qt6 without any preparations in KF5 & Qt5. Remember that this is not just KF 5 -> 6, but also Qt 5 -> 6. And perhaps even C++11 -> C++17. IMHO only those would recommend to port directly from one set of APIs to an other one without any intermediate checkppints for the working sate of the software who want to secure their job for a while, because it will take ages to fix all the regressions introduced during the port. Unless the company/community goes down in the meantime, because the ported software does not get done. BTW, even the Qt Company recommends that step-by-step approach, and they surely do want to have their customers be successful in a short time ;) -> https://doc.qt.io/qt-6/portingguide.html That is also why some of us invested so much of our time into properly tagging API with deprecations warning macros and visibility guards, so porting can be done step by step away from the old AP assisted by the compiler, always having a working software. Because we have been through some porting in KDE and learned our lessons, haven't we... ;) Yes it is manual work. However, since the documentation does not remove stuff that has been removed from the API, it's a thing of adding newer deprecation markers, which seems manageable. While perhaps it might be a nice thing to have a shortcut list of API that is deprecated in KF5 times, as a manifest to look-up things, ideally we find ways to auto-generate that from the existing API markup. After all KDE is a software developing community, so we should be able to automate that, no? ;) So, I can only really ask to keep documentation of KF5's deprecated API in one place, and do it properly there, with nice examples, already now useful to those who port away when they can. And that place should be the current KF5 API docs. Even more as people come and go, and having yet another place which needs to be kept even more manually up-tod-ate does not improve things, it adds more risk to have outdated unmaintained information. As you could see in review, it already now needs poking in every second review to have proper documentation. And then also do that in some separate content? What would be very good to have though IMHO, are preparations of the porting documentation of that API which is not deprecated in KF5, but will be replaced by something else in KF6 (because it cannot be done earlier for reasons). The KF6 task board should have some data about such plans. Such documentation will need a place and a
Re: Porting notes / deprecation docs
Hi, On 7/10/21 7:38 PM, Friedrich W. H. Kossebau wrote: Am Samstag, 10. Juli 2021, 18:00:13 CEST schrieb Frederik Schwarzer: as mentioned earlier Any pointers? :) It was discussed in the weekly BBB meetings a few weeks ago. I would like to document classes/methods/etc that are going to be deprecated during KF6 development. Can you help confused-on-first-read people by explaining what "deprecated during KF6 development" is referring to? Deprecated during KF5 development and no longer be available in KF6? Not yet deprecated due to no existing replacement, but with replacement planned in KF6? Everything that is marked deprecated when KF6 sees the light of day. For that I scraped up all the deprecation macros from the frameworks and edited them to be more unified. That sounds like duplication of data, and worse, a manual copy of a certain state, which also needs to be manually maintained to be up-to-date to stay useful. In general I am also curious what audience is targeted by the planned documentation and in which work-flows that documentation should solve which needs, and what other solutions are there which would not satisfy those needs well enough? In general, for API already deprecated now during lifetime of KF5 we are adding porting notes to the very API itself. Which is also the place as API consumer I would be hoping for to get all needed information straight in one go, instead of having to jump to other places, which might even get out of sync or focus of developers (remember that current online docs of api.kde.org also only provide docs for latest version (and even the development one, not just the latest released). And this is a change to what happened in kdelibs4 times, where most deprecation happened in the development branches for what became KDE Frameworks, so there also was no API documentation maintained at the same time. So copying the approach taken for the KDE Frameworks porting notes would not be needed here 1:1 for what I understand. Instead we would need to add documentation for those things which are again deprecated (well, removed rather) during preparation of KF6, where the replacement also only will be in KF6, so no-one can port before. The idea is to have the APIs that are being deprecated now documented when those APIs (and with it the API docs) are removed. The audience is everyone who is starting the porting work when KF6 is already there for some time. Yes it is manual work. However, since the documentation does not remove stuff that has been removed from the API, it's a thing of adding newer deprecation markers, which seems manageable. Do you disagree? Cheers, Frederik
Re: Porting notes / deprecation docs
On 7/10/21 6:17 PM, Ahmad Samir wrote: On 10/07/2021 18:00, Frederik Schwarzer wrote: Hi, as mentioned earlier, I would like to document classes/methods/etc that are going to be deprecated during KF6 development. For that I scraped up all the deprecation macros from the frameworks and edited them to be more unified. Good work, that must have been a huge task! (82 frameworks ... :)). grep ran a few seconds to give me a 2600 lines text file, which I then had to edit to be more readable, which took me several hours. :) The hard part is still about to come. :) As for the location, I would probably start putting content in the community wiki to a place like https://community.kde.org/Frameworks/KF6_Porting_Notes. Does anyone see a problem with that? Might is be better to write such docs in markdown or restructured text for being better suited for a more modern location? A wiki page is not most friendly way of editing huge technical documents. Personally, I think a markdown file in a git repo would be great, and then it can be "published" to a wiki page or a static web page on one of KDE's web sites. Or, we start with an markdown text file, then after it's fleshed out / polished, put it in the wiki, editing/adding a small section here or there would be easier. (But I do prefer text files, much easier to edit in my usual editor of choice). Yes, I agree. A text file in Git is also better for tracking changes. FWIW, there is supposed to be a KF6 meeting soon[1]. Not sure if we'll start this week or the next one though. I have the Mondays on my calendar now. :)
Porting notes / deprecation docs
Hi, as mentioned earlier, I would like to document classes/methods/etc that are going to be deprecated during KF6 development. For that I scraped up all the deprecation macros from the frameworks and edited them to be more unified. Now I need some opinions. For once, there is still some stuff in deprecation from KDE4 times. E.g. void setDoScanFile(bool scanFile); from kiowidgets. I looked up a few of them in https://community.kde.org/Frameworks/Porting_Notes but they are not mentioned there. Do you think these need to be mentioned in current porting notes as well or have they been deprecated for long enough to consider them "over with"? As for the location, I would probably start putting content in the community wiki to a place like https://community.kde.org/Frameworks/KF6_Porting_Notes. Does anyone see a problem with that? Might is be better to write such docs in markdown or restructured text for being better suited for a more modern location? Thanks! Cheers, Frederik
Re: Progress is good for us but bad for documentation
Hi everyone, thank you for your input and sorry it took me a while to reply. For now I have created a list of issues on gitlab to be reminded. https://invent.kde.org/teams/documentation/sprints/-/issues Some issues I started to investigate but was struck by kapidox_generate being broken on my local machine. This is now addressed and will hopefully be fixed soon. :) Others like the KXmlGui ones I reply to here, I will play through at some point and look what I can do to fill some holes. Feel free to add issues to the issues list as you stumble over them. Cheers, Frederik On 6/14/21 2:00 PM, David Hurka wrote: Hi Frederik, here is my report about a negative experience with existing documentation: So what to report? Documentation that ... - [...] - has holes in it. For example a tutorial where you suddenly think, you skipped an important step. - you wish was there but you could not find it. When I tried to understand KXmlGui an KParts (about 15 months ago?), I felt left alone from the documentation. KXmlGui: KXmlGui explains itself as user configurable main windows (toolbars, shortcuts), which should be enough for an introduction. But KXmlGui docs didn’t give me examples how to use it. Just creating a KXmlGui main window and putting a KXmlGuiClient in it didn’t work as easy as setting the main widget of a QMainWindow. My experiment application always crashed at startup. Here I would expect some minimal working examples. It also misses an introduction about merging multiple KXmlGuiClients to one user interface. KParts: KParts didn’t tell me what the whole framework is good for. After reading the documentation, I doubted that a KPart is anything more than a KXmlGuiClient with another name or even a QWidget with a list of actions. Why not just instantiate a QWidget derived object from a library, and put that QWidget in my main window? Here I would expect an introduction why I should use KParts. Only KReadOnlyPart and KReadWritePart made some sense for me. These were able to provide reading and writing files through KIO just through the openUrl() and saveAs() methods. And Konqueror can search for a KReadOnlyPart that allows to open a specific document type, and use this part through a common API. Cheers, David
Re: Progress is good for us but bad for documentation
On 6/9/21 6:02 PM, Johannes Zarl-Zierl wrote: Hi, Am Mittwoch, 9. Juni 2021, 01:20:23 CEST schrieb Frederik Schwarzer: I would like to ask you to report such documentation to me. We see the topic come up here and there but it then sometimes sinks into oblivion again because it was part of a merge request that has then been merged or so. [...] So what to report? Documentation that ... - explains outdated technology or concepts like KDE 4 or HAL. - has holes in it. For example a tutorial where you suddenly think, you skipped an important step. - you wish was there but you could not find it. Is this an effort with universal scope, or is there a limit? Obviously you are at least talking about the wikis. Are you also (at the current time) talking about other websites and/or application handbooks? It is meant as an open question. All answers welcome. Of course not everything can be worked on now. But compiling a list of stuff to work on will help pushing and coordinating the work. heers, Frederik
Re: Progress is good for us but bad for documentation
On 6/9/21 6:02 PM, Johannes Zarl-Zierl wrote: Hi, Am Mittwoch, 9. Juni 2021, 01:20:23 CEST schrieb Frederik Schwarzer: I would like to ask you to report such documentation to me. We see the topic come up here and there but it then sometimes sinks into oblivion again because it was part of a merge request that has then been merged or so. [...] So what to report? Documentation that ... - explains outdated technology or concepts like KDE 4 or HAL. - has holes in it. For example a tutorial where you suddenly think, you skipped an important step. - you wish was there but you could not find it. Is this an effort with universal scope, or is there a limit? Obviously you are at least talking about the wikis. Are you also (at the current time) talking about other websites and/or application handbooks? It is meant as an open question. All answers welcome. Of course not everything can be worked on now. But compiling a list of stuff to work on will help pushing and coordinating the work. heers, Frederik
Progress is good for us but bad for documentation
Hi, we are all making progress but the way to notice it can be painful. Looking at something you created years ago might make you cringe, but that's actually a good sign. It indicates, that you made progress. KDE is making progress as well. Here the indicator is outdated documentation. There is still quite some documentation from KDE 4 times where the technology documented already moved on to more modern times. And just as your résumé needs updating once in a while to reflect your newly acquired skills and references, documentation needs updating so it reflects the current state of KDE (as in software, places to communicate, go-to people for all the several parts of the projects, etc.). I would like to ask you to report such documentation to me. We see the topic come up here and there but it then sometimes sinks into oblivion again because it was part of a merge request that has then been merged or so. So to let me know, you can send me an email (on- or off-list) and I will create a ticket for it where further discussion can take place. Of course you could theoretically open a ticket yourself but we still need to find the best place for those topics. I will keep you posted on that one. :) So what to report? Documentation that ... - explains outdated technology or concepts like KDE 4 or HAL. - has holes in it. For example a tutorial where you suddenly think, you skipped an important step. - you wish was there but you could not find it. Thanks a bunch. :) Cheers, Frederik
Progress is good for us but bad for documentation
Hi, we are all making progress but the way to notice it can be painful. Looking at something you created years ago might make you cringe, but that's actually a good sign. It indicates, that you made progress. KDE is making progress as well. Here the indicator is outdated documentation. There is still quite some documentation from KDE 4 times where the technology documented already moved on to more modern times. And just as your résumé needs updating once in a while to reflect your newly acquired skills and references, documentation needs updating so it reflects the current state of KDE (as in software, places to communicate, go-to people for all the several parts of the projects, etc.). I would like to ask you to report such documentation to me. We see the topic come up here and there but it then sometimes sinks into oblivion again because it was part of a merge request that has then been merged or so. So to let me know, you can send me an email (on- or off-list) and I will create a ticket for it where further discussion can take place. Of course you could theoretically open a ticket yourself but we still need to find the best place for those topics. I will keep you posted on that one. :) So what to report? Documentation that ... - explains outdated technology or concepts like KDE 4 or HAL. - has holes in it. For example a tutorial where you suddenly think, you skipped an important step. - you wish was there but you could not find it. Thanks a bunch. :) Cheers, Frederik
Re: kdesrc-build expects fixed path
Hi, thanks for your replies. So it seems as if it broke recently and I was not just doing it wrong. :) In the code the bashrc snippet is just plain text. That's not going to work if there two different repo layouts. As for the fix, I guess we could either make kdesrc-build handle both layouts or make it add the path of the checkout it was run from to the bashrc. It feels intentional to use the copy from the repo layout to be more self-contained so it continues to work when the initial repo is deleted or moved around. Once the repo layout question is decided, we can check what to do here. Cheers, Frederik On 6/7/21 12:13 AM, Nate Graham wrote: I think a better change would be to return to the older, simpler, shorter "flat" folder structure. See https://invent.kde.org/sdk/kdesrc-build/-/merge_requests/96 Nate On Sat, 05 Jun 2021 22:27:44 -0600 Ömer Fadıl USTA wrote > I think we need to change templates and other docs for its standard location as$HOME/kde/src/sdk/kdesrc-build > because it already downloads its self (as a copy) whenever we run kdesrc-buildI believe it was set up flat structure just before passing to invent structure sonow it must be looked up in sdk folder > > Ömer Fadıl Usta > PGP key : 0xfd11561976b1690b > about.me/omerusta > > > Frederik Schwarzer , 5 Haz 2021 Cmt, 20:18 tarihinde şunu yazdı: > Hi, > > when I just tried to set up kdesrc-build with --initial-setup it offered > me to update my .bashrc file. > > The changes made did not work for me because it adds > $HOME/kde/src/kdesrc-build > to the PATH while I have my checkout at another location. > > Maybe I have missed something but I think we should either > - print a warning or even an error message when >running "--initial-setup" from a "wrong" location > or > - add the location of the actual checkout to .bashrc > > Any thought or amendments? > > Cheers, > Frederik >
kdesrc-build expects fixed path
Hi, when I just tried to set up kdesrc-build with --initial-setup it offered me to update my .bashrc file. The changes made did not work for me because it adds $HOME/kde/src/kdesrc-build to the PATH while I have my checkout at another location. Maybe I have missed something but I think we should either - print a warning or even an error message when running "--initial-setup" from a "wrong" location or - add the location of the actual checkout to .bashrc Any thought or amendments? Cheers, Frederik
Re: Shall we condense the bots' commit announcements
Am 26.05.2021 03:12 schrieb Nicolás Alvarez: El mar, 25 de may. de 2021 a la(s) 21:59, Frederik Schwarzer (schwar...@kde.org) escribió: Another thought I had was that GIT_SILENT messages could be omitted. Maybe also worth considering? Seems this is already possible in the configuration, per channel. Some channels have notify_silent=False: https://invent.kde.org/sysadmin/irc-notifications/-/blob/master/gateway/notifications.cfg Thanks for the info. Cheers Frederik
Re: Shall we condense the bots' commit announcements
Hi, I would not object to this change. Maybe keep the longer versions in #kde-commits? Another thought I had was that GIT_SILENT messages could be omitted. Maybe also worth considering? Cheers Frederik On 5/25/21 11:25 PM, Nate Graham wrote: Hello all, Recently we removed the commit announcement bots from the #plasma and #kwin chatrooms because we felt their output was too noisy. However for the rooms where they are still active and announcing git commits, would people appreciate it if the announcements were shorter? For example, instead of sending 5 messages (title, first three lines, and URL) the announcement could send one message (something like title and URL combined). Would anyone object to this change? Nate
Re: Winding down Phabricator
Hi, thanks for putting so much effort in the transition. We, as the German translation team, use Phabricator for reviewing the work of casual contributors. I wonder how other teams handle this. I am not saying, Phabricator going away will break our workflow completely but it is a good way to discuss changes and keep track of the discussion. Cheers Frederik On 6/21/20 5:38 AM, Ben Cooksley wrote: Hi all, With the completion of Phase 1 of our move to Gitlab, all code review activity should now be taking place on Gitlab, with only residual reviews being cleaned out of Phabricator (which hopefully we're already well underway with - please start this if you haven't already) This leaves just Tasks left on Phabricator. As interacting with repositories isn't a core requirement for this functionality, we've now taken the step of disabling all repository functionality on Phabricator. This means that going forward, repositories will no longer be browsable on Phabricator, nor will commit information be visible on Phabricator. Additionally, actions normally taken via hooks (such as "Differential Revision" and "Fixes Txxx") will no longer work. Should anyone have any questions regarding this, please let us know. Thanks, Ben Cooksley KDE Sysadmin
Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?
Am 14.10.2019 22:51 schrieb Johan Ouwerkerk: On 14.10.2019 21:22, Frederik Schwarzer wrote: If however, master had seen commits as well, fast-forwarding is performing a rebase ... is that correct? The workflow would be: whenever master is updated, you rebase your local feature/work branch and force-push to the remote copy of the feature/work branch. This is exactly the problem I see. I create a branch. I start to use, let's say ... KDialog in my feature as KDialog has been used throughout the application and make 20 commits. Now on master, someone merges a branch that replaces all the KDialogs with overlays and removes all KDialog includes. So if I rebase on that, all my 20 commits will fail to build. Checking out an older revision to test something will not work. Now I will fix my latest revision and merge to master. Still: 19 commits are not compiling anymore. Or am I missing something here? How would we deal with that? Is "short-lived branches" (as you stated below) enough to reduce the risk? Cheers Frederik
Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?
Hi, just asking in case I didn't get it. I branch off of master and do a few commits in that new branch. If I now merge the branch back to master and master had not seen any commits in between, it's just relocating the master "tag" and all is fine. If however, master had seen commits as well, fast-forwarding is performing a rebase ... is that correct? Wouldn't rebasing be evil because it rewrites history? Cheers Frederik On 10/14/19 6:29 PM, Johan Ouwerkerk wrote: Yes, please, pretty please with cherry on top. :) Regards, -Johan On Sun, Oct 13, 2019 at 10:57 PM Albert Astals Cid wrote: I find the merge behavior to be not what we've been doing in phabricator so given the idea is to maintain our workflows i'd appreciate if we can agree on continue doing the same. https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html Opinions? Cheers, Albert
Re: Building KDE (phonon-vlc) fails
On Monday, December 10, 2018 12:34:22 PM CET Harald Sitter wrote: > On Mon, Dec 10, 2018 at 11:26 AM Frederik Schwarzer wrote: > > After installing it, phonon-vlc built fine. > > this should be easier to diagnose in the future > https://commits.kde.org/phonon-vlc/e441972892fe61e361ee9b2c39ce0b319f6d1c9e Nice. Thanks for improving that. :) Cheers Frederik
Re: Building KDE (phonon-vlc) fails
On Monday, December 10, 2018 12:29:54 AM CET Michael Pyne wrote: > On Sun, Dec 09, 2018 at 10:18:42AM +0100, Frederik Schwarzer wrote: > > Hi, > > > > please forgive my ignorance. It has been ages since I last built KDE from > > sources. > > > > Using kdesrc-build, the phonon-vlc package fails on cmake with the > > following> > > error: > > -- Checking for module 'libvlc' > > -- Found libvlc, version 3.0.4 > > > > CMake Error at cmake/FindLIBVLC.cmake:106 (message): > > Could not find LibVLC > > > > Found, but not found? Maybe it is looking for a different version? > > > > libvlc-dev is installed on Kubuntu 18.04. > > > > Any idea on what I am missing here? > > Perhaps you need a package libvlccore-dev or similar? The FindLIBVLC in > phonon-vlc checks for both libvlc and for libvlccore but only gives the > one error message if either one is missing. Thank you for your answer. I read the FindLIBVLC file and found three checks. The one for the header file: # find / -iname vlc.h /usr/include/vlc/vlc.h The one for libvlc: # find / -iname libvlc.* /usr/lib/x86_64-linux-gnu/libvlc.so.5.6.0 /usr/lib/x86_64-linux-gnu/libvlc.so /usr/lib/x86_64-linux-gnu/libvlc.so.5 And the one for libvlccore: # find / -iname libvlccore.* /usr/lib/x86_64-linux-gnu/libvlccore.so.9 /usr/lib/x86_64-linux-gnu/libvlccore.so.9.0.0 These looked fine to my untrained eyes at first but the missing libvlccore.so (without the version number) made me think so I looked it up and indeed, the package libvlccore-dev was missing. After installing it, phonon-vlc built fine. Thanks for the pointer. :) Cheers Frederik
Building KDE (phonon-vlc) fails
Hi, please forgive my ignorance. It has been ages since I last built KDE from sources. Using kdesrc-build, the phonon-vlc package fails on cmake with the following error: -- Checking for module 'libvlc' -- Found libvlc, version 3.0.4 CMake Error at cmake/FindLIBVLC.cmake:106 (message): Could not find LibVLC Found, but not found? Maybe it is looking for a different version? libvlc-dev is installed on Kubuntu 18.04. Any idea on what I am missing here? Cheers Frederik
Re: Deploy Weblate/Pootle system for translation
On Donnerstag, 4. Mai 2017 17:59:58 CEST Guo Yunhe wrote: Hi, this discussion would be a better fit for kde-i18n-...@kde.org. > However, our SVN is stopping people from contributing. Not only techniques > but also transparency. When here are some disagreement on specific > translation, usually those who have SVN commit permission can choose the > option they prefer. Sometimes it is disappointing. Just want to point out here that disputes are not better dealt with in web translation systems. It's like saying, in SVN, if two people disagree, just give them both access and the problem will go away. Just do not solve people problems with technical solutions. As for the rest ... this topic is coming up every once in a while, so the mail archive of kde-i18n-...@kde.org is full of pro and con arguments. For me it's a matter of taste and I did not see a system yet that I like. Cheers, Frederik
Re: kde on windows
Am 31.07.2016 um 07:32 schrieb Doug: > I don't know what you think you've accomplished by limiting KDE on > Windows to just 4 files. Please take this discussion to kde-wind...@kde.org There you will get better answers than here. Also please choose your words more constructively. For most this is a leisure time project and everything is given away for free. Regards, Frederik
Re: KRandom regression + fix
Am 27.04.2016 23:45 schrieb Albert Astals Cid: El dimecres, 27 d’abril de 2016, a les 11:42:46 CEST, Frederik Schwarzer va escriure: Am 27.04.2016 08:48 schrieb Johannes Huber: > thanks for the patch. When i read "randon numbers were predictable" > instantly > a alarm bell rings in my head. Is this a security issue? The docs of rand() state that you should not use it for serious business like cryptography http://en.cppreference.com/w/cpp/numeric/random/rand and the most serious business I could see within KDE was PIN generation for Bluetooth pairing. But you can never know who is using it for what outside of the KDE infrastructure. Since I am neither a core developer (just maintaining a game which was beaten by the consequences of this issue) nor a crypto guy, I cannot really assess the severity of such a regression but my first thoughts were: - why is there no unit test cathing this? Because noone wrote one (obvious answer) Yes, of course that's the obvious answer. :) I asked because the answer could have been something along the lines of "because KRandom is old; do not use it; we have something new in frameworks" or so. From my "i know nothing about random numbers", i guess it's hard to write a unit test for a sequente of random numbers, you can get ten "3" in a row and it's still a valid random sequence. srand() is the same as srand(1) so it uses a fixed seed. Thus two initialisations produce the same sequence. Not sure though if this can be done in a unit test. - should KRandom api doc pass through the note of not using it for serious business in general? Probably makes sense adopting what rand() says, yes. Would you propose a patch? Already did: https://git.reviewboard.kde.org/r/127767/ Comments about the wording welcome. :) Regards, Frederik
Re: KRandom regression + fix
Am 27.04.2016 08:48 schrieb Johannes Huber: Hi Johannes, KRandom saw a regression in KCoreAddon's 5.21.0 release, which impacts a wide range of applications and use cases. Since the rand() was not seeded, the numbers generated were predictable, which is ugly in games and probably alarming for bluetooth pairing. thanks for the patch. When i read "randon numbers were predictable" instantly a alarm bell rings in my head. Is this a security issue? The docs of rand() state that you should not use it for serious business like cryptography http://en.cppreference.com/w/cpp/numeric/random/rand and the most serious business I could see within KDE was PIN generation for Bluetooth pairing. But you can never know who is using it for what outside of the KDE infrastructure. Since I am neither a core developer (just maintaining a game which was beaten by the consequences of this issue) nor a crypto guy, I cannot really assess the severity of such a regression but my first thoughts were: - why is there no unit test cathing this? - should KRandom api doc pass through the note of not using it for serious business in general? That's why I CC'ed kde-core-devel. Regards, Frederik
KRandom broken?
Hi, it seems as if KRandom is currently broken. https://bugs.kde.org/show_bug.cgi?id=362161 Given the potential impact, is there something to be done (besides fixing it) wrt distro packagers? Regards
Re: Could we enable Travis-CI on our github mirrors?
Am 21.04.2016 07:56 schrieb Teo Mrnjavac: Hi, Can we call things as they are please? The name is "Travis CI", not "githubCI". Travis CI is open source, a separate product and service that happens to talk to GitHub. I think Albert's concern is (and I agree) that the meaning of a potential Travis-hosted CI is shifting over time from "addition" to "main one". People tend to do this. Oh, this one feature here, oh, the easier login there ... In general I think 3rd party services should be avoided to get an official status in KDE. Sourceforge suddenly started adding adware to all downloads. Github can do the same. Tomorrow, nezt week, next year. They might announce this first or they don't. The same way TravixCI could say, they now want money or put ads all over the place. We have no control over this at all. So it is better to invest some time and money to maintain our own infrastructure. It makes us independent from some management decision made by some company. Also, for an infrastructure inside KDE, we need people to work on it. If now people start to use 3rd party sevices, less people are looking at our infrastructure and it gets less attention. That's at least why I would vote against that kind of "additions" made official. If some developer wants to use something somewhere, I guess there is nothing to hold him back but KDE shoud remain as self-contained as possible. Wth all the little problems coming with this. Regards, Frederik
Re: KConfig - setStandardButtons() breaks Help button?
Am Sonntag, 6. März 2016, 12:20:38 schrieb Albert Astals Cid: > El Saturday 05 March 2016, a les 08:34:27, Frederik Schwarzer va escriure: > > Hi, > > > > I am struggling with using KConfigDialog. If I use it like this: > > KConfigDialog* dialog = new KConfigDialog(this, > > > > "settings", Settings::self()); > > > > connect(dialog, ::settingsChanged, > > > > this, ::loadSettings ); > > > > dialog->show(); > > > > the Help button works. > > > > Since in my use case, some of the values in the dialog are > > calculated and (to my understanding) cannot be handled correctly > > by Kcfg, I want> > > to get rif of the "Restore Defaults" button. So I add this line: > > dialog->setStandardButtons(QDialogButtonBox::Ok | > > > > QDialogButtonBox::Cancel | QDialogButtonBox::Help); > > As a side note, there's ways in which you can make it so the > "restore default" button does execute some code for those "tricky" > settings (i.e. override updateWidgetsDefaults) Hmm, updateWidgetsDefaults() is protected. Would I not have to make my own Dialog and inherit from KConfigDialog to overwrite that? > > but then the Help button does not open the Help browser anymore. > > Is that expected? Do I use KConfigDialog incorrectly? Is this just > > broken on my system? > > > > In case someone wants to see what is happening, I created a semi- > > > > minimal buildable example to play with. See: > > https://quickgit.kde.org/?p=scratch%2Fschwarzer%2Fkconfigexamp > > le.git > As Thomas says you have to recreate the connections, so basically > > connect(buttonBox->button(QDialogButtonBox::Help), > SIGNAL(clicked()), q, SLOT(showHelp())); This was done before during the KF5 porting but it did not open the correct halp page. So I removed that part and used the StardardButtons to make the help work. ... Leading to other problems. :) Kigo is q bit complicated in this regard. Even now Applying settings with an invalid Go command is breaking the whole game until the next restart. My goal would be to get rid of the "tricky" part alltogether and just let the standard config dialog handle everything but it's a lot of fiddling to find out what can be done and what can't. Thanks, Frederik
Re: KConfig - setStandardButtons() breaks Help button?
Am Sonntag, 6. März 2016, 12:19:14 schrieb Thomas Lübking: > On Sonntag, 6. März 2016 12:10:36 CEST, Frederik Schwarzer wrote: > >> The most straight forward solution is likely to hide or delete > >> button(QDialogButtonBox::RestoreDefaults) > > > > I would like to try this but cannot find info on how to hide a > > standard button. > > The KDE 4 version did not have that button either so it's at least > > not worse than before. > > if (QPushButton *restore = > button(QDialogButtonBox::RestoreDefaults)) restore->hide(); Meh, KDevelop completed to "QDialogButtonBox::Reset" which then compiled but crashed without the if() condifion. :) Thanks. Frederik
Re: KConfig - setStandardButtons() breaks Help button?
Am Samstag, 5. März 2016, 10:53:18 schrieb Thomas Lübking: > On Samstag, 5. März 2016 08:34:27 CEST, Frederik Schwarzer wrote: Hi, > > Since in my use case, some of the values in the dialog are > > calculated and (to my understanding) cannot be handled correctly > > by Kcfg, I want> > > to get rif of the "Restore Defaults" button. So I add this line: > > dialog->setStandardButtons(QDialogButtonBox::Ok | > > > > QDialogButtonBox::Cancel | QDialogButtonBox::Help); > > > > but then the Help button does not open the Help browser anymore. > > > ::setStandardButtons simply forwards the call to the internal button > ::box which nukes all button objects (incl. their slot connections) > ::and recreates them w/ the new item list. Ok, reading it like this, the behaviour suddenly makes sense. :) > The most straight forward solution is likely to hide or delete > button(QDialogButtonBox::RestoreDefaults) I would like to try this but cannot find info on how to hide a standard button. The KDE 4 version did not have that button either so it's at least not worse than before. > Rather replace the restore defaults button, resp. re-link it to your > own calculation slot. I will add a comment that this is better and should be considered in the future. Thanks for the hints. Regards, Frederik
Re: Static code analysis - the easiest way to improve
Am Sonntag, 28. Februar 2016, 20:18:22 schrieb Nick Shaforostoff: > > > Let us know in this thread if code you're interested in isn't > > > there.> > > Could we have kdegames there? > > ok, i'll include them in the next build (in a week or so) Thank you.
Re: File dialog filters
Am Dienstag, 16. Februar 2016, 18:27:23 schrieb Christian Dávid:
Hi,
> I noticed that in KMyMoney the filter strings for file dialogs are
> created "by hand", e.g. i18n("C++ sources (*.cpp *.cxx *.c++);;All
> files (*)"). So each of them must be translated. Alternatively
> something like
>
> QMimeDatabase db;
> db.mimeTypeForName("text/x-c++src").filterString()
Just a guess but many application might not succeed in finding their
MIME type in the db. They could provide an XML file for that, but this
is quite a hassle compared to just writing a few characters. Also how
can several mime types be represented? Like your example "C++
sources;;Allfiles".
>From the docs: "If the MIME type database cannot be found on the
system, as is the case on most Windows, OS X, and iOS systems, Qt will
use its own copy of it."
While this does not sound too bad, it at least gives the impression of
a not too well working process.
> could be used to create these string lowering the burden on the
> translators and resulting in consistent translations for all
> mimetypes.
Thank you for thinking about the translators. :)
I did not know about QMimeDatabase until now. On my system I have 930
MIME types in the db. Just for you to compare with yours.
To me this looks like a nice way to have unified strings for file
types and I would also like to know if there are things speaking
against using it.
Regards,
Frederik
Re: Problem with KConfigGroup
Am Montag, 15. Februar 2016, 14:20:11 schrieben Sie:
> On Monday, February 15, 2016 4:02:32 AM CET Frederik Schwarzer
wrote:
> > Hi,
> >
> > in Klickety the Configure dialog stopped working in one specific
> > area. It's a QGroupBox with radio buttons represented as an Enum
> > in the kcfg file. Two of the radio buttons have another widget
> > right next to them.
> >
> >
> >
> > | o Theme|
> > | o Color [kcolorbutton] |
> > | o Image [kurlrequester] |
> >
> >
> >
> > So, as is, the Enum always says "0" and the Apply button remains
> > grayed-out.
> > If I then remove both of those extra widgets, the correct value is
> > given (0-2) and the Apply button works as expected.
> >
> > You can find the UI file in
> > https://quickgit.kde.org/?p=klickety.git=blob=bgselector.ui=
> > plain and the last two widgets (KUrlRequester and KColorButton)
> > are the culprits.
> >
> > Does anone have an idea why having another widget there disturbs
> > the radio buttons?
>
> You can diff the generated files and see what happens. Also for the
> KConfigCompiler (I think that's what you are complaining about? I
> don't see any reason KConfigGroup would be the culprit here?)
Thanks for the hint. I tried that. If I remove the two widgets, the
changes in the build dir are as follows. For me this looks pretty much
as I would expect it to be.
diff -ur temp_with/ui_bgselector.h temp/ui_bgselector.h
--- temp_with/ui_bgselector.h 2016-02-15 17:37:35.855052087 +0100
+++ temp/ui_bgselector.h2016-02-15 17:36:33.449802766 +0100
@@ -36,8 +36,6 @@
QRadioButton *theme;
QRadioButton *color;
QRadioButton *image;
-KUrlRequester *kcfg_BgImage;
-KColorButton *kcfg_BgColor;
void setupUi(QWidget *BackgroundSelector)
{
@@ -70,17 +68,6 @@
gridLayout1->addWidget(image, 2, 0, 1, 1);
-kcfg_BgImage = new KUrlRequester(kcfg_BgType);
-kcfg_BgImage->setObjectName(QStringLiteral("kcfg_BgImage"));
-kcfg_BgImage->setEnabled(false);
-
-gridLayout1->addWidget(kcfg_BgImage, 2, 1, 1, 1);
-
-kcfg_BgColor = new KColorButton(kcfg_BgType);
-kcfg_BgColor->setObjectName(QStringLiteral("kcfg_BgColor"));
-
-gridLayout1->addWidget(kcfg_BgColor, 1, 1, 1, 1);
-
gridLayout->addWidget(kcfg_BgType, 3, 0, 1, 1);
But then I looked at the latest KDE 4 version and it worked quite fine
so I went through the changes since then and found that these widgets
resided within a KButtonGroup, which was changed to a QGroupBox during
porting (by me *coughs*) whereas it should have been changed to a
combination of a QGroupBox and QButtonGroup according to
http://api.kde.org/frameworks-api/frameworks5-apidocs/kdelibs4support/html/classKButtonGroup.html
So currenty I am fighting with QtCreator to put in a QButtonGroup
(harder than expected). Back to reading for now. :)
Thanks,
Frederik
Re: Review Request 126249: Fix apidoc format
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126249/#review91464 --- Ping? - Frederik Schwarzer On Dec. 5, 2015, 8:38 a.m., Frederik Schwarzer wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126249/ > --- > > (Updated Dec. 5, 2015, 8:38 a.m.) > > > Review request for kdelibs. > > > Repository: kio > > > Description > --- > > A full-stop within the first sentence (short description) breaks the line > there. See e.g. > http://api.kde.org/frameworks-api/frameworks5-apidocs/kio/html/namespaceKIO.html#a17631774b47cddb0127d8a3c1fc2315c > > > Diffs > - > > src/core/storedtransferjob.h 3f267c9 > src/core/transferjob.h 6d78793 > > Diff: https://git.reviewboard.kde.org/r/126249/diff/ > > > Testing > --- > > > Thanks, > > Frederik Schwarzer > >
Re: Review Request 126249: Fix apidoc format
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126249/ --- (Updated Jan. 23, 2016, 11:20 a.m.) Status -- This change has been marked as submitted. Review request for kdelibs and David Faure. Repository: kio Description --- A full-stop within the first sentence (short description) breaks the line there. See e.g. http://api.kde.org/frameworks-api/frameworks5-apidocs/kio/html/namespaceKIO.html#a17631774b47cddb0127d8a3c1fc2315c Diffs - src/core/storedtransferjob.h 3f267c9 src/core/transferjob.h 6d78793 Diff: https://git.reviewboard.kde.org/r/126249/diff/ Testing --- Thanks, Frederik Schwarzer
Review Request 126249: Fix apidoc format
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126249/ --- Review request for kdelibs. Repository: kio Description --- A full-stop within the first sentence (short description) breaks the line there. See e.g. http://api.kde.org/frameworks-api/frameworks5-apidocs/kio/html/namespaceKIO.html#a17631774b47cddb0127d8a3c1fc2315c Diffs - src/core/storedtransferjob.h 3f267c9 src/core/transferjob.h 6d78793 Diff: https://git.reviewboard.kde.org/r/126249/diff/ Testing --- Thanks, Frederik Schwarzer
Review Request: Do not patch strings that can be combined.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104712/ --- Review request for KDE Base Apps. Description --- The way it is now, it created two strings, one of which does not hold anything to translate (just markup). This change merges them to one string with a placeholder which enables the translator to see the whole picture. Diffs - konqueror/settings/konqhtml/css/kcmcss.cpp b4e5146 Diff: http://git.reviewboard.kde.org/r/104712/diff/ Testing --- Thanks, Frederik Schwarzer
Re: Review Request: Display the tab title on root (/) folder properly in konqueror filemanager mode
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101374/#review3371 --- konqueror/src/konqview.cpp http://git.reviewboard.kde.org/r/101374/#comment2806 Wrong indentation. Its the paren of the outer if block. - Frederik On May 17, 2011, 9:18 p.m., Burkhard Lück wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101374/ --- (Updated May 17, 2011, 9:18 p.m.) Review request for KDE Base Apps, David Faure and Peter Penz. Summary --- Konqueror in filemanager mode shows an empty tab title on browsing root (/) folder. Dolphin displays the tab title on root (/) folder properly, so this patch is a copy of three lines from dolphin dolphinmainwindow.cpp. This addresses bug 153573. http://bugs.kde.org/show_bug.cgi?id=153573 Diffs - konqueror/src/konqview.cpp 699c9d5 Diff: http://git.reviewboard.kde.org/r/101374/diff Testing --- compiled and works for me Thanks, Burkhard
Re: Review Request: Display the tab title on root (/) folder properly in konqueror filemanager mode
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101374/#review3375 --- WRT the parenthesis ... the outermost if statement breaks before the opening paren, the second if statement uses paren on the same line as the statement and the third uses no parens at all. Might that be worth unifying? - Frederik On May 17, 2011, 9:18 p.m., Burkhard Lück wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101374/ --- (Updated May 17, 2011, 9:18 p.m.) Review request for KDE Base Apps, David Faure and Peter Penz. Summary --- Konqueror in filemanager mode shows an empty tab title on browsing root (/) folder. Dolphin displays the tab title on root (/) folder properly, so this patch is a copy of three lines from dolphin dolphinmainwindow.cpp. This addresses bug 153573. http://bugs.kde.org/show_bug.cgi?id=153573 Diffs - konqueror/src/konqview.cpp 699c9d5 Diff: http://git.reviewboard.kde.org/r/101374/diff Testing --- compiled and works for me Thanks, Burkhard
Re: Top 15 Mailinglists with messages in moderation May 1st
[Tom Albers - Sonntag, 1. Mai 2011 16:00:57] Hi, New month, new list. If lists are unused, let me know, I will delete them. If someone wants to help with moderation for any of these list, let me know as well. 19 kde-news-de You can put me in change here. I will look into the moderation list ... but the list itself seems pretty dead so, let's see how it turns out. I will contact you, if I figured it out. Regards
Re: April: Top 15 Mailinglists with messages in moderation
On 01/04/2011, Tom Albers t...@kde.org wrote: Hi, The monthly overview of the lists with most messages in the moderation queue: 19 kde-news-de This might be a candidate for a closedown. The archive ends in 2007 and there are no plans to revive something like this. Was the admin asked for his opinion? Regards Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: 4.6 branches created in git again
On 22/03/2011, Ian Monroe i...@monroe.nu wrote: On Mon, Mar 21, 2011 at 18:13, Alex Merry k...@randomguy3.me.uk wrote: On 21/03/11 20:17, Alexander Neundorf wrote: On Monday 21 March 2011, Ian Monroe wrote: Ben did add this block to his hook. Hooray. :) I'm thinking I should just go ahead and rename KDE/4.6 to 4.6 etc. Wasn't the conclusion more like going with the longer name, i.e. KDE/4.6 ? That's what I understood from the earlier discussion... I get why people like the prefix in theory, since I mean that's why I left it there. It looks nice. From what I understand the problem, it's not a like/dislike question but a real problem if an application has its own version numbers and reaches e.g. version 4.6. But in practice its obviously just been confusing. Even now that creating 4.6 is blocked, that just means its blocked and we won't notice when people struggle. Can the hook not give a message pointing to some Wiki page that explains the issue? Regards
Re: Top 15 Mailinglists with messages in moderation
On 01/03/2011, Harri Porten por...@froglogic.com wrote: On Tue, 1 Mar 2011, Raphael Kubo da Costa wrote: 34 kfm-devel I could help with this one. I do keep an eye on messages held back btw. As long as there's just spam I don't bother logging in to clean it up. Granted, this is slightly risky so any help is welcome. listadmin ftw :) http://blog.lydiapintscher.de/category/productivity/ Regards
