Re: [kde] KDE's rough edges... what are your experiences?

[Kevin Krammer]

On Friday, 2013-11-01, 17:31:33, Michael wrote:
> Am Thu, 31 Oct 2013 14:58:43 +0100
> schrieb Kevin Krammer :

> > There are already quite some applications that have their own pace,
> > e.g. Amarok and Digikam, so this is mostly an option that might be
> > explored by more applicatons in the future.
> 
> So it *is* possible with qt4 / kde4 already and not a feature (planned
> or already done) in qt5 / kde5.

There is no technical limitation now, if you mean that.

> To convince other application
> developers to do the same, no idea how qt5 might help help there.

Qt5 or KDE Frameworks 5 doesn't change anything, however the reorganization of 
the platform into frameworks constitutes a change in how the libraries will be 
handled (as products of their own) which will likely serve as a trigger for 
other changes.

> As I guess the most obvious reason for slower paced development is just lack
> of manpower. Any pointers there that qt5 does actually help?

I don't think Qt5 changes anything regarding man power. The KDE Framworks 5 
effort might result in an increase of developers spending time on the 
frameworks, i.e. applications developers currently not working with KDE based 
libraries but rolling their own.

> > The relation to the KDE Frameworks 5 initiative is that are
> > consideration to potentially release frameworks separately or in
> > smaller groups on individual schedules. When the release of
> > dependencies is no longer synchronized, it becomes more unlikely that
> > things built upon them are released in a synchronized fashion.
> > 
> > But, as I said in another posting, this is not definit yet.
> 
> Uh... even after reading that paragraph several times, I seem to have
> some issues understanding it. O_o So... come again? Or point me to the
> other mail, maybe that will clear things up.

Separate release schedules are something that is discussed but not decided 
yet, at least not by all application teams.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Michael]

Am Thu, 31 Oct 2013 14:58:43 +0100
schrieb Kevin Krammer :

> On Thursday, 2013-10-31, 11:45:04, Michael wrote:
> > Am Tue, 29 Oct 2013 14:35:29 + (UTC)
> > schrieb Duncan <1i5t5.dun...@cox.net>:
> 
> > > Up the stack at the application level, kde5 is breaking up and
> > > shipping most individual apps with their own version tagging and
> > > release timing, so apps that are evolving fast can ship updates
> > > every month or even every week if they wish, while already mature
> > > apps in primarily maintenance mode might ship an update a year,
> > > mostly just to keep them building on current libraries with
> > > current tools, with the occasional security update as well when
> > > necessary.
> > 
> > With QT4 / KDE4, could applications not just build against maybe
> > older qt- / kdelibs which would then not prevent fast-paced
> > application-development?
> 
> There are already quite some applications that have their own pace,
> e.g. Amarok and Digikam, so this is mostly an option that might be
> explored by more applicatons in the future.

So it *is* possible with qt4 / kde4 already and not a feature (planned
or already done) in qt5 / kde5. To convince other application
developers to do the same, no idea how qt5 might help help there. As I
guess the most obvious reason for slower paced development is just lack
of manpower. Any pointers there that qt5 does actually help?


> The relation to the KDE Frameworks 5 initiative is that are
> consideration to potentially release frameworks separately or in
> smaller groups on individual schedules. When the release of
> dependencies is no longer synchronized, it becomes more unlikely that
> things built upon them are released in a synchronized fashion.
> 
> But, as I said in another posting, this is not definit yet.

Uh... even after reading that paragraph several times, I seem to have
some issues understanding it. O_o So... come again? Or point me to the
other mail, maybe that will clear things up.


> > > That means currently qt-but-non-kde apps and desktop options may
> > > become more popular as well.  There's smplayer, and the razor-qt
> > > desktop.
> > 
> > Right, there *is*! No idea why the new "de-coupling style" benefits
> > such projects. BUT ignore the question you might see here, as it
> > will go in a direction which is out of the scope of this thread.
> > Really, don't answer the question, ignore it.
> 
> 
> Should probably not ask it then ;-)

Yeah! :-) But it is kind of hard to make the balancing act between
showing Duncan what parts *could* (or should) be skipped and carrying
on the overall conversation. The idea was to show him a possible
conclusion a person might have and as the reaction to that conclusion
would miss the scope of the conversation, try to convince him to not
answer it. But agreed, under normal circumstances I would not have
written a thing that could be understood as a question when I don't
want that question to be followed in the first place. But in this case
the idea may have failed or was a bad idea to begin with...
whatever. :-)

> It is somewhat relevant though. Making KDE technology more available
> to projects currently not using it has the potential of increasing
> the number of people working on them.
> Another thing that influences the topic of QA is that part of the
> effort is to increase test coverage, or, making the tests more
> explicit (things that got lots of implicit testing through being used
> by other parts now gain their own tests).

As I don't want to go there any further anyway: We'll see. ;-)

regards
Michael
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Myriam Schweingruber]

On Fri, Nov 1, 2013 at 2:02 PM, Duncan <1i5t5.dun...@cox.net> wrote:
...
> [tl;dr summary, more modular-qt/kde-frameworks discussion]

Yay! Duncan, I love you :)


Regards, Myriam

-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Duncan]

Michael posted on Thu, 31 Oct 2013 11:45:04 +0100 as excerpted:

> Am Tue, 29 Oct 2013 14:35:29 + (UTC)
> schrieb Duncan <1i5t5.dun...@cox.net>:
> 
>> Michael posted on Tue, 29 Oct 2013 06:48:40 +0100 as excerpted:
>> 
>>> If KDE5 will have the same QA-style, I guess KDE will
>>> go into the history books of open source software, as always shiny
>>> but buggy to a degree that it may even be unusable.
>> 
>> Call me an optimist (heh, wrote that before noting your email address 
>> =:^) if you will, but I believe the kdeers are on the right track
>> with this kde frameworks five stuff.
> 
> That means you think with QT5 and KDE5 the overall bug- and
> maintenance-situation will improve?

Yes...

[tl;dr summary, more modular-qt/kde-frameworks discussion]

>> Both the kde foundations and the qt it's based on are becoming a lot
>> more modular, with the ability for developers to pick and choose the 
>> dependencies they want/need without having to bring in the whole big 
>> currently monolithic qtlibs and kdelibs.
> 
> How I see it, that would only help to get the issue-list down for
> people NOT using the full-stack of KDE.

It tightens down the scope.  Individual modules are smaller both in code 
and in authors.  Less code means less bugs.

At the same time, more projects that would have previously ruled out 
using that library due to the cost of pulling in the whole ecosystem will 
likely find the now lower cost of pulling in just the module they need 
rather more palatable.

More application users and more application developer's and advanced 
user's eyes looking at a smaller pile of code... should mean faster and 
more in depth bug finding and fixing.

>> Qt itself is maturing as a developer-community-based toolkit in its
>> own right, and qt5 is far more community-driven than any qt ever
>> before in history.
> 
> More community-driven as non-qt frameworks as well, or at least on par
> with them? And regarding the issues discussed in this thread, I don't
> see a necessary benefit from the possibly higher factor of
> community-drivenness there too. And I doubt the issues I have in mind
> here are QT-issues.

When qt was driven by trolltech and then nokia, it was corporate 
controlled, and certain changes that might have made sense from a library 
and code perspective would not be accepted because they conflicted with 
where the corporation intended to take its product.  It was sort of like 
closed source, you can't fix it as it's not in your control so you 
develop your own workarounds.  It wasn't near as bad as closed source 
because the source was open so people could see what the code was 
actually doing without reverse-engineering it and could submit proposed 
patches, but whether those patches would be taken or not...

>From the various mostly kde devs blogs I've read, but supported by the 
razor-qt and lxde moves as well, that's gone and qt is fully community 
driven and community transparent now.  It's far easier for kde to move 
former kdelibs functionality down into qt where it makes sense, yet 
because of the increased modularity, doing so doesn't bloat qt as a 
whole, because to a large extent the code is going into optional qt 
modules, not into qt-core where it'd be forced on every qt user, 
regardless of need.

Meanwhile, kdelibs is itself becoming smaller as bits of it break off 
into optional kde libs or into various qt modules.

The bigger picture is one of the entire ecosystem going more modular, 
with higher level users now able to interact far more directly with their 
now narrower scope lower level dependencies, meaning the whole stack is 
more transparent and what were kdelibs or kde-category-libs level 
workarounds to qt level bugs in the kde4/qt4 and even more the kde3/qt3 
era, now can be fixed directly in the qt module with the bug by the 
developer experiencing the bug themselves (of course providing they're a 
qt dev too, but it's a community and that's open to them now).  And the 
same at the kde frameworks level as kdelibs breaks into a framework of 
libs, some higher level some lower, with some functionality transferred 
to qt and thus not kde level at all any longer.

That problem I mentioned with khotkeys4 that ultimately traced to qt4 not 
having proper multikey support?  Based on comments I've read, qt5 doesn't 
have that problem, in part because the kde developers who suffered with 
it in qt4 made very sure qt5 did it right.

Entire qt4 era workarounds in kdelibs and above are now being chopped 
from the qt5/kde-frameworks-5 code, because the problems can and are 
being fixed directly in qt5 now, so the workarounds are simply no longer 
necessary.  Both directly less bugs and less workarounds as a result, and 
indirectly, slicing whole layers of workaround code out as a result, 
meaning any bugs in THAT code are now gone!

> Off-Topic (writing style): Both paragraphs repetition over repetition of
> former statements with only small amounts of new arguments. Do you se

Re: [kde] KDE's rough edges... what are your experiences?

[Kevin Krammer]

On Thursday, 2013-10-31, 10:57:51, Ross Boylan wrote:
> On Thu, Oct 31, 2013 at 11:54:50AM +0100, Kevin Krammer wrote:
> > On Thursday, 2013-10-31, 11:48:10, Michael wrote:
> > > Am Wed, 30 Oct 2013 18:34:56 +0100
> > > 
> > > schrieb Kevin Krammer :
> > > > On Wednesday, 2013-10-30, 18:00:46, Michael wrote:
> > > > > And on the thread itself, I did not talk about any applications, I
> > > > > only speak of the UI + widgets and its issues. I know the threshold
> > > > > might be fuzzy there sometimes.
> > > > 
> > > > Right. There are more precise ways to address different products,
> > > > e.g. Plasma desktop or Plasma workspace(s), but anything than using
> > > > the project/vendor name is usally already an improvement.
> > > > 
> > > > > So, KDE4 is officially abandoned, great! :-(
> > > > 
> > > > No.
> > > > As explained in short and in length :)
> > > 
> > > From what I wanted to know, it generally is. That not
> > > all-and-everything KDE-related is obsolete is quite clear.
> > 
> > I guess it also depends on the definition of abandoned. Usually that means
> > discarded or remaining untouched, etc.
> > If we define abandoned as no new extensions that is of course a different
> > case.
> > 
> > Cheers,
> > Kevin
> 
> My main concern with 4 is not whether features are being added but
> whether bugs are being removed.  What are the prospects for that?

I can see bugfix commits going into the kde-workspaces KDE/4.11 branch so I'd 
say it isn't a matter of prospects but happening as planned.

> And has anything been done in the KDE5 cycle to assure higher levels of
> reliability?

Don' know, I am not involved in either workspace development nor the Qt5 
porting efforts.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Ross Boylan]

On Thu, Oct 31, 2013 at 11:54:50AM +0100, Kevin Krammer wrote:
> On Thursday, 2013-10-31, 11:48:10, Michael wrote:
> > Am Wed, 30 Oct 2013 18:34:56 +0100
> > 
> > schrieb Kevin Krammer :
> > > On Wednesday, 2013-10-30, 18:00:46, Michael wrote:
> > > > And on the thread itself, I did not talk about any applications, I
> > > > only speak of the UI + widgets and its issues. I know the threshold
> > > > might be fuzzy there sometimes.
> > > 
> > > Right. There are more precise ways to address different products,
> > > e.g. Plasma desktop or Plasma workspace(s), but anything than using
> > > the project/vendor name is usally already an improvement.
> > > 
> > > > So, KDE4 is officially abandoned, great! :-(
> > > 
> > > No.
> > > As explained in short and in length :)
> > 
> > From what I wanted to know, it generally is. That not
> > all-and-everything KDE-related is obsolete is quite clear.
> 
> I guess it also depends on the definition of abandoned. Usually that means 
> discarded or remaining untouched, etc.
> If we define abandoned as no new extensions that is of course a different 
> case.
> 
> Cheers,
> Kevin

My main concern with 4 is not whether features are being added but
whether bugs are being removed.  What are the prospects for that?  And
has anything been done in the KDE5 cycle to assure higher levels of
reliability?

Ross Boylan
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Kevin Krammer]

On Thursday, 2013-10-31, 11:45:04, Michael wrote:
> Am Tue, 29 Oct 2013 14:35:29 + (UTC)
> schrieb Duncan <1i5t5.dun...@cox.net>:

> > Up the stack at the application level, kde5 is breaking up and
> > shipping most individual apps with their own version tagging and
> > release timing, so apps that are evolving fast can ship updates every
> > month or even every week if they wish, while already mature apps in
> > primarily maintenance mode might ship an update a year, mostly just
> > to keep them building on current libraries with current tools, with
> > the occasional security update as well when necessary.
> 
> With QT4 / KDE4, could applications not just build against maybe older
> qt- / kdelibs which would then not prevent fast-paced
> application-development?

There are already quite some applications that have their own pace, e.g. 
Amarok and Digikam, so this is mostly an option that might be explored by more 
applicatons in the future.

The relation to the KDE Frameworks 5 initiative is that are consideration to 
potentially release frameworks separately or in smaller groups on individual 
schedules. When the release of dependencies is no longer synchronized, it 
becomes more unlikely that things built upon them are released in a 
synchronized fashion.

But, as I said in another posting, this is not definit yet.

> > That means currently qt-but-non-kde apps and desktop options may
> > become more popular as well.  There's smplayer, and the razor-qt
> > desktop.
> 
> Right, there *is*! No idea why the new "de-coupling style" benefits
> such projects. BUT ignore the question you might see here, as it will
> go in a direction which is out of the scope of this thread. Really,
> don't answer the question, ignore it.


