This forum has been archived. All content is frozen. Please use KDE Discuss instead.
The Discussions and Opinions forum is a place for open discussion regarding everything related to KDE, within the boundaries of KDE Code of Conduct. If you have a question or need a solution for a KDE problem, please post in the apppropriate forum instead.

KDE dev priorities

Tags: None
(comma "," separated)
spoovy
Registered Member
Posts
49
Karma
0
OS

KDE dev priorities

Sun Oct 10, 2010 6:36 pm
I stopped using 4.x at about 4.4.2 after finally losing my patience with it. We all know the many reasons why end users like me are so frustrated with 4.x so I won't repeat them again (much). But I decided to try 4.5 today, as it is now at 4.5.2 and I gathered 4.5 was mainly a bugfix release anyway. I can't say I had high hopes, but I had hopes anyway. I will try not to go on too much of a rant because I know that it really doesn't help, but I need to rant a little bit i'm afraid in order to make my point.

I have had about 8 or 9 plasma crashes so far (in one afternoon) causing me to ctrl-alt-del each time. The whole desktop seems more complex than ever, yet still doesn't work. Little annoyances like popups that can't be turned off are still present, and it took me ten minutes to work out how to turn off the dreaded blue glow because for some reason this setting has been moved to a completely new location.

In the process of re-re-re-learning the systemsettings GUI I accidentally changed my desktop into a "newspaper format" or something like that, which didn't work in any way shape or form, and wouldn't let me change it back either. The cashew started flipping from top right to top left seemingly at random..... etc.....etc....etc....

I can barely believe that I am still posting rants like this after so long, but the serious question behind this rant is - why do the KDE devs seem so obsessed with messing around with irrelevant GUI details rather than make the damn thing work in the first place? We are at 4.5.2 for christ's sake! how long does it take to make a desktop that doesn't regularly crash for no reason?

And please don't reply by saying I should detail my problems and ask politely for help blah blah. Yes there is a time and a place for that, but there is a time and a place for this as well. What are the devs trying to do here?
User avatar
TheBlackCat
Registered Member
Posts
2945
Karma
8
OS

Re: KDE dev priorities

Sun Oct 10, 2010 7:25 pm
spoovy wrote:I have had about 8 or 9 plasma crashes so far (in one afternoon) causing me to ctrl-alt-del each time.

Did you post bug reports for the crash? Which widgets are you using?

spoovy wrote:Little annoyances like popups that can't be turned off are still present,

As I explained months ago, they can be turned off.

spoovy wrote:and it took me ten minutes to work out how to turn off the dreaded blue glow because for some reason this setting has been moved to a completely new location.

Yes, there was a reorganization of systemsettings because the old layout was dreadful. Some less-used oxygen settings were moved to a separate tool.

spoovy wrote:In the process of re-re-re-learning the systemsettings GUI I accidentally changed my desktop into a "newspaper format" or something like that, which didn't work in any way shape or form, and wouldn't let me change it back either.

What, exactly didn't work?

spoovy wrote:The cashew started flipping from top right to top left seemingly at random

That's really strange. Did you post a bug report?

spoovy wrote:why do the KDE devs seem so obsessed with messing around with irrelevant GUI details rather than make the damn thing work in the first place? We are at 4.5.2 for christ's sake! how long does it take to make a desktop that doesn't regularly crash for no reason?

You are assuming that they aren't concerned with making it work. I follow the plasma-dev mailing list, I can tell you that they are very concerned with making it work.

However, for every person that is complaining about crashes, there is a person complaining that their favorite pet feature hasn't been implemented yet. Everyone has different demands, the developers have to balance everyone's desires. Even in this very post you are complaining that your pet feature hasn't been implemented (even though it had) at the same time you complain about them not focusing on "making it work". You can't have it both ways.

Did you post bug reports explaining your problems? If not, then how do you expect them to get fixed? I have KDE 4.5 installed on six computers and I have never seen anything remotely similar to any of the bugs you are seeing. That means that developers may not be seeing them, either. They can't fix bugs they don't know about. If you aren't willing to report the bugs, they aren't going to get fixed.

spoovy wrote:And please don't reply by saying I should detail my problems and ask politely for help blah blah. Yes there is a time and a place for that, but there is a time and a place for this as well. What are the devs trying to do here?

