[kde-community] Applications in KDE Generation 5
Hi, It's time we talked about Applications. With the Frameworks and Plasma Tech Previews out the door we have applications starting to port to the hot new stuff, and we need to start discussing now how all the decisions being made around Frameworks and Plasma (such as the new Plasma naming scheme) will impact our Applications. What does it mean to be a KDE Application? How will we organise their development and release? How will we describe and promote them? The reason I'm raising this on the Community list rather than the Devel or Release or Promo lists is this really is a discussion about how we organise our community. I've talked about this with a few people at KDE events over the last year, and there seems a rough consensus that our current module organisation and the SC concept no longer reflects the way our community works both socially and technically, and so needs an overhaul to better reflect how we actually work today and to present our users a more compelling and co-ordinated vision for the future. At the core of everything are the modules. These are partially an artefact of our use of SVN to organise groups of people with similar interests to attack app domains that needed FOSS solutions. They usually revolved around a community mailing list and bugzilla category. Some modules were created simply because we had to have an SVN repo for code to go into. If we look at the modules now, while some are still thriving active communities with well-maintained apps, others are moribund or effectively dead with their apps slowly bit-rotting from lack of attention (and a lack of visibility to the wider community that this is an issue). Some hover somewhere between the two. This might not be so bad if the bit-rotting apps weren't also a part of the SC where they give users a poor impression of KDE Applications, as well as contributing to the sense of 'bloat' when people go to install a full KDE desktop experience and get a million-and-one small and mostly useless utilities. Some of these apps hardly seem relevant to a modern end-user experience, or integrate poorly with our modern workspace. We can do better than this. With all the work around KF5, Plasma 2, the separate git repos, and possible separate release cycles for Frameworks, Workspaces and Applications we have a chance to do a through review on the state of the modules and apps to ensure that our next major release is one that meets both the needs of our developer community and the needs of our users, today and for the next 5 years. What does a modern desktop/tablet/mobile *really* need? What is essential for a workspace, and what are just extras? How do we organise this all? And what the heck do we call it? The main points I think most people I talked to agreed on were: * A number of our apps and utilities really have had their day and need retiring, e.g. KsCD, Kppp, KFloppy. There's no point keeping low-quality or unmaintained apps around just to try ship a complete desktop experience, especially if there are other better apps out there (even if not KDE ones). Being part of the official release should be a stamp of quality: make apps work for it. Lets go through the existing apps and agree what needs dropping to Extragear or Unmaintained. * There are a lot of high-quality utils, apps and libraries in Extragear that better deserve to be in the main release, lets go through them and see what deserves to be promoted. Things like the NetworkManager plasmoid, Ktp, and KScreen are already on the list to move, but what else is there? Lets have a look and talk to their maintainers. * Can we have a clearer split between Workspace and Application? Perhaps it's time we moved Workspace essential tools like KMix from being the responsibility of a module to being part of Workspaces? (i.e. don't move the NetworkManager plasmoid from Extragear into the Network module, move it to Workspaces). This ensures the Workspaces community have better visibility and control of they things they really need, especially if they split release cycles. * 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? * Application domain-specific libraries such as libkipi or libkcddb may now be better organised under Frameworks rather than their modules, where they could gain a wider user base and a clearer maintenance viability. Can we have a Frameworks category for non-api stable libraries? * We have things like thumbnailers, kio slaves, dolphin plugins and strigi analyzers under each module, would these be better organised into meta-groups in Extragear so they're easier to find? * Can we create a proper KDE SDK? We have the SDK module which is really a mix of general development related apps and KDE-specific dev tools, and we have Examples, and we have a few
Re: [kde-community] Applications in KDE Generation 5
John Layt wrote: One other thing I would do is change our app lifecycle slightly. I'd introduce a new status of Deprecated that lies between Released and Unmaintained, for apps like Kopete and KPPP that are no longer relevant for most people or are being replaced, but may still have limited use and so need to be kept alive for a while. I'd envision a new lifecycle metadata attribute that looks something like Experimental - Incubator - Stable - Deprecated - Unmaintained, with only Stable apps eligible to be included in the regular Applications release cycle. Just my 2 cents here: I would be careful with this kind of lifecycle. An application with low activity (almost unmaintained) can be still stable for a long time, given our committment to binary compatibility. This is true especially for small applications, but it is something that should be considered. Also, I would be careful to use the word deprecated for applications like Kopete, where Ktp has not covered all the functionalities (yet); also Kopete receives changes/fixes. This is for the 4.x world, at least (if Kopete is not ported to 5 the problem is solved, but otherwise the problem still holds). Ciao -- Luigi ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Applications in KDE Generation 5
On 15 January 2014 22:15, Luigi Toscano luigi.tosc...@tiscali.it wrote: John Layt wrote: One other thing I would do is change our app lifecycle slightly. I'd introduce a new status of Deprecated that lies between Released and Unmaintained, for apps like Kopete and KPPP that are no longer relevant for most people or are being replaced, but may still have limited use and so need to be kept alive for a while. I'd envision a new lifecycle metadata attribute that looks something like Experimental - Incubator - Stable - Deprecated - Unmaintained, with only Stable apps eligible to be included in the regular Applications release cycle. Just my 2 cents here: I would be careful with this kind of lifecycle. An application with low activity (almost unmaintained) can be still stable for a long time, given our committment to binary compatibility. This is true especially for small applications, but it is something that should be considered. Yes, stable would have a fairly wide definition, but that's deliberate so it does include things like KCalc that really don't change much and don't need much work done to them. Perhaps an extra proviso of actively maintained would be needed to be included in the regular release cycle, where active means a named person as maintainer who triages any bugs. Also, I would be careful to use the word deprecated for applications like Kopete, where Ktp has not covered all the functionalities (yet); also Kopete receives changes/fixes. This is for the 4.x world, at least (if Kopete is not ported to 5 the problem is solved, but otherwise the problem still holds). Yeap, the terminology comes from me being a libraries person, deprecated api for us means still working and supported, we just think there's a better option so we won't put much effort into improving it. If there's a better word to use for normal people then that would be fine :-) One benefit from looking at the apps in this way will be to decide what does and doesn't get ported, labelling something as unmaintained says don't bother, deprecated would be port only if you really need it and don't make too much effort modernising it (use kde4support). Of course, if someone really wants to keep Kopete going they're welcome to do the work required and to take on maintainer status, and that would qualify for regular release status, but achieving that extra level of being included in Essentials would require wider community support, and I see that position in the future belonging to Ktp. That's really what this email is about, getting those sorts of conversations going about specific apps so we know where to start once KF5 goes final. Cheers! John. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
[kde-community] Plasmoids and Apps - was - Re: Applications in KDE Generation 5
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. 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? Cheers, Albert ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
[kde-community] High-quality apps in extragear - was - Re: Applications in KDE Generation 5
El Dimecres, 15 de gener de 2014, a les 21:47:17, John Layt va escriure: Hi, * There are a lot of high-quality utils, apps and libraries in Extragear that better deserve to be in the main release, lets go through them and see what deserves to be promoted. Things like the NetworkManager plasmoid, Ktp, and KScreen are already on the list to move, but what else is there? Lets have a look and talk to their maintainers. I barely remember us rejecting apps to be in the main modules, if apps are on extragear is because the maintainers want that. Cheers, Albert ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Qt Community partner
On 18 September 2013 15:43, Claudia Rauch ra...@kde.org wrote: On 18 September 2013 15:24, Jaroslaw Staniek stan...@kde.org wrote: Hi Claudia, Attached re-worked HTML that's relevant to Calligra. Some of that is a simple replacing KOffice-Calligra. I hope the quote from Boudewijn still applies to Calligra and can be put this way. Calligra folks and others, please comment and improve if possible :) Other changes: more recent screenshots, updated app names, Coffice screenshot for Android replaced maemo's KOffice, new Krita video from David Revoy. Great, thanks, Jaroslaw! Let me know when this is final. Hi Claudia, I see no other feedback. Please consider this as final already. I am sorry for delay. On 10 September 2013 10:38, Claudia Rauch ra...@kde.org wrote: On 9 September 2013 22:33, Jaroslaw Staniek stan...@kde.org wrote: By the way, Jos All, I am looking for a Digia contact so we can send updated content for [1]. As you see it stills explains KOffice. Perhaps someone would like to refresh the KDE 4 part too? Thanks for the pointer. I have a call with Digia about the partner program next week and will ask them to change it. Any suggestions for an updated text are welcome :) [1] http://qt.digia.com/Product/Qt-in-Action/KDE-and-KOffice/ On 5 September 2013 09:36, Jos Poortvliet jospoortvl...@gmail.com wrote: On Wednesday 04 September 2013 16:09:08 Cornelius Schumacher wrote: On Wednesday 04 September 2013 00:35:41 Aleix Pol wrote: I don't really understand how can it happen that Digia has a community program around Qt and we don't know about it... What am I missing? The partnership program was presented at the DevDays last year and some KDE people were there. So it's not that we know nothing. That doesn't mean that the communication around it can't be improved. From our point of view, I would just take it from where we are and get involved. Ok, will talk to them. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community -- regards / pozdrawiam, Jaroslaw Staniek Kexi Calligra KDE | http://calligra.org/kexi | http://kde.org Qt for Tizen | http://qt-project.org/wiki/Tizen Qt Certified Specialist | http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community -- Claudia Rauch Business Manager KDE e.V. Linienstr. 141 10115 Berlin Germany Phone: +49 (0) 30 2023 7305 0 Fax: +49 (0) 30 2023 7305 9 Mobile: +49 178 522 3086 Twitter: @frankfurtine KDE e.V. is a German Verein registered at the Amtsgericht Berlin (Charlottenburg), with number VR 31685 B. Its president is Cornelius Schumacher. For more information please see http://ev.kde.org, and http://kde.org/ ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community -- regards / pozdrawiam, Jaroslaw Staniek Kexi Calligra KDE | http://calligra.org/kexi | http://kde.org Qt for Tizen | http://qt-project.org/wiki/Tizen Qt Certified Specialist | http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community -- Claudia Rauch Business Manager KDE e.V. Schönhauser Allee 6/7 10119 Berlin Germany Phone: +49 (0) 30 2023 7305 0 Fax: +49 (0) 30 2023 7305 9 Mobile: +49 178 522 3086 Twitter: @frankfurtine KDE e.V. is a German Verein registered at the Amtsgericht Berlin (Charlottenburg), with number VR 31685 B. Its president is Cornelius Schumacher. For more information please see http://ev.kde.org, and http://kde.org/ ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community -- regards / pozdrawiam, Jaroslaw Staniek Kexi Calligra KDE | http://calligra.org/kexi | http://kde.org Qt for Tizen | http://qt-project.org/wiki/Tizen Qt Certified Specialist | http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
[kde-community] Applications hopping in and out of the coordinated release - was - Re: Applications in KDE Generation 5
El Dimecres, 15 de gener de 2014, a les 21:47:17, John Layt va escriure: Hi, We can still have a regular KDE Applications Release, but it is then up to individual communities or applications to opt in to that release cycle, or to decide to release on their own cycle. Strong communities with a distinct identity in the wider FOSS world, like PIM or Games or Calligra, may find it better to have their own separate release cycles and promo efforts, but I suspect most will stay with the regular release cycle. Hopping in an out of a release cycle is a pain in the ass for those making the release, at the moment we release around 160 git repos. If someone needs to herd 160 (actually more since you want to split more stuff) maintainers to find out what needs and what not every 4 weeks, you can find a lot of money for that guy since it's going to be the worst job ever. Cheers, Albert ___ 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 Wednesday 15 January 2014 23:13:11 Albert Astals Cid wrote: Besides how would you define this KDE Essential Applications group? I mean a tarball? An XML file somewhere? Personally I find distros should be smart enough to decide which apps they want to ship by default and which not. It's still nice to have some kind of grouping defined by the KDE release; the reason for that being that it's much easier to say install kdegames than install khangman and kgoldrunner and ktiktaktoe and ksnap and ltskat and ... and if kdegames -- or kdeessentials -- refers to the same name across distro's, that's good for migrating users. You really don't want a (non-smart) distro saying Oh, we didn't think kmix was essential . If there's a list of these 38 repositories / tarballs are the essentials this time around then that at least is a strong indication that that's what upstream (i.e. us as KDE) wants. [ade] ___ 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 13 January 2014 11:06:12 Jure Repinc wrote: Dne Sobota, 11. januarja 2014 ob 22:37:18 je Gustav González napisal(a): I guess this is my last message related to this thread. I just want to say thank you for all your help. Now I guess I can say that officially Tupi is part of the KDE project :) Welcome to the KDE community! Welcome! As part of the KDE community, you get a whole bunch of downstream for free, and probably people trying to build your software in places you did not expect. This mailing list isn't the right place for technical discussions or comments like it doesn't compile, but .. it doesn't compile (in places you didn't expect). This is expected :) Where do you expect .. oh, wait, it does mention a bug-tracker in the README. Right, I'll go off and start filing things there. Cheers, [ade] ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
[kde-community] Retiring applications - was - Re: Applications in KDE Generation 5
El Dimecres, 15 de gener de 2014, a les 21:47:17, John Layt va escriure: Hi, * A number of our apps and utilities really have had their day and need retiring, e.g. KsCD, Kppp, KFloppy. There's no point keeping low-quality or unmaintained apps around just to try ship a complete desktop experience, especially if there are other better apps out there (even if not KDE ones). Being part of the official release should be a stamp of quality: make apps work for it. Lets go through the existing apps and agree what needs dropping to Extragear or Unmaintained. I am not conviced by that, we probably still have some users for that and i'm pretty sure some of those apps still get roaming fixes from people, if you move them out from the apps we release on each release, you'll end up with the K3b situation, an application that has had bugfixes but hasn't had a release in ages so noone is beneffiting from those bugfixes because there's noone around that has enough power to do a release. Cheers, Albert ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
[kde-community] Killing Modules - was - Re: Applications in KDE Generation 5
El Dimecres, 15 de gener de 2014, a les 21:47:17, John Layt va escriure: Hi, I think those are fairly uncontroversial, but I feel that's not quite enough, it's just cleaning up the existing modules. I'd like to see something more radical: I'd abolish the Software Collection, the Modules and Extragear. As said in another sub-thread answer, i still think we should keep a pretty hard separation of the stuff we release every month (call it SC or as you want) and the stuff that is released on its own (call it extragear or as you want). But I do agree that Modules nowadays do not serve of much use and I would not disagree to killing them. There's always been the question of if blinken is a game or an edu app and if ktuberling is a game or an edu app, if you kill the modules you don't have to answer that anymore :D Cheers, Albert ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