Should probably not ask it then ;-)
It is somewhat relevant though. Making KDE technology more available to 
projects currently not using it has the potential of increasing the number of 
people working on them.
Another thing that influences the topic of QA is that part of the effort is to 
increase test coverage, or, making the tests more explicit (things that got 
lots of implicit testing through being used by other parts now gain their own 
tests).

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Kevin Krammer]

On Thursday, 2013-10-31, 11:48:10, Michael wrote:
> Am Wed, 30 Oct 2013 18:34:56 +0100
> 
> schrieb Kevin Krammer :
> > On Wednesday, 2013-10-30, 18:00:46, Michael wrote:
> > > And on the thread itself, I did not talk about any applications, I
> > > only speak of the UI + widgets and its issues. I know the threshold
> > > might be fuzzy there sometimes.
> > 
> > Right. There are more precise ways to address different products,
> > e.g. Plasma desktop or Plasma workspace(s), but anything than using
> > the project/vendor name is usally already an improvement.
> > 
> > > So, KDE4 is officially abandoned, great! :-(
> > 
> > No.
> > As explained in short and in length :)
> 
> From what I wanted to know, it generally is. That not
> all-and-everything KDE-related is obsolete is quite clear.

I guess it also depends on the definition of abandoned. Usually that means 
discarded or remaining untouched, etc.
If we define abandoned as no new extensions that is of course a different 
case.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Michael]

Am Wed, 30 Oct 2013 18:34:56 +0100
schrieb Kevin Krammer :

> On Wednesday, 2013-10-30, 18:00:46, Michael wrote:
> 
> > And on the thread itself, I did not talk about any applications, I
> > only speak of the UI + widgets and its issues. I know the threshold
> > might be fuzzy there sometimes.
> 
> Right. There are more precise ways to address different products,
> e.g. Plasma desktop or Plasma workspace(s), but anything than using
> the project/vendor name is usally already an improvement.
> 
> > So, KDE4 is officially abandoned, great! :-(
> 
> No.
> As explained in short and in length :)

>From what I wanted to know, it generally is. That not
all-and-everything KDE-related is obsolete is quite clear.

regards
Michael
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Michael]

Am Tue, 29 Oct 2013 14:35:29 + (UTC)
schrieb Duncan <1i5t5.dun...@cox.net>:

> Michael posted on Tue, 29 Oct 2013 06:48:40 +0100 as excerpted:
> 
> > Oh, KDE4 is more or less in "maintenance-mode"? Err... scratch
> > that. As of now I still believe maintenance is something that does
> > not apply well to the KDE-kind-of development-style, so KDE4 is
> > more or less obsolete now?
> 
> That would seem to be the case, yes.
> 
> > Well, it would fit the (current and as of now unofficial)
> > description. If KDE5 will have the same QA-style, I guess KDE will
> > go into the history books of open source software, as always shiny
> > but buggy to a degree that it may even be unusable.
> 
> Call me an optimist (heh, wrote that before noting your email address 
> =:^) if you will, but I believe the kdeers are on the right track
> with this kde frameworks five stuff.

That means you think with QT5 and KDE5 the overall bug- and
maintenance-situation will improve?


> Both the kde foundations and the qt it's based on are becoming a lot
> more modular, with the ability for developers to pick and choose the 
> dependencies they want/need without having to bring in the whole big 
> currently monolithic qtlibs and kdelibs.

How I see it, that would only help to get the issue-list down for
people NOT using the full-stack of KDE.

> Qt itself is maturing as a developer-community-based toolkit in its
> own right, and qt5 is far more community-driven than any qt ever
> before in history.

More community-driven as non-qt frameworks as well, or at least on par
with them? And regarding the issues discussed in this thread, I don't
see a necessary benefit from the possibly higher factor of
community-drivenness there too. And I doubt the issues I have in mind
here are QT-issues.

> As part of that, it's both expanding and going
> modular, with most of its components becoming optional -- developers
> only pull in what they need, and will no longer have to depend on
> (and ship, for platforms where bundling is common) the parts they
> don't pull in.  As part of the expansion and because it /is/ more
> community focused now and kde has been and remains a large part of
> that community, parts of what were kdelibs are now becoming part of
> qt5.  But at the same time, because qt's becoming more modular and
> much of it is now optional, all those extra features aren't bloating
> qt5 out of control, because if a developer doesn't need them he
> simply won't pull them in, and the modular components that are pulled
> in may well be far slimmer with qt5 than with qt4.
> 
> At the same time, kdelibs and the kdebase platform is similarly 
> modularizing, allowing the same choice at the kde developer and user 
> level as well as blurring the lines between what's qt and what's kde, 
> since parts that were once kdelibs are now qt, but either way,
> they're now optional, so a formerly kde app may actually find itself
> only needing qt now, and even if it does pull in some kde libraries,
> because both the kde libs and qt are going modular, the dependencies
> may now well be smaller as a full kde app than they were previously
> as a qt-only app!

Off-Topic (writing style): Both paragraphs repetition over repetition of
former statements with only small amounts of new arguments. Do you see
that now in retrospect?

On-Topic: Nothing new to add. At least nothing that screams to be added.


> Up the stack at the application level, kde5 is breaking up and
> shipping most individual apps with their own version tagging and
> release timing, so apps that are evolving fast can ship updates every
> month or even every week if they wish, while already mature apps in
> primarily maintenance mode might ship an update a year, mostly just
> to keep them building on current libraries with current tools, with
> the occasional security update as well when necessary.

With QT4 / KDE4, could applications not just build against maybe older
qt- / kdelibs which would then not prevent fast-paced
application-development?


> So the kde frameworks 5 core is going to be MUCH smaller, while most
> of the bundled apps we know as kde today will be unbundled and
> shipped separately, either as individual apps or possibly as a
> functional bundle -- dolphin and kmail and rekonq and konqueror and
> plasma will likely all release separately, with their own versions.
> (Actually, some of them have their own versions now; kmail is version
> 2.something these days for instance, but nobody knows their kmail
> version without looking, they simply say kmail 4.11.2 or whatever,
> the kde version.)  But kdegames (for example) may still ship as a
> kdegames bundle, with a common kdegames (not kde) version.

OffTopic: Different view / some new arguments on previous statements.
Apart from that: repetition. And you somewhat answer stuff that was not
asked for. You went into a possible direction ahead which hinders me
from a natural way of the "asking and answering"-thing, as you did
answe

Re: [kde] KDE's rough edges... what are your experiences?

[Kevin Krammer]

On Wednesday, 2013-10-30, 18:00:46, Michael wrote:

> And on the thread itself, I did not talk about any applications, I
> only speak of the UI + widgets and its issues. I know the threshold
> might be fuzzy there sometimes.

Right. There are more precise ways to address different products, e.g. Plasma 
desktop or Plasma workspace(s), but anything than using the project/vendor 
name is usally already an improvement.

> So, KDE4 is officially abandoned, great! :-(

No.
As explained in short and in length :)

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Michael]

Am Tue, 29 Oct 2013 21:45:55 +0100
schrieb Kevin Krammer :

> On Tuesday, 2013-10-29, 06:48:40, Michael wrote:
> > Hi Frank,
> > 
> > Am Mon, 28 Oct 2013 20:36:02 +0100
> > 
> > schrieb Frank Steinmetzger :
> 
> > > I suppose right now the migration to 5.0 takes lots of developer
> > > resources, so I imagine fixing bugs in “obsolete” 4 gets even less
> > > attention. I attempted fixing bugs before (and sent a patch in two
> > > instances), but it requires lots of work to get into the code,
> > > especially in bigger projects like Amarok or KMail.
> > 
> > Oh, KDE4 is more or less in "maintenance-mode"?
> 
> Yes and no :)
> 
> In the context of this discussion, i.e. KDE's desktop environment,
> yes. In the larger context of all KDE products, no.
> 
> Duncan already explained that in more detail :)

In *wy* too much detail. I really did not want to be "too" rude as I
informed him about my concerns there (telling people possible flaws is
always a tricky thing which I did not master yet), but am I really the
only one that feels somewhat "annoyed" by his extremely longish and in
times painfully repetitive mails? :-/

And on the thread itself, I did not talk about any applications, I
only speak of the UI + widgets and its issues. I know the threshold
might be fuzzy there sometimes.

So, KDE4 is officially abandoned, great! :-(

not so optimistic
Michael
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Kevin Krammer]

On Wednesday, 2013-10-30, 08:59:34, Duncan wrote:
> Kevin Krammer posted on Tue, 29 Oct 2013 22:02:12 +0100 as excerpted:
> > Hi Duncan,
> > 
> > as usual thanks for the thorough explanations.
> > I've noted a couple of minor inaccuracies, so here we go :)
> > 
> > On Tuesday, 2013-10-29, 14:35:29, Duncan wrote:

> >> Qt itself is maturing as a developer-community-based toolkit in its own
> >> right, and qt5 is far more community-driven than any qt ever before in
> >> history.  As part of that, it's both expanding and going modular, with
> >> most of its components becoming optional -- developers only pull in
> >> what they need, and will no longer have to depend on (and ship, for
> >> platforms where bundling is common) the parts they don't pull in.
> > 
> > The modularisation of Qt5 compared to Qt4 is mostly on the respository
> > level though. Qt4 is already split into several modules which can be
> > used individually, e.g. a program can choose to use QtCore, QtGui and
> > QtNetwork and not choose to depend on QtXml, QtSql and so on.
> > 
> > That change already happened at the Qt3 to Qt4 transition.
> 
> Agreed, but I think that misses a part of the overall picture just as I
> did, because we're focusing on different close-ups of the overall picture.

I am not sure. I think we were both looking at it from the app developer's 
perspective, but lets see :)

> At least here on gentoo, qt4 has in fact already been for some time a
> convenience metapackage that simply pulls in all the separate qt4 module
> packages, while individual apps depend on the individual qt4 modules the
> need, tho I'm unaware to what extent other distros have split up qt4.

Also true for Debian.

> But with a quick check (on 4.8.5) confirming it, qt4 is still shipped as
> a single tarball

True, but that is of no concern to the application developers.
They have not only the option of specifying concrete dependencies, they 
actually have to do it.
There is no such thing as "enable all of Qt", it is always a concious choice 
of individual Qt modules, with only "QtCore" and "QtGui" being preselected by 
default.

> For both kde and qt, those tarballs generally reflect upstream
> development repo layout altho I guess there are some exceptions.

Mostly correct. I think the Qt5 packages contain most repos, e.g. qtbase + 
qtdeclarative + qtwebkit and so on.

> But I don't believe "mostly on the repository level" fully reflects the
> reality of the situation, however, tho you're correct in that it's part
> of an ongoing process.

Well, that is the main change, splitting wise, between Qt4 and Qt5 :)
It is not even important for most people working on Qt since there is a way to 
checkout all repositories that make up Qt in one go.

> The repository splits do indeed reflect an
> ultimate separation that has in other regards already occurred, yes, but
> it's my belief that despite the earlier conceptual separation, the
> combined repositories were holding the otherwise mostly separate modules
> hostage to a combined immediate future, and that fully separating them
> not only reflects evolving reality, but will in fact free them from the
> limits that were being artificially imposed on them due to that current
> situation and immediate qt4 future, such that we will now see the
> individual modules evolving further now that those restrictions are
> lifted.

All the modules that are not considered addons are still developed together. 
It makes developing Qt a bit less resource intensive since you don't have to 
checkout or build repositories that you are not working on and the Continous 
Integraton system does not have to do that either.

But I think most developers still run the scripts that checkout all of Qt.

> In the qt realm, that's likely to result in the individual modules
> becoming far more popular as library dependencies, since it'll be much
> more like pulling in an individual library dependency to take care of a
> specific function, instead of having to pull in the whole heavy ecosystem
> when most of it wasn't to be used.

But for Qt that was never the case after Qt3.
As I wrote above, each module has to be explicitly activated. The only module 
that changed was QtGui, so one can now do a QtQuick application without 
pulling in QtWidgets.

Most desktop applications use widgets, so there is no change for them in 
matters of dependency size.

> > The Qt5 transition splits QtGui into two (QtGui and QtWidgets) but most
> > other modules remained the same (library wise, some got their own
> > respository source wise as noted above).
> 
> As I said, while (AFAIK) that's literally true, I believe it's missing
> the larger picture, and that now freed from the heavyweight bonds of
> having to depend on the entire qt package in many cases, individual qt
> modules and libs will likely see dramatically increased use over the
> coming years, as more distros (generically, not just Linux) split up qt
> into these modules and thus dramatically low

Re: [kde] KDE's rough edges... what are your experiences?

[Duncan]

Kevin Krammer posted on Tue, 29 Oct 2013 22:02:12 +0100 as excerpted:

> Hi Duncan,
> 
> as usual thanks for the thorough explanations.
> I've noted a couple of minor inaccuracies, so here we go :)
> 
> On Tuesday, 2013-10-29, 14:35:29, Duncan wrote:
> 
>> Both the kde foundations and the qt it's based on are becoming a lot
>> more modular, with the ability for developers to pick and choose the
>> dependencies they want/need without having to bring in the whole big
>> currently monolithic qtlibs and kdelibs.
>> 
>> Qt itself is maturing as a developer-community-based toolkit in its own
>> right, and qt5 is far more community-driven than any qt ever before in
>> history.  As part of that, it's both expanding and going modular, with
>> most of its components becoming optional -- developers only pull in
>> what they need, and will no longer have to depend on (and ship, for
>> platforms where bundling is common) the parts they don't pull in.
> 
> The modularisation of Qt5 compared to Qt4 is mostly on the respository
> level though. Qt4 is already split into several modules which can be
> used individually, e.g. a program can choose to use QtCore, QtGui and
> QtNetwork and not choose to depend on QtXml, QtSql and so on.
> 
> That change already happened at the Qt3 to Qt4 transition.

Agreed, but I think that misses a part of the overall picture just as I 
did, because we're focusing on different close-ups of the overall picture.

At least here on gentoo, qt4 has in fact already been for some time a 
convenience metapackage that simply pulls in all the separate qt4 module 
packages, while individual apps depend on the individual qt4 modules the 
need, tho I'm unaware to what extent other distros have split up qt4.