I can tell you what they can't do, and that is read minds.


Man is the lowest-cost, 150-pound, nonlinear, all-purpose computer system which can be mass-produced by unskilled labor.
-NASA in 1965
spoovy
Registered Member
Posts
49
Karma
0
OS

Re: KDE dev priorities

Sun Oct 10, 2010 7:56 pm
What a surprise, a reply from Blackcat which completely fails to even address the question.

It is perfectly reasonable to ask why new features are appearing while the basics are still failing. In my field (civil engineering) these types of issue crop up regularly. They are issues about priorities within project teams, and they are up for debate. Why is it somehow forbidden to even discuss these types of issues when it comes to the KDE project without being immediately attacked by a mod.

I am and end user, and presumably therefore the person that KDE is designed for; I do not have to defend every little aspect of my personal experience in order for it to be valid.
User avatar
TheBlackCat
Registered Member
Posts
2945
Karma
8
OS

Re: KDE dev priorities

Sun Oct 10, 2010 8:53 pm
There is nothing wrong with discussing it. The problem is when all you do is rant without letting developers know what the problems are. The problem is when you complain about something not getting done and then a few lines later urge them not do it, or when you complain that something is not getting done when shortly before you were telling them to focus their attention on something else. The problem is when you complain that something hasn't been done without even asking whether it had been done in the first place.

There are constructive ways to discuss a subject. This is a textbook example of how not discuss something constructively. Your demands are self-contradictory. Your comments lack sufficient detail that anyone could actually do anything about them.

You whole post is a great demonstration of why what you want to have happen is impossible. They cannot focus on fixing bugs they do not know about. Your entire argument assumes that the developers are actually aware that the problem you are experiencing exist, but your apparent refusal to inform them of the problems makes this unlikely.

To put it in a more concrete terminology, you are assuming facts not in evidence. You are assuming that developers are not focused on making things work as well as possible. Before we can have a discussion about whether the developers are focused on this, it must first be established that they are not focused on it. You have provided no reason to draw this conclusion.


Man is the lowest-cost, 150-pound, nonlinear, all-purpose computer system which can be mass-produced by unskilled labor.
-NASA in 1965
samhain
Banned
Posts
201
Karma
1
OS

Re: KDE dev priorities

Mon Oct 11, 2010 10:07 am
TheBlackCat, you are (still) wrong. You try fixing user problems by micromanagement, but miss the big picture. KDE4 is still way behind KDE3.5. Debian squeeze will soon become stable, with KDE4 forced on all lenny users with KDE3.5. Can you imagine what's up ahead? The "ranting" that took/takes place in this forum is a light reflection of things to come.
DaSheep
Registered Member
Posts
95
Karma
1
OS

Re: KDE dev priorities

Mon Oct 11, 2010 1:54 pm
samhain wrote:TheBlackCat, you are (still) wrong. You try fixing user problems by micromanagement

What else can we do? Rant? Nag? Rant really hard? Well obviously that's not working out ...
Perhaps TELL what's so bad about KDE4 in CONCRETE examples!

Topics like these have zero use but drive developers away to other projects.
If you want to get something fixed in FOSS you either do it yourself (yes, I said it, again) or notify the developers of bugs and make friendly suggestions.

KDE4 is still way behind KDE3.5

You keep on saying that, please be more concrete, give specific examples. Otherwise there is nothing we can do.

Debian squeeze will soon become stable, with KDE4 forced on all lenny users with KDE3.5.

If debian considers it stable it probably is, so it can't be that bad.
samhain
Banned
Posts
201
Karma
1
OS

Re: KDE dev priorities

Mon Oct 11, 2010 2:12 pm
What else can we do? Rant? Nag? Rant really hard? Well obviously that's not working out ...
Perhaps TELL what's so bad about KDE4 in CONCRETE examples!
[...]
You keep on saying that, please be more concrete, give specific examples. Otherwise there is nothing we can do.

Install KDE3.5 on maschine A, install KDE4 on maschine B. Compare -> You got your answer. Hint: look at KPIM.

If debian considers it stable it probably is, so it can't be that bad.

