Re: [kde-community] Retiring applications - was - Re: Applications in KDE Generation 5
On Wed, Jan 15, 2014 at 4:37 PM, Albert Astals Cid wrote: > 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 K3b rocks. I hear of gnome and unity users all the time who use it, and recommend it to others. Would this be a good candidate for the CWG "Needs Some Love" series? Valorie -- http://about.me/valoriez ___ 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
Hi folks, I've finally gotten up-to-date on this long, technical and emotional discussion. I'd just like to say, I love each of you who wrote. You care about quality, you care about the KDE community, and you care deeply about one another. Damn do I love this community. As long as we can keep remembering that -- that we love one another, even while we might be hurt by a chance remark -- we can get through this. On most technical lists, it wouldn't be OK to bring these feelings to the surface, I guess. But guess what? This is the community list, and feelings are right there along with the technical details. It is worthwhile to remember that our words have power. One of the things I've found useful, when I hear my keys banging loudly, is to finish the email I'm typing and then walk away. Let those emotions dissipate a bit, and then return to the keyboard to turn the language down a notch before sending. Strong feelings are awesome! We get angry and hurt for the same reason we feel joy -- because we care. But sometimes the email should wait a few minute or even a day before being sent. We care, and that's why we're able to create the best software in the world. Thanks to each of you for being YOU. Valorie -- http://about.me/valoriez ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Applications in KDE Generation 5
Hello, Very important thread IMO, but way too big for me to follow properly already. I tried to locate one email I could use to reply "after the facts", that one doesn't look too bar. :-) On Thursday 16 January 2014 11:42:43 Aaron J. Seigo wrote: > On Wednesday, January 15, 2014 21:47:17 John Layt wrote: > > It's time we talked about Applications. With the Frameworks and > > Huzzah; thanks for starting this conversation Agreed. > > * Can we have a clearer split between Workspace and Application? > > We’ve been working on it for ~6 years now :) Still not there yet though, but this year or the next might be the one it seems. :-) > > 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). > > For KMix and NetworkManager I think this makes a lot of sense. Definitely, and they might even agree to it if there are changes to the way we organize our releases (back in the day that was why NetworkManager maintainer wanted to stay in Extragear). > > This ensures the Workspaces > > community have better visibility and control of they things they > > really need, especially if they split release cycles. > > I would not word it in terms of control, as that might sound scary (and > rightfully so) to e.g. the KMix team. They should be able to work under > their own steam. It would certainly encourage all of those teams to > *collaborate* more with each other, however, and not worry as much about > things like “how does KMix work in GNOME Shell”. > > The scoping of this needs to be done between the current (growing) > Workspaces community and the individual application teams. Guideline > questions I’ve used in the past for identifying a useful set of lines are: > > * Is this an application that is commonly provided by bare-bones desktop > envs? (Yes: +1; both because it means it duplicates features in other envs > but also because it is probably *expected* to be there by users) > * Is this an application that requires a large number of assumptions about > the desktop env? (Yes : +1) > * Can you use the desktop env without it? (Maybe: +0.5, Not really: +1) > * Is this an application that has significant usage in other desktop envs > today? (No: +1) > > So for kmix the answers might be: yes, no, no, maybe: 3.5 points > KDE NetworkManager: yes, yes, no, yes: 4 points > Dolphin: Yes, No, Maybe, Yes: 1.5 points > For KSnapshot: no, no, yes, yes: 0 points > > It becomes more easy to pick which apps “belong” and which probably don’t > using these questions. It’s still a matter of judgement calls, but > personally I find those 4 questions helpful. Definitely seem useful, makes me wonder who makes the call for such a move in Workspaces as clearly the answer to those questions can be somewhat personal (I'd answer differently for KSnapshot for instance), we could easily end up with disagreements... and so needs conflict handling which is generally done by the maintenance team of the product. I'm not sure we really have that for Workspaces yet (might be wrong impression though, been disconnected from Workspaces dynamics quite a bit). > > * 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? > > Perhaps we should keep Frameworks its own thing: API stable libraries that > follow all the requirements of a framework and have a clear tier definition. Yes definitely. That said the lines might get blurry once we get things like kdepimlibs under the KDE Frameworks roof as the number of domain touched will grow. Would it be shocking to have a cddb framework? Not necessarily. For KIPI I'm not sure... We might be sitting on a product definition time bomb. When do we stop adding frameworks? Is there a domain it shouldn't cover? At that point I don't think we have a good answer to that. For quality requirements OTOH we have good answers, and it's being even improved over time, we need the same for its feature set. > Other libs would live somewhere else without all these requirements. I don’t > know what that would be called :) Well, just like applications which would be released on their own schedule such libs could live on their own too. If it's "all Extragear" (blatant oversimplification) then libs can be treated in the same way IMO. > > * 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 other bits-and-pieces > > scattered around. Can we split the apps off to stand on their own > > repos in Extragear, and merge Examples
Re: [kde-community] Plasmoids and Apps - was - Re: Applications in KDE Generation 5
On Thu, Jan 16, 2014 at 10:43:42AM +0100, Aaron J. Seigo wrote: > We’ve had plasma-windows for ages now which runs plasmoids in their own > independent window like a mini application. For apps like ksnapshot and kcalc > the results would be identical or nearly so (kcalc would require support for > putting a menu[bar] somewhere, or reorganizing how those particular features > are presented). How would they look and feel? I'm not overly fond of the way widgets in plasma look (and if I had Eike's super vision I could probably point out what's wrong and fix it, probably something with the alignments and gradients), and they don't follow my normal widget styling. On a related note, the new plasma based lockscreen is still not up to par with the old non-plasma one (keyboard focus is still flaky I just noticed again, for one, and widget styles that try to draw a background needs to add a hack). So I think it's a bit naïve to think that it will be an easy task to make stand-alone plasmoids that can replace the normal applications. So while I don't really see the reasons for replacing applications like KCalc with stand-alone plasmoids, I see a couple of reasons not to. -- Martin Sandsmark ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Plasmoids and Apps - was - Re: Applications in KDE Generation 5
On Friday, 2014-01-17, 12:05:51, Sebastian Kügler wrote: > On Friday, January 17, 2014 09:21:29 Kevin Krammer wrote: > > Right. Or I imagine that there could be a PlasmaAppletView class or > > similar > > that can be used in a small launcher executable > That's pretty much what plasma-windowed does (modulo some setup of > KDeclarative, etc.). Disadvantage of a binary-per-app would be that it > requires compiling, with a generic "app shell loader thing" (like plasma- > windowed), you can write whole apps without compiling anything, so making it > really easy to write, and deploy, no setup of development environment, etc. Right. I was mainly addressing this from the point of an existing application such as KCalc, i.e. an option on how to provide the usual application. As an alternative to a plasma-windowed based Exec line, with the additional potential to do some UI around the Plasma based content, e.g. menus. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Plasmoids and Apps - was - Re: Applications in KDE Generation 5
On Friday, 2014-01-17, 19:48:14, Marco Martin wrote: > On Friday 17 January 2014, Sebastian Kügler wrote: > > That's pretty much what plasma-windowed does (modulo some setup of > > KDeclarative, etc.). Disadvantage of a binary-per-app would be that it > > requires compiling, with a generic "app shell loader thing" (like plasma- > > windowed), you can write whole apps without compiling anything, so making > > it really easy to write, and deploy, no setup of development environment, > > etc. > > > > In order to make it easy to start them from the commandline, a one-liner > > script installed into the PATH would be enough. (Done that before, works > > like a charm.) > > btw, this is something worth exploring not only for having plasmoids as > apps, but also from qt iirc they are thinking about an alternative to > qmlscene (the command line tool) that they would advertise as shell for > running simple full applications, so some 3rd party app that uses the thing > may come up I think this tool is simply called "qml". Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