But with a quick check (on 4.8.5) confirming it, qt4 is still shipped as 
a single tarball, much as early kde4 still shipped many of its category 
packages (such as kdegames and kdepim) as monolithic tarballs, even when 
they were already split into individual packages internal to the tarball.  
(FWIW, in an ongoing process, those big kde category tarballs have been 
splitting into individual package tarballs as kde4 has matured, with a 
lot more but much smaller tarballs for say 4.11 as compared against say 
4.5.)

For both kde and qt, those tarballs generally reflect upstream 
development repo layout altho I guess there are some exceptions.

But I don't believe "mostly on the repository level" fully reflects the 
reality of the situation, however, tho you're correct in that it's part 
of an ongoing process.  The repository splits do indeed reflect an 
ultimate separation that has in other regards already occurred, yes, but 
it's my belief that despite the earlier conceptual separation, the 
combined repositories were holding the otherwise mostly separate modules 
hostage to a combined immediate future, and that fully separating them 
not only reflects evolving reality, but will in fact free them from the 
limits that were being artificially imposed on them due to that current 
situation and immediate qt4 future, such that we will now see the 
individual modules evolving further now that those restrictions are 
lifted.

In the qt realm, that's likely to result in the individual modules 
becoming far more popular as library dependencies, since it'll be much 
more like pulling in an individual library dependency to take care of a 
specific function, instead of having to pull in the whole heavy ecosystem 
when most of it wasn't to be used.

Of course that's mostly at the dev level, as will be the changes at the 
kdelibs and base frameworks five level.  The far more visible results at 
the user level will be as I said, individual kde apps chosen for their 
genre leading features and/or because they are the best match for a 
specific need, as users are able to pull them in with just their direct 
deps, instead of having to pull in an entire kde and qt ecosystem just to 
support a single app they want, thus making it less likely they'll use 
ANY kde apps, unless they happen to be willing to standardize on nearly 
ALL kde apps.

> The Qt5 transition splits QtGui into two (QtGui and QtWidgets) but most
> other modules remained the same (library wise, some got their own
> respository source wise as noted above).

As I said, while (AFAIK) that's literally true, I believe it's missing 
the larger picture, and that now freed from the heavyweight bonds of 
having to depend on the entire qt package in many cases, individual qt 
modules and libs will likely see dramatically increased use over the 
coming years, as more distros (generically, not just Linux) split up qt 
into these modules and thus dramatically lower the dependency cost to 
depend on the functionality of just one or two of them.

>> Up the stack at the application level, kde5 is breaking up and shipping
>> most individual apps with their own version tagging and release timing,
>> so apps that are evolving fast can ship updates every month or even
>> 

Re: [kde] KDE's rough edges... what are your experiences?

[Stephen Dowdy]

Kevin Krammer wrote, On 10/29/2013 06:53 AM:
> On Tuesday, 2013-10-29, 13:42:16, Mirosław Zalewski wrote:
>> Unless something changed in 4.11 (I am still using 4.10), you can
>> go to configuration dialog in Dolphin and there, in Navigation pane,
>> make double click open files (single click selects, then).
> 
> Or in system settings, input devices, mouse

Or,

kwriteconfig --file kdeglobals --group KDE --key SingleClick false

You can use this to setup an /etc/kde/kdeglobals so all users default
to double-click mode.

But, this doesn't take effect for any currently open 'dolphin' windows
(but it does for any subsequently opened windows).  I tried:

qdbus org.kde.dolphin-21870 /MainApplication reparseConfiguration

but doesn't seem to be the right thing to do to notify the running dolphin

Anybody know how to signal running applications to reprocess kdeglobals
(or their own KConfig setup?)

--stephen
-- 
Stephen Dowdy  -  Systems Administrator  -  NCAR/RAL
303.497.2869   -  sdo...@ucar.edu-  http://www.ral.ucar.edu/~sdowdy/

___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Kevin Krammer]

Hi Duncan,

as usual thanks for the thorough explanations.
I've noted a couple of minor inaccuracies, so here we go :)

On Tuesday, 2013-10-29, 14:35:29, Duncan wrote:

> Both the kde foundations and the qt it's based on are becoming a lot more
> modular, with the ability for developers to pick and choose the
> dependencies they want/need without having to bring in the whole big
> currently monolithic qtlibs and kdelibs.
> 
> Qt itself is maturing as a developer-community-based toolkit in its own
> right, and qt5 is far more community-driven than any qt ever before in
> history.  As part of that, it's both expanding and going modular, with
> most of its components becoming optional -- developers only pull in what
> they need, and will no longer have to depend on (and ship, for platforms
> where bundling is common) the parts they don't pull in.

The modularisation of Qt5 compared to Qt4 is mostly on the respository level 
though.
Qt4 is already split into several modules which can be used individually, e.g. 
a program can choose to use QtCore, QtGui and QtNetwork and not choose to 
depend on QtXml, QtSql and so on.

That change already happened at the Qt3 to Qt4 transition.

The Qt5 transition splits QtGui into two (QtGui and QtWidgets) but most other 
modules remained the same (library wise, some got their own respository source 
wise as noted above).

> As part of the
> expansion and because it /is/ more community focused now and kde has been
> and remains a large part of that community, parts of what were kdelibs
> are now becoming part of qt5.

Mostly single classes though, nothing in the scope of a Qt module.
Also some contributions of new code inspired by KDE code, contributed by KDE 
developers who worked on the original KDE code.

> Up the stack at the application level, kde5 is breaking up and shipping
> most individual apps with their own version tagging and release timing,
> so apps that are evolving fast can ship updates every month or even every
> week if they wish, while already mature apps in primarily maintenance
> mode might ship an update a year, mostly just to keep them building on
> current libraries with current tools, with the occasional security update
> as well when necessary.

I am not sure that this has been fully established as the new procedure yet, 
but it is one of the possibilities.
Applications might still be released together or in sets, etc.

> the full-featured alternative.  And then there's lxde, formerly a gtk-
> based "lite" desktop, that's switching to qt and cooperating with razor-
> qt in some development areas.

I think they actually are planning to merge. But I could be misinterpreting 
things.

> So the qt5/kde-frameworks-five generation is going to bring with it an
> entirely new level of choice and flexibility, both at the developer and
> user levels, and it's going to be very interesting indeed to watch how
> that ends up working, and what the fallout is in terms of app popularity
> say five years from now.

Indeed!

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Kevin Krammer]

On Tuesday, 2013-10-29, 06:48:40, Michael wrote:
> Hi Frank,
> 
> Am Mon, 28 Oct 2013 20:36:02 +0100
> 
> schrieb Frank Steinmetzger :

> > I suppose right now the migration to 5.0 takes lots of developer
> > resources, so I imagine fixing bugs in “obsolete” 4 gets even less
> > attention. I attempted fixing bugs before (and sent a patch in two
> > instances), but it requires lots of work to get into the code,
> > especially in bigger projects like Amarok or KMail.
> 
> Oh, KDE4 is more or less in "maintenance-mode"?

Yes and no :)

In the context of this discussion, i.e. KDE's desktop environment, yes.
In the larger context of all KDE products, no.

Duncan already explained that in more detail :)

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Kevin Krammer]

On Monday, 2013-10-28, 20:36:02, Frank Steinmetzger wrote:
> On Sun, Oct 27, 2013 at 07:54:09AM +0100, Michael wrote:
> > Hi peops,
> > […]
> > 3.) Widgets, plasmoids, generel KDE features: Yeah well, really nice
> > design (mostly), but from a usability standpoint? Often a mess.
> 
> Plasma is a constant source of annoyance for me. I never really
> understood the need for a second UI style next to the “normal” one. 

I think the UI style was more a side effect. The main idea of Plasma was to be 
able to create adaptable and customizable workspace shells.
Quite forward looking given the time when this all started, but unfortunatly 
also hampered by the available technologies of the time (QGraphicsView).

It took Qt itself until 5.1 to have widget like styling available for QtQuick 
(a.k.a QtQuick.Controls).

> > 4.) […] configuration tends be be trashed every now and then, from one
> > moment to the next (in the process of configuring KDE for example, so
> > no change to the installed packages or other changes to the system)
> > KDE may start to behave "weird".
> 
> Akonadi, the problem child for many, is a nice example with its (for
> this human) incomprehensible config and data file layout.

Off-topic for this discussion about KDE's desktop environment or workspace, 
but as a new project Akonadi follows the guidelines for cross desktop 
locations: config in $XDG_CONFIG_HOME/akonadi, data in $XDG_DATA_HOME/akonadi

> I suppose right now the migration to 5.0 takes lots of developer
> resources, so I imagine fixing bugs in “obsolete” 4 gets even less
> attention.

I think I read somewhere tht the workspace people will be going with 2.0, 
since the next version will be the second iteration of Plasma workspaces.
But yes, it currently seems to bind a lot of their resources, however, I am 
pretty sure they still maintain the current version, after all there are more 
KDE software compilation releases scheduled which they are a part of.

> I attempted fixing bugs before (and sent a patch in two
> instances), but it requires lots of work to get into the code,
> especially in bigger projects like Amarok or KMail.

No idea about Amarok and only very little about KMail, but as far as I can 
tell its developers are working quite determined on further modularization, 
making it easier to tackle sub areas.
Still quite complicated due to being one of the oldest KDE application in 
existance, lots of generations of code and coders preferenecs in there :)

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Kevin Krammer]

On Tuesday, 2013-10-29, 15:58:33, Frank Steinmetzger wrote:

> That was more of a sarcastic nudge at how fast KDE 3 was dropped in
> favour of the yet unusable 4.0.

You mean 4.2 (the first 4.x release after the last 3.x release)

> And I believe I read somewhere that 4.11
> was to be the last 4.x release.

In the context of this thread, the desktop environment product of KDE, yes, 
the last minor release. Still releasing patch level as far as I know.

And, out of scope of this thread, as Duncan mentioned already, only applies to 
the desktop environment or workspace product.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Duncan]

Frank Steinmetzger posted on Tue, 29 Oct 2013 15:58:33 +0100 as excerpted:

> I believe I read somewhere that 4.11 was to be the last 4.x release.

AFAIK that's not quite accurate, tho (like most error that propagates 
well) it has a grain of truth at its core, just distorted and twisted 
beyond that truth.

The bit of truth being that 4.11 (or more precisely 4.11.0, since the 4.x 
micro-series have always been bugfix-only stable series) was the last 
feature release for *SOME* kde4 packages -- they're going into 
maintenance mode now, with further features implemented only in the 
frameworks-five version.

Kdelibs has actually been feature-frozen for some time now, it was listed 
as feature-frozen in the 4.10 feature plan, tho 4.9 had some feature 
changes.  But with 4.11 plasma announced as feature-frozen for kde4 
(changes for 4.11, none for 4.12), and I believe a few other apps are 
similarly feature frozen for kde4 now too.

But a 4.12 series is already planned and a release schedule and feature 
plan is in fact already publicly available on techbase:

http://techbase.kde.org/Schedules

(That's my bookmarked link I've been referring to for several release 
cycles now. As they say, stay tuned! =:^)

As you'll note from the 4.12 feature plan, not all kde4 packages are even 
feature-frozen, tho in comparing that to earlier versions, it's already 
evident that the list is significantly shorter than it was in earlier 
versions, reflecting the freeze in some areas.

And actually, it appears 4.12 feature freeze is tomorrow (Oct. 30), with 
beta1 tagging/release a week later on November 6.  And 4.12.0 should 
continue the semi-yearly feature-release schedule with release due in mid-
January, 2014 (Tuesday, Jan 14, actually, tho as we know, software 
release schedules do occasionally slip a bit), with the last scheduled 
4.12 series release being 4.12.5, scheduled for the end of April, 2014.

I've actually seen talk of a 4.13 beyond that as well, and I /think/ it's 
reasonably likely there will either be a 4.13 or at least 4.12 releases 
scheduled beyond the 4.12.5 that's currently the last scheduled release, 
but AFAIK that's still up in the air and will likely depend on how kde 
frameworks five, which is preliminarily scheduled for initial release in 
1H-2014 as well, is coming by then.

So short of "World War III" or "the rapture" or something similarly earth 
shattering, 4.12 appears to be a given, at this point.  It's just not 
going to be as big a release, feature-wise, as earlier releases, because 
they're focusing on 4.x stability and 5.x development, at this point.  
But there are still SOME feature enhancements coming, just not as many.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Duncan]

Kevin Krammer posted on Tue, 29 Oct 2013 15:31:46 +0100 as excerpted:

>> anyway) developers do stuff not only for them. And if stuff is not
>> supposed to be for "everyone", why release it to the public in the
>> first place?
> 
> Publishing makes sense even if there is only a subset of "everyone" who
> has the same needs. Even if one doesn't know if there is someone else.

That's worth a requote spotlighting. =:^)

Once the work is done, it's very little more trouble to publish it, 
especially when one is already using a (D)VCS such as git to track 
changes already.  Even if NO one else uses it, putting it on a public 
server provides an additional backup in case something happens to the 
local copy -- as Linus says, "real men" let the internet be their backup. 
=:^)

But the chances are pretty good that /someone/ else will find the work 
useful, and once /someone/ does, there's a good change a not 
insignificant group of "someones" will find it useful, even if there's 
never any measurable market share, and even if the ultimate goal never 
advances one whit beyond "scratching your own itch" for the original 
developer and no one else ever provides a patch at all.

So there's certainly reason to get it "out there" even if you have no 
idea if even one "someone else" will find it useful.  Because someone 
might, and even if they don't, at the very least, it's still an off-site 
backup. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Duncan]

Kevin Krammer posted on Tue, 29 Oct 2013 15:11:01 +0100 as excerpted:

>> ... please describe the expectations the KDE project / developers have
>> for their users. And...
> 
> I don't know. Since this discussion is about the DE aspect or KDE's DE
> product I can't say because I am not involved there.

Just wanted to say, Kevin, thanks for your continued helpful activity 
here on this list.  I know it can't be easy and isn't always fun as often 
the negativity can seem overwhelming, but I'm glad you're making an 
effort to provide /some/ contact point to the devs on these lists, and 
/some/ developer perspective, and I always appreciate your insight even 
if I don't always agree (tho I do agree, most of the time).

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Duncan]

