[kde-community] KDE Essential 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, > > I'd propose a > new collection of apps called KDE Essential Applications. This would > be a collection of high-quality applications that are considered > essential to a modern user experience and that the KDE community as a > whole guarantees to maintain to the highest standards. These would be > apps like Kate, Dolphin, Gwenview, Okular, Konsole, Ktp, etc, those > tools that you need to use every day and want to work well. Distros > and users would then know that this is a group that they need to > always install I feel this would create tension, who's going to be the one that says to someone "Sorry but your app is not good enough" and how is that person going to feel about it? 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. > with the other apps in the common release cycle being > optional but still of decent quality. Rather than these apps being > maintained separately inside their old module communities, they would > be organised into a new community that takes a shared responsibility > for ensuring they are maintained to the highest level with a > consistent user experience. Isn't that community the thing we call KDE? 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] KDE Essential Applications - was - Re: Applications in KDE Generation 5
On Wednesday, January 15, 2014 23:13:11 Albert Astals Cid wrote: > El Dimecres, 15 de gener de 2014, a les 21:47:17, John Layt va escriure: > > Hi, > > > > I'd propose a > > new collection of apps called KDE Essential Applications. This would > > be a collection of high-quality applications that are considered > > essential to a modern user experience and that the KDE community as a > > whole guarantees to maintain to the highest standards. These would be > > apps like Kate, Dolphin, Gwenview, Okular, Konsole, Ktp, etc, those > > tools that you need to use every day and want to work well. Distros > > and users would then know that this is a group that they need to > > always install > > I feel this would create tension, who's going to be the one that says to > someone "Sorry but your app is not good enough" and how is that person going > to feel about it? > > Besides how would you define this "KDE Essential Applications" group? I mean > a tarball? An XML file somewhere? I would expect this definition to be on projects.kde.org in the groupings that are already being made. > Personally I find distros should be smart > enough to decide which apps they want to ship by default and which not. +1 to what Adriaan said here. -- 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 2014-01-15, Albert Astals Cid wrote: > 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. I've actually in my distribution tried to ship stuff, including package selection, quite close to what is shipped by upstream, even when it not might be the best final choice for users, *because* that's what KDE is shipping, so should we. /Sune ___ 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, January 15, 2014 23:46:29 Adriaan de Groot wrote: > 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. I'm not sure the current categorisation works very well here, for example installing kdegraphics gives you a whole bunch of graphics-related tools, but probably too many (and then some are missing, such as digikam), and workflows might still not be complete. (Underlying assumptions, the user wants to accomplish a task, not "run an application".) A brainfart: rather than categorizing applications by their domain, maybe providing sets of apps for certain workflows or usecases, a vertical, rather than a horizontal integration, if you wish. For example: a SOHO metapackage would ship Calligra Sheets and Words, Kraft, Kontact. A primary educational metapackage would ship edu apps suitable for a certain age. A "Tablet" metapackage would include Plasma Active's UI, Krita Sketch, and other touch-suitable apps, and so on. These metapackages could even cause configuration changes elsewhere, so installing a "hobby photographer" metapackage would add an Activity for this task in Plasma Desktop. These metapackages can of course overlap (as it's really just a dependency definition), but it would it make it easier to create coherent, yet complete systems, and be a way to reflect a clearer vision for apps and sets of apps towards the actual use-cases. Just an idea... -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ 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 16 January 2014 11:56:08 Sebastian Kügler wrote: > On Wednesday, January 15, 2014 23:46:29 Adriaan de Groot wrote: > > 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 > > > > 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" > > I'm not sure the current categorisation works very well here, for example > installing kdegraphics gives you a whole bunch of graphics-related tools, > but probably too many (and then some are missing, such as digikam), and > workflows might still not be complete. (Underlying assumptions, the user > wants to accomplish a task, not "run an application".) Well-said. This is a topic in FreeBSD-packaging land right now, actually: how to make all the little KDE Applications visible (stuff pulled from extragear or third-party stuff that doesn't currently belong to one of the old-fashioned SVN module groupings). And, as you point out, digiKam is a natural for the "kde graphics" (well, is it?) grouping, even if it's not actually in that repository. > A brainfart: rather than categorizing applications by their domain, maybe > providing sets of apps for certain workflows or usecases, a vertical, rather > than a horizontal integration, if you wish. I like the idea, but fear for its practicality. Figuring out what the vertical is (pick a metier, ambacht or trade here -- say Photography) and which apps service it will take quite a bit of thinking. On the other hand, it might start something really nice: metaports, or software products (or whatever your distro + package manager calls it) that map to what people want to do .. oh, wait, you wrote that already: > For example: a SOHO metapackage would ship Calligra Sheets and Words, Kraft, > Kontact. A primary educational metapackage would ship edu apps suitable for > a certain age. A "Tablet" metapackage would include Plasma Active's UI, > Krita Sketch, and other touch-suitable apps, and so on. These metapackages > could even cause configuration changes elsewhere, so installing a "hobby > photographer" metapackage would add an Activity for this task in Plasma > Desktop. > > These metapackages can of course overlap (as it's really just a dependency > definition), but it would it make it easier to create coherent, yet complete > systems, and be a way to reflect a clearer vision for apps and sets of apps > towards the actual use-cases. A distro could also evaluate the packages available, of course, and add cheese to "hobby photographer", replacing whatever (*is* there even an equivalent?) KDE has there, in order to provide the best-possible set of apps for that vertical. But I don't think that "Scuba-diving C++ programmer" is going to be a viable metapackage any time soon. [ade] ___ 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. Well, scuba-diving seems popular among C programmers, but it seems that even these people are being more open-minded towards C++ lately. http://subsurface.hohndel.org/2013/12/subsurface-4-0-has-been-released/ Let's see what the future brings. ;) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ 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] KDE Essential Applications - was - Re: Applications in KDE Generation 5
On Thursday 16 January 2014 11:56:08 Sebastian Kügler wrote: > On Wednesday, January 15, 2014 23:46:29 Adriaan de Groot wrote: > > 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. > > I'm not sure the current categorisation works very well here, for example > installing kdegraphics gives you a whole bunch of graphics-related tools, > but probably too many (and then some are missing, such as digikam), and > workflows might still not be complete. (Underlying assumptions, the user > wants to accomplish a task, not "run an application".) > > A brainfart: rather than categorizing applications by their domain, maybe > providing sets of apps for certain workflows or usecases, a vertical, rather > than a horizontal integration, if you wish. > > For example: a SOHO metapackage would ship Calligra Sheets and Words, Kraft, > Kontact. A primary educational metapackage would ship edu apps suitable for > a certain age. A "Tablet" metapackage would include Plasma Active's UI, > Krita Sketch, and other touch-suitable apps, and so on. These metapackages > could even cause configuration changes elsewhere, so installing a "hobby > photographer" metapackage would add an Activity for this task in Plasma > Desktop. > > These metapackages can of course overlap (as it's really just a dependency > definition), but it would it make it easier to create coherent, yet complete > systems, and be a way to reflect a clearer vision for apps and sets of apps > towards the actual use-cases. > > Just an idea... Is it just me, or does this idea sound like it's going in a similar direction to the "Flows" Björn and I talked about at Akademy? ;) Tasks/workflows is really what we should be thinking about, because that's the user's perspective, and thus much more likely to be helpful to users than any technology-centric perspective. So, long story short, a big +1 from me! ___ 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 16 January 2014 21:50:47 Thomas Pfeiffer wrote: > > Is it just me, or does this idea sound like it's going in a similar > direction to the "Flows" Björn and I talked about at Akademy? ;) > Tasks/workflows is really what we should be thinking about, because that's > the user's perspective, and thus much more likely to be helpful to users > than any technology-centric perspective. > So, long story short, a big +1 from me! one thing tough... from this thread i'm gathering there seems to be the need as well of clearer distinction between applications and workspace, making also the applications to e able to be small, standalone, few dependencies entities. while an integrated workflow concept ties together way furtner applications and workspace, and applications between each other (maybe at the point you don't have a very defined concept of "application" anymore) 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? -- Marco Martin ___ 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 16.01.2014 22:24, Marco Martin wrote: On Thursday 16 January 2014 21:50:47 Thomas Pfeiffer wrote: Is it just me, or does this idea sound like it's going in a similar direction to the "Flows" Björn and I talked about at Akademy? ;) Tasks/workflows is really what we should be thinking about, because that's the user's perspective, and thus much more likely to be helpful to users than any technology-centric perspective. So, long story short, a big +1 from me! one thing tough... from this thread i'm gathering there seems to be the need as well of clearer distinction between applications and workspace, making also the applications to e able to be small, standalone, few dependencies entities. while an integrated workflow concept ties together way furtner applications and workspace, and applications between each other (maybe at the point you don't have a very defined concept of "application" anymore) 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? Just to be clear: Organizing applications in task/workflow-based sets is of course still a far cry from the task-centric UI vision we presented, and of course we'll still see standalone applications for the foreseeable future. Maybe they will co-exist with "Flow Components" or whatever why may call these building blocks, maybe an application can exist both as standalone and as part of a flow. What I meant with my mail was that to me, sebas' idea indicated a change in the underlying mindset. The current modules seem mostly organized from _our_ perspective, based on things like using the same libraries or being done by the same group of people. Bundling them together by what tasks users can accomplish with them seems way more useful to me from a user's perspective. Take KDE Edu for example: Though all applications in that module *can* be used for educational purposes, people may use some of them (e.g. Marble or Cantor) in a non-educational context and may not even be aware that they were originally meant for educational purposes. I, for one, have more than once tried to install marble on a machine with an Arch-based distro by typing pacman -S marble, wondering why the package could not be found. When I searched for marble, I was surprised that the package name was kdeedu-marble, because I use marble mainly for routing and thus am unaware that it's actually an educational application. That does not mean I want to split the KDE Edu community apart, of course. They're working together wonderfully and nobody would want to change that. Still, we cannot assume that all users see all applications which this community creates as "educational applications" just because they were originally created as such. People use Marble for routing, they use Cantor or KmPlot or Rocs in science, but they may all be used in educational settings as well. It all depends on the individual task. That also means that, as sebas suggested, an application/package can be part of more than one set of applications. Of course, distributions can create meta packages any way they want, but since all distros I've tried offer meta packages for the current modules, it seems that packages welcome the categorization we offer them. ___ 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] KDE Essential Applications - was - Re: Applications in KDE Generation 5
On Friday 17 January 2014, Thomas Pfeiffer wrote: > > Just to be clear: Organizing applications in task/workflow-based sets is > of course still a far cry from the task-centric UI vision we presented, > and of course we'll still see standalone applications for the > foreseeable future. Maybe they will co-exist with "Flow Components" or > whatever why may call these building blocks, maybe an application can > exist both as standalone and as part of a flow. yeah, but since this is the direction, i just wanted to raise this point, since to me this is a very fascinating problem, trying to fit together things that seems mutually exclusive and unconciliable is very interesting.. it challenges assumptions ;) > > That also means that, as sebas suggested, an application/package can be > part of more than one set of applications. Of course, distributions can > create meta packages any way they want, but since all distros I've tried > offer meta packages for the current modules, it seems that packages > welcome the categorization we offer them. so basically instead of one SC, there will be software collections, of which applications may belong to many collections.. marble would belong to the Education collection.. but also to Travel for instance -- Marco Martin ___ 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 Friday, 17 January 2014, Marco Martin wrote: > > >> >> That also means that, as sebas suggested, an application/package can be >> part of more than one set of applications. Of course, distributions can >> create meta packages any way they want, but since all distros I've tried >> offer meta packages for the current modules, it seems that packages >> welcome the categorization we offer them. > > so basically instead of one SC, there will be software collections, of which > applications may belong to many collections.. > marble would belong to the Education collection.. but also to Travel for > instance Welcome to tags ;) IIRC also a reason why Bodega's design is so clean. > > -- > Marco Martin > ___ > 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
Re: [kde-community] KDE Essential Applications - was - Re: Applications in KDE Generation 5
On Thursday 16 January 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 shouldn't be a dichotomy. It's a matter of defining and then pointing out sensible groupings of applications (a term which I use broadly here) to downstream. Whether any particular downstream picks it up (e.g. as a FreeBSD metaport or an OpenSUSE product) is up to them. But just defining these things forces *us* to think about how things work together and what kinds of tasks / workflows / hobbies we can effectively enable with our applications. It can also help downstream think about how *they* group stuff and present it to the user. This discussion is straying close to "package management without talking about packages anymore". That's probably a good thing. In the FreeBSD world, there's a history of having metapackages that get particular tasks done. One is called "kde4" and it installs a whole bunch of KDE things; also extragear apps and some third-party stuff as well. But my favorite metaport used to be "instant-workstation". You install it, and it pulls in the X server, some programming libraries, programming tools, and twm. And it's a great match between the task I want to accomplish and the (meta)package that implements this. And then I don't need to worry about figuring out where to get xterm from, if I can trust the people who define instant-workstation to think about the task at hand and what tools are needed. Note also that we *have* some kinds of metapackages already defined. Thery're on our website, at http://www.kde.org/applications/ . You'll note that the list of applications in "graphics" doesn't coincide with the repositories, and does include digiKam, because that's a useful application for doing (some kinds of) graphics work. Who said tags earlier in this thread? Yeah. [ade] ___ 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
Adriaan de Groot wrote: > Note also that we *have* some kinds of metapackages already defined. Thery're > on our website, at http://www.kde.org/applications/ . You'll note that the > list of applications in "graphics" doesn't coincide with the repositories, > and > does include digiKam, because that's a useful application for doing (some > kinds of) graphics work. They are not metapackages, imho: those are simple the packages from the same category (graphics, in this case) from SC and extragear. Categories can stay, I think; the definition of metapackages is orthogonal and can use the input from packagers. Ciao -- Luigi ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