Debian testing has KDE 4.4.5 with it. Unstable has 4.4.5. Does that tell you something?
User avatar
TheBlackCat
Registered Member
Posts
2945
Karma
8
OS

Re: KDE dev priorities

Mon Oct 11, 2010 3:18 pm
samhain wrote:Install KDE3.5 on maschine A, install KDE4 on maschine B. Compare -> You got your answer. Hint: look at KPIM.

I've done that, and KDE 3.5 seems way, way behind to me in every way.

samhain wrote:Debian testing has KDE 4.4.5 with it. Unstable has 4.4.5. Does that tell you something?

I don't know, why don't we see what they say about it

As Squeeze has been frozen, Debian will ship Squeeze with KDE 4.4.5. Unstable repos will have 4.4.5 too until Squeeze release. KDE 4.5.x will be available via other repo some time later.


Man is the lowest-cost, 150-pound, nonlinear, all-purpose computer system which can be mass-produced by unskilled labor.
-NASA in 1965
User avatar
anda_skoa
KDE Developer
Posts
783
Karma
4
OS

Re: KDE dev priorities

Tue Oct 12, 2010 7:42 am
samhain wrote:
What else can we do? Rant? Nag? Rant really hard? Well obviously that's not working out ...
Perhaps TELL what's so bad about KDE4 in CONCRETE examples!
[...]
You keep on saying that, please be more concrete, give specific examples. Otherwise there is nothing we can do.

Install KDE3.5 on maschine A, install KDE4 on maschine B. Compare -> You got your answer. Hint: look at KPIM.

I think this is exactly the problem montfras was pointing out: "Compare -> You got your answer".
Because you can compare all day and not find a single difference or compare all day and come to the conclusion that your usual workflow is now easier or better supported or compare all day and find your workflow being more difficult.

Software usage, especially of multi purpose components, depends a lot on how individuals perform certain tasks.
Take something very simple as an example: copy&paste. Lets say copy&paste options are removed from the context menu, all people using keyboard shortcuts or "Edit" menu won't even know, people soley using context menu for copy&paste however will be completely stuck.

So "see for yourself" makes only very little sense as it will almost never end in the same discovery you might have found.


samhain wrote:
If debian considers it stable it probably is, so it can't be that bad.

Debian testing has KDE 4.4.5 with it. Unstable has 4.4.5. Does that tell you something?


It tells us that Unstable is frozen due to the freeze of Testing in order to prepare the next Stable release.

Otherwise Unstable would be at 4.5.2 now.


Cheers,
_


anda_skoa, proud to be a member of KDE forums since 2008-Oct.
User avatar
Moult
Global Moderator
Posts
663
Karma
2
OS

Re: KDE dev priorities

Wed Oct 13, 2010 5:50 pm
I don't want to poke any open wounds here, but I would like to share my experience about KDE Developer priorities.

All developers, I believe, love to add new features and change things around. However as soon as one of their creations is "unusable" then making it "usable" is their first priority. Making it "perfect", which is obviously subjective, is unlikely to be the first priority, but "usable" is the top priority.

It sounds as though you have described a completely unusable system. It would therefore be safe to assume that other KDE users, and especially developers, are not experiencing the same - if they were, it would be fixed. It is your responsibility as a user to provide the developers with enough clues so that they can get a hint as to where your problem is, isolate it, and then fix it.

To use an inspirational example, I have been for a long time having a rather relatively slow system due to KDE. Running KDE applications on other WMs would fix the problem, so it was obviously KDE's fault. However "KDE is slow" is hardly a way to solve the problem. I got in contact with developers on the KDE and plasma IRC channels, and gave them the _hints_ to the problem, that slowdown only occured within KDE. Then following their suggestions, the next weeks were spent by me trying out different scenarios to help _isolate_ the problem. Once the problem was isolated, we had enough information to lodge a well-informed complaint on KDE's bugtracker. You can see it here:

https://bugs.kde.org/show_bug.cgi?id=242653

I recommend you look at the bug post. Developers care. Even if they don't experience the pain. Notice how much technical information I was providing.

When the bugfix was finally done, Hugo, the developer who was working on the bug wrote a blog post, available here: http://hugo-kde.blogspot.com/2010/09/pe ... -call.html