Michael posted on Mon, 28 Oct 2013 14:59:12 +0100 as excerpted:

> Hell! Don't take it the wrong way, but I strongly suggest you rethink
> your way of "communicating" on mailinglists. You went in such lengths in
> absolutely unrelated topics and even with slightly related topics you
> went by far, far, far, far to deep. It was really no pleasure at all to
> read it all, which I had to as courtesy demands it, as I did ask for
> feedback. And what I took from your 25.457 characters in 441 lines and
> 4270 words would fit in roundabout 10-20 lines.

FWIW, I'm aware of the situation, and/but...

I do in fact have quite a collection of thanks from people who find my 
"essays" useful enough to thank me, and in some cases, to actually have a 
"Duncan folder" where they save those "essays" for further reference. =:^)

OTOH, I'm also aware that some people find them intolerable, to the point 
of killfiling me -- which I'm OK with as I've always considered 
killfiling an absolute right on the net (that being one of the reasons I 
prefer newsgroups and mailing lists to web forums, where killfiling is 
often not possible), no reason needed, and in fact IMO it's often better 
no reason given, since most "you're killfiled, plonk!" posts I've seen 
would have been better not posted at all.  (I seldom make such posts 
myself as if it really /has/ gotten to the point I'm plonking, I seldom 
see what further positive contribution that last post from my end could 
make.  From their perspective I guess I just stop replying... letting 
them have the last word.)

I guess most people are somewhere in between, skimming/reading my 
"epistles" with varying degrees of impatience.

> If you really feel the urge to go into such detail, do everyone on the
> list a favour and divide your mails in two parts.

I am /trying/ to develop the habit of doing a TL;DR paragraph near the 
top when length justifies, but I'm afraid I've not made it a particularly 
regular habit just yet.

FWIW, thanks for the reminder that I need to keep working at it.  As I 
said at the top, I /am/ aware of the situation...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Frank Steinmetzger]

On Tue, Oct 29, 2013 at 01:17:34PM +, Duncan wrote:
> Frank Steinmetzger posted on Mon, 28 Oct 2013 20:36:02 +0100 as
> excerpted:
> 
> > I thought of not sending this, as it is more like a collection of
> > bug whining, but after having spent lots of time on composing, it
> > would be a waste of electrons not to send it.
> 
> FWIW, I've quit worrying much about that. [...] so I'm the better for
> having written it, regardless of whether I send it or simply hit the X
> and close the window without sending.

That doesn’t help here, the screen session with mutt inside would still
be running. Getting OT, but *SCNR*.
-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any Facebook service.

Three words to describe myself?
Not good at maths.


signature.asc
Description: Digital signature
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Duncan]

Michael posted on Mon, 28 Oct 2013 15:14:40 +0100 as excerpted:

> Am Mon, 28 Oct 2013 16:10:16 +0530 schrieb dE :
> 
>> I think KDE is not suitable for production environment. Just for casual
>> enthusiasts.
> 
> I guess that view is a bit too extreme, but interesting nevertheless. As
> annoying as the "typical" KDE-issues might be or get, there will be a
> point where users know the issues and can adapt to the "buggy"
> situation, so that KDE is not a general "show stopper" to their
> workflow.

I think it's extreme at one level, but not at another.

I already stated that I think kde 4.5 (and will further specify here 
later 4.5, so 4.5.4 and 4.5.5) finally reached "release quality".  Since 
then, the quality has gone up and down a bit, but as a general rule, by 
4.x.4 or so it tends to be reasonably good, "production environment" 
level, for at least some definition thereof.

What's more disturbing to me, however, and why I agree that at a 
different level, dE's correct and kde is not production environment 
quality, is the longer term record of claims made vs. reality.  We have a 
situation where a very public statement was made that kde3 support would 
continue as long as there were users, which WOULD have been production 
environment quality, but then exactly the opposite occurred, support was 
dropped for what real users were saying was the only reasonably working 
version.  At the same time, kde was publicly insisting that the new 
version was ready, while the facts were very clearly otherwise, both 
because even the devs were saying various bits weren't ported yet, and 
because the real users were simply finding the new version unworkable in 
the state it was in at the time.

That's not production environment quality by pretty much any measure, so 
even if the code does arguably literally reach production environment 
quality at some point (as I assert it did with late 4.5), taking the 
project as a whole including the claims made and evident behavior seen, 
no, kde in its 4.x state is NOT production environment quality -- it 
cannot be depended on over time to maintain a product that can be relied 
upon at claimed level of support, because the quality of the in-support 
code drops *WELL* below production environment quality for **YEARS** at a 
time, with users being left in the lurch.

It remains to be seen if that has changed.  With the 5/frameworks effort 
in full swing now, we'll see over the coming couple years just how much 
kde learned with the early kde4 disaster.  If they continue to support 
kde4 code until *USERS* say 5/frameworks is actually ready, or at a very 
minimum, refrain from claiming that they'll do so and then dropping 
support just like that, then when USERS say 5/frameworks code is 
"production environment" ready, a reasonable argument can then be made 
that kde has learned from its earlier mistakes and really /is/ production 
environment ready, even if literal code quality does drop below that 
level from time to time.

I'm actually quite optimistic, as the plan I've seen stated is to allow 
and support both 4.x and 5.x applications running side by side for a 
time, so users can upgrade individual apps to their frameworks-5 versions 
as /users/ consider them ready, while continuing to run other apps at the 
4.x version level until they (the users) consider the frameworks-5 
versions suitably stable to upgrade to them individually.

This actually fits the whole more modular emphasis and theme of 
frameworks-5 as well, so as I said I'm optimistic.  OTOH, the more 
cautious side of me says we've seen promises of continued support before, 
and we know how THAT turned out!

So we'll see, but I really AM optimistic, hopefully not to my own 
detriment.  Regardless, once bitten, twice shy, and I'm better prepared 
for a less-than-smooth transition this time, in part because over time 
I've been forced off of kde based technologies for one thing after 
another, so there's less kde on my system now TO be affected and the 
effect will thus be much more limited however it turns out, and if worse 
does come to worse, it'll be far easier to switch entirely off of kde, 
since there's simply less to switch out, now.

We /will/ see!

>> As of your problems -- if you continue to use KDE, you'll get used to
>> it. For e.g. now removable disks will now show up in device manager.
>> I've to restart KDE to fix it.
> 
> Used to it? That is most unlikely. I could tolerate such issues for some
> time but I guess I could never "adapt" to a point where I would not even
> realize the issues anymore.

Arguably, this is actually what happened to the kde devs themselves -- 
they became used to their workarounds to the point they ceased to even be 
aware of them as workarounds any longer, thus explaining their claim that 
kde 4.2 was ready for ordinary use.  Only the new users still trying to 
upgrade from the by then unsupported 3.5.x could see how horribly broken 
4.2 and 4.3 still were, because they s

Re: [kde] KDE's rough edges... what are your experiences?

[Frank Steinmetzger]

On Tue, Oct 29, 2013 at 06:48:40AM +0100, Michael wrote:

> > > Hi peops,
> > > […]
> > > 3.) Widgets, plasmoids, generel KDE features: Yeah well, really nice
> > > design (mostly), but from a usability standpoint? Often a mess.
> > 
> > Plasma is a constant source of annoyance for me. I never really
> > understood the need for a second UI style next to the “normal” one.
> > The many animations that can’t be switched off and low contrasts are
> > causes of grievance for me. There are layout bugs [...], redrawing
> > bugs [...], UI bugs [...] and feature regressions [...].
> 
> I guess one has to be fair here. I guess KDE4 is designed to be
> feature-rich, beautiful, with many bells and whistles. One could argue,
> it is not designed to be stripped down to a bare minimum.

Well, different to other “modern” desktops, which only seem to offer the
lower end, KDE can be both simplistic and over-the-top full of stuff.

> I may be wrong, but I see it like a person walking in a car-salon, he
> wants to buy some means of transportation.

No, he wants to buy a car. And usually already made up his mind about
specifics, b/c salons commonly have only one or two brands. Sorry, car
comarisons are common in IT discussion, but this one’s not very
applicable. ;-)

> As he is offered some cars, he complains [...]. Don't go to a
> car-salon, if you really want a motorcycle or even a bike.

What exactly is your KDE analogy? Don’t use KDE if you want a window
manager?

> Btw. what about that netbook-design? Isn't that something specifically
> designed for lower-end hardware?

To me, it’s the same plasma, just with a specific default widget setup.
I never used it because (you might guess) it has too many animations and
requires too much clicking. I prefer the classic K-Menu.

> > [...]

> > I suppose right now the migration to 5.0 takes lots of developer
> > resources, so I imagine fixing bugs in “obsolete” 4 gets even less
> > attention. I attempted fixing bugs before (and sent a patch in two
> > instances), but it requires lots of work to get into the code,
> > especially in bigger projects like Amarok or KMail.
> 
> Oh, KDE4 is more or less in "maintenance-mode"?

That was more of a sarcastic nudge at how fast KDE 3 was dropped in
favour of the yet unusable 4.0. And I believe I read somewhere that 4.11
was to be the last 4.x release. Anyhoo, I remained with KDE 3 for a long
time, then used both in parallel and only around 4.3 or even 4.4 I made
the final switch (Gentoo provided for the parallel installation of both
for a long time).

-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any Facebook service.

There are two kinds of people in this world:
Those who are good with words and those who are... erm... thingy...


signature.asc
Description: Digital signature
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Duncan]

Frank Steinmetzger posted on Mon, 28 Oct 2013 20:36:02 +0100 as excerpted:

> But from a convenience standpoint, KDE beats them all with nice extra
> features (KIO, global keyboard shortcuts, range of consistent
> base-applications). And even though I have some issues with it now and
> then (like reliable and *easy*
> file transfer via Bluetooth), I come back to KDE every time, despite it
> taking 20 hours to compile on an Atom. ^^

FWIW, I run an old first-gen 32-bit-only atom netbook here too.  But I 
couldn't tell you how long kde or anything else takes to build on it, 
because I have a 32-bit build-image chroot on my main 6-core Athlon fx 
with 16 gigs RAM and dual SSDs in btrfs raid1 mode.  That's where I do 
all my atom/netbook targeted update builds, then rsync them across to the 
netbook.  Tho I only actually update the netbook every year or longer... 
it's still running kde 4.6, IIRC, and I really should update it again, 
one of these days...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Duncan]

Michael posted on Tue, 29 Oct 2013 06:48:40 +0100 as excerpted:

> Oh, KDE4 is more or less in "maintenance-mode"? Err... scratch that. As
> of now I still believe maintenance is something that does not apply well
> to the KDE-kind-of development-style, so KDE4 is more or less obsolete
> now?

That would seem to be the case, yes.

> Well, it would fit the (current and as of now unofficial)
> description. If KDE5 will have the same QA-style, I guess KDE will go
> into the history books of open source software, as always shiny but
> buggy to a degree that it may even be unusable.

Call me an optimist (heh, wrote that before noting your email address 
=:^) if you will, but I believe the kdeers are on the right track with 
this kde frameworks five stuff.

Both the kde foundations and the qt it's based on are becoming a lot more 
modular, with the ability for developers to pick and choose the 
dependencies they want/need without having to bring in the whole big 
currently monolithic qtlibs and kdelibs.

Qt itself is maturing as a developer-community-based toolkit in its own 
right, and qt5 is far more community-driven than any qt ever before in 
history.  As part of that, it's both expanding and going modular, with 
most of its components becoming optional -- developers only pull in what 
they need, and will no longer have to depend on (and ship, for platforms 
where bundling is common) the parts they don't pull in.  As part of the 
expansion and because it /is/ more community focused now and kde has been 
and remains a large part of that community, parts of what were kdelibs 
are now becoming part of qt5.  But at the same time, because qt's 
becoming more modular and much of it is now optional, all those extra 
features aren't bloating qt5 out of control, because if a developer 
doesn't need them he simply won't pull them in, and the modular 
components that are pulled in may well be far slimmer with qt5 than with 
qt4.

At the same time, kdelibs and the kdebase platform is similarly 
modularizing, allowing the same choice at the kde developer and user 
level as well as blurring the lines between what's qt and what's kde, 
since parts that were once kdelibs are now qt, but either way, they're 
now optional, so a formerly kde app may actually find itself only needing 
qt now, and even if it does pull in some kde libraries, because both the 
kde libs and qt are going modular, the dependencies may now well be 
smaller as a full kde app than they were previously as a qt-only app!

Up the stack at the application level, kde5 is breaking up and shipping 
most individual apps with their own version tagging and release timing, 
so apps that are evolving fast can ship updates every month or even every 
week if they wish, while already mature apps in primarily maintenance 
mode might ship an update a year, mostly just to keep them building on 
current libraries with current tools, with the occasional security update 
as well when necessary.

So the kde frameworks 5 core is going to be MUCH smaller, while most of 
the bundled apps we know as kde today will be unbundled and shipped 
separately, either as individual apps or possibly as a functional bundle 
-- dolphin and kmail and rekonq and konqueror and plasma will likely all 
release separately, with their own versions.  (Actually, some of them 
have their own versions now; kmail is version 2.something these days for 
instance, but nobody knows their kmail version without looking, they 
simply say kmail 4.11.2 or whatever, the kde version.)  But kdegames (for 
example) may still ship as a kdegames bundle, with a common kdegames (not 
kde) version.

That means currently qt-but-non-kde apps and desktop options may become 
more popular as well.  There's smplayer, and the razor-qt desktop.

The effect should be that individual kde apps will be chosen on their 
merits, no longer simply because they're part of kde, and people doing 
what I'm effectively already doing here, mixing a few kde apps with a few 
gtk apps with a few independent apps, picking the app in each case that 
best fits their needs, will become much more common.

Of course since I'm effectively already doing that, rejecting kmail since 
I don't like its akonadi and semantic-desktop dependencies and don't need 
that additional functionality, preferring the gtk-based claws-mail, and 
preferring firefox to konqueror/rekonq, but running it all on a (semantic-
desktopless) core kde desktop including plasma.

