Request for Code Review for Falkon merge request
Hello, I work on a Falkon feature (per site settings in sqlite database) which I believe should be done more or less in one go correctly. That is because it can make Falkon unusable since it runs on each page reload and maybe more. So, i would like to request a CodeReview, the knowledge of good practice within Qt development would help me a lot. The merge request can be found at #72 of Falkon repository: https://invent.kde.org/network/falkon/-/merge_requests/72 Feel free to roast it since I want to include it in a release within this year. PS: It is still a little a work in progress, but I am not sure if the current code is worth adding more to. Thank you very much. Best regards, Juraj signature.asc Description: This is a digitally signed message part.
Re: Should we stop distributing source tarballs?
On piatok 5. apríla 2024 9:04:14 CEST Tobias Leupold wrote: > Am 05.04.24 um 06:25 schrieb Juraj Oravec: > > Hello Albert, > > > > The release tarballs can be signed with GPG (or is it PGP?) which > > provide another layer of protection to make sure the release is > > authenthic. > > > > If KDE wants to lead by example and use only git tags for releases, > > at least the tags should be signed with GPG for verification. > > > > It would be best to have all commits in the repository signed (in > > Gitlab "Verified"). While we are unable to make sure that the > > historical commits are also signed, since most of them are not, at > > least new commits and tags should be signed. Maybe the commits can > > be signed retrospectively (while breaking the repository history), > > but this is probablôy just my dream. > > If all commits in the xz repo would have been signed, the backdoor > would have been sneaked in as well -- only that the commit would have > been signed. Also if the tags would have been signed, the releases > with the backdoor would have been published exactly as is -- only > difference: The respective tags would have been signed. > > Just sayin ... You are correct, it would not solve a problem of corrupted tarballs. I am saying this for the "git tag" approach proposed in the first mail. How do we ensure that the repository was not tempered with by third party along the way by lets say governments or network companies? The governments wants (and in some states they already do) install a root certificates into your machines so that they can interfere in the encrypted https traffic. If the commits or at least tags are not signed, it makes it easy for them (in the name of safety) to redirect the packager or user to different server with tempered repository. Noone will suspect anything since there is no mechanism to make sure it is authentic. Other than hard working honest developers, nothing can protect us from the xz type of attack. Juraj signature.asc Description: This is a digitally signed message part.
Re: Should we stop distributing source tarballs?
On streda 3. apríla 2024 18:34:04 CEST Albert Vaca Cintora wrote: > Hi KDE folks, > > The recent xz backdoor scandal made me realize how bad and obsolete > distributing tarballs is. The source of truth for our code are the > repositories, and releases can simply be tags on those repos. > > As a big free software community, I think we should lead by example > and get rid of tarballs altogether (as I hope to see in other projects > as well) after the recent events. > > Packagers can git pull. > > If we ever replace git with something else, that something else will > have tags as well. > > What's the advantage of providing tarballs? > > Albert Hello Albert, The release tarballs can be signed with GPG (or is it PGP?) which provide another layer of protection to make sure the release is authenthic. If KDE wants to lead by example and use only git tags for releases, at least the tags should be signed with GPG for verification. It would be best to have all commits in the repository signed (in Gitlab "Verified"). While we are unable to make sure that the historical commits are also signed, since most of them are not, at least new commits and tags should be signed. Maybe the commits can be signed retrospectively (while breaking the repository history), but this is probablôy just my dream. With modern approach for "reproducible" builds in the Linux distributions, it is required to provide a way to make sure that the release is authentic, the tarballs allows that, but with current use of git tags we do not even provide a way to make sure the tag was made by trusted developer or a release team, iinstead the tag could be faked by anyone providing another way of entry. Have a nice day. Juraj signature.asc Description: This is a digitally signed message part.
Re: Can we rename gitklient?
Hello, I suggest: - ReThinKit One should revisit the code which is going to be commited and really think what to write in the commit message, so that it can be understood later and also for other people. (or simply that you do not end up scolder for weird merge commits) Best regards, Juraj On štvrtok 2. marca 2023 19:32:30 CET Hamed Masafi wrote: > Considering that gitklient is very close to the first version, I have > to say something about its naming. > When I started the project, no name came to my mind. Of course, it is > the same now. That's why, just so that the name of the project is not > empty, change its name to gitklient, in kde 3 naming style (I know). > Considering that the first version of this app has not been published > yet, can we change the name? > If the answer is yes, what name should we choose? To be honest, I > still don't have a suitable name in mind! > > I sent this email so that we can talk about this (of course, if we can > change the name of the program) and find a good name for it. > > I had a long chat with ChatGpt! Also, I got help from some name > suggestion sites and asked some people for their opinion. Finally, I > have a list of suggested names to start a discussion. > > - Kodify > - Kittie > - Kode > - Kommit > - Codekit > - Kodev > - > > Please let me know what you think. > > BR signature.asc Description: This is a digitally signed message part.
Re: Regarding GSoC idea for integration of Firefox Sync in Falkon
> Also, does this mean that only the ideas listed in the 2023 GSoC idea list > are available to contributors for this year's GSoC? I would say that is the case. But all can change when you ask involved people, it requires some luck. Best regards, Juraj On Sun, Feb 19, 2023 at 8:17 PM Shivodit wrote: > > I see, that's unfortunate. Maybe I'll take a look at it as a project outside > of GSoC. > > Also, does this mean that only the ideas listed in the 2023 GSoC idea list > are available to contributors for this year's GSoC? > > Thanks, > Shivodit > > On Mon, Feb 20, 2023 at 12:34 AM Juraj Oravec wrote: >> >> Hello, >> >> No, there is noone to support the idea on the Falkon side. >> The idea was not finished though. >> >> Best regards. >> Juraj >> >> On Sun, Feb 19, 2023 at 7:38 PM Shivodit wrote: >> > >> > Hello, >> > >> > I am a Computer Science student who is looking to contribute to KDE in >> > this year's GSoC. I saw the idea to integrate Firefox Sync into Falkon on >> > KDE's GSoC idea list for 2020. Is the idea still open to contributors? >> > >> > Thanks, >> > Shivodit
Re: Regarding GSoC idea for integration of Firefox Sync in Falkon
Hello, No, there is noone to support the idea on the Falkon side. The idea was not finished though. Best regards. Juraj On Sun, Feb 19, 2023 at 7:38 PM Shivodit wrote: > > Hello, > > I am a Computer Science student who is looking to contribute to KDE in this > year's GSoC. I saw the idea to integrate Firefox Sync into Falkon on KDE's > GSoC idea list for 2020. Is the idea still open to contributors? > > Thanks, > Shivodit
Re: Easy mouse settings changing from right- to left-handed
On sobota 18. februára 2023 13:09:22 CET Tobias Leupold wrote: > Hi all! > > My little son starts to use a computer for school, so I currently > share my notebook with him. He's left-handed (and I'm right-handed), > so I searched for a convenient way to switch the mouse settings from > right-handed to left-handed and vice versa, like with a small systray > icon and just one click to do. > > The only thing I found was "mouseswap-kf5" ( > https://www.pling.com/p/998954/ ) which seems to do this exact thing. > But it seems to be outdated and unmaintained -- I could not build it. > > I then looked into the sources and thought it could not be that hard > to re- write or update the thing, but after messing a bit with it, I > have to admit that I have no idea how to do it properly ;-) I could > not even connect to some DBUS signal telling me that any > systemsettings setting has been changed (I never worked with this > before) ... > > So: Is there anything comparable we have in "official" KDE? And if > not, can anybody point me to docs about how to do it, so that I can > try to implement this myself? > > This would imo be a nice addition to the default mouse system > settings, like "show a systray icon to switch between left- and > right-handed" or such. I think this would be a nice extra for a lot > of people sharing their computer with others. > > Thanks for all help and all hints :-) > > Cheers, Tobias Hello Tobias, Have you considered using libinput and undex Xorg xinput tool and some scripts around (create script and bind to keyboard shortcut, create some icon...)? Example from my machine (mouse can have multiple entries here): $ xinput list ⎡ Virtual core pointer id=2[master pointer (3)] ⎜ ↳ Razer Razer Basilisk V3 id=17 [slave pointer (2)] $ xinput --list-props 17 Device 'Razer Razer Basilisk V3': . libinput Left Handed Enabled (294): 0 libinput Left Handed Enabled Default (295): 0 ... Probably: $ xinput --set-prop 17 "libinput Left Handed Enabled" 1 Good luck, Juraj signature.asc Description: This is a digitally signed message part.
Re: "Gardening" old bugreports
Hello, > Just to clarify, should we just exclude Falkon from bug report > gardening or also from merge request gardening too? > > Merge request gardening is pinging MRs with no activity for 30 days, > then closing if there is no response even two months after the ping > message. Good idea, I would also exclude Falkon from MR-Bot. Thank you, Juraj. > On Sun, Jan 29, 2023 at 1:18 PM Justin wrote: > > Hi Juraj, > > > > Of course we are happy to exclude Falkon from the list. > > > > Regards, > > > > Justin > > > > On 28/1/23 23:45, Juraj Oravec wrote: > > > Hello, > > > > > >> Exclusions so far: > > >> - okteta > > >> - krita > > >> - any bug reported by sit...@kde.org > > >> > > >> Thanks again for the feedback! > > > > > > Can you also add Falkon to the exclusion list? > > > There are not that many bugs nor people working on it and at the > > > moment it is easy to browse the bugs. > > > > > > Also I do not know if this was discussed, but some info message on > > > the bugzilla would be nice, if this project is managed by this > > > BugBot or not. > > > > > > Thank you for the help. > > > > > > Best regards, > > > Juraj. > > > > > > On piatok 27. januára 2023 22:56:09 CET Justin Zobel wrote: > > >> Thanks for the feedback, everyone. > > >> > > >> Given the distribution of positive vs negative feedback, we plan > > >> to > > >> resume automatic bug triage of old non-wishlist bugs that have > > >> not > > >> been updated in over 2 years. If you would like to opt your > > >> product > > >> out of this initiative because you're able to keep on top of the > > >> manual bug triage work, please let us know and we'll be happy to > > >> accommodate you. > > >> > > >> Exclusions so far: > > >> - okteta > > >> - krita > > >> - any bug reported by sit...@kde.org > > >> > > >> Thanks again for the feedback! > > >> > > >> On Sun, Jan 22, 2023 at 6:10 PM Thomas Baumgart > > >> > > > > > > wrote: > > >>> On Donnerstag, 19. Januar 2023 22:39:45 CET Johannes Zarl-Zierl > > > > > > wrote: > > >>>> Hi, > > >>>> > > >>>> Am Donnerstag, 19. Jänner 2023, 12:26:08 CET schrieb Nicolas > > > > > > Fella: > > >>>>> Am 19.01.23 um 04:04 schrieb Justin: > > >>>>>> The gardening team aims to find out if the bug reports are > > >>>>>> still > > >>>>>> relevant by involving the users who reported them in > > >>>>>> determining if > > >>>>>> they are still valid. This increases community involvement > > >>>>>> and > > >>>>>> helps > > >>>>>> KDE as there isn't anywhere near enough manpower to review > > >>>>>> the > > >>>>>> thousands upon thousands of bugs that haven't been touched in > > >>>>>> years. > > >>>>> > > >>>>> Anecdotally many people don't like such automated changes > > >>>>> being > > >>>>> done to their bugreports that don't actually engage with the > > >>>>> content of the report.> > > > >>>> > > >>>> Well, anecdotally you will mostly get feedback from people who > > >>>> don't like it. Unless something is exceptionally great, few > > >>>> people will take the time to speak out in favor of something > > >>>> that > > >>>> is already happening. > > >>>> > > >>>>>> The bugs that we are interacting with are ones that have not > > >>>>>> had any > > >>>>>> activity for over 2 years. We are simply trying to > > >>>>>> reinvigorate > > >>>>>> discussion on those bugs to see if they are still valid. If > > >>>>>> the user > > >>>>>> does not reply within the standard 30 day period after a bug > > >>>>>> is set to NEEDSINFO, it is automatically closed by the Bug > > >>>>>> Janitor. > > >>>>>
Re: "Gardening" old bugreports
Hello, > Exclusions so far: > - okteta > - krita > - any bug reported by sit...@kde.org > > Thanks again for the feedback! Can you also add Falkon to the exclusion list? There are not that many bugs nor people working on it and at the moment it is easy to browse the bugs. Also I do not know if this was discussed, but some info message on the bugzilla would be nice, if this project is managed by this BugBot or not. Thank you for the help. Best regards, Juraj. On piatok 27. januára 2023 22:56:09 CET Justin Zobel wrote: > Thanks for the feedback, everyone. > > Given the distribution of positive vs negative feedback, we plan to > resume automatic bug triage of old non-wishlist bugs that have not > been updated in over 2 years. If you would like to opt your product > out of this initiative because you're able to keep on top of the > manual bug triage work, please let us know and we'll be happy to > accommodate you. > > Exclusions so far: > - okteta > - krita > - any bug reported by sit...@kde.org > > Thanks again for the feedback! > > On Sun, Jan 22, 2023 at 6:10 PM Thomas Baumgart wrote: > > On Donnerstag, 19. Januar 2023 22:39:45 CET Johannes Zarl-Zierl wrote: > > > Hi, > > > > > > Am Donnerstag, 19. Jänner 2023, 12:26:08 CET schrieb Nicolas Fella: > > > > Am 19.01.23 um 04:04 schrieb Justin: > > > > > The gardening team aims to find out if the bug reports are > > > > > still > > > > > relevant by involving the users who reported them in > > > > > determining if > > > > > they are still valid. This increases community involvement and > > > > > helps > > > > > KDE as there isn't anywhere near enough manpower to review the > > > > > thousands upon thousands of bugs that haven't been touched in > > > > > years. > > > > > > > > Anecdotally many people don't like such automated changes being > > > > done to their bugreports that don't actually engage with the > > > > content of the report.> > > > > Well, anecdotally you will mostly get feedback from people who > > > don't like it. Unless something is exceptionally great, few > > > people will take the time to speak out in favor of something that > > > is already happening. > > > > > > > > The bugs that we are interacting with are ones that have not > > > > > had any > > > > > activity for over 2 years. We are simply trying to > > > > > reinvigorate > > > > > discussion on those bugs to see if they are still valid. If > > > > > the user > > > > > does not reply within the standard 30 day period after a bug > > > > > is set to NEEDSINFO, it is automatically closed by the Bug > > > > > Janitor. > > > > > > > > > > I am not simply closing bugs, so I do take offense that care > > > > > is not > > > > > applied. > > > > > > > > Properly "triaging" old reports requires at least some level of > > > > understanding of the project, codebase etc. I'm afraid there is > > > > no > > > > simple solution to that and rule-based approaches aren't good > > > > enough. > > > > Even taking things like CONFIRMED status or wishlist priority > > > > into > > > > account assumes that these have actually been consistently > > > > applied. > > > > > > As a maintainer on a small project, I'm quite happy to get an > > > occasional nudge on old reports. Yes, I do occasionally go over > > > old reports to see if they are still valid, but having somebody > > > else doing this methodically makes sure I don't gloss over some > > > bug that could be closed or fixed. > > > > > > Having this done by someone else without too much internal > > > knowledge is an absolute plus in my opinion. After all, if you > > > want to clean up your attic, you try to find a helper who does > > > not have the same emotional attachment as yourself. > > > > > > > > I will halt it until it is approved by more developers. > > > > > However if it > > > > > is decided that it isn't wanted then the KDE as a whole will > > > > > need to > > > > > entice more people in sorting old bugs individually as it is > > > > > clearly > > > > > not a priority right now for the majority. > > > > > > Speaking for KPhotoAlbum, I really appreciate the bugzilla > > > gardening. Thank you for doing it! > > > > I can second that for the KMyMoney project. An occasional poke and > > the automated cleanup when no response arrives where it is needed > > helps a lot. > > > > > > -- > > > > Regards > > > > Thomas Baumgart > > > > - > > With every day I come closer to the grave and learn something new. > > It all happens because I have wandered around too much and stumbled > > into the Linux world - which is a fantastic place to be! (Algis > > Kabaila †) > > - signature.asc Description: This is a digitally signed message part.
Falkon - Generate plugins.qmltypes for its QML API
Hello, What needs to be done (or "How to") generate the plugins.qmltypes for Falkon QML API? The C++ source code of QML implementation is at: https://invent.kde.org/network/falkon/-/tree/master/src/lib/plugins/qml So, how to get the qmltypes out of it apart from doing it manualy? I tried to look at "ecm_generate_qmltypes" ECM module function but it fails as well as when I run the "qmlplugindump" manualy. Maybe the obstacle is that QML is linked inside one big library "libfalkonprivate.so" and it needs to be in separate file? Is there something I am missing or is it realy REQUIRED to write it by hand? Thank you in advance for any help. Best regards, Juraj signature.asc Description: This is a digitally signed message part.
D26793: Exclude the KSharedConfig::openStateConfig from the sip parser
SGOrava abandoned this revision. SGOrava added a comment. Done in https://phabricator.kde.org/D26815 REPOSITORY R237 KConfig REVISION DETAIL https://phabricator.kde.org/D26793 To: SGOrava, #frameworks Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
D26793: Exclude the KSharedConfig::openStateConfig from the sip parser
SGOrava added a reviewer: Frameworks. REPOSITORY R237 KConfig REVISION DETAIL https://phabricator.kde.org/D26793 To: SGOrava, #frameworks Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
D26793: Exclude the KSharedConfig::openStateConfig from the sip parser
SGOrava created this revision. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. SGOrava requested review of this revision. REVISION SUMMARY Fix python binding compilation error. - Add *.pyc files to .gitignore REPOSITORY R237 KConfig BRANCH pyqt5-ksharedconfig-compile-error (branched from master) REVISION DETAIL https://phabricator.kde.org/D26793 AFFECTED FILES .gitignore cmake/rules_PyKF5.py To: SGOrava Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
D26755: [WIP] KMessageWidget: Set widget height on resize event
SGOrava added a comment. it would, but I am not such great guru. I tried few ways to change the behaviour but it was even worse, and since this is used in many programs I do not want to break them. REPOSITORY R236 KWidgetsAddons REVISION DETAIL https://phabricator.kde.org/D26755 To: SGOrava, #frameworks Cc: anthonyfieroni, dhaumann, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
D26755: [WIP] KMessageWidget: Set widget height on resize event
SGOrava added a comment. This is the test I used to check the validity of my change, it kind of always fails. I only hope someone can fix this widget at least for KF6. REPOSITORY R236 KWidgetsAddons REVISION DETAIL https://phabricator.kde.org/D26755 To: SGOrava, #frameworks Cc: anthonyfieroni, dhaumann, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
D26755: [WIP] KMessageWidget: Set widget height on resize event
SGOrava updated this revision to Diff 73872. SGOrava added a comment. - KMessageWidget: Add resize autotest REPOSITORY R236 KWidgetsAddons CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D26755?vs=73845=73872 BRANCH more-proper-height (branched from master) REVISION DETAIL https://phabricator.kde.org/D26755 AFFECTED FILES autotests/kmessagewidgetautotest.cpp autotests/kmessagewidgetautotest.h src/kmessagewidget.cpp To: SGOrava, #frameworks Cc: anthonyfieroni, dhaumann, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
D26755: [WIP] KMessageWidget: Set widget height on resize event
SGOrava added a comment. It looks good. But I wrote a test as you suggested which still fails. The test creates parent widget and puts the kmesagewidget and qlistwidget in it in vertical order (as in my test app) and than it resizes the parent widget and compares the height (the available macros in *autotest.cpp) I will also upload this test. REPOSITORY R236 KWidgetsAddons REVISION DETAIL https://phabricator.kde.org/D26755 To: SGOrava, #frameworks Cc: anthonyfieroni, dhaumann, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
D26755: [WIP] KMessageWidget: Set widget height on resize event
SGOrava retitled this revision from "KMessageWidget: Set widget height on resize event" to "[WIP] KMessageWidget: Set widget height on resize event". REPOSITORY R236 KWidgetsAddons BRANCH more-proper-height (branched from master) REVISION DETAIL https://phabricator.kde.org/D26755 To: SGOrava, #frameworks, dhaumann Cc: dhaumann, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
D26755: KMessageWidget: Set widget height on resize event
SGOrava added a comment. No, my tests say no. This does not update sizeHint which can cause some issue later. It sure looks nice in my test app but it is wrong in the core. This is not the right solution. REPOSITORY R236 KWidgetsAddons BRANCH more-proper-height (branched from master) REVISION DETAIL https://phabricator.kde.org/D26755 To: SGOrava, #frameworks, dhaumann Cc: dhaumann, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
D26755: KMessageWidget: Set widget height on resize event
SGOrava added a comment. OK, I will try to write a test for it. REPOSITORY R236 KWidgetsAddons REVISION DETAIL https://phabricator.kde.org/D26755 To: SGOrava, #frameworks Cc: dhaumann, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
D26755: KMessageWidget: Set widget height on resize event
SGOrava edited the summary of this revision. REPOSITORY R236 KWidgetsAddons REVISION DETAIL https://phabricator.kde.org/D26755 To: SGOrava, #frameworks Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
D26755: KMessageWidget: Set widget height on resize event
SGOrava created this revision. SGOrava added a reviewer: Frameworks. Herald added a project: Frameworks. SGOrava requested review of this revision. REVISION SUMMARY When the resize event was triggered only the content was resized and the widget itself was kept with same height. This results in either huge gap between other widgets or text which is cut of and rendered behind other widgets. TEST PLAN Show a message in KMessageWidget and resize the widget. I made an application to test this error: https://invent.kde.org/jurajo/bug-412829-test-app REPOSITORY R236 KWidgetsAddons BRANCH more-proper-height (branched from master) REVISION DETAIL https://phabricator.kde.org/D26755 AFFECTED FILES src/kmessagewidget.cpp To: SGOrava, #frameworks Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
KNewStuff: Multiple categories with different TargetDir in same knsrc file
Hello, I would like to know if I can have displayed 2 categories and also have different TargetDir for each category as described in old documentation. https://github.com/KDE/knewstuff/blob/master/docs/Design.txt Is it possible to do this ? I know that as a workaround I can split it and use separate downloadWidget/ Dialog for each category. Thank you for answers. Best regards, Juraj Oravec signature.asc Description: This is a digitally signed message part.