What was so amazing was the sheer magnitude of others who were also experiencing the same problem but just didn't a) know it existed, and just blamed it on KDE, b) experienced it, disregarded it and left KDE, or c) didn't take the effort to track it down and provide developers with useful feedback. This totaled 61 comments on that blog post alone. Now, I and so many other people who didn't speak up can look forward to a much better 4.6 (and 4.5.3). Even Aaron took a lead from this and helped remove a significant amount of slowdown with similar pixmap problems, shown here: http://aseigo.blogspot.com/2010/09/be-v ... xmaps.html

So as you can see, I turned a vague, rantable complaint like "KDE is slow", and turned it into a solution that helped so many others. I honestly have to say that what made it possible was not my persistence, but rather the persistence and continued interest of developers.

Developers care about you.

YMMV.


Moult, proud to be a member of KDE forums since 2008-Oct.
thinkMoult - source for tech, art, and animation: hilarity and interest ensured!
WIPUP.org - a unique system to share, critique and track your works-in-progress projects.
spoovy
Registered Member
Posts
49
Karma
0
OS

Re: KDE dev priorities

Wed Oct 13, 2010 11:04 pm
Moult, you wrote -

Code: Select all
It is your responsibility as a user to provide the developers with enough clues so that they can get a hint as to where your problem is, isolate it, and then fix it.


I agree; I understand the responsibility of end users in FOSS projects, and in the past I have submitted bug reports. But surely after five major point releases it is reasonable to expect that my fresh installation will work without regular crashes. I have installed on about 8-9 different machines over the last year or so and had broadly the same experiences on each, with 4.2, 4.3, 4.4 and now 4.5.

Which i suppose is the root of my question - what is a reasonable time for an end user to wait in order to get a useable product? How many bug reports does it take? Following your logic without monitoring and correcting developer priorities could result in a perpetually improving - and also perpetually broken - program. My suggestion (in the "Discussion and Opinion" forum remember) is that the devs' priorities are wrong.


And on the other note..
Blackcat - I was using examples of the bugs I have *most recently* experienced not to ask for help in solving them (which would be normal), but in order to make a wider point. I hoped that this much was obvious to all. Clearly not. Note that this is posted in the "Discussions and Opinions" forum - I would have hoped this was enough of a clue. Please never go into my industry, you'd still be diligently painting half the bridge with anti-rust paint two years after the other half had fallen into the sea.




edit - I just read this post-

Code: Select all
What else can we do? Rant? Nag? Rant really hard? Well obviously that's not working out ...
Perhaps TELL what's so bad about KDE4 in CONCRETE examples!


This is an terribly limited view. This is the "Discussion and Opinions" forum! As FOSS end users we can't vote with our wallets, so we must vote with our patronage, and voices. If all we are allowed to do is comment on the most low level technical problems, then we,the end users, are completely at the mercy of the mysterious dev project manager whoever they are. Ignoring your customers is a guaranteed way to dig a big fat grave for your company/project, or alternatively forever trap it in the realm of the people who are able and willing to submit bug reports and work out work-arounds. Is that the limit of KDE's ambition?

Last edited by spoovy on Wed Oct 13, 2010 11:36 pm, edited 1 time in total.
User avatar
TheBlackCat
Registered Member
Posts
2945
Karma
8
OS

Re: KDE dev priorities

Wed Oct 13, 2010 11:32 pm
spoovy wrote:I agree; I understand the responsibility of end users in FOSS projects, and in the past I have submitted bug reports. But surely after five major point releases it is reasonable to expect that my fresh installation will work without regular crashes - or isn't' it? I have installed on about 8-9 different machines over the last year or so and had broadly the same experiences on each. Do the devs not use their own product, or do any testing of their own at all?

Once again, you are assuming that they see these crashes. I don't see the crashes, and several others have said they don't see them either. There may be a problem with your distribution, or it may be your specific combination of hardware, software, and applets are triggering crashes that others don't see.

I was having crashes when plasma shut down, but I traced the problem to a particular third-party widget. Removing that fixed the problem. It may very well just be one bad third-party widget that is causing trouble for you.

spoovy wrote:Which i suppose is the root of my question - what is a reasonable time for an end user to wait in order to get a useable product? How many bug reports does it take?