But what's going to be interesting is what happens with plasma vs the 
relatively new and much lighter razor-qt.  I expect the latter to become 
very popular as a kde-lite desktop base, while plasma will continue to be 
the full-featured alternative.  And then there's lxde, formerly a gtk-
based "lite" desktop, that's switching to qt and cooperating with razor-
qt in some development areas.  I expect quite a few former lxde folks 
will end up running more kde apps, since the dependency gap will be FAR 
smalle

Re: [kde] KDE's rough edges... what are your experiences?

[Kevin Krammer]

On Monday, 2013-10-28, 14:59:12, Michael wrote:

> > FWIW, my thinking on this is that it just happens that the kde devs
> > (and in particular the plasma devs, since that's the desktop kde
> > uses) have a particularly bad case of one of the traits very common
> > to free and open source application development and the developers
> > behind them -- the "developer scratches his own itch and stops when
> > it stops itching for him" phenomenon.
> 
> That "phenomenon" does exist, but again, I really hope it is not the
> main attitude in KDE-land. If I am wrong, then, developers please stand
> up and say "KDE is just for us, not for users that don't contribute /
> code".

I think we can safely assume that desktop developers do not share that 
attitude.
Some are certainly working towards a more long term goal, but in general a lot 
of how things are implemented suggest that they make customization as easy as 
possible, making it easy for others to either scratch their itch or find 
someone with a similar goal who is scratching theirs :)

> anyway) developers do stuff not only for them. And if stuff is not
> supposed to be for "everyone", why release it to the public in the first
> place?

Publishing makes sense even if there is only a subset of "everyone" who has 
the same needs. Even if one doesn't know if there is someone else.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Kevin Krammer]

On Monday, 2013-10-28, 17:56:50, Michael wrote:

> I feel without checking each ones claims how serious each and
> every issue KDE has is or how complex a bug-hunt would be, we can argue
> all day long how likely it is that any given issue is rather complex to
> track down. I can only speak for those issues that I found, reported
> and "helped" to track down with other projects (Xfce, Gnome, Mate, Linux
> Kernel, mdadm, mesa / radeon, smuxi (<3) ...) and on average it was not
> *that* hard to track the issue down. How complex a fix was... well, no
> real idea as I can't code / don't know C or any other programming
> language, but most of the time it was a thing of minutes a fix was
> there, or at least the discussion on how to actually fix the given
> issue started when the fix was not so obvious or easy to get right.

Right. I was mostly addressing the difficulty to find the actual cause and 
fixing it properly that often increases the overall time required to 
completely resolve an issue.

> > During analysis it is often estonishing how many different code paths
> > can be executed depending on factors one wouldn't have considered at
> > all.
> 
> Well, let's stop right here the argument how complex any given issue
> might get, just try to answer why KDE has compared to other DEs more
> issues, if you even agree there. If not, why do you think many users
> (me included) have such a "bad" opinion about KDE in that regard?

I don't know. I have basically no issues at all with the DE. I do run into 
issues with applications now and then, but the DE works for me in all 
situations.

I don't have a multi monitor setup, though I often have to connect a 
projector. However the projector is never used as a "second monitor" in the 
sense of having a separate panel or something.

> > Those are usually easy to fix then and make good candidates for
> > contribution entries. In KDE's issue system they sometimes get
> > labelled as JJ (Junior Job) to indicate that they are considered
> > suitable tasks for people who have not dived into the code base that
> > deep yet.
> 
> But I hope you do not expect any given user needs to learn C / QT to
> actually fix even those easy bugs.

Obviously not. Why would you think I would?

> A question I did ask already here
> and as you seem to be a KDE-developer (why else would you have such a
> fancy e-mail-address?)

I am but a @kde.org address is available to all long term contributors, not 
just developers.

> ... please describe the expectations the KDE
> project / developers have for their users. And...

I don't know. Since this discussion is about the DE aspect or KDE's DE product 
I can't say because I am not involved there.

> 1.) Do you agree that KDE is more "buggy" than other Desktop
> Environments?

Do you have any numbers? Are there more bug reports in a year files against 
Plasma Desktop than, say, GNOME Shell?

> 2.) If yes, why do you think KDE has so many issues?
> If no, how come many users have such a bad opinion about KDE?

I can't be sure, but a guess is that the Qt technologies used my Plasma 
Desktop had not been as good as the DE developers had assumed and/or applied 
it in a way that wasn't considered.

Or maybe they attempted too early to create a flexible package and had to work 
around limitations that they encountered but hadn't planned for.

Not sure about bad opinions. most of the initial uproar about the Plasma seems 
to have settled down and I think the desktop (also often referred to as 
workspace) team has made great improvements over time. 

> 3.) How could the situation change? For better not worse. :)

I would say that a lot of knowledge has been acquired over the last couple of 
years, i.e. on how to build flexible workspace shells, pitfalls, etc.

As I said before I don't have any internal insights into the team's work but 
their communicated plans sound good as far as I can tell.

> > > having any clue about the code itself. And it was an issue that was
> > > open for years and it clearly showed the lack (for whatever
> > > reasons) of interest upstream had in that issue.
> > 
> > How did you determine that it was a lack of interest and not a lack
> > of something else, e.g. resources?
> > Somebody commenting that they don't care?
> 
> "for whatever reason" did include possible time constraints and overall
> lack of resources.

Well, lack of interest is a very different thing than lack of resources and/or 
time. The "for whatever reason" was applied to "lack of interest".

> If a developer does not have enough time to address
> an issue, that means he prioritizes other issues higher.

Not necessarily. That would only be a valid conclusion if the assumption that 
the time is spent on other issues would hold.
Resources such as time could be, and often are, drained by aspects outside the 
KDE contributing.

> Which is fine,
> but that would be the reason behind the lack of interest. "Lack of
> interest" does not mean "I would have enough ti

Re: [kde] KDE's rough edges... what are your experiences?

[Duncan]

Frank Steinmetzger posted on Mon, 28 Oct 2013 20:36:02 +0100 as excerpted:

> I thought of not sending this, as it is more like a collection of bug
> whining, but after having spent lots of time on composing, it would be a
> waste of electrons not to send it.

FWIW, I've quit worrying much about that.  It used to bother me, but 
somewhere along the line I decided that if it took that long to compose 
and I decide it's not worth sending, I figure there must have been some 
reason I needed to write it for myself or I wouldn't have bothered 
writing it in the first place, so I'm the better for having written it, 
regardless of whether I send it or simply hit the X and close the window 
without sending.  So sometimes I do simply hit that X, even if it's an 
hour or more of work I'm blowing away.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Kevin Krammer]

On Tuesday, 2013-10-29, 13:42:16, Mirosław Zalewski wrote:
> Dnia 2013-10-29, o godz. 07:13:37
> 
> Draciron Smith  napisał(a):
> > The whole single click thing which cannot be modified too a
> > double click makes file transfers from disks an effort in frustration.
> 
> Unless something changed in 4.11 (I am still using 4.10), you can
> go to configuration dialog in Dolphin and there, in Navigation pane,
> make double click open files (single click selects, then).

Or in system settings, input devices, mouse

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Mirosław Zalewski]

Dnia 2013-10-29, o godz. 07:13:37
Draciron Smith  napisał(a):

> The whole single click thing which cannot be modified too a
> double click makes file transfers from disks an effort in frustration.

Unless something changed in 4.11 (I am still using 4.10), you can
go to configuration dialog in Dolphin and there, in Navigation pane,
make double click open files (single click selects, then).
-- 
Best regards
Mirosław Zalewski
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Draciron Smith]

I'm going to disagree with you there DE. KDE is the most user friendly of
desktops I've yet found. Odd behavior plagues all desktops, especially
windoze. That Unity insanity which Windows 8 apparently attempted to
mirror, trying to walk a new user through that garbage is like trying to
learn a foreign language AS you are teaching it to somebody else.  Gnome
just seems primitive and unfriendly to me. It's usable but I suffer plenty
of odd behavior under Gnome, probably more than under KDE.  I have my own
gripes about KDE (I still mourn the loss of Kedit for example. More so, so
many of KDE's default apps are so lame when compared to other KDE apps
availible). My biggest gripe is Dolphin which is all but unavoidable
because opening up removable drives is a real pain with far better file
managers. The whole single click thing which cannot be modified too a
double click makes file transfers from disks an effort in frustration. I
don't want to OPEN the thing, just because my control or shift key is not
quite pressed hard enough. I might want to click on it so I can right click
and view information or open with something other than default. Gah I HATE
using Dolphin for file management.

My complaints however are generally mild. The interface is highly
customizable, friendly and I spend my time doing stuff WITH my computer not
TOO it. KDE + Linux is an awesome combo. I can take a noob or an
experienced user and they are able to sit down with little or no KDE
experience and have at it. My daughter was 8 years old and without having
to teach her anything really she was able to sit down and use my KDE
machines. People look at Gnome or Unity or most other desktops and wonder
just how to get started and what to do.  I still prefer KDE 3 over KDE 4,
but the future of KDE has more than enough promise to stay with KDE. Just
wish I could get Kedit back and change the default file manager for
removable media.


On Mon, Oct 28, 2013 at 5:40 AM, dE  wrote:

> On 10/27/13 12:24, Michael wrote:
>
>> Hi peops,
>>
>> I somewhat force myself to use KDE (once again), even though I am very
>> likely to get annoyed rather fast when it comes to the KDE-specific
>> kind of issues. Issues, I have never seen with any other project to
>> that extent. And I ask myself, if others are annoyed too there or am I
>> just a whiny little bitch and no one else really bothers there?
>>
>> To describe the kind of issues I am referring to, some examples:
>> 1.) KSysGuard: I just closed a program via its own menu (file ->
>> close), wondered why even after several minutes (and even now, half an
>> hour later) KSysGuard still showed that process, so I did look with
>> "ps" and to my surprise, the process is *not* there anymore, but
>> KSysGuard shows it nevertheless in the "process table".
>> https://bugs.kde.org/show_bug.**cgi?id=261255
>>
>> 2.) Panels: Changed the "alignment" on one panel (for DualHead
>> "mirrored" panel setup), one should think now the alignment is changed
>> like in any other tool (mostly word processing tools I guess) but well,
>> it is not, widgets and stuff still want to "fall" to the left. I guess
>> because of that and other "bugs" there, several issues arise.
>> http://forum.kde.org/**viewtopic.php?f=67&t=94642
>> https://bugs.kde.org/show_bug.**cgi?id=248186
>> http://askubuntu.com/**questions/116040/how-to-right-**
>> align-widgets-in-panel-in-**kubuntu-11-10
>>
>> 3.) Widgets, plasmoids, generel KDE features: Yeah well, really nice
>> design (mostly), but from a usability standpoint? Often a mess. First
>> one sees a feature and thinks "Great" and later on he might realize how
>> bad that feature is implemented. I don't want to get into details yet,
>> as this mail is going to be long enough already, but if there is any
>> need and someone has no idea what I am talking about here, just ask. But
>> remember, I don't say all and everything is implemented badly, with
>> KDE-stuff it just looks to me the tendency is there that stuff gets
>> implemented in a rather weird / bad / less- to un-usable way.
>>
>> 4.) Weird messages and... stuff: Be it annoying phonon messages that a
>> audio device was removed, though it definitely was NOT, power-manager
>> framework telling me it doesn't work because of... yada yada, but it
>> does work nevertheless, starting others DEs stuff while KDE is running
>> (or the other way around) might screw things up bigtime, configuration
>> tends be be trashed every now and then, from one moment to the next (in
>> the process of configuring KDE for example, so no change to the
>> installed packages or other changes to the system) KDE may start to
>> behave "weird". Like starting KDE-apps (dolphin) takes several minutes
>> while other apps just start fast as before, conte

Re: [kde] KDE's rough edges... what are your experiences?

[Duncan]

Kevin Krammer posted on Mon, 28 Oct 2013 14:29:37 +0100 as excerpted:

> Well, you could have used a + instead of /, same number of characters,
> no? :)

Mmm, indeed.  Thanks for the hint.  It makes sense and I'll file it away 
to (hopefully remember to) use the next time. =:^)



-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Michael]

Hi Frank,

Am Mon, 28 Oct 2013 20:36:02 +0100
schrieb Frank Steinmetzger :

> On Sun, Oct 27, 2013 at 07:54:09AM +0100, Michael wrote:
> > Hi peops,
> > […]
> > 3.) Widgets, plasmoids, generel KDE features: Yeah well, really nice
> > design (mostly), but from a usability standpoint? Often a mess.
> 
> Plasma is a constant source of annoyance for me. I never really
> understood the need for a second UI style next to the “normal” one.
> The many animations that can’t be switched off and low contrasts are
> causes of grievance for me. There are layout bugs (notifications on a
> friend’s machine pop up in three places simultaneously), redrawing
> bugs (flicker in the taskbar when switching desktops), UI bugs (the
> scrollbars don’t adhere to the usual GUI behaviour like middle-click)
> and feature regressions (ksysguard graphs are nigh-useless in a
> panel).

I guess one has to be fair here. I guess KDE4 is designed to be
feature-rich, beautiful, with many bells and whistles. One could argue,
it is not designed to be stripped down to a bare minimum. I may be
wrong, but I see it like a person walking in a car-salon, he wants to
buy some means of transportation. As he is offered some cars, he
complains that they need fuel, that they are so heavy, that they pollute
the environment, that they need constant maintenance, that they need so
much space. Don't go to a car-salon, if you really want a motorcycle or
even a bike.
But agreed, low contrast on the gauges, bad design decisions and the
overall buginess, is something a car-owner does not want.
Btw. what about that netbook-design? Isn't that something specifically
designed for lower-end hardware?


> > 4.) […] configuration tends be be trashed every now and then, from
> > one moment to the next (in the process of configuring KDE for
> > example, so no change to the installed packages or other changes to
> > the system) KDE may start to behave "weird".
> 
> Akonadi, the problem child for many, is a nice example with its (for
> this human) incomprehensible config and data file layout. When I back
> up my setup or want to sync two machines, I’m never really sure what
> files to include and exclude if I, for example, want to sync only my
> address book data between machines. I went akonadi-free for a while
> on the netbook, but eventually installed it again because KMail just
> fits best into my Qt-centric computing ecosystem (although I prefer
> Firefox as main browser).

