Re: RFC: an improved ki18n_install
On 2023-03-07 13:12, Friedrich W. H. Kossebau wrote: Am Dienstag, 7. März 2023, 02:51:06 CET schrieb Aleix Pol: Having ninja/make do this dependency generation can end up being more work than worth it because then we need to have a static list Such static list could be generated by scripty when it updates the po/ folder and stored there, no? Which then could be sourced by the ki18n_install cmake code in some way. That sounds like a good solution, one could just emit some CMake file to include that contains the call to the ki18n_install helper with the right args, then on the outside one would just need to add the po dir and be done. Greetings Christoph I'd urge to use the existing tools like make/ninja as much as possible instead of reimplementing their logic partially and maintaining a non-integrated sub buildsystem, with all the shortcomings and fails. Thanks for working on this in any case, the current state is far from ideal. -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Telemetry in Plasma and Discover
On 2022-07-13 06:03, Luca Beltrame wrote: In data martedì 12 luglio 2022 16:52:21 CEST, Nate Graham ha scritto: Hello Nate, +Fabian Vogt and Luca Beltrame specifically Thanks, that's a relief! Does this looks legit enough for openSUSE to stop patching out the KUSerFeedback integration? In principle I do not have any objections given the thread, but I'd also like input from Christophe (added to CC). As an aside I see that similar messages were sent out for PIM and other applications. That might be enough to re-enable things everywhere. Hi, at least for Kate & KWrite I would hope we followed the rules by the letter, with a merge request and the mandatory mail. Therefore I would love to see that people are able to activate the telemetry and it not being patched out (if that is the case ATM). If it is patched out ATM, I would have appreciated some notification that we did something wrong, then we could have rectified it. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: New cmake warning.
On 2022-05-16 19:38, Alexander Neundorf wrote: On Dienstag, 3. Mai 2022 18:43:48 CEST Méven wrote: Le mar. 3 mai 2022 à 18:25, Thomas Friedrichsmeier < thomas.friedrichsme...@kdemail.net> a écrit : > On Tue, 3 May 2022 10:35:20 +0200 > > Méven wrote: > > I am guessing you are using cmake >= 3.16 so it allows you to run, but > > since the project does not have a cmake minimum, for others using > > cmake < 3.16 the build will break. > > This warning highlights it, so you inform your contributor they need > > cmake 3.16 before running into the hard fail in FindKF5. > > On the downside, project wishing to remain backwards-compatible with > older systems (which will come with older versions of both cmake and > ECM) will want to avoid adding such a requirement, explicitly. Cmake 3.16 dates from November 2019 to put things in perspective. RHEL 8, which many commercial users have not updated to yet, comes with cmake 3.11, to add some more perspective ;-) Yeah, that is true, but to be realistic: We do commercial software development and even need to stick with RHEL 7 and we do what everybody else does: Just install a proper cmake during both the CI and the normal development. We even install our own compilers or at least the latest devtoolset, otherwise RHEL 7 is useless. I don't think the enterprise distros are anything we should really look at for determining our dependency versions. Greetings Christoph Alex -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Git merge workflow: reverse it?
On 2022-05-10 15:33, Nate Graham wrote: On 5/10/22 04:15, Ingo Klöcker wrote: https://manifesto.kde.org/commitments/ I don't see anything in there that would force the same merge workflow on all KDE projects. In my view the merge workflow is comparable to the coding style. Regards, Ingo I don't think anyone is trying to force anything; rather, the proposal is to get voluntary consensus around standardizing on a single workflow (whatever it is) so that we all individually reap the benefits of consistency by not having to remember two workflows, look up which workflow a project uses, etc. Personally I don't care which one we standardize on, but I am in favor of voluntarily and communally standardizing on one of them. Yeah, I doubt we can or want to force people. I personally prefer the cherry-pick approach from master to the stable branch(es), given I only work on the master branch and that is for me the best way to previously test the stuff properly. Naturally for e.g. Kate we only backport trivial stuff that way. Greetings Christoph Nate -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
KUserFeedback integration for KWrite
Hi, we will change KWrite to re-use the Kate codebase. As side-effect, KWrite will like Kate now support opt-in telemetry via KUserFeedback (can be even deactivated fully during compile time, purely optional dependency). The code is the same as used in Kate, the relevant merge request for the unification is: https://invent.kde.org/utilities/kate/-/merge_requests/692 This will happen soon in master, if reviewed & ok'd, the first release with this will be 22.08. This will then be documented as needed on https://community.kde.org/Telemetry_Use If you have feedback, please refer to the above merge request. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Gitlab CI - Inbound
On 2021-09-06 11:48, Ben Cooksley wrote: On Mon, Sep 6, 2021 at 9:00 PM Tom Zander wrote: On zondag 5 september 2021 08:13:09 CEST Ben Cooksley wrote: In terms of the format of the 'Dependencies' section, Playing with kde-build script and noticing the fast growing dependency trees we have today, I think it may be beneficial to have two types of compile dependencies in this setup. 1. required-to-build. Which means that if something in the parent tree changes, this one is scheduled for re-build. 2. optional. Equivalent of the cmake feature, if its not there some code is not compiled. At least once before a release the full dependencies can be compiled to see if it fully compiles. From the perspective of the CI system there is basically no difference in terms of making a dependency available or not as all dependencies are always satisfied using previously built binaries. If a dependency is not available your build fails. We also have to make a hard choice - we either bring in optional dependencies or we don't. If we were to randomise whether we brought them in - or just brought them in at certain times - then we would make the system state deterministic. This could in some cases cause builds to break if it was random whether or not we included optional dependencies. This would occur if the dependency of a dependency of a project were rebuilt without an optional dependency being present which in turn caused it's API interface to change. That would then cause the project to fail as the dependency would now be broken. Pushing everything into required is likely not scalable, causing projects too wait too long for compile. Avoiding the optional ones means you lack coverage of compile and testing failures due to changes in libs. The CI system has reused the results of previous builds of dependencies since the very first generation of the system (this would be generation 5) so this is not a problem facing the CI system. For individual developers, my understanding is that kdesrc-build makes use of incremental builds which eliminates most of the issue as well. What do people think, is it useful to have an 'optional' category in future there? Maybe useful to think that far ahead now people are populating their dependencies :-) Hi, I would prefer to not have some optional category to be sure the CI always builds with the same state of dependencies, too. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: KDE Gear releases & Frameworks dependencies
On 2021-03-02 22:11, Albert Astals Cid wrote: El dimarts, 2 de març de 2021, a les 19:39:57 CET, Christoph Cullmann va escriure: Hi, for the KDE Gear release service releases, what is actually an acceptable Frameworks release requirement for the upcoming 21.04? e.g. at the moment, Kate requires Frameworks 5.79 in master, we needed some new API to avoid ugly hacks. Would it be acceptable to move this to the latest version that will be out in March, e.g. 5.80? Or will this lead to issues? Applications and libraries part of the release service can define their own dependencies, the worst that can happen is that your application doesn't get packaged for some distributions because your dependency is un-attainable for them, but that's a risk you seem be willing to take, so nothing against it. On the other hand from a release point of view, the release service dependency freeze is on March 11 and KDE Frameworks 5.80 is not released until March 13, so I would personally prefer you don't do that. It's very possible that I won't have KDE Frameworks 5.80 avaialble for me when doing the Beta release on March 18. Is it really that needed to have that KF5 version for kate? Are the features enabled by that KF5 version so critical they can't wait for 21.08 or maybe be protected with ifdefs? No, 5.80 isn't needed. Just wanted to ask how the general feeling is for such things. 5.79 makes the life a lot easier and I see no problem with that, given with old frameworks you have bugs you don't to have with the 21.04 release, can live with it not being packaged on such systems. Will just stick with 5.79, thanks for the feedback! Greetings Christoph Cheers, Albert That way we (the Kate people) could ensure that Kate 21.04 will only be (without that people patch it) build-able against some Frameworks release that has at least the bugs fixed that we really care about. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
KDE Gear releases & Frameworks dependencies
Hi, for the KDE Gear release service releases, what is actually an acceptable Frameworks release requirement for the upcoming 21.04? e.g. at the moment, Kate requires Frameworks 5.79 in master, we needed some new API to avoid ugly hacks. Would it be acceptable to move this to the latest version that will be out in March, e.g. 5.80? Or will this lead to issues? That way we (the Kate people) could ensure that Kate 21.04 will only be (without that people patch it) build-able against some Frameworks release that has at least the bugs fixed that we really care about. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: KDE Frameworks 6 - Virtual Sprint setup
On 2021-01-30 12:14, Volker Krause wrote: On Freitag, 29. Januar 2021 15:57:59 CET Adam Szopa wrote: Hello, I've been talking with David Faure about setting up a Sprint focused on KF6 work. Some of the topics would include: - Reviewing the KF6 board (https://phabricator.kde.org/project/board/310/[1]): -- Clean up -- Tagging Junior Jobs - Working out a structure/process for handling: -- "Stuck" tasks -- Unit test regressions - Decide the 5.15 minimum requirement bump timeline - Decide on a 6 branching strategy and timeline - Decide if/how ECM should support multiple Qt versions That's just an example list - the wiki[1] should include the up to date and detailed topics. The Sprint will use the KDE BBB instance - same tech that powered last years Akademy; I'll coordinate that with our sysadmins to have it available. As for the date and length, usually Virtual Sprints are a weekend thing. I'd love to hear from you if that sounds OK, and which weekend would be workable for you (how soon can we get this started) and your preferred availability hours. I'll set up a poll later to pinpoint the final timing. Thanks for driving this, I'm in! European hours preferred, any weekend starting from w6 should be possible. Count me in, too ;=) European hours preferred. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Retiring
On 2021-01-13 23:05, Milian Wolff wrote: On Mittwoch, 13. Januar 2021 21:57:13 CET Christoph Feck wrote: Hello developers, my personal situation allows for much less time for KDE related work, at least during the Corona times. I would like to retire as soon as possible from these responsibilities: - bug triaging - release service - KIconTheme maintainer - KPlotting maintainer - KWidgetAddons maintainer For bugzilla, I see many new and old contributors doing awesome work with triaging, so departing here shouldn't be a big issue. I hope someone can continue checking responses to NEEDINFO bugs and REPORTED bugs that didn't get a reply within about two weeks. Regarding the release service work, I have made sure the load isn't all back to Albert. For future release work, Heiko Becker volunteered to help, but maybe another hand would be awesome, too. For the frameworks modules, I initially assumed each module must have a separate maintainer, so I volunteered. Today I see many modules still just community-maintained, and I hope the community can take over maintainance. Not that I did any relevant work here in the recent years... I might eventually continue to prepare some patches, so please keep all my accounts intact, but only de-list me as the maintainer. Thanks a lot Christoph for all your work! As I myself has had the pleasure of quasi-retiring but never quite leaving - may the same happen to you ;-) I.e.: Take your well earned break and come back whenever it suites you again! Really thanks a lot for all the work ;=) I can't even count the bugs you worked on alone for KTextEditor/Kate/... There was always another Christoph faster than me ;=) Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Swap - An Addition to Cut/Copy/Paste for Text Handling
On 2020-12-04 20:12, Jason Christie wrote: Hello, all! I *really* feel I'm intruding here, so I will try and be brief and succinct. When you have text buffered/in the clipboard, and need to replace other text while at the same time keeping it as well, there's no easy and fast way to do this. Some of us do this many times a day, whether as programmers, data entry people, accountants, authors, spammers, etc. It seems to me to be relatively easy to swap the highlighted text for the buffered text. It would probably be harder to find a meaningful available keypress. Anyway, I thought I would at least put it out there for the people most capable of doing it. Ideally, we would see this addition catch on worldwide, with KDE being the innovators in this area. I'm probably capable of implementing it myself, were I directed to the right areas, but I am far from an expert as far as the underlying structure of things goes. But perhaps this post will spark a discussion. Hi, I think this is very nice idea and I don't know why we didn't have this earlier. Here some patch for KTextEditor: https://invent.kde.org/frameworks/ktexteditor/-/merge_requests/48 Greetings Christoph Thanks! Jason -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Please review KUserFeedback support in Dolphin
On 2020-10-29 21:46, Elvis Angelaccio wrote: Hi everyone, I was planning to add KUserFeedback in Dolphin for the upcoming 20.12 release, but then I realized that our telemetry policy [1] says we should go through a public review on kde-core-devel first. So here I am, this is the MR: https://invent.kde.org/system/dolphin/-/merge_requests/45 Please have a look. Dependency freeze for 20.12 is on November 5th, so in one week. I'd appreciate some feedback before that. Thanks :) Hi, could we make KUserFeedback a framework then, to ensure we have some proper released and updated foundation, if we use that in more stuff now? Greetings Christoph Cheers, Elvis [1]: https://community.kde.org/Policies/Telemetry_Policy#Compliance -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Git merge workflow: reverse it?
On 2020-09-15 01:06, Albert Astals Cid wrote: El dimecres, 12 d’agost de 2020, a les 22:42:37 CEST, Albert Astals Cid va escriure: Would it make sense to do an Akademy BoF about this to try to get more than 3 people to decide on it? So we didn't have an Akademy BoF. I need clear messaging on this, so we can tell people clear messaging that i will or will not be doing stable to master merging for the 20.12 releases branching. I myself prefer the > # Current workflow > > - Proposed workflow is to instead commit all changes in master, and > cherry-pick related changes in the stable branch as needed > - We had been using this workflow for about 1 month now and I'd say it > is working nicely for us. variant. (and in doubt only will cherry-pick very "small" fixes back, to avoid regressions) Greetings Christoph Cheers, Albert Cheers, Albert El dimecres, 29 de juliol de 2020, a les 14:01:07 CEST, Bhushan Shah va escriure: > Hello everyone! > > At plasma, we are experimenting with new workflow regarding how bugfixes > are put on the stable branch [1]. > > # Previous workflow > > - Current workflow is that we commit to stable branch and then merge it > upwords until master branch > - i.e commit to Plasma/5.18 branch, merge 5.18 into 5.19 and then > master > > # Current workflow > > - Proposed workflow is to instead commit all changes in master, and > cherry-pick related changes in the stable branch as needed > - We had been using this workflow for about 1 month now and I'd say it > is working nicely for us. > > # Why? > > We occasionally hit several issues with previous workflow, > > - Merge conflicts when merging changes upwords > - Changes which are valid only for stable branch needs to be reverted in > master branches. So you end-up with, stable-fix, revert of stable fix > and then different fix and overall weird history. > - Accidential merges from the master branch to stable branch which > needs to be force-resetted. > - It's worth noting that Qt also recently changed to merge to dev, > cherry-pick backwards. > - This also allows for workflows where we want to commit some bugfix in > the master branch for few days/weeks and if it works fine in general > testing then, cherry-pick it in stable branches. > > Proposal is to probably adapt this policy kde-wise if people feel that > advantages are worth it. > > Thanks > > [1] https://mail.kde.org/pipermail/plasma-devel/2020-June/117887.html > > -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: KUserFeedback integration for Kate
On 2020-02-02 12:27, Christoph Cullmann wrote: Hi, I created some initial merge request for basic user feedback integration into Kate: https://invent.kde.org/kde/kate/merge_requests/60 To do this properly like described in https://community.kde.org/Policies/Telemetry_Policy I would like to have people review this change and raise issues that might violate our policy. For now, we just collect some usage statistics. Please provide your feedback either on this list or on the merge request. I got two positive reviews for this. I merged this now, to be used in 20.04. I added the relevant info to https://community.kde.org/Telemetry_Use If something is still bad/missing/..., please ping us on kwrite-de...@kde.org or open some issue for that! Thanks! Greetings Christoph Thanks! Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
KUserFeedback integration for Kate
Hi, I created some initial merge request for basic user feedback integration into Kate: https://invent.kde.org/kde/kate/merge_requests/60 To do this properly like described in https://community.kde.org/Policies/Telemetry_Policy I would like to have people review this change and raise issues that might violate our policy. For now, we just collect some usage statistics. Please provide your feedback either on this list or on the merge request. Thanks! Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
KUserFeedback integration for Kate
Hi, I created some initial merge request for basic user feedback integration into Kate: https://invent.kde.org/kde/kate/merge_requests/60 To do this properly like described in https://community.kde.org/Policies/Telemetry_Policy I would like to have people review this change and raise issues that might violate our policy. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
KUserFeedback integration for Kate
Hi, I created some initial merge request for basic user feedback integration into Kate: https://invent.kde.org/kde/kate/merge_requests/60 To do this properly like described in https://community.kde.org/Policies/Telemetry_Policy I would like to have people review this change and raise issues that might violate our policy. For now, we just collect some usage statistics. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
Hi, With my KTextEditor hat on: KF6:TextDocument implies somehow a link to QTextDocument or KF6:TextEditor, which both is incorrect, right? QTextDocument is exactly what it's about, which makes the name KF6::TextDocument fully appropriate and correct. Before starting this work, let's clarify whether we can find a more unique name (like KF6:GrantleeTextDocument). The name I suggest is already correct. Since I haven't used Grantlee yet, I sm likely not the best person to find a better name ;) Remember, Grantlee is a set of Frameworks (*Just like KF5/6*) which happens to contain just TWO independent libraries. Hmm, I am not that sure about that naming. I see that it provides stuff with QTextDocument in mind, but KF6::TextDocument would in my eyes more look like some generic "enhanced" QTextDocument, but Grantlee provides a very specific extension. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: HiDPI issues with KDE applications
On 2019-09-28 18:23, Michael Reeves wrote: While were on this topic https://bugreports.qt.io/browse/QTBUG-75039 It seems qt has a few bugs related to this. Make sure multi monitor setups are tested as well. I have no multi-monitor different DPI setup available. But if somebody has, for sure, testing there would be appreciated. I can only tell, that without the below change, already on one screen it looks horrible :=) Greetings Christoph On Sat, Sep 28, 2019, 11:05 AM Christoph Cullmann wrote: Hi, I just checked again the HIDPI support of Kate/KWrite on Windows and it "sucked". It seems we never properly did setup the stuff to auto-scale, e.g. the QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true); call was missing, we only had the QCoreApplication::setAttribute(Qt::AA_UseHighDpiPixmaps, true); part that we sprinkled in most of KDE's things in the past. I now rectified that for Kate/KWrite, shall we do this for all our applications? Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: HiDPI issues with KDE applications
On 2019-09-28 17:37, Christoph Cullmann wrote: On 2019-09-28 17:34, Albert Vaca Cintora wrote: If this has to be done for all apps, why isn't it done at Qt level? Because in some cases, that breaks the application, e.g. if it expects pixel to be real physical pixel 1:1. Therefore, after changing that, one needs to try the application if it behaves OK. (I did that for KWrite/Kate) Still not properly scaled seem to be things that get painted via QStyle, like the KMultiTabBar buttons: QStyleOptionButton opt; opt.initFrom(this); opt.icon = icon(); opt.iconSize = iconSize(); // removes the QStyleOptionButton::HasMenu ButtonFeature opt.features = QStyleOptionButton::Flat; QPainter painter(this); style()->drawControl(QStyle::CE_PushButton, , , this); => here I still see artifacts, both on Linux and Windows (easy to try with some export QT_SCALE_FACTOR=3) Greetings Christoph On Sat, Sep 28, 2019 at 5:05 PM Christoph Cullmann wrote: Hi, I just checked again the HIDPI support of Kate/KWrite on Windows and it "sucked". It seems we never properly did setup the stuff to auto-scale, e.g. the QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true); call was missing, we only had the QCoreApplication::setAttribute(Qt::AA_UseHighDpiPixmaps, true); part that we sprinkled in most of KDE's things in the past. I now rectified that for Kate/KWrite, shall we do this for all our applications? Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: HiDPI issues with KDE applications
On 2019-09-28 17:34, Albert Vaca Cintora wrote: If this has to be done for all apps, why isn't it done at Qt level? Because in some cases, that breaks the application, e.g. if it expects pixel to be real physical pixel 1:1. Therefore, after changing that, one needs to try the application if it behaves OK. (I did that for KWrite/Kate) Greetings Christoph On Sat, Sep 28, 2019 at 5:05 PM Christoph Cullmann wrote: Hi, I just checked again the HIDPI support of Kate/KWrite on Windows and it "sucked". It seems we never properly did setup the stuff to auto-scale, e.g. the QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true); call was missing, we only had the QCoreApplication::setAttribute(Qt::AA_UseHighDpiPixmaps, true); part that we sprinkled in most of KDE's things in the past. I now rectified that for Kate/KWrite, shall we do this for all our applications? Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
HiDPI issues with KDE applications
Hi, I just checked again the HIDPI support of Kate/KWrite on Windows and it "sucked". It seems we never properly did setup the stuff to auto-scale, e.g. the QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true); call was missing, we only had the QCoreApplication::setAttribute(Qt::AA_UseHighDpiPixmaps, true); part that we sprinkled in most of KDE's things in the past. I now rectified that for Kate/KWrite, shall we do this for all our applications? Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Possible to move some KF5 frameworks to invent?
Hi, perhaps this would be some good BoF at Akademy: What is needed to move frameworks development to invent.kde.org. (I assume we want to do that some when in the future anyways) At this point my planning expected that Frameworks would move when the rest of KDE moves (which will likely be a massive migration that happens in very quick succession once everything is ready). is there some timeline known when this might happen? And is there some help needed to handle the transition? Btw., thanks already for all the work you and others did on improving our infrastructure! Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Possible to move some KF5 frameworks to invent?
Hi, > Unfortunately the problem isn't with Frameworks, Applications and > Plasma - they're easy to handle and their naming can be scripted > without too much trouble. > The problem lies with Extragear, which has a large number of projects, > all of which have different rules for what a stable branch is named. As Albert said, the solution would be to establish a common scheme for protected branches. Actually my suggestion was a common scheme for unprotected branches. perhaps this would be some good BoF at Akademy: What is needed to move frameworks development to invent.kde.org. (I assume we want to do that some when in the future anyways) Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Possible to move some KF5 frameworks to invent?
On 2019-08-11 16:53, Albert Astals Cid wrote: El diumenge, 11 d’agost de 2019, a les 12:33:19 CEST, Christoph Cullmann va escriure: Hi, is it possible to move individual framework modules over to invent.kde.org or will that be done at once somewhen in the future? Seems kde-frameworks-devel would be a better list to ask about this. You are right ;=) Would be interested to move syntax-highlighting and ktexteditor if that is possible. But if that shall be done as bulk in the future I can wait ;=) I personally feel the loss of "email gets sent to kde-frameworks-devel on MR" is a problem. Hmm, shouldn't we be able to fix that with adding some "kde-frameworks-devel" user to our gitlab instance that configures it's notification mail address for the KDE group to kde-frameworks-devel@? Also i remember dfaure not being very thrilled about the "not possible to force push to 'my branches' on the main repo" issue. Therefore I CC'ed David, as he needs to be ok with this anyways doing the whole release work. Greetings Christoph Cheers, Albert Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Possible to move some KF5 frameworks to invent?
Hi, is it possible to move individual framework modules over to invent.kde.org or will that be done at once somewhen in the future? Would be interested to move syntax-highlighting and ktexteditor if that is possible. But if that shall be done as bulk in the future I can wait ;=) Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: CI system maintainability
Hi, > Hi, > > On Thu, 28 Mar 2019 at 15:21, Kevin Ottens wrote: > >> Hello, >> >> On Thursday, 28 March 2019 14:33:59 CET laurent Montel wrote: >> > I am against to force mandatory review, as it will create a lot of lose >> of >> > time, >> >> As I said, unpopular. >> > > I don't get why mandatory code reviews are so unpopular. > > I don't care if you lose time. I don't want the guys building my house to > cut corners mixing my concrete because it's going to save time. Why are you > in such a massive hurry to make changes to software which for example holds > access to my Google Account password? In fact, the very fact that you make > this argument makes me wonder if I'm running trustable code on my computer > at all, because apparently doing it quickly is far more important than > doing it right. > > As a user, I simply do not want unreviewed crap running on my computer. > Yes, crap, because no software engineer writes bug-free code all the time, > and if you're so overconfident that you don't need reviews on even your > one-liners, you're probably too overconfident to be writing good code > anyway, so I'm going to operate on the presumption that if the code hasn't > had more than one pair of eyeballs ever looking at it, it's crap. > > As a developer, I know that even one-liners, and especially one-liners, the > sort where you think "meh, this is a tiny little thing, I don't have to be > careful" are the ones that have the most dangerous typos and unintended > bugs. Reviews catch that. > > In a project like PIM, if the code hasn't been through review, which > independent party do I trust to verify that you're not, for example, > leaking my Google password to some world-readable tempfile? Do you really > expect every user to read the entire codebase for themselves and make sure > that's not being done? The whole point of having all the code out in the > open for independent audit purposes, to protect your security and privacy > and what not is completely moot if no one else actually looks at the code > anyway. And let's be honest, the code quality of some of KDE's projects - I > wouldn't touch them with a six-foot pole. The ones I would touch though, > all have multiple people looking at the code and reviewing everything that > goes in. > > Let me be very clear - even if you're the best damn programmer on the > planet, if *you* wrote the code, I do not trust *you* one inch to tell me > that that code is correct. That verification needs to come from someone > else, someone who does not have a conflict of interest in seeing that code > get into production. This is nothing personal, this is confirmation bias on > the author's part which leads to issues that even though they might be > infrequent, usually have catastrophic impact. > > And if "culture" trumps over engineering best practices, it follows that I > should just stop using software produced by this entity because who knows > what it's doing. Mandatory code reviews are nice, if you have the manpower. Look at our phabricator, look for example at the queue of reviews for KTextEditor. The team is small and the code is complex and old (not rocket-science, it is a text editor, but still...). I and others tried to get more reviews done in the past, but actually I merged more than once stuff that I reviewed but it did break the CI. In most cases I fixed it myself afterwards or reverted again, but a few times I needed to get ping'd by others that I was stupid, too. In the current case discussed an error happend, it could have happend exactly the same way if for example "me" would have reviewed it. A lot of the changes which are at the moment in the queue are stuck because a) lack of time to review the change b) lack of time to ever be able to test the change For any non-trivial behavior change (especially for features you not use yourself at all), any meaningful review is a full-time job. e.g. in our company you would let some student test the changed behavior some days. This is just not feasible for me, and yes, for some of these changes, rather than abandoning them (and trashing precious work others did), I will somewhen apply them with close to zero real testing. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: Falkon in kdereview
Hi, > On Sun, Mar 25, 2018 at 11:08 PM, David Rosca <now...@gmail.com> wrote: >> On Sat, Mar 24, 2018 at 7:58 PM, Dr.-Ing. Christoph Cullmann >> <cullm...@absint.com> wrote: >>> Hi, >>> >>> no objections from my side, >>> >>> just a note that we need to take care of the last remaining things on >>> >>> https://community.kde.org/Incubator/Projects/Falkon >>> >>> for the final incubation to be done. >>> >>> I think the mailing list/website stuff shouldn't be an issue to get done. >> >> I've requested mailing list creation, but I'm not sure about the >> website. Does it have to be a site under kde.org (subdomain)? If yes, >> then I'm afraid I have no idea how to proceed there. The other option >> is to host it on my server, as is www.qupzilla.com right now. >> For the site contents it would be enough just basic info and download >> links, I think. >> > > Mailing list and websites are now up and running. Repository was also > moved to extragear. > > Incubation should be completed now. I think so, too. As said in https://phabricator.kde.org/T6857 somebody can take a final look at the manifesto compliance and we are done ;=) Some usable web browser in our umbrella ;=) Nice! Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: Falkon in kdereview
Hi, no objections from my side, just a note that we need to take care of the last remaining things on https://community.kde.org/Incubator/Projects/Falkon for the final incubation to be done. I think the mailing list/website stuff shouldn't be an issue to get done. The Manifest compliance is IMHO there, licensing stuff was reviewed some weeks ago if I am not mistaken. Greetings Christoph - Am 20. Mrz 2018 um 13:40 schrieb nowrep now...@gmail.com: > On Wed, Feb 28, 2018 at 12:10 PM, David Rosca <now...@gmail.com> wrote: >> Hi, >> I'd like to request review for Falkon. >> > > All issues that were pointed out are now fixed. > > It's been in kdereview for over two weeks now, so if there are no > objections I will request move to extragear by the end of this week. > > David -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: Policy regarding QtWebKit and QtScript
Hi, >> Isn't the designated successor for QtScript QJSEngine >> (I even assumed there should be some porting tools?) > > That's what I meant under 'qml engines'. :) > > A relevant mail by Frederik: > http://lists.qt-project.org/pipermail/interest/2015-June/017446.html for KTextEditor: 1) kross is useless for it 2) QJSEngine: I tried to port with Qt 5.4, but it didn't allow for all things needed like setting up some global functions in the engine and wrapping custom datatypes like QtScript did, perhaps this has changed but as IMHO no porting guidelines exist, have not tried it again. (attached the state of the port, if somebody wants to give it a try) But as the above mail indicates, such a guide should come up. Greetings Christoph -- ----- Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 qjs.diff.gz Description: GNU Zip compressed data
QIcon Search Paths Question
Hi,
I tried to set the icon search path relative to the application directory, e.g.
like:
QIcon::setThemeName(QStringLiteral("breeze"));
QIcon::setThemeSearchPaths(QStringList() <<
QCoreApplication::applicationDirPath() + QStringLiteral("/../Resources/icons"));
with breeze dir inside the "icons" path with the index.theme inside.
Sometimes, that even works, sometimes, not.
Is there anything special to do? Does KIconThemes play around with that, too?
Greetings
Christoph
--
----- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com
Science Park 1 Tel: +49-681-38360-22
66123 Saarbrücken Fax: +49-681-38360-20
GERMANYWWW: http://www.AbsInt.com
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: QIcon Search Paths Question
;=)
Forget my question, macdeployqt just purged my svg icon engine ;)
Greetings
Christoph
- Am 21. Okt 2015 um 20:00 schrieb cullmann cullm...@absint.com:
> Hi,
>
> I tried to set the icon search path relative to the application directory,
> e.g.
> like:
>
> QIcon::setThemeName(QStringLiteral("breeze"));
> QIcon::setThemeSearchPaths(QStringList() <<
> QCoreApplication::applicationDirPath() +
> QStringLiteral("/../Resources/icons"));
>
> with breeze dir inside the "icons" path with the index.theme inside.
>
> Sometimes, that even works, sometimes, not.
>
> Is there anything special to do? Does KIconThemes play around with that, too?
>
> Greetings
> Christoph
>
> --
> - Dr.-Ing. Christoph Cullmann -
> AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com
> Science Park 1 Tel: +49-681-38360-22
> 66123 Saarbrücken Fax: +49-681-38360-20
> GERMANYWWW: http://www.AbsInt.com
>
> Geschäftsführung: Dr.-Ing. Christian Ferdinand
> Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
--
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com
Science Park 1 Tel: +49-681-38360-22
66123 Saarbrücken Fax: +49-681-38360-20
GERMANYWWW: http://www.AbsInt.com
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: [Development] Please help me get my pending review count down
Hi, is one of the problems the misuse of QDBus in KUniqueApplication before the actual QApplication is constructed? Would it be possible to just create in that case a temporary QCoreApplication on the stack in KUniqueApplication::start? Kate had similar I get stuck problems until the QApplication was correctly constructed in all cases before the first QDBus use. Greetings Christoph - Ursprüngliche Mail - On Wednesday, July 29, 2015 11:03:15 AM Martin Klapetek wrote: On Wed, Jul 29, 2015 at 11:47 AM, Marc Mutz marc.m...@kdab.com wrote: On Wednesday 29 July 2015 09:04:42 Martin Klapetek wrote: Can you perhaps create a single diff against 5.5/dev/master which could be easily applied? That should make things much easier to help :) Assuming you're talking about the dbus changes, wouldn't you actually want to cherry-pick them one by one and see which one breaks? Perhaps that should be done as well, yes, although Thiago requested the /whole set of changes/ to be tested: I need someone to take the whole set of changes, apply to their Qt 5.5 build and test KF5-powered applications to see what gets broken and why. Please provide patches to either QtDBus, KF5 or the applications. Which would be much simpler with a single diff. Gerrit gives you a git command to copy'n'paste and you can pull the changeset and test it. That's much better than manually applying some plaintext diff. Bye -- Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
RFC: KDE Bugzilla Bugs Expiration
Hi, I think one of the problems with our current Bugzilla database is that it contains a lot of old bugs and wishs. As the manpower is limited and we sometimes not even keep up with the incoming new bugs, might it be a good idea to adopt a similar strategy like the Qt Project and expire bugs that got not changed since more than one year? The idea would that a scripts closes all bugs that have no activity in the last year e.g. on a weekly basis and the closing comment would contain some gentle note that if the bug is still an issue, the reporter (or any person on CC) can just reopen it again. I think this would make a lot of time consuming bug triaging much easier. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: KDE Applications Versioning
Hi, Since this hasn't been finalized I didn't include it in my email to kde-cvs- announce about the creation of the 15.08 branches for the KDE Applications modules. Cheers, Albert El Dimarts, 14 de juliol de 2015, a les 07:08:57, Andreas Cord-Landwehr va escriure: On Monday 13 July 2015 23:14:17 Albert Astals Cid wrote: I did a few tweaks, i still feel it seems this is the official way other than an optional way of defining the version but maybe that's just me. Hi, I have the same feeling as Albert that the current text is not clear enough that both variants (increase version by hand and using the scripted approach) are fine. What about adding an introduction paragraph like the following: - snip - Every application has an application version number that regular has to be increased to distinguish different versions of the application (e.g., features, bugfixes). When an application does not have its own release schedule but is released alongside with KDE Applications, there is also the version number of the KDE Applications release. It is the maintainer's duty to take care on increasing the version number regularly and there are specifically two possible ways: 1. increase the version number by hand for each new release 2. use the same version number as KDE Applications and let the release script update the version number In the following, we explain how to use the scripted version numbers. - snap - If it is OK this way, I can add it later today to the wiki page. I somehow missed that mail ;=) I am all for adding that paragraph and then moving the wiki page to the right place. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: KDE Applications Versioning
- Ursprüngliche Mail - El Dissabte, 11 de juliol de 2015, a les 16:59:13, Christoph Cullmann va escriure: - Ursprüngliche Mail - El Dissabte, 11 de juliol de 2015, a les 15:52:44, Christoph Cullmann va escriure: Hi, something like that? https://userbase.kde.org/KDE_Applications_Versioning I'd like to make it clearer that this is optional and maybe also an example that only uses KDE_APPLICATIONS_VERSION_MICRO Also KDE_APPLICATIONS_VERSION is not replaced at all, just MAJOR MINOR and MICRO as in the script i linked. Yeah, thats true, I just wanted to show the typical boiler plate you might want. Where to move it? userbase doesn't seem the right place for this tbh, what does it have to do with users, techbase? Lol, ok, that's true, I actually wanted to add it to techbase, but guess after the login I ended up on the wrong wiki and did not check that again :/ And is the script in place now? I linked it in the email to the release-team thread (why so much list hopping?), so yes. Because I am not on release-team :P I only read the request for some article here ;=) Next time you send emails there, you may awnt to add a P.S: saying you're not subscribed so people CC you on answers. Yeah, that was my fault, sorry ;=) I updated the page a bit: https://userbase.kde.org/KDE_Applications_Versioning If I get any feedback, until now, nobody touched the page, that this is OK, we should move it over to techbase, any idea for a good location there? Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: KDE Applications Versioning
Hi, something like that? https://userbase.kde.org/KDE_Applications_Versioning Where to move it? And is the script in place now? Greetings Christoph - Ursprüngliche Mail - On Wed, Jul 8, 2015 at 1:24 PM, Aleix Pol aleix...@kde.org wrote: On Wed, Jul 8, 2015 at 11:43 AM, Martin Klapetek martin.klape...@gmail.com wrote: As the KDE Apps release is getting near, is this being considered/deployed? Should we be setting some CMake variables? Cheers -- Martin Klapetek | KDE Developer Yes, that's why Albert was asking for a blog/wiki documentation. ...on a release-team mailing list to which I guess most of us are not subscribed ;) Cheers -- Martin Klapetek | KDE Developer -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: KDE Applications Versioning
- Ursprüngliche Mail - El Dissabte, 11 de juliol de 2015, a les 15:52:44, Christoph Cullmann va escriure: Hi, something like that? https://userbase.kde.org/KDE_Applications_Versioning I'd like to make it clearer that this is optional and maybe also an example that only uses KDE_APPLICATIONS_VERSION_MICRO Also KDE_APPLICATIONS_VERSION is not replaced at all, just MAJOR MINOR and MICRO as in the script i linked. Yeah, thats true, I just wanted to show the typical boiler plate you might want. Where to move it? userbase doesn't seem the right place for this tbh, what does it have to do with users, techbase? Lol, ok, that's true, I actually wanted to add it to techbase, but guess after the login I ended up on the wrong wiki and did not check that again :/ And is the script in place now? I linked it in the email to the release-team thread (why so much list hopping?), so yes. Because I am not on release-team :P I only read the request for some article here ;=) Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: KDE Applications Versioning
On Tue, Jun 9, 2015 at 11:35 AM, David Jarvie djar...@kde.org wrote: There has been debate about this for frameworks, and there is an argument there (not agreed by everybody) for making all frameworks have the same version, since framework libraries are dependencies for other software. The same arguments don't apply to applications, which in general are not dependencies. Other than convenience for maintainers who forget to update version numbers, I can see no good reason for forcing applications to have a uniform version number. I prefer using the version number to reflect the development status of the application (by use of major, minor and patch version numbers), as in the past. This makes it easier when dealing with bug reports, to know the state of the program at the version in question. For maintainers who want to use some other scheme, that's also fine. The important thing is to leave the choice. Personally I prefer having the application versions matching the release version (ie. 15.04.x) so that there is no additional versions mapping required (is version 3.4 part of KDE Applications 15.04 or 15.08 or..?). So I for one would also welcome such feature, but can absolutely relate to David's position too; the versioning should not be forced on Applications. So this could be easily made opt-in by using some predefined CMake variable and projects having such var would get the version raised by the scripts. +1 to that idea. Hi, I don't want to force people to use it, just to have always existing and updated KDE_APPLICATIONS_ variables around for people wanting to use them. And I think it makes sense to use them for a lot apps, given not many apps have any real version number updates it seems ;=) (it makes bug reports much nicer, if you can actually track the bug to some released version) Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
KDE Applications Versioning
Hi, for frameworks, it is all very nice and automatic, the version in the CMakeLists.txt get auto-updated on each KF 5.x release. It seems to me, for the applications collection, something similar might make sense. E.g. I missed to ever update the Kate version since 5.0 and other applications like Dolphin and Konsole seem to have similar problems. Would it make sense to have some we auto-define some version CMake var to KDE Application release number? For e.g. bug reports that would make all things easier. Or do I miss some magic already in place (e.g. the opensuse packages seems to have patched release numbers, at least for Konsole). Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: Scripting/Extensions BoF at Akademy?
Greetings all, I'd like to ask if there is any interest of having a BoF around the topic of script language based extensions for KDE applications. Some applications already offer that, e.g. Kate, and Plasma is even designed around that idea. But currently there seems to be quite some infrastructure implemented multiple times, e.g. a require or include mechanism for QtScript. My goal for the BoF would be to see which functional blocks we have spread across KDE software, if we could identify bits that can be upstreamed and bits that would be nice in a KScriptAddon framework. One thing for the latter could be support for packages, probably based on Plasma packages, as a nice and common way of making application extensions distributable including assets and translations. Hi, for the JS scripting in KatePart I would be interested in a BoF, for the Python stuff I have actually no clue how it works :P Interesting would be, what we should use for scripting actually. KatePart still uses QtScript which is in maintainance mode, I tried to port to the the Qml/JSEngine stuff, but that was to buggy in 5.2, perhaps in 5.3 and later it is usable. Act Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: Scripting/Extensions BoF at Akademy?
On Saturday, 2014-08-09, 18:04:18, Christoph Cullmann wrote: for the JS scripting in KatePart I would be interested in a BoF, for the Python stuff I have actually no clue how it works :P Neither do I but we can certainly discuss multi language support, etc as well if there is an interest by some participants. Some things like packaging is probably applicable in a very similar way. Interesting would be, what we should use for scripting actually. KatePart still uses QtScript which is in maintainance mode, I tried to port to the the Qml/JSEngine stuff, but that was to buggy in 5.2, perhaps in 5.3 and later it is usable. I was primarly thinking about QtScript. My understanding is that despite its label it is still the primary scripting module due to QJSEngine not having all the API yet and all work regarding it being concentrated on the QML use case. But, indeed, this is a good topic as well. Actually, the Qt documentation states in the module list explicitly that QtScript shall not be used for new stuff ;=) Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: KDE Applications December 2014 release: which apps are targeting Qt4/Qt5?
On Monday 21 July 2014 13:26:32 Frank Reininghaus wrote: * Many applications have an embedded terminal, which is provided by the Konsole KPart. If Konsole does not release a Qt5-based version in December, then any application which does will not have an embedded terminal any more. * All of Konqueror's functionality is provided by KParts that are provided by libraries and applications and that are loaded at runtime. If some of these KParts will not have a Qt5-based release, then the functionality of a Qt5-based Konqueror would be severely limited. Are we figuring out a way to co-install both sets of KParts and load the right one at runtime? The Qt plugin mechanism should be enough to prevent the wrong .so file from being loaded, but it would be easier on the system if the files were on different paths on the filesystem. Hi, actually that already works, e.g. Kate KF5 version at the moment loads KonsolePart KF5 version just fine, with Kate Konsole 4.x installed, too. (and without the KF5 KonsolePart installed, Kate still works, thought the poor console window stays empty) Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: KSaveFile, QSaveFile, QFile
On Thursday 21 March 2013 19:02:13 David Faure wrote: I'm afraid it's one or the other: * safe code, always a working file available, but hardlinks get splitted up * possibility to corrupt the existing file, but a backup exists; hardlinks are kept. OK, bug number 2, saving into a non-writable directory, also leads to the above issue: no way to use the safe code. So I implemented direct-overwrite for the case of a non-writable directory. https://codereview.qt-project.org/52059 If this is approved, then the same solution could be used to preserve hardlinks and to preserve the owner if different from the current user, for bug number 3. In bug number 2 there was a suggestion of finding another writable directory in the same partition and moving the file from there, but it seems rather difficult to find such a directory in general, and it wouldn't help with bugs 1 and 3 anyway. Hi, sounds reasonable solutions for the current problems! Searching for some directory that is writable is anyway problematic, guess users will have to live with less safe saving in such settings. Will KSaveFile get some of that patches, too? Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: Interesting issue for kde-baseapps, Jenkins kdesrc-build, proposed solution
Other alternatives include splitting kate up in the various library/runtime- support/application components but that's a lot of extra work for what is really just a kde-projects problem. Does anyone have objections to the sysadmins realigning the 3 git modules in question? (And if so, I'd appreciate ideas for better ways to fix). Hi, I would have no problem with moving kate.git around, splitting is IMHO a pain for later developing on it, as all parts are tightly coupled anyway. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: Login for bug reporting
On Thu, Feb 7, 2013 at 10:26 AM, Anders Lund and...@alweb.dk wrote: Onsdag den 6. februar 2013 22:20:07 skrev Frank Reininghaus: considering that we get lots of duplicates for any reproducible bug, my impression is actually not that there are to many obstacles in the bug reporting process. Providing any kind of contact me via email/Facebook channel will only make it worse. I'm already spending a lot of time marking reports as duplicate/invalid or telling people that reporting bugs for KDE 4.8 or earlier is not quite as useful as they think. Please do not make it worse by lowering the bug reporting barriers. How would the demand for having an account lower the amount of duplicates? The other way round: we already have a lot of duplicates with the current system, if the reports don't have to make an account anymore we would get even more useless reports. Beside, does the account generation not at least validate the E-Mail address, or? I mean, I have nothing against allowing people to login with their Google account or whatever if that is possible, but I would not like to see bug reports by idontc...@lala.org. Greetings Christoph -- -- Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: Login for bug reporting
Hi, actually, if he has taken the obstacles of installing tens of megabytes of stuff, what was the problem with creating an account? Was it some problem with privacy, that he doesn't want his mail to register there (than he won't give his mail address as feedback point, anyway) or was the process to much work? Last time I did so, that takes 1 minute and if you won't spend that time, would you spend the time to reply to any question in the bug you reported, because most times, if the backtrace is not just perfect or it is easily reproducable, without any interaction, the bug won't help at all ;) Greetings Christoph - Ursprüngliche Mail - Hi folks, at FOSDEM I was approached by a person who asked me to relay his dissatisfaction with the requirement of having a KDE Bugzilla account to report crashes via the KDE crash handler dialog. The issue in his case was kind of made worse by having this obstacle appear too late, i.e. after he had followed the instructions to create a useful backtrace and had downloaded several tens of megabytes of debug symbols. Being a FOSS developer himself he said that he understands the need for having a communication channel with the reported, but just having an email address for that would be sufficient (e.g. Debian's bug tracker works that way). So the question is whether alternative login options [1] are something we could do or whether this is impossible in our setup or just something we don't want to do because of certain drawbacks. Cheers, Kevin [1] assuming that a KDE bugzilla login is nowadays a KDE Identity login, could we have something like on the Wikis, e.g. OpenID, or something comment sections of websites used, e.g. login via Facebook? -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring -- -- Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: About Writing Documentation in KDE
El Dilluns, 2 de juliol de 2012, a les 10:00:05, Anne Wilson va escriure: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/07/12 09:00, Albert Astals Cid wrote: El Dilluns, 2 de juliol de 2012, a les 01:45:14, Dominik Haumann va escriure: Hi everyone, so let's sum up and get back to arguments. 1. Versioning for our KDE SC Releases It was mentioned that a wiki automatically provides versioning. However, what is completely not covered, yet, is the fact that we have different KDE SC releases. There is not 'branching' support for the wikis, so you have to create different wiki pages, copying the entire content for each release. Contrary, this is completely covered by maintaining the documentation in the respective modules. This is also the reason why we have documentation freezes (even one of the last freezes [2]). 2. Documentation Team We have a documentation team, even for each of our supported languages. They coordinate on kde-i18n-doc [1], and Burkhard offered support several times, saying that if you do not want to write docbook, the documentation team will do the markup, they even write the documentation for you to some extent. 3. Consistency The documentation team makes sure the documentation sticks to the documentation guidelines for consistency (example: folder vs. directory). This was mentioned in the past several times on the mailing lists. Again, a statement of the documentation team is very important here. 4. Getting Help Please ask the documentation team for their opinion, before raising critics the way it currently works. Maybe it works for a lot of other projects perfectly fine. In the thread it was mentioned, that some people do not even know where the documentation resides (maybe this is due to the partial transition to git). A simple solution is to ask the documentation team (or Burkhard) where to find the documentation. I'm pretty sure the documentation team has really valuable information. Please do not ignore them. 5. A Simple Solution: Possibility of a Combination If docbook really does not work for your project, it's fine to have an additional entry in the Help menu that links to the Community Documentation on UserBase. There is room for both, docbook and the wiki. 6. Respect [4]: Akademy Award In 2010, Burkhard Lück got the Akademy Award for his fantastic work on improving the state of the KDE documentation [3], supported by the entire KDE community. Now, two years later, this thread on kcd acts as if the documentation completely sucks. Guys, it does not. Really. Please think about this for a minute... (see 5.) That's all. 7. The one that does the work decides 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) while people doing documentation and translation of manuals (Yuri, Burkhard, Chusslove) say the current workflow is good. Seems like the The one that does the work decides is being ingored. This is not in any way dissing the work of those that put in much effort but - If the current system is so good, can someone please explain to me why distros ship with docbook help pages that were written years ago and not updated since? Maybe they don't need to be updated? http://techbase.kde.org/Projects/Documentation/KDE4_%28health_table%29 looks quite green to me Yeah, and, just as an other example, look at the state for Kate docs: State of manual: The manual is really nice, Burkhard and Hollingsworth really keep the manual up-to-date and complete. Thanks to the brilliant work of our translators, we even get this translated! Thanks to all for that massive work State of wiki: Look at http://userbase.kde.org/Kate The user base page about Kate is just a small skeleton, even no german translation is around. But, I agree, that it might be nice to have some predefined link in the menu to go to the matching userbase page for the app, if available, in the right language, to allow the user to discover this additional information more easily Greetings Christoph -- -- Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: Using userbase for manuals
On 07/01/2012 07:02 AM, Boudewijn Rempt wrote: After yesterday's discussion where David said that for frameworks/qt5 the help center invocation is actually one of the trickier things, I'm giving this out for consideration for other app developers... Over at Konversation we've likewise struggled to keep our Docbook manual going: It's still among the better ones around, but we've been terribly lazy and let it rot, and if it hadn't been for Burkhard Lück showing it some love last year, it'd would probably be too outdated to use by now. At the same time we're doing reasonably well at maintaining our Userbase presence. We used to have our own MediaWiki installation but migrated everything to Userbase last year, and I wrote some software that sends report mails to our development mailing list highlighting changes and new pages so we can review them and make sure the quality stays high. Newly written documentation is now usually added to the wiki, not the manual, e.g. I wrote this this month: http://userbase.kde.org/Konversation/Configuring_SASL_authentication I can't really put my finger on it, but somehow it's just more convenient and enoyable to do it in the wiki. It gets you easy preview, makes collaboration easier, and somehow it feels like a more appropriate place for topic-focused guides than the book- structured Docbook manual. At the same time topic-focussed guides seem to be the best fit for us, because being an IRC client our helpdesk naturally is the IRC channel and handing out links that answer a particular question comprehensively works very well there. Ultimately Albert isn't wrong with his concern, but the reality seems to be that we just can't get our act together on the offline documentation while maintaining the wiki comes a lot easier to us. And it's better to have wiki documentation than no good documentation, IMHO. +1 for that, but only if it is an extension to the current manuals. For example for Kate, Hollingsworth and Lück did a really GREAT job to write a consistent manual. And like programming, manual writing is nothing arbitrary people can do. Its an art on its own and I doubt we would have the same quality if arbitrary users just write up their knowledge. I think an additional standardized point of contact in the wiki would be great, just like hitting Help... hit Support Base... or what ever and get there the community info that are available for the application. There can be cool stuff, useful FAQ, howtos, video guides, whatever, but I think that should be in the normal case an extension of the local manual. Greetings Christoph -- -- Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: QtScript considered dangerous
On Friday, May 25, 2012 11:14:17 Dominik Haumann wrote: So it's probably non-trivial to create this patch (haven't looked into it, though), a dead end as it's Qt4, and unclear, whether such a patch would be accepted at all in the Qt 4.x line, given that the focus is on Qt5 now. And it's unclear, whether a jsc update would fix the issue, btw :-) Still, a fix for QtScript would be the nicest solution or a port to the new engine provided in Qt5, as I understood, there QtScript is anyway deprecated in favour of the V8 based new variant? But does the new engine provide the same nice features to easily wrap your objects and expose a custom API? That was the major reason we switched over from KJS to QtScript. Greetings Christoph -- -- Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: KDE Frameworks 5: Rhythm
- Original Message - Thiago Macieira wrote: On Monday, 23 de January de 2012 09.58.46, Stephen Kelly wrote: If it does belong to the garbage bin, we should consider getting some stuff into the existing class - making toLower() built into the scheme() etc. Do you have a list of such small fixes? No, I don't. If the most glaring, major flaw doesn't get fixed, what good are the small fixes? If scheme() lower cases, there is no reason for KUrl::protocol to exist. Less difference between Qt and KDE API for no lasting reason is a good thing. Hi, just out of curiosity: Why is Intel blocking this to get into Qt? Greetings Christoph -- -- Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: KDE Frameworks 5: Rhythm
- Original Message - On Tuesday, 24 de January de 2012 19.26.01, Christoph Cullmann wrote: Hi, just out of curiosity: Why is Intel blocking this to get into Qt? The Qt Contribution License Agreement has not been approved internally yet. Ok, I see. Just was curious if that is some no, not this stuff or a general problem. Large companies take their time ;) Greetings Christoph -- -- Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: proposal: remove KTextEditor interface from kdelibs repository
On Tuesday, February 01, 2011 11:11:08 am Sune Vuorela wrote: On 2011-02-01, Aaron J. Seigo ase...@kde.org wrote: --nextPart3865859.bpjpIik9D5 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Monday, January 31, 2011, Michael Pyne wrote: On Monday, January 31, 2011 17:42:56 Aaron J. Seigo wrote: potential caveats are that it makes it harder to build certain KDE apps because now you need not only kdelibs, but kate. this is already true f= or things that require libs in kde-support, kdepimlibs or kdegraphics, though. =20 This is more a package management concern, and while I do want to avoid indeed; i'm hoping one or more of the packagers will chime in at some point. I have commented on the kate developers plans more than once, but people just seems to bring it up over and over again. But no. Nothing has changed in my perception of things. So far, we as packagers have been told that applications can expect all plugins (kio slaves, kparts, ...) located in kdelibs and kdebase-runtime to be available, and segfault is a acceptable way of handling missing things. I agree that this will lead to additional dependency to kate package for some modules, but is this that bad? Application developers has made their *current* apps based on this, and stuff will break by moving e.g. katepart out of kdelibs. Now KTextEditor. KTextEditor is a public library in kdelibs. This means that people can actually expect KTextEditor to be there when they do find_package(KDE4 REQUIRED) Yeah, and because of this requirement, which I can agree on, I didn't remove it from kdelibs, as its public API and I wanted to be SC + BC. And no, runtime components moving to other modules is not a SC/BC problem. It also means that people who builds from source can do svn up / git pull in kdelibs and install new requirements,make, make install and still have all apps working. They never can do that. Every now and then new dependencies come up. New versions of virtuoso needed, new lib*, whatever. You NEVER was able to rely that you can just up + recompile kdelibs and be fine. Normally it not even compiled... I'm unsure why we wants to break the promises we made to the rest of the world about the stability of our libraries. (oh. and why should a kile/kdevelop/... user compile and install kate?) Because it uses katepart? We could even split it up more, in more repos, like katepart, kate, kwrite, but given they interdepend a lot, that is even more hassle. Beside, kile users won't compile it, they will use the versions shipped with the distro. /Sune - who as a packager will have a hard time effectively undoing this work in order to *keep* the compatibility. As a packager, I actually trust KDE to live up to their promises. I still no get this problem. kdelibs adds more and more dependencies over the last years, same for other modules. Why is this dependency change different at all? It is not even a compile time dependency change... Beside: I am grateful for your work as packager and don't want to annoy you. But really, the whole git moving only makes sense, if stuff that is related is grouped. And no, beside using kdelibs stuff, katepart and co. is not really related. And working over 3 repositories is a hassle. (you need to clone all, thats slow on dialup, you need to send at most 3 patches, you need to fiddle with CMake to build only the kate parts, if you want only to have katepart and co. fresh and not all libs, ...) I can understand that new dependencies are work, but I don't see the problem in comparison to other dependencies which change the whole time. To get new contributors for Kate, it is essential, that working on it is EASY. And the current way is easy (http://kate-editor.org/get-it/), the old not. Greetings Christoph -- -- Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