If you allow third-party software, that depends entirely on the quality of the third-party software. Plasma should be completely usable now, it has been for me for several releases now. You are assuming the fault lies with the plasma developers, but you don't know that.

spoovy wrote:Please never go into my industry, you'd still be diligently painting half the bridge with anti-rust paint two years after the other half had fallen into the sea.

How would you feel if you spent years spent setting up the traffic lights in the city and someone called accusing you of not putting enough effort into making the stoplights work efficiently? They made no effort to actually check how much effort you really spent, despite the fact that such data is readily available, they just assumed you didn't spend enough time.

Then imagine that random strangers are putting up their own stoplights as well, but people keep calling and complaining to you about these stoplights.

Now imagine the people complaining outright refuse to tell you which stoplights are causing a problem, arguing that since they told you about others in the past, they should all be working now. This is despite the fact that there are many stoplights you have no control over, changes in one stoplight (including changes these people suggested) can sometimes cause unexpected effects on other lights or on overall traffic flow, and different cars, trucks, motorcycles, and bicycles with different breaking, speed, and handling characteristics have different optimal stoplight configurations so it is impossible to test every available vehicle with every light.

Despite the fact that roads have been around a long time, traffic jams still happen.


Man is the lowest-cost, 150-pound, nonlinear, all-purpose computer system which can be mass-produced by unskilled labor.
-NASA in 1965
spoovy
Registered Member
Posts
49
Karma
0
OS

Re: KDE dev priorities

Wed Oct 13, 2010 11:44 pm
For the record I dont use any of these third party widget things, I don't like em. All my problems are with the basic vanilla KDE, and always have been. I use Arch, and nobody else as far as I know has reported these issues. It seems to be hardware - specific, even though I use very common, standard hardware.

You are still avoiding the issue by deflecting - just man up and face the issue, or keep your keyboard silent. You are the one making assumptions by assuming that the problems I am experiencing are third-party, and by extension therefore casting doubt on the validity of my experiences, which you have no right to do.
User avatar
TheBlackCat
Registered Member
Posts
2945
Karma
8
OS

Re: KDE dev priorities

Thu Oct 14, 2010 2:00 am
spoovy wrote:For the record I dont use any of these third party widget things, I don't like em. All my problems are with the basic vanilla KDE, and always have been. I use Arch, and nobody else as far as I know has reported these issues. It seems to be hardware - specific, even though I use very common, standard hardware.

That casts further doubt on your expectation that the KDE developers should have been aware of the problem.

Is it really that hard to just tell us what specific widgets you are using? Could you even just take a screenshot of your desktop and post it if it is too much trouble to list them? We really want to get these problems fixed.

spoovy wrote:You are still avoiding the issue by deflecting - just man up and face the issue, or keep your keyboard silent.

What specifically do you mean by "face the issue"? The issue is that you are experiencing a very rare, possibly unique, vague problem that apparently can only be triggered by a very specific, possibly unique, almost totally unknown combination of hardware and software. What sort of response do you expect? To agree with you that developers should somehow be able to fix a very rare, very difficult to trigger problem that they don't even know is happening?

If you had some sort of practical suggestion about how plasma developers could go about fixing problems like this, or avoiding them, I would be glad to discuss it. But your only suggestion so far is that they should just throw more time at it. But that isn't going to help unless they have some clue as to what they should be spending that time on.

spoovy wrote:You are the one making assumptions by assuming that the problems I am experiencing are third-party, and by extension therefore casting doubt on the validity of my experiences, which you have no right to do.

I never said that the problems were due to third-party widgets. I listed three possible causes, one of which was third party widgets.


Man is the lowest-cost, 150-pound, nonlinear, all-purpose computer system which can be mass-produced by unskilled labor.
-NASA in 1965
samhain
Banned
Posts
201
Karma
1
OS

Re: KDE dev priorities

Thu Oct 14, 2010 10:40 am
The propper way to fix plasma would be a redesign. It's inconsistent in handling user input. It's inconsistent and uncapable of correct configuration. It's nice eyecandy and one could take it as a preproduction prototype. I don't think you'd like to face that, anyway.


Bookmarks



Who is online

Registered users: Bing [Bot], Google [Bot], q.ignora, watchstar