Yeah, there are several features KDE offers, which are hard to not miss
if one chooses to switch to another DE. But as time goes by, other DEs
might fill the gaps. I really don't need much, Cinnamon or Mate are
almost there. But, we'll see. And one thing is sure, other DEs do have
a better QA-reputation, so we might get features without all the
stability issues.


> > […]
> > So, that all said, what do you guys, users and maybe even
> > developers of KDE, think? I don't want to come around as rude or
> > overly harsh, as really, I think KDE is a great Desktop
> > Environment, it just has some really rough edges.
> 
> Sometimes I find myself using XFCE or even Awesome on my netbook for
> their sheer speed and easy go on resources. But from a convenience
> standpoint, KDE beats them all with nice extra features (KIO, global
> keyboard shortcuts, range of consistent base-applications). And even
> though I have some issues with it now and then (like reliable and
> *easy* file transfer via Bluetooth), I come back to KDE every time,
> despite it taking 20 hours to compile on an Atom. ^^

Eeks! Those gentooers... I really don't get them. :)


> > Is it just me, or are others also thinking KDE could / should invest
> > more efforts in QA and maybe less in implementing new stuff?
> 
> I, too, sometimes think “It’s a grave bug and so old already, why
> doesn’t it get fixed?eleven?”, like bad scrolling distances in
> Dolphin. But I suppose part of why I can’t always be accomodated with
> my problems is my diminishing use case -- KDE on a weak netbook.
> Brightness control is really messed up on *my* machine right now (it
> works, but KDE and ACPI fight over control, so I get temporary
> lockups). But I’m not the majority, so I can’t expect everything to
> go smoothly in all cases. After all, you get what you pay for. ;o)

Well, sure. Corner-case bugs that only face under rare and uncommon
circumstances might have a lower priority. But first, we are not
talking about these bugs, second, bug is bug, every bug should be
fixed. Even if lower-priority bugs might take longer.


> I suppose right now the migration to 5.0 takes lots of developer
> resources, so I imagine fixing bugs in “obsolete” 4 gets even less
> attention. I attempted fixing bugs before (and sent a patch in two
> instances), but it requires lots of work to get into the code,
> especially in bigger projects like Amarok or KMail.

Oh, KDE4 is more or less in "maintenance-mode"? Err... scratch that. As
of now I still believe maintenance is something t

Re: [kde] KDE's rough edges... what are your experiences?

[Frank Steinmetzger]

On Sun, Oct 27, 2013 at 07:54:09AM +0100, Michael wrote:
> Hi peops,
> […]
> 3.) Widgets, plasmoids, generel KDE features: Yeah well, really nice
> design (mostly), but from a usability standpoint? Often a mess.

Plasma is a constant source of annoyance for me. I never really
understood the need for a second UI style next to the “normal” one.  The
many animations that can’t be switched off and low contrasts are causes
of grievance for me. There are layout bugs (notifications on a friend’s
machine pop up in three places simultaneously), redrawing bugs (flicker
in the taskbar when switching desktops), UI bugs (the scrollbars don’t
adhere to the usual GUI behaviour like middle-click) and feature
regressions (ksysguard graphs are nigh-useless in a panel).

> 4.) […] configuration tends be be trashed every now and then, from one
> moment to the next (in the process of configuring KDE for example, so
> no change to the installed packages or other changes to the system)
> KDE may start to behave "weird".

Akonadi, the problem child for many, is a nice example with its (for
this human) incomprehensible config and data file layout. When I back up
my setup or want to sync two machines, I’m never really sure what files
to include and exclude if I, for example, want to sync only my address
book data between machines. I went akonadi-free for a while on the
netbook, but eventually installed it again because KMail just fits best
into my Qt-centric computing ecosystem (although I prefer Firefox as
main browser).

> […]
> So, that all said, what do you guys, users and maybe even developers of
> KDE, think? I don't want to come around as rude or overly harsh, as
> really, I think KDE is a great Desktop Environment, it just has some
> really rough edges.

Sometimes I find myself using XFCE or even Awesome on my netbook for
their sheer speed and easy go on resources. But from a convenience
standpoint, KDE beats them all with nice extra features (KIO, global
keyboard shortcuts, range of consistent base-applications). And even
though I have some issues with it now and then (like reliable and *easy*
file transfer via Bluetooth), I come back to KDE every time, despite it
taking 20 hours to compile on an Atom. ^^

> Is it just me, or are others also thinking KDE could / should invest
> more efforts in QA and maybe less in implementing new stuff?

I, too, sometimes think “It’s a grave bug and so old already, why
doesn’t it get fixed?eleven?”, like bad scrolling distances in Dolphin.
But I suppose part of why I can’t always be accomodated with my problems
is my diminishing use case -- KDE on a weak netbook. Brightness control
is really messed up on *my* machine right now (it works, but KDE and
ACPI fight over control, so I get temporary lockups). But I’m not the
majority, so I can’t expect everything to go smoothly in all cases.
After all, you get what you pay for. ;o)

I suppose right now the migration to 5.0 takes lots of developer
resources, so I imagine fixing bugs in “obsolete” 4 gets even less
attention. I attempted fixing bugs before (and sent a patch in two
instances), but it requires lots of work to get into the code,
especially in bigger projects like Amarok or KMail.



I thought of not sending this, as it is more like a collection of bug
whining, but after having spent lots of time on composing, it would be a
waste of electrons not to send it.
-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any Facebook service.

You call this cappucino?  It’s not even sprinkled with Parmesan!


signature.asc
Description: Digital signature
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Michael]

Am Mon, 28 Oct 2013 15:12:41 +0100
schrieb Kevin Krammer :

> Hi Michael,
> 
> On Monday, 2013-10-28, 12:22:15, Michael wrote:
> > Hi Kevin,
> > 
> > Am Sun, 27 Oct 2013 13:08:10 +0100
> > schrieb Kevin Krammer :
> > > On Sunday, 2013-10-27, 07:54:09, Michael wrote:
> > > > Granted, not all issues will face on every system, something
> > > > triggers the issues, sure. Not all users will think some stuff
> > > > is implemented weird and in a rather un-usable state (even if I
> > > > think something must be wrong with them then, as I can even
> > > > understand the Gnome-decisions and way of implementing
> > > > things!), not everyone has the same need and idea for a feature
> > > > and how to implement it. Some may never have any issue
> > > > whatsoever, be it just coincidence or they just don't use that
> > > > particular feature or at least not in a way that the issues
> > > > would show itself.
> > > 
> > > I guess this is at the heart of the problem, i.e. issues or weird
> > > behavior only triggered under certain circumstances.
> > > Computer systems have a huge variety of aspects, each potentially
> > > contributing to the observed behavior.
> > 
> > And I guess that is not the point, at least it is not the primary
> > point. Especially to negate such arguments I did provide some links
> > to show that the issues are NOT limited to corner-cases or weird and
> > unusual user setups.
> 
> I didn't claim it was the full problem, just that large number of
> influences is at the heart of the problem.

I feel without checking each ones claims how serious each and
every issue KDE has is or how complex a bug-hunt would be, we can argue
all day long how likely it is that any given issue is rather complex to
track down. I can only speak for those issues that I found, reported
and "helped" to track down with other projects (Xfce, Gnome, Mate, Linux
Kernel, mdadm, mesa / radeon, smuxi (<3) ...) and on average it was not
*that* hard to track the issue down. How complex a fix was... well, no
real idea as I can't code / don't know C or any other programming
language, but most of the time it was a thing of minutes a fix was
there, or at least the discussion on how to actually fix the given
issue started when the fix was not so obvious or easy to get right. At
least after all those years I tend to just think, the person who did
program the code, knows his / her way around to find an issue many
times rather fast. If KDE does differ there, no idea, but if so, why? I
would tend to think something must be awfully wrong then.


> During analysis it is often estonishing how many different code paths
> can be executed depending on factors one wouldn't have considered at
> all.

Well, let's stop right here the argument how complex any given issue
might get, just try to answer why KDE has compared to other DEs more
issues, if you even agree there. If not, why do you think many users
(me included) have such a "bad" opinion about KDE in that regard?


> Especially since an observed behavior is often just a symptom. Fixing
> the symptom is nice short term but finding the cause is the real deal.

Agreed, but see above.


> > > It often takes a concerted effort of many people to narrow down
> > > those candidates to the actually contributing factors in order to
> > > make a problem reproducable with enough reliability to analyse
> > > and fix it (including verification of the solution).
> > 
> > Even though that might be the case for some cases, it can't be for
> > the vast majority of issues, as I could easily reproduce most issues
> > reliable on different boxes.
> 
> Good :)
> I wasn't saying that all things are hard to reproduce, just that
> often narrowing down the variables to just the contributing factors
> can be time consuming.

Well, life is no pony ranch, right? ;-)


> > And yes, sometimes issues are really hard to track down. I myself
> > know that for a fact. But I do know that many issues are visible in
> > the code quite clearly too.
> 
> Those are usually easy to fix then and make good candidates for
> contribution entries. In KDE's issue system they sometimes get
> labelled as JJ (Junior Job) to indicate that they are considered
> suitable tasks for people who have not dived into the code base that
> deep yet.

But I hope you do not expect any given user needs to learn C / QT to
actually fix even those easy bugs. A question I did ask already here
and as you seem to be a KDE-developer (why else would you have such a
fancy e-mail-address?)... please describe the expectations the KDE
project / developers have for their users. And...

1.) Do you agree that KDE is more "buggy" than other Desktop
Environments?
2.) If yes, why do you think KDE has so many issues?
If no, how come many users have such a bad opinion about KDE?
3.) How could the situation change? For better not worse. :)


> > There may be issues in one part of the stack that
> > only affects some applications under some circumstances but it is
> > not 

Re: [kde] KDE's rough edges... what are your experiences?

[Michael]

Am Mon, 28 Oct 2013 14:33:24 +0100
schrieb Kevin Krammer :

> On Monday, 2013-10-28, 16:10:16, dE wrote:
> 
> > I think KDE is not suitable for production environment. Just for
> > casual enthusiasts.
> 
> I guess it will depend on the definition of those terms. I am sure
> the people who use KDE as their work place environment will enjoy
> learning that they are enthusiasts in yours :)
> 
> > As of your problems -- if you continue to use KDE, you'll get used
> > to it. For e.g. now removable disks will now show up in device
> > manager.
> 
> Removable disks show up in device manager for quite some time now.
> But I guess it might also depend on the definition of now.
> Had that since KDE3 times, so now would several years back :)

I guess he meant to say "Now removable disks do NOT show..." but I
can't confirm that issue here.

optimistic regards
Michael
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Michael]

Am Mon, 28 Oct 2013 16:10:16 +0530
schrieb dE :

> I think KDE is not suitable for production environment. Just for
> casual enthusiasts.

I guess that view is a bit too extreme, but interesting nevertheless.
As annoying as the "typical" KDE-issues might be or get, there will be
a point where users know the issues and can adapt to the "buggy"
situation, so that KDE is not a general "show stopper" to their
workflow. For example with the KSysGuard-thing mentioned earlier, one
just has to restart KSysGuard to get a reliable depiction what
processes currently run or simply not use it at all.


> As of your problems -- if you continue to use KDE, you'll get used to 
> it. For e.g. now removable disks will now show up in device manager. 
> I've to restart KDE to fix it.

Used to it? That is most unlikely. I could tolerate such issues for
some time but I guess I could never "adapt" to a point where I would
not even realize the issues anymore.


> I think the most stable release of KDE is at best beta.

Do you think the KDE developers are happy with that "state"? And "beta"
implies "bugfixing follows". If bugs don't get addressed, they could
dump the code as public domain and be done with it. So I really hope
the situation is just at a very bad point but it will get better, even
if it takes years, I am in no hurry. :)

optimistic regards
Michael
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Kevin Krammer]

Hi Michael,

On Monday, 2013-10-28, 12:22:15, Michael wrote:
> Hi Kevin,
> 
> Am Sun, 27 Oct 2013 13:08:10 +0100
> schrieb Kevin Krammer :
> > On Sunday, 2013-10-27, 07:54:09, Michael wrote:
> > > Granted, not all issues will face on every system, something
> > > triggers the issues, sure. Not all users will think some stuff is
> > > implemented weird and in a rather un-usable state (even if I think
> > > something must be wrong with them then, as I can even understand
> > > the Gnome-decisions and way of implementing things!), not everyone
> > > has the same need and idea for a feature and how to implement it.
> > > Some may never have any issue whatsoever, be it just coincidence or
> > > they just don't use that particular feature or at least not in a
> > > way that the issues would show itself.
> > 
> > I guess this is at the heart of the problem, i.e. issues or weird
> > behavior only triggered under certain circumstances.
> > Computer systems have a huge variety of aspects, each potentially
> > contributing to the observed behavior.
> 
> And I guess that is not the point, at least it is not the primary
> point. Especially to negate such arguments I did provide some links to
> show that the issues are NOT limited to corner-cases or weird and
> unusual user setups.

I didn't claim it was the full problem, just that large number of influences 
is at the heart of the problem.
During analysis it is often estonishing how many different code paths can be 
executed depending on factors one wouldn't have considered at all.

Especially since an observed behavior is often just a symptom. Fixing the 
symptom is nice short term but finding the cause is the real deal.

> > It often takes a concerted effort of many people to narrow down those
> > candidates to the actually contributing factors in order to make a
> > problem reproducable with enough reliability to analyse and fix it
> > (including verification of the solution).
> 
> Even though that might be the case for some cases, it can't be for the
> vast majority of issues, as I could easily reproduce most issues
> reliable on different boxes.

Good :)
I wasn't saying that all things are hard to reproduce, just that often 
narrowing down the variables to just the contributing factors can be time 
consuming.

> And yes, sometimes issues are really hard to track down. I myself know
> that for a fact. But I do know that many issues are visible in the code
> quite clearly too.

Those are usually easy to fix then and make good candidates for contribution 
entries. In KDE's issue system they sometimes get labelled as JJ (Junior Job) 
to indicate that they are considered suitable tasks for people who have not 
dived into the code base that deep yet.

