What is my goal / intention in doing this? I hope to get many of us thinking about or at least aware of really important issues that require consensus and shared action. I hope to start a conversation on each of these topics that can take on a life of its own, with each blog entry being the spark that lights a bonfire of discussion for us to share and illuminate our surroundings with. I hope that others will also find some inspiration in this process and subsequently find the time and words to do a similar exploration within the KDE communities they are in. The ultimate goal is progress and a happier, healthier, better, stronger, $SUPERLATIVE KDE.
What will follow are not promises or even predictions about what KDE is going to do in 2010. Instead, I'll be writing about things that we should probably put thought and attention to in the coming year. Some of these things are already getting attention and effort, some of them aren't. Some are outright challenges we face, some are simply opportunities.
Some individual teams within KDE are also doing planning and project introspection on their own. I saw such an email thread on the KDE Edu list just the other day, in fact. This is absolutely terrific to see as it can only help improve community cohesion and the project's overall quality. Since we are often best positioned to understand and be able to address the issues relating to our own projects, such efforts can be invaluable. Of course, when we feel we need a helping hand or that some outside perspective would be useful, we have the great KDE community to fall back on by asking for needed help or even just using others as a sounding board for our thoughts.
There are also topics which concern all of us in KDE and which can be helped by addressing them together, and this is the genre of topics I've tried to stick to here. Which is to say, this isn't going to be a laundry of list of detail items like "Plasma Desktop needs a better ZUI". I don't think such lists are overly useful outside of project level discussions: they tend to become too divided, too full of well intended but less than helpful input and too chaotic due to usually covering too many bases at once (or not enough). I've also chosen to skip over some topics that are already well in hand and which I think are set to have a great 2010 already.
The list of topics isn't exhaustive, either. In trying to keep this a manageable set of topics and sticking to ones with the biggest "footprint" on the project, I've skipped some issues such as "printing", even though it does need more investment put into it and is quite important, and "Kontact" which should have a great 2010 if the expected targets are hit. I've also stayed away from topics that aren't completely within KDE's control alone, such as the critical "how do we achieve a reliable top-to-bottom platform within the Free software operation system ecosystem?" challenge; the issues on my list below are KDE's alone to succeed or fail with, to pay attention to or ignore. This is why "multimedia" isn't there, for instance, as the challenges surrounding that are deeply rooted elsewhere even though they affect us and need our attention.
There are also some teams and topics where there just isn't anything more to say than "keep up the great work, can't wait to see what you come up with in 2010" (yes, I'm looking at you KDE Games, Amarok, Dolphin, Digikam and so many others :) and so also aren't on the list. In fact, given the size of KDE and the relatively small number of "hot topics", it was evident to me as I was crafting it that there are many more things going very right in our world than are not. Yes, we have challenges to address, but we have many more successes to show alongside those challenges.
So ... now that I've said what I won't be talking about in my usual long winded fashion, here is the list of topics that I will be taking on in alphabetical order:
- Deployability
- Device spectrum
- Git
- Identifying projects in need
- KOffice
- Managing the wave of new apps
- Mobilizing/Enabling KDE Supporters
- Nepomuk
- Promo Messaging
- Scripting and dynamic language support
- Silk
- Quality
- Web Presence
- WebKit
Starting tomorrow, I'll be publishing a blog entry for each of the above at the rate of two a day until we're through the list. Hopefully it will be an interesting ride for everyone. :)
28 comments:
counting from 0...how very programmer of you.
14. Optimize window handling
Read KDE Brainstorm and you'll see a lot of suggestions for knotify, windowlists, systray, menubars, titlebars... Look at the current implementation: It's inconsistent. I think this task is very important, we should not forget the core-tasks of a desktop-environment.
15. KDevelop
Comments:
Sciprting languages:
There will be QtScript-support, Falcon-support and Guile-support, Ruby and Python are working very well. There's active developmentand there are great frameworks. (also Qyoto becomes better)
Don't worry about language support!
Integration into applications is not yet perfect. Konqueror, Akonadi, Kate and KDevelop have great plugin-systems, but there aren't any plugins written in scripting-languages, although it should be somehow possible using the pluginfactories.
KOffice:
There's real innovation in KOffice: The great user interface and the plugins. But it is not yet capable for serious applications. For text-editing it should combine the best things from (Open)Office, LaTeX, LyX and TeXmacs. Adapting some (Open)Office-elements is not enough to become comfortable for everybody. Concretely: KOffice needs features like tocs, glossars, footnotes, new input-methods, LaTeX-import, better justification... There won't be real innovation in writing Office-import-filters but in those features.
The User
@Roman Shtylman: is there some other number to start at? ;)
seriously though, i will often count from zero in normal conversations when i'm listing things and that does indeed get an odd look on occasion from my non-programmer associates ;)
zero just feels ... right. it's the zeroth element. oh no, i'm starting to get a feeling reminiscent to the "what year do centuries and decades start in" conversation. *sigh* silly pedants are we. ;)
@Jonathan: 14 is something that falls into the "needs to be addressed by the individual project(s) involved" category. if i included those kinds of things, i could go on and on and on and on ..... i purposefully kept myself to big issues that are likely to have a big across-KDE-affect or require across-KDE-effort.
KDevelop very nearly made my list as well ... but it's really in the same category as, say, Kopete: it's an individual app that needs a good release in 2010 and more attention paid to it than it gets right now. but that's not a KDE-wide strategic issue. these are the kinds of things we/i deal with directly with the team involved.
maybe i should do another blog entry about "important strategic issues within KDE that involve secific project teams"? ;) a challenge to those kinds of blog entries is that it's really easy to step on toes and i find it's much more productive to work with the project itself, e.g. KDevelop, in defining and addressing the issues and letting the project insiders then articulate the results.
"Don't worry about language support!"
i'm not worried about the availability of it; not at all. in fact, i think we're in a pretty good place in that regard as you note. as you will see (hopefully, anyways :) in the blog entry that covers scripting, my thoughts deviate towards supporting, encouraging and boosting the *use* of these options. that's something we're not quite there with yet.
"There's real innovation in KOffice: The great user interface and the plugins. But it is not yet capable for serious applications."
depends on the application in question. for most of them, i agree. for some of them, like Kexi or Krita, i would differ. but again, this will be more about the potential impact of KOffice across the KDE universe and what we might want to do in support of that. iow, how do we get those needed features? what is there to be gained with a strong KOffice? etc... :)
thanks for you input, it's evident you have put some thought into it :)
Beware: Ranting ahead!
KDE has awesome tech, yet the software feels very sloppy in some areas.
KDE SC 4 is now two years old and there are still so many areas where icons are missing, 1990's "Yes/No" questions are shown, etc.
Instead of drawing much-needed icons to finally complete the set, the artwork team choses to redo the window decoration each release. WTF?!
You programmers often don't even look into the oxygen icon folder if there is a fitting icon. Just some stupid placeholder is dumped in the code. Then people like me need to jump in and tidy up the mess (at least I try to -- often I just don't understand the code and how to add icons in specific places).
Sometimes I wonder if the programmers actually use KDE SC...
What about a good robust communication / IM program, I know kopete is there but it has been found wanting in terms of having any voice/video capability.
I think it has been consistently postponed since 4.0 days and now it is 4.4 and there is still nothing, how can KDE become a top notch platform without kopete getting better.
Even Gnome has cleaned up their act with empathy. Do you think in 2010 I will be able to get rid of skype?
I also hope that KCall or even a new VoIP-App will reach a usable state for KDE (using telepathy would be nice).
Another important step is the port of KDE-PIM (KMail, Korganizer) to Akonadi. I´m looking forward to. I like KMail, but sometimes I really hate it.
I would like to point out that instead of focusing on *new* things like nepomuk, git, koffice, webkit, new applications, maybe others it's rather important to stop for the moment and try to realize what's going with already-there parts of KDE.
Those things I mentioned won't be ready during 2010 to provide rock-solid experience (maybe git stand out here) even in a very optimistic scenario. KDE4 is already there for a few years and it's time to talk about the present than the future
@kamikazow:
"KDE has awesome tech, yet the software feels very sloppy in some areas."
then you'll enjoy the blog entry for point 11.
"KDE SC 4 is now two years old"
KDE's software represents a massive code base, some of which is more actively worked on than others and some of which is worked on by people who have an eye for these things .. or not.
KDE3 was really no different, btw, though i think we're at an improved point. just not perfect yet. and we've been dealing with some mildly more pressing issues in the last year. those are behind us, by and large, at this point, so ... well, you can just wait for the blog on point #11 to hear more about my thoughts on that ;)
"Instead of drawing much-needed icons to finally complete the set, the artwork team choses to redo the window decoration each release. WTF?!"
i think you'll find the definition of "much-needed" is plastic. you're also making the mistake of thinking that it's a monolithic art team. the person working on the style and window deco is a new *software developer* who wasn't involved at all previously and who *develops software* not draw icons.
now, that said, there was a huge amount of work done to the icon theme. i update the oxygen set on a regular basis from svn and see new additions all the time. are there more icons to draw? yes. are there more icons being drawn? yes. so 4.4 is an improvement over 4.3. are the artists maintaining their quality standards as they do so, rather than just press to rush through to whatever artificial end point we set in the ground for them? yes, and that's the most important thing here.
"You programmers often don't even look into the oxygen icon folder if there is a fitting icon."
generalizing people into one big group is unfair and can be pretty upsetting to people in that group that don't deserve the criticism. it tends to make even your would-be allies not want to cooperate very much.
part of working in a large team is having to deal with various people's strengths as well as their weaknesses. it's no secret that many software developers aren't great artists and often lack a keen eye for aesthetics. that's just how it is.
and so we get people who DO have those abilities (who have different weaknesses) to fill in those gaps.
so instead of complaining about it, let me suggest this: when you fix something, you're filling in the weak points of another person in our community; that person (or another) is filling in your weaknesses as well. it's just how it goes, and the end result is something better for everyone.
view your work as an important bit of saving grace to the end product, your contribution to something being made better than it would be without you. it's a rather more healthy viewpoint than considering it to be working against those you are working with, especially when it comes to natural weaknesses (e.g. aesthetics)
of course, it's not quite that dire either. if there's a place someone needs to improve, then demonstrate how that improvement can be made. write a blog on planetkde about, document it on techbase, etc and raise awareness. often people improve (though rarely perfect a natural weakness) simply by being shown some simple techniques and by being reminded of its importance.
"often I just don't understand the code and how to add icons in specific places"
you can always ask. #kde-devel on irc.freenode.net, kde-devel at kde dot org. people will be happy to help out.
"Sometimes I wonder if the programmers actually use KDE SC..."
yes, we do. i use it as my primary desktop system, even when i'm in front of people doing presentations. i let the audience know that, of course, and it's not always comfortable.
in any case, i don't feel that particular bit of your comment was particularly fair :)
@venky80: "What about a good robust communication / IM program"
i agree with your point about a good voice/video calling app being useful. however, in the blog post i noted:
"Which is to say, this isn't going to be a laundry of list of detail items"
and i meant it. such lists aren't useful as they aren't in context and so i won't be addressing that in these blog entries, even though this is an issue. it's an issue that needs to be discussed with the kopete team, however, in the context of kopete.
of course, the question is why hasn't this issue been given the attention it deserves?
well, see point #3 on my list.
"how can KDE become a top notch platform without kopete getting better."
honestly, i don't think kopete is a make-or-break application for KDE as a whole. now, that isn't to say it isn't important or that we don't care about individual applications. quite the opposite. but we need to keep perspective as well otherwise it becomes very hard to make rational strategies.
the biggest hurdle in the kopete issue is why more people aren't working on it. remember that we aren't a top-down structure where someone gets to throw extra resources on things. it's a bottom-up and laterally-cooperative venture. again, you'll want to read my blog on point #3 in the list, i think.
"Even Gnome has cleaned up their act with empathy."
having looked at what was there before empathy and what empathy is now, and without being overly critical or harsh about things: you are painting that picture just a little too brightly, i think.
there has been a marked tendency in GNOME to replace one app with another as soon as the previous app stalls or gets "too complicated" for the audience they have in their minds. i don't think that strategy has paid off well at all, and empathy hasn't been a pure bed of roses.
(that isn't to say that the solution isn't sometimes to add a new app or even replace an old one. but it needs to be done with care and clear purpose.)
"Do you think in 2010 I will be able to get rid of skype?"
i honestly don't know. i hope to figure such things out, however .... which is the point of blog entry topic 3 :)
@smurfy: "I also hope that KCall "
there will be tons of all kinds of new features and even new apps that appear in 2010. maybe KCall will be part of that rising tide, i don't know for sure yet. but other than being relevant to blog topic #5, this gets filed under "project specific, need to take it up with the KCall people"
keep in mind that KDE is really, really large these days and such "we should" lists that covers every app in that kind of granularity would be insanely large. the same is true of software that comes from, say, Apple and Microsoft, btw. :) it's an issue with scale ... so i won't be talking much about specifics at that granularity. i do hope that KCall both gets more traction and that the developer(s) working on it share their thoughts and progress with us more.
"Another important step is the port of KDE-PIM (KMail, Korganizer) to Akonadi."
agreed; and that one nearly made my list because Akonadi integration touches a large number of key points in and around KDE. however, i think 2010 will be a good year for Kontact/Akonadi and decided that it is better to let the Akonadi team have some space over it. i already took them task last year about communication, and too much pressure is never good, particularly when a team is generally on track as they are.
:)
@vtokarev: "Those things I mentioned won't be ready during 2010 to provide rock-solid experience"
when it comes to WebKit, Nepomuk, Git and the new apps that have been arriving, i simply can not agree with you.
QtWebKit is finally mature in Qt 4.6 and we have KDE integration in KDE SC 4.4. it's also an issue we've been dealing with, or not dealing with as the case may be, since the KDE 3 days.
Nepomuk has been used by KDE applications for a couple years now and with the ontology standarization and Akonadi's commitment to it becomes a non-negotiable part of things. note that on-disk file indexing is one small part of Nepomuk and not even the really interesting bits. but Nepomuk is an important part of the KDE of the here-and-now and needs to be considered so that it doesn't end up on this list again in future years.
KOffice as a whole is iffy to make the leap to "ready for prime time" mark in 2010, though parts of it are absolutely there (Krita, Kexi, in particular) and they are poised to make huge leaps this year if given the appropriate attention and space to do so. also remember that KOffice started in the late 90s; it is one of our "already there" bits that needs some sort of closure.
as for the "new apps", these are mostly things like the "new" finance applications that recently joined KDE (Kraft, KMyMoney, Skrooge) but which each have great histories behind them. the other half of that is new apps by existing communities and the challenges that brings up ... including the impact on "what already exists".
you are asking to pay attention to what already exists, and to that i agree. i fact, posts 0, 3, 4, 5, 6, 8, 9, 11 and 12 will be all about that, in particular point 11: Quality.
so we are generally on the same page here: the list i've compiled is overwhelmingly about things that already exist and most of those things have existed for quite some time.
instead of jumping to conclusions about what i'm thinking, i'd like to request some patience on your part and that you read each blog entry as it appears. i think you'll find that your comment was unnecessary, since i am advocating a looking to the "now" position.
Sorry Aaron, but what Plasma really needs is a multi-process design.
I know it's hard to do that and all, but there is no way around it if you want to get it fully stable.
Maybe we can come up with a solution for making this painless, as we need something similar in Amarok too. I'm starting to contemplate a little helper library/class for handling the IPC nicely. We'll see.
Anyway, good blog, as always :)
--
Regards, Mark
@Mark: "but what Plasma really needs is a multi-process design."
not sure what that had to do with the blog, unless you feel that that's a critical, pan-KDE issue? :)
"I know it's hard to do that and all, but there is no way around it if you want to get it fully stable."
it's not just "hard" it's ridiculous.
"I'm starting to contemplate a little helper library/class for handling the IPC nicely."
the IPC is not the hard part. managing the events and the painting is. with a MP system there will be so much locking, so much context switching and/or so much data being passed around that it's really infeasible, esp as it wouldn't do jack for crashes in Qt or any of the other pieces that would remain active in the main process. when we actually look at where the crashes are right now, it becomes evident how little there is to gain (and how much pain there would be go this route).
not to mention it would mean heavy work on every single widget we have right now as they are all written to QGraphicsWidget ... which also isn't designed at all (and for good reasons) for MP.
there is nothing meaningful in common between MP apps like Chrome and an application like plasma-desktop. but that hasn't stopped people from making comparisons or thinking that it's therefore a solution.
as i've said before, DataEngines could certainly move to their own process (which would have a few nice benefits, actually) and that would be painless. that won't do much for stability, however, as it isn't in the DataEngines that the problems exist.
when we look at where the actual issues lie, it becomes apparent that hardening all that new code in Qt is critical (MP or not, this needs to get done for stability) and scripting steps in for where most of the rest of the crashes end up.
I would like to add: - slim.
Qt 4 give us a lot of promisse of faster sppeds and less resource usages in KDE, but reality is a bitch, and KDE 4 is hell slow. Even if it is usable on machines such as an Asus eee 701, it is long away from the promisse and a galaxy in distance from other DEs as lxde or iceWM.
For some machines, fancy graphics, widgets are not needed.
Worse thing is new services like neopomuk that create HUGE databases in a very small HD and take almost all resources to itself while indexing.
I remember KDE 3.4 was almost exclusive for optimizations, can't we get a speedy 4.6, please? :)
Meanwhile, I'll format my eee today and remove KDE4 from it. *shame* :-(
When you get to #3, don't forget the sadly-abandoned(?) Quanta+...at the moment, it's the only major application that *I* can think of that I still miss in KDE4.
(which is otherwise running quite nicely indeed on my Eee 901...)
Not entirely sure what you mean by "device spectrum", but I'm guessing you mean hardware support and interfaces? If so, I'm looking forward to that post (bluetooth devices are giving me fits now that I'm trying to actually use them - if kbluetooth4 is going to let me connect to my bluetooth GPS for geolocation in Marble I'll be a very happy nerd.)
@aseigo
KOffice:
I don't know a lot about kexi, I think it uses some scripting-stuff, but I do not know if it's innovative. What do you think about it?
In my point of view Krita has a better ui than Gimp and Photoshop and it has a powerful-plugin-structure: Flake-plugins, stuff for efficient filters and shaders and Kross. There are very flexible features like filter-layers ("smart-filters" in ps), clone layers and brushes supporting a lot of fine-tuning. Sometimes it's a bit too slow. But when you can live without some very special features from PS or Gimp, Krita is seriously usable.
Scripting languages:
They should be more widely used. When there would be working examples for Ruby- and Python-plugins for Konqueror I think there could be a lot of new development. Imagine KHotNewStuff for Konqueror-plugins.
Git:
Is there already a timeline or something like that?
Counting from 0:
That's very useful, I have just to keep a pointer to the first of your aspects. Then I can add the index and dereference it to read your item. I do not have to worry about any +/-1. :)
@kamikazow
I hope the new IconInserter-KTextEditor-plugin will encourage people to place icons in their code. I had already started to use it, before I finished it. ;)
@venky80
Few days ago there was a planetkde-entry "implementing webcam-support for Phonon", you should not give up, there may be webcam support in Kopete this year. And there's a special KDE-VoIP-application.
@Mark
You should read this.
It would be applicable for Plasma, Amarok and maybe others.
The User
@Epicanis
What do you mean, when you say "Quanta+ was abandoned". KDevPlatform+KDevelop+Quanta is under very active development, although they would need some more developers. There's a great PHP-plugin, XML-support becomes better, there are experimental debugger-plugins for PHP and JS... And there are not only advancements for web-development, it's even done in a very effective way: KDevPlatform provides a great plugin structure and a simple API and the different applications using it (KDevelop, Quanta, Kile and Gluon Creator I think) can benefit from each other. (There are a lot of negative examples: Amarok+Bangarang, Konqueror+Rekonq+Arora, KMail+Mailody...)
@Aseigo
WebKit:
There is some support in KDE 4.4, but it is still worse then KHTML. It will not be a perfect replacement, until all important features of KHTML are ported:
-Native KDE Widget (I do not want to miss KLineEdit, KPushButton etc., they look and behave different)
-API-compatibility, it should be possible to use KHTML-KPart-plugins by changing the word KHTML to WebKit in their source-code (this implies some stuff, look at the available plugins)
-KWallet-integration (Is it already usable? I don't know)
-Of course stability and performance ;)
@Iuri Fiedoruk: "KDE 4 is hell slow."
then either the packaging was poorly done or the graphics driver sucks. yes, we could stick with 1990s look, feel and features and everything would be just fine. i could also using gas lighting in my house and real lead pipes (yum, lead! :), but i choose to move on to better things. unfortunately for us, in the x.org world driver writers were not ready for that.
"For some machines, fancy graphics, widgets are not needed."
you can turn it all off.
"Worse thing is new services like neopomuk that create HUGE databases in a very small HD and take almost all resources to itself while indexing."
you can turn file indexing off as well; Nepomuk can still be used for the other things it offers (usually hidden behind application features) without the file indexing. i've done that before; there's a checkbox in system settings for it.
"I remember KDE 3.4 was almost exclusive for optimizations, can't we get a speedy 4.6, please? "
there was a lot more in 3.4 than optimizations, and every 3.x release provided significant optimizations. we've been doing the same in the 4.x releases as well, with significant performance improvements across the board ... except for some x.org drivers, some of which have even gotten _worse_ not better (hello, Intel). and that's something we just can't do much about from KDE.
@Jonathan: http://forum.kde.org/viewtopic.php?f=83&t=49042&p=142179
that is, unfortunately, not even remotely applicable to plasma-desktop. there isn't a simple one sentence answer as to why as it isn't a simple set of challenges. i've looked at the possibility as an option, long before people got Chrome-fever, and ruled it out as a realistic option.
.. as for the rest of your (and Epicanis') questions, they'll be answered in the individual blog postings
@Jonathan last time I checked (which was admittedly months ago) it appeared Quanta+ porting to QT4/KDE4 was being sorta worked on by one person who was really too busy working on something else to do much with it. After watching for it since the release of KDE4.0 for so long I had given up. The Quanta+ website still doesn't appear to have been updated in half a decade (2005), which doesn't help.
Since you mentioned it, I went and looked and found:
http://websvn.kde.org/trunk/extragear/sdk/quanta/
which, as you say, appears to be in active development.
So - thanks for proving me wrong! Hopefully this means I'll be able to install it alongside KDE 4.4 when it comes out in a few weeks.
@Aseigo
What does this have to do with Chrome?
@Jonathan: it was only after Chrome was released and it's MP approach got a lot of (well deserved) discussion that we started getting inundated with the "plasma should be multiprocess" suggestions. i don't think that came up even once prior to the "Chrome is MP" stuff, and i even predicted to some friends that we'd start to get requests for that in plasma-desktop even though it wasn't applicable.
the idea of MP in a web browser is really, really good.
the idea of MP in a desktop shell, esp one that does what plasma-desktop does, not so much.
oh well :)
it's interesting, btw, that whenever another product comes out with something, some people will inevitably clamour for its inclusion in KDE software as well. whether it's Vista's app menu, MacOS's dock or Chrome's MP .. it's the same pattern. sometimes it is a good idea to do so, but more often than not it's just "i saw a good idea, let's see if we can't apply it everywhere!" thinking :)
Looking very much forward to reading all these articles. Please don't forget to link them from the list in this article so it's easier to find all of them later from this one page. Thanks!
@DigitalFreedom: good idea, i'll do that :)
Aseigo wrote:
"generalizing people into one big group is unfair and can be pretty upsetting to people in that group that don't deserve the criticism. it tends to make even your would-be allies not want to cooperate very much.
part of working in a large team is having to deal with various people's strengths as well as their weaknesses. it's no secret that many software developers aren't great artists and often lack a keen eye for aesthetics. that's just how it is."
I'm sorry, but that's just an excuse. You can't tell me that the author of KCalc was not able to find the "calculator" icon for the options window.
The "Mouse Plugins" author wasn't able to find a "window" icon for the "Switch Window" action?
The "Empty Trash" author can't find a trashcan icon? https://bugs.kde.org/show_bug.cgi?id=209454
The Akonadi authors can't find the Nepomuk icon for https://bugs.kde.org/show_bug.cgi?id=221592 ?
KWin authors can't find a "window" icon for killer_helper? https://bugs.kde.org/show_bug.cgi?id=210172 (Heck, nobody of them even looked at this bug. It's still "unconfirmed" after two months!!)
Aseigo wrote:
"you can always ask. #kde-devel on irc.freenode.net, kde-devel at kde dot org. people will be happy to help out."
As a non-programmer, I won't understand the answers anyway. Anything more complicated than "KIcon" (in .cpp files) or "Icon=" (in .desktop files) is above my skill level.
My main work within KDE is actually translating K3b to German. I only fix the icons, because apparently I'm the only SVN account owner within the whole KDE community who gets a rash whenever he sees that ugly question mark placeholder icon....
The app's author -- who knows the code inside out -- could fix such problems within 30 seconds. It takes someone like me waayy longer than that (if I even manage to do it).
Aseigo wrote:
"yes, we do. i use it as my primary desktop system, even when i'm in front of people doing presentations. i let the audience know that, of course, and it's not always comfortable.
in any case, i don't feel that particular bit of your comment was particularly fair :)"
Yes, maybe I'm not fair. I wasn't pretending to give a fair analysis when I begun my post with "Ranting ahead", though.
Maybe I'm missing something, but e.g. so many people report Kontact crashes (https://bugs.kde.org/show_bug.cgi?id=193514 -- check the amount of dupes). Why aren't crashes like these the first thing to get fixed? Are devs so used to running trunk versions that they just don't expect stability? Are devs so used to question mark placeholder icons all over the place that they don't care to look into the oxygen icons folder?
Maybe I'm an evil troll, because I throw devs from so different areas within KDE into a single bucket, because I can't comprehend that authors of crashy apps with placeholder icons feel that it's OK the way it is...
Johnathan wrote:
"@kamikazow
I hope the new IconInserter-KTextEditor-plugin will encourage people to place icons in their code. I had already started to use it, before I finished it. ;)"
Great!
1. Code optimization
2. Bugs fixing
3. Code optimization
4. Bugs fixing
5. Code optimization
6. Bugs fixing
fixed for you.
Oh, people, come on: Maybe i'm a troll too, but can we discuss, if Aaron's list is correct, or if somebody feel, there are gaps etc. But, please don't discuss every special app, this is not the point here. I'm not a developer, so i'm interested in the direction of evolution of my favorite desktop, not in every single bug, which is mabye also posted in bugs.kde.org.
Hey Aaron, this post needs some page rank love ;) If you know what I mean.
(Complete the links .. always be explicit on the intertubes)
Post a Comment