Re: Post-MegaRelease projects
On Friday, 23 February 2024 03:27:00 CET Jin Liu wrote: > Another thing I'd like to explore is to have some universal way to > programmatically change KDE settings. > > Currently, I either change settings in KCMs, or manually edit a config > file then make a dbus "reconfigure" call. But the latter is mostly > undocumented Maybe there is a way to make kwriteconfig also trigger that after it has written the change? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
Re: Welcome* Ingo!
On Tuesday, 6 September 2022 00:11:43 CEST Aleix Pol wrote: > Hi everyone, > Last year during Akademy, we discussed different positions under the > umbrella of Make a Living in KDE. Today I'm reaching out to announce > that Ingo Klöcker (CC) will be taking on the role of App Stores > Support Engineer. Very cool! Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: [kde-community] user stats for Neon
On Thursday, 2016-04-14, 14:36:21, Jonathan Riddell wrote: > On Thu, Apr 14, 2016 at 04:18:30PM +0200, Thomas Pfeiffer wrote: > > Any potentially privacy-sensitive information transfer should be opt-in, > > not opt-out. > > I'd assume that the vast majority of users will allow it (given that it's > > not personally identifiable and they trust their distro), but opt-in puts > > you on the safe side. > > What's privacy sensitive about it? It's a machine ID but not linked > to any other information other than IP address and there's no personal > information we can link it to. I am with Thomas. While individually pieces of information aren't personal, they can be in combination. In this case the combination of a unique machine ID and IP address together with geolocation would allows us to track movement of machines. Movement profiles can often quite easily be used to identify the moving person. There was a huge scandal in the US a couple of years back in which a telecom company released fully anonymized (random unique IDs) mobile phone location tracks. Researchers who correlated positions with addresses were able to identify more than 80% of the telco customers with pretty good accuracy only shortly after. Cheers, Kevni -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] can you give a talk at Linuxwochen Wien?
On Tuesday, 2016-01-12, 14:58:07, Stefan Derkits wrote: > Hi, > > On 2016-01-12 14:46, Sebastian Kügler wrote: > > Hi all, > > > > An invitation to participate in the Linuxwochen Wien has landed in my > > inbox. As I won't be able to make it, perhaps someone else (living > > closer?) will be. > > > > If you're in Wien, or in Austria, KDE and the organisers would surely > > appreciate if you could give a talk there. For that, please get in contact > > wiht Mr Willich directly, or follow the procedure at > > http://www.linuxwochen.at/call-for-participation-der-linuxwochen-wien-2016 > > thanks Sebas for forwarding the Mail. Would be a really good idea to be > represented with some talks @ LinuxWochen Wien, I forwarded the mail to > the kde-at mailinglist, let's hope there are some interested people to > submit proposals and maybe also someone to help me with organize a booth > there (would be a pitty if KDE isn't represented if they already contact > us). I want to add that Grazer Linuxtage, which didn't have to "steal" [1] the name of the Austria-wide umbrella event :) , is also asking for talk and workshop proposals: https://www.linuxtage.at/call-for-lectures/ Same weekend actually, since the guys from LinuxWochen Wien can't be bothered to read any other event's earlier annoucements. Cheers, Kevin [1] Linuxwochen is the name used to refer to all Linux/FOSS events happening in Austria in a given year, originally the events in Vienna, Graz, Salzburg, one in Upper Austria and Linuxday in Dornbirn. -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] can you give a talk at Linuxwochen Wien?
On Tuesday, 2016-01-12, 15:31:02, Stefan Derkits wrote: > Hi, > > On 2016-01-12 15:27, Kevin Krammer wrote: > > Same weekend actually, since the guys from LinuxWochen Wien can't be > > bothered to read any other event's earlier annoucements. > > that really sucks that they are on the same weekend. > Although Linuxwochen (actually Linuxtage is anyways the better name) > starts one day earlier, so you could submit a talk for Friday at > Linuxwochen Wien :) True, however I am one of the organizers of the Graz event, so I will be very busy the whole week :-/ Usually we wait until Vienna has selected a date and then try to accomodate this choice with our date, but it took them way to long this year so we selected a date hoping that they would check for collision as well. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] What is a GitHub pull request exactly?
On Saturday, 2015-09-19, 23:06:47, Eike Hein wrote: > On 09/19/2015 10:32 PM, Kevin Krammer wrote: > > I don't see there this github review is coming from. > > Review is an interactive process where you ask for changes and > iterate. Once you open the door to doing it on GitHub, you will: > > * Have a hard time making some contributors understand why > they should go through the trouble of moving to Phabricator > in the midst of the review process, or next time. > > * Have a hard time making some KDE developers understand why > they shouldn't just do it on GitHub. First, I have no idea where this "use github for review" comes from at all. Who wants to do that in the first place? > I don't understand why you expect thinks like "if it matters > people will take it to RB/Phab as second stage" or "after the > first patch we ask someone to get an account and switch to > Phab" will happen as a matter of course. Because that is how it has always worked until now. I don't believe that people will start ignoring the need for KDE review despite a project's policies, or shoulder patch integration work for new contributors indefinitely. Do you find it likely that a KDE developer who asks an email-patch contributor to submit further changes via Phab would not ask a github-patch contributor? Do you find it likely that a KDE developer who follows the projects guidelines on putting patches through Phab would suddenly decide to push directly? KDE developers who have shown for years that their profressionalism and sense of community has made it unnecessary to enforce things like review policies by technical means. Who have shown that they prefer new contributors to become fully integrated team members? Because I do not. I find it way more likely that KDE developers who accept patches from new contributors will ask these contributors to get their own developer account after a while. I also find it way more likely that they will continue to abide by the rules of the projects they are contributing to. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] What is a GitHub pull request exactly?
On Saturday, 2015-09-19, 20:56:31, Eike Hein wrote: > On 09/19/2015 08:43 PM, Kevin Krammer wrote: > > Well, the github side review will make the job of the KDE contributor who > > brings the patch into KDE a lot easier, because when they put the patch up > > for review as "their" contribution, most of the things that the > > contributor knew about will already have been fixed. > > No, it won't make it easier. It will busy up KDE contributors > with process snags instead of actual work - now they don't > just have to review, they also have to file requests for work > not their own. It makes stepping up to becoming a regular > contributor less desirable, because it means taking on duties > like this. I didn't mean easier than when the author of a patch initiated the actual review themselves. Of course doing only the actual review that counts is a lot easier than doing a preliminary one and then doing the actual one, but sometimes doing a preliminary one is a nice gesture [1]. Since the goal of any established contributor will be to get the new contributor to work on their own as soon as possible, they will not likely do that proxying for long. > The purpose of code review tools is to facilitate review by > making the process sufficiently tenable. Chaining two of them > and creating additional work items does not aid in that > purpose. Exactly. So why would one continue to do the prelimiary review in addition to the required one? As soon as there is a stream of patches from a new contributor, that contributor will be asked to get an account of their own. Need for preliminary review or patch proxying removed, ideal situation established. > It'll also create social tensions of various kinds: > > * Developers not participating in GitHub review and only > seeing a patch once it makes it to Phab will feel > pressured to accept something because part of the > discussion has already happened elsewhere, vastly in- > creasing the conviction required to don the cap and > baton of the Bad Cop at that point. Developers cooperating on a patch or patchset before review submission is nothing new. > * Developers will have opinions on whether it's OK for > other developers to tell requestees to use Phab next > time. I am afraid I didn't get that one. > Really, the only way we can enable GitHub for code > review is if we can work up a community consensus > that it will a full alternative to Phan because it's > worth it to us. I don't think this would be a good idea. The only review that counts in the end is the one all KDE developers have access to. Which is Phab. Using any other tool before review submission is a developer's personal choice. If it helps them to gather confidence for the review, why not. See also [1]. Cheers, Kevin [1] I've done plenty of these with new contributors, e.g. GSoC students, so they can fix "embarrasing" things with only me seeing them and providing an already improved version for general review. -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Bikeshedding - our strength apparently *sigh*
On Saturday, 2015-09-19, 20:32:43, Eike Hein wrote: > On 09/19/2015 08:25 PM, Kevin Krammer wrote: > > Saying "I don't look at the KDE review tool" would be like saying "I am > > not > > interested in your patch". > > Saying "My personal productivity and efficiency matters more > to me in the long-run than your patch, so please use the tool > I prefer to reach me" happens all the time, and is a respect- > able stance. > > In fact, it's come up in this thread because that's what "I > don't want to use two review sites even if having two means > more patches than I would get otherwise" means. > > It also comes up when someone says "please put this in BKO > instead of telling me on IRC because not having all my data > in one central location is a problem for me". > > Simplicity and centralization matter. If there are two code > review sites, some people will be willing to work with both > of them, others will prefer one over the other. Some of the > latter may pick GitHub. Right. If a maintainer wants all patches via email, that is how they work. Even using a review tool in the first place is something that the maintainer asks people to do. If you don't want to you don't override the maintainer's decision and push directly, do you? So the hypothetical situation is that there is a KDE project who's maintainer does not want the contribution of any other KDE developer. Their loss, no? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Bikeshedding - our strength apparently *sigh*
On Saturday, 2015-09-19, 21:08:27, Eike Hein wrote: > On 09/19/2015 08:58 PM, Kevin Krammer wrote: > > Even using a review tool in the first place is something that the > > maintainer asks people to do. > > No. We advertise ReviewBoard (and later Phab) as a general > interface to throw code at our maintainers. "I don't look > at ReviewBoard" is not a socially tenable position in our > community in practice, just like "I don't look at GitHub" > won't be*. The pressure will be to cover all places. Some > people will say they don't want to or can't and abandon > one for the other, and we'll have conflict over it and it > will affect who develops for KDE and who maintains our > products. So, right now, a maintainer is expected to check reviewboard even if they are content with all holders of commit accounts to push directly. But that as soon as there is a second option, then not checking reviewboard becomes acceptable? That would then be a bonus for all maintainers who don't want to use pre-push reviews. They no longer have any pressure to check any review tool. So bascially a win-win-win situation. Maintainers who do not care about review are free to not use any, maintainers who want contributions from other KDE developers use Phab and maintainers who do not want contributions from KDE developers use whatever they feel like using. If we assume that the third group even exists. Otherwise it is a plain win-win situation, still an improvement over the the lose-win situation we apparently have (maintainers being socially pressured into using reviewboard). Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] What is a GitHub pull request exactly?
On Saturday, 2015-09-19, 22:11:10, Eike Hein wrote: > On 09/19/2015 09:55 PM, Kevin Krammer wrote: > > Exactly. > > So why would one continue to do the prelimiary review in addition to the > > required one? > > As soon as there is a stream of patches from a new contributor, that > > contributor will be asked to get an account of their own. > > Need for preliminary review or patch proxying removed, ideal situation > > established. > > Except the pro-GitHub side specifically argues for > GitHub as increasing the frequency of first patch > submissions, so the total amount of work spent on > dealing with them increases. Yes, but those who argue for that are aware of the extra work that will cost. Like Jaroslaw explained, he is fully aware of the extra work that this means, but he already has this extra work no matter which indirect submission forms he supports. So in his experience it is worth it for him. > This is on some level > a "nice problem to have", but creates a pressure to > drop two-stage review and use GitHub as a primary > channel to optimize that channel. I don't see there this github review is coming from. A preliminary review on github is something the KDE contributor, who will then take the patch to KDE review, can do if they think it will make their review easier. Or to provide the patch author with confidence to do it themselves next time. I would assume that in most case the patch from the first time contributor is just taken to KDE review and the author asked to submit directly next time. Everything else is not "optimizing the channel", only direct submission to KDE review is optimal. > I.e. once again > leading me to the conclusion that two-stage review > is simply not viable and runs counter to what the > proposal wants to achieve. Indeed. Somehow people bring up additional github review all the time. I doubt anyone would do that in practise. > > Developers cooperating on a patch or patchset before review submission is > > nothing new. > > This sort of "we have a precedent for this" argument > comes up a lot, but is often a really poor argument > because it doesn't establish that precedent was > actually a positive experience or a desirable > situation. I always found direct collaboration, e.g. at sprints, extremely desirable. As a GSoC mentor I am also pretty confident that my students found our private reviews desirable, based on them asking for them. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] What is a GitHub pull request exactly?
On Saturday, 2015-09-19, 20:20:56, Eike Hein wrote: > On 09/19/2015 08:13 PM, Kevin Krammer wrote: > > I am afraid my understanding of the technical background of this is still > > too hazy. > > How would review "move" from KDE to github? > > If review on reviewboard is required (per project's unwritten social > > contract), it cannot not happen. > > If it is not required, better have a patch reviewed elsewhere than not at > > all. > His argument is that because KDE developer accounts can > write to repositories directly (which we have discussed > many times we don't want to change), lazyness will win > and patches will go into repositories directly after > GitHub review. That is a matter of project policy. It it only uses review as a "can do" thing, then yes, any contributor can push any patch at any time. Just like they do today. If it is "should do", then yes, a contributor could consider pushing directly. Just like they do today. It it is "must do", then no, the maintainer will revert their patch and remind them of the policy. So in the first two cases a patch that would otherwise not have seen any review got some review. In the third case it will get two. > Personally I agree that is the likely scenario. Two-stage > review is simply too much work and hassle, and I doubt > it's desirable to anyone who actually wants to use > GitHub. Well, the github side review will make the job of the KDE contributor who brings the patch into KDE a lot easier, because when they put the patch up for review as "their" contribution, most of the things that the contributor knew about will already have been fixed. If the review and integration work turns out to be too annoying, I would expect these KDE developers to ask their source to do it themselves next time around. Having to do the integration work has so far been a great motivator to eventually ask a regular new contributor to get an account on their own. With more and more reviewing becoming "mandatory" I don't see that motivation going down. Quite the opposite. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Bikeshedding - our strength apparently *sigh*
On Saturday, 2015-09-19, 19:58:26, Eike Hein wrote: > On 09/19/2015 07:52 PM, Kevin Krammer wrote: > > You mean that a KDE project would ignore your review request it it comes > > from reviewboard/phabricator? > > I think that's a realistic, even likely concern. We already > know that some devs don't like using multiple code review > sites concurrently from the gerrit and Phab trial runs, and > it's conceivable that some developers might prefer GitHub to > Phabricator. "Please file this on GitHub because I don't look > at Phab" would be a matter of time. I don't find that likely. The trial runs were a different thing, equally valid alternatives. Saying "I don't look at the KDE review tool" would be like saying "I am not interested in your patch". A maintainer can always not accept a patch. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Official KDE mirror on github
On Saturday, 2015-09-19, 16:26:04, Luigi Toscano wrote: > Kevin Krammer ha scritto: > > On Saturday, 2015-09-19, 12:29:31, Vishesh Handa wrote: > >> On Sat, Sep 19, 2015 at 12:09 PM, Ivan Čukić <ivan.cu...@kde.org> wrote: > >>> alternatives. Just as they do not have access to my personal inbox > >>> > >>>> where much corresponse often happens, and patches are discussed. > >>> > >>> Not sure that this is a statement you want to advertise, since it > >>> implies that the development happens behind the closed doors. (yes, we > >>> all do that sometimes, but is should not be a part of our workflow, > >>> and not something we should be proud of) > >>> > >>> Now, with GitHub, it would not be exactly 'development behind the > >>> closed doors' but for a lot of us it would be basically the same. As > >>> Martin mentioned, this would be hidden from his eyes since he has no > >>> intention to follow development on GitHub. > >> > >> Some development does happen behind closed doors. Someone sends me a > >> patch, I commit it, and then point them towards reviewboard for the > >> next time. Ditto with bugs actually. I get reports via IRC, emails, > >> Google+ and even FB (once). If it is minor I act on it, if it isn't I > >> point the user towards bugzilla or just file a bug myself so that I > >> don't forget. > > > > Right, this is also my understanding of what is proposed. > > > > If you work on a project where you can push without review, it really > > doesn't matter how you arrived at the commit, you would have pushed your > > own version without review as well. > > > > If you work on a project where you have to go through review, then again, > > it really doesn't matter how the commit has been created, it is still > > being reviewed. > > The only difference is that the submitter of the review request is not the > > author of the commit. > > But that's not using the pull request. Such workflow would mean that the > pull request is not accepted anyway, but the code is pushed through the > infrastructure and not trough Github interface. I though that a pull request was a way for one clone's owner to notify the main repo owner that the clone had a change they would like to propose for upstream. The repo owner could then pull the clone at the given revision and then follow whatever workflow they would like to follow. In a KDE project with mandatory review that would be uploading the change to reviewboard/gerrit/phabricator. In a KDE project without mandatory review that could be uploading to KDE's review or pushing to the KDE git server. > Just to be sure, question for Vishes, Albert Vaca, Jaroslaw: can you please > explain exactly what is the meaning of "use Github"? Do we all agree that in > any way pull requests will never be merged directly through Github > interface? What sense would that even make? Then the mirror would have a different state than the repo it is mirroring. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Bikeshedding - our strength apparently *sigh*
On Saturday, 2015-09-19, 17:19:16, Riccardo Iaconelli wrote: > On Saturday, September 19, 2015 10:58:09 AM Michael Pyne wrote: > > Is anyone actually arguing this point in the way you ask? No one's asking > > to prevent "one offs" entirely, the core of the issue is that KDE > > development should happen *within* KDE-the-whole-community, not *apart > > from* KDE. > > Nobody is proposing to move there the development! And pull requests are > really "one offs", no stable contributor would sensibly use them as a > regular basis, just like no stable contributor doesn't get an account and > develops only through mailing patches... > > This whole thread started with one sentence which started like "if somebody > sends me a patch, it doesn't matter if she/he sends it to me via mail, > github, or by post... if it's good work, I am going to integrate it". I > think we should keep to that and not escalate it to "some KDE projects move > to github for development". > > I think there was some confusion on that point, so let me state this again: > the agreement is that github mirrors ARE going to be kept read-only, so > someone with a KDE account and the developer karma still has to push the > patch to git.kde.org (or reviewboard or so on...), if he wants to see it > integrated. I don't see how that destroys our values. I just see it as a > way through which potential newcomers can submit their first contribution, > instead of mailing a patch. > > At least, in my view, the mirrors will STILL be *READ-ONLY*. Exactly! How would a mirror even be read/write? We are not going to upload a private key to github to allow some script there to push and we are not going to automatically and blindly pull and merge from github either, no? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
[kde-community] What is a GitHub pull request exactly?
I have some difficulty understanding the perceived difference in workflow, so I'd like to get some input on where my line of thinking and reality differ :-) The following example deals with clones of a repository and the revision of HEAD in the master branch. Example: akonadiclient, three developers (Bhaskar, Jonathan, Kevin). Repo: revision of HEAD@master 1) Initial situation git.kde.org: acbd Bhaskar: abcd Jonathan: abcd Kevin: abcd 2) Kevin creates a patch git.kde.org: acbd Bhaskar: abcd Jonathan: abcd Kevin: ghij 3) Patch goes to reviewboard git.kde.org: acbd Bhaskar: abcd Jonathan: abcd Kevin: ghij 4) Patch is reviewed and gets "Ship it". Kevin pushes to git.kde.org git.kde.org: ghij Bhaskar: abcd Jonathan: abcd Kevin: ghij 5) The other developers update git.kde.org: ghij Bhaskar: ghij Jonathan: ghij Kevin: ghij 6) KDE gets a github mirror git.kde.org: ghij github: ghij Bhaskar: ghij Jonathan: ghij Kevin: ghij 7) A new developer, Fred, clones on github git.kde.org: ghij github: ghij Fred's clone: ghij Bhaskar: ghij Jonathan: ghij Kevin: ghij 8) Fred creates a patch git.kde.org: ghij github: ghij Fred's clone: ghij Bhaskar: ghij Jonathan: ghij Kevin: ghij Fred: klmn 9) Fred pushes to his clone git.kde.org: ghij github: ghij Fred's clone: klmn Bhaskar: ghij Jonathan: ghij Kevin: ghij Fred: klmn 10) Fred makes a pull request git.kde.org: ghij github: ghij Fred's clone: klmn Bhaskar: ghij Jonathan: ghij Kevin: ghij Fred: klmn Ok, now my understanding is there are two options: (a) someone pulls from Fred's clone (b) there is a merge option on GitHub 11a) Kevin pulls from Fred's clone git.kde.org: ghij github: ghij Fred's clone: klmn Bhaskar: ghij Jonathan: ghij Kevin: klmn Fred: klmn 12a) Kevin puts Fred's patch up on review, pushes it to git.kde.org once it gets "Ship it" git.kde.org: klmn github: klmn Fred's clone: klmn Bhaskar: ghij Jonathan: ghij Kevin: klmn Fred: klmn 11b) Kevin used the merge option on github git.kde.org: ghij github: klmn Fred's clone: klmn Bhaskar: ghij Jonathan: ghij Kevin: ghij Fred: klmn 12b) Kevin pulls from github git.kde.org: ghij github: klmn Fred's clone: klmn Bhaskar: ghij Jonathan: ghij Kevin: klmn Fred: klmn 13b) Kevin puts the patch of for review, pushes to git.kde.org when it gets "Ship it" git.kde.org: klmn github: klmn Fred's clone: klmn Bhaskar: ghij Jonathan: ghij Kevin: klmn Fred: klmn So (a) and (b) workflows differ in that in (a) github mirror and git.kde.org have the same state, while in (b) the mirror is for a period of time not actually a mirror, but "ahead". Where "ahead" could also mean wrong if "klmn" needs to be modified or gets rejected. Is (b) the problem people keep discussing about? Because as far as I can tell it is not really an option given that it can lead to an inconsistent state of two clone sources that are considered to be mirrored. If the problem is somewhere in (a), where is it? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] What is a GitHub pull request exactly?
On Saturday, 2015-09-19, 12:06:18, Michael Pyne wrote: > On Sat, September 19, 2015 17:32:33 Kevin Krammer wrote: > > So (a) and (b) workflows differ in that in (a) github mirror and > > git.kde.org have the same state, while in (b) the mirror is for a period > > of time not actually a mirror, but "ahead". > > > > Where "ahead" could also mean wrong if "klmn" needs to be modified or gets > > rejected. > > > > Is (b) the problem people keep discussing about? > > Kevin, first off thanks for taking all the time to diagram this in an email! :-) Since I haven't had to deal with these pull requests in any form yet, I wasn't sure I understood the implications. Git is already highly distributed, each developer has a full clone of whatever repository they work on and already have options of sharing "remotes". A clone on github is, as far as I understand, just a publically visible "remote" of one developer's state of the repository. And a pull request is just a formal notification that a certain commit, patch set or branch could be interesting for upstream. > I think some of us are seeing this as simply an administrative or technical > discussion of how we merge changes into git.kde.org in the presence of > Github. I don't think it's really that at all, but instead a question of > "where is the development happening" and "how is KDE [the community] > staying involved/up-to- date with that development"? Yes, good point. I just wanted to make sure I have the techical aspects sorted out correctly before making predictions or assumptions based on misunderstanding of how things work. > So I understand that from the perspective of "I already take patches by > email, this is just another way of accepting new patches" this whole > discussion might seem incredibly overdone. But there's another perspective > of "how do we [KDE] ensure that our community values around common > development are still maintained?", and that is the perspective from which > many of us have questions. For that is mostly an artifact of git, only a non-distributed VCS can "enforce" centralized development. > If the whole question were just a matter of s/emailed patch/pull request/ > and *nothing else* I think I'd agree that there's no problem. The questions > that are popping up are coming instead from trying to envision the next few > steps out from "We started accepted pull requests on Github", i.e. the > developer pressure on the rest of us to conform, "where will we do the code > reviews", or the fear that development would naturally shift over to > Github. I understand and agree with the concern regarding social pressure to allow this form of patch submission on a global basis once it is allowed by some projects. But I am still unsure on the "development will happen at github" part. Development happens on the developers machine which, due to git, can be done without any server after the initial clone. If developers want to cooperate on some work, they have, again due to git, several options, where using the original server (either as a branch or a personal clone on the server) is only one. They could allow one to access the other's machine, or use a private server or use any of the git hosting providers. What makes cloning from KDE's github mirror repository so different than uploading the code on your own? > Because after all if you can now contribute to KDE *just* by submitting pull > requests on your Github fork, then why bother getting a KDE development > account? This is something we didn't really have to worry about with > Bugzilla or emailed-patches because no one's masochistic enough to sustain > extended development that way. Well, when I started contributing to KDE, mailing patches was the only option. And I would have easily continued doing that if my counterpart, the already accredited KDE developer, wouldn't have told me to basically either get a CVS account or get lost ;-) Sure, the pull request is easier than to write a mail, but not a lot (sending a patch via email to the same recipient is easily scriptable). The burden in either case is on the receiving KDE developers. They become responsible for the patch, they either need to clean it up before pushing (on projects without review) or put it up for review and address all comments (for projects with review). How likely is a developer going to do that longer than accepting patches via email. For them this is almost the same overhead (almost since saving a patch and calling git am is slighlty more work than calling git pull on an already established remote). > But on Github that workflow is already the default, it would be more work to > go further and request a KDE identity.
Re: [kde-community] Bikeshedding - our strength apparently *sigh*
On Saturday, 2015-09-19, 17:53:17, Martin Graesslin wrote: > On Saturday, September 19, 2015 5:46:07 PM CEST Kevin Krammer wrote: > > The patch would still go through review at KDE. Even with no github at all > > a patch could have been through several revisions before being submitted. > > The review always deals with the "final" submission (obviously not final > > if things need to be changed). > > KDE does not have mandatory code review. I have to admit that I as a > maintainer have quite often pushed commits directly which went to me by mail > because I then reviewed them before pushing. Why uploading just to press > shipit? Right. I was just saying that the workflow would be the same. Patches of new contributors would go through review, either formal or by an established contributor, just like they would now. > My fear here is that if we allow pull request, people will also start to use > them for code review at which point we have split the development team in > those doing code review through reviewboard and those through github. You mean that if a project currently doesn't to reviews, it would start doing so due to accepting github contributions and then doing those on github instead of the KDE tool? Hmm, haven't though of that. But wouldn't that, from the point of view of anyone else (existing contributors, other KDE contributors) just be like the status before? I.e. no code review? Just that the patches that get pushed are potentially of higher quality because they had actually been reviewed? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] What is a GitHub pull request exactly?
On Saturday, 2015-09-19, 17:47:38, Martin Graesslin wrote: > On Saturday, September 19, 2015 5:32:33 PM CEST Kevin Krammer wrote: > > If the problem is somewhere in (a), where is it? > > I'm afraid of code review happening through the pull request instead of our > infrastructure. To me github pull requests are not just the "here's the > patch", but also the code review. But wouldn't that be just additional code review? Either on top of no code review or on before actual code review for projects that require it? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Bikeshedding - our strength apparently *sigh*
On Saturday, 2015-09-19, 17:36:09, Martin Graesslin wrote: > On Saturday, September 19, 2015 5:19:16 PM CEST Riccardo Iaconelli wrote: > > I think there was some confusion on that point, so let me state this > > again: > > the agreement is that github mirrors ARE going to be kept read-only, so > > someone with a KDE account and the developer karma still has to push the > > patch to git.kde.org (or reviewboard or so on...), if he wants to see it > > integrated. I don't see how that destroys our values. I just see it as a > > way through which potential newcomers can submit their first contribution, > > instead of mailing a patch. > > > > At least, in my view, the mirrors will STILL be *READ-ONLY*. > > I disagree. What I write now I mean for anything hosted under KDE/* and not > e.g. mgraesslin/* > > If we have some projects accepting pull requests it creates pressure for > other projects to also accept pull requests. This means my identity.kde.org > account is no longer enough to maintain a KDE project. This is the concern I understand. Some projects accepting such requests (whatever that means, still unclear on that) could easily create the expectation that all projects do. > Pullrequests in the github are more than a way to submit a patch. It's also > code review. At the point where this would happen, part of the community is > excluded from participating in the code review process. Even more part of > our code actually moves to github. Previous versions of the patch are then > only available through github infrastructure. I am not quite sure I understand this concern. The patch would still go through review at KDE. Even with no github at all a patch could have been through several revisions before being submitted. The review always deals with the "final" submission (obviously not final if things need to be changed). Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Official KDE mirror on github
On Monday, 2015-08-17, 09:12:18, Martin Graesslin wrote: On Monday, August 17, 2015 08:55:57 AM Jos van den Oever wrote: On Monday 17 August 2015 07:46:44 Martin Graesslin wrote: Hi community, over the last months I observed the following: * people not finding our git repositories Searching on ixquick: 'calligra git' https://community.kde.org/Calligra/Git 'kde git' https://community.kde.org/Sysadmin/GitKdeOrgManual 'kwin git' https://github.com/faho/kwin-tiling 'plasma git' https://community.kde.org/Plasma/Active/Development Searching on Google: 'calligra git' https://community.kde.org/Calligra/Building/2 'kde git' https://techbase.kde.org/Development/Git 'kwin git' http://blog.martin-graesslin.com/blog/2014/04/kwin-moved-to-an-own-reposit o ry/ 'plasma git' - https://aur.archlinux.org/packages/plasma-desktop-git/ On google the highest link to github was in position 4. Not too bad. There was no link to https://projects.kde.org/ or https://quickgit.kde.org/ What part of the KDE infrastructures can be fixed to make the repositories easier to find? * people being surprised that our code is not on github This is good moment to educate them on the ideals of KDE. Yes certainly, I start with lecturing a potential new contributor /sarcasm I know, sarcasm tag and all, but that is not what Jos was saying. Educating doesn't imply lecturing, laying out reasons for decisions that resulted in a situation can be done in a non confrontational or belitteling way. Not all potential new contributors will be developers of proprietary software who just happen to use our software in some way. Some will be developers specifically interested in contributing to FOSS but they might not have thought about the problem of proprietary services yet. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] RFC: Announcing new mailing lists
On Saturday, 2014-12-20, 21:21:01, Laszlo Papp wrote: On Sat, Dec 20, 2014 at 3:54 PM, Albert Astals Cid aa...@kde.org wrote: El Dissabte, 20 de desembre de 2014, a les 22:19:35, Ben Cooksley va escriure: In some instances, the creation of a new mailing list (like a bugs-dist list) would be noise. I'd be in favour of the requestor(s) announcing the new list though - so they could explain what the list would be used for. If sysadmin ends up doing it we'll likely be unable to provide as decent an explanation (as we're simply not as involved). But you're the only ones knowing that a mailing list has created. And as far as i understand there's a description field asked when requesting a list no? Could automatically send an email here saying List X was created with description Y. +1. If it is not automated, it will likely not be done properly as some people will forget about it. It ought to be easy to implement, too. The person requesting the list will get a notification mail when the list has been set up. So we just need to make sure that this mail contains text that says something like Consider announcing the availability of your new list to the wider KDE community by posting an introduction to kde-community@kde.org Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Fwd: Top 15 Mailinglists with messages in moderation
On Tuesday, 2014-09-02, 21:45:15, Ben Cooksley wrote: 11 kde-de I can take this one, it is one of my regular lists. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday, 2014-08-26, 12:02:27, Aaron J. Seigo wrote: On Tuesday, August 12, 2014 21.23:54 Kevin Ottens wrote: For instance, Kevin Krammer's example of having a mean of contacting largely for gauging the need of a scripting BoF is spot on. I hope it won't get to that point, but k-c-d would still have value if it was the only kind of traffic on it. How is a pan-KDE scripting BoF not a frameworks topic? It is mostly an application development topic, it becomes a frameworks topic if there is a need to create a framework for sharing stuff. In this specific case that's true, but not necessarily always. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday, 2014-08-26, 11:34:20, Aaron J. Seigo wrote: On Tuesday, August 12, 2014 17.31:11 Kevin Krammer wrote: On Tuesday, 2014-08-12, 16:40:36, Aaron J. Seigo wrote: On Tuesday, August 5, 2014 21.28:14 Kevin Krammer wrote: review requests probably should be going elsewhere; they make following actual discussion not about specific patches more difficult. I didn't mean review request as in reviewboard notifications. I meant request for review of things moving into kde-review. Ok :) So, kde-review requests ... There are two broad categories: * module-specific * lone projects An example of a module-specific category woudl be a new Calligra application. Does that benefit more from being announced on k-c-d, or on the Calligra devel ml? I think the reason these review request go to the general list is that more people would like to help with reviewing them, e.g. Albert is always looking at i18n issues. We can either subscribe Albert to all module lists or require that review requests are posted to multiple lists. Or keep it simple for everyone and post to the shared development list. If kde-devel@ is the mailing list for discussing use of KDE frameworks/libraries (as opposed to the development of them), then this would be a natural place for that to occur. It would also bring some additional focus and energy to kde-devel@ that is quite on-topic for that list. My suggestion therefore is to move kde-review announcements to kde-devel@, allowing k-c-d to focus on frameworks development and coordination. That is also an option. kde-devel is not as noisy as it used to be, so all developers could rejoin it. inter-module coordination ... should that not happen on the relevant module lists? You mean multiposting to several lists, potentially ones one is not subscribed to? Ah, we have a terminology issue. When I hear inter-module I hear something that affects 2-3 specific modules at the application level; you seem to be using it as a loose synonym for frameworks. No, I mean the former. Application modules. Another example, this time yours: Lets take for example my inquiry on interest for a scripting BoF. I could have posted that to all module development lists, I am sure posting to kde-core-devel was the better choice. Yes, k-c-d is perfect for that kind of thing; pan-KDE-software scripting is a frameworks issue. I don't see that as inter-module discussion any more than kcoreaddons, threadweaver, or any other frameworks level technology is. Only if it involves a (potential) framework. In this this is incidentally true. If the scope of the BoF would just be gathering best pratices, I would have had to post to plasma-devel, kdepim, kwrite-devel, kwin-devel, kde-edu, kde- games-devel, calligra-devel and those are just the ones I can think of right now. I am not even subscribed to all of these, I am sure the respective list moderators would be thrilled to get tons of moderation requests. the reason kde-devel exists separately from kde-core-devel is to provide a place for developers working with KDE libraries and applications that doesn't also carry discussion related to work ongoing in kdelibs. Sure, but asking questions about how to use frameworks will end up on the frameworks list, because that's the most obvious name for people looking for help on frameworks. agreed; my suggestion is that we already have these lists: kde-core-devel and kde-devel. frameworks-devel ought to be closed and merged back into k-c-d from whence it was forked with the r-b traffic going to a new list. If we feel that this will be a problem we'll need frameworks users. we already have that: kde-devel@ Hence me writing if. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday, 2014-08-26, 16:15:56, Aaron J. Seigo wrote: On Tuesday, August 26, 2014 13.28:56 Kevin Krammer wrote: On Tuesday, 2014-08-26, 12:02:27, Aaron J. Seigo wrote: On Tuesday, August 12, 2014 21.23:54 Kevin Ottens wrote: For instance, Kevin Krammer's example of having a mean of contacting largely for gauging the need of a scripting BoF is spot on. I hope it won't get to that point, but k-c-d would still have value if it was the only kind of traffic on it. How is a pan-KDE scripting BoF not a frameworks topic? It is mostly an application development topic, it becomes a frameworks topic if there is a need to create a framework for sharing stuff. Stuff means more than code. A best practice is shared stuff; a community-wide policy is shared stuff. The difference between having an agreed upon best practice or policy and a code repository is academic; it requires the same people to buy into it and provide input. Ok, sure, if everything development related is a frameworks topic, then this is also a framework topic. I used frameworks in the sense of being related to KDE frameworks products as in contrast to KDE application products. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday, 2014-08-12, 16:40:36, Aaron J. Seigo wrote: On Tuesday, August 5, 2014 21.28:14 Kevin Krammer wrote: k-c-d is the list to for things that happen in development, like kde-review requests, inter-module coordination, etc. It is more like a kde-community-technical list. review requests probably should be going elsewhere; they make following actual discussion not about specific patches more difficult. I didn't mean review request as in reviewboard notifications. I meant request for review of things moving into kde-review. inter-module coordination ... should that not happen on the relevant module lists? You mean multiposting to several lists, potentially ones one is not subscribed to? Doesn't sound very viable to me. Lets take for example my inquiry on interest for a scripting BoF. I could have posted that to all module development lists, I am sure posting to kde-core-devel was the better choice. kde-devel is more a list for question regarding developing with the KDE platform. If there is really a need to fold one list with kde-frameworks its this one. ... and then where do people go who want to ask questions about KDE-related development issues?[1] the reason kde-devel exists separately from kde-core-devel is to provide a place for developers working with KDE libraries and applications that doesn't also carry discussion related to work ongoing in kdelibs. Sure, but asking questions about how to use frameworks will end up on the frameworks list, because that's the most obvious name for people looking for help on frameworks. If we feel that this will be a problem we'll need frameworks users. putting frameworks discussion on kde-devel would just create a new displacement. Hence writing If there is really a need Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday, 2014-08-05, 20:29:05, Albert Astals Cid wrote: El Dilluns, 4 d'agost de 2014, a les 20:36:44, Vishesh Handa va escriure: Hello people Random Idea: How about we close the k-c-d mailing list? It's main purpose used to be to discuss kdelibs changes, but now since we have kde-frameworks, the mailing list seems less useful. We already have kde-devel for other generic kde stuff. kde-core-devel main purpose may had been discuss kdelibs changes, but it has trascended that purspose a while ago. I agree with Albert. k-c-d is the list to for things that happen in development, like kde-review requests, inter-module coordination, etc. It is more like a kde-community-technical list. kde-devel is more a list for question regarding developing with the KDE platform. If there is really a need to fold one list with kde-frameworks its this one. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Saturday, 2014-05-03, 16:56:05, Martin Klapetek wrote: I'm putting this reply separately as it's not directly related to the previous one... On Sat, May 3, 2014 at 2:19 PM, Myriam Schweingruber myr...@kde.org wrote: Also: changing names all the time and making releases for KDE sc and x and y and z and plasma and don't call it KDE are just not working, did ever anybody of you got aware that the whole rebranding to KDE is not what we release, it's a community is a complete and utter failure? I stopped long ago correcting people who call what they get on their desktop KDE and not KDE SC with plasma desktop or whatever is the official name we should use. It just doesn't work. Period. I think we have a great chance now, to start fresh with the upcoming release. But we have to get it right and we don't have much time left. I agree with Marco that this will be more natural once we don't have an SC release anymore. The desktop workspace product will probably still be refered to as KDE but the applications will be easier to conceive as separated products when they are not released at the same time as the workspace. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Request to join the Kde incubator for GCompris
On Friday, 2014-02-14, 13:02:31, Shlomi Fish wrote: Hi Aaron, On Fri, 14 Feb 2014 09:17:05 +0100 Aaron J. Seigo ase...@kde.org wrote: On Friday, February 14, 2014 04:24:12 Shlomi Fish wrote: The VideoLAN / VLC project took the opposite approach and after being unhappy with the GPLv3, decided to convert all their GPLv2 code into LGPLv2. I can name two likely reasons: DRM and tivoization clauses. Indeed, there is no one-size-fits-all license. Yes. BTW, regarding the so-called Tivoisation, from what I recall reading on http://zgp.org/pipermail/linux-elitists/ , the whole story was that Tivo contacted the https://en.wikipedia.org/wiki/Free_Software_Foundation (FSF) asking whether the practise of signing the kernel was allowed by the GPLv2. After consulting their lawyers, the FSF replied Yes , it's OK, thanks for asking.. Then after Tivo became popular, this practice was deemed non-desireable and Richard Stallman nicknamed it Tiovization after Tivo despite the fact that earlier the FSF told Tivo that it was acceptable. I doubt that the FSF has any problem with cryptography being used to protect users from software from untrusted sources so I doubt that they do not consider signing acceptable. The problem with Tivo, as far as I understand, is not them signing their binaries and checking that signature before execution. The problem is that Tivo does not provide an adequate mechanism to register new keys. Which of course denies the user at least one of the four core principles of Free Software. I doubt that Tivo asked the FSF whether withholding one of the Four Freedoms would be OK and the FSF said yes. I doubt they would even need to ask their legal counsels. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Plasmoids and Apps - was - Re: Applications in KDE Generation 5
On Friday, 2014-01-17, 19:48:14, Marco Martin wrote: On Friday 17 January 2014, Sebastian Kügler wrote: That's pretty much what plasma-windowed does (modulo some setup of KDeclarative, etc.). Disadvantage of a binary-per-app would be that it requires compiling, with a generic app shell loader thing (like plasma- windowed), you can write whole apps without compiling anything, so making it really easy to write, and deploy, no setup of development environment, etc. In order to make it easy to start them from the commandline, a one-liner script installed into the PATH would be enough. (Done that before, works like a charm.) btw, this is something worth exploring not only for having plasmoids as apps, but also from qt iirc they are thinking about an alternative to qmlscene (the command line tool) that they would advertise as shell for running simple full applications, so some 3rd party app that uses the thing may come up I think this tool is simply called qml. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Plasmoids and Apps - was - Re: Applications in KDE Generation 5
On Thursday, 2014-01-16, 10:43:42, Aaron J. Seigo wrote: We’ve had plasma-windows for ages now which runs plasmoids in their own independent window like a mini application. For apps like ksnapshot and kcalc the results would be identical or nearly so (kcalc would require support for putting a menu[bar] somewhere, or reorganizing how those particular features are presented). I also thought about plasma-windowed when reading that :) However, I think it is one of those hidden gems that nobody knows about. I've had questions like can I run $applet stand-alone on the user support lists a couple of times and plasma-windowed was the answer. Its drawback currently is that it is not very easy to figure out what to pass as its commandline argument. We also have an “application” form factor for plasmoids for ~1 year now which allows these components to make useful adjustments between being embedded as a plasmoid component and being run as a top-level window. Wow, nice! I don't think I've ever heard about this before and I am even monitoring plasma-devel. I don’t think it makes huge amounts of sense to turn ksnapshot into a plasmoid, but KCalc probably would as it would give us feature parity between the version on the desktop (and panels). Right now we have 2 calculators with differing features and levels of maintenance. I think these kind of convergences will become more natural once we can do traditional UI with QML (either through QtQuick.Controls or DeclarativeWidgets). Using the same application logic both for stand-alone application as well as Plasma applet becomes trivial then. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Plasmoids and Apps - was - Re: Applications in KDE Generation 5
On Thursday, 2014-01-16, 22:07:17, Albert Astals Cid wrote: El Dijous, 16 de gener de 2014, a les 12:05:17, Aaron J. Seigo va escriure: On Thursday, January 16, 2014 11:46:33 Kevin Krammer wrote: On Thursday, 2014-01-16, 10:43:42, Aaron J. Seigo wrote: I also thought about plasma-windowed when reading that :) However, I think it is one of those hidden gems that nobody knows about. I've had questions like can I run $applet stand-alone on the user support lists a couple of times and plasma-windowed was the answer. Its drawback currently is that it is not very easy to figure out what to pass as its commandline argument. KRunner will do this for you, actually. If you type “calc”, and the plasmoid runner is installed, you’ll get a match offering to run the plasmoid in a window. Well, it doesn’t actually *say* that, since that’s jargon, but that’s what the match does. For plasmoids suited to being run as an app they should also install a .desktop file with this command in it so that it is completely transparent to the user. All of the above occurs in Plasma Active, so we know it works well from a technical POV. Can you start it from the command line? plasma-windowed can be run from the commandline, e.g. plasma-windowed org.kde.networkmanagement A hypothetical KCalc Plasma applet could also install a .desktop file that has the appropriate Exec line. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] KDE Dinner at FOSDEM?
I will be there and I am interested as well :) Cheers, Kevin On Friday, 2014-01-03, 18:34:17, Marta Rybczynska wrote: Good idea. If we can get the list of people interested earlier, booking should be easier, too. Cheers, Marta On Fri, Jan 3, 2014 at 11:28 AM, John Layt jl...@kde.org wrote: On 3 January 2014 03:46, Aleix Pol aleix...@kde.org wrote: On Fri, Jan 3, 2014 at 1:19 AM, Albert Astals Cid aa...@kde.org wrote: Hi there, I know lots of us KDE heads will be at FOSDEM so I was wondering if people is interested in an official KDE Dinner for saturday. If you're interested, do you have suggestions for the restaurant? It sounds like a good idea, we've done that before. The biggest problem I guess is that we'll end up being ~15 people and it's not easy to allocate that much people. Also, I'm clueless about restaurants :). Two lessons learned from previous times: organise place and time in advance so everyone knows where to go, and don't make the time too early as people take ages to leave FOSDEM and get into the city. If someone local(ish) can find/remember a decent restaurant and book it would be best. John. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