Sometimes those turn out to be just a short term measure which hides the 
actual problem though. Still a good start.

> There may be issues in one part of the stack that
> only affects some applications under some circumstances but it is not
> clear where in the stack the actual bug is. But for many other issues,
> it is quite clear where the issue lies, or at least where it most
> likely lies. Over the years I did report an abundance of different
> issues, be it kernel or userspace related. I'd say 90% of them were
> rather easy to track down. With some help from a friend who knows
> *some* C we were able to track down one bug without having any clue
> about the code itself. And it was an issue that was open for years and
> it clearly showed the lack (for whatever reasons) of interest upstream
> had in that issue.

How did you determine that it was a lack of interest and not a lack of 
something else, e.g. resources?
Somebody commenting that they don't care?

> > > So, that all said, what do you guys, users and maybe even
> > > developers of KDE, think? I don't want to come around as rude or
> > > overly harsh, as really, I think KDE is a great Desktop
> > > Environment, it just has some really rough edges. Is it just me, or
> > > are others also thinking KDE could / should invest more efforts in
> > > QA and maybe less in implementing new stuff? I know, "send patch"
> > > yada yada... that does not apply here, at least not well enough.
> > 
> > It does apply here as well. While sending a patch is a particular
> > form of contribution, e.g. providing a potential fix, it is generally
> > a suggestion to get involved [1] in the process of finding a solution.
> 
> No it does not apply WELL! It does apply to a certain and rather
> limited degree, but hell no, not on an average scale.

Why not? Suggesting involvment is a nice way to emphasis that the project 
and/or community is open, that the reporter is not assumed to be clueless or 
incapable just because there has been no prior contact, etc.

You would be surprised how often people assume that something is out of their 
hands or that their potential work would not be considered of good enough 
quality.

I've seen people enthusiastically rework whole wikis once they found o

Re: [kde] KDE's rough edges... what are your experiences?

[Michael]

Hi Duncan,

Hell! Don't take it the wrong way, but I strongly suggest you rethink
your way of "communicating" on mailinglists. You went in such lengths
in absolutely unrelated topics and even with slightly related topics
you went by far, far, far, far to deep. It was really no pleasure at
all to read it all, which I had to as courtesy demands it, as I did ask
for feedback. And what I took from your 25.457 characters in 441 lines
and 4270 words would fit in roundabout 10-20 lines.

If you really feel the urge to go into such detail, do everyone on the
list a favour and divide your mails in two parts. One where you try to
stick to the topic as closely as possible and a second one which you
mark as "detailed stuff" or whatever fits the situation. So others
can choose to read it all, or just get the essentials out of it. As for
me, I am really in no way interested how you configured your KDE, how
much you like gentoo, what features gentoo has, what assumptions and
possible ways to debug all those possible issues have, especially not in
SUCH DETAIL (including the redundant repetition that happened several
times).

But enough critics... let's get to your mail.

 Am Sun, 27 Oct 2013 16:47:08 + (UTC)
schrieb Duncan <1i5t5.dun...@cox.net>:

> Michael posted on Sun, 27 Oct 2013 07:54:09 +0100 as excerpted:
> 
> > Hi peops,
> > 
> > I somewhat force myself to use KDE (once again), even though I am
> > very likely to get annoyed rather fast when it comes to the
> > KDE-specific kind of issues. Issues, I have never seen with any
> > other project to that extent. And I ask myself, if others are
> > annoyed too there or am I just a whiny little bitch and no one else
> > really bothers there?
> 
> There are certainly issues with most desktop environments.
> [snip]

All software tends to have issues, but this conversation here is solely
about KDEs possible QA-issues and if you folks think the situation is
worse compared to other Desktop Environments or not. So it is a rather
limited scope I follow here and I humbly ask of you to stay on topic as
good as possible as chances are the topic will get heated anyway.


> > To describe the kind of issues I am referring to, some examples:
> 
> > 1.) KSysGuard: I just closed a program via its own menu (file ->
> > close), wondered why even after several minutes (and even now, half
> > an hour later) KSysGuard still showed that process, so I did look
> > with "ps" and to my surprise, the process is *not* there anymore,
> > but KSysGuard shows it nevertheless in the "process table".
> > https://bugs.kde.org/show_bug.cgi?id=261255
>
> [snip] 
>
> First point, most directly apropos to that bug, while I'd /think/ it 
> would be obvious enough to note as it was my immediate first question 
> upon reading the above, you didn't above and nobody seems to have
> noted it specifically in any of the bug comments either...

Well, because it is save to assume no one would be that  to
deliberately set that value to "0" and because the default is something
sane as "2" seconds? And of course because it was said more than once,
that not every application / process did still show up after closing
it. So your idea does not make much (if any) sense.

 
> What do you have the sheet/tab properties update interval set for?
> If it's set to zero, it's not going to update and of course the
> information will ultimately go stale.  Similarly if the interval is
> maxed out... here the max it will let me enter is 1000 seconds, aka
> 16 minutes 40 seconds. You do mention half an hour so it should have
> updated in that time, but perhaps only once.

...

default, 2 seconds


>
> [snip]
>
> > 2.) Panels: Changed the "alignment" on one panel (for DualHead
> > "mirrored" panel setup), one should think now the alignment is
> > changed like in any other tool (mostly word processing tools I
> > guess) but well, it is not, widgets and stuff still want to "fall"
> > to the left. I guess because of that and other "bugs" there,
> > several issues arise.
> 
> FWIW, I'd not think that at all.
> 
> In fact, quite the contrary, just because I switch a panel from one
> end of the edge its on to the other, does NOT mean I want or expect
> the individual plasmoids to change alignment within the panel as
> well!  I'd go so far as to consider it a bug if they did!

Well, there is an option one can set for the "alignment" on the panel.
It offers right, left and middle. for What else should that
alignment be?


> > http://forum.kde.org/viewtopic.php?f=67&t=94642
> > https://bugs.kde.org/show_bug.cgi?id=248186
> > http://askubuntu.com/questions/116040/how-to-right-align-widgets-in-
> panel-in-kubuntu-11-10
> 
> In general panel plasmoid alignment and spacing in kde4 plasma has
> ALWAYS been buggy at best.

Well, figures. But at least other DEs have trouble with sane
panel-behaviour as well, even if I'd say it is not as "broken" there it
is more like they lack some feature to make it behave in a sane way,
whereas in KDE it offers fe

Re: [kde] KDE's rough edges... what are your experiences?

[Kevin Krammer]

On Monday, 2013-10-28, 16:10:16, dE wrote:

> I think KDE is not suitable for production environment. Just for casual
> enthusiasts.

I guess it will depend on the definition of those terms. I am sure the people 
who use KDE as their work place environment will enjoy learning that they are 
enthusiasts in yours :)

> As of your problems -- if you continue to use KDE, you'll get used to
> it. For e.g. now removable disks will now show up in device manager.

Removable disks show up in device manager for quite some time now. But I guess 
it might also depend on the definition of now.
Had that since KDE3 times, so now would several years back :)

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Kevin Krammer]

On Monday, 2013-10-28, 09:42:07, Duncan wrote:
> Kevin Krammer posted on Sun, 27 Oct 2013 21:23:05 +0100 as excerpted:
> >> Those commercial/proprietary model proponents do have a point, that IS
> >> a weakness of FLOSS
> > 
> > I think the problem with this statement is mixing terms for orthogonal
> > properties into one.
> > A commercial product is something that is monetarized, a proprietary
> > product is something that only one entity has source access to, a FLOSS
> > product is something that is also available in source to anyone.
> > 
> > Since some of those labels are for orthogonal concepts, they can appear
> > in different combinations.
> 
> FWIW, that's actually why I chose to use both terms, commercial/
> proprietary, instead of just one or the other by itself. 

I see. I read the / as a way to suggest replacability, especially since the 
context on the "other side" was just FLOSS not something like FLOSS/.

> The group of
> people (and their argument) I had in mind are rather specifically the
> proponents of /both/ concepts unified.  There's commercial software
> that's FLOSS, but this argument is unlikely to be made there, because
> it's hitting too close to home -- they're often built on non-commercial
> FLOSS components so they're in effect arguing that the choice of
> components they made was a poor one.  And there's proprietary software
> that's not commercial, but there too, this particular argument is
> unlikely to be put forward, because often, the argument actually applies
> to them to some degree as well (they scratched their own itch and then
> simply made the binaries public, but kept the sources to themselves).

Exactly. So it is important IMHO not to repeat the omissions but to show that 
the comparison was non-sensical in the first place.

> So it's the specific combination of /both/ commercial and proprietary
> that tends to put forth this argument, and as I said, they do have a
> point, but it's my opinion that the balance of things is still
> overwhelmingly against commercial/proprietary, even if they do score a
> minor point with this one argument.

I don't think they have a point because they conciously conflate areas to 
which there criticism does not apply into the same abbreviation.
More over using an abbreviation that covers the one aspect of the competing 
product that has least to do with their allegded advantage/disadvantage 
comparison.

> Tho arguably in ordered to make that clear, I should have specified
> commercial _and_ proprietary (both together, not just one), but I was
> attempting to abbreviate the concept and argument, and as often happens
> when I try that, someone came along to point out the gap I left with my
> impreciseness. =:^/

Well, you could have used a + instead of /, same number of characters, no? :)
Anyway, I was mostly commenting on the second part of the comparison, see 
above.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Michael]

Hi Kevin,

Am Sun, 27 Oct 2013 13:08:10 +0100
schrieb Kevin Krammer :

> On Sunday, 2013-10-27, 07:54:09, Michael wrote:
> 
> > Granted, not all issues will face on every system, something
> > triggers the issues, sure. Not all users will think some stuff is
> > implemented weird and in a rather un-usable state (even if I think
> > something must be wrong with them then, as I can even understand
> > the Gnome-decisions and way of implementing things!), not everyone
> > has the same need and idea for a feature and how to implement it.
> > Some may never have any issue whatsoever, be it just coincidence or
> > they just don't use that particular feature or at least not in a
> > way that the issues would show itself.
> 
> I guess this is at the heart of the problem, i.e. issues or weird
> behavior only triggered under certain circumstances.
> Computer systems have a huge variety of aspects, each potentially
> contributing to the observed behavior.

And I guess that is not the point, at least it is not the primary
point. Especially to negate such arguments I did provide some links to
show that the issues are NOT limited to corner-cases or weird and
unusual user setups. But sure, I HAD to acknowledge that SOME issues
may be indeed caused by rather unusual setups or even localized
system / distro issues, as I can't possibly know all issues that all
users might have and the cause of those. And that's why I took great
care to phrase KDE SEEMS to have the TENDENCY for such issues compared
to other Desktop Environments rather than using somewhat more
"definitive" words. 


> It often takes a concerted effort of many people to narrow down those 
> candidates to the actually contributing factors in order to make a
> problem reproducable with enough reliability to analyse and fix it
> (including verification of the solution).


Even though that might be the case for some cases, it can't be for the
vast majority of issues, as I could easily reproduce most issues
reliable on different boxes. As a matter of fact the only one I can not
reproduce is the one where many things KDE-related took minutes to
complete. Starting from starting apps, to showing dialog-boxes and a
context-menu. Granted, some issues might be tricky to reproduce, but if
one really wants to, not a real problem. For example waiting until
ksysguard shows processes that are gone already, *might* take some
time, even though that was not an issue here. I just waited some time
and did check every now and then on a different machine if processes I
did close there are shown or not.
And yes, sometimes issues are really hard to track down. I myself know
that for a fact. But I do know that many issues are visible in the code
quite clearly too. There may be issues in one part of the stack that
only affects some applications under some circumstances but it is not
clear where in the stack the actual bug is. But for many other issues,
it is quite clear where the issue lies, or at least where it most
likely lies. Over the years I did report an abundance of different
issues, be it kernel or userspace related. I'd say 90% of them were
rather easy to track down. With some help from a friend who knows
*some* C we were able to track down one bug without having any clue
about the code itself. And it was an issue that was open for years and
it clearly showed the lack (for whatever reasons) of interest upstream
had in that issue.  


> > So, that all said, what do you guys, users and maybe even
> > developers of KDE, think? I don't want to come around as rude or
> > overly harsh, as really, I think KDE is a great Desktop
> > Environment, it just has some really rough edges. Is it just me, or
> > are others also thinking KDE could / should invest more efforts in
> > QA and maybe less in implementing new stuff? I know, "send patch"
> > yada yada... that does not apply here, at least not well enough.
> 
> It does apply here as well. While sending a patch is a particular
> form of contribution, e.g. providing a potential fix, it is generally
> a suggestion to get involved [1] in the process of finding a solution.

No it does not apply WELL! It does apply to a certain and rather
limited degree, but hell no, not on an average scale. I know and
absolutely agree that KDE and GNU/Linux in general is
contribution-driven to some degree, but that is it exactly: to some
degree! Most projects want their users to just report bugs and if
something is not clear help them to reproduce a bug and maybe even
track it down with some trial and error approach. Almost no project I
know of thinks (or expects) that most if not all users can actually
code, know any computer language or are able to fix the issues on their
own. Sure, the prjects are glad if patches come from the userbase, but
they don't *expect* it! I just guess that over 95% of users using any
given software on GNU/Linux / *BSD are not anywhere near to be able to
fix anything. So "send patch", if that is the sole kind of approach
that is a

Re: [kde] KDE's rough edges... what are your experiences?

[dE]

On 10/27/13 12:24, Michael wrote:

Hi peops,

I somewhat force myself to use KDE (once again), even though I am very
likely to get annoyed rather fast when it comes to the KDE-specific
kind of issues. Issues, I have never seen with any other project to
that extent. And I ask myself, if others are annoyed too there or am I
just a whiny little bitch and no one else really bothers there?

To describe the kind of issues I am referring to, some examples:
1.) KSysGuard: I just closed a program via its own menu (file ->
close), wondered why even after several minutes (and even now, half an
hour later) KSysGuard still showed that process, so I did look with
"ps" and to my surprise, the process is *not* there anymore, but
KSysGuard shows it nevertheless in the "process table".
https://bugs.kde.org/show_bug.cgi?id=261255

