Re: [kde-community] Your KDE highlight of 2014?
On Tuesday, December 23, 2014 20.31:55 Jonathan Riddell wrote: Sign on the door says KDE Does it say Blue Systems on the door, or just KDE? -- Aaron J. Seigo 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] Using software created by KDE and KDE-related communities/companies for KDE infrastructure
On Tuesday, September 16, 2014 16.31:23 Ingo Klöcker wrote: If we want to use MyKolab.com: About 3 months ago Georg Greve has sent a message to the KDE e.V. mailing list (sorry, this list is restricted to KDE e.V. members) with a special offer for KDE people who want to use Kolab Systems' MyKolab.com. If KDE e.V. wishes to offer services to KDE as a whole, that really means things like being able to share calendars, having backups that are available to our sysadmins, etc. That takes more than the vanilla mykolab.org. ergo .. -- Aaron J. Seigo 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] Give People Access to Great Technology - a possible vision
On Saturday, September 20, 2014 10.15:56 Cornelius Schumacher wrote: On Friday 19 September 2014 19:04:53 Valorie Zimmerman wrote: On Fri, Sep 19, 2014 at 9:56 AM, Andrew Lake jamboar...@gmail.com wrote: Image: http://wstaw.org/m/2014/09/19/A_possible_vision.png I would say Plasma and Frameworks at the center. I think it's right to put the KDE desktop in the center in addition to the KDE frameworks. It's Plasma and the application which are our base and where we are coming from. It's this whole set which gives us the integration points we can use to expand to cloud, to devices, to other services. The desktop is a great starting point. Plasma was intended as a way to move beyond the desktop while retaining the desktop as a first class citizen, so that paragraph contains some irony. I use desktop in quotation marks because the end-user computing tasks performed on laptops and desktop computers have been moving to non-desktop form factors for some years now while the desktop type hardware has been slowly adopting some hardware characteristics of non-desktop devices. Fixating on the desktop is to bury one's head in the sand about that reality. Finally, the desktop has always been the primary focus. It has never not been the starting point. (Despite Plasma's goals.) This vision sounds like it comes from KDE circa 2005. Perhaps that's the goal, since as Andrew wrote, These thoughts are not intended to suggest an entirely new direction. However, this leaves me slightly stumped as to what the goal is here. Is it to remind KDE what it is, because that's been forgotten? Is it to reaffirm what KDE is as a means to pull back into its own center? -- Aaron J. Seigo 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] Give People Access to Great Technology - a possible vision
On Friday, September 19, 2014 09.56:39 Andrew Lake wrote: * Be free * Maintain our purpose * Have fun If I am understanding your proposal (and perhaps I'm not .. if so, please offer clarification), the vision statement consisting of the above three elements is a stand our ground vision in which nothing actually changes. That's based a fairly literal interpretation of the second point, while recognizing the the first and third points as long-standing principles in KDE. There's also a couple of we're already doing this statements in the email which seems to suggest that's sort of the intention. Which confuses me a bit. If what KDE is already doing what it needs to be doing, what is the problem? Maybe it's because of this: How do we regain some of the focus Paul Adams suggests we may have lost? What leads you to believe there has been a loss in technical focus? The hope though is for a clear, unambiguous focus that acknowledges our strengths as well as the reality of the trends in our technological ecosystem. I've read it over a few times now and I'm struggling to answer these questions: *As a developer, what principles from this vision should my KDE projects take on? * As a user, what benefits will this vision result in for me that would cause me to maintain or even deepen my commitment to KDE? * As a promoter, what points can I take from this vision to convince people to get excited about KDE? I'm struggling because there are over a dozen targets here: http://wstaw.org/m/2014/09/19/A_possible_vision.png such as social networking and smart home without definition of functional target or intended user benefit. It's a little like an alphabet soup of things that are currently part of the computing landscape that still needs to be arranged into sentences and paragraphs. Or perhaps that is the suggested vision: Do All The Technologies? http://wstaw.org/m/2014/09/19/A_possible_vision.png Why is desktop and frameworks mixed together? Why are applications peripheral? Why should applications have equal affinity for both frameworks and desktop? Should applications also demonstrate high capability for cloud and devices? -- Aaron J. Seigo 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] Give People Access to Great Technology - a possible vision
On Saturday, September 20, 2014 22.44:45 David Wright wrote: I wonder whether going forward we would be better served by asking the question of our users, 'What do you need KDE* to be for you?' The users KDE has now? The users KDE wants? The users KDE has contact with? Because essentially we are saying that with plasma 5 and kf5 it could be anything you want it to be. Is that really what people perceive is the message? That would be moderately shocking to me, though it would explain a few things I suppose. Maybe we should start by splitting this into commercial and consumer needs and take it from there. I'm not 100% clear on what you mean by commercial and consumer needs. By commercial and consumer do you roughly mean things needed to get work tasks done and things needed to consume content from the internet? Or do you mean something a bit more literal like people in offices and people at home? I know from my company that KDE would suit us as KDE for Windows would allow us to slowly shift over desktop apps first, before swapping out the o/s from underneath. We can't be the only company in a similar boat. In your opinion, what (general) vision does that translate into for KDE? *By KDE here im referring to the software, as I'm not sure what the term is for the amalgamation of plasma 5 / kf5 applications There is no such amalgamation, and that's probably why there is no term. -- Aaron J. Seigo 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] Using software created by KDE and KDE-related communities/companies for KDE infrastructure
On Monday, September 15, 2014 16.24:55 Aleix Pol wrote: - Kollab: This was already discussed recently in this list, it doesn't seem feasible to offer a Kollab instance to the membership (let alone the whole community) so I don't think we want to depend on it. That said, We might want to ensure we have all the tools to use the standards we can rely on, then ensure Kollab is capable to interact with them, given it's one of the few platforms we could have a say. I'm sure we can work sth out with Kolab Systems. - Bodega: +1, it should happen soon. I'd say there's some rough edges to polish on the client side, as we don't really have all the infrastructure needed so that it shines, but I'm confident it will happen sooner rather than later. This really depends on demonstrated interest. When I stepped back from KDE, I let this drop on the floor as well. If there is real interest, then I'm happy to take up development again. Someone in the ElementaryOS community on G+ mentioned Bodega the other day, openSuse is interested in using it. I'm just not interested in herding cats ... so if the cats will herd themselves in Bodega's direction, I'll meet you all there. -- Aaron J. Seigo 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] A change of heart
On Wednesday, August 27, 2014 22.07:23 Ben Cooksley wrote: I have examined the forum solution they suggest using - bbPress - and it is much less featureful than our current forum software, phpBB. In addition it does not support nested forums, which we are quite dependent on to organise content (we have 51,203 topics with 244,596 posts at the time of writing this email). It is also questionable I've actually used CommonsInABox and while quite nice in some ways, its performance is pretty dismal, some of the feature sets (e.g. the wikis, if one can call them that) are very weak and protecting against spam accounts is next to impossible ... -- Aaron J. Seigo 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, 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: 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. 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? Similarly for a new framework / library: that probably makes most sense to request review from the Frameworks team since it needs to follow a rather specific and highly prescribed set of standards. I don't think it makes any more sense to announce a new framework is available for review on the Calligra list than it does to announce a new Calligra application on k-c-d. This pattern repeats with kdepim, plasma, edu, games, etc.. Lone projects, ones that don't fit into any particularly active existing community, need a place to announce, of course. Also, i18n/l10n probably wants to be able to track such things. 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. 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. Example: If it involves, say, KDE Edu and KDE Games considering adopting a common QML UI strategy (random, but potentially realistic, example) then cross-posting to those lists seems quite sane. In such cases, k-c-d is not the best possible venue, though I see it being used for that from time to time. 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. 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@ -- Aaron J. Seigo 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, August 26, 2014 13.39:46 Kevin Krammer wrote: 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 At risk of repeating myself in this thread: the definition of frameworks is being used in a fashion that is too narrow to be useful. If the scripting BoF never results in a physical git repository that joins KDE Framework, but only results in a best practice to be adopted by the Frameworks audience, then it ought to be on-topic for the frameworks devel list. It should, after all, be reflected in KDE Frameworks as well as the applications above it. .. and what of the applications? At least one person from each KDE development team which uses frameworks ought to be on the frameworks devel mailing list, if only to keep frameworks devel on track for the needs of the wider audience of application developers. If that assumption is wrong, then KDE is going to have some serious problems on its hands in short order; but I suspect it is not at all off the mark and you ought to be able to announce your BoF on a k-c-d that is dedicated primarily to frameworks-as-a-product and reach your intended audience. -- Aaron J. Seigo 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, 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. -- Aaron J. Seigo 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, August 26, 2014 22.24:24 Eike Hein wrote: So yeah, let's please not make a write apps for Plasma mailing list. It doesn't fit what KDE is today - and that's a good thing, because our ambitions have become grander and our means to accomplish them have, too. I generally agree; that said, there is also nothing wrong with having good integration with Plasma. The key is to ensure it doesn't block the application from being used proficiently in other environments. The way I've seen the goal for years is something like this: * applications should run great everywhere they can * applications deliver an even *better* experience when paired with Plasma You know, a little both/and :) -- Aaron J. Seigo 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, 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. inter-module coordination ... should that not happen on the relevant module lists? 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. putting frameworks discussion on kde-devel would just create a new displacement. perhaps it would make more sense to recall the purpose of each list, adapt to how the community is using reviewboard, and simplify rather than redefine and move around long-extant infrastructure? [1] from https://mail.kde.org/mailman/listinfo -- Aaron J. Seigo 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] Jitsi Meet installation for KDE?
(belated response, catching up with kde lists i'm still sub'd to :) On Friday, August 1, 2014 15.24:48 Martin Sandsmark wrote: On Friday 1. August 2014 14.54.06 David Edmundson wrote: AFAIK QTox doesn't have group video just 1-1. Hmm, tox.im claims it supports video conferencing, but might be missing in qtox. Anyone want to try? :) a few of us tried it out this afternoon. the qt tox client does not support video, just chat. tox itself is highly onerous to use currently. it appears to be far too immature / young a codebase to be seriously used in this fashion. -- Aaron J. Seigo 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 Monday, August 4, 2014 20.36:44 Vishesh Handa wrote: 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. Not a good idea imho, and not only for the valid reasons others have already expressed in this thread. The frameworks list made sense for a while, when the idea was to not disrupt others with what was a pretty new and difficult effort, but that ceased being true a while back. Closing k-c-d would not only be a needless heaving of tradition overboard[1] we'd have to figure out what to do about everyone who is subscribed. Mass subscription is possible, but for what purpose? And who gets to deal with all the questions about it that will inevitably arise? What about all mentions in blogs, other emails and probably even devel documentation out there? A more real problem imho is that kde-frameworks-devel has become a review board ghetto. The vast majority of traffic is review board. k-c-d is only marginally better. This drowns out normal discussion and makes both lists less attractive to be on if you aren't a core contributor. This is not unlike how in the past using mailing lists for bug report CC's drowned out some lists. What would be nice imho is to have one list that is just review board requests (and move all the workspace related review requests to plasma-devel or to its own RB list) and another that is for actual non-patch-based discussion. Design discussion will be easier and it won't feel like standing in front of a fire hose when you join k-c-d or kde-frameworks-devel just because you want to get a bit involved. [1] culture matters, and culture centers around customs -- Aaron J. Seigo 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 Wednesday, February 19, 2014 21:18:25 Thomas Zander wrote: The beliefs of freedom are not at all hurt by someone taking that FLOSS and packaging it for a fee. There is no incompatibility there. Agreed, and this could be an opportunity to explore what is possible there. Perhaps the way we’ve been distributing KDE applications on platforms such as Windows and Mac is not the best. KDE Connect already goes through an application store on Android, though it is made available at no cost. People can always get the sources and build for themselves, but for these other platforms it could make sense to offer binaries via app stores and even charge a small fee. I know that I would happily pay a couple euros (or whatever) for KDE Connect on Android ... I do think we should keep the discussions of monetization separate from community hosting, however. They are not related, as can be seen by all the Linux distros who take the source code we write and monetize it. Some give back (some do so significantly, in fact), others don’t .. we don’t seem to be bothered by it. So definitely a topic for further discussion, and one that is sure to have a variety of points of view within KDE ... but perhaps we should separate it from issues of hosting projects. Our manifesto says nothing about monetization, probably because that isn’t part of the core values that defines KDE’s identity: freedom and community do. -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Future Git Plans
On Friday, February 14, 2014 22:52:04 Jeff Mitchell wrote: However, in the intervening years, GitLab (https://www.gitlab.com/) has Playing around with the demo a bit this morning, there are a number of benefits I see, most of which you already mentioned. The big one for me is the integration; that it feels a lot like github in style is a bonus too, as that should make KDE infrastructure feel more familiar to many new comers. It will mean a period of learning new tools by people used to what we have now, and a lot of dead links to projects.kde.org floating around out there unless there is some magical rewrite system implemented .. but those are not blocker issues imho. Due to its feature set, GitLab alone could take the place of at least projects.kde.org, commits.kde.org, quickgit.kde.org, and -- due to the built-in merge request workflow -- reviewboard.kde.org, drastically easing management and maintenance burden for the sysadmins. If the That’s a definitely plus and perhaps all the reason we need. I suppose sysadmin has already looked into what it will take to integrate it with identity.kde.org. You didn’t mention that in your email, but I assume that was probably one of the first things you did :) Since you said that gitlab has been doing well to gain adoption, I imagine that we will continue to see it grow or at least be maintained for a good while. That’s obviously quite important for KDE ... built-in wiki and issue tracking capabilities are enabled (which can be managed per-project), then projects (especially self-contained ones, such as Extragear projects) that desire a highly integrated workflow could migrate those functions to GitLab as well (note that this is not a statement indicating that we are planning to ditch Bugzilla any time soon!). I suppose a project could use the issue tracking as an internal project task list, which would be nice to have. Bugzilla is great for the public interaction, but that also makes its use for task lists not overly useful. It’s not a kanban board, but it’s at least a step up from what we have now on KDE infrastructure. This email serves two purposes: one, to inform the community of the direction we would like to go with KDE's Git hosting and request feedback; two, to ask for volunteer projects that are willing to act as crash test dummies for the new system, helping us figure out the best way to set it up, work out kinks, etc. Due to the bleeding-edge nature, we're currently limiting this to self-contained projects, such as those in Extragear. I’d be happy to engage in this process with Sprinter. It’s self-contained and active. -- Aaron J. Seigo ___ 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 Sunday, January 19, 2014 23:42:58 Martin Sandsmark wrote: On Sun, Jan 19, 2014 at 11:55:13AM +0100, Aaron J. Seigo wrote: this is not really related at all, and i hesitate to engage in the topic here due to loss of topical focus. It was merely to illustrate a point, that switching to QML is not a simple process, I don’t believe anyone intimated it was; the work done to get Plasma there has been more than a master class in that. and it seemingly takes us over a year (at the very least, since we still aren't close) to reach feature parity with the old solution. Yes, it takes time and effort. The QWidget UI has a ~20 year legacy behind it, while the QML legacy is quite recent, so this is to be expected. Therefore I think it's useless to move existing, nicely working applications (like kcalc) to it for seemingly no good reason at all. I agree that if there is no good reason, then there is no point. Good reasons were offered in the original mail, however, namely duplication of effort and inconsistency due to multiple implementations of what is from a use case perspective the same thing. have you worked with the Qt5 QML2 desktop components? Yes, I've been playing with the desktop components in Qt 5.2. Hopefully they will get a lot better before we release anything using them, though, because things like the file/folder selector is basically unusable in the current state, at least on the systems I've tested it on. For things like kcalc, the things the desktop components are not good at are irrelevant; the things it *is* good at could radically improve its UI. -- Aaron J. Seigo ___ 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 Monday, January 20, 2014 18:29:16 Martin Sandsmark wrote: On Mon, Jan 20, 2014 at 11:10:06AM +0100, Aaron J. Seigo wrote: namely duplication of effort and inconsistency due to multiple implementations of what is from a use case perspective the same thing. This would be all well and good if it wasn't for the gross regressions it would suffer. Yes, you don’t have to believe me. You argued the exact same thing for the screen locker. Er, no, actually. That was a completely different decision matrix that bears zero resemblance to this one. The screen locker was about consistency with other desktop shell components, the application issue is about deduplication of effort. But what you're arguing is a kind of false dichtomy. You would think that instead of two half-assed solutions we would get a single superior implementation, but instead we get a single inferior one. I disagree; ultimately the code will decide who was right, though with stop energy like this I can imagine the experiment never being undertaken at all. For things like kcalc, the things the desktop components are not good at are irrelevant; the things it *is* good at could radically improve its UI. The thing I'm unable to discern is how it would radically improve its UI. For one: by having a nice paper-tape presentation of the calculation with history. Rather easier to do in a visually pleasant way with QML. The current kcalc UI is very good, I often use it for stuff like bit fiddling, etc. I can't say the same thing for the calculator plasma applet. But please feel free to prove me wrong and make the plasma calculator much better than kcalc. I would expect a QML UI on top of the kcalc logic would be a far more sensible approach. Not sure why you would think we’d go at it from the other direction. But I'd argue very strongly to not replace kcalc until the replacement is visibly better. Agreed, or at the very least has parity. -- Aaron J. Seigo ___ 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, January 16, 2014 22:54:43 Albert Astals Cid wrote: So basically there's no difference between a plasmoid and a non-plasmoid? There are differences; I would never do Krita as a plasmoid, e.g. Or, for that matter, Okular. The Plasmoid design pattern lends itself to self-contained, highly focused, single-use-case UIs. That is purposeful; the “full desktop application” paradigm is not visible in kcalc, and full desktop apps are not well suited to be implemented as plasmoids. It’s a question of granularity across a spectrum that runs from desktop shell gadgets to full desktop applications. There is a gray area in the middle of that spectrum: things like KCalc make sense both as desktop shell gadgets but also as stand-alone applications. What the application FormFactor and the single-plasmoid shells like plasma- windowed provide is a way to address that middle zone. Apps the “full desktop app” end of the spectrum may *use* plasmoids (or a similar pattern) themselves. We see this in Skrooge and Amarok, for instance. If that's the case, I don't understand why John started the discussion if we should favor plasmoids over non-plasmoids or viceversa since it seems to me plasmoid or not is an implementation detail. I think it’s a matter of consciously deciding which implementation direction to take different apps, and that implies we know why we pick one or the other. Beyond that, it is an implementation detail, yes. -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] KDE Essential Applications - was - Re: Applications in KDE Generation 5
On Thursday, January 16, 2014 22:24:09 Marco Martin wrote: they are both desiderable, but they seems quite in contrast each other. I'm sure I'm hitting a false dichotomy there, but not seeing a clear solution. does anybody does? there are (at least) two ways to approach the “integrated workflow” goal: * tie everything together by using a common implementation (the ‘shared library’ approach, if you will) * define patterns that developers implement in their applications (the ‘human interface guidelines’ approach) we can do both at the same time: Plasma can create a tightly integrated workflow for the components under the Plasma umbrella, and KDE applications can take advantage of the defined patterns. this can be made easier by utilizing runtime interfaces that provide a contact surface to the desktop shell and other applications. this is what kparts and dcop were designed around in their day, if one thinks about it from that perspective. these integrated workflows could be seen as the next iteration of this philosophy in our design. -- Aaron J. Seigo ___ 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, January 16, 2014 22:05:08 Albert Astals Cid wrote: * Sorry for being rude ... * Sorry if being being rude and wrong made you feel insulted. It was not my intention at all. thanks for writing this, it is meaningful. i would echo what marco said about sorry for being wrong, though ... -- Aaron J. Seigo ___ 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 Wednesday, January 15, 2014 22:56:12 Albert Astals Cid wrote: El Dimecres, 15 de gener de 2014, a les 21:47:17, John Layt va escriure: Hi, * Do we need small utilities like KCalc as stand-alone apps, or do they belong in Workspaces, perhaps as Plasmoids? Where do we draw the line between them? And if there's both a Plasmoid and an App for something, which goes in the main release? Please don't force plasmoids down my throat. That is not a real threat, and phrasing it like it is a real threat feels extremely disrespectful. As the person who came up with and used to maintain this part of KDE, It makes me feel like you think I’ve been wandering around forcing people to do things they don’t want to and that makes me feel very uncomfortable. Why would i want a calculator as a plasmoid instead of an application? So that i need to minimize all my other apps to see the desktop to see it instead of just alt-tabbing? What’s worse than insulting another person is doing so from ignorance. 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 won’t even get into the dashboard or panels ...) 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. 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. Should we force kcalc to port to QML and become a plasmoid? No, because it is up to the maintainer .. but I think we ought to think about these things in non-reactive, accurate technical terms where the goal is ‘what is the best end result for the user’. -- Aaron J. Seigo ___ 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, January 16, 2014 11:35:29 Sebastian Kügler wrote: I think this is really not the way we should discuss things. Accusing Albert of insulting anybody is not necessary, accusing him of doing it out of ignorance is clearly against our code of conduct. Fine; so when someone says “I need to minimize all my other apps to see the desktop to see it” and that is blatantly false, how would you like me to respond? That particular statement has been used for years and I’ve patiently corrected it time and again, and it is still used to justify things like “don’t force this down our throat”. That is not fair play. It seems that CoC applies to me, while it’s cool for Albert to say things like “don’t force plasmoids down my throat”. Yay for double standards and not having any sort of expectation of fair play. -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] KDE Essential Applications - was - Re: Applications in KDE Generation 5
On Thursday, January 16, 2014 12:15:05 Adriaan de Groot wrote: But I don't think that Scuba-diving C++ programmer is going to be a viable metapackage any time soon. No, but it could be a “Sports and Fitness” metapackage. There are a remarkable number of such apps for Android, for instance. (Well, remarkable at least to me ... :) Did you know there is a running app that simulates being in a zombie apocolypse? There’s a whole multi-month workout routine built around this story line and it’s quite popular. It even has multiple “seasons” of storyline now! If we had a “Sports and Fitness” metapackage that only included a scuba-diving app right now, it might inspire people to think about the possibilities and create more apps in this category. tl;dr - This approach of having metapackages for everything might be a positive thing, even in the odd cases of “single entry” packages. ..and of course, if there was just only “Sports and Fitness” application on git.kde.org, distros could merge with apps from other projects as you noted about “hobby photographer”. -- Aaron J. Seigo ___ 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, January 16, 2014 16:09:03 Sebastian Kügler wrote: Hi Aaron, On Thursday, January 16, 2014 13:24:51 Aaron J. Seigo wrote: That particular statement has been used for years and I’ve patiently corrected it time and again, and it is still used to justify things like “don’t force this down our throat”. That is not fair play. Just to point out the obvious, while it might be human to lose patience, it's not OK, and certainly not helpful. After literally years of this, it is not a matter of “keeping one’s patience”. I have kept my patience and tried to work through these issues over the course of some 6 years now. I think that is reasonable beyond reasonable, and I resent you asking the person who says “This has made me feel uncomfortable” to sit on it. It’s rather close to the ”blame the victim” pattern. Had you said exactly that (This has made me feel uncomfortable”), it would have been completely fine. Instead you implied ignorance and ill-intent. This makes all the difference. Let me quote to you from my own email then: As the person who came up with and used to maintain this part of KDE, It makes me feel like you think I’ve been wandering around forcing people to do things they don’t want to and that makes me feel very uncomfortable.” As you can see, I did indeed say exactly “that makes me feel very uncomfortable” Furthermore, I was not under the impression there was any ill-intent. That is something you read into what I wrote, for whatever reason. I’ve tried to make it clear that I do not see ill-intent, but a double standard in action and an institutionalized acceptance of negative personal response depending on the source and recipient. I accept that you read into what I wrote something I did not intend, but now could you return that favor and accept that this I do not actually see ill-intent here? As for implying ignorance: I did not imply it, I stated it openly. I will freely admit that using that precise word probably is born of frustration with a six year background story: after patiently correcting the same rubbish within your own community to no effect, I don’t know how else to help people understand that the meme in question is not an opinion, but a factual error. The dictionary definition of ignorance is this: the state or fact of being ignorant : lack of knowledge, education, or awareness http://www.merriam-webster.com/dictionary/ignorance If I had said Albert was stupid (which he is not), that would have been something rather different: a statement (insult, even) about the person himself. Ignorance is an observation of state, at least when offered non- pejoratively. Let me offer an example: I am ignorant about Poppler (to take an example); by contrast, Albert knows quite a bit about Poppler. I would hope that in a conversation where Poppler comes up that I would not make sweeping statements without fact checking them. Doing so would be speaking out of ignorance. If you wish to discuss the rest of you email, we can do so face to face (virtually, e.g. on G+ hangouts) -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Tupi: Open 2D Magic
On Monday, December 23, 2013 00:14:13 Gustav González wrote: So guys, what is the next step we should take to join the KDE community? First off: Tupi looks *awesome* .. nicely done :) You’ve probably already seen the KDE Manifesto: http://manifesto.kde.org/ That pretty much sums up the commitments and benefits. The big one for Tupi probably is to migrate the home of the primary git repo from github.com to git.kde.org. To do that, your developers need to apply for a commit account on https://identity.kde.org/ and then someone should add the Tupi git repository to their scratch area, following the directions here: http://community.kde.org/Sysadmin/GitKdeOrgManual and then make a sys admin request here: https://sysadmin.kde.org/tickets/index.php?page=ticketsact=add to move the repository to a proper home (probably in extragear, perhaps in artwork?). You can browse the repository structure here: https://projects.kde.org/projects with extragear here: https://projects.kde.org/projects/extragear I look forward to seeing Tupi part of the KDE community :) -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Translating the KDE manifesto
On Thursday, December 19, 2013 20:05:38 Albert Astals Cid wrote: Any reason why the manifesto translations should be more strict than say the 4.12 announcement? IMHO: The release announcements do not encode community ground rules and consensus agreements. The wording in the KDE Manifesto is carefully selected to communicate very specific ideas. A mistranslation of a release announcement doesn’t have the same implications as a mistranslation of this sort of document. -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Discussion: KDE Manifesto, established practices
On Tuesday, November 12, 2013 18:38:24 Myriam Schweingruber wrote: Sorry to top-post, but this is getting wordier and wordier and I have long lost trace of what is said. Could we have a tl::dr wrap-up, please? my position: * “special considerations” is ill defined and can be applied to nearly anything * this defeats the point of having such language in the manifesto * abuse of loosely defined phrasing has happened in the past within KDE * exceptions to established practices exist and belong in the documentation for that practice example: coding style is noted as variable across KDE in the commit policy * the new wording is ‘relaxed’ enough to not come across as overly strict, even without exceptions; KISS -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Discussion: KDE Manifesto, web services
On Monday, November 11, 2013 20:04:52 Ingo Klöcker wrote: Is the which is approved by the KDE system administration team really needed? since they’ll be doing the work and responsible for the outcome (that is the mandate we gave them), it is only proper that we agree that the action plans we’re going to expect them to support are agreeable to them. -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Tuesday, November 12, 2013 16:43:27 Cornelius Schumacher wrote: It also sounds like it would rule out using any other tools, which are not hosted on KDE infrastructure. In the IRC log there were mentioned Google Docs, Trello, there are certainly more (and not only closed-source ones). I don't think we are trying to say that, as that would obviously go against the status quo, and the manifest is supposed to document our current view, not a future goal. what project assets are hosted on google docs, trello, etc? perhaps we’re having a definition problem here. to me “project assets” are all the things that make up the end project/product as released. this is how the word is used in relation to, for instance, games with all their data and graphics. TODO lists and other non-deliverables are not project assets. they are things the project team may use, but they are not project assets. it is very problematic to include things like TODO lists in there since a developer may keep a TODO list, meeting notes or other things related to projects entirely on a local disk. what then? no, this should only be about what is delivered as part of the project’s product itself. if that is not clear (and apparently it is not .. you aren’t the first to suggest this) then perhaps we need a phrase other than “project assets” or some clarification of it. * Hosting location is still not nailed down further than KDE contributor accounts must have r/w access, answering a de- mand in the original Manifesto discussion. I guess the reason why I'm perceiving this as excluding non-KDE hosted infrastructure is that I read KDE contributor accounts must have r/w access as I must be able to log in with identity.kde.org. That's obviously not possible with many services hosted by other parties. that's precisely the point: to ensure that if you have a KDE contributor account that you can then use that account to change assets. -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Monday, November 11, 2013 10:34:09 Eike Hein wrote: There's two halves to the access model: * All KDE contributor accounts must have direct write access. (There we all agree on this point, it is therefore unnecessary to go into this further. it is the ONLY clause: * Only KDE contributor accounts may have direct write access. That means if your code is in a place that in theory allows giving others access, you're not allowed to do so. this is unenforceable, and probably not even measurable. again, we can observe that by examining it in terms of being a tautology: only people with direct write access to git.kde.org can change the code on git.kde.org. (repeat for any other kde hosted service) if there was a theoretical repository on git-hub for the (also theoretical) kde-foo project, writes to that repository could still not find their way into git.kde.org unless somone with write access pushes it there. this is, in fact, exactly what we do every single day on reviewboard.kde.org: we proxy changes for others. so: “if your code is in a place that in theory allows giving others access” becomes “if your code is in place that in theory allows giving others access, that code still requires a KDE contributor account to approve of those changes before they reach git.kde.org. therefore, if your code is in a place that in theory allows giving others access, only KDE contributors accounts may have direct write access to the git.kde.org repository.” iow, it has solved nothing. worse, if we actually were to try and enforce this in a meaningful fashion, it could only be done in a way that would interfere with reviewboard and similar patch review systems. perhaps what you are trying to say is: the canonical version of the project is hosted on KDE infrastructure now *that* makes sense because it means that to be a KDE project then it must be hosted within the KDE infrastructure .. which in turn means that for any contributions to make it into the canonical version of that project which come from by means other than direct access must be approved by a KDE contributor account. -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Monday, November 11, 2013 10:44:46 Eike Hein wrote: On Monday 11 November 2013 10:14:56 Aaron J. Seigo wrote: the difference is that it does not specify “ONLY”, which in this day and age of decentralized revision control systems seems sensible. or are you suggesting that we should not allow any contributions from the “outside”? You're confusing direct write access with contributing. We have several means to accept contributions from the out- side that don't require the former, e.g. ReviewBoard. ha. i just wrote an email noting this as well. fun. it is exactly this point about contribution vs write access that makes the entire “ONLY” clause useless. not only is the new language clearer thanks to removing 2 lines and one indented list, it makes the manifesto sound a lot less like it was put together by pedants: ONLY and ALL .. really? The purpose of the Manifesto is to codify established practice and important, long-held ideas of the community in order to act as a cache that aids us in making future discussions. To agreed. i have been making that exact argument for goodness how many years :) that end, we had a long discussion process that produced a con- sensus that was put in writing. The burden of proof is there- fore on change proposals, and changes in intended meaning should be argued a lot better than the current wording does not soothe my eyes and with spikes like really?. great; please respond to my other email. -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Monday, November 11, 2013 10:56:11 Eike Hein wrote: On Monday 11 November 2013 10:29:07 Aaron J. Seigo wrote: i’ll also point out that we already have a tiered system: maintainers. Psychology matters. It's a lot easier to step up to become a right, so not all tiered systems are bad. it depends on the implementation of them and what the resulting attributes are due to that implementation. ergo concern about “second class citizens” is unwaranted and in fact goes against healthy and well-formed processes we already see in KDE. so if the ONLY clause was somehow intended to address the “second class citizen” issue, it should be evident how it can not do so in its current form and also remain consistent with KDE’s current, consensus culture. -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Monday, November 11, 2013 11:18:34 Eike Hein wrote: By disallowing direct write access for folks without a KDE contributor account, we're making them get KDE contributor accounts to gain write access. This ends up happening as a natural result of the tedium involved with proxying changes, and once they've got their accounts, there are few-to-no barriers between them and diversifying into other KDE pro- jects. Meanwhile, because everyone's been through the same process to get that account, this can work in terms of trust. i fail to see how the ONLY clause addresses that in the least. I think you're locked into the idea Eike and his ilk are just scared of the barbarians at the gates, this is classic tribalism!”, not at all; my concern is that is that literal wording in the manifesto describes a “barbarians at the gates” mentality. you may not have that in mind, but that’s what it states. it is so awkward that i honestly can not show it to people without them frowning to figure out just what the heck they read or me having to explain why it is so awkward. i don’t think the ONLY clause inevitably leads to what you are hoping for, there are other methods people come into KDE by and emphasizing this particular one in such a manner within the Manifesto makes it incomplete. i totally get what the language is trying to do from a social engineering perspective. i think we can do better than that wording, however. but my actual evil plan is to turn the, eh, barbarians at the gates into folks who accept responsibi- lity in KDE. Because I've *seen it work*. i’m not disagreeing with that model. what i’m trying to point out is that the ONLY clause does nothing to help with that. what it did do was make the manifesto sound ham-fisted and awkward. it may make sense to you, but it’s actually quite opaque. an obfuscated (intentionally or not) manifesto will only lead to it being poorly implemented at best and at worst worked against. you’ve spent several emails explaining what you want to cause. i think we all agree that the “get more people in the KDE community” goal, along with the methodology you describe, is a good thing. what i’d prefer to discuss is: * how the ONLY clause will actually work * how we can open entry gateways using the manifesto that are more broadly encompassing as well as clearer in the formation -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Why were there no talks about Ubuntu Mobile at Akademy?
On Wednesday, August 21, 2013 09:14:58 Michael Zanetti wrote: - Not all areas can be shared. This is true. So let’s focus on the many things that can be instead of focusing on what can’t be done :) I for one work on Unity8, which just works and looks so different in every way than plasma does. We don't need Plasmoid containers, you don't need search scopes. How do you know we don’t need search scopes? The functional similarity between “search scopes” and Plasma::AbstractRunner is pretty stunning, actually. - Once there is something which might make sense to be shared, it requires the exact people working on it having interest in collaborating. Which Yes .. and no. If we leave it up to each and every individual to make a decision on their own in a vacuum, then you are correct. If we make thoughtful community/corporate encompassing goals then it is not left up to each individual: there will be a point of guidance that people can use to guide their decisions. means, the responsive KDE person needs to accept that a certain API needs to change for requirements NOT needed by KDE This is a non-sequitor. If someone is using KDE libraries, then their requirements become part of what is needed by KDE. KDE is not a castle on a hill with a moat around it; it is an open marketplace where the edges are defined by participation. and the responsive person in Canonical needs to have interest in pulling in something that most likely can do way more than Ubuntu needs at this stage, There is that word again: “likely” :) Every time I see that I think “.. it means we haven’t done the necessary homework to know for sure and so people are making assumptions” There are two important points to consider: a) Probably most libraries used do more than Ubuntu needs. Is every glibc call used by Ubuntu software written by Canonical? Is every Qt API used? (QWidget, e.g.) b) If a library in KF5 is poorly modularized, resulting in something that does so much more than it ought to that we should reconsider the division lines within it, we need to know *now*. So if there is a KF5 library that would make sense being used in Unity (e.g.) but it does “way too much”, we can fix that. But we need to know. needed. It is not possible for me or Albert to go to some API guys and tell them: You have to share code with KDE. This needs to happen from inside the team. The person doing the work must drive it. There must be leadership that can set engineering mandates? Now, coming from the Gnome/Gtk area, Canonical's people mostly are aware what code could be shared with Gnome, but not many of them have a clue what KDE frameworks actually is. I’d just echo Thiago’s questions here, as they are truly insightful and key .. Same the other way round. I'm quite sure very few here know how the Ubuntu's architecture is built up. Not many, I’m sure, but they exist. We have the Kubuntu folks and then there are crazy people like me who do look at what ends up in Canonical’s public repos and who have even done things like port apps written for Ubuntu Touch to other QML component sets. So the ignorance can be dissipated through effort! Then again, we actually do share and reuse some code. Take all the lightdm stuff for example, the dbusmenu stuff and many more libs which in history have flown into both directions already. The status notifier stuff was a success, yes. I’d like to see that built upon so we have many more like that. -- Aaron J. Seigo 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] Why were there no talks about Ubuntu Mobile at Akademy?
On Friday, August 16, 2013 07:42:54 Carl Symons wrote: The weird part of this discussion for me is how Canonical became the victim, how Jos's comment were intended to bash Canonical at every turn. Having watched many Canonical employees interact with people over the last several months on G+, it is very apparent that this has become part of the culture there. Either that or they only hire people who view the world in this manner. Either way, it adds challenge to dealing with Canonical and anyone who approaches them should bear in mind to be triply clear in what they say and ensure doubly the other person understands what was said. -- Aaron J. Seigo 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
