Under the subheading of "Documentation", can we discuss code commenting? And ideally - encourage it? The API docs are good and generally well-maintained, but inside the applications themselves, the quantity and quality of code comments varies quite a bit. Some of our products are quite large and use many of the Frameworks together. It can be daunting at times to decipher how a block of code works and why it was constructed in the way it was.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Apr 11 2018
Apr 10 2018
In T6832#136906, @neofytosk wrote:And more about bugzilla's usefulness here:
https://mail.kde.org/pipermail/kde-community/2018q1/004274.html
Apr 6 2018
Maybe it's worth to add to the describtion of this task:
Vault uses FUSE, no block-level for the time being. I was toying with Tomb and preallocated fixed-size containers in the filsystem which uses Luks in the back, but I'm not sure it can be made to work properly.
In T8447#136980, @dvratil wrote:@gregormi This is only partially related. We already have an option how to automatically decrypt all incoming emails in KMail, although it's not very intuitive to set up. You can create a local filter (Settings -> Configure filters) for all incoming emails and choose the "Decrypt" action. The reason it's not done by default is due to privacy concerns. For example you may want to keep your personal emails always encrypted on your employer's computer so they can't read your private emails.
@ivan: tanx for the input
Vault does not support public-private key encryption - it is out of the project's scope. And it would be quite strange for the user to see items like "KMail Index for ABCDEFGH01234... key" in the list of existing vaults. :)
@gregormi also think about the privacy impact. If you use an unsecured laptop, the mails can be accessed without any password etc. Also when you use IMAP the unencrypted mails would saved back to your mailserver and would be accessible there. It might be usescases for that. But I think the propper way is to make sure, that we can handle the encrypted mails all the way down without removing the encryption.
@gregormi This is only partially related. We already have an option how to automatically decrypt all incoming emails in KMail, although it's not very intuitive to set up. You can create a local filter (Settings -> Configure filters) for all incoming emails and choose the "Decrypt" action. The reason it's not done by default is due to privacy concerns. For example you may want to keep your personal emails always encrypted on your employer's computer so they can't read your private emails.
I have a question to that because I encountered this issue years ago when I used Thunderbird with Enigmail. I assume the indexing we are talking about here takes place in the local mail client, not in a web client, right? I wonder why incoming encrypted mails are also stored encrypted? Why not always decrypt those mails permanently? This would prevent losing old mail because of lost private key and there would be no problem with indexing. In this Enigmail bug report (https://sourceforge.net/p/enigmail/bugs/1/) from 2003 this request was made. The main reason for not implementing it is a technical one ("this feature is blocked by necessary Thunderbird changes") not fundamental ones. I thought the goal of end-to-end encryption is protect the data when it is underway and not also on the end-points themselves. Are there any reasons why KDE PIM does not decrypt incoming encrypted mail permanently? (or is there already and option to do that? Then sorry for the fuzz)
Related to T7014
Apr 5 2018
In regard to UNCOFIRMED/CONFIRMED status, there's a relevant discussion here:
https://mail.kde.org/pipermail/kde-community/2018q1/004395.html
And more about bugzilla's usefulness here:
https://mail.kde.org/pipermail/kde-community/2018q1/004274.html
Apr 3 2018
Apr 2 2018
It should be added to the kdepim workboard
Mar 27 2018
Mar 26 2018
In T7116#134920, @richardbowen wrote:What do you think about a dedicated stack for web development? As there is C++, Qt/QML for the desktop, like wise a dedicated/preferred programming language(s) and framework can be chosen for the web. This would help in onboarding contributors to the web side of things and potentially make management of the web stack easier for both the developers and the system admins.
What do you think about a dedicated stack for web development? As there is C++, Qt/QML for the desktop, like wise a dedicated/preferred programming language(s) and framework can be chosen for the web. This would help in onboarding contributors to the web side of things and potentially make management of the web stack easier for both the developers and the system admins.
Mar 25 2018
@ngraham ok i did open new bug report : https://bugs.kde.org/show_bug.cgi?id=392339
i hope you will add list this in "Top-notch usability and productivity for basic software" thank you
@manuelmuzzurru, the best place for that kind of request is in the form of a Bugzilla ticket for frameworks-kio.
hi, did you see my comment for filesystem in dolphin (panel information)?
Mar 21 2018
Mar 15 2018
As a newcomer and junior-jobs guy, I'm happy to see this initiative being pushed forward by the Top People(tm) of the KDE organization. I've been stumbling my way through a few patches with the help of @rkflx and @ngraham, the latter of which agreed to mentor me in the ways of KDE. Henrik has been patient with me as I learn C++ and has given me a few assignments for Spectacle bugfixing. Nate has been a good guide to the environment and community. I'm sure there are many more like these two out there. Busy people, but willing to share their knowledge and expertise.
Mar 13 2018
Mar 9 2018
Feb 19 2018
On thing we could use is an official policy regarding whether the stable or master branch is more appropriate for any given patch. Right now it's often not clear for edge cases such as D10651: Fix thumbnail hover icon show-in-fullscreen action. In that patch, a bug was fixed that led to a behavior change. Stable or master? We committed to master to be safe, but it wasn't as clear as we would have preferred.
Feb 18 2018
hi, i wish to ask you:
Feb 15 2018
Recently, I tried to find out KDE best practices to work with Docbook.
Feb 14 2018
I really like UHD's explanatory text above the login box. We should implement that, with some short documentation and a link pointing to identity.kde.org. Who has the power to do this? KDE Sysadmins?
Feb 13 2018
In T7646#127445, @ngraham wrote:Out of curiosity, what are our criteria for considering this task done?
Well, I reply to myself as I got the following notification just after making the post above :
https://phabricator.kde.org/D10461
gmenu-dbusmenu-proxy
"This application finds windows using GTK GMenu DBus interfaces [1] and forwards them through DBusMenu. This way no adjustments in Plasma are needed."
Hi ! I wonder whether this one would fit in the KDE usability list : global menus don't work with GTK apps, cf :
https://github.com/kotelnik/plasma-applet-active-window-control/issues/78
Feb 10 2018
I have updated https://community.kde.org/Get_Involved#Getting_in_touch_and_working_together and https://community.kde.org/Infrastructure/Phabricator#Logging_in, and included a picture highlighting the login button.
Feb 6 2018
Feb 1 2018
Hi everyone, I feel bad for being quiet over the last couple of weeks. Lots of changes happening in Jan-Feb for me, and also FOSDEM and the KDE Promo sprint are coming up. I'll try to push this goal forward in a consistent way once all these have passed.
Jan 31 2018
Jan 30 2018
@mmustac this is done now!
Jan 28 2018
@ngraham Great to hear that. I will be one of the first to test your explanations if they are also ready for noobs like me :-D And provide my feedback of course.
Yes, it will be a redirect to https://community.kde.org/Get_Involved
Is it going to be a redirect to the existing pages? The example of page shown is a bit too much developer-oriented compared to https://community.kde.org/Get_Involved
@mmustac Yup, I've proposed that and already gotten buy-in and permission to do it. Just working on getting my access to change the page.
What about editing the "Get involved" page on kde.org as first step?
I am missing an up2date step by step guide to get a working development environment.
Because I really would like to get started.
Jan 27 2018
FWIW, I updated https://community.kde.org/Get_Involved#Getting_in_touch_and_working_together with a more clear and concise description of how to sign up and log into Phabricator.
Jan 23 2018
In T6831#124835, @IlyaBizyaev wrote:The recently introduced KWallet support in VLC is cool; can it also be implemented for Firefox? When a master password is set, Firefox asks for it on every launch, which for me is usually just after unlocking my Wi-Fi passwords with KWallet. If Firefox could make use of KWallet (like Chrome and Opera do), it'd be one password prompt less on every device boot :)
The recently introduced KWallet support in VLC is cool; can it also be implemented for Firefox? When a master password is set, Firefox asks for it on every launch, which for me is usually just after unlocking my Wi-Fi passwords with KWallet. If Firefox could make use of KWallet (like Chrome and Opera do), it'd be one password prompt less on every device boot :)
Jan 22 2018
Jan 20 2018
It would be awesome if we could have a page like https://whatcanidoformozilla.org/#!/progornoprog/advocate
Jan 17 2018
Jan 13 2018
In T7116#123722, @dhaumann wrote:I think we could obtain the relevant list of contributors from the sysadmins: all accounts that were created since last Akademy.
I would like to add another todo item to the list: All new contributors (e.g. the ones who committed a patch for the first time within the last year) should get a personal email, asking them to please attend the KDE conference. I think Akademy is an integral part of holding people together. As such, we need to push those a bit who are unsure (I was in this situation myself in 2004).
Jan 11 2018
For now I added some information at https://community.kde.org/Get_Involved#Ways_to_contribute
SO, being very much green I wanted to ask you or anyone where/who I would go to for website edits. After some searching, I quickly found the webpage is wiki style. Because of how crazy it has been, I had to ask in the irc how to get to the registration link again so I can submit sample language and placement on community.kde.org. Wouldn't you know, valorie and I started talking about the issue, and bingo, she agreed to put changes to page as suggested. I also pitched for the auto-forward link like mozilla. Pretty cool! This is my first contribution...and it was surprising to see how easy and simple it was. Thanks again for the support and encouragement.
Jan 7 2018
Find below the merged version of previous comments, as requested.
Jan 6 2018
Jan 5 2018
Only the next goal matters.
@michaelh With your goals in mind, you could go to kde.org, and see how you manage to get directions from there for what you want to do, and write down what you think is missing, needs improvement, or is awesome as it is, and then provide such feedback here.
I'm to excited I found this that I'm commenting before having completly read this thread. This topic is very close to an idea I woke up with this morning.
Jan 3 2018
I would say no extensive documentation is needed when the interface is obvious on itself.
Thanks for the video, you are making good progress towards changing things for the better. There are two root problems I can extract from it:
+1 for Junior Jobs!
Thank you, that's quite useful :)
Well, here is a video. I think it might surprise some how much digging you would have to do in order to come to the realization that phabricator is the place where a lot of things get done if one is interested in contributing. Digging into a resource manual after several clicks fall below the bar of what can and should be done, in my opinion.
Jan 2 2018
Cannot be answered in a simple way. Basically what we need is to put Fabricator right in the place where people would be looking for it, and the process to be as simple and straightforward as possible.
@es20490446e agreed. I am super new to this, who would you recommend this get assigned to? And what is the best path for someone who is new to go from posting ---> to implementation for something like this? What is an ideal background someone should have?
Dec 31 2017
Please add this bug to the list: https://bugs.kde.org/show_bug.cgi?id=270808
Dec 27 2017
Don't overthink it, just do it! ;)
Thanks for the attention and comments to this.
Dec 26 2017
In T7646#121756, @vijaykrishnavanshi wrote:I will create a page for elaborating the process of registering on Phabricator and creating reviews shortly and link it here. Footer idea is also cool :)
I agree there is still room for improvements to make it easier to register. People I have in mind here are those who want to start contributing changes to the code, get involved in the VDG, do promotional things etc., i.e. everything not related to bug reporting or triaging for which Bugzilla is the place to go at the moment.
I will create a page for elaborating the process of registering on Phabricator and creating reviews shortly and link it here. Footer idea is also cool :)