2.) Panels: Changed the "alignment" on one panel (for DualHead
"mirrored" panel setup), one should think now the alignment is changed
like in any other tool (mostly word processing tools I guess) but well,
it is not, widgets and stuff still want to "fall" to the left. I guess
because of that and other "bugs" there, several issues arise.
http://forum.kde.org/viewtopic.php?f=67&t=94642
https://bugs.kde.org/show_bug.cgi?id=248186
http://askubuntu.com/questions/116040/how-to-right-align-widgets-in-panel-in-kubuntu-11-10

3.) Widgets, plasmoids, generel KDE features: Yeah well, really nice
design (mostly), but from a usability standpoint? Often a mess. First
one sees a feature and thinks "Great" and later on he might realize how
bad that feature is implemented. I don't want to get into details yet,
as this mail is going to be long enough already, but if there is any
need and someone has no idea what I am talking about here, just ask. But
remember, I don't say all and everything is implemented badly, with
KDE-stuff it just looks to me the tendency is there that stuff gets
implemented in a rather weird / bad / less- to un-usable way.

4.) Weird messages and... stuff: Be it annoying phonon messages that a
audio device was removed, though it definitely was NOT, power-manager
framework telling me it doesn't work because of... yada yada, but it
does work nevertheless, starting others DEs stuff while KDE is running
(or the other way around) might screw things up bigtime, configuration
tends be be trashed every now and then, from one moment to the next (in
the process of configuring KDE for example, so no change to the
installed packages or other changes to the system) KDE may start to
behave "weird". Like starting KDE-apps (dolphin) takes several minutes
while other apps just start fast as before, context-menu might need
*minutes* to open, shutdown-, reboot-, logout-popup takes minutes to
show...

And a bunch of other stuff that might just happen when using KDE that
somewhat feels... well... awkward, weird, annoying. Bottom line, it
feels like a lot of rough edges and that those edges might be smoothed
out eventually, but apparently it looks like they don't, as where I
pointed out links to bugtracker or forum-posts, the issues are as old as
Methusalems grandpa. With other DEs (Gnome2 + 3, Mate, Xfce, LXDE, e17)
I have never seen that amount of "roughness". They might have other
"issues", like the apparent need the Gnome-devs feel to get rid of
every useful feature ;) (well, I could be more fair there, but I am on
a KDE list anyway, so no need for gnome-devs-understaning, right? *g*),
but I always had the feeling the "rough" edges were smoothed out from
release to release. I was not always happy with the way issues were
addressed, but at least I could understand why it makes sense for some
or even most users to have an issue resolved in that particular way it
was addressed with.

Granted, not all issues will face on every system, something triggers
the issues, sure. Not all users will think some stuff is implemented
weird and in a rather un-usable state (even if I think something must
be wrong with them then, as I can even understand the Gnome-decisions
and way of implementing things!), not everyone has the same need and
idea for a feature and how to implement it. Some may never have any
issue whatsoever, be it just coincidence or they just don't use that
particular feature or at least not in a way that the issues would show
itself.

So, that all said, what do you guys, users and maybe even developers of
KDE, think? I don't want to come around as rude or overly harsh, as
really, I think KDE is a great Desktop Environment, it just has some
really rough edges. Is it just me, or are others also thinking KDE
could / should invest more efforts in QA and maybe less in implementing
new stuff? I know, "send patch" yada yada... that does not apply here,
at least not well enough.

Optimistic greetings
Michael
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.

Re: [kde] KDE's rough edges... what are your experiences?

[Duncan]

Kevin Krammer posted on Sun, 27 Oct 2013 21:23:05 +0100 as excerpted:

>> Those commercial/proprietary model proponents do have a point, that IS
>> a weakness of FLOSS
> 
> I think the problem with this statement is mixing terms for orthogonal
> properties into one.
> A commercial product is something that is monetarized, a proprietary
> product is something that only one entity has source access to, a FLOSS
> product is something that is also available in source to anyone.
> 
> Since some of those labels are for orthogonal concepts, they can appear
> in different combinations.

FWIW, that's actually why I chose to use both terms, commercial/
proprietary, instead of just one or the other by itself.  The group of 
people (and their argument) I had in mind are rather specifically the 
proponents of /both/ concepts unified.  There's commercial software 
that's FLOSS, but this argument is unlikely to be made there, because 
it's hitting too close to home -- they're often built on non-commercial 
FLOSS components so they're in effect arguing that the choice of 
components they made was a poor one.  And there's proprietary software 
that's not commercial, but there too, this particular argument is 
unlikely to be put forward, because often, the argument actually applies 
to them to some degree as well (they scratched their own itch and then 
simply made the binaries public, but kept the sources to themselves).

So it's the specific combination of /both/ commercial and proprietary 
that tends to put forth this argument, and as I said, they do have a 
point, but it's my opinion that the balance of things is still 
overwhelmingly against commercial/proprietary, even if they do score a 
minor point with this one argument.

Tho arguably in ordered to make that clear, I should have specified 
commercial _and_ proprietary (both together, not just one), but I was 
attempting to abbreviate the concept and argument, and as often happens 
when I try that, someone came along to point out the gap I left with my 
impreciseness. =:^/

I guess I should be happy that people are paying enough attention to what 
I wrote to notice that gap. =:^)  Plus of course that's a common pattern 
on public lists/newsgroups/forums anyway; someone stakes out an original 
position, then others come along and expand on it, filling in the gaps as 
well as calling attention to cases where it doesn't apply, thus inviting 
further adjustment of the original position, developing and honing the 
now common work until the whole is a far better product than any 
individual would/could have posted on their own.  =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Kevin Krammer]

On Sunday, 2013-10-27, 16:47:08, Duncan wrote:

> FWIW, my thinking on this is that it just happens that the kde devs (and
> in particular the plasma devs, since that's the desktop kde uses) have a
> particularly bad case of one of the traits very common to free and open
> source application development and the developers behind them -- the
> "developer scratches his own itch and stops when it stops itching for
> him" phenomenon.

I don't think so. Most applications have way more features than what the 
respective handful of developers would be using themselves.
What is most likely true though is that those features which are not used by 
the developers themselves need to receive active and continuous testing by 
other contributors lest they easily break.

> Those commercial/proprietary model proponents do have a point, that IS a
> weakness of FLOSS

I think the problem with this statement is mixing terms for orthogonal 
properties into one.
A commercial product is something that is monetarized, a proprietary product 
is something that only one entity has source access to, a FLOSS product is 
something that is also available in source to anyone.

Since some of those labels are for orthogonal concepts, they can appear in 
different combinations.

E.g. a FLOSS product is not necessarily developed by a community of 
individuals, nor is it necessarily non-commerical.
A proprietary product is also not necessarily commercial, etc.

Proprietary software vendors often get a free pass at stabs at FLOSS software 
because they managed to make people think of certain combinations as opposite 
sides.

Lets take for example a commercial, single-vendor product. Whether the code is 
proprietary or FLOSS licensed does not change its commercial status, does not 
change the development model, etc.
If the vendor is responsive enough to implement new features and fix bugs 
there migth not even be a pratical difference from user point of view.
However, should the vendor not be responsive enough, then a FLOSS license 
would make the vendor one of several options for change.

This enabling of users to take their business elsewhere is why proprietary 
vendors try their best to fold all kinds of unrelated aspects into the FLOSS 
moniker, so people don't see that they can't get this advantage from the 
proprietary vendor but can get all other advantages from a non-proprietary 
one.

This subterfuge is slowly breaking down though, as more and more categories of 
users see the bigger picture, see how different aspects affect different 
properties of the software they are using.

I think it is important that we as users of FLOSS software understand and 
communicate how the different influences work together.

For example for KDE products, the available features and/or development 
direction is most strongly influenced by the volunteer community driven 
development aspect, a bit by the non-commercial aspect and negligibly by the 
licensing aspect [1].

Other things are more influences by the non-commercial aspect, e.g. 
availability of services.

And again other things, like customizability, are most strongly influenced by 
the licensing aspect, i.e. the license enabling others to provide tailoring.

Cheers,
Kevin

[1] licensing obviously influences the amount of volunteers but it has only 
little direct impact on feature availability

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] KDE's rough edges... what are your experiences?

[Duncan]

Michael posted on Sun, 27 Oct 2013 07:54:09 +0100 as excerpted:

> Hi peops,
> 
> I somewhat force myself to use KDE (once again), even though I am very
> likely to get annoyed rather fast when it comes to the KDE-specific kind
> of issues. Issues, I have never seen with any other project to that
> extent. And I ask myself, if others are annoyed too there or am I just a
> whiny little bitch and no one else really bothers there?

There are certainly issues with most desktop environments.  But I've yet 
to find one I like in its default state and I doubt I ever will, which by 
definition means I tend to be a *HEAVY* customizer, and kde does tend to 
support a higher level of customization than most desktops.

But that doesn't by any means mean I don't have my own frustrating 
issues...

> To describe the kind of issues I am referring to, some examples:

> 1.) KSysGuard: I just closed a program via its own menu (file ->
> close), wondered why even after several minutes (and even now, half an
> hour later) KSysGuard still showed that process, so I did look with "ps"
> and to my surprise, the process is *not* there anymore, but KSysGuard
> shows it nevertheless in the "process table".
> https://bugs.kde.org/show_bug.cgi?id=261255

ksysguard is an interesting one.  There's a couple points I can make 
about it, with the second leading into a rather wider discussion, and 
finally a third point/hunch that might be worth investigating, just in 
case.

First point, most directly apropos to that bug, while I'd /think/ it 
would be obvious enough to note as it was my immediate first question 
upon reading the above, you didn't above and nobody seems to have noted 
it specifically in any of the bug comments either...

What do you have the sheet/tab properties update interval set for?  If 
it's set to zero, it's not going to update and of course the information 
will ultimately go stale.  Similarly if the interval is maxed out... here 
the max it will let me enter is 1000 seconds, aka 16 minutes 40 seconds.  
You do mention half an hour so it should have updated in that time, but 
perhaps only once.

Given the importance of the question I can't see why nobody on that bug 
(or you above) specifically mentions that they do NOT have the update 
interval set to zero and what they DO have it set at.  Similarly, nobody 
mentions whether OTHER processes are updating or whether it's essentially 
a static display of a one-shot sample, which would explain...  That may 
or may not be the issue, but if it isn't, how can such basic information 
be overlooked in the bug report or here?  That implies people simply 
haven't checked, which means it well COULD be the issue!

The second point is a MUCH more general point, applying both to ksysguard 
and to kde, specifically kde4, in general.

ksysguard was in fact one of my early kde4 pain points.  Back in the late 
kde3 era, I had the ksysguard kicker applet running constantly on one of 
my kicker panels, real-time graphing various system statistics and 
performance metrics including cpu (user/system/nice stacked together in a 
single plotter so the total of all three was also the total CPU usage), 
memory (app/cache/buffer stacked), network traffic, etc.

In early kde4, not only was there no plasmoid replacement for what I 
considered a very vital kicker applet, but even simply running ksysguard 
with the various plotters, etc I wanted and forcing the window position 
and always-on-top didn't work, as ksysguard itself was horribly broken!  
I remember that plotters didn't work well, for one thing, but there were 
a couple other problems with it too, that I've forgotten now.

Now it should be noted that while I said "early" kde4, this was *NOT* the 
kde 4.0/4.1 era, when the kde devs themselves admitted kde4 wasn't ready 
for ordinary use.  This was in fact late 4.2 and into 4.3, when the 
message was that kde4 was supposed to be ready for ordinary users, 
despite all sorts of horribly broken behavior remaining (and filed as 
bugs so the devs knew about them), including ksysguard's problems!   In 
fact, at the same time they were insisting that kde4 was ready for normal 
(as in, not beta testing!) users and that they weren't supporting kde3 
any more, on some bugs they were still saying that functionality critical 
to the way various users used kde hadn't yet been ported from kde3 yet!

Well, I've been running alphas/previews/pre-releases from the early MS 
Windows days when MS-DOS was still the primary OS (tho FWIW I left 
proprietary servantware behind and switched to Linux when eXPrivacy came 
out, as it crossed lines I simply wasn't going to cross!), both big money 
commercial stuff and single developer level, freedomware and servantware, 
and one thing I know about pre-release software is that if critical 
functionality isn't yet implemented, it's *NOT* considered release 
quality, ready for normal users, in fact it's not even BETA, that's ALPHA 
quality.  (Beta is commonly defined a

Re: [kde] KDE's rough edges... what are your experiences?

[Kevin Krammer]

On Sunday, 2013-10-27, 07:54:09, Michael wrote:

> Granted, not all issues will face on every system, something triggers
> the issues, sure. Not all users will think some stuff is implemented
> weird and in a rather un-usable state (even if I think something must
> be wrong with them then, as I can even understand the Gnome-decisions
> and way of implementing things!), not everyone has the same need and
> idea for a feature and how to implement it. Some may never have any
> issue whatsoever, be it just coincidence or they just don't use that
> particular feature or at least not in a way that the issues would show
> itself.

I guess this is at the heart of the problem, i.e. issues or weird behavior 
only triggered under certain circumstances.
Computer systems have a huge variety of aspects, each potentially contributing 
to the observed behavior.

It often takes a concerted effort of many people to narrow down those 
candidates to the actually contributing factors in order to make a problem 
reproducable with enough reliability to analyse and fix it (including 
verification of the solution).

> So, that all said, what do you guys, users and maybe even developers of
> KDE, think? I don't want to come around as rude or overly harsh, as
> really, I think KDE is a great Desktop Environment, it just has some
> really rough edges. Is it just me, or are others also thinking KDE
> could / should invest more efforts in QA and maybe less in implementing
> new stuff? I know, "send patch" yada yada... that does not apply here,
> at least not well enough.

It does apply here as well. While sending a patch is a particular form of 
contribution, e.g. providing a potential fix, it is generally a suggestion to 
get involved [1] in the process of finding a solution.

That process starts at, as I outline above, narrowing down contributing 
factors, ideally resulting in a situation that will show the faulty behavior 
on a development setup.

Cheers,
Kevin

[1] http://community.kde.org/Getinvolved/Quality
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.