Re: Telemetry information in Pim apps + ruqola
Le mardi 10 novembre 2020, 11:06:21 CET Ben Cooksley a écrit : > On Tue, Nov 10, 2020 at 6:55 PM Laurent Montel wrote: > > Hi, > > Hi Laurent, > > > I didn't know that it must be necessary to speak about it on > > kde-core-devel > > ML. > > I discussed it with Volker during last Pim sprint for pim apps, for ruqola > > indeed no discussion as it used standard info. > > So I send email as requested > > > > Basically what we are requesting is (from Plasma at bulk, including > > the Plasma shell and Discover): > > - BasicSystemInformation Level: > > Application version > > Platform information > > Qt version information > > > > - BasicUsageStatistics > > Usage time > > Launches count > > > > - DetailedSystemInformation > > Screen parameters > > Number and type of accounts configured in KMail (receiver and sender). > > (for > > kmail only) > > Return the number of account. (ruqola only) > > > > - DetailedUsageStatistics > > Language and regional parameters. > > Thanks for the above details. > > Could you please supply links to the relevant code within the various PIM > applications using Telemetry so we can review the manner in which these > details are collected? Hi, All classes are in theses directories: https://invent.kde.org/pim/kmail/-/tree/master/src/userfeedback https://invent.kde.org/pim/korganizer/-/tree/master/src/userfeedback https://invent.kde.org/pim/pim-sieve-editor/-/tree/master/src/userfeedback https://invent.kde.org/pim/kaddressbook/-/tree/master/src/userfeedback https://invent.kde.org/pim/akregator/-/tree/master/interfaces/userfeedback https://invent.kde.org/network/ruqola/-/tree/master/src/widgets/userfeedback > > Of particular concern to me above is "screen parameters" as the > configuration of a device's screens carries significant information that > when combined with a few other datapoints is often sufficient to create a > unique fingerprint to identify the device. We'll therefore need to ensure > this is sufficiently fuzzed to eliminate that as a possibility. > > > Regards > > Many thanks, > Ben Regards > > > -- > > Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software > > Engineer > > KDAB (France) S.A.S., a KDAB Group company > > Tel: France +33 (0)4 90 84 08 53, http://www.kdab.fr > > KDAB - The Qt, C++ and OpenGL Experts -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel: France +33 (0)4 90 84 08 53, http://www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts
Telemetry information in Pim apps + ruqola
Hi, I didn't know that it must be necessary to speak about it on kde-core-devel ML. I discussed it with Volker during last Pim sprint for pim apps, for ruqola indeed no discussion as it used standard info. So I send email as requested Basically what we are requesting is (from Plasma at bulk, including the Plasma shell and Discover): - BasicSystemInformation Level: Application version Platform information Qt version information - BasicUsageStatistics Usage time Launches count - DetailedSystemInformation Screen parameters Number and type of accounts configured in KMail (receiver and sender). (for kmail only) Return the number of account. (ruqola only) - DetailedUsageStatistics Language and regional parameters. Regards -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel: France +33 (0)4 90 84 08 53, http://www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts
Re: Banning QNetworkAccessManager
Le lundi 3 février 2020, 10:49:10 CET David Edmundson a écrit : > I updated: > > https://community.kde.org/Policies/API_to_Avoid > > Which had no mention of this. > > David I think that you made an error "networkAccessManger->setAttribute(QNetworkRequest::FollowRedirectsAttribute, true); " Doesn't exist it's a enum from QnetworkRequest::RedirectPolicy And FollowRedirectsAttribute is old value It seems that we need to use QnetworkRequest::NoLessSafeRedirectPolicy directly no ? -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent software solutions
Re: Submitting Grantlee as a KF5 Framework
Le samedi 21 décembre 2019, 13:03:17 CET Stephen Kelly a écrit : > On 08/12/2019 10:12, laurent Montel wrote: > > Le dimanche 8 décembre 2019, 10:52:19 CET Volker Krause a écrit : > >> Hi, > >> > >> very happy to see Grantlee "coming home" :) > >> > >> Technically I think it's largely in line with Frameworks requirements > >> already, and it has been reliably powering e.g. KMail's message viewer > >> for > >> years. Moving to a faster and, more importantly, predictable release > >> cycle > >> would help us a lot with upstreaming extensions and improvements though, > >> and would allow us to get rid of some repeated code in applications. > > > > Indeed same for kaddressbook/knotes/akregator :) > > > >> Longer term I'd also hope we can add the support for QtGui types (icons, > >> colors, palettes, etc) that is currently spread around application code, > >> either as a plugin in the Grantlee repo directly, or as a tier 2 > >> framework > >> on top. > >> > >> So, definitely a +1 from me! > > > > +1 for me too > > Great, Grantlee is now available at g...@git.kde.org:grantlee.git. > > I've pushed a few commits to make it depend on ECM etc. > > Once the review period is finished it can be part of KF5 releases. > > Thanks, > > Stephen. Thanks a lot Stephen ! Regards -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent software solutions
Re: Submitting Grantlee as a KF5 Framework
Le dimanche 8 décembre 2019, 10:52:19 CET Volker Krause a écrit : > Hi, > > very happy to see Grantlee "coming home" :) > > Technically I think it's largely in line with Frameworks requirements > already, and it has been reliably powering e.g. KMail's message viewer for > years. Moving to a faster and, more importantly, predictable release cycle > would help us a lot with upstreaming extensions and improvements though, > and would allow us to get rid of some repeated code in applications. Indeed same for kaddressbook/knotes/akregator :) > > Longer term I'd also hope we can add the support for QtGui types (icons, > colors, palettes, etc) that is currently spread around application code, > either as a plugin in the Grantlee repo directly, or as a tier 2 framework > on top. > > So, definitely a +1 from me! +1 for me too Thanks Stephen ! > > Regards, > Volker > > On Friday, 6 December 2019 22:36:09 CET Stephen Kelly wrote: > > Hello, > > > > I have been developing Grantlee for over 10 years with contributions > > from a community of others mostly connected with KDE. > > > > https://github.com/steveire/grantlee > > > > I have not been able to maintain a reasonable release cadence of > > Grantlee in the last few years (last release 3 years ago), so I'm > > submitting Grantlee to KDE Review with the aim of addition to KDE > > Frameworks. > > > > Grantlee consists of two libraries, > > > > * Grantlee::Templates is a text-template system based on Qt introspection > > * Grantlee::TextDocument is a builder design pattern implementation for > > processing QTextDocuments > > > > Grantlee is already a dependency of several KDE applications, but it is > > treated as an external dependency. This change would make it a Tier 1 > > KDE Framework. > > > > $ apt-cache rdepends libgrantlee-templates5 > > libgrantlee-templates5 > > > > Reverse Depends: > >libgrantlee5-dev > >skrooge > >rocs > >libkf5pimcommon5abi3 > >libkf5messageviewer5abi5 > >libkf5messageviewer-plugins > >libkf5kaddressbookgrantlee5 > >libkf5grantleetheme5 > >libkf5grantleetheme-plugins > >libkf5calendarutils5abi1 > >libkf5calendarutils-bin > >kdepim-addons > >kjots > >khelpcenter > >kdevelop52-libs > >kdevelop > > > > $ apt-cache rdepends libgrantlee-textdocument5 > > libgrantlee-textdocument5 > > > > Reverse Depends: > >libgrantlee5-dev > >libkf5pimtextedit5abi3 > >libkf5messageviewer5abi5 > >libkf5messagecomposer5abi2 > >kjots > > > > My intention is to make one more release of Grantlee myself before > > turning it into a KDE Frameworks repository. > > > > I don't think much needs to change in terms of the C++ code. The > > namespace would remain Grantlee:: etc, so that releases made from KDE > > Frameworks will be binary compatible with previous Grantlee5 releases. > > > > However, I've not been putting time into making releases (The last > > release was over 3 years ago). > > > > This is a proposal to submit Grantlee as a KF5 repository. It should be > > a natural addition to the KF5 ecosystem. This move will mean: > > > > * Grantlee will be released regularly as part of KF5 > > * All KDE contributors will have the commit bit to make changes > > * My guilt about lack of releases will be reduced > > > > Grantlee::Templates depends on QtQml for script bindings (can be > > disabled at build time). > > Grantlee::TextDocument depends only on QtGui. > > > > > > I'm not quite familiar with what needs to happen to complete this > > transition. It seems to me that something along these lines ought to do > > it: > > > > * I make one last release of Grantlee myself > > * Set up a new KDE repository for me to push to > > * Integrate KF5 buildsystem into Grantlee (ECM for example) > > * Set up CI for that repository > > * Set up doxygen generation for the repository > > * Transfer grantlee.org to KDE sysadmin > > > > Grantlee already has ki18n integration in the form of a library > > > > implementing Grantlee abstractions: > > https://cgit.kde.org/grantleetheme.git/about/ > > > > Initial reviews and comments welcome! > > > > Thanks, > > > > Stephen. -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent software solutions
Re: Ruqola in KDE-review
Le mardi 17 septembre 2019, 00:07:38 CEST Albert Astals Cid a écrit :
> El dilluns, 16 de setembre de 2019, a les 7:00:32 CEST, laurent Montel va
escriure:
> > Le lundi 16 septembre 2019, 00:14:12 CEST Albert Astals Cid a écrit :
> > > El dijous, 12 de setembre de 2019, a les 9:20:45 CEST, laurent Montel va
> >
> > escriure:
> > > > Hi,
> > > > I would like to move ruqola to extragear/network.
> > > > So I asked to sysadmin to move ruqola to kde-review (it was done).
> > > >
> > > > Ben told me that this period will start in 2 weeks.
> > > >
> > > > If you want to review it... :)
> > >
> > > Now onto the using side:
> > >
> > > Starting it for the first time says
> > >
> > > received something unhandled: "{\"server_id\":\"0\"}"
> > > Connected
> > > org.kde.ruqola: Unknown service type:
> > > "Accounts_OAuth_Gitlab_identity_path" org.kde.rocketchatqtrestapi: Auth
> > > settings is empty. It's a bug
> > > org.kde.rocketchatqtrestapi: Impossible to start
> > > GetSupportedLanguagesJob
> > > org.kde.rocketchatqtrestapi: Impossible to start
> > > GetSupportedLanguagesJob
> >
> > Normal it's a bug from yesterday. This one will be fixed today.
> >
> > > And then the ui says "login failed"
> > >
> > >
> > > Connected to what? Is it attempting to login to something even if i have
> > > never used the app?
> >
> > Yep on open.rocket.chat server. It's the default server. Perhaps I need to
> > disable it.
>
> If there's no user/password i guess it makes sense to not try to log in.
Indeed I will fix it
>
> > ... snip ...
> >
> > > Ah, on the second login looked different and it at least showed my
> > > account
> > > name there on the first line (even though i still was not able to
> > > configure
> > > anything?)
> > >
> > > Searching for "montel" on the webapp on the company server shows me your
> > > chat (that i don't have open), searching for the same on ruqola doesn't,
> > > so
> > > i don't really have a way to talking to you
> >
> > Where do you search it ?
>
> On the left side bar.
It's a lineedit for searching in existing room/channel in listview.
It's not for searching new channel/user as in RC.
For it you need to click on icon at right of this lineedit
There is a menu => "open room"
Regards
>
> This is the webapp when searching for you (blocked your avatar)
> https://i.imgur.com/4EMfwL6.png This is ruqola when searching for you
> https://i.imgur.com/qeSt5Qz.png
>
> Cheers,
> Albert
--
Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53,
www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent
software solutions
Re: Ruqola in KDE-review
Le lundi 16 septembre 2019, 23:01:56 CEST Albert Astals Cid a écrit : > El dilluns, 16 de setembre de 2019, a les 6:54:40 CEST, laurent Montel va escriure: > > Le dimanche 15 septembre 2019, 23:54:19 CEST Albert Astals Cid a écrit : > > > El dijous, 12 de setembre de 2019, a les 9:20:45 CEST, laurent Montel va > > > > escriure: > > > > Hi, > > > > I would like to move ruqola to extragear/network. > > > > So I asked to sysadmin to move ruqola to kde-review (it was done). > > > > > > > > Ben told me that this period will start in 2 weeks. > > > > > > > > If you want to review it... :) > > > > > > class LIBRUQOLACORE_TESTS_EXPORT Emoji > > > has > > > Emoji =(const Emoji ); > > > but no > > > Emoji(const Emoji ); > > > > > > newer gcc complains about it, also the operator= doesn't copy > > > mCachedHtml is that on purpose? If not i'd suggest to simply mark > > > operator= and the copy contructor as = default. > > > > > > > > > > > > > > > class LIBRUQOLACORE_TESTS_EXPORT User > > > also has the same warning, given that the operator= is implemented and > > > not > > > the copy constructor. Same suggestion to just use = default on them. > > > > > > > > > and a whole lots more of classes seem to have this issue. Can you double > > > check them for me? > > > > Fixed thanks > > Awesome, i think i may have forgotten to paste 2 more (the warning log was > very long) > > http://paste.debian.net/1101123/ Fixed thanks > Cheers, > Albert > > > > http://paste.debian.net/1100950/ > > > > > > Cheers, > > > > > > Albert > > > > > > > Regards. -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent software solutions
Re: Ruqola in KDE-review
> Can the icons on the top bar have tooltips? I had no idea what would happen > when pressing the "two people" icon. Done.
Re: Ruqola in KDE-review
Le lundi 16 septembre 2019, 00:14:12 CEST Albert Astals Cid a écrit :
> El dijous, 12 de setembre de 2019, a les 9:20:45 CEST, laurent Montel va
escriure:
> > Hi,
> > I would like to move ruqola to extragear/network.
> > So I asked to sysadmin to move ruqola to kde-review (it was done).
> >
> > Ben told me that this period will start in 2 weeks.
> >
> > If you want to review it... :)
>
> Now onto the using side:
>
> Starting it for the first time says
>
> received something unhandled: "{\"server_id\":\"0\"}"
> Connected
> org.kde.ruqola: Unknown service type: "Accounts_OAuth_Gitlab_identity_path"
> org.kde.rocketchatqtrestapi: Auth settings is empty. It's a bug
> org.kde.rocketchatqtrestapi: Impossible to start GetSupportedLanguagesJob
> org.kde.rocketchatqtrestapi: Impossible to start GetSupportedLanguagesJob
Normal it's a bug from yesterday. This one will be fixed today.
>
> And then the ui says "login failed"
>
>
> Connected to what? Is it attempting to login to something even if i have
> never used the app?
Yep on open.rocket.chat server. It's the default server. Perhaps I need to
disable it.
> Maybe we should not try to do that? it's a bit
> confusing
>
> Can the icons on the top bar have tooltips? I had no idea what would happen
> when pressing the "two people" icon.
I will add tooltips on theses icons.
>
> Quite a few of the "default avatars" (i.e. those that don't have their own
> avatar set) look small and wrong if you compare them to what they look on
> the webapp (see your company chat for an example)
Yep known bug. For the moment I don't understand why.
>
> Configure account is unfinished? https://i.imgur.com/d8wUwNn.png
Yep it's in progress.
> Ah, on the second login looked different and it at least showed my account
> name there on the first line (even though i still was not able to configure
> anything?)
>
> Searching for "montel" on the webapp on the company server shows me your
> chat (that i don't have open), searching for the same on ruqola doesn't, so
> i don't really have a way to talking to you
Where do you search it ?
>
> Also some of the fonts look terrible for a chat app, but that may be because
> of Qt Quick itself :/
I know it. For the moment no idea about this bug too
>
> Compare https://i.imgur.com/d4sKAwn.png (ruqola) with
> https://i.imgur.com/ibZ7Uim.png (kmail)
>
> Other than that it seems that it is a good start, so i agree it's a good
> idea to make some noise around it and see if we can get some more
> contributors :)
>
> Cheers,
> Albert
>
> > Regards.
--
Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53,
www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent
software solutions
Re: Ruqola in KDE-review
Le dimanche 15 septembre 2019, 23:54:19 CEST Albert Astals Cid a écrit : > El dijous, 12 de setembre de 2019, a les 9:20:45 CEST, laurent Montel va escriure: > > Hi, > > I would like to move ruqola to extragear/network. > > So I asked to sysadmin to move ruqola to kde-review (it was done). > > > > Ben told me that this period will start in 2 weeks. > > > > If you want to review it... :) > > class LIBRUQOLACORE_TESTS_EXPORT Emoji > has > Emoji =(const Emoji ); > but no > Emoji(const Emoji ); > > newer gcc complains about it, also the operator= doesn't copy mCachedHtml is > that on purpose? If not i'd suggest to simply mark operator= and the copy > contructor as = default. > > > > > class LIBRUQOLACORE_TESTS_EXPORT User > also has the same warning, given that the operator= is implemented and not > the copy constructor. Same suggestion to just use = default on them. > > > and a whole lots more of classes seem to have this issue. Can you double > check them for me? Fixed thanks > > http://paste.debian.net/1100950/ > > Cheers, > Albert > > > Regards. -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent software solutions
Re: Ruqola in KDE-review
Le jeudi 12 septembre 2019, 11:07:04 CEST Luca Beltrame a écrit : > Il giorno Thu, 12 Sep 2019 09:20:45 +0200 > > laurent Montel ha scritto: > > Hi, > > I would like to move ruqola to extragear/network. > > So I asked to sysadmin to move ruqola to kde-review (it was done). > > Naive question: what does ruqola do? It's a RocketChat client writen in qml. It supports main RC features. (it supports new server 2.0.0 too). See https://rocket.chat/ -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent software solutions
Ruqola in KDE-review
Hi, I would like to move ruqola to extragear/network. So I asked to sysadmin to move ruqola to kde-review (it was done). Ben told me that this period will start in 2 weeks. If you want to review it... :) Regards. -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent software solutions
Re: CI system maintainability
Le jeudi 28 mars 2019, 18:27:42 CET Friedrich W. H. Kossebau a écrit : > Thanks for reply. More below: > > Am Donnerstag, 28. März 2019, 16:56:33 CET schrieb laurent Montel: > > Le jeudi 28 mars 2019, 16:11:12 CET Friedrich W. H. Kossebau a écrit : > > > Hi Laurent, > > > > > > Am Donnerstag, 28. März 2019, 14:33:59 CET schrieb laurent Montel: > > > > For example I works all days on kde (pim or other) when I wake up, or > > at > > > > > noon after my lunch or the evening, I will not wait several days for a > > > > review because nobody has time to do it. > > > > > > > > (For example I make ~ 15 commits by days on pim/ruqola/framework, I > > > > don't > > > > want to wait several days/weeks until someone wants to review my > > patchs) > > > > Something might be lost in translation here, do you think, because you > > > work > > > daily on code of KDE projects, and other people (so potential reviewers) > > > do > > > not, this is an argument to do instant pushes of unreviewed commits? > > > > I maintain pim* from several years, I fix bugs, I improve apps, I fix all > > bugs that I put in my code, so for this one I consider that I can commit > > without review them (as other guys on other project that they maintain). > > For framework I mainly use phabricator. > > I was thinking of projects where there are multiple persons contributing/ > maintaining, like Frameworks. For framework I use mainly phabricator See https://phabricator.kde.org/people/revisions/196/ > > So for projects where you are the only person who has any real insight, > indeed I agree to pushing directly, as I do that as well :) > > Because IMHO the costs for having to hope & wait for somebody else to do a > "review", where one then spends lots of time rather explaining things to > someone, who is not really into the project and also never might be, is not > anywhere worth the time one could have otherwise invested in fixing other > existing bugs or adding new features or improving code quality. > > If people want to get into a project, doing own patches or just watching the > commits and asking normally on irc or by email about the architecture > should work good enough. Abusing reviews for teaching about some project > would annoy me at least, usually the patch is to fix some annoying bug or > add a wanted feature, so it should get in as early as possible. > > > > Not sure where this is from, but often I have seen an unwritten policy > > > applied where people for a patch uploaded for review after one week of > > > no > > > response add a ping and then wait another week, before finally pushing > > the > > > > change. To me this seems a fair and reasonable policy, only ignores > > people > > > > who are on vacation for some more weeks or otherwise inactive, but I > > > have > > > not seen that ever been a real issue. > > > > 2 weeks for a commit, for me it's too long. > > I understand why people can be demotivated when they must wait long time > > until having an answer. > > Well, 2 weeks is the time-out, only reached in worst case. Ideally people > give some feedback before, which often enough happens. And indeed one also > has to hunt people down to get a review, like at meetings or in chat (or > trade review work with each other :) ). But isn't this the same also at > work- work, unless there is a dedicated review team which needs to react by > itself? Co-operating on something needs social interaction after all. > > > > Given the actual purpose of this thread, I would be more curious how you > > > have CI integrated in your workflow? > > > > CI: sometime I look at it, sometime not, sometime some guys informs me > > that > > it's broken (I remember that Luca told me some days ago that a package > > didn't compile, so I fixed it). > > Sometime my code compiles on local so for me it's ok but it's just that I > > forgot to trash my builddir. > > So you do not go on yourself to build.kde.org and check yourself? Does #kde- > pim have a bot reporting build failures? Long time ago we had it in #kontact. It's not the case now. > > For what I can tell e.g. for KDevelop, personally I rely on the bot on > #kdevelop reporting the CI state/build results, as I only look at emails > rather once a day, while the chat channel is more real-time, and one also > can immediately talk to peers about why some build now fails, as well as > coordinate who will fix that. > > > > And where things could be improved,
Re: CI system maintainability
Le jeudi 28 mars 2019, 16:11:12 CET Friedrich W. H. Kossebau a écrit : > Hi Laurent, > > Am Donnerstag, 28. März 2019, 14:33:59 CET schrieb laurent Montel: > > For example I works all days on kde (pim or other) when I wake up, or at > > noon after my lunch or the evening, I will not wait several days for a > > review because nobody has time to do it. > > > > (For example I make ~ 15 commits by days on pim/ruqola/framework, I don't > > want to wait several days/weeks until someone wants to review my patchs) > > Something might be lost in translation here, do you think, because you work > daily on code of KDE projects, and other people (so potential reviewers) do > not, this is an argument to do instant pushes of unreviewed commits? I maintain pim* from several years, I fix bugs, I improve apps, I fix all bugs that I put in my code, so for this one I consider that I can commit without review them (as other guys on other project that they maintain). For framework I mainly use phabricator. > > While I understand one can get impatient if not getting instant review of > changes one would like to depend on with further changes (I know this well > :) ), still this seems a flawed argument at least for > part-time-contributors based KDE projects, where the people one co-operates > with only have time now and then, like once per week. It could be seen > unfair & ignorant to them if one simply ignores their opinion, because one > has more time reserved/ available. KPIM doesn't have a big active team... > Not sure where this is from, but often I have seen an unwritten policy > applied where people for a patch uploaded for review after one week of no > response add a ping and then wait another week, before finally pushing the > change. To me this seems a fair and reasonable policy, only ignores people > who are on vacation for some more weeks or otherwise inactive, but I have > not seen that ever been a real issue. 2 weeks for a commit, for me it's too long. I understand why people can be demotivated when they must wait long time until having an answer. I know that I don't participate a lot on qtcreator dev as we need to wait long time to have some review... > > Given the actual purpose of this thread, I would be more curious how you > have CI integrated in your workflow? CI: sometime I look at it, sometime not, sometime some guys informs me that it's broken (I remember that Luca told me some days ago that a package didn't compile, so I fixed it). Sometime my code compiles on local so for me it's ok but it's just that I forgot to trash my builddir. > And where things could be improved, to > prevent the current state of unhappiness for people who care about CI some > more? Given you said you work daily on KDE projects, it seems that the > brokeness of those projects on the KDE CI has slipped your attention. So > how does this happen, and how could this be prevented, other than people > having to hunt you down on irc and tell you :) I think that Luca idea to send an email directly to the people which breaks code when it breaks from several commit is a good idea. If I received directly a message about kcontact 19.04 after 1 days I fixed it directly. Master build correctly and unfortunately I don't have 19.04 and master in parallel. Regards > > Cheers > Friedrich -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent software solutions
Re: CI system maintainability
Le jeudi 28 mars 2019, 09:29:22 CET Kevin Ottens a écrit : > Hello, > > On Thursday, 28 March 2019 09:16:11 CET Ben Cooksley wrote: > > Please note that the commits in this instance were pushed without > > review, so restrictions on merge requests wouldn't make a difference > > in this case unfortunately. > > Maybe it's about time to make reviews mandatory... I know it's unpopular in > KDE, and I advocated for "don't force a tool if you can get someone to look > at your screen or pair with you" in the past. Clearly this compromise gets > somewhat exploited and that's especially bad in the case of a fragile and > central component like KDE PIM. > > Regards. Hi, I am against to force mandatory review, as it will create a lot of lose of time, and we will not be sure that review is correct (see comment from Volker about "transaction lock regression") It's necessary to having a big team for doing it. Ok a repo was broken, but it was just that fix was created in master not 19.04, I didn't see nobody on IRC told us "this package is always broken", when I saw it this morning I just cherry pick (2 seconds for fixing it). For example I works all days on kde (pim or other) when I wake up, or at noon after my lunch or the evening, I will not wait several days for a review because nobody has time to do it. (we can see a review from zanshin for example https://phabricator.kde.org/D16210 we can see that David waited 2 months until having an answer...). (For example I make ~ 15 commits by days on pim/ruqola/framework, I don't want to wait several days/weeks until someone wants to review my patchs) I will not lose my time to review some code that I don't understand... I never reviewed Akonadi patch as I don't understand this code, and I will take time on it just for the pleasure as I prefer fixing bug or adding new features in components that I maintain. When we have a big team as Qt team it can help but in pim component where we don't have any redundant guy, we will lose a lot of time. So for each increase version for each package I will wait a review. For sure not. Each time that I will improve code as coding style I will wait that someone wants to review... I know that it's easy to write "make reviews mandatory" there is not an impact about your work as we know that you are not really active on kde at the moment... For sure I broke kcontact 2 days ago, but as a friend told me when I started to work on kde "We can't create a bug when we don't code..." Regards -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent software solutions
Re: Zanshin is in kdereview
Le dimanche 2 juillet 2017, 18:43:38 CEST Kevin Ottens a écrit : > > But what I can say from my work in Debian is that often Debian needs to > > coordinate the discussion to get rid of copies, that could have been > > avoided if the different projects had been talking directly with each > > other. > > > > For me the existence of those copies and no discussions with kdepim are a > > -1 for moving it out of Review. > > You're assuming this wasn't discussed previously. It's been discussed a long > time ago in person. It's not like no one in kdepim knew about it. Hi, Kevin and me discussed about it long time ago when zanshin was ported to kf5. So indeed a kdepim guy (me) knows it :) Regards > Regards. -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent software solutions
Re: Please cleanup your scratch and clone repositories
Hi, Done. I cleaned up my reporitories Regards -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent software solutions
Re: Dropping kdelibs4-based applications in KDE Applications 17.12
Le jeudi 10 novembre 2016, 23:42:36 CET Albert Astals Cid a écrit : > Hi, my proposal would be to make KDE Applications 17.08 the last release we > accept applications based on kdelibs4, that means people have a year until > KDE Applications 17.12 to port the applications from the list below to KF5. > > The ones that aren't ported we would just drop to unmaintained or if they > have an active developer team that somehow doesn't want to move to KF5 they > could move to "extreagear". > > I know lots of you would want to see this happen *now* but remember there's > people using those apps so dropping them makes them no good. > > Comments? > > Cheers, > Albert > There is a framework branch for theses games: > kgoldrunner > kigo > kolf > konquest > kreversi > ksnakeduel > kspaceduel > ksudoku > kubrick > lskat > palapeli But nobody merged or finished porting. I made first step but for sure I didn't have time to finish it. +1 remove them in 17.12 if nobody finishs porting. -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent software solutions
Re: [Kde-pim] Qt 4 Builds
Le lundi 28 mars 2016, 00:50:20 CEST Kevin Kofler a écrit : > laurent Montel wrote: > > Oh?:) > > Fedora continue to support some programs which are not supported from > > several years before kdepim5 ? > > Fedora would not have to do that if you were not removing functionality as > large as entire applications (!) between releases. > > Also, KNode still works great, maybe BECAUSE it is "not supported from > several years" and so did not get infected with Akonadi. And it has still qt3support it was never port to qt4 pure. Fedora helped us to port to qt4 pure and port to qt5 ? I didn't see patchs for it. So yep I removed it because I don't want to maintain another application. But if you port to qt4 pure + qt5 + fix bugs ok we can speak about to reintegrate it. > KNode still works > as well as in the pre-Akonadi days. KMail 2 has become literally 100 to 1000 > times slower (!) :) I like to see theses number without real tests :) > and a lot more buggy than KMail 1, simply from getting > ported to Akonadi. I think that I closed a lot of bugs against kmail1 and kmail2. But you can continue to support knodes/ktimertracker during age, it's not my problem now that KDE CI removed it. (but I don"t see fix for knodes provided by fedora dev) > > > Interesting good luck :) > > > > Better solution to find others new programs which are maintaining no ? > > Point me to a maintained NNTP client using Qt, and at least I will happily > consider switching to it. (At least if it doesn't use Akonadi. ;-) ) > > This message was brought to you by KNode (through Gmane). > > Kevin Kofler -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: [Kde-pim] Qt 4 Builds
Le dimanche 27 mars 2016, 15:31:47 CEST Martin Koller a écrit : > On Sunday 27 March 2016 09:21:01 laurent Montel wrote: > > Le dimanche 27 mars 2016, 10:57:18 CEST Ben Cooksley a écrit : > > > Hi all, > > > > > > As part of the CI overhaul, we've attempted to perform a complete set > > > of builds for Qt 4, as it's still (unfortunately) used. > > > > > > Sadly, as expected for something nobody has really tried to build for > > > ages, many things don't build. > > > One of those is the entire PIM suite - because Baloo removed it's Qt 4 > > > build metadata (meaning as far as the CI system is concerned, Baloo > > > has no Qt 4 branches and is Qt 5 only) > > > > > > You've two options here: > > > 1) Drop Qt 4 PIM. > > > 2) Reinstate Baloo's Qt 4 branches. > > > > > > I intend to carry out option #1 if there is no response to this. > > > > I vote for #1 too. > > We will not create more release from kdepim4, no distro uses it even > > debian :) > The latest openSuse (Leap 42.1) ships the Qt4 based kdepim, although it uses > plasma5 desktop. It's opensuse problem :) > > Speaking of it: given that openSuse decided against shipping KF5-based PIM, > how stable is KF5-based PIM considered these days ? > Is it ready for productive daily professional use ? For me yep it's stable with an akonadi better than kde4 akonadi. -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: [Kde-pim] Qt 4 Builds
Le dimanche 27 mars 2016, 16:08:09 CEST Luigi Toscano a écrit : > laurent Montel ha scritto: > > Le dimanche 27 mars 2016, 14:02:26 CEST Luigi Toscano a écrit : > >> laurent Montel ha scritto: > >>> Le dimanche 27 mars 2016, 11:58:07 CEST Kevin Kofler a écrit : > >>>> laurent Montel wrote: > >>>>> We will not create more release from kdepim4, no distro uses it even > >>>>> debian :) > >>>> > >>>> Fedora will ship (it's currently under review) a kdepim4 package > >>>> containing > >>>> KNode and KTimeTracker, which are not included in the new KF5 kdepim. > >>> > >>> Oh?:) > >>> Fedora continue to support some programs which are not supported from > >>> several years before kdepim5 ? > >>> Interesting good luck :) > >>> > >>> Better solution to find others new programs which are maintaining no ? > >> > >> Do you plan an akonadi resource for NNTP? :) > > > > It's necessary to have an application which use akonadi ? > > For sure Akregator kf5 doesn't use akonadi and it's not a problem. > > > > (and yes there was a nntp akonadi resource in kde4 removed in kf5 as > > unused) > No, it's not necessary, but when KNode was removed I thought that the idea > was to integrate the NNTP viewing inside KMail, more or less like what > Thunderbird does. Hence my question. It was a plan long time ago, but it complexified a lot kmail for it. It was not just a new resources, it was change a lot kmail to support it. I preferred a kmail as actual as a mixte between mail and nntp support. Regards. > Ciao -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: [Kde-pim] Qt 4 Builds
Le dimanche 27 mars 2016, 11:58:07 CEST Kevin Kofler a écrit : > laurent Montel wrote: > > We will not create more release from kdepim4, no distro uses it even > > debian :) > > Fedora will ship (it's currently under review) a kdepim4 package containing > KNode and KTimeTracker, which are not included in the new KF5 kdepim. Oh?:) Fedora continue to support some programs which are not supported from several years before kdepim5 ? Interesting good luck :) Better solution to find others new programs which are maintaining no ? Regards > > Kevin Kofler -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: [Kde-pim] Qt 4 Builds
Le dimanche 27 mars 2016, 10:57:18 CEST Ben Cooksley a écrit : > Hi all, > > As part of the CI overhaul, we've attempted to perform a complete set > of builds for Qt 4, as it's still (unfortunately) used. > > Sadly, as expected for something nobody has really tried to build for > ages, many things don't build. > One of those is the entire PIM suite - because Baloo removed it's Qt 4 > build metadata (meaning as far as the CI system is concerned, Baloo > has no Qt 4 branches and is Qt 5 only) > > You've two options here: > 1) Drop Qt 4 PIM. > 2) Reinstate Baloo's Qt 4 branches. > > I intend to carry out option #1 if there is no response to this. I vote for #1 too. We will not create more release from kdepim4, no distro uses it even debian :) So +1 for #1 Regards > > As a general anecdote, the community needs to decide if we are going > to continue releasing and supporting Qt 4 builds at all. Considering > Qt 4 itself is EOL per upstream I believe, I think it's time we > followed suit. > > Regards, > Ben > ___ > KDE PIM mailing list kde-...@kde.org > https://mail.kde.org/mailman/listinfo/kde-pim > KDE PIM home page at http://pim.kde.org/ -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: RFC: KDE Bugzilla Bugs Expiration
Le Friday 31 July 2015, 11:07:54 Daniel Vrátil a écrit : On Friday, July 31, 2015 10:12:00 AM Christoph Cullmann wrote: Hi, I think one of the problems with our current Bugzilla database is that it contains a lot of old bugs and wishs. True that! 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. We were actually discussing something similar for KDE PIM but our idea was based on Fedora, i.e. closing all bugs for given release when the release goes EOL. There is a comment added by a bot 3 weeks before EOL stating that the release will go EOL and if user thinks the bug is still valid in newer/current release, they should re-assign to newer release. When the release actually goes EOL all bugs still assigned to it are closed. The advantage of this approach IMO is that it also clears out bugs where the reporters are no longer available/willing to provide additional info to devs and at the same time without losing bugs which might be important yet non-trivial to fix (read: take more than a year for a dev to get there). Especially for KDE PIM, given the size of the userbase and the amount of developers (3), bugs often take more than a year to get to and to be fixed. +1 As Daniel wrote we have a lot of bug and a very small team. So we can't able to fix bug in 1 year. And I don't want to see all bugs closed after 1 year because it's useful to read all bug and sometime it takes me some months/years to fix bugs. Regards I think this would make a lot of time consuming bug triaging much easier. Cannot agree more :) Cheers, Daniel Greetings Christoph -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: Moving akonadi from kdesupport and akonadi-search from playground
Le Friday 24 July 2015, 00:13:48 Albert Astals Cid a écrit : El Dimarts, 21 de juliol de 2015, a les 13:52:01, Daniel Vrátil va escriure: On Monday, July 20, 2015 04:17:16 PM Daniel Vrátil wrote: Hi all, we (the KDE PIM team) kinda screwed up when we forgot to communicate our intentions about next KDE PIM release with the release team and we ended up in a situation that we have some repositories in modules from which they cannot be released as part of KDE Applications, so releasing KF5-based KDE PIM as part of KDE Applications is currently endangered. Normally I'd have to ask for the 2-week review period before moving the repos but since we are under a big time pressure and because the modules have both proven themselves (see below), I kindly ask for those repositories to be granted an exception to the review period and they can be moved right away. akonadi-search repository contains PIM-specific code that originally lived in Baloo repository and was split out when Baloo switched to KF5. We only ported the code to KF5 and removed all mentions of Baloo from code (it's now Akonadi::Search namespace). Technically this code already went through review when Baloo has been reviewed for move from playground, and also during Baloo development, and has been actively used with KDE PIM 4.x for several releases. akonadi I think has proven itself well enough in during the years :) I'd like to move both repositories to kde/pim module where other KDE PIM repos (mostly those split from kdepimlibs) currently live. If that's fine with everyone I'd request the move ASAP. Hi all, if there are no objections, I'll request the repos to be move later in the afternoon. Please let's get this done and end this painful release asap. I don't know why it did not do it yet. Dan ask it 2 days ago but no news. I don't know why it was not done yet. Regards Albert Thanks, Dan Cheers, Daniel -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: Moving akonadi from kdesupport and akonadi-search from playground
Le Tuesday 21 July 2015, 13:52:01 Daniel Vrátil a écrit : On Monday, July 20, 2015 04:17:16 PM Daniel Vrátil wrote: Hi all, we (the KDE PIM team) kinda screwed up when we forgot to communicate our intentions about next KDE PIM release with the release team and we ended up in a situation that we have some repositories in modules from which they cannot be released as part of KDE Applications, so releasing KF5-based KDE PIM as part of KDE Applications is currently endangered. Normally I'd have to ask for the 2-week review period before moving the repos but since we are under a big time pressure and because the modules have both proven themselves (see below), I kindly ask for those repositories to be granted an exception to the review period and they can be moved right away. akonadi-search repository contains PIM-specific code that originally lived in Baloo repository and was split out when Baloo switched to KF5. We only ported the code to KF5 and removed all mentions of Baloo from code (it's now Akonadi::Search namespace). Technically this code already went through review when Baloo has been reviewed for move from playground, and also during Baloo development, and has been actively used with KDE PIM 4.x for several releases. akonadi I think has proven itself well enough in during the years :) I'd like to move both repositories to kde/pim module where other KDE PIM repos (mostly those split from kdepimlibs) currently live. If that's fine with everyone I'd request the move ASAP. Hi all, if there are no objections, I'll request the repos to be move later in the afternoon. I spoke with Dan. He told me that Ben waited more feedback from kde dev about it. He kde-code-dev guys could you give us more feedback please ? It urges because Albert waits this moving for creating 15.08. For the moment it's postponed. Thanks Regards Thanks, Dan Cheers, Daniel -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: Moving akonadi from kdesupport and akonadi-search from playground
Le Monday 20 July 2015, 17:08:45 Daniel Vrátil a écrit : On 20.07.2015 16:44, Martin Sandsmark wrote: On Mon, Jul 20, 2015 at 04:17:16PM +0200, Daniel Vrátil wrote: We only ported the code to KF5 Unless I'm misunderstanding something, isn't this a quite significant change? From experience even seemingly simple ports can introduce pretty serious breakage in edge cases. True, although the core code is mostly plain Qt wrapper around Xapian. We've (me, Laurent and few people on #kontact) been using it for couple weeks - months now without any problems. Yep I use it from 2 months without problem. I fixed some bugs etc. It's not just a porting we use it. Regards Dan -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: Moving akonadi from kdesupport and akonadi-search from playground
Le Monday 20 July 2015, 22:58:39 Luigi Toscano a écrit : Daniel Vrátil ha scritto: Hi all, we (the KDE PIM team) kinda screwed up when we forgot to communicate our intentions about next KDE PIM release with the release team and we ended up in a situation that we have some repositories in modules from which they cannot be released as part of KDE Applications, so releasing KF5-based KDE PIM as part of KDE Applications is currently endangered. I have a related question about this (sorry for hijacking the thread), but as I'm moving translations around... - do you mean do you want to move those to modules to kdepim? We don't want to merge it in kdepim We want to move in KDE/ . - do we need all kdepim, kdepim-runtime, kdepimlibs AND kde/pim? For what ? Ciao -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: Kdebugsettings in kdereview
Le Tuesday 14 April 2015 06:46:14 laurent Montel a écrit : Ok It's in kdereview from the 23 march. Is it ok to move it ? Regards No answer from the 14 april. So I will ask to move it from kde-review to kdeutils. Regards
Re: Kdebugsettings in kdereview
Le Tuesday 21 April 2015 19:54:39 Albert Astals Cid a écrit : El Dimarts, 21 d'abril de 2015, a les 14:02:26, laurent Montel va escriure: Le Tuesday 14 April 2015 06:46:14 laurent Montel a écrit : Ok It's in kdereview from the 23 march. Is it ok to move it ? Regards No answer from the 14 april. So I will ask to move it from kde-review to kdeutils. I actually had a reminder in my calendar to say +1 if noone had said so yet, so +1 :D Great :) Thanks Regards Cheers, Albert Regards -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: Kdebugsettings in kdereview
Ok It's in kdereview from the 23 march.
Is it ok to move it ?
Regards
Le Monday 23 March 2015 08:19:40 laurent Montel a écrit :
Le Sunday 22 March 2015 22:27:57 Albert Astals Cid a écrit :
El Diumenge, 22 de març de 2015, a les 21:06:15, laurent Montel va
escriure:
Le Sunday 22 March 2015 13:43:25 Albert Astals Cid a écrit :
El Diumenge, 22 de març de 2015, a les 08:40:42, laurent Montel va
escriure:
Hi,
Now kdebugsettings is in kdereview.
All features are implemented before 1.0.
This application allows to configure qloggingcategories.
Is this a replacement of kdebugdialog? Or it can't do kdebug stuff and
thus
we need both?
It's not a replacement for kdebugdialog.
Kdebugdialog modified kdebug and qdebug doesn't use same method.
So not it's not a replacement.
I would like to move it in kdeutils or kdeadmin in the future.
Please use it and reports bug about it.
So we are back to having a huge file with all the categories on it?
Yes because qt doesn't support as in kde4 a dynamic categories.
That's quite unfortunate :/
Is there at least a way so that we don't have to write everything in that
kde.categories file but let's say that okular installs it's own categories
file?
Yes we have it.
const QStringList dirs =
QStandardPaths::locateAll(QStandardPaths::GenericConfigLocation,
QStringLiteral(qdebug.categories/), QStandardPaths::LocateDirectory);
Q_FOREACH (const QString dir, dirs) {
const QStringList fileNames = QDir(dir).entryList(QStringList()
QStringLiteral(*.categories));
Q_FOREACH (const QString file, fileNames) {
Category::List categoriesLocal =
KDebugSettingsUtil::readLoggingCategories(dir + QLatin1Char('/') + file);
categories categoriesLocal;
}
}
We can load file with extension .categories.
Regards
Cheers,
Albert
--
Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: [Kde-pim] The Future or KDE PIM Releases
Le Tuesday 14 April 2015 00:17:39 Albert Astals Cid a écrit : El Diumenge, 12 d'abril de 2015, a les 11:31:26, Daniel Vrátil va escriure: Greetings from Toulouse! Instead we will aim towards releasing KF5-based KDE PIM with Akonadi 1 in the next release of KDE Applications in August. That means we now have about 4 months to make sure that there are no regressions caused by changes in Qt behavior - this should be manageable and not much effort really. This is an internal change more or less, users won't notice anything. Meaning we stop releasing the LTS 4.14 by then? Yep after release kf5 version we will stop it indeed. But until it I will continue to fix 4.14.x version. So we will release some 4.14.x version yet. Regards. Cheers, Albert -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: Kdebugsettings in kdereview
Le Sunday 22 March 2015 22:27:57 Albert Astals Cid a écrit :
El Diumenge, 22 de març de 2015, a les 21:06:15, laurent Montel va escriure:
Le Sunday 22 March 2015 13:43:25 Albert Astals Cid a écrit :
El Diumenge, 22 de març de 2015, a les 08:40:42, laurent Montel va
escriure:
Hi,
Now kdebugsettings is in kdereview.
All features are implemented before 1.0.
This application allows to configure qloggingcategories.
Is this a replacement of kdebugdialog? Or it can't do kdebug stuff and
thus
we need both?
It's not a replacement for kdebugdialog.
Kdebugdialog modified kdebug and qdebug doesn't use same method.
So not it's not a replacement.
I would like to move it in kdeutils or kdeadmin in the future.
Please use it and reports bug about it.
So we are back to having a huge file with all the categories on it?
Yes because qt doesn't support as in kde4 a dynamic categories.
That's quite unfortunate :/
Is there at least a way so that we don't have to write everything in that
kde.categories file but let's say that okular installs it's own categories
file?
Yes we have it.
const QStringList dirs =
QStandardPaths::locateAll(QStandardPaths::GenericConfigLocation,
QStringLiteral(qdebug.categories/), QStandardPaths::LocateDirectory);
Q_FOREACH (const QString dir, dirs) {
const QStringList fileNames = QDir(dir).entryList(QStringList()
QStringLiteral(*.categories));
Q_FOREACH (const QString file, fileNames) {
Category::List categoriesLocal =
KDebugSettingsUtil::readLoggingCategories(dir + QLatin1Char('/') + file);
categories categoriesLocal;
}
}
We can load file with extension .categories.
Regards
Cheers,
Albert
--
Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Kdebugsettings in kdereview
Hi, Now kdebugsettings is in kdereview. All features are implemented before 1.0. This application allows to configure qloggingcategories. I would like to move it in kdeutils or kdeadmin in the future. Please use it and reports bug about it. Thanks Regards -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: Kdebugsettings in kdereview
Le Sunday 22 March 2015 13:43:25 Albert Astals Cid a écrit : El Diumenge, 22 de març de 2015, a les 08:40:42, laurent Montel va escriure: Hi, Now kdebugsettings is in kdereview. All features are implemented before 1.0. This application allows to configure qloggingcategories. Is this a replacement of kdebugdialog? Or it can't do kdebug stuff and thus we need both? It's not a replacement for kdebugdialog. Kdebugdialog modified kdebug and qdebug doesn't use same method. So not it's not a replacement. I would like to move it in kdeutils or kdeadmin in the future. Please use it and reports bug about it. So we are back to having a huge file with all the categories on it? Yes because qt doesn't support as in kde4 a dynamic categories. There's nothing we can do with this new and improved Qt to have dynamic categories like we had in kdebug? I don't think that Qt has project to implement it. You have an empty README file, either add something or remove it? I will fix it. It does not have a COPYING file. Indeed I will add it Thanks for info. Cheers, Albert Thanks Regards -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: Review Request 122987: Allow user to specify path to myspell dictionary files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122987/#review77617 --- src/plugins/hunspell/CMakeLists.txt https://git.reviewboard.kde.org/r/122987/#comment53304 you add a / at the end and in source code you use MYSPELL_DICTS_PATH/%1.dic = it will create /usr/...//%1.dic = you need to remove a / somewhere. - Laurent Montel On mars 17, 2015, 11:16 matin, Eugene Shalygin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122987/ --- (Updated mars 17, 2015, 11:16 matin) Review request for kdelibs. Repository: sonnet Description --- Not on all systems myspell dictionaries are located in /usr/share/myspell/dicts/, which is hardcoded in the hunspell plugin sources. For instance, on Gentoo it is /usr/share/myspell/. So let the user define this path. Diffs - src/plugins/hunspell/CMakeLists.txt 098fb49 src/plugins/hunspell/hunspell-plugin-conf.h.cmake PRE-CREATION src/plugins/hunspell/hunspellclient.cpp 9e3aa67 src/plugins/hunspell/hunspelldict.cpp 621113d Diff: https://git.reviewboard.kde.org/r/122987/diff/ Testing --- hunspell plugin began to work on Gentoo Thanks, Eugene Shalygin
Re: Review Request 122987: Allow user to specify path to myspell dictionary files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122987/#review77636 --- Ok for me. Just wait that maintainer gives you a Ship it - Laurent Montel On mars 17, 2015, 1:09 après-midi, Eugene Shalygin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122987/ --- (Updated mars 17, 2015, 1:09 après-midi) Review request for KDE Frameworks and kdelibs. Repository: sonnet Description --- Not on all systems myspell dictionaries are located in /usr/share/myspell/dicts/, which is hardcoded in the hunspell plugin sources. For instance, on Gentoo it is /usr/share/myspell/. So let the user define this path. Diffs - src/plugins/hunspell/CMakeLists.txt 098fb49 src/plugins/hunspell/config-hunspellplugin.h.cmake PRE-CREATION src/plugins/hunspell/hunspellclient.cpp 9e3aa67 src/plugins/hunspell/hunspelldict.cpp 621113d Diff: https://git.reviewboard.kde.org/r/122987/diff/ Testing --- hunspell plugin began to work on Gentoo Thanks, Eugene Shalygin
Re: Review Request 122987: Allow user to specify path to myspell dictionary files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122987/#review77631 --- I am not maintainer of this module but I can put a +1 - Laurent Montel On mars 17, 2015, 1:05 après-midi, Eugene Shalygin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122987/ --- (Updated mars 17, 2015, 1:05 après-midi) Review request for KDE Frameworks and kdelibs. Repository: sonnet Description --- Not on all systems myspell dictionaries are located in /usr/share/myspell/dicts/, which is hardcoded in the hunspell plugin sources. For instance, on Gentoo it is /usr/share/myspell/. So let the user define this path. Diffs - src/plugins/hunspell/CMakeLists.txt 098fb49 src/plugins/hunspell/config-hunspellplugin.h.cmake PRE-CREATION src/plugins/hunspell/hunspellclient.cpp 9e3aa67 src/plugins/hunspell/hunspelldict.cpp 621113d Diff: https://git.reviewboard.kde.org/r/122987/diff/ Testing --- hunspell plugin began to work on Gentoo Thanks, Eugene Shalygin
Re: Review Request 122987: Allow user to specify path to myspell dictionary files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122987/#review77630 --- src/plugins/hunspell/hunspellclient.cpp https://git.reviewboard.kde.org/r/122987/#comment53311 #include ... we use local file. - Laurent Montel On mars 17, 2015, 1:05 après-midi, Eugene Shalygin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122987/ --- (Updated mars 17, 2015, 1:05 après-midi) Review request for KDE Frameworks and kdelibs. Repository: sonnet Description --- Not on all systems myspell dictionaries are located in /usr/share/myspell/dicts/, which is hardcoded in the hunspell plugin sources. For instance, on Gentoo it is /usr/share/myspell/. So let the user define this path. Diffs - src/plugins/hunspell/CMakeLists.txt 098fb49 src/plugins/hunspell/config-hunspellplugin.h.cmake PRE-CREATION src/plugins/hunspell/hunspellclient.cpp 9e3aa67 src/plugins/hunspell/hunspelldict.cpp 621113d Diff: https://git.reviewboard.kde.org/r/122987/diff/ Testing --- hunspell plugin began to work on Gentoo Thanks, Eugene Shalygin
Re: Review Request 122471: Enable Compilation of about Protocol
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122471/#review75584 --- about/kio_about.cpp https://git.reviewboard.kde.org/r/122471/#comment52281 QApplication app(argc, argv); app.setApplicationName(QLatin1String(kio_about)); = you remove KComponentData which is in kdelibs4support - Laurent Montel On fév. 7, 2015, 10:23 après-midi, David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122471/ --- (Updated fév. 7, 2015, 10:23 après-midi) Review request for kde-workspace and David Faure. Repository: kio-extras Description --- Basically porting away from QUrl and KDE_EXPORT Diffs - CMakeLists.txt 3379ce7 about/kio_about.h 620d6aa about/kio_about.cpp d7396d8 Diff: https://git.reviewboard.kde.org/r/122471/diff/ Testing --- Tested compilation and installation: $ find /home/david/kio-install/ -name *about* /home/david/kio-install/lib64/plugins/kio_about.so /home/david/kio-install/share/kservices5/about.protocol Thanks, David Narváez
Re: Review Request 122471: Enable Compilation of about Protocol
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122471/#review75657 --- Seems good. Did you changed commit message as David told you ? Otherwise ship it. - Laurent Montel On fév. 9, 2015, 6:03 matin, David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122471/ --- (Updated fév. 9, 2015, 6:03 matin) Review request for kde-workspace and David Faure. Repository: kio-extras Description --- Basically porting away from QUrl and KDE_EXPORT Diffs - CMakeLists.txt 3379ce7 about/kio_about.h 620d6aa about/kio_about.cpp d7396d8 Diff: https://git.reviewboard.kde.org/r/122471/diff/ Testing --- Tested compilation and installation: $ find /home/david/kio-install/ -name *about* /home/david/kio-install/lib64/plugins/kio_about.so /home/david/kio-install/share/kservices5/about.protocol Thanks, David Narváez
Re: [Kde-pim] kdepimlibs splitting done
Le Friday 12 December 2014 05:19:00 Aleix Pol a écrit : Hi, I have performed the first round of kdepimlibs splitting tonight, as we agreed. Below you can see the for reference how the splitting was performed. Dan, Laurent, can you give me the ok? Then we can proceed to remove the modules from the kdepimlibs repository. Hi, For me it's ok. I didn't test module but as you keep history and split it you can remove module from kdepimlibs. Regards.
Re: [Kde-pim] kdepimlibs splitting done
Le Friday 12 December 2014 12:11:22 laurent Montel a écrit : Le Friday 12 December 2014 05:19:00 Aleix Pol a écrit : Hi, I have performed the first round of kdepimlibs splitting tonight, as we agreed. Below you can see the for reference how the splitting was performed. Dan, Laurent, can you give me the ok? Then we can proceed to remove the modules from the kdepimlibs repository. Hi, For me it's ok. I didn't test module but as you keep history and split it you can remove module from kdepimlibs. Regards. You need to make active module in project.kde.org otherwise kdesrc-build will not work. Thanks -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: [Kde-pim] kdepimlibs splitting done
Le Friday 12 December 2014 13:00:29 Aleix Pol a écrit : On Fri, Dec 12, 2014 at 12:15 PM, laurent Montel mon...@kde.org wrote: Le Friday 12 December 2014 12:11:22 laurent Montel a écrit : Le Friday 12 December 2014 05:19:00 Aleix Pol a écrit : Hi, I have performed the first round of kdepimlibs splitting tonight, as we agreed. Below you can see the for reference how the splitting was performed. Dan, Laurent, can you give me the ok? Then we can proceed to remove the modules from the kdepimlibs repository. Hi, For me it's ok. I didn't test module but as you keep history and split it you can remove module from kdepimlibs. Regards. You need to make active module in project.kde.org otherwise kdesrc-build will not work. Thanks -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr Hi Laurent, I've enabled all repositories' tooling as well as made master the kf5 trunk branch. Ok thanks. So for me split it. (indeed send info to kde-i18n but you can do it) Thanks Regards
KFind
Hi, I think that we can use Dolphin to search files. I want to remove Kfind from kde-baseapps. It was not ported and there is not maintainer. If nobody has an objection I will remove it at before christmas. Regards. -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: KFind
Le Friday 05 December 2014 10:33:07 Martin Gräßlin a écrit : On Friday 05 December 2014 10:00:24 laurent Montel wrote: Hi, I think that we can use Dolphin to search files. I want to remove Kfind from kde-baseapps. It was not ported and there is not maintainer. If nobody has an objection I will remove it at before christmas. I don't think that Dolphin's search is a working replacement for KFind as it uses an indexer which only indexes a subset of the system by default. Dolphin's search is awesome, but it's not a solution for when I need to use KFind. Ok I see. I'm also surprised that you say not ported, because I remember to have ported it ;-) Indeed it's not finish to port (I worked on it too). Still depend against kdelibs4support . Ok so we still need to have a maintainer which will finish porting. Cheers Martin -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Kdepim* master will not release with 4.14.12
Hi, Finally there is still more work to do. So we can't release kdepim based on kf5 in 4.14.12. I will postpone it for next release. Could you use 4.14 branch please for 4.14.12 ? Thanks -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: Releases in 3 months
Hi, As you know I work a lot on kdepim (but you forgot to ask me if it was a good idea or I didn’t receive mail... :) ) Ok kdelibs and kde-workspace is frozen until KDE SC5 so less work for you for example. But for kdepim we are not a big team, and we have a lot of feature to implement and it’s not possible in 2 months. For example I finished my last feature 2 days ago (sorry I was a lot of feature to do for 4.11) So I disagree to reduce development time to 2 months just because kde- workspace is frozen. And as it’s frozen why reduce development time ? Why increase number of release ? Just to increase number ? So for my point of view it’s not a good idea to reduce time, we will speed to create feature so more bugs because not big period of test, or we will stop to develop feature because we don’t have time to finish. Why is the reason to divide by 2 the release time ? Regards Le lundi 8 juillet 2013 15:04:40 Àlex Fiestas a écrit : Now that kde-workspace and kdelibs are going to be frozen (which in theory means less work for everybody) I'd like to propose a new release schedule to be applied starting with 4.12. Basically the idea is to cut testing time and compensate it by keeping master always in a releaseable state, now that two major components are frozen it looks like it is a good time to get used to it. You can read all the proposal in: http://community.kde.org/KDE_Core/ReleasesProposal Before sending this email I have checked with distro people, i18n people, other developers and almost all of them seemed to either like or be neutral about it (only one exception :p) so I hope that the proposal is not a complete disaster. As its name indicates, it is a proposal, so please be constructive in the feedback, we can change as many things as we need. Finally, I have scheduled a Bof at Akademy, would be nice to have all the feedback from the community that is not able to come before it happens: http://community.kde.org/Akademy/2013/Wednesday#Room_A2_-_17_July Cheers ! -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090
Re: Releases in 3 months
Le lundi 8 juillet 2013 16:11:05 Frank Reininghaus a écrit : Hi, 2013/7/8 Àlex Fiestas: Now that kde-workspace and kdelibs are going to be frozen (which in theory means less work for everybody) I'd like to propose a new release schedule to be applied starting with 4.12. Basically the idea is to cut testing time and compensate it by keeping master always in a releaseable state, now that two major components are frozen it looks like it is a good time to get used to it. You can read all the proposal in: http://community.kde.org/KDE_Core/ReleasesProposal Before sending this email I have checked with distro people, i18n people, other developers and almost all of them seemed to either like or be neutral about it (only one exception :p) so I hope that the proposal is not a complete disaster. As its name indicates, it is a proposal, so please be constructive in the feedback, we can change as many things as we need. I like the idea (from the Dolphin development point of view). Most of the changes that went into master during the past months had already been tested rather well before they were merged, and the remaining regressions were found rather quickly by people who use the master branch a lot. Therefore, it would have been nice if some of the improvements could have been shipped to users sooner - quite a few bugs that had been fixed in master (with patches that were IMHO too intrusive for the 4.10 branch) months ago were reported again and again. @Laurent:you say that you have a lot of features to implement, and that this would not be possible with a shorter release schedule. But wouldn't it be possible to implement some of the features for the next version and the rest for the one after that? If you think that you need more time to stabilize a feature in the master branch, then maybe developing the feature in a separate branch and merge it once it's finished might be a good idea? No it’s not a good idea because nobody tests branch you can see pb that we had when we merge akonadi branch (last big changes). So no develop in branch will just create more bugs. And same question: why reduce time by 2 ? What we will have as result ? Ok in january with will release 4.14 great, so it’s right we will never release a so big number of kde but don’t know if it’s a good idea to run after number... And when we reduce time for example for 4.12 which finish in october, for me for example I have 2 weeks of vacations = dev == 1 month 1/2 ! Great for create features... Kdelibs and kdebase frozen is good for kdelibs/kdebase dev but it will not impact on kdepim... Best regards, Frank -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090
Re: Releases in 3 months
Le lundi 8 juillet 2013 16:19:02 Àlex Fiestas a écrit : I did pasted the link in #kontact and #akonadi a couple of times before sending this email :p I never saw it. And paste on irc is not speak with guy which works several project. The development time is NOT divided and it is NOT limited to 2 months, instead now master will be always open to include features and once every 3 months we'll make a release. So at a specific date you takes code without freeze before ?! For example, if you take a look at this pic: http://community.kde.org/images.community/b/b8/Drawing.png For example between 4.12 branching (15/10) and 4.13 branching (15/01/2014) there will be 3 months. If for whatever reason your feature is not stable to go into 4.13, you can delay it for 4.14 which will happen 3 months after, so not much is changing of how we are doing things now. So you will take code from what ? I will continue to work on master so you will take a broken code ? It’s more logical to freeze master until release otherwise you will release broken code it’s sure. Said it in another way, if you want to keep a 6 months release schedule you can ! this just allow others to ship features more often. Finally, I'm NOT proposing this because kde-workspace and kdelibs are frozen, that's just an opportunity to change the release cycle since it will affect less people. You can read the motivation here: http://community.kde.org/KDE_Core/ReleasesProposal#Motivation The main motivation for this change is to reduce the amount of time between releases and make them simpler, making us able to deliver new features faster to our users while keeping if not improving the current quality. “ deliver new features faster” ? :) new feature broken yes (less time more bugs) Regards Cheers ! On Monday 08 July 2013 15:45:13 you wrote: Hi, As you know I work a lot on kdepim (but you forgot to ask me if it was a good idea or I didn’t receive mail... :) ) Ok kdelibs and kde-workspace is frozen until KDE SC5 so less work for you for example. But for kdepim we are not a big team, and we have a lot of feature to implement and it’s not possible in 2 months. For example I finished my last feature 2 days ago (sorry I was a lot of feature to do for 4.11) So I disagree to reduce development time to 2 months just because kde- workspace is frozen. And as it’s frozen why reduce development time ? Why increase number of release ? Just to increase number ? So for my point of view it’s not a good idea to reduce time, we will speed to create feature so more bugs because not big period of test, or we will stop to develop feature because we don’t have time to finish. Why is the reason to divide by 2 the release time ? Regards -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090
Re: Releases in 3 months
Le lundi 8 juillet 2013 19:55:46 Albert Astals Cid a écrit : El Dilluns, 8 de juliol de 2013, a les 15:45:13, laurent Montel va escriure: Hi, As you know I work a lot on kdepim (but you forgot to ask me if it was a good idea or I didn’t receive mail... :) ) Ok kdelibs and kde-workspace is frozen until KDE SC5 so less work for you for example. But for kdepim we are not a big team, and we have a lot of feature to implement and it’s not possible in 2 months. For example I finished my last feature 2 days ago (sorry I was a lot of feature to do for 4.11) Errr, what? You finished a feature 2 days ago? Why? We've been feature frozen for 1 month! Yes I finished it 2 days ago, but started 2 months ago. So it was bug fixing, I didn’t create new feature 2 days ago. And I had 6 months to develop it, so think when there is 3 months to do it. Regards. Cheers, Albert -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090
Re: Review Request 109568: GHNS3: If the provider file lists a register account URL, provide a link to that in the upload dialog
On March 22, 2013, 5:38 p.m., Laurent Montel wrote: For me seems good. Regards Sven Brauch wrote: Sorry to annoy you again ;) just to make sure, I'd push this to kdelibs master now, ok? I hope nobody will mind the increase in the required attica version... yes in master. Regards - Laurent --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109568/#review29732 --- On March 22, 2013, 11:31 a.m., Sven Brauch wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109568/ --- (Updated March 22, 2013, 11:31 a.m.) Review request for Attica, kdelibs and Jeremy Paul Whiting. Description --- When the provider file lists an URL to register a new account, this patch adds a link to the login screen of the upload dialog which enables a user to register a new account. This patch depends on https://git.reviewboard.kde.org/r/109567/. Diffs - CMakeLists.txt b116f50 knewstuff/knewstuff3/uploaddialog.h 3f58f7d knewstuff/knewstuff3/uploaddialog.cpp 922469e knewstuff/knewstuff3/uploaddialog.ui aa54d2b knewstuff/knewstuff3/uploaddialog_p.h 1bb0af4 Diff: http://git.reviewboard.kde.org/r/109568/diff/ Testing --- Thanks, Sven Brauch
Re: Review Request 109568: GHNS3: If the provider file lists a register account URL, provide a link to that in the upload dialog
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109568/#review29670 --- You need to increase attic - Laurent Montel On March 18, 2013, 5:41 p.m., Sven Brauch wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109568/ --- (Updated March 18, 2013, 5:41 p.m.) Review request for Attica, kdelibs and Jeremy Paul Whiting. Description --- When the provider file lists an URL to register a new account, this patch adds a link to the login screen of the upload dialog which enables a user to register a new account. This patch depends on https://git.reviewboard.kde.org/r/109567/. Diffs - knewstuff/knewstuff3/uploaddialog.h 3f58f7d knewstuff/knewstuff3/uploaddialog.cpp 922469e knewstuff/knewstuff3/uploaddialog.ui aa54d2b knewstuff/knewstuff3/uploaddialog_p.h 1bb0af4 Diff: http://git.reviewboard.kde.org/r/109568/diff/ Testing --- Thanks, Sven Brauch
Re: Review Request 109568: GHNS3: If the provider file lists a register account URL, provide a link to that in the upload dialog
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109568/#review29671 --- You need to increase attica version and make kdelibs depends against it. Otherwise it will not compile. We can't depends against git master version, we must have a official release regards. - Laurent Montel On March 18, 2013, 5:41 p.m., Sven Brauch wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109568/ --- (Updated March 18, 2013, 5:41 p.m.) Review request for Attica, kdelibs and Jeremy Paul Whiting. Description --- When the provider file lists an URL to register a new account, this patch adds a link to the login screen of the upload dialog which enables a user to register a new account. This patch depends on https://git.reviewboard.kde.org/r/109567/. Diffs - knewstuff/knewstuff3/uploaddialog.h 3f58f7d knewstuff/knewstuff3/uploaddialog.cpp 922469e knewstuff/knewstuff3/uploaddialog.ui aa54d2b knewstuff/knewstuff3/uploaddialog_p.h 1bb0af4 Diff: http://git.reviewboard.kde.org/r/109568/diff/ Testing --- Thanks, Sven Brauch
Re: Review Request 109568: GHNS3: If the provider file lists a register account URL, provide a link to that in the upload dialog
On March 22, 2013, 6:20 a.m., Laurent Montel wrote: You need to increase attica version and make kdelibs depends against it. Otherwise it will not compile. We can't depends against git master version, we must have a official release regards. Sven Brauch wrote: Ah, yes. So, I would increase attica's version from 0.4.1 to 0.4.2 and make kdelibs master depend on that? Yes - Laurent --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109568/#review29671 --- On March 18, 2013, 5:41 p.m., Sven Brauch wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109568/ --- (Updated March 18, 2013, 5:41 p.m.) Review request for Attica, kdelibs and Jeremy Paul Whiting. Description --- When the provider file lists an URL to register a new account, this patch adds a link to the login screen of the upload dialog which enables a user to register a new account. This patch depends on https://git.reviewboard.kde.org/r/109567/. Diffs - knewstuff/knewstuff3/uploaddialog.h 3f58f7d knewstuff/knewstuff3/uploaddialog.cpp 922469e knewstuff/knewstuff3/uploaddialog.ui aa54d2b knewstuff/knewstuff3/uploaddialog_p.h 1bb0af4 Diff: http://git.reviewboard.kde.org/r/109568/diff/ Testing --- Thanks, Sven Brauch
Re: Review Request 109568: GHNS3: If the provider file lists a register account URL, provide a link to that in the upload dialog
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109568/#review29732 --- For me seems good. Regards - Laurent Montel On March 22, 2013, 11:31 a.m., Sven Brauch wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109568/ --- (Updated March 22, 2013, 11:31 a.m.) Review request for Attica, kdelibs and Jeremy Paul Whiting. Description --- When the provider file lists an URL to register a new account, this patch adds a link to the login screen of the upload dialog which enables a user to register a new account. This patch depends on https://git.reviewboard.kde.org/r/109567/. Diffs - CMakeLists.txt b116f50 knewstuff/knewstuff3/uploaddialog.h 3f58f7d knewstuff/knewstuff3/uploaddialog.cpp 922469e knewstuff/knewstuff3/uploaddialog.ui aa54d2b knewstuff/knewstuff3/uploaddialog_p.h 1bb0af4 Diff: http://git.reviewboard.kde.org/r/109568/diff/ Testing --- Thanks, Sven Brauch
Re: Review Request 108965: fix kde_infopage css for webkit
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108965/#review28660 --- Ship it! Seems good. Ship it. - Laurent Montel On March 5, 2013, 6 p.m., Xuetian Weng wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108965/ --- (Updated March 5, 2013, 6 p.m.) Review request for kdelibs and KDEPIM. Description --- Now a bunch of application render their info page with WebKit, for example kmail. But this css still using -khtml prefix for them so they are looks very bad. This page simply add new background-size: property, also keep the old -khtml one. And please notice that -khtml-background-size: 100%; is changed to background-size: 100% 100%; in order to archieve same semantics. Diffs - kdeui/about/kde_infopage.css 05e2b3ea Diff: http://git.reviewboard.kde.org/r/108965/diff/ Testing --- now all kdepim looks ok, and konqueror still looks all the same (seems about:konqueror is still using KHTML). Thanks, Xuetian Weng
Re: Review Request 108637: Fix KColorButton change color + cancel behaviour
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108637/#review26728 --- Ship it! For me seems good. Ship it. - Laurent Montel On Feb. 5, 2013, 11:56 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108637/ --- (Updated Feb. 5, 2013, 11:56 p.m.) Review request for kdelibs and Laurent Montel. Description --- Do not connect colorSelected to _k_colorChosen otherwise two bad things happen: a) Selecting a color and canceling still changes the color of the color button (this is KColorButtonTest::testChangeAndCancel that fails without my change) b) If you are in Recent Colors there's a crash (bug 313984 because a lot of bad things happen (this is KColorButtonTest::testRecentColorsPick that crashes without my change) Laurent added connect(dialog, SIGNAL(colorSelected(QColor)), q, SLOT(_k_colorChosen())); to make sure that double click worked, thus i've added KColorButtonTest::testDoubleClickChange() to prove it still works after my change Comments? Developed against master, plan to apply against KDE/4.10 too Diffs - kdeui/tests/kcolorbuttontest.cpp PRE-CREATION kdeui/tests/kcolorbuttontest.h PRE-CREATION kdeui/tests/CMakeLists.txt 85f12ed kdeui/colors/kcolorbutton.cpp 786cb9d Diff: http://git.reviewboard.kde.org/r/108637/diff/ Testing --- Okular no longer crashes, the tests pass Thanks, Albert Astals Cid
Re: Review Request 108637: Fix KColorButton change color + cancel behaviour
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/108637/#review26294
---
kdeui/colors/kcolorbutton.cpp
http://git.reviewboard.kde.org/r/108637/#comment20013
Perhaps this signal/slot is not necessary
because okClicked() call accept()
which emit accepted()
see:
void QDialog::done(int r)
{
emit finished(r);
if (r == Accepted)
emit accepted();
...
}
so for me we can remove this line.
- Laurent Montel
On Jan. 28, 2013, 12:27 a.m., Albert Astals Cid wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/108637/
---
(Updated Jan. 28, 2013, 12:27 a.m.)
Review request for kdelibs and Laurent Montel.
Description
---
Do not connect colorSelected to _k_colorChosen otherwise two bad things
happen:
a) Selecting a color and canceling still changes the color of the color
button (this is KColorButtonTest::testChangeAndCancel that fails without my
change)
b) If you are in Recent Colors there's a crash (bug 313984 because a lot of
bad things happen (this is not in my tests, will add later if you guys agree
this is the correct fix))
Laurent added
connect(dialog, SIGNAL(colorSelected(QColor)), q,
SLOT(_k_colorChosen()));
to make sure that double click worked, thus i've added
KColorButtonTest::testDoubleClickChange() to prove it still works after my
change
Comments?
Developed against master, plan to apply against KDE/4.10 too
Diffs
-
kdeui/colors/kcolorbutton.cpp 786cb9d
kdeui/tests/CMakeLists.txt 85f12ed
kdeui/tests/kcolorbuttontest.h PRE-CREATION
kdeui/tests/kcolorbuttontest.cpp PRE-CREATION
Diff: http://git.reviewboard.kde.org/r/108637/diff/
Testing
---
Okular no longer crashes, the tests
Thanks,
Albert Astals Cid
Re: Review Request: Fix opening links in translation tab of KAboutApplicationDialog
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107706/#review23465 --- Ship it! Seems good. Ship it - Laurent Montel On Dec. 13, 2012, 6:26 p.m., Lasse Liehu wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107706/ --- (Updated Dec. 13, 2012, 6:26 p.m.) Review request for kdelibs. Description --- See the summary. Diffs - kdeui/dialogs/kaboutapplicationdialog.cpp 24e982d Diff: http://git.reviewboard.kde.org/r/107706/diff/ Testing --- Compiles and links can be opened. Thanks, Lasse Liehu
Re: Review Request: KConfigXT performance fix: no need to reparse when nothing to save
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103166/#review8410 --- Ship it! Ship It! - Laurent Montel On Nov. 17, 2011, 3:41 p.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103166/ --- (Updated Nov. 17, 2011, 3:41 p.m.) Review request for kdelibs and Aaron J. Seigo. Description --- Closing a kmail composer window takes a very long time, because it's calling writeConfig() on 7 kconfigskeleton objects (see KMKernel::slotSyncConfig), and each of them calls KConfig::sync() [that's ok, it doesn't do anything if there's no change to save, i.e. no dirty entry] followed by readConfig(), which calls KConfig::reparseConfiguration(). That's a lot of config file parsing, for a case where *nothing has changed*. Looking into the history of the kconfigskeleton code didn't help finding out why writeConfig calls readConfig, this was added by Waldo in the initial code in 2003. A real sync() with dirty entries triggers a reparsing (to merge changes on-disk with changes in memory), so it makes sense to propagate the changes from KConfig to the KConfigSkeleton member variables after a sync. But not when sync does nothing at all. Diffs - kdecore/config/kconfig.h 51381ca kdecore/config/kconfig.cpp fcf0ce9 kdecore/config/kcoreconfigskeleton.cpp f5dd4bf Diff: http://git.reviewboard.kde.org/r/103166/diff/diff Testing --- kdecore unittests pass. The testing of closing a composer window isn't fully fixed with this patch alone, kmail2rc is still reparsed because the kdeui code that calls revertToDefault on entries that are equal to the default value, makes the config dirty. This requires a different fix which I'll submit separately. Thanks, David Faure
Re: [Kde-pim] Who relies on Soprano::Model::statement[s]Added|Removed signals?
Le Wednesday 5 October 2011 08:55:08 Volker Krause a écrit : On Friday 30 September 2011 13:36:22 Sebastian Trüg wrote: Hi lists, with frameworks in the building and Nepomuk probably going that direction already for 4.8 I would like to clean up a bit. One of these cleanup tasks targets the Soprano::Model statement signals. So far these were the only way to get informed about changes in Nepomuk - with a very bad impact on performance and bad usability. With 4.7 we already introduced a preliminary version of the Nepomuk::ResourceWatcher[1] which is now in charge of informing clients about changes. I would like to anyone using the old API to change to the new ResourceWatcher as soon as possible because I would like to disable the old signals soon. They simply entail to many problems and clutter the API. kdepim uses those signals in the following places: - libmessagelist (kdepim/messagelist) - kmail - Nepomuk tag resource (kdepim-runtime/resources/nepomuktag) regards Volker There is a HOWTO to explain how to convert it ? Regards
