[gentoo-amd64] Heads-up: KDEers: Particularly kde3-ers,

[gentoo-amd64] Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

Those of you kde-ers, particularly kde3-ers (aka stable kde-ers),
heads-up!

If you aren't aware of the current gentoo kde (especially kde3) 
situation, you *NEED* to subscribe to the gentoo-desktop list (normally 
lower activity than here, so it shouldn't be a huge burden), AND check 
the archives for the last couple months.

The short version:  kde3 is likely going to be masked, soon, apparently 
very possibly before any kde4 is ever marked stable.  The current plan is 
to leave kde3 in-tree but masked, probably until early next year, at 
which point it'll move to an overlay, kde-sunset or similarly named, 
where it'll be maintained primarily by interested users.

If any Gentoo kde3 user has the skills and time to volunteer, 
particularly if you are /not/ planning to move to kde4 in the near 
future, they're looking for a Gentoo kde3 dev or two, and/or skilled kde3 
users who can devote time to it.

The reasoning is multi-fold.  Unfortunately, while upstream KDE gets all 
nasty if you try to call kde3 unmaintained and asegio famously blogged a 
year or so ago that it would be maintained as long as there were users, 
apparently, unmaintained is what it's becoming in actual practice, 
regardless of /what/ upstream kde wants to call it.  What's happening is 
that they aren't strongly encouraging KDE devs to continue to maintain 
the old kde3 apps. (Note that with KDE as much of FLOSS, many of the devs 
are unpaid volunteers, and volunteers can hardly be forced, but strong 
encouragement is certainly possible.)  As a result, bugs filed on kde3 
apps are increasingly being closed as unmaintained version, upgrade.

Of course, qt3 upon which kde3 depends is in similar or even worse shape 
(except that it was in arguably better shape when it went unsupported, as 
until then, people had been paid to keep it working, even if they'd have 
otherwise preferred to be working on the newer versions), apparently not 
supported any longer by its own (commercial FLOSS) upstream.

Unfortunately, all this is complicated by the state of kde4, in many ways 
a mirror image of kde3 -- specifically like a mirror image in that it's 
similar, but nicely reversed.  kde4 is getting all sorts of developer 
attention, but again despite what upstream says, it's anything /but/ as 
stable and smoothly functional and polished as kde3 is.  I'm normally an 
early adopter, running ~arch and in fact often unmasking and even 
reaching into overlays for fresh versions, often beta or rc, sometimes 
even live-vcs versions direct from the upstream repositories.

Despite all that and despite the fact that upstream kde recommended 4.2 
for most users and calls 4.3 fully stable, 4.2.4 was /barely/ getting 
functional enough to be able to work in it well enough for me to start 
transferring settings and otherwise getting serious about switching to 
kde4.  Despite the recommendation, in practice, as a user that regularly 
runs development versions, betas and rcs, 4.2.4 was therefore /barely/ 
what I'd call early beta.  4.3 (as every kde4 version so far) is markedly 
better than the previous version, but there's still a LOT of broken 
functionality, features still rapidly evolving, etc.  

kde4.3 therefore at what I'd normally consider the late-beta stage.  
User's who actually used and depended on the previous version for 
anything beyond basic functionality shouldn't be upgrading yet unless 
they're prepared to spend HOURS, in this case, DAYS, even WEEKS, 
upgrading, finding fixes and workarounds for bugs, even switching to 
alternative software solutions at times when the functionality simply 
isn't there. I estimate I've spent about 80 hours on the upgrade and 
reconfiguring, all told.  Now, a major version switch is a major version 
switch, and users WILL need to spend SOME time reconfiguring and 
adapting, but perhaps 20-40 hours is reasonable, NOT 80!  80 hours, two 
weeks of full-time 40-hour-week equivalent work, simply indicates how 
immature and broken some aspects of the project still are, thus 
necessitating workarounds and the like.  (If anybody wants hard examples, 
I can list the issues I had and have here, but this post is long enough 
without it.  Ask, or check kde's general and kde-linux lists archives for 
the last couple months.)

Or, put another way, there are solid reasons no kde4 is unmasked to 
gentoo stable yet.

As I said, every new kde4 version is solidly improved from the previous 
one, but by kde3.5, it was very very polished, very very functional, very 
very fully featured, and very very depended on, at least here.  kde4 
/was/ basically a ground-up rewrite, and given how mature, functional and 
well polished kde3 was, they had a *LOT* of ground to cover.  So while 
kde4 *IS* is progressing well and rapidly, it's /just/ /not/ /there/
/yet/.  Rome wasn't built in a day, neither has it ever been /re/built in 
a day.

I estimate that given current progress, kde4.5 will finally compare well 
against 3.5.  The further 4.3.x releases should be much like -rc versions 
normally are, and 4.4, scheduled for early next year, should be much like 
the infamous x.0 releases that early adopters that didn't hit the betas 
use, but that many users forego, in favor of x.1, which should be 4.5 
(scheduled for 3Q2010, minors are semi-annual and 4.3 was early this 
month, so 4.5 should be ~1 year from now).  Thus, 4.3 is sort of usable 
for beta tester types -- requiring a lot of user workaround and 
adjustment, 4.4 should hopefully be reasonably usable by ordinary people 
(what kde folks claimed 4.2 was, I /do/ expect 4.4 to hit this as they /
are/ finally hitting the fit and finish bugs that make a release fit for 
ordinary users), and 4.5 should finally be a mature product, nearly bug 
free and usable by nearly everyone.

But kde4 is a mirror in another regard as well, as unlike most upgrades, 
it seems the more advanced a user you are, the more trouble the upgrade 
tends to be.  This seems to be at least partially because the basic/core 
functionality plus some nice eye candy was implemented first, and it was 
then released, with the more advanced functionality that kde3 advanced 
users depended on still broken.  Thus, users who seldom change the 
defaults and are easily impressed when eye candy is made the default,
/did/ in many cases find 4.2, or even earlier, usable.  It's the folks 
that depended on 3.5's advanced functionality that are having the worst 
upgrade problems, because much of that functionality is still only 
partially working.

Regardless, the fact remains that kde4.3 is not yet in a really usable 
state for many, at least not without DAYS or even WEEKS worth of 
workarounds, fixes, and tweaks.  Of course, that makes the situation with 
kde3 even more dire, as it now looks likely that Gentoo KDE users, as KDE 
users on various other distributions before, will likely be rather 
strongly pushed toward the immature and not yet ready new version, as the 
older well functioning version goes unsupported before the smooth upgrade 
path has been established.  For Gentoo/KDE, that could well mean users 
will find 3.x masked before any 4.x at all is keyword-unmasked to stable.

The above is further complicated by a couple Gentoo-specific factors.  Of 
course, being a source-based distribution, the quality of the kde3/qt3 
sources affects Gentoo users (and therefore devs) more than the typical 
binary distribution user.  Sources that don't build without workarounds 
can often be handled by the skilled binary distribution devs doing the 
building for them, yet be entirely unsatisfactory for general Gentoo use 
because here, every user, including those who don't know much about 
upstream at all and who lack the skills necessary to do those 
workarounds, has to build from source.  Thus, as the upstream kde3/qt3 
sources go stale and fail to build without intervention against newer 
system libraries and with newer gccs, it's putting ever more strain on 
the Gentoo/KDE devs and project testers to support them.

Second, it seems that no Gentoo/KDE project members are actually still 
running kde3 as their normal desktop -- they've all migrated to kde4.  
Thus the urgent request for skilled kde3 users, with or without an 
interest in becoming a Gentoo dev, to volunteer to help out.  (Still, 
it's worth mentioning that apparently unlike kde upstream, there's 
effective pressure, and caring devs/testers, enough to /try/ to keep it 
functioning, regardless of their personal interest in it, because they 
know users continue to depend on it.)  How successful they are at 
actually attracting such skilled kde3 users, and how long those skilled 
kde3 users remain using it and how much time they have available to 
invest in the project, thus /very/ much affects how long and under what 
conditions Gentoo can continue to provide a usable kde3 to /it's/ users.


So where does that actually leave us?

Well, to a large extent that depends on a number of factors that remain 
unknowns ATM.  The current Gentoo/KDE kde4 stabilization target is 4.3.1, 
which should be release in a few weeks.  As I said, upstream is finally 
fixing many of the remaining serious bugs, so this is reasonable, but not 
assured.  There's of course a couple other factors (python issues, etc) 
involved whether 4.3.1 will actually make stable or not, and even if it 
does, we're looking at six weeks or so, minimum (I'm not sure when 4.3.1 
is scheduled for upstream release, but Gentoo policy is 30 days without 
bugs, so it'd be a minimum 30 days after that).  That's early October at 
the earliest.  If there's complications and/or it has to wait until 
4.3.2, we're looking at, perhaps, stable kde4 as a Christmas present.

Gentoo's kde3 remaining time and status depends very much on the evolving 
security situation, as well as how successful they are at attracting 
someone, preferably someone who is or can become a Gentoo dev, to 
basically dedicate themselves to it.  

Apparently, upstream maintenance is in severe enough a state (again, 
despite asegio's very public claim that kde3 will continue to be 
supported as long as there are users, and despite the fact they get 
unhappy when people say it's unsupported) that there are very real 
questions about the ability to provide security updates, as the normal 
stream of browser vulnerability announcements, etc, continues.  Depending 
on how serious a vuln is and what components are affected, etc, there's 
some chance that various other distributions will continue to cooperate 
in coming up with patches, but the list of distributions continuing to 
ship a full kde3 is continuing to shrink.  Still, there's some government 
and other reasonably large long term kde3 consultancy and support 
contracts in Europe, so some patches will no doubt continue to flow for 
another, probably, two years anyway, regardless of mainline distribution 
and upstream support.

But anyway, they're now playing it by ear in terms of security 
vulnerabilities, and if a big one comes up (for all I know there may 
already be one that's not yet public), and there's no forthcoming 
patches, it'll mean rather short-notice kde3 masking, very possibly, 
according to the summary of the last Gentoo/KDE project meeting as posted 
in -desktop (the reason people concerned about kde should be following 
that list, that's where those summaries go, and thus the reason I have 
all this information and can post it), without a kde4 of any kind being 
stable yet.

It's based on THAT that I decided to post this.  People still using and 
depending on kde3 **NEED** to know what could well be happening to their 
desktop.

According to that summary, they do plan to keep kde3 in-tree for a few 
more months, probably until early next year some time, before booting it 
to the kde-sunset or whatever they decide to call it, overlay.  However, 
it's likely to be masked from late this year, as I said, possibly within 
weeks if the security situation warrants it.

That said, if possible, they do want a stable kde4 before kde3 gets 
masked -- but it's now no longer considered a given.

Meanwhile, again according to the summary, the goal before actual removal 
from tree, is EITHER one of: TWO kde4 "minor" versions stabilized, OR at 
least kde4.4 out, and at least ONE "minor" version stabilized.  "Minor" 
is in quotes, there, because it's not clear to me exactly what they mean 
in that regard.  "Minor" in normal usage would be 4.3, 4.4, etc, but if 
that's what's intended, and a 4.3 version does indeed make it to stable, 
then the two OR conditions look pretty close to identical, since 4.4 
would then be the second "minor" version stabilized.  Thus, I'm wondering 
if they actually meant "micro" aka "patch" version, which would fulfill 
the two-stable-version requirement if 4.3.1 and 4.3.2 are stabilized, 
thus distinguishing it better from having a 4.4 version out and 
preferably stable.  Significantly, however, that's removal from the tree 
to the overlay.  I know I'm repeating myself but it's important to 
understand, kde3 could well be masked in September, if events warrant it, 
and if so, it'll almost certainly mean NO UNMASKED/STABLE KDE IN THE TREE 
AT ALL for some weeks, until some version of kde4 is deemed to have 
reached that level!

So as I said, currently, they plan to remove kde3 from the tree (where it 
will have probably completed the last few months in-tree masked), along 
with all packages depending on kde3, sometime 1H2010 (first half next 
year).  qt3 and all qt3 dependencies will follow shortly thereafter, so 
likely before this time next year.  Both will be headed to overlays, with 
the viability of the overlays, at least the kde-sunset overlay, almost 
certainly depending on skilled users, not kde devs.

All that can be summarized in one sentence:  If you are currently a kde3 
user and have NOT yet figured out where you're moving to from there, you 
**BETTER** get a move on!

FWIW, they *DO* plan to announce it on the Gentoo front-page, in the user 
forum, and via the gentoo tree package news mechanism, before the 
masking, and likely again before the final move out of tree to the 
overlay.  However, given the time it took /me/ to accomplish the upgrade 
and the serious trouble I had getting actually working kde4 or suitable 
non-kde replacements for all the functionality I depend on, AND the usual 
churn that accompanies a major desktop upgrade of that nature even if 
everything technically goes off without a hitch, I decided a bit of an 
additional heads-up warning would likely be appreciated by anyone still 
on kde3, particularly if they've not yet started preparing for the 
inevitable  and now rather shortly pending.

-- 
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

Re: [gentoo-amd64] Heads-up: KDEers: Particularly kde3-ers,

[Mark Knecht]

On Sun, Aug 23, 2009 at 7:16 AM, Duncan<1i5t5.duncan@cox.net> wrote:
> Those of you kde-ers, particularly kde3-ers (aka stable kde-ers),
> heads-up!
>
> If you aren't aware of the current gentoo kde (especially kde3)
> situation, you *NEED* to subscribe to the gentoo-desktop list (normally
> lower activity than here, so it shouldn't be a huge burden), AND check
> the archives for the last couple months.
>
> The short version:  kde3 is likely going to be masked, soon, apparently
> very possibly before any kde4 is ever marked stable.  The current plan is
> to leave kde3 in-tree but masked, probably until early next year, at
> which point it'll move to an overlay, kde-sunset or similarly named,
> where it'll be maintained primarily by interested users.
>
<SNIP>

Duncan,
   I am not a KDE user as I've always felt it's too large to build and
maintain on Gentoo, at least on my machines. That said it seems to me
that maybe you should consider cross-posting this to Gentoo-users as I
expect there are a lot of KDE-3 users there that aren't reading this
list.

   You might consider a more concise version of this if you do. you
have a lot to say on a subject that is clearly important to you.
However many folks might not be willing to dig in as deeply on first
reading as your first message here requires.

Cheers,
Mark

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

Mark Knecht posted on Sun, 23 Aug 2009 08:49:47 -0700 as excerpted:

> Duncan,
>    I am not a KDE user as I've always felt it's too large to build and
> maintain on Gentoo, at least on my machines. That said it seems to me
> that maybe you should consider cross-posting this to Gentoo-users as I
> expect there are a lot of KDE-3 users there that aren't reading this
> list.
> 
>    You might consider a more concise version of this if you do. you
> have a lot to say on a subject that is clearly important to you. However
> many folks might not be willing to dig in as deeply on first reading as
> your first message here requires.

Thanks for the encouraging words.  It's appreciated, honestly.  However, 
I'm not the one to post it to -user, which I don't follow.  Others may 
wish to do so, either in their own (likely shorter) words, or referencing 
my post and/or the ones in -desktop.

FWIW, my post, as seen on gmane:
http://permalink.gmane.org/gmane.linux.gentoo.amd64/15046

And I'd have linked the -desktop posts in my initial post,
had I thought of it before.  Here's their links:

KDE 3 Future/Status (Aug 10 posting):
http://permalink.gmane.org/gmane.linux.gentoo.desktop/3426

KDE project 20090618 meeting summary (posted late, Aug 23)
http://permalink.gmane.org/gmane.linux.gentoo.desktop/3438

KDE project 20090820 meeting summary (also posted Aug 23)
http://permalink.gmane.org/gmane.linux.gentoo.desktop/3439

-- 
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

Re: [gentoo-amd64] Heads-up: KDEers: Particularly kde3-ers,

[Volker Armin Hemmann]

On Sonntag 23 August 2009, Duncan wrote:
> Those of you kde-ers, particularly kde3-ers (aka stable kde-ers),
> heads-up!
>
> If you aren't aware of the current gentoo kde (especially kde3)
> situation, you *NEED* to subscribe to the gentoo-desktop list (normally
> lower activity than here, so it shouldn't be a huge burden), AND check
> the archives for the last couple months.

bullshit

>
> The short version:  kde3 is likely going to be masked, soon, apparently
> very possibly before any kde4 is ever marked stable.  The current plan is
> to leave kde3 in-tree but masked, probably until early next year, at
> which point it'll move to an overlay, kde-sunset or similarly named,
> where it'll be maintained primarily by interested users.

maybe, you you don't have to be subscribed to -desktop to find that. Anyway, 
without an official announcement it is just a plan.

<cut unimportant crap >

>
> Of course, qt3 upon which kde3 depends is in similar or even worse shape
> (except that it was in arguably better shape when it went unsupported, as
> until then, people had been paid to keep it working, even if they'd have
> otherwise preferred to be working on the newer versions), apparently not
> supported any longer by its own (commercial FLOSS) upstream.

and here we come to the real stuff. qt3 is planned to be removed from the tree. 
Nothing else.

>
> Unfortunately, all this is complicated by the state of kde4, in many ways
> a mirror image of kde3 -- specifically like a mirror image in that it's
> similar, but nicely reversed.  kde4 is getting all sorts of developer
> attention, but again despite what upstream says, it's anything /but/ as
> stable and smoothly functional and polished as kde3 is.  

bullshit


> I'm normally an
> early adopter, running ~arch and in fact often unmasking and even
> reaching into overlays for fresh versions, often beta or rc, sometimes
> even live-vcs versions direct from the upstream repositories.

you are also writing way too much.


>4.3 (as every kde4 version so far) is markedly
> better than the previous version, but there's still a LOT of broken
> functionality, features still rapidly evolving, etc.

extreme bullshit

>
> kde4.3 therefore at what I'd normally consider the late-beta stage.
> User's who actually used and depended on the previous version for
> anything beyond basic functionality shouldn't be upgrading yet unless
> they're prepared to spend HOURS, in this case, DAYS, even WEEKS,

even more bullshit.

emerge @kde4.3

some hours later: perfectly  fine working kde 4.3. No bugs, stable, all 
funtionality needed there.

So instead of talking you typical annoying much worded crap, could you please 
point out the problems with 4.3? Examples?
 
> upgrading, finding fixes and workarounds for bugs, even switching to
> alternative software solutions at times when the functionality simply
> isn't there. I estimate I've spent about 80 hours on the upgrade and
> reconfiguring, all told. 

nice. I spent maybe 3h. All told.

> switch, and users WILL need to spend SOME time reconfiguring and
> adapting, but perhaps 20-40 hours is reasonable, NOT 80!  80 hours, two
> weeks of full-time 40-hour-week equivalent work, simply indicates how
> immature and broken some aspects of the project still are,

and more bullshit.

So, name your examples.

And I didn't even bother to read the rest.

duncan, if I want to read a book, I buy a book, This is an INTERNATIONAL list. 
We are not living in nightmare land where everybody's first language is 
english.
Reading your emails takes more time than installing kde.

All you had said to this point could have been said in two simple sentences 
too:

kde 3.5 is planned to go away into an overlay because qt3 is not supported 
anymore
kde 4.X has still some problems.

See? See the difference to you writings? Short, compact, same message. Oh, and 
of course I left out the bullshit.

But no, you do have to write a freaking essay.

In the future: keep it short.

Re: [gentoo-amd64] Heads-up: KDEers: Particularly kde3-ers,

[Mark Knecht]

On Sun, Aug 23, 2009 at 10:04 AM, Volker Armin
Hemmann<volkerarmin@googlemail.com> wrote:
<SNIP>
> Reading your emails takes more time than installing kde.
<SNIP>
bullshit.

(I hate using profanity on a list like this but it seems to be the way
Volker thinks so be it.)

- Mark

Re: [gentoo-amd64] Heads-up: KDEers: Particularly kde3-ers,

[Volker Armin Hemmann]

On Sonntag 23 August 2009, Mark Knecht wrote:
> On Sun, Aug 23, 2009 at 10:04 AM, Volker Armin
> Hemmann<volkerarmin@googlemail.com> wrote:
> <SNIP>
>
> > Reading your emails takes more time than installing kde.
>
> <SNIP>
> bullshit.
>
> (I hate using profanity on a list like this but it seems to be the way
> Volker thinks so be it.)
>
> - Mark

you are free to disagree.

Re: [gentoo-amd64] Heads-up: KDEers: Particularly kde3-ers,

[Mark Knecht]

On Sun, Aug 23, 2009 at 11:42 AM, Volker Armin
Hemmann<volkerarmin@googlemail.com> wrote:
> On Sonntag 23 August 2009, Mark Knecht wrote:
>> On Sun, Aug 23, 2009 at 10:04 AM, Volker Armin
>> Hemmann<volkerarmin@googlemail.com> wrote:
>> <SNIP>
>>
>> > Reading your emails takes more time than installing kde.
>>
>> <SNIP>
>> bullshit.
>>
>> (I hate using profanity on a list like this but it seems to be the way
>> Volker thinks so be it.)
>>
>> - Mark
>
> you are free to disagree.
>
>
I had to. I read his post in about 10 minutes. I don't know of anyone
installing kde in that amount of time.

But what I most disagree with is both your vile use of language as
well as the tone you *consistently* use here in this public forum. It
seems you cannot resist the opportunity to pound your views into
others and apparently can only do it with a large hammer as opposed
simply bringing people around to your views based on the strength of
your arguments.

Personally I think you don't add value here - I am sure no one does
responding the way you did to Duncan. My view is you own Duncan and
the list in general an apology. You are of course free to disagree. It
seems to be your nature - disagreeable.

Cheers,
Mark

Re: [gentoo-amd64] Heads-up: KDEers: Particularly kde3-ers,

[Volker Armin Hemmann]

On Sonntag 23 August 2009, Mark Knecht wrote:
> On Sun, Aug 23, 2009 at 11:42 AM, Volker Armin
>
> Hemmann<volkerarmin@googlemail.com> wrote:
> > On Sonntag 23 August 2009, Mark Knecht wrote:
> >> On Sun, Aug 23, 2009 at 10:04 AM, Volker Armin
> >> Hemmann<volkerarmin@googlemail.com> wrote:
> >> <SNIP>
> >>
> >> > Reading your emails takes more time than installing kde.
> >>
> >> <SNIP>
> >> bullshit.
> >>
> >> (I hate using profanity on a list like this but it seems to be the way
> >> Volker thinks so be it.)
> >>
> >> - Mark
> >
> > you are free to disagree.
>
> I had to. I read his post in about 10 minutes. I don't know of anyone
> installing kde in that amount of time.
>
> But what I most disagree with is both your vile use of language as
> well as the tone you *consistently* use here in this public forum. It
> seems you cannot resist the opportunity to pound your views into
> others and apparently can only do it with a large hammer as opposed
> simply bringing people around to your views based on the strength of
> your arguments.
>
> Personally I think you don't add value here - I am sure no one does
> responding the way you did to Duncan. My view is you own Duncan and
> the list in general an apology. You are of course free to disagree. It
> seems to be your nature - disagreeable.
>
> Cheers,
> Mark

and I disagree again.

What was wrong with this mail?
http://marc.info/?l=gentoo-amd64&m=124898073532184&w=2

please also read the rest of the thread. Who wrote how much and who stayed on 
topic.

before that I find three other threads where I at least tried to help. And I 
was neither harsh nor did I use profanity. Instead I tried to keep it short 
and on topic. 

I also have to add that I can't remember you ever posting something else than 
cries for help. 

Re: [gentoo-amd64] Heads-up: KDEers: Particularly kde3-ers,

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

Volker Armin Hemmann schrieb:
> On Sonntag 23 August 2009, Mark Knecht wrote:
>> On Sun, Aug 23, 2009 at 11:42 AM, Volker Armin
>>
>> Hemmann<volkerarmin@googlemail.com> wrote:
>>> On Sonntag 23 August 2009, Mark Knecht wrote:
>>>> On Sun, Aug 23, 2009 at 10:04 AM, Volker Armin
>>>> Hemmann<volkerarmin@googlemail.com> wrote:
>>>> <SNIP>
>>>>
>>>>> Reading your emails takes more time than installing kde.
>>>> <SNIP>
>>>> bullshit.
>>>>
>>>> (I hate using profanity on a list like this but it seems to be the way
>>>> Volker thinks so be it.)
>>>>
>>>> - Mark
>>> you are free to disagree.
>> I had to. I read his post in about 10 minutes. I don't know of anyone
>> installing kde in that amount of time.
>>
>> But what I most disagree with is both your vile use of language as
>> well as the tone you *consistently* use here in this public forum. It
>> seems you cannot resist the opportunity to pound your views into
>> others and apparently can only do it with a large hammer as opposed
>> simply bringing people around to your views based on the strength of
>> your arguments.
>>
>> Personally I think you don't add value here - I am sure no one does
>> responding the way you did to Duncan. My view is you own Duncan and
>> the list in general an apology. You are of course free to disagree. It
>> seems to be your nature - disagreeable.
>>
>> Cheers,
>> Mark
> 
> and I disagree again.
> 
> What was wrong with this mail?
> http://marc.info/?l=gentoo-amd64&m=124898073532184&w=2
> 
> please also read the rest of the thread. Who wrote how much and who stayed on 
> topic.
> 
> before that I find three other threads where I at least tried to help. And I 
> was neither harsh nor did I use profanity. Instead I tried to keep it short 
> and on topic. 
> 
> I also have to add that I can't remember you ever posting something else than 
> cries for help. 
> 

Err ... guys, stop it! This isn't your occasional flamewar. If you
didn't notice it, your posts have been personally insulting (or very
close to) from the very beginning of this thread.

I don't like to act like your local police man but I'd really recommend
you to read the Gentoo Code of Conduct:
http://www.gentoo.org/proj/en/council/coc.xml

Participating in this community is a privilege, not a right. So please,
shut up and do something productive, like stealing candy from a baby or
something ...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-amd64] Heads-up: KDEers: Particularly kde3-ers,

[Mark Knecht]

On Sun, Aug 23, 2009 at 1:35 PM, Florian
Philipp<lists@f_philipp.fastmail.net> wrote:
<SNIP>
> Err ... guys, stop it! This isn't your occasional flamewar. If you
> didn't notice it, your posts have been personally insulting (or very
> close to) from the very beginning of this thread.
>
> I don't like to act like your local police man but I'd really recommend
> you to read the Gentoo Code of Conduct:
> http://www.gentoo.org/proj/en/council/coc.xml
>
> Participating in this community is a privilege, not a right. So please,
> shut up and do something productive, like stealing candy from a baby or
> something ...
>
>

I agree. It's out of line and I apologize to the list for allowing my
feeling about this individual and my view of his long standing conduct
on this list to be displayed in that manner. I should have kept them
private as I usually do.

With best regards,
Mark

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

Volker Armin Hemmann posted on Sun, 23 Aug 2009 19:04:45 +0200 as
excerpted:

> duncan, if I want to read a book, I buy a book, This is an INTERNATIONAL
> list. We are not living in nightmare land where everybody's first
> language is english.
> Reading your emails takes more time than installing kde.

OK, so it's obvious you don't like my emails.  Why don't you killfile me 
then, and not have to bother?

Meanwhile, some find them useful.  I'm writing for them, obviously not 
for people who call them "bullshit".  Naturally, YMMV, but I fail to 
understand why someone who has such obvious antipathy to what I say and 
how I say it, can't find the killfile functionality in his client, to 
make it simply go away, never to be bothered with again.

-- 
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

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[szalkai]

Now that this exciting little flamewar has finished, and everybody is friends again :), could you Duncan please give some examples of major
breakage in KDE4?  I have been using it since 4.1.something and it is getting better and better.  Also, it took me nowhere near 80 hours to
switch from 3.5.10 to 4.

I admit that I have a konsole with seven tabs open all the time, and do most of my work from there (and use firefox for browsing and
thunderbird for emails), so I am not a KDE poweruser by far (while definitely a linux poweruser at least), but even 4.2 already seemed
stable enough for me.  Actually, the thing that made me switch in excitement was the promise of the semantic desktop stuff, not the
eyecandy, but it has disappointed me so far.

BTW Duncan, I do enjoy and appreciate your posts here.

Akos

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Sebastian Beßler]

szalkai@szalkai.net schrieb:
> Now that this exciting little flamewar has finished, and everybody is
> friends again :), could you Duncan please give some examples of major
>  breakage in KDE4? 

I'm not Duncan but I have 5 reasons not to switch to kde4 atm.

1) Speed: I have a AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ with
8GB of ram and a Radeon HD 3600 card but still kde 4.3 most of the time
feels like walking through mud.

2) Crashes: kde 4.3 crashes way to often, sometimes it even brings X to
its knees. Kde 3.5.10 is solid as a rock.

3) Screen-setup: I have to monitores connected to my pc static in xorg
as two seperated displays :0.0 and :0.1. If I start kde <4.4-svn I have
both screens on my main monitor and the second is just as good as dead.
There is a patch for this in svn (or is it git now?) and as much as I
can say by testing a few live-builds this point will be gone by next
release.

4) Design: I have a very small design with two small bars at the bottom
and on the right side. I can't create a design in kde4.x so far that
consumes as few space on my monitor as i have it in kde 3.

The fifth point on my list is that many of the functions and (3rd party)
kde programms I use day by day aren't there yet at all or only with lack
of functions and mostly in late alpha-state: k3b, amarok, kdevelop,
kvirc to just name a few.

The last reason I stick with kde 3.5.10 for a while is that working with
kde 4.x just doesn't feel right. Switching to kde4 is like switching to
a completly different DE. KDE 4 isn't kde anymore, it is something
absolutly different that calls itself kde.

Greetings

Sebastian Beßler

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Barry Schwartz]

Sebastian Beßler <sebastian@darkmetatron.de> skribis:
> The last reason I stick with kde 3.5.10 for a while is that working with
> kde 4.x just doesn't feel right. Switching to kde4 is like switching to
> a completly different DE. KDE 4 isn't kde anymore, it is something
> absolutly different that calls itself kde.

A few months ago, having used KDE4 for a bit and sensing what was
ahead, I pre-emptively dumped KDE and now run just fluxbox and rox
pinboard (which I was running in place of the KDE3 wm and desktop,
anyway).

I don't know why I should adapt to the software, rather than the other
way around. It's not really a Gentoo problem that other projects won't
settle on a basic plan and stick with it, and I'm glad Gentoo hasn't
been like that.

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

Barry Schwartz posted on Mon, 24 Aug 2009 17:20:50 -0500 as excerpted:

> Sebastian Beßler <sebastian@darkmetatron.de> skribis:
>> The last reason I stick with kde 3.5.10 for a while is that working
>> with kde 4.x just doesn't feel right. Switching to kde4 is like
>> switching to a completly different DE. KDE 4 isn't kde anymore, it is
>> something absolutly different that calls itself kde.
> 
> A few months ago, having used KDE4 for a bit and sensing what was ahead,
> I pre-emptively dumped KDE and now run just fluxbox and rox pinboard
> (which I was running in place of the KDE3 wm and desktop, anyway).
> 
> I don't know why I should adapt to the software, rather than the other
> way around. It's not really a Gentoo problem that other projects won't
> settle on a basic plan and stick with it, and I'm glad Gentoo hasn't
> been like that.
>

KDE has lost a lot of users with the way they've handled kde4, no doubt 
about it.  Many will likely eventually come back, especially since it 
looks as if gnome is about to have some major changes of its own with the 
planned jump to 3.x, tho I do hope they learned from kde and manage it 
MUCH better, but some won't, and even for those that do, the level of 
trust and loyalty KDE had gained is now entirely gone, and will take 
/years/ to rebuild.

Change is always difficult, but it wasn't the change so much here, as the 
way it was, and still is to some degree, being handled.

But regardless, it's not like there's any better options for me, a 
confirmed power-user that LIKES and USES many of those configuration 
levers KDE exposes that GNOME etc likes to hide, and other desktops 
simply don't provide the utility.  Plus, the technology is sound, and 
despite the terrible management of the transition, KDE now has a very 
solid and powerful platform, that once the bugs are worked out, has the 
potential to be every bit as smoothly polished as 3.5.10, without all the 
cruft and kinks, as they're dealing with a far cleaner and more modern 
and modular code base now.

So really, even after all this, I'm still a believer, even if I /don't/ 
trust the PR-speak any more and have had to put to use that thick hide 
that years surviving the infamous gentoo-dev list flame wars has given 
me.  (FWIW, nothing either previous in this thread or on the kde lists 
came even /close/ to the humiliation I've seen certain former devs 
inflict on other supposedly same-team devs on the gentoo-dev list, simply 
because it was allowed, for no more than entertainment.  I'm glad /that/ 
dark period seems to be over!  Call it the verbal parallel to Abu-ghraib, 
which I'm also glad is over.)

Anyway, that's why I'm still on KDE, and with 4.3, it /is/ beginning to 
get there, finally.  But the trust isn't there any more, and won't be for 
awhile, and I don't blame folks for deserting them.  In fact, after what 
I went thru on the kde lists, I'm surprised they continue to have the 
followers they do.  Oh, well...

-- 
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

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Volker Armin Hemmann]

On Montag 24 August 2009, Sebastian Beßler wrote:
> szalkai@szalkai.net schrieb:
> > Now that this exciting little flamewar has finished, and everybody is
> > friends again :), could you Duncan please give some examples of major
> >  breakage in KDE4?
>
> I'm not Duncan but I have 5 reasons not to switch to kde4 atm.
>
> 1) Speed: I have a AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ with
> 8GB of ram and a Radeon HD 3600 card but still kde 4.3 most of the time
> feels like walking through mud.

turn of composite or install a xorg-server with the 
fedora_dont_backfill_bg_none.patch and see kde fly.

>
> 2) Crashes: kde 4.3 crashes way to often, sometimes it even brings X to
> its knees. Kde 3.5.10 is solid as a rock.

I had never seen a 'bring down X' crash. There have been some konqueror 
crashes in the past - but the same is true for 3.5. Compared with 3.2 or 3.4 
4.3 is a lot more stable (for me).

>
> 3) Screen-setup: I have to monitores connected to my pc static in xorg
> as two seperated displays :0.0 and :0.1. If I start kde <4.4-svn I have
> both screens on my main monitor and the second is just as good as dead.
> There is a patch for this in svn (or is it git now?) and as much as I
> can say by testing a few live-builds this point will be gone by next
> release.

ok, sounds like a genuine stupid bug. Can't even fixed with krandrtray?

>
> 4) Design: I have a very small design with two small bars at the bottom
> and on the right side. I can't create a design in kde4.x so far that
> consumes as few space on my monitor as i have it in kde 3.

but you know that you can make the plasma bar very small - and add a couple of 
them to the desktop?

>
> The fifth point on my list is that many of the functions and (3rd party)
> kde programms I use day by day aren't there yet at all or only with lack
> of functions and mostly in late alpha-state: k3b, amarok, kdevelop,
> kvirc to just name a few.

I haven't found anything missing in k3b or amarok - and I don't use kdevelop 
or kvirc. What are you missing from k3b?


> The last reason I stick with kde 3.5.10 for a while is that working with
> kde 4.x just doesn't feel right. Switching to kde4 is like switching to
> a completly different DE. KDE 4 isn't kde anymore, it is something
> absolutly different that calls itself kde.

people said the same when going from 1.1 to 2.0 and 2.2 to 3.0....

The only two things that I really disliked about kde 4.X is the new 
'systemsettings' - I liked kcontrol. Very much. And akonadi creeping into 
everything.

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Nikos Chantziaras]

On 08/25/2009 02:33 AM, Volker Armin Hemmann wrote:
> On Montag 24 August 2009, Sebastian Beßler wrote:
>> szalkai@szalkai.net schrieb:
>>> Now that this exciting little flamewar has finished, and everybody is
>>> friends again :), could you Duncan please give some examples of major
>>>   breakage in KDE4?
>>
>> I'm not Duncan but I have 5 reasons not to switch to kde4 atm.
>>
>> 1) Speed: I have a AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ with
>> 8GB of ram and a Radeon HD 3600 card but still kde 4.3 most of the time
>> feels like walking through mud.
>
> turn of composite or install a xorg-server with the
> fedora_dont_backfill_bg_none.patch and see kde fly.

...and see it produce a crapload of artifacts during window and menu 
opening.  Still better than a slow as molasses GUI though.

In any event though, that's hardly KDE's fault anyway.  It's the crappy 
Catalyst drivers from AMD (I suffer the same issues).

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Volker Armin Hemmann]

On Dienstag 25 August 2009, Nikos Chantziaras wrote:
> On 08/25/2009 02:33 AM, Volker Armin Hemmann wrote:
> > On Montag 24 August 2009, Sebastian Beßler wrote:
> >> szalkai@szalkai.net schrieb:
> >>> Now that this exciting little flamewar has finished, and everybody is
> >>> friends again :), could you Duncan please give some examples of major
> >>>   breakage in KDE4?
> >>
> >> I'm not Duncan but I have 5 reasons not to switch to kde4 atm.
> >>
> >> 1) Speed: I have a AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ with
> >> 8GB of ram and a Radeon HD 3600 card but still kde 4.3 most of the time
> >> feels like walking through mud.
> >
> > turn of composite or install a xorg-server with the
> > fedora_dont_backfill_bg_none.patch and see kde fly.
>
> ...and see it produce a crapload of artifacts during window and menu
> opening.  Still better than a slow as molasses GUI though.
>
> In any event though, that's hardly KDE's fault anyway.  It's the crappy
> Catalyst drivers from AMD (I suffer the same issues).

or from a bad decision by the xorg devs to punish everybody for crappy intel 
hardware. Also the artifacts don't happen everytime. In fact, I only see them 
occasionally.

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Nikos Chantziaras]

On 08/25/2009 02:55 AM, Volker Armin Hemmann wrote:
> On Dienstag 25 August 2009, Nikos Chantziaras wrote:
>> On 08/25/2009 02:33 AM, Volker Armin Hemmann wrote:
>>> On Montag 24 August 2009, Sebastian Beßler wrote:
>>>> szalkai@szalkai.net schrieb:
>>>>> Now that this exciting little flamewar has finished, and everybody is
>>>>> friends again :), could you Duncan please give some examples of major
>>>>>    breakage in KDE4?
>>>>
>>>> I'm not Duncan but I have 5 reasons not to switch to kde4 atm.
>>>>
>>>> 1) Speed: I have a AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ with
>>>> 8GB of ram and a Radeon HD 3600 card but still kde 4.3 most of the time
>>>> feels like walking through mud.
>>>
>>> turn of composite or install a xorg-server with the
>>> fedora_dont_backfill_bg_none.patch and see kde fly.
>>
>> ...and see it produce a crapload of artifacts during window and menu
>> opening.  Still better than a slow as molasses GUI though.
>>
>> In any event though, that's hardly KDE's fault anyway.  It's the crappy
>> Catalyst drivers from AMD (I suffer the same issues).
>
> or from a bad decision by the xorg devs to punish everybody for crappy intel
> hardware.

Only Catalyst has this problem.  The open source Radeon drivers are fine 
(and of course NVidia's closed drivers and everything Intel is fine 
too).  It's one of those Catalyst bugs that are there for several years 
but one bothers fixing.

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Volker Armin Hemmann]

On Dienstag 25 August 2009, Nikos Chantziaras wrote:
> On 08/25/2009 02:55 AM, Volker Armin Hemmann wrote:
> > On Dienstag 25 August 2009, Nikos Chantziaras wrote:
> >> On 08/25/2009 02:33 AM, Volker Armin Hemmann wrote:
> >>> On Montag 24 August 2009, Sebastian Beßler wrote:
> >>>> szalkai@szalkai.net schrieb:
> >>>>> Now that this exciting little flamewar has finished, and everybody is
> >>>>> friends again :), could you Duncan please give some examples of major
> >>>>>    breakage in KDE4?
> >>>>
> >>>> I'm not Duncan but I have 5 reasons not to switch to kde4 atm.
> >>>>
> >>>> 1) Speed: I have a AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ with
> >>>> 8GB of ram and a Radeon HD 3600 card but still kde 4.3 most of the
> >>>> time feels like walking through mud.
> >>>
> >>> turn of composite or install a xorg-server with the
> >>> fedora_dont_backfill_bg_none.patch and see kde fly.
> >>
> >> ...and see it produce a crapload of artifacts during window and menu
> >> opening.  Still better than a slow as molasses GUI though.
> >>
> >> In any event though, that's hardly KDE's fault anyway.  It's the crappy
> >> Catalyst drivers from AMD (I suffer the same issues).
> >
> > or from a bad decision by the xorg devs to punish everybody for crappy
> > intel hardware.
>
> Only Catalyst has this problem.  The open source Radeon drivers are fine
> (and of course NVidia's closed drivers and everything Intel is fine
> too).  It's one of those Catalyst bugs that are there for several years
> but one bothers fixing.

nvidia was not fine for a long time - and since nvidia replaces a lot of x and 
kernel funtionailty within their driver I would not be surprised if they 
replaced the offending parts too. Intel is not hit, because it is their patch 
that made their life splendid and everybody else bad.

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Nikos Chantziaras]

On 08/25/2009 03:54 AM, Volker Armin Hemmann wrote:
> On Dienstag 25 August 2009, Nikos Chantziaras wrote:
>> Only Catalyst has this problem.  The open source Radeon drivers are fine
>> (and of course NVidia's closed drivers and everything Intel is fine
>> too).  It's one of those Catalyst bugs that are there for several years
>> but one bothers fixing.
>
> nvidia was not fine for a long time - and since nvidia replaces a lot of x and
> kernel funtionailty within their driver I would not be surprised if they
> replaced the offending parts too. Intel is not hit, because it is their patch
> that made their life splendid and everybody else bad.

And what about the two open source drivers?  (radeon and radeonhd.) 
They don't suffer either, and they're not Intel.

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Volker Armin Hemmann]

On Dienstag 25 August 2009, Nikos Chantziaras wrote:
> On 08/25/2009 03:54 AM, Volker Armin Hemmann wrote:
> > On Dienstag 25 August 2009, Nikos Chantziaras wrote:
> >> Only Catalyst has this problem.  The open source Radeon drivers are fine
> >> (and of course NVidia's closed drivers and everything Intel is fine
> >> too).  It's one of those Catalyst bugs that are there for several years
> >> but one bothers fixing.
> >
> > nvidia was not fine for a long time - and since nvidia replaces a lot of
> > x and kernel funtionailty within their driver I would not be surprised if
> > they replaced the offending parts too. Intel is not hit, because it is
> > their patch that made their life splendid and everybody else bad.
>
> And what about the two open source drivers?  (radeon and radeonhd.)
> They don't suffer either, and they're not Intel.

they start/started to suffer as soon as they use(d) acceleration. As long as 
everything is done by the cpu in system memory and just the results copied 
into the framebuffer everything seems to be fine and dandy .

bridgeman and others explained it in several threads on the phoronix forum. 
Start with the ask ati devs thread and then look at the other threads 
featuring bridgeman.

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Sebastian Beßler]

Volker Armin Hemmann schrieb:


>> 2) Crashes: kde 4.3 crashes way to often, sometimes it even brings X to
>> its knees. Kde 3.5.10 is solid as a rock.
> 
> I had never seen a 'bring down X' crash. There have been some konqueror 
> crashes in the past - but the same is true for 3.5. Compared with 3.2 or 3.4 
> 4.3 is a lot more stable (for me).

Ok, maybe its because I started with kde 3.5 a few years ago but kde was
never so unstable as with

>> 3) Screen-setup: I have to monitores connected to my pc static in xorg
>> as two seperated displays :0.0 and :0.1. If I start kde <4.4-svn I have
>> both screens on my main monitor and the second is just as good as dead.

> ok, sounds like a genuine stupid bug. Can't even fixed with krandrtray?

No, because I can't use randr as randr doesn't supports my setup at all.
I had to deactivate randr-support in catalyst-drivers to get it working.
With randr only stupid bigscreen is possible. This is the reason why I
still stick with the closed driver, the open ones only support xrandr.

> but you know that you can make the plasma bar very small - and add a couple of 
> them to the desktop?

Yes I know. But then many things aren't useable anymore because scaling
of the icons freaks out here if it gets to small.

> I haven't found anything missing in k3b or amarok - and I don't use kdevelop 
> or kvirc. What are you missing from k3b?

k3b is one of the programms that is rather complete but still in late
alpha state. Even the ebuild has alpha in its name. And amarok is
missing so much.

1) the collection-scanner is broken. Only approx. 400 songs are added to
the collection. I have over 10000 songs on my pc.

2) Support for generic mp3-players doesn't exist or needs workarounds
(in live-builds atm)

3) Not really a mising feature but amarok 2 looks like crap. I like the
way 1.4 looks and hate that amarok 2 forces me to learn everything new.
But forcing users to learn new ways to do old things its all that is
kde4. I hate it if i get forced to do something.

>> The last reason I stick with kde 3.5.10 for a while is that working with
>> kde 4.x just doesn't feel right. Switching to kde4 is like switching to
>> a completly different DE. KDE 4 isn't kde anymore, it is something
>> absolutly different that calls itself kde.
> 
> people said the same when going from 1.1 to 2.0 and 2.2 to 3.0....

Maybe because people like it the way it is. I switched to linux because
I really like the freedom to choose what I want to do with my computer.
But more and more linux becomes like windows in the way that it forces
the user to adapt to the system. Yes I can switch the DE if i dislike
kde4 but in a few month or maybe a year there is no way around randr and
then I have to stick with old kernel, old driver and old X or be forced
to adapt to the way some people think whats best for all of us.

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Volker Armin Hemmann]

On Dienstag 25 August 2009, Sebastian Beßler wrote:
> Volker Armin Hemmann schrieb:
> >> 2) Crashes: kde 4.3 crashes way to often, sometimes it even brings X to
> >> its knees. Kde 3.5.10 is solid as a rock.
> >
> > I had never seen a 'bring down X' crash. There have been some konqueror
> > crashes in the past - but the same is true for 3.5. Compared with 3.2 or
> > 3.4 4.3 is a lot more stable (for me).
>
> Ok, maybe its because I started with kde 3.5 a few years ago but kde was
> never so unstable as with
>
> >> 3) Screen-setup: I have to monitores connected to my pc static in xorg
> >> as two seperated displays :0.0 and :0.1. If I start kde <4.4-svn I have
> >> both screens on my main monitor and the second is just as good as dead.
> >
> > ok, sounds like a genuine stupid bug. Can't even fixed with krandrtray?
>
> No, because I can't use randr as randr doesn't supports my setup at all.
> I had to deactivate randr-support in catalyst-drivers to get it working.
> With randr only stupid bigscreen is possible. This is the reason why I
> still stick with the closed driver, the open ones only support xrandr.

hm, latest catalyst do have randr-1.2 support, does that help?

>
> > but you know that you can make the plasma bar very small - and add a
> > couple of them to the desktop?
>
> Yes I know. But then many things aren't useable anymore because scaling
> of the icons freaks out here if it gets to small.

hm, the only icons that don't scale well 'here' are the ones in systemtray.

> 1) the collection-scanner is broken. Only approx. 400 songs are added to
> the collection. I have over 10000 songs on my pc.

my current collection has ~1700 songs

>
> 2) Support for generic mp3-players doesn't exist or needs workarounds
> (in live-builds atm)

okay, I never used that feature, so I can't say anything about it. I see the 
mtp useflag - but again, never used.


>
> 3) Not really a mising feature but amarok 2 looks like crap. I like the
> way 1.4 looks and hate that amarok 2 forces me to learn everything new.
> But forcing users to learn new ways to do old things its all that is
> kde4. I hate it if i get forced to do something.

'learn everything new'? Collection left, check, Playlist right, check. Play 
buttons on top. check. Also you can radically change the look of amarok the 
way you want it to look like.

btw: amarok version 2.1.1

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Sebastian Beßler]

Volker Armin Hemmann schrieb:
> On Dienstag 25 August 2009, Sebastian Beßler wrote:

>> No, because I can't use randr as randr doesn't supports my setup at all.
>> I had to deactivate randr-support in catalyst-drivers to get it working.
>> With randr only stupid bigscreen is possible. This is the reason why I
>> still stick with the closed driver, the open ones only support xrandr.
> 
> hm, latest catalyst do have randr-1.2 support, does that help?

Yes, it has and I had to deactivate it to get my setup running. Do you
really read what I am writing?
As I said randr doesn't support two separated displays, only
bigscreen-mode. The people programming xorg and randr say that there is
no need for the old behavior because nearly everything can be done with
randr. Nearly yes but not that what I now have and need.

> my current collection has ~1700 songs

maybe it is something here, filename, filetype.
I don't know and I don't care what it is as long as it doesn't work.

> okay, I never used that feature, so I can't say anything about it. I see the 
> mtp useflag - but again, never used.

mtp - Enable support for Media Transfer Protocol
That is only for devices that uses this protocol, not for generic usb
filesystem devices. For those it is needed (in live-builds) to create a
hidden file on that device so that amarok can use it.

>> 3) Not really a mising feature but amarok 2 looks like crap. I like the
>> way 1.4 looks and hate that amarok 2 forces me to learn everything new.
>> But forcing users to learn new ways to do old things its all that is
>> kde4. I hate it if i get forced to do something.
> 
> 'learn everything new'? Collection left, check, Playlist right, check. Play 
> buttons on top. check. Also you can radically change the look of amarok the 
> way you want it to look like.

With amarok 1.4 I have one big playlist window and on the left side the
vertical tabs with all the other menues.

With amarok 2 there are three areas. Maybe it is only me, but that is a
fundamentel difference, the whole interface design changed.

I am a user not a designer. I don't know how to create a new design or
whatever needed to make it look and behave like what I had before.

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Volker Armin Hemmann]

On Dienstag 25 August 2009, Sebastian Beßler wrote:

> I am a user not a designer. I don't know how to create a new design or
> whatever needed to make it look and behave like what I had before.

kde-look.org amarok themes. There you go.

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Sebastian Beßler]

Volker Armin Hemmann schrieb:
> On Dienstag 25 August 2009, Sebastian Beßler wrote:
> 
>> I am a user not a designer. I don't know how to create a new design or
>> whatever needed to make it look and behave like what I had before.
> 
> kde-look.org amarok themes. There you go.
> 

This link would be nice but there is no theme there that transforms the
look and feel of amarok 2 to that of 1.4.
There are only 10 themes new enough for a possibility to work with
amarok 2 and not one of those helps.

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Jesús Guerrero]

On Tue, August 25, 2009 19:17, Sebastian Beßler wrote:
> Volker Armin Hemmann schrieb:
>
>> On Dienstag 25 August 2009, Sebastian Beßler wrote:
>>
>
>>> No, because I can't use randr as randr doesn't supports my setup at
>>> all. I had to deactivate randr-support in catalyst-drivers to get it
>>> working. With randr only stupid bigscreen is possible. This is the
>>> reason why I still stick with the closed driver, the open ones only
>>> support xrandr.
>>
>> hm, latest catalyst do have randr-1.2 support, does that help?
>
> Yes, it has and I had to deactivate it to get my setup running. Do you
> really read what I am writing? As I said randr doesn't support two
> separated displays, only bigscreen-mode. The people programming xorg and
> randr say that there is no need for the old behavior because nearly
> everything can be done with randr. Nearly yes but not that what I now have
> and need.

Sorry to interrupt. Could you direct me how to disable xrandr for
this driver? I suspect it could be the culprit of a problem I am
having when updating it.

Thanks.
-- 
Jesús Guerrero

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Jesús Guerrero]

On Tue, August 25, 2009 23:56, Jesús Guerrero wrote:
>

> On Tue, August 25, 2009 19:17, Sebastian Beßler wrote:
>
>> Volker Armin Hemmann schrieb:
>>
>>
>>> On Dienstag 25 August 2009, Sebastian Beßler wrote:
>>>
>>>
>>
>>>> No, because I can't use randr as randr doesn't supports my setup at
>>>>  all. I had to deactivate randr-support in catalyst-drivers to get
>>>> it working. With randr only stupid bigscreen is possible. This is
>>>> the reason why I still stick with the closed driver, the open ones
>>>> only support xrandr.
>>>
>>> hm, latest catalyst do have randr-1.2 support, does that help?
>>
>> Yes, it has and I had to deactivate it to get my setup running. Do you
>> really read what I am writing? As I said randr doesn't support two
>> separated displays, only bigscreen-mode. The people programming xorg
>> and randr say that there is no need for the old behavior because nearly
>> everything can be done with randr. Nearly yes but not that what I now
>> have and need.
>
> Sorry to interrupt. Could you direct me how to disable xrandr for
> this driver? I suspect it could be the culprit of a problem I am having
> when updating it.

Ignore please, I found it myself. And it, indeed, solved my problem,
thanks a lot for the inspiration, this has been bothering me for
some time.


-- 
Jesús Guerrero

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Sebastian Beßler]

Jesús Guerrero schrieb:

> Ignore please, I found it myself. And it, indeed, solved my problem,
> thanks a lot for the inspiration, this has been bothering me for
> some time.

Just in case anyone is still trying to disable RandR 1.2 support in
catalyst driver ( and for me as a backup :-D ), the following command
worked for me:

# aticonfig --set-pcs-str="DDX,EnableRandR12,FALSE"

The command can be verified by looking at the amdpcsdb file:

# grep RandR /etc/ati/amdpcsdb
EnableRandR12=SFALSE

Make sure X isn't running when issuing this command as the amdpcsdb file
gets rewritten when X stops.

Greetings

Sebastian Beßler

[gentoo-amd64] Re: Re: Heads-up: KDEers: Particularly kde3-ers,

[Allistar]

Jesús Guerrero wrote:

> 
> On Tue, August 25, 2009 23:56, Jesús Guerrero wrote:
>>
> 
>> On Tue, August 25, 2009 19:17, Sebastian Beßler wrote:
>>
>>> Volker Armin Hemmann schrieb:
>>>
>>>
>>>> On Dienstag 25 August 2009, Sebastian Beßler wrote:
>>>>
>>>>
>>>
>>>>> No, because I can't use randr as randr doesn't supports my setup at
>>>>>  all. I had to deactivate randr-support in catalyst-drivers to get
>>>>> it working. With randr only stupid bigscreen is possible. This is
>>>>> the reason why I still stick with the closed driver, the open ones
>>>>> only support xrandr.
>>>>
>>>> hm, latest catalyst do have randr-1.2 support, does that help?
>>>
>>> Yes, it has and I had to deactivate it to get my setup running. Do you
>>> really read what I am writing? As I said randr doesn't support two
>>> separated displays, only bigscreen-mode. The people programming xorg
>>> and randr say that there is no need for the old behavior because nearly
>>> everything can be done with randr. Nearly yes but not that what I now
>>> have and need.
>>
>> Sorry to interrupt. Could you direct me how to disable xrandr for
>> this driver? I suspect it could be the culprit of a problem I am having
>> when updating it.
> 
> Ignore please, I found it myself. And it, indeed, solved my problem,
> thanks a lot for the inspiration, this has been bothering me for
> some time.

I've read this part of the thread with interest. Being a KDE3 user myself
(on AMD64) the one thing I won't sacrifice in the eventual move to KDE4 is:
a triple head setup with 2 separate desktops running compiz fusion on both.
I have two nVidia cards driving this and it works pretty well. I  have
my "main" desktop occupying the left two LCD's in "bigscreen" mode and the
other desktop (i.e. a separate KDE instance) in the right hand 3rd monitor.

Has anyone gotten a setup like this to work in KDE4 as it does in KDE3?

What's the compiz support like in KDE4?

Thanks,
Allistar.

Re: [gentoo-amd64] Re: Re: Heads-up: KDEers: Particularly kde3-ers,

[Volker Armin Hemmann]

On Donnerstag 27 August 2009, Allistar wrote:
> Jesús Guerrero wrote:
> > On Tue, August 25, 2009 23:56, Jesús Guerrero wrote:
> >> On Tue, August 25, 2009 19:17, Sebastian Beßler wrote:
> >>> Volker Armin Hemmann schrieb:
> >>>> On Dienstag 25 August 2009, Sebastian Beßler wrote:
> >>>>> No, because I can't use randr as randr doesn't supports my setup at
> >>>>>  all. I had to deactivate randr-support in catalyst-drivers to get
> >>>>> it working. With randr only stupid bigscreen is possible. This is
> >>>>> the reason why I still stick with the closed driver, the open ones
> >>>>> only support xrandr.
> >>>>
> >>>> hm, latest catalyst do have randr-1.2 support, does that help?
> >>>
> >>> Yes, it has and I had to deactivate it to get my setup running. Do you
> >>> really read what I am writing? As I said randr doesn't support two
> >>> separated displays, only bigscreen-mode. The people programming xorg
> >>> and randr say that there is no need for the old behavior because nearly
> >>> everything can be done with randr. Nearly yes but not that what I now
> >>> have and need.
> >>
> >> Sorry to interrupt. Could you direct me how to disable xrandr for
> >> this driver? I suspect it could be the culprit of a problem I am having
> >> when updating it.
> >
> > Ignore please, I found it myself. And it, indeed, solved my problem,
> > thanks a lot for the inspiration, this has been bothering me for
> > some time.
>
> I've read this part of the thread with interest. Being a KDE3 user myself
> (on AMD64) the one thing I won't sacrifice in the eventual move to KDE4 is:
> a triple head setup with 2 separate desktops running compiz fusion on both.
> I have two nVidia cards driving this and it works pretty well. I  have
> my "main" desktop occupying the left two LCD's in "bigscreen" mode and the
> other desktop (i.e. a separate KDE instance) in the right hand 3rd monitor.
>
> Has anyone gotten a setup like this to work in KDE4 as it does in KDE3?
>
> What's the compiz support like in KDE4?

what compiz support?

you can use compiz as a wm if you really have to. system-settings, default 
applications, windowmanager....

Re: [gentoo-amd64] Re: Re: Heads-up: KDEers: Particularly kde3-ers,

[Jeff Gardner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Volker Armin Hemmann wrote:

>> I've read this part of the thread with interest. Being a KDE3 user myself
>> (on AMD64) the one thing I won't sacrifice in the eventual move to KDE4 is:
>> a triple head setup with 2 separate desktops running compiz fusion on both.

Multi head is still a failure with kde-4*. As far as I'm concerned, this
is a show-stopper.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqWGX8ACgkQiR2KxEpdjyOVkQCfdFoBiHYExrSZWD0u1s7fL97K
+ywAn3teUKdOdXAkg3unj+Ryj7Dh3Zve
=VEmO
-----END PGP SIGNATURE-----

Re: [gentoo-amd64] Re: Re: Heads-up: KDEers: Particularly kde3-ers,

[Sebastian Beßler]

Jeff Gardner schrieb:
> 
> Volker Armin Hemmann wrote:
> 
>>> I've read this part of the thread with interest. Being a KDE3 user myself
>>> (on AMD64) the one thing I won't sacrifice in the eventual move to KDE4 is:
>>> a triple head setup with 2 separate desktops running compiz fusion on both.

Do you use xrandr for that or plain old static layout in xorg.conf?

> Multi head is still a failure with kde-4*. As far as I'm concerned, this
> is a show-stopper.

It is a lot better in recent live-builds.

[gentoo-amd64] Re: Re: Re: Heads-up: KDEers: Particularly kde3-ers,

[Allistar]

Sebastian Beßler wrote:

> Jeff Gardner schrieb:
>> 
>> Volker Armin Hemmann wrote:
>> 
>>>> I've read this part of the thread with interest. Being a KDE3 user
>>>> myself (on AMD64) the one thing I won't sacrifice in the eventual move
>>>> to KDE4 is: a triple head setup with 2 separate desktops running compiz
>>>> fusion on both.
> 
> Do you use xrandr for that or plain old static layout in xorg.conf?

No, a static layout in xorg.conf. From what I know, the XRANDR extension
doesn't play well with the COMPOSITE extension. Also the XINERAMA extension
doesn't play well with COMPOSITE either. (WHich is why I have two separate
X desktops instead of one by using XINERAMA).

>> Multi head is still a failure with kde-4*. As far as I'm concerned, this
>> is a show-stopper.
> 
> It is a lot better in recent live-builds.

Still sounds like it's a show stopper for me. Thanks for the feedback.

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

Allistar posted on Fri, 28 Aug 2009 10:05:31 +1200 as excerpted:

> No, a static layout in xorg.conf. From what I know, the XRANDR extension
> doesn't play well with the COMPOSITE extension. Also the XINERAMA
> extension doesn't play well with COMPOSITE either. (WHich is why I have
> two separate X desktops instead of one by using XINERAMA).

I've had no problem with RandR and Composite here.

Xinerama seems to be deprecated, almost.  At least I've not used actual 
xinerama in ages and from what I've read, yes, there are problems (not 
just with kde, but with X, and between RandR and Xinerama).  However, at 
least with the single-card-multi-output hardware I've seen, xinerama 
isn't actually necessary to use it, as "pseudo-xinerama" works, and seems 
to work fine.  The first I heard of pseudo-xinerama was with Radeon 
merged-framebuffer mode, before RandR, but it seems to be an X default, 
now, no actual Xinerama extension needed.

But I think xinerama is still needed for actual multiple cards, and with 
the lower use it's getting these days due to the built-in pseudo-
xinerama, it does seem to not be keeping up, or at least, I've read more 
about problems than about using it problem-free, since RandR.

-- 
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

[gentoo-amd64] Re: Re: Re: Heads-up: KDEers: Particularly kde3-ers,

[Allistar]

Jeff Gardner wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Volker Armin Hemmann wrote:
> 
>>> I've read this part of the thread with interest. Being a KDE3 user
>>> myself (on AMD64) the one thing I won't sacrifice in the eventual move
>>> to KDE4 is: a triple head setup with 2 separate desktops running compiz
>>> fusion on both.
> 
> Multi head is still a failure with kde-4*. As far as I'm concerned, this
> is a show-stopper.

I would have thought multi-head was a function of xorg and not of KDE
itself. I suppose KDE does need to know something of the screen layout
though.

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

Volker Armin Hemmann posted on Tue, 25 Aug 2009 01:33:23 +0200 as
excerpted:

> n Montag 24 August 2009, Sebastian Beßler wrote:
>> szalkai@szalkai.net schrieb:
>> > Duncan please give some examples of major breakage in KDE4?
>>
>> I'm not Duncan but I have 5 reasons not to switch to kde4 atm.
>>
>> 1) Speed: I have a AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ with
>> 8GB of ram and a Radeon HD 3600 card but still kde 4.3 most of the time
>> feels like walking through mud.
> 
> turn of composite or install a xorg-server with the
> fedora_dont_backfill_bg_none.patch and see kde fly.

In general, agreed, but there's more too it than that.  Here, while I did 
need to make config changes, it wasn't near as drastic as turning off 
composite or even just window translucency, tho in testing that did work, 
and I didn't have to go patching my xorg either, tho that may well be the 
most effective for frglx users, the ones with the biggest problems 
dealing with that patch.

The performance problem as I experienced it was a multi-headed hydra.  
Fixing one issue helped but there were others too.  Only after dealing 
with (or bypassing, as just shutting off composite does) them all did I 
have a kde4 desktop anything close to as responsive as my kde3 desktop 
had been.

Two of the issues had been dealt with by the time I started my real push 
to get kde4 working here, with 4.2.4.  One kde fixed, one's still a kde 
issue but I had learned my way around it by that point.

The one kde fixed was that in early kde4 versions, it was way to easy to 
set OpenGL rendering when it was broken on that hardware, as early kde4 
did nothing to stop you.  Not only would that result in a crash, but it 
would often result in kde being unable to start again, because it was now 
set to broken OpenGL.  By 4.2.4 (and I think for 4.2.0, maybe even 
4.1.something), kde had fixed that.  It now tries to detect if OpenGL 
will work before setting it, and normally won't let you set it if it 
thinks it won't work.  You can override it, but in ordered to do so you 
have to click thru several warnings, and anybody doing that should be 
prepared to live with the consequences.  One bug down, and a very bad one 
at that, so good work, kde.

The one I had learned around, that still exists, is that while kde now 
detects OpenGL compatibility and won't let you switch to it without 
warnings if it thinks it won't work, on the all-effects tab (of the 
desktop effects settings applet), there's still no indication of what 
effects simply do nothing in xrender/composite-only mode.  One thus has 
to trial-and-error enable and test anything that looks interesting one by 
one, and if it does nothing, preferably disable it again.  If they won't 
work anyway in xrender/composite-only mode, they should be disabled in 
that mode, so only the effects that actually work are available to select 
and try.  Since most don't work without OpenGL, showing them as available 
to try and then having them do nothing when people do just that, is 
confusing at best.  Dim them out and don't let people select them in that 
case, and usability on that tab for Composite-only users would go up 
several hundred percent.  By 4.2.4 however, when I decided to really push 
toward a usable and well configured for my use kde4, I had already 
learned which ones did nothing, so that didn't bother me any more, other 
than simply knowing it continues to be an issue.

That leaves the two issues I actually had to deal with in my push.

By this time, Gentoo/kde had straightened out pretty much all of the kde3/
kde4 combination issues and it was possible to run a kde4 app on a kde3 
desktop, or conversely, without the settings for the one being 
overwritten by the other.  As it was obvious I wasn't making much 
progress trying to go whole-hog kde4, and it was now possible, I decided 
to try running and configuring individual kde4 apps on my kde3 desktop, 
so by the time I actually switched to a kde4 desktop, at least the 
individual apps would mostly be already configured to my liking.

It was thus that I was able to discover these two issues separately, as 
otherwise, the one would have masked the other, and performance was so 
bad on kde4 that I had trouble getting anything serious at all done.

So it was that I began working thru the major kde4 apps one by one on my 
kde3 desktop, unmerging the kde3 version so the kde4 version would be 
invoked when I ran the app (with FEATURES=buildpkg, I could always emerge 
-K the kde3 version and get back a working config if necessary, but it 
turned out not to be necessary) configuring them as necessary, then going 
on to the next one.  Since kcontrol is v3 and systemsettings v4, I was 
able to easily invoke systemsettings as necessary from kde3 as well, thus 
able to configure all those without issue (well, without issue running it 
on kde3, at least.  There was the colors issue I already posted about, 
and another one I might discuss later.)  konsole, kmail, konqueror, all 
the normal apps, passed without major issue.

After I got thru with the normal apps, I thought a bit about kwin, then 
killed the kde3 version, and launched the kde4 version, direct from 
konsole window.  It worked! =:^)

Well, sort of. kwin v4 launched just fine, and the colors as configured 
in systemsettings worked, and the kde4 kwin setting all took effect, but 
NOW THE SYSTEM WAS SLOW!  I had found the first of the what turned out to 
be two performance issues.

In Desktop Effects, All Effects tab, second from the bottom of the 
Appearance section, is Translucency.  With it enabled (as I had it since 
it worked just fine on kde3), click on the wrench button to configure 
it.  At the bottom of the left-hand column is Fading duration.  This was 
my problem.

On fading duration, if you hit the spinner, you'll note that each 
increment is 100 ms.  I'm not sure what the default was, but it was WAY 
too high.  While the obvious intent is that it's supposed to be the 
duration of the entire effect, it seems here as if it configures the 
duration for each step of the animation.  What was obviously several 
hundred ms seemed to do that for each step, with the entire effect 
running for several seconds.  Moving between one window and another just 
once, that worked, if it was slightly slow, but with several windows on 
the desktop and focus follows mouse (my default) set, it did NOT work, as 
now it was several seconds per transition, five, ten, twenty seconds 
after I stopped moving the mouse before the effects finished doing their 
thing!  WAY WAY WAAAAYYY too slow!!

The simple thing is to simply set that to instant, 0 ms.  However, typing 
a specific value in the textbox also works, and I discovered that 
anything up to about 20ms was fine.  But of course using the spinner, the 
resolution means 0 or 100ms, unless you type it in.

A related setting that I didn't notice in 4.2.4 so I'm not sure if it's 
there or not, but that I DID notice in 4.3.0, is back in the Desktop 
Effects dialog, on the General tab.  Animation speed, with choices of 
instant, very fast... extremely slow.  Apparently, this controls what the 
"default" value in the fading duration setting above is.  Of course, I 
now have that set to instant.  But back in 4.2.4 when I discovered the 
problem, I'm not sure if the General tab setting was there or not, and it 
was the fading duration setting that I was able to configure to kill that 
problem.

That was the first of the two performance issues I ran into.  The rest of 
the kwin v4 on kde3 configuration went without issue, and I used kde3 
with kwin v4 for several hours, no problem at all, after I fixed the 
duration thing.

That was the last thing I could really configure from the kde3 desktop, 
so after that, it was time to actually try kde4 again, and see if it 
worked better now.  Pretty much the only thing remaining to configure was 
the desktop itself, replacing kdesktop and kicker with plasma, when 
restarted X with the kde4 desktop.  So that's what I did, hoping the kwin 
duration fix now had kde4 running smoothly.  BUT KDE4 WAS STILL SLOW!!

What could be the problem now?  Turn off transparency just to check, sure 
enough the problem went away.  But it couldn't be /just/ that, as that's 
a kwin v4 thing, and I had it running fine on kde3.  So the problem now 
had to be the kde4 desktop itself, or rather, how it interacted with kwin.

Sure enough, the second problem was plasma, but what and how?  Well, I 
was asking myself the same question.  What was different between kicker/
kdesktop and plasma, that could have plasma being slow much slower?

Then I had my answer.  When I had been experimenting with earlier kde4 
versions, before the panels worked very well, I had put a number of 
plasmoids on the desktop.  Back in kde3, I routinely ran the ksysguard 
kicker applet, monitoring cpu activity, coretemps, load, memory, etc, and 
as kde4 had ksysguard (aka system monitor) but no ksysguard plasmoid to 
replace the ksysguard kicker applet, I had the cpu temps and cpu activity 
system monitor plasmoids, among others, on the desktop.

Of course, kde3's kdesktop was much more static.  What thus ended up 
being the problem was all those dynamically updating plasmoids on the 
desktop -- triggering a bug I'll mention in a moment, but not even kde 
devs knew about that bug at the time, and it was too technical for users 
to groke.

But what I decided (correctly, tho I didn't realize the ultimate cause) 
was that since the problem went away when I disabled transparency, and 
since it had to be plasma related, and since kde3's kdesktop didn't show 
the issue, it had to be due to all those plasmoids on the desktop -- that 
was the biggest difference between it and kdesktop.

What I decided was happening was that with those dynamically updating 
plasmoids on the desktop, by themselves, everything worked relatively 
fine.  But with several layers of windows over top, with those dynamic 
updates having to work themselves up the stack thru layers of semi-
transparent windows, the updates to the entire stack must be killing the 
performance.  Again, I was right, but for the wrong reason, as we'll see.

Anyway, as I suspected, when I created new panels to put the widgets in 
and moved the widgets from the desktop onto the panels, the issue 
disappeared.  I expected it would, because the panels are normally either 
hidden, or on top.  There's not the multiple layers of compositing going 
on that I thought was the problem.

So that's what I did, I moved all the widgets off my desktop.  It's the 
bare wallpaper now, not so much as a folderview on it.  And my 
performance is back to normal! =:^)

So it took two config changes to get reasonable performance.  First, 
kwin's translucent window effects needed set to instant.  Second, at 
least for now, the plasma desktop can't have plasmoids, particularly 
dynamically updating plasmoids, on it.  Either of those wrong is a 
performance killer, and together, they were REALLY bad.  What's worse, it 
would have been quite difficult to figure it out, had I not taken one app 
at a time as I did, because the other issue would have always masked the 
improvement to some degree even if I /did/ get the one right.  So I was 
very fortunate in a way, in that I did have the opportunity to run apps 
from the one on the other (on some distributions, that's not possible, 
and it wasn't on Gentoo for awhile either, because you ended up with 
screwed up settings every time you tried, but the Gentoo/kde folks 
finally got that working =:^), and in that I did have the insight to try 
tackling the issues a single app at a time.

OK, so what's the real problem I keep mentioning?  Just a couple weeks 
ago, one of the kde hackers realized there was a qt4 bug.  The plain 
English version is this:  On qt4 to-date, if a graphic element is 
entirely removed without first deleting it from the parent graphics 
context (think removing a widget that's no longer needed, without first 
telling qt to delete it from the window it had been drawing it on), qt 
triggers a redraw of the entire context (the entire window), instead of 
just the bit where the widget was at.  It shouldn't matter.  If the 
element is removed, qt should know where it was, and be smart enough to 
repaint just that bit, regardless of whether it was actually deleted from 
the drawing context first, or not.

A lot of kde devs had code that did the removal without the delete first, 
and the last couple weeks they've been committing fixes.  Some of these 
will make it to 4.3.1 or 4.3.1.  Others might not make it until 4.4.0

Now if it's just one single event, that's not too bad, a single redraw of 
an entire window takes a fraction of a second, but if if that's all it 
is, a single event, no big deal.

But guess who was one of the big users of the bad code?  Right, plasma.  
Turns out that each plasmoid update was triggering a repaint, not for 
that relatively small rectangular area, BUT FOR THE ENTIRE CONTAINER.  
Now that's bad enough if it's a panel, but when that widget is on the 
desktop, ITS THE ENTIRE DESKTOP!  Of course, when it's a dynamically 
updating plasmoid such as a temperature or CPU activity gauge, guess 
what, you're now repainting the entire desktop at every update of that 
plasmoid.  And if there's several such plasmoids...

That's bad enough as it is, but when it's just the bare desktop, still 
tolerable.  But now consider what happens when that's being filtered up 
thru multiple layers of semi-transparent windows!  No *WONDER* people 
with older or not well accelerated graphics cards are having issues!  And 
on a desktop the size of mine, say 1920x2200 after the panels top and 
bottom are removed, still running on a vintage Radeon 9200, that's a HUGE 
performance issue!  No WONDER I was having problems with it!

According to asegio's blog, he's committed fixes for both 4.4 trunk and 
the 4.3 branch, which should hit 4.3.1.

So now I'm looking forward to 4.3.1, to see if I can put widgets back on 
the desktop again.

But meanwhile, its the stack of bugs such as this, that really shouldn't 
be appearing in an X.0 release let alone X.3, that's distressing.  And 
it's even /more/ distressing when support for the previous very stable 
version is being dropped, before the current version even gets up to 
normal X.0 version quality, let alone the X.1 that many wait for before 
they consider it safe to switch.

Still, regardless of the problems in version handling and premature end 
of support for earlier versions, good progress /is/ being made, and as 
I've said, I expect 4.4 to finally be what 4.0 should have been. with 4.5 
finally being well polished and ready for virtually everyone, thus 
replacing 3.5.  There's very good indications that 4.4 will meet that 
prediction, as should 4.5, and the finding and fixing of this bug is one 
of them.

-- 
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

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Volker Armin Hemmann]

On Mittwoch 26 August 2009, Duncan wrote:
  By 4.2.4 (and I think for 4.2.0, maybe even
> 4.1.something), kde had fixed that.  It now tries to detect if OpenGL
> will work before setting it, and normally won't let you set it if it
> thinks it won't work.  You can override it, but in ordered to do so you
> have to click thru several warnings, and anybody doing that should be
> prepared to live with the consequences.  One bug down, and a very bad one
> at that, so good work, kde.
>

no, it tries if composite works with the pre-selected composite type (either 
ogl or xrender).

And to turn off this test you only have to unselect one checkbox - without 
warnings. In fact, without that check composite works fine for me, while with 
the check my box loves to lock up with some driver versions.

xrender on the other hand is just utterly broken beyond help.


> The one I had learned around, that still exists, is that while kde now
> detects OpenGL compatibility and won't let you switch to it without
> warnings if it thinks it won't work, on the all-effects tab (of the
> desktop effects settings applet), there's still no indication of what
> effects simply do nothing in xrender/composite-only mode. 

except there is a warning popup when you enable composite telling you exactly 
which stuff does not work. Like explosion.


> One thus has
> to trial-and-error enable and test anything that looks interesting one by
> one, and if it does nothing, preferably disable it again.  If they won't
> work anyway in xrender/composite-only mode, they should be disabled in
> that mode, so only the effects that actually work are available to select
> and try. 

even better, per default only effects that work on the vast majority of systems 
are activated. If you are turning on the rest and they don't work you get a 
nice warning message after clicking the 'apply' button. You then can unselect 
them - or don't care because they are not used anymore.


> Since most don't work without OpenGL, showing them as available
> to try and then having them do nothing when people do just that, is
> confusing at best.  Dim them out and don't let people select them in that
> case, and usability on that tab for Composite-only users would go up
> several hundred percent.

confusing?
'Following effects could not be enabled:
Explosion'

right after the test. 
You can still enable them, in case the next driver update fixes that, the one 
you are installing in five minutes or ignore them, because they do no harm 
deactivated. 

What is not nice about it? Non working stuff is just ignored - and told so. If 
you choose to ignore the warnings - well, that is YOUR choice.

KDE is about choice, you know?


>
> After I got thru with the normal apps, I thought a bit about kwin, then
> killed the kde3 version, and launched the kde4 version, direct from
> konsole window.  It worked! =:^)
>
> Well, sort of. kwin v4 launched just fine, and the colors as configured
> in systemsettings worked, and the kde4 kwin setting all took effect, but
> NOW THE SYSTEM WAS SLOW!  I had found the first of the what turned out to
> be two performance issues.
>
> In Desktop Effects, All Effects tab, second from the bottom of the
> Appearance section, is Translucency.  With it enabled (as I had it since
> it worked just fine on kde3), click on the wrench button to configure
> it.  At the bottom of the left-hand column is Fading duration.  This was
> my problem.
>
> On fading duration, if you hit the spinner, you'll note that each
> increment is 100 ms.  I'm not sure what the default was, but it was WAY
> too high.  While the obvious intent is that it's supposed to be the
> duration of the entire effect, it seems here as if it configures the
> duration for each step of the animation.  What was obviously several
> hundred ms seemed to do that for each step, with the entire effect
> running for several seconds.  Moving between one window and another just
> once, that worked, if it was slightly slow, but with several windows on
> the desktop and focus follows mouse (my default) set, it did NOT work, as
> now it was several seconds per transition, five, ten, twenty seconds
> after I stopped moving the mouse before the effects finished doing their
> thing!  WAY WAY WAAAAYYY too slow!!
>

or you are using hardware that is way, way tooo slow. Or you are hit by the 
backfill patch fallout. Or you are using hardware that was never meant for this 
kind of stuff. 

What is your graphics adapter again?

> The simple thing is to simply set that to instant, 0 ms.  However, typing
> a specific value in the textbox also works, and I discovered that
> anything up to about 20ms was fine.  But of course using the spinner, the
> resolution means 0 or 100ms, unless you type it in.

and you can type it in. Isn't that userfriendly?

> That was the last thing I could really configure from the kde3 desktop,
> so after that, it was time to actually try kde4 again, and see if it
> worked better now.  Pretty much the only thing remaining to configure was
> the desktop itself, replacing kdesktop and kicker with plasma, when
> restarted X with the kde4 desktop.  So that's what I did, hoping the kwin
> duration fix now had kde4 running smoothly.  BUT KDE4 WAS STILL SLOW!!
>
> What could be the problem now?  Turn off transparency just to check, sure
> enough the problem went away.  But it couldn't be /just/ that, as that's
> a kwin v4 thing, and I had it running fine on kde3.  So the problem now
> had to be the kde4 desktop itself, or rather, how it interacted with kwin.

no. You are wrong here. kwin3 does not have 'real' transparency. Hust fake 
one. Fake one is pretty fast even on utterly broken hardware. Real 
transparency is used by kwin4. And that needs at least sane drivers and not 
hardware from yesrermillenium. You are comparing apples to oranges here.


>
> But guess who was one of the big users of the bad code?  Right, plasma.
> Turns out that each plasmoid update was triggering a repaint, not for
> that relatively small rectangular area, BUT FOR THE ENTIRE CONTAINER.
> Now that's bad enough if it's a panel, but when that widget is on the
> desktop, ITS THE ENTIRE DESKTOP!  Of course, when it's a dynamically
> updating plasmoid such as a temperature or CPU activity gauge, guess
> what, you're now repainting the entire desktop at every update of that
> plasmoid.  And if there's several such plasmoids...

they do nothing with recent enough graphics hardware :P

>
> That's bad enough as it is, but when it's just the bare desktop, still
> tolerable.  But now consider what happens when that's being filtered up
> thru multiple layers of semi-transparent windows!  No *WONDER* people
> with older or not well accelerated graphics cards are having issues!  And
> on a desktop the size of mine, say 1920x2200 after the panels top and
> bottom are removed, still running on a vintage Radeon 9200, that's a HUGE
> performance issue!  No WONDER I was having problems with it!

and now we are getting down to the interessting facts.

The short version of all your text:

'I had tried some graphic demanding stuff, turned into a even bigger workload 
by a small programming mistake on hardware that was even considered slow and 
underpowered when it was released 6 years ago.'


> But meanwhile, its the stack of bugs such as this, that really shouldn't
> be appearing in an X.0 release let alone X.3, that's distressing.  And
> it's even /more/ distressing when support for the previous very stable
> version is being dropped, before the current version even gets up to
> normal X.0 version quality, let alone the X.1 that many wait for before
> they consider it safe to switch.

you mean bugs that only hit when you use modern graphics on a 6 year old, slow 
even then, graphic adapter?

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

Volker Armin Hemmann posted on Wed, 26 Aug 2009 18:13:51 +0200 as
excerpted:

> On Mittwoch 26 August 2009, Duncan wrote:
>   By 4.2.4 (and I think for 4.2.0, maybe even
>> 4.1.something), kde had fixed that.  It now tries to detect if OpenGL
>> will work before setting it, and normally won't let you set it if it
>> thinks it won't work.  You can override it, but in ordered to do so you
>> have to click thru several warnings, and anybody doing that should be
>> prepared to live with the consequences.  One bug down, and a very bad
>> one at that, so good work, kde.
>>
>>
> no, it tries if composite works with the pre-selected composite type
> (either ogl or xrender).
> 
> And to turn off this test you only have to unselect one checkbox -
> without warnings. In fact, without that check composite works fine for
> me, while with the check my box loves to lock up with some driver
> versions.
> 
> xrender on the other hand is just utterly broken beyond help.

I wasn't aware of it checking composite (they dramatically improved that 
in 4.3.0 and I'm still discovering bits of it I didn't know about from my 
initial setup on 4.2.4), but it also checks OpenGL support, and that's 
what the warnings are on if you don't have it.

It seems you don't have an issue with OpenGL support, however, so you'd 
never see the warnings.  It would appear that just as I wasn't aware of 
some of the new composite stuff since that works just fine here, you 
weren't aware of the OpenGL stuff since that works just fine for you.

>> The one I had learned around, that still exists, is that while kde now
>> detects OpenGL compatibility and won't let you switch to it without
>> warnings if it thinks it won't work, on the all-effects tab (of the
>> desktop effects settings applet), there's still no indication of what
>> effects simply do nothing in xrender/composite-only mode.
> 
> except there is a warning popup when you enable composite telling you
> exactly which stuff does not work. Like explosion.

That popup appears whenever the mode changes, it would seem.  Composite 
toggle, it appears.  OpenGL/Xrender toggle, it appears as well.

Of course, on a system with everything working, it wouldn't appear except 
when switching out of OpenGL mode, if any OpenGL-only effects (like the 
mouse locater) are enabled.

But that doesn't cure the problem I'm talking about, which is that in 
Xrender/composite-only mode (no OpenGL), it should dim out the effects 
that require OpenGL.

For that matter, if composite doesn't work (or when it's disabled), it 
should dim out the effects requiring composite, too.  I think all the 
effects require one or the other, in which case with both disabled, the 
whole tab could be either disabled or removed.

>> One thus has
>> to trial-and-error enable and test anything that looks interesting one
>> by one, and if it does nothing, preferably disable it again.  If they
>> won't work anyway in xrender/composite-only mode, they should be
>> disabled in that mode, so only the effects that actually work are
>> available to select and try.
> 
> even better, per default only effects that work on the vast majority of
> systems are activated. If you are turning on the rest and they don't
> work you get a nice warning message after clicking the 'apply' button.
> You then can unselect them - or don't care because they are not used
> anymore.

Except I don't get that "nice warning".  With OpenGL off, Explode, the 
Cube, Track Mouse, Snow, Cover-switch, and perhaps others, silently allow 
enabling, no warning, they simply do nothing.  They should be dimmed out 
and not even available to be chosen, as they require OpenGL which isn't 
on.  

>> Since most don't work without OpenGL, showing them as available to try
>> and then having them do nothing when people do just that, is confusing
>> at best.  Dim them out and don't let people select them in that case,
>> and usability on that tab for Composite-only users would go up several
>> hundred percent.
> 
> confusing?
> 'Following effects could not be enabled: Explosion'

Except that only pops up when the mode is switched, not when specific 
items are enabled and/or when one hits apply.

> right after the test.
> You can still enable them, in case the next driver update fixes that,
> the one you are installing in five minutes or ignore them, because they
> do no harm deactivated.
> 
> What is not nice about it? Non working stuff is just ignored - and told
> so. If you choose to ignore the warnings - well, that is YOUR choice.

Except as I've said, there are no warnings for effect toggles, only when 
the composite/opengl/xrender the mode is switched.

> KDE is about choice, you know?

Indeed.  Something we agree on! =:^)

> or you are using hardware that is way, way tooo slow. Or you are hit by
> the backfill patch fallout. Or you are using hardware that was never
> meant for this kind of stuff.

This part is purely a settings thing, no more, no less.  If people are 
having trouble with performance, these settings should help, as they did 
me.  I was simply passing them on for others who may find them helpful.  
No more, no less.

>> The simple thing is to simply set that to instant, 0 ms.  However,
>> typing a specific value in the textbox also works, and I discovered
>> that anything up to about 20ms was fine.  But of course using the
>> spinner, the resolution means 0 or 100ms, unless you type it in.
> 
> and you can type it in. Isn't that userfriendly?

??  I wasn't saying it wasn't userfriendly.  All I'm saying is that the 
spinner increment is too high -- don't use it when setting this, if 
you're doing it in ordered to increase performance, anyway.  Just type it 
in.  So I've no idea where you're comment is coming from.  It makes no 
sense in context.

>> What could be the problem now?  Turn off transparency just to check,
>> sure enough the problem went away.  But it couldn't be /just/ that, as
>> that's a kwin v4 thing, and I had it running fine on kde3.  So the
>> problem now had to be the kde4 desktop itself, or rather, how it
>> interacted with kwin.
> 
> no. You are wrong here. kwin3 does not have 'real' transparency. Hust
> fake one. Fake one is pretty fast even on utterly broken hardware. Real
> transparency is used by kwin4. And that needs at least sane drivers and
> not hardware from yesrermillenium. You are comparing apples to oranges
> here.

Yes, kwin3 *DID* have real transparency, working with xorg composite, 
which provided the functionality.  Without composite, it didn't work, so 
yes, it /was/ real xorg based composite transparency.

In that regard, kwin4 uses exactly the same composite functionality that 
kwin3 used.

What I believe you're referring to is the "fake" transparency certain 
kde3 apps (kicker and konsole, at least) used well before xorg composite 
even appeared.  Not only were they doing it earlier, so it couldn't 
/possibly/ have used xorg's composite, but unlike the xorg composite 
based transparency of kwin3 (from 3.5.1, IIRC), it was clearly "fake" 
from a developer perspective in that all it did was take the desktop 
pixel values and blend them with the application window pixel values, to 
form a "fake" transparency that was actually simply duplication and 
blending at the individual application window level.  It was clearly 
"fake" transparency from a user perspective as well, since it didn't 
"see" any intervening windows between it and the desktop, like "real" 
composite based transparency does.

That's a mistaken generalization of fact that a lot of people make.  
konsole3 and kicker never had "real" transparency, no, it was all faked.  
But kwin itself did, using the same xorg composite extension that kwin4 
does for that and other non-OpenGL based effects.  Zooming, drop-shadows, 
the zooming based present-windows task-switcher and desktop-grid effects, 
all these are composite based, using the /same/ xorg composite technology 
kwin3 did, post 3.5.1, I believe was the version that introduced it.

>> But guess who was one of the big users of the bad code?  Right, plasma.
>> Turns out that each plasmoid update was triggering a repaint, not for
>> that relatively small rectangular area, BUT FOR THE ENTIRE CONTAINER.
>> Now that's bad enough if it's a panel, but when that widget is on the
>> desktop, ITS THE ENTIRE DESKTOP!  Of course, when it's a dynamically
>> updating plasmoid such as a temperature or CPU activity gauge, guess
>> what, you're now repainting the entire desktop at every update of that
>> plasmoid.  And if there's several such plasmoids...
> 
> they do nothing with recent enough graphics hardware :P

And you know why?  It's because the graphics hardware accelerates the 
repaint, and is smart enough to realize that the entire desktop doesn't 
need repainted, despite the instructions it was handed. =:^)  But qt's 
still handing the hardware bad instructions.  The hardware's just smart 
enough to recognize and ignore the parts that haven't actually updated 
and thus don't actually need repainted.

But of course not everybody has that level of hardware acceleration yet.

>> That's bad enough as it is, but when it's just the bare desktop, still
>> tolerable.  But now consider what happens when that's being filtered up
>> thru multiple layers of semi-transparent windows!  No *WONDER* people
>> with older or not well accelerated graphics cards are having issues! 
>> And on a desktop the size of mine, say 1920x2200 after the panels top
>> and bottom are removed, still running on a vintage Radeon 9200, that's
>> a HUGE performance issue!  No WONDER I was having problems with it!
> 
> and now we are getting down to the interessting facts.
> 
> The short version of all your text:
> 
> 'I had tried some graphic demanding stuff, turned into a even bigger
> workload by a small programming mistake on hardware that was even
> considered slow and underpowered when it was released 6 years ago.'

May be, but that doesn't change the need to do the tweaks to fix the 
problem, which was what the entire post was about.  Given the problems 
others have posted, it's likely to be helpful to them as it was to me, 
and there's no reason they should have to do all the same work I did to 
rediscover what I already know, after learning it the hard way.

>> But meanwhile, its the stack of bugs such as this, that really
>> shouldn't be appearing in an X.0 release let alone X.3, that's
>> distressing.  And it's even /more/ distressing when support for the
>> previous very stable version is being dropped, before the current
>> version even gets up to normal X.0 version quality, let alone the X.1
>> that many wait for before they consider it safe to switch.
> 
> you mean bugs that only hit when you use modern graphics on a 6 year
> old, slow even then, graphic adapter?

Could be, but regardless, there's people out there using such hardware, 
and the posted information both explains how I discovered the issues, and 
the workarounds and configuration tweaks necessary to get decent 
performance anyway, despite the age and speed of the hardware.

-- 
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

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[BRM]

----- Original Message ----
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-amd64@lists.gentoo.org
Sent: Thursday, August 27, 2009 7:15:38 AM
Subject: [gentoo-amd64]  Re: Heads-up: KDEers: Particularly kde3-ers,
Volker Armin Hemmann posted on Wed, 26 Aug 2009 18:13:51 +0200 as
excerpted:
> > they do nothing with recent enough graphics hardware :P
> And you know why?  It's because the graphics hardware accelerates the 
> repaint, and is smart enough to realize that the entire desktop doesn't 
> need repainted, despite the instructions it was handed. =:^)  But qt's 
> still handing the hardware bad instructions.  The hardware's just smart 
> enough to recognize and ignore the parts that haven't actually updated 
> and thus don't actually need repainted.
> But of course not everybody has that level of hardware acceleration yet.
> >> That's bad enough as it is, but when it's just the bare desktop, still
> >> tolerable.  But now consider what happens when that's being filtered up
> >> thru multiple layers of semi-transparent windows!  No *WONDER* people
> >> with older or not well accelerated graphics cards are having issues! 
> >> And on a desktop the size of mine, say 1920x2200 after the panels top
> >> and bottom are removed, still running on a vintage Radeon 9200, that's
> >> a HUGE performance issue!  No WONDER I was having problems with it!
> > and now we are getting down to the interessting facts.
> > The short version of all your text:
> > 'I had tried some graphic demanding stuff, turned into a even bigger
> > workload by a small programming mistake on hardware that was even
> > considered slow and underpowered when it was released 6 years ago.'
> May be, but that doesn't change the need to do the tweaks to fix the 
> problem, which was what the entire post was about.  Given the problems 
> others have posted, it's likely to be helpful to them as it was to me, 
> and there's no reason they should have to do all the same work I did to 
> rediscover what I already know, after learning it the hard way.
> >> But meanwhile, its the stack of bugs such as this, that really
> >> shouldn't be appearing in an X.0 release let alone X.3, that's
> >> distressing.  And it's even /more/ distressing when support for the
> >> previous very stable version is being dropped, before the current
> >> version even gets up to normal X.0 version quality, let alone the X.1
> >> that many wait for before they consider it safe to switch.
> > you mean bugs that only hit when you use modern graphics on a 6 year
> > old, slow even then, graphic adapter?
> Could be, but regardless, there's people out there using such hardware, 
> and the posted information both explains how I discovered the issues, and 
> the workarounds and configuration tweaks necessary to get decent 
> performance anyway, despite the age and speed of the hardware.

I have to agree with Duncan on this one. (not that that's a bad thing - I've really enjoyed his insights on this thread.)

Not everyone upgrades their video card every 6 months.
Most probably get a video card upgrade only when they buy a new computer;
and most don't buy a new computer every other year either, probably more like 4 years or so.

I typically buy a new computer about every 8 years; and most people I know are probably between 4 and 8 years.

So yes, KDE4 must be able to handle older hardware as Duncan describes.

Glad you have the cash to burn on more frequent updates, but you're in the minority of computer users in general.

One of the things I love about gentoo is using my older hardware - my server running gentoo (and hosting portage for my internal network) is a PII 233 from 1997.
My gentoo laptop is a Pentium M from 2003; and my desktop is an AMD64 from 2005; both run KDE3 and will be running KDE4 in time - just waiting for Gentoo to mark stable on respective architectures as I don't want to play with testing on these systems at that kind of level.

And I'm sure there are plenty of users in the same boat as me. I may be a computer enthusiast, but I don't have cash to burn on "frequenty" hardware upgrades. I make the hardware I have last as long as I can - I just retired a P90 Slackware-base server last spring, but then only b/c the hard drive (from 1997) died due to the system being placed badly the truck during a move.

Ben

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Mark Knecht]

On Thu, Aug 27, 2009 at 6:16 AM, BRM<bm_witness@yahoo.com> wrote:
<SNIP>
>
> I have to agree with Duncan on this one. (not that that's a bad thing - I've really enjoyed his insights on this thread.)

As do I.

>
> Not everyone upgrades their video card every 6 months.
> Most probably get a video card upgrade only when they buy a new computer;
> and most don't buy a new computer every other year either, probably more like 4 years or so.
>
> I typically buy a new computer about every 8 years; and most people I know are probably between 4 and 8 years.
>
> So yes, KDE4 must be able to handle older hardware as Duncan describes.
>
> Glad you have the cash to burn on more frequent updates, but you're in the minority of computer users in general.
>
> One of the things I love about gentoo is using my older hardware - my server running gentoo (and hosting portage for my internal network) is a PII 233 from 1997.
> My gentoo laptop is a Pentium M from 2003; and my desktop is an AMD64 from 2005; both run KDE3 and will be running KDE4 in time - just waiting for Gentoo to mark stable on respective architectures as I don't want to play with testing on these systems at that kind of level.
>
> And I'm sure there are plenty of users in the same boat as me. I may be a computer enthusiast, but I don't have cash to burn on "frequenty" hardware upgrades. I make the hardware I have last as long as I can - I just retired a P90 Slackware-base server last spring, but then only b/c the hard drive (from 1997) died due to the system being placed badly the truck during a move.
>
> Ben

We need better tools for creating and maintaining personal overlays.
Here is my story.

Support for old hardware has been one of the downfalls of the devs
deciding to not keep everything in portage but rather they start
weeding out software before we users have really finished using it. I
have 4 Asus Pundit-R machines which use an ATI chipset with
intergrated graphics. They are low profile machines and you cannot
just buy a new graphics controller for them. I use these machines as
MythTV frontends. (2 at my house, 2 at my parents) The machine has
S-Video outputs which drive most of our TVs and leave other inputs
free. At the time I bought the machines the Open Source radeon driver
didn't support S-Video so I had to use the ATI driver which worked
fine.

A couple of years ago ATI, in all wisdom, dropped TV Out support for
this specific chipset from their closed source driver so I was forced
to stick with the driver that was current at that time. This was OK
for awhile as it was in portage and I could just mask higher
revisions. However after awhile it turned out kernel updates forced
incompatibilities between new kernels and this old driver so I was
forced to mask newer revisions than the last one that worked with the
last radeon driver that worked.

3 months go by and portage maintainers decide to start weeding 'old'
software out and, you guessed it, they weeded out what I needed to run
this hardware. The ATI driver was gone. The kernel was gone. No
discussions, no announcements. It was just gone. A machine I could
build and run using a Gentoo 2006 install CD could no longer be built
and run using a 2008 CD.

Then I'm forced to learn about attics, building overlays, etc. It was
a mess for a long time.

Recently the Open Source driver has started to support TVOut on this
version of the Radeon hardware, so I'm now back to using Open Source,
but video quality is FAR inferior to the ATI driver, although CPU
usage is far superior so at least with OS I have a quiet machine while
watching a bad picture.

Moral of the story - don't trust portage to support your machine
tomorrow just because it works today, and don't expect portage
maintainers to care. The response you'll get, if you get one at all,
is 'be a man, create your own overlay, be responsible for your
machine, and shut up'.

From experience,
Mark

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Arttu V.]

On 8/27/09, Mark Knecht <markknecht@gmail.com> wrote:
> Moral of the story - don't trust portage to support your machine
> tomorrow just because it works today, and don't expect portage
> maintainers to care. The response you'll get, if you get one at all,
> is 'be a man, create your own overlay, be responsible for your
> machine, and shut up'.

Given the possibly large-ish number of folks trying to run Gentoo on
older hardware with similar problems, and given that there already are
overlays for "bleeding edge" (qting-edge, kde-crazy, everything with
live-scm ebuilds etc), maybe some of the old hw owners should organize
a bit and try to pool their time into, e.g., a "grandpas-trusty"
overlay with much of the old ebuilds easily available or something.

I think it has already been suggested and considered that everything
that gets removed from portage would instead get moved into some
"old-stuff-dump" overlay, but I just don't have the time to look up
any references and discussion over it right now ...

Naturally it is not a perfect solution as bit-rot will inevitably get
you when things like APIs and ABIs change enough, but just not having
to hunt down everything from Attics (not to mention patch-packages and
the original sources) into local overlays would probably be a
considerable time-saver.

But once again, it comes down to the question "ok, maybe it could
work, who'll do it?" The regular devs seem to be pretty occupied given
their current workload, so they might not have the extra oomph saved
for this.

-- 
Arttu V.

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Mark Knecht]

On Thu, Aug 27, 2009 at 8:36 AM, Arttu V.<arttuv69@gmail.com> wrote:
> On 8/27/09, Mark Knecht <markknecht@gmail.com> wrote:
>> Moral of the story - don't trust portage to support your machine
>> tomorrow just because it works today, and don't expect portage
>> maintainers to care. The response you'll get, if you get one at all,
>> is 'be a man, create your own overlay, be responsible for your
>> machine, and shut up'.
>
> Given the possibly large-ish number of folks trying to run Gentoo on
> older hardware with similar problems, and given that there already are
> overlays for "bleeding edge" (qting-edge, kde-crazy, everything with
> live-scm ebuilds etc), maybe some of the old hw owners should organize
> a bit and try to pool their time into, e.g., a "grandpas-trusty"
> overlay with much of the old ebuilds easily available or something.
>
> I think it has already been suggested and considered that everything
> that gets removed from portage would instead get moved into some
> "old-stuff-dump" overlay, but I just don't have the time to look up
> any references and discussion over it right now ...
>
> Naturally it is not a perfect solution as bit-rot will inevitably get
> you when things like APIs and ABIs change enough, but just not having
> to hunt down everything from Attics (not to mention patch-packages and
> the original sources) into local overlays would probably be a
> considerable time-saver.
>
> But once again, it comes down to the question "ok, maybe it could
> work, who'll do it?" The regular devs seem to be pretty occupied given
> their current workload, so they might not have the extra oomph saved
> for this.
>
> --
> Arttu V.

Yes, the 'who' is always a big question in open source, and the only
reliable answer I've seen is 'the person who wants to', which
unfortunately can change over time.

It's not an answer to the whole problem as it wouldn't allow me to
build an old machine from scratch but I'd love to see some little
daemon that ran on my system and noticed when something I currently
had installed was being removed from portage. If it see this it would
automatically moved a copy of ebuilds and distfiles into some sort of
a local 'in-use' overlay so they'd still be available to me on this
machine. With something like that at least then nothing would be lost.
Maybe then there's a little app to allow me to remove it from the
overlay when I'm done wit it, or I'd do it by hand.

What I dislike about the current system is some person out there in
the ether deciding what's right for my hardware with the main criteria
being what's easy for him. Yes, I can, by hand and with time and
training, eventually find and replace things I need, but I have never
thought the way it is working now was the right way.

- Mark

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

Mark Knecht posted on Thu, 27 Aug 2009 09:25:01 -0700 as excerpted:

> If it see this it would automatically moved a copy of ebuilds and
> distfiles into some sort of a local 'in-use' overlay so they'd still be
> available to me on this machine. With something like that at least then
> nothing would be lost. Maybe then there's a little app to allow me to
> remove it from the overlay when I'm done wit it, or I'd do it by hand.
> 
> What I dislike about the current system is some person out there in the
> ether deciding what's right for my hardware with the main criteria being
> what's easy for him. Yes, I can, by hand and with time and training,
> eventually find and replace things I need, but I have never thought the
> way it is working now was the right way.

You're aware that you have a copy of the existing installed ebuild in the 
portage installed-packages database (typically /var/db/portage), right?  
That also contains a copy of the environment used to install the package 
as well, so all the eclasses as they were at installation, etc, tho it'd 
be a bit of work to reconstruct that.  And I'm not sure about the patches 
if any were applied.  But the ebuild, that's easy, and that's the most 
frequently needed bit.

For those with FEATURES=buildpkg, the ebuild is also glued to the end of 
the tarball containing the built binaries.  I happened to discover that 
before I did the /var/db/portage database, and used an editor to grab the 
ebuild out of the binpkg a couple of times.

-- 
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

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Arttu V.]

On 8/27/09, Mark Knecht <markknecht@gmail.com> wrote:
> I'd love to see some little
> daemon that ran on my system and noticed when something I currently
> had installed was being removed from portage.

Gentoo seems to provide a feed with the information (additions,
removals etc) parseable over here:

http://packages.gentoo.org/feed/

But there is no turn-key solution that I know of (not that I have been
looking for, so maybe there is, maybe there isn't).

-- 
Arttu V.

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

Mark Knecht posted on Thu, 27 Aug 2009 07:56:25 -0700 as excerpted:

> We need better tools for creating and maintaining personal overlays.

I'd like to explore that comment a bit, but below...

> Here is my story.
> 
> Support for old hardware has been one of the downfalls of the devs
> deciding to not keep everything in portage but rather they start weeding
> out software before we users have really finished using it. I have 4
> [old but special machines I use] as MythTV frontends.

> At the time I bought the machines the Open Source radeon driver didn't
> support S-Video so I had to use the ATI driver which worked fine.

When I first switched to Linux, I was in much the same boat.  While I had 
been researching a switch for a couple years, and had therefore verified 
that all my hardware purchases "did Linux", I wasn't yet aware of the 
difference between "Linux drivers" and "freedomware Linux driver".  I had 
thus verified that my nVidia card with "Twinview", one of the reasons I 
purchased it, did "Twinview" on Linux as well, but unfortunately didn't 
know to verify that the FLOSS drivers handled it.  Of course, the open 
source nv driver doesn't, due to lack of vendor cooperation.

Shortly after I actually /did/ switched to Linux and discovered all that, 
I vowed that while I couldn't at the time do anything about the video 
card I was running (no budget for a new one), that was the LAST time I 
would make that mistake!

And it was the last time I DID.  My cards since then have all been 
Radeons, and I've only purchased ones well supported by the freedomware 
drivers, which is why I'm still on a 9200, as that was the best 
freedomware supported for quite awhile, until AMD bought ATI and turned 
them around in that regard.

FWIW, I expect to upgrade video again shortly, I've had it penciled in 
for 2H2009 for awhile and that's what it is now.  It'll be to another 
Radeon of course, as with AMD at the helm, that is again the best 
freedomware choice.  As I'm still AGP, and the hdXXXX series (r6XX+) do 
better on PCI-E, I'll probably get the top of the line r5XX series, the 
x1950, altho I'd much prefer $100 to the $150 it still seems to be 
running.

> A couple of years ago ATI, in all wisdom, dropped TV Out support for
> this specific chipset from their closed source driver so I was forced to
> stick with the driver that was current at that time.

Yeah.  Well, as you note below, at least the freedomware drivers are 
picking up support for it now.

> This was OK for awhile as it was in portage and I could just mask
> higher revisions. However after awhile it turned out kernel updates
> forced incompatibilities between new kernels and this old driver so I
> was forced to mask newer revisions than the last one that worked with
> the last radeon driver that worked.

Yeah, that happens.  Expecially when you're running servantware drivers 
for hardware they've quit supporting.

> 3 months go by and portage maintainers decide to start weeding 'old'
> software out and, you guessed it, they weeded out what I needed to run
> this hardware.

Just a minor term correction.  As the term is normally used, "portage 
maintainers" would refer to those maintaining the portage package.

What you want would be something like "Gentoo devs" or "Gentoo tree 
maintainers", or here, it would have been the "package maintainers" for 
the packages in question, since newer versions of the same package 
remain.  If the entire package, all versions, is removed, that's often 
the tree cleaners project, or the devs in charge of the herd the package 
belonged to.  But in that case, there's an established procedure of a 30 
day package-mask and an announcement on the gentoo-dev list, in case 
another dev wishes to rescue it, and to give any users that may still be 
using it time to react, putting it in their overlay or switching to a 
different alternative, before the package is actually removed.  Plus, by 
the time it's removed, it's often dead upstream, abandoned, no longer 
compiling with current gcc and/or against current glibc, open bugs with 
little chance of fixing them, a Gentoo-dev maintainer that's either long 
retired or no longer interested in maintaining the package, etc.

Of course, this whole thread is about how kde3 is heading there, but it 
wouldn't count in this regard since there are newer versions, so it's not 
entire package removal, except for the kde3 packages that don't have kde4 
versions, in which case, yes, they'll go thru the mask and announcement 
for removal process, before final removal.  But one of the big 
differences here vs normal upgrades is that there's a real possibility 
they'll end up masking kde3 before kde4 goes stable, according to the kde 
meeting summary.  Plus, all the various things still keeping people on 
kde3, some of which are why kde4 is /not/ yet stable.

Meanwhile, you didn't do it here, but in general, and it's a habit I've 
had to correct myself as well, also note that what used to be termed the 
"portage tree", that is, the main Gentoo tree, really shouldn't be 
referred to as the portage tree anymore either, as there are other 
package managers (PMs).  For historical reasons, it's also often called 
the gentoo/x86 tree, even tho that isn't really accurate either since 
it's generally scripts for building from source on all archs (as we know 
in the context of this list).  But I guess the original Gentoo folks 
didn't realize that, and created their tree under an x86 subdir.

The most accurate way to refer to the main Gentoo tree, therefore, would 
be just that, or simply the Gentoo tree, or the Gentoo repository, since 
that's it's official name now, as can be seen in profiles/repo_name, 
distinguishing it from other repositories/overlays/trees, including those 
of Gentoo based distributions such as funtoo.

> The ATI driver was gone. The kernel was gone. No
> discussions, no announcements. It was just gone.

As mentioned, it's upto the package maintainer what versions he keeps in 
the tree, and there's no special process necessary when he decides to get 
rid of one, except that ordinarily, they're not supposed to remove the 
highest keyworded (either ~arch or stable) version without consulting 
with the arch team in question.  Of course, that's part of the process 
the kde team is going thru now, warning other devs that kde3 may end up 
masked...

Only if a package is removed entirely does the package removal process 
trigger, masked for 30 days with an announcement on -dev, then a removal 
if no-one has stepped up to maintain it and no other serious overrides.

> A machine I could build and run using a Gentoo 2006 install CD could no
> longer be built and run using a 2008 CD.
> 
> Then I'm forced to learn about attics, building overlays, etc. It was a
> mess for a long time.
> 
> Recently the Open Source driver has started to support TVOut on this
> version of the Radeon hardware, so I'm now back to using Open Source,
> but video quality is FAR inferior to the ATI driver, although CPU usage
> is far superior so at least with OS I have a quiet machine while
> watching a bad picture.

Well, might be poor solace, but at least you can see the good with the 
bad.

> Moral of the story - don't trust portage to support your machine
> tomorrow just because it works today, and don't expect portage
> maintainers to care. The response you'll get, if you get one at all, is
> 'be a man, create your own overlay, be responsible for your machine, and
> shut up'.

Umm... package maintainers, but that's covered above...

Of course, I'd say another moral is to pick hardware that's FLOSS 
supported from the beginning, if at all possible.  Sometimes it may not 
be, and then one has to decide whether it's worth the negatives to go 
servantware or not.  It's a decision I'd make differently than many here, 
but it /is/ an individual decision.

But, being able to create overlays and the like is one of the features of 
Gentoo, and I'd agree with them in that regard.  However, just because 
it's true, doesn't mean they shouldn't at least provide some pointers to 
documentation on creating an overlay, etc.  After all, it's other humans 
with very real problems of their own they're dealing with, and it's good 
to remember that just as us users need to remember that when we wonder 
why there's no apparent action on our bug.

But that brings us back full circle to what I mentioned above.  As 
someone who has gone thru it as an ordinary user, what /did/ you find 
most difficult about the process of creating your own overlay?  What sort 
of tools are you referring to, that could make the process easier?  I'm 
just a user too, but am perhaps more technical than most, and spend 
enough time on the dev list and etc, that while I didn't find the process 
particularly difficult, and don't really understand what sort of tools 
could have made it much simpler than I found it -- it was just a matter 
of taking the time to do it -- I can't take that as indicative of the 
problems an ordinary user may have.

The reason I'm asking, is that it's just this sort of feedback that devs 
often lack, and if between us and others here who may want to speak up as 
well, if it can be hashed out exactly what is causing the problems, 
perhaps I can present them to somebody who can do something about it.  
After all, it's not like the devs generally go out of their way to make 
things more difficult.  If there's a reasonable way to make the process 
easier, and it's not going to take an unreasonable amount of programming 
to make it so, there's a reasonable chance something can be done about it.

And... I'd not mind being a part of the project and any solution that 
might come of it.  After all, not only might I find it's easier for me 
too, but that's a another way I may be able to make my own contribution 
to this great big community project we call Gentoo, the even bigger one 
that's Linux, and the even BIGGER one that's the FLOSS community and 
projects in general. I may not be a coder, but if I can do something to 
help, I'll certainly give it a try!  =:^)

And of course the same applies to you.  If any changes come out of this, 
you can point to them and say it's because of you!  That's a very nice 
feeling to have! =:^)

(Of course, it's a similar feeling to the one I get as a reward for all 
the work I put into my posts here, when I see folks saying they actually 
find them useful, even to the point of archiving them. =:^)  I remember 
the first time someone mentioned saving my posts, back a very long time 
ago both in years and in changed personal situation, as it was about a 
decade ago, and it was a post I made to the IE4/OE4 beta newsgroups... 
how times have changed indeed, but you should have seen me after reading 
that comment, as I must have been walking about two feet off the ground!  
I know because it took me about a week before my feet touched ground 
again! =:^) That's a VERY powerful reward indeed!  =:^)

-- 
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

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Mark Knecht]

On Thu, Aug 27, 2009 at 9:52 AM, Duncan<1i5t5.duncan@cox.net> wrote:
<SNIP>
> Of course, I'd say another moral is to pick hardware that's FLOSS
> supported from the beginning, if at all possible.  Sometimes it may not
> be, and then one has to decide whether it's worth the negatives to go
> servantware or not.  It's a decision I'd make differently than many here,
> but it /is/ an individual decision.
>
<SNIP>

While I wholeheartedly agree - and whether or not someone takes action
on this agreement - the problem with Open Source is there is no real
commitment to support anything going forward, there is no commitment
to remove bugs if found, and there is no way to tell what the word
'supported' really means. It's up to the good graces and kindness of
those who write this stuff.

In the case of the Radeon 9100IGP chipset, it isn't that it's not
supported by the FLOSS driver - it was always supported, it's that a
certain FEATURE of the hardware wasn't supported. Now, if I had
purchased the machine specifically depending on this feature then
maybe I would have been more careful about understanding the level of
support, but the use of hardware changes over time. You buy a desktop
machine today and use it as a file server later. You buy a small
machine to use as a router and later decide to use it for MythTV.
Things change over time and we cannot always know how something will
be used, most especially I think with older hardware. We own it so we
try to use it. Better than scraping it and contributing to all the
trash problems we have on the planet.

Beyond all of that motherhood and apple pie stuff there's just the
problem of determining what the **REAL** quality and support is for
some piece of FLOSS. It's just nice people doing what they want to do.
It's great stuff, and amazing that we have what we have - operating
systems, desktops, applications - but it's not like we have real
quality control or a commitment to continuous improvement.

The current FLOSS radeon driver says there is support for TVOut on
this antiquated chipset.That is correct - it does work. However also
in truth, the picture on my TV is not pleasing and is so dark that in
many lighting conditions it is simply unusable. There are no xorg.conf
settings for changing brightness or contrast so I have no CPU level
control over it. Maybe it's an issue with this PC coupled with this
TV. Possibly it works better with other TVs. I don't know. The
developers do not seem inclined so far to help me out so I'm stuck for
now.

How do I address ALL of that prior to purchase? Look for someone using
the same hardware and driving the same TV? What's the chances? If I
cannot address ALL of it then it's still a shot in the dark.

Now, lest it sound like I'm complaining, I'm really not. I'm just
saying how I see the truth about this stuff. I prefer FLOSS when it
does what I need, but being FLOSS it may or may not be up to the
quality I can get from closed source support, especially in the area
of hardware support. If the closed source driver makes my wife happy
then who am I to tell her she cannot use it? Just because I'm
sys-admin for our midget little home network doesn't mean I want to
cook my own dinners or sleep on the back porch. We have wild animals
here. I'd like some guarantee of not being eaten at night! ;-)

Just my 2 cents,
Mark

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

Mark Knecht posted on Thu, 27 Aug 2009 11:15:15 -0700 as excerpted:

> Now, lest it sound like I'm complaining, I'm really not. I'm just saying
> how I see the truth about this stuff. I prefer FLOSS when it does what I
> need, but being FLOSS it may or may not be up to the quality I can get
> from closed source support, especially in the area of hardware support.

Agreed with everything you said.  Here, when FLOSS doesn't cut it for 
particular hardware, it's as if that feature doesn't exist on that 
hardware, since I don't consider non-FLOSS an option (now that I know the 
difference, as I said, I didn't when I check Linux support for that last 
nVidia card before I switched).  But as I said, that's a personal 
decision.  Others have different priorities and different consciences, 
and can consider the non-FLOSS option based on the the risks of when the 
company will drop updates.

-- 
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

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Sebastian Beßler]

Duncan schrieb:

> When I first switched to Linux, I was in much the same boat.  While I had 
> been researching a switch for a couple years, and had therefore verified 
> that all my hardware purchases "did Linux", I wasn't yet aware of the 
> difference between "Linux drivers" and "freedomware Linux driver". 

Here I see the same thing but reversed, as the "Linux driver" gives me
possibilities that the "freedomware Linux driver" don't give me as they
only support xrandr. The problem I have is that I can't hope for
anything that makes it better, only worse over time.

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Paul Hartman]

On Thu, Aug 27, 2009 at 8:16 AM, BRM<bm_witness@yahoo.com> wrote:
> Not everyone upgrades their video card every 6 months.
> Most probably get a video card upgrade only when they buy a new computer;
> and most don't buy a new computer every other year either, probably more like 4 years or so.

You can get a GeForce 9600 for around USD$50, which comes near the
performance of the famously-expensive 8800 series (or at least near
enough for costing hundreds of dollars less), and has an H.264 decoder
so you can use vdpau with mplayer or mythtv to allow even very slow
computers to play high-res video smoothly. Many people spend that much
to fill up their automobile or go out to to the movies or a dinner
with the family. I don't think it's an incomprehensible amount of
money to spend on something that will greatly improve performance on
your computer for quite a long time, but I also understand that
everyone has their own budget to live by, things are more expensive in
some countries, and some people are not technically inclined or
physically able to do things like changing a video card.

> I typically buy a new computer about every 8 years; and most people I know are probably between 4 and 8 years.

That seems about right to me, though 4 or 5 years in computers is a
lifetime. I know some people who are still using Windows 95 machines
at home (so old, even the viruses aren't compatible anymore!). And
most people are using Windows XP which just had its 8-year birthday. I
personally seem to upgrade about ever other CPU generation. I went
from an XT to a 386 to P2 to P4 to Core 2.

> So yes, KDE4 must be able to handle older hardware as Duncan describes.

Look on the bright side, the work they are doing now will be mature
and run smoothly on your next new computer and last you well into the
future another 4-8 years after that. :)

According to KDE FAQ on kde.org: "To run KDE it is recommended that
you have at least a pentium II processor, 64MB of memory and 500MB of
free disk space for a basic installation." Definitely not cutting-edge
hardware requirements. I think the requirements to compile KDE are
probably greater than the requirements to run it.

If you're trying to use all of the special 3D effects etc then of
course the requirements will be higher, just like windows vista 3D
effects require newer hardware. And it'll make things slower in many
cases, just like windows vista 3D effects. :)

My computer is fast compared to the ones you mentioned, but is not
cutting-edge: it is more than 2 years old, Abit motherboard (Abit
doesn't even exist anymore), Intel Core 2 Duo E6600 (no longer made),
Samsung 500GB 5400 RPM hard drive (current price new: USD$50), 8GB of
DDR800 RAM (USD$110) and a Nvidia Geforce 9600GT video card (USD$70),
but I disabled the desktop effects/3D stuff in KDE4 for a few reasons.
Primarily because everything feels a lot more responsive without it.
Also, none of the desktop effects that I used had any utility, they
were just "eye candy" (there are some which have real use, like
zooming out to see all windows, but I didn't use those) so I can live
without them. I would also have weird issues when using some 3D
programs, usually when pop-ups happened (new mail) it would get really
extremely slow and flicker, which does not happen when effects are
off. There was also the "X uses 100% CPU" problem that started around
the time of KDE 4.3; don't know if it's the fault of KDE or xorg or
nvidia-drivers but it does not happen when desktop effects are off.

I also have Gentoo on my laptop which is a little older. Athlon64 2.0
GHz with 1.25GB of RAM and ATI Mobile Radeon 9700 video card. Not a
bad laptop overall, but compared to the Core 2 it takes double the
time to compile things on average. KDE4 performance was actually not
bad on this machine, it felt about the same as the desktop machine
honestly, but the compile times were a killer to me. I don't know how
you guys use gentoo on such old old hardware, your machines must spend
more time compiling than not. :) For a laptop which is not my primary
device, it was a bit ridiculous in my case. Sometimes I may go 2 or 3
months without even turning the laptop on, so then I've have like a
weeks worth of compiling and updating to do. Gentoo is -definitely-
more manageable when you do the updates often (I do them daily on the
desktop). So, on the laptop I switched to XFCE (which has 3D effects
now too, by the way) primarily because of the much shorter compile
times and less frequent updates. If I used a different distro and
compiling wasn't a factor, I would probably still use KDE4 on that
machine, though. Too bad Gentoo is the best so I'm not going to
swtich. :)

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Sebastian Beßler]

Paul Hartman schrieb:
> On Thu, Aug 27, 2009 at 8:16 AM, BRM<bm_witness@yahoo.com> wrote:
>> Not everyone upgrades their video card every 6 months.
>> Most probably get a video card upgrade only when they buy a new computer;
>> and most don't buy a new computer every other year either, probably more like 4 years or so.
> 
> You can get a GeForce 9600 for around USD$50, which comes near the
> performance of the famously-expensive 8800 series (or at least near
> enough for costing hundreds of dollars less), and has an H.264 decoder
> so you can use vdpau with mplayer or mythtv to allow even very slow
> computers to play high-res video smoothly. 

Many mainboards from that time only have AGP not PCI-E and to get a 9600
with AGP is not easy or even possible, so that is not really a option.
And even if it is possible why trash a card that most of the time works
and needs only a fraction of the power of a modern card?

Greetings

Sebastian

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Paul Hartman]

On Thu, Aug 27, 2009 at 11:03 AM, Sebastian
Beßler<sebastian@darkmetatron.de> wrote:
> Paul Hartman schrieb:
>> On Thu, Aug 27, 2009 at 8:16 AM, BRM<bm_witness@yahoo.com> wrote:
>>> Not everyone upgrades their video card every 6 months.
>>> Most probably get a video card upgrade only when they buy a new computer;
>>> and most don't buy a new computer every other year either, probably more like 4 years or so.
>>
>> You can get a GeForce 9600 for around USD$50, which comes near the
>> performance of the famously-expensive 8800 series (or at least near
>> enough for costing hundreds of dollars less), and has an H.264 decoder
>> so you can use vdpau with mplayer or mythtv to allow even very slow
>> computers to play high-res video smoothly.
>
> Many mainboards from that time only have AGP not PCI-E and to get a 9600
> with AGP is not easy or even possible, so that is not really a option.

I have an old Pentium 4 box which has a PCI-E video card. If a
computer is so old it doesn't even have PCI-E, its owner probably
wouldn't expect 3D desktop effects to work so well in the first place.

My old PII 266MHz had an AGP 3dfx card. I wonder if KDE4 desktop
effects would run well on that? :)


> And even if it is possible why trash a card that most of the time works
> and needs only a fraction of the power of a modern card?

If your primary concern is power usage, you're probably not going to
use the desktop effects anyway. To improve performance, which is what
I thought we were talking about, you could get a better-performing
card.

I could ride a horse to work but I choose to drive a car instead
because it is faster. :)

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[BRM]

----- Original Message ----
From: Paul Hartman <paul.hartman+gentoo@gmail.com>
To: gentoo-amd64@lists.gentoo.org
Sent: Thursday, August 27, 2009 12:27:31 PM
Subject: Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,
> On Thu, Aug 27, 2009 at 11:03 AM, Sebastian
> Beßler<sebastian@darkmetatron.de> wrote:
> > Paul Hartman schrieb:
> >> On Thu, Aug 27, 2009 at 8:16 AM, BRM<bm_witness@yahoo.com> wrote:
> >>> Not everyone upgrades their video card every 6 months.
> >>> Most probably get a video card upgrade only when they buy a new computer;
> >>> and most don't buy a new computer every other year either, probably more like 4 years or so.
> >>
> >> You can get a GeForce 9600 for around USD$50, which comes near the
> >> performance of the famously-expensive 8800 series (or at least near
> >> enough for costing hundreds of dollars less), and has an H.264 decoder
> >> so you can use vdpau with mplayer or mythtv to allow even very slow
> >> computers to play high-res video smoothly.
> > Many mainboards from that time only have AGP not PCI-E and to get a 9600
> > with AGP is not easy or even possible, so that is not really a option.
> I have an old Pentium 4 box which has a PCI-E video card. If a
> computer is so old it doesn't even have PCI-E, its owner probably
> wouldn't expect 3D desktop effects to work so well in the first place.
> My old PII 266MHz had an AGP 3dfx card. I wonder if KDE4 desktop
> effects would run well on that? :)

Remember, however, pretty much 100% of laptops cannot have their video card replaced.
My laptop has a built-in ATI card. Great little card, and I do hope that it will be able to do some effects - though, as you said, I won't expect the world of it.

That said, about the only thing that really prevents a lot of this is drivers. I'll update everything else, but I have to be able to use the hardware. That is one reason _why_ I use Linux to start with.

Most cards - even the ATI R250 in my laptop - can probably handle a lot of effects without much problem; but it's the access to the drivers that is the problem.

I can't run the ATI binary drivers b/c ATI no longer supports the chipset; yet I _cannot_ upgrade the card - it's impossible - without throwing out an otherwise perfectly good laptop.
Fortunately the F/OSS drivers are good enough, and I hope they continue to stay around.

> > And even if it is possible why trash a card that most of the time works
> > and needs only a fraction of the power of a modern card?
> If your primary concern is power usage, you're probably not going to
> use the desktop effects anyway. To improve performance, which is what
> I thought we were talking about, you could get a better-performing
> card.

Graphically, I notice not difference between the ATI R250 in my laptop and the nVidia 9600 in my AMD64 Desktop.
Granted, the 9600 could probably beat the pants off the R250 by the raw numbers; but the general uses of the system make no difference between them.
Then again, perhaps KDE4 will show something - but I doubt it.

Of course, I wouldn't expect the nVidia RIVA128 in my PII 233 do be able to much if any effects at all.

Ben

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

BRM posted on Thu, 27 Aug 2009 10:03:02 -0700 as excerpted:

> Graphically, I notice not difference between the ATI R250 in my laptop
> and the nVidia 9600 in my AMD64 Desktop.

One thing to keep in mind is the relative resolutions.  One of the 
reasons the netbooks do as good as they do with their relatively low 
performance chips is that the resolution they're dealing with is so much 
lower as well.  Doing 3D on 1024x600 (many gen-2 or later netbooks) or 
even 800x480 (IIRC, the original EEE) takes **WAY** less muscle than 
doing the same thing across a big 1920x1200 or 2560x1600 monitor, let 
alone dual-monitors @ that.  Even adding a 1280x1024 or similar external 
monitor, while it might be a strain for the little netbook chips, doesn't 
really compare to the typical resolutions a dual monitor setup on a 
desktop would typically be dealing with.

It's the same principle that allows a machine to handle STD def TV with 
ease, that would struggle with a full 1080p HD render, and at the other 
end, allows tiny cell phones and iPod Video, etc, with their low power 
chips. to handle video on their equally tiny 300x240 or whatever 
resolution screens.

-- 
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

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Frank Peters]

Henry Ford, the great American industrial pioneer, once remarked:
"The best way to solve the problems of the city is to leave the city."

After reading this thread on the problems of the new KDE, I can only
say that the best solution would be to abandon KDE entirely and choose
something much simpler.

What does KDE, or Gnome for that matter, offer that a simple window
manager cannot?  I would claim that the benefits are all illusory.
The user is deceived by the scintillating visual effects into believing
that he possesses a tool extraordinaire.

But this is pure bunk.  Using Openbox with a virtual desktop and
the old-fashioned Midnight Commander file manager that runs in an
X terminal, I could probably beat the pants off anyone, in terms of
raw productivity, that is hooked on KDE or Gnome.

Do we all understand the ancient idea of iconoclasm?

Iconoclasm is the disdain of imagery, because images are entirely
superficial in nature and ultimately will deceive, beguile, and prevent
one from ascertaining the truth.  It is no exaggeration to say that KDE
and Gnome (as MS Windows) are based on luxuriant visual methodologies
that can only obscure the true essence of computing.

Of course, I realize that very few will accept this argument.  More
and more will embrace KDE or Gnome or their ilk as time progresses.
The developers of X Window and even Gentoo will begin to disallow
simpler configurations.  Linux will then become a swampland of fantastic
imagery but increasingly difficult computation.

That's my view of things.

Frank Peters

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Volker Armin Hemmann]

On Donnerstag 27 August 2009, Frank Peters wrote:
> Henry Ford, the great American industrial pioneer, once remarked:
> "The best way to solve the problems of the city is to leave the city."

Henry Ford also praised national socialism.


>
> But this is pure bunk.  Using Openbox with a virtual desktop and
> the old-fashioned Midnight Commander file manager that runs in an
> X terminal, I could probably beat the pants off anyone, in terms of
> raw productivity, that is hooked on KDE or Gnome.

and I disagree wholeheartly here.

KDE offers what openbox never can do: integration. 
Also: network transparency.

>
> Do we all understand the ancient idea of iconoclasm?

yes, and the iconoclasts were people who destroyed art and knowledge for 
nothing. Which is a reason why they are still seen as one of the most stupid 
elements of human history.

>
> Iconoclasm is the disdain of imagery, because images are entirely
> superficial in nature and ultimately will deceive, beguile, and prevent
> one from ascertaining the truth.  It is no exaggeration to say that KDE
> and Gnome (as MS Windows) are based on luxuriant visual methodologies
> that can only obscure the true essence of computing.

oh so wrong.

>
> Of course, I realize that very few will accept this argument.  More
> and more will embrace KDE or Gnome or their ilk as time progresses.
> The developers of X Window and even Gentoo will begin to disallow
> simpler configurations.  Linux will then become a swampland of fantastic
> imagery but increasingly difficult computation.

you are free to see it that way - and please, complain to the X devs who 
torture us with hal crap (they are mostly fedora/intel based - so you should 
complain there).

But as someone who has used *box and enlightenment and icewm and other stuff I 
long forgot: KDE was the first environment where I did not have to adjust all 
and everything to be able to do stuff. No, instead I was able to spent my time 
doing stuff.

You are satisfied with openbox and mc?

Well, I need konqueror and konsole and their working together. I need okular. 
I love gwenview. And I love the fact that I do not have to learn a whole new 
set of key-combos and config syntax for every single app I use.

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Jesús Guerrero]

On Thu, August 27, 2009 21:14, Volker Armin Hemmann wrote:
> On Donnerstag 27 August 2009, Frank Peters wrote:
> Also: network transparency.

mc can do whatever konqueror can, including ftp, ssh, samba, and some
more things that konqueror can't, isos, archives, etc. Oh, and it
actually work, unlike the io-slaves, which works sometimes (or so they
used to, to be frank, I haven't tested intensively these features in
kde4, only superficially).


> You are satisfied with openbox and mc?
>
>
> Well, I need konqueror and konsole and their working together. I need
> okular. I love gwenview. And I love the fact that I do not have to learn a
> whole new set of key-combos and config syntax for every single app I use.

It's not a war, they all can coexist. I use fvwm and love mc and bash,
however I also think that okular is probably the best pdf viewer that
there has been in linux, ever.

But this is really completely out of the purpose of the thread.

-- 
Jesús Guerrero

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Volker Armin Hemmann]

On Freitag 28 August 2009, Jesús Guerrero wrote:
> On Thu, August 27, 2009 21:14, Volker Armin Hemmann wrote:
> > On Donnerstag 27 August 2009, Frank Peters wrote:
> > Also: network transparency.
>
> mc can do whatever konqueror can, including ftp, ssh, samba, and some
> more things that konqueror can't, isos, archives, etc. Oh, and it
> actually work, unlike the io-slaves, which works sometimes (or so they
> used to, to be frank, I haven't tested intensively these features in
> kde4, only superficially).

oh really? can mc present an audiocd as ogg/mp3/flac/wav files?

I don't think so. 
Konqueror can do archives just fine.
or encrypt/decrypt files nicely.


> > Well, I need konqueror and konsole and their working together. I need
> > okular. I love gwenview. And I love the fact that I do not have to learn
> > a whole new set of key-combos and config syntax for every single app I
> > use.
>
> It's not a war, they all can coexist. I use fvwm and love mc and bash,
> however I also think that okular is probably the best pdf viewer that
> there has been in linux, ever.
>
> But this is really completely out of the purpose of the thread.

well, I am just saying that even if Frank things highly integrated, code and 
functionanilty sharing DEs might be superfluos I am thinking the exact 
opposite.

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Sebastian Beßler]

Volker Armin Hemmann schrieb:

> well, I am just saying that even if Frank things highly integrated, code and 
> functionanilty sharing DEs might be superfluos I am thinking the exact 
> opposite.

Well, thats the good thing we all use Linux and everyone can use what
ever he/she/it likes to use. Because most of the time linux and even
more Gentoo is all about choise.

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Jesús Guerrero]

On Fri, August 28, 2009 00:34, Volker Armin Hemmann wrote:
> On Freitag 28 August 2009, Jesús Guerrero wrote:
>
>> On Thu, August 27, 2009 21:14, Volker Armin Hemmann wrote:
>>
>>> On Donnerstag 27 August 2009, Frank Peters wrote:
>>> Also: network transparency.
>>>
>>
>> mc can do whatever konqueror can, including ftp, ssh, samba, and some
>> more things that konqueror can't, isos, archives, etc. Oh, and it
>> actually work, unlike the io-slaves, which works sometimes (or so they
>> used to, to be frank, I haven't tested intensively these features in
>> kde4, only superficially).
>
> oh really? can mc present an audiocd as ogg/mp3/flac/wav files?
>
> I don't think so.
> Konqueror can do archives just fine.
> or encrypt/decrypt files nicely.

Well, that's true :)

But I was talking about file management, and not media ripping.
In that regards, mc do everything that konqueror can do, and more,
and consistently.

Konqueror is a container for kparts, so it's virtually impossible
to compare it with any other program unless you specify which kpart
is the one that you refer to, I am referring to the file
management part, not the rest of kio-slaves like man:/, info:/
the khtml part and so on. You can embed konsole and kate on it as
well if you want, but that's not what we are speaking about.

konqueror can do anything that kde can, virtually.

Just as a side note, for those fond on generic tools that are DE
agnostic, cdfs can do that.

I can agree that sometimes it's better to use a graphical file manager,
like konqueror or dolphin. For example when you need to manage image
colletions. They are great for lots of purposes.

>>> Well, I need konqueror and konsole and their working together. I need
>>>  okular. I love gwenview. And I love the fact that I do not have to
>>> learn a whole new set of key-combos and config syntax for every single
>>> app I use.
>>
>> It's not a war, they all can coexist. I use fvwm and love mc and bash,
>> however I also think that okular is probably the best pdf viewer that
>> there has been in linux, ever.
>>
>> But this is really completely out of the purpose of the thread.
>>
>
> well, I am just saying that even if Frank things highly integrated, code
> and functionanilty sharing DEs might be superfluos I am thinking the exact
>  opposite.

Integration is good, and sharing code is good, but all the wm's and
desktop do that their own way. KDE reuses code thought kdelibs, but
kdelibs replicate lots of things that the linux core system can do
in a different way. Things like media handling/fs stuff, network, etc
are done  usually by the kernel/OS core, but KDE reinvented it instead of
reusing it. So, as you see, it all depends on how you look at it. If
you look it that way, kde is the one who's doing wrong.

Not that I think that, I am just trying to tell you that that same
argument can be used against kde as well. I actually think that the
kde architecture is very smart, and I like it.

Not everyone needs a bulky desktop, it just depends on your needs. I am
sure that lots of people will work proficiently in fluxbox, some others
will use xmonad, some fvwm as I do, and I am sure that a lot of persons
will work proficiently in kde or gnome. It depends on the task at hand
and your workflow.

The whole discussion is pointless by now, just choose whatever you want
and leave the rest do the same, this isn't aimed at you, Volker, I am
just summing up the thing. :)

-- 
Jesús Guerrero

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Frank Peters]

On Fri, 28 Aug 2009 00:34:24 +0200
> 
> oh really? can mc present an audiocd as ogg/mp3/flac/wav files?
> 
> I don't think so. 

I am not sure what is meant by "present an audio cd," but mc can be
programmed by the user to accomplish a lot of tasks based on the
file type.  Therefore, although I have not researched this specific
possibility, I would be inclined to believe that it can be done
with mc.

Most importantly, mc could do it without requiring the support of
hundreds of extra libraries.  The more complex a structure, the more
difficult it becomes to eliminate or even locate problems and flaws.

One can also argue that the whole idea of an evolving graphical
interface is a fallacy.  Human beings do not need any new and improved
methods for interacting with a computer.  In my opinion, the GUI had
reached its peak way back in 1995.  Nothing else needs to be done.
Current GUI designs should be sufficient for the next thousand years.

> well, I am just saying that even if Frank things highly integrated, code and 
> functionanilty sharing DEs might be superfluos I am thinking the exact 
> opposite.
> 

It's all a matter of personal preference and philosophy.  I am a minimalist
at heart and I'm sure a lot of other people are as well.  For me, using
a computer means interacting closely with the hardware without the intervention
of a thick layer of GUI.  I derive much satisfaction with being able to write
bash scripts or perl/python code to do jobs that other users could probably 
accomplish with a few mouse clicks within KDE or Gnome.  To me, the whole
point of computing is to be in total awareness and control of the computer.
Fortunately, Linux (and Gentoo) still provides that minimalist opportunity.

Frank Peters

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Jesús Guerrero]

On Fri, August 28, 2009 02:01, Frank Peters wrote:
> On Fri, 28 Aug 2009 00:34:24 +0200
>
>>
>> oh really? can mc present an audiocd as ogg/mp3/flac/wav files?
>>
>> I don't think so.
>>
>
> I am not sure what is meant by "present an audio cd," but mc can be
> programmed by the user to accomplish a lot of tasks based on the file type.
> Therefore, although I have not researched this specific
> possibility, I would be inclined to believe that it can be done with mc.

He is talking about a kio-slave that does kind of like the cdfs kernel
module, though in a more limited way.

In kde, when you enter a cdaudio in your drive and open it, this
kio-slave presents you the cdaudio disk in an fs-like fashion, with
a number of folders. One folder containing ogg files, other mp3 files,
other wav files, and so on, depending on your USE flags and such things

This allows you to rip the thing by just dragging files into another
folder, though to tell the truth, it never worked reliably for me in
kde3, I have no idea if it has improved.

mc already do this for a number of formats, like iso, via vfs's, I have
no idea how complex would it be to develop this for cdaudio, but, as said
we have cdfs anyway, and mc is not meant to be an audio encoder at all.
I'd vote against this, unless it can be implemented purely as an vfs
module or as an external addon without touching a single line of the mc
core.


-- 
Jesús Guerrero

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Volker Armin Hemmann]

On Freitag 28 August 2009, Jesús Guerrero wrote:
> On Fri, August 28, 2009 02:01, Frank Peters wrote:
> > On Fri, 28 Aug 2009 00:34:24 +0200
> >
> >> oh really? can mc present an audiocd as ogg/mp3/flac/wav files?
> >>
> >> I don't think so.
> >
> > I am not sure what is meant by "present an audio cd," but mc can be
> > programmed by the user to accomplish a lot of tasks based on the file
> > type. Therefore, although I have not researched this specific
> > possibility, I would be inclined to believe that it can be done with mc.
>
> He is talking about a kio-slave that does kind of like the cdfs kernel
> module, though in a more limited way.
>
> In kde, when you enter a cdaudio in your drive and open it, this
> kio-slave presents you the cdaudio disk in an fs-like fashion, with
> a number of folders. One folder containing ogg files, other mp3 files,
> other wav files, and so on, depending on your USE flags and such things
>
> This allows you to rip the thing by just dragging files into another
> folder, though to tell the truth, it never worked reliably for me in
> kde3, I have no idea if it has improved.
>
> mc already do this for a number of formats, like iso, via vfs's, I have
> no idea how complex would it be to develop this for cdaudio, but, as said
> we have cdfs anyway, and mc is not meant to be an audio encoder at all.
> I'd vote against this, unless it can be implemented purely as an vfs
> module or as an external addon without touching a single line of the mc
> core.

and cdfs also does the id3 tags?

btw, it worked reliable in kde3 for me and it still works reliable in kde4

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Jesús Guerrero]

On Fri, August 28, 2009 03:18, Volker Armin Hemmann wrote:
> On Freitag 28 August 2009, Jesús Guerrero wrote:
>
>> On Fri, August 28, 2009 02:01, Frank Peters wrote:
>>
>>> On Fri, 28 Aug 2009 00:34:24 +0200
>>>
>>>
>>>> oh really? can mc present an audiocd as ogg/mp3/flac/wav files?
>>>>
>>>> I don't think so.
>>>>
>>>
>>> I am not sure what is meant by "present an audio cd," but mc can be
>>> programmed by the user to accomplish a lot of tasks based on the file
>>> type. Therefore, although I have not researched this specific
>>> possibility, I would be inclined to believe that it can be done with
>>> mc.
>>
>> He is talking about a kio-slave that does kind of like the cdfs kernel
>> module, though in a more limited way.
>>
>> In kde, when you enter a cdaudio in your drive and open it, this
>> kio-slave presents you the cdaudio disk in an fs-like fashion, with a
>> number of folders. One folder containing ogg files, other mp3 files,
>> other wav files, and so on, depending on your USE flags and such things
>>
>>
>> This allows you to rip the thing by just dragging files into another
>> folder, though to tell the truth, it never worked reliably for me in
>> kde3, I have no idea if it has improved.
>>
>> mc already do this for a number of formats, like iso, via vfs's, I have
>>  no idea how complex would it be to develop this for cdaudio, but, as
>> said we have cdfs anyway, and mc is not meant to be an audio encoder at
>> all. I'd vote against this, unless it can be implemented purely as an
>> vfs module or as an external addon without touching a single line of the
>> mc core.
>
> and cdfs also does the id3 tags?

You really don't understand the nature of command line tools. Usually,
no tool will do everything. They concentrate on a task, and do it well.
I don't think cdfs does that, it does't need to. It's an fs driver...

You can copy the file to wherever you want, and encode it and tag it
however you want. Including that into cdfs would be a nonsense, it would
replicate the functionality that's already there.


-- 
Jesús Guerrero

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Volker Armin Hemmann]

On Freitag 28 August 2009, Jesús Guerrero wrote:
> On Fri, August 28, 2009 03:18, Volker Armin Hemmann wrote:
> > On Freitag 28 August 2009, Jesús Guerrero wrote:
> >> On Fri, August 28, 2009 02:01, Frank Peters wrote:
> >>> On Fri, 28 Aug 2009 00:34:24 +0200
> >>>
> >>>> oh really? can mc present an audiocd as ogg/mp3/flac/wav files?
> >>>>
> >>>> I don't think so.
> >>>
> >>> I am not sure what is meant by "present an audio cd," but mc can be
> >>> programmed by the user to accomplish a lot of tasks based on the file
> >>> type. Therefore, although I have not researched this specific
> >>> possibility, I would be inclined to believe that it can be done with
> >>> mc.
> >>
> >> He is talking about a kio-slave that does kind of like the cdfs kernel
> >> module, though in a more limited way.
> >>
> >> In kde, when you enter a cdaudio in your drive and open it, this
> >> kio-slave presents you the cdaudio disk in an fs-like fashion, with a
> >> number of folders. One folder containing ogg files, other mp3 files,
> >> other wav files, and so on, depending on your USE flags and such things
> >>
> >>
> >> This allows you to rip the thing by just dragging files into another
> >> folder, though to tell the truth, it never worked reliably for me in
> >> kde3, I have no idea if it has improved.
> >>
> >> mc already do this for a number of formats, like iso, via vfs's, I have
> >>  no idea how complex would it be to develop this for cdaudio, but, as
> >> said we have cdfs anyway, and mc is not meant to be an audio encoder at
> >> all. I'd vote against this, unless it can be implemented purely as an
> >> vfs module or as an external addon without touching a single line of the
> >> mc core.
> >
> > and cdfs also does the id3 tags?
>
> You really don't understand the nature of command line tools. Usually,
> no tool will do everything. They concentrate on a task, and do it well.
> I don't think cdfs does that, it does't need to. It's an fs driver...
>
> You can copy the file to wherever you want, and encode it and tag it
> however you want. Including that into cdfs would be a nonsense, it would
> replicate the functionality that's already there.

so why are you even bringing cdfs up?

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Jesús Guerrero]

On Fri, August 28, 2009 03:39, Volker Armin Hemmann wrote:
> On Freitag 28 August 2009, Jesús Guerrero wrote:
>
>> On Fri, August 28, 2009 03:18, Volker Armin Hemmann wrote:
>>
>>> On Freitag 28 August 2009, Jesús Guerrero wrote:
>>>
>>>> On Fri, August 28, 2009 02:01, Frank Peters wrote:
>>>>
>>>>> On Fri, 28 Aug 2009 00:34:24 +0200
>>>>>
>>>>>
>>>>>> oh really? can mc present an audiocd as ogg/mp3/flac/wav files?
>>>>>>
>>>>>>
>>>>>> I don't think so.
>>>>>>
>>>>>
>>>>> I am not sure what is meant by "present an audio cd," but mc can
>>>>> be programmed by the user to accomplish a lot of tasks based on
>>>>> the file type. Therefore, although I have not researched this
>>>>> specific possibility, I would be inclined to believe that it can
>>>>> be done with mc.
>>>>
>>>> He is talking about a kio-slave that does kind of like the cdfs
>>>> kernel module, though in a more limited way.
>>>>
>>>> In kde, when you enter a cdaudio in your drive and open it, this
>>>> kio-slave presents you the cdaudio disk in an fs-like fashion, with
>>>> a number of folders. One folder containing ogg files, other mp3
>>>> files, other wav files, and so on, depending on your USE flags and
>>>> such things
>>>>
>>>>
>>>> This allows you to rip the thing by just dragging files into
>>>> another folder, though to tell the truth, it never worked reliably
>>>> for me in kde3, I have no idea if it has improved.
>>>>
>>>> mc already do this for a number of formats, like iso, via vfs's, I
>>>> have no idea how complex would it be to develop this for cdaudio,
>>>> but, as said we have cdfs anyway, and mc is not meant to be an audio
>>>> encoder at all. I'd vote against this, unless it can be implemented
>>>> purely as an vfs module or as an external addon without touching a
>>>> single line of the mc core.
>>>
>>> and cdfs also does the id3 tags?
>>
>> You really don't understand the nature of command line tools. Usually,
>> no tool will do everything. They concentrate on a task, and do it well. I
>> don't think cdfs does that, it does't need to. It's an fs driver...
>>
>> You can copy the file to wherever you want, and encode it and tag it
>> however you want. Including that into cdfs would be a nonsense, it would
>>  replicate the functionality that's already there.
>
> so why are you even bringing cdfs up?

Nevermind.
-- 
Jesús Guerrero

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Frank Peters]

On Fri, 28 Aug 2009 02:42:00 +0200
Jesús Guerrero <i92guboj@terra.es> wrote:

> 
> In kde, when you enter a cdaudio in your drive and open it, this
> kio-slave presents you the cdaudio disk in an fs-like fashion, with
> a number of folders. One folder containing ogg files, other mp3 files,
> other wav files, and so on, depending on your USE flags and such things
> 
> This allows you to rip the thing by just dragging files into another
> folder, though to tell the truth, it never worked reliably for me in
> kde3, I have no idea if it has improved.
> 

That's nice.  But with a bash script using less that a dozen lines
of code one could accomplish the same thing and much, much more.
The ripped wav files could easily be normalized, equalized, dithered,
low-pass or high-pass or band-pass filtered, mixed, companded, etc., etc.,
before being finally compressed into flac, mac, ape, shorten, ogg, mp3,
etc., etc., etc., and then even burned onto another CD/DVD or medium
of choice.

Let's see KDE with its 10,000 (I jest) support libraries top that.

Frank Peters

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Volker Armin Hemmann]

On Freitag 28 August 2009, Frank Peters wrote:
> On Fri, 28 Aug 2009 02:42:00 +0200
>
> Jesús Guerrero <i92guboj@terra.es> wrote:
> > In kde, when you enter a cdaudio in your drive and open it, this
> > kio-slave presents you the cdaudio disk in an fs-like fashion, with
> > a number of folders. One folder containing ogg files, other mp3 files,
> > other wav files, and so on, depending on your USE flags and such things
> >
> > This allows you to rip the thing by just dragging files into another
> > folder, though to tell the truth, it never worked reliably for me in
> > kde3, I have no idea if it has improved.
>
> That's nice.  But with a bash script using less that a dozen lines
> of code one could accomplish the same thing and much, much more.
> The ripped wav files could easily be normalized, equalized, dithered,
> low-pass or high-pass or band-pass filtered, mixed, companded, etc., etc.,
> before being finally compressed into flac, mac, ape, shorten, ogg, mp3,
> etc., etc., etc., and then even burned onto another CD/DVD or medium
> of choice.
>
> Let's see KDE with its 10,000 (I jest) support libraries top that.

it already does.

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Paul Hartman]

On Thu, Aug 27, 2009 at 2:03 PM, Frank Peters<frank.peters@comcast.net> wrote:
> What does KDE, or Gnome for that matter, offer that a simple window
> manager cannot?  I would claim that the benefits are all illusory.
> The user is deceived by the scintillating visual effects into believing
> that he possesses a tool extraordinaire.

Of course, if you're looking at KDE or Gnome as a simple window
manager they don't offer much over the others but their own look and
feel. And many people (me included) use it in that way. But there is
much more to KDE, it is an application development framework, a suite
of hundreds of applications, many integrated with each other (both
from a user's and developer's standpoint). And all the
semantic-desktop stuff that I still don't understand, but is
apparently supposed to be A Big Deal(tm).

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

Frank Peters posted on Thu, 27 Aug 2009 15:03:51 -0400 as excerpted:

> After reading this thread on the problems of the new KDE, I can only say
> that the best solution would be to abandon KDE entirely and choose
> something much simpler.

That's what many are doing.  Under a bit different circumstances, I'd be 
one of them, but it does still seem to be the best for me, even if it's 
taking way more work than it should for the transition.  Even then, there 
are bits that I'm switching to non-kde alternatives for, like the hotkey 
thing.

> But this is pure bunk.  Using Openbox with a virtual desktop and the
> old-fashioned Midnight Commander file manager that runs in an X
> terminal,

Another mc fan. =:^)  I use it for my sysadmin type work, and have highly 
customized the user menu to that end.  For ordinary user file management, 
however, managing images and videos and that sort of thing, working with 
preview-based icons is nice, and I still use kde tools for that.  But 
certainly gnome tools would work too, and possibly file roller, etc.  
I've never tried them since I'm already using kde and might as well use 
the kde solution since it's already there and working well... for the 
tasks I use it for.

-- 
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

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Barry Schwartz]

Duncan <1i5t5.duncan@cox.net> skribis:
> Frank Peters posted on Thu, 27 Aug 2009 15:03:51 -0400 as excerpted:
> 
> > After reading this thread on the problems of the new KDE, I can only say
> > that the best solution would be to abandon KDE entirely and choose
> > something much simpler.
> 
> That's what many are doing.  Under a bit different circumstances, I'd be 
> one of them, but it does still seem to be the best for me, even if it's 
> taking way more work than it should for the transition.  Even then, there 
> are bits that I'm switching to non-kde alternatives for, like the hotkey 
> thing.

Well, I've perhaps changed my mind, after trying 4.3. I'm still using
fluxbox -- easily the best wm for me that I've tried -- but plasma
seems to be working well enough now that I can use it, although I
still would have preferred the combination of rox pinboard and
kicker.

Konsole for 4 seems to need a bit more work, so I'm continuing with
rox-term for now. (It's very similar to gnome-terminal.) I don't
really use file managers at all except for things like browsing images
and fonts; the terminal emulator is my most important tool. My main
reason for running KDE is it's an easy way to get the full
functionality of apps written for it. I'm too old-fashioned and messy
to care about some sort of "full user experience". :)

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

Barry Schwartz posted on Thu, 27 Aug 2009 19:54:58 -0500 as excerpted:

> Konsole for 4 seems to need a bit more work,

What issues are you seeing?  That's /one/ major kde thing I use that I 
had /no/ problems with the 4.x version on, at least since 4.2.4.  I don't 
believe I ran it enough before that to really know, since kde4 as a whole 
simply wasn't working well enough to do more than play with it, and 
konsole is primarily a work tool. =:^)

-- 
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

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Barry Schwartz]

Duncan <1i5t5.duncan@cox.net> skribis:
> Barry Schwartz posted on Thu, 27 Aug 2009 19:54:58 -0500 as excerpted:
> 
> > Konsole for 4 seems to need a bit more work,
> 
> What issues are you seeing?

No background image support, apparently (I couldn't find it, and
Googling made me think it wasn't there yet). I use a simulation of
handmade paper; it shows off fonts well.

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

Barry Schwartz posted on Fri, 28 Aug 2009 03:56:33 -0500 as excerpted:

> Duncan <1i5t5.duncan@cox.net> skribis:
>> Barry Schwartz posted on Thu, 27 Aug 2009 19:54:58 -0500 as excerpted:
>> 
>> > Konsole for 4 seems to need a bit more work,
>> 
>> What issues are you seeing?
> 
> No background image support, apparently (I couldn't find it, and
> Googling made me think it wasn't there yet). I use a simulation of
> handmade paper; it shows off fonts well.

Hmm, yes, I believe you're right.

As I prefer light foreground on dark background (like a normal text-mode 
VC), "Linux Colors" is the color-scheme I always use, and it works well 
for me, particularly since I the color-codes for ls and portage, etc, 
probably show up better on a dark background since that's what they're 
designed for.

But if you prefer a light background, but not /too/ light (thus a light 
but not white paper texture/color), there's several schemes that do that, 
but it doesn't appear that there's actual image background yet, you're 
right.

I was just asking because I couldn't really imagine konsole not 
working... but it seems it's color-scheme you're having problems with, 
not broken functionality.  And I can identify, because I sure have 
problems with light backgrounds, so I can't blame you for being picky 
about wanting your particular color/image-background setup at all.  I'd 
certainly find it unacceptable if all it had were light backgrounds!

-- 
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

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

Paul Hartman posted on Thu, 27 Aug 2009 11:27:31 -0500 as excerpted:

> I have an old Pentium 4 box which has a PCI-E video card. If a computer
> is so old it doesn't even have PCI-E, its owner probably wouldn't expect
> 3D desktop effects to work so well in the first place.

I'd contest that.  Of course, if the video is that age too, yes.  
However, reasonably decent video is still available on AGP.  I'm planning 
on updating to a Radeon x1950, top of the r5xx chip line, and not too 
shabby ATM, tho it'll be old by the time I'm done with it.

The biggest problem is that such chips were generally already designed 
for PCI-E, and require a bridge chip to AGP, which adds significantly to 
the price while not exactly decreasing latency or increasing 
performance...  The Radeon x1950 I'm looking at still runs $150, for 
instance, tho the performance is probably comparable to that of a more 
modern $50-$100 PCI-E card.

That x1950 won't run the latest fancy games at the highest framerate, 
sure, but I'm not generally into such things anyway, and it should be 
more than adequate for OpenGL desktop effects, even across the two 
1920x1200 DVI screen's I'll be plugging into it (that's the largest 
resolution DVI-D single-link is supposed to be able to serve, BTW, which 
is why there's a cutoff there), and even across the two 2560x1600 (each 
requiring dual-link DVI-D) I'd love to upgrade to at some point...

And since I'm already running dual dual-core Opteron 290s (top of their 
line 2.8 GHz), with 8 gigs of RAM on an extremely well supported by both 
manufacturer and Linux Tyan mobo, with 4-way SATA based kernel/md RAID, I 
figure the base system should be good for a few more years yet.  I just 
need to upgrade the graphics from the now aging Radeon 9200 I'm running 
now.

When I upgrade again after that, I expect it to be to by then a single-
chip oct-core or the like, maybe doubling the RAM to 16 gig, maybe a 
couple terabytes SSD storage, who /knows/ what graphics, for, by then, 
maybe $500.  But that's several years away yet, tho it's coming.

OTOH, maybe I'll go netbook for my main system by then, as by then, what 
compares to today's netbooks should be quad-core, 4-8 gig RAM, terabyte 
SSD, on its own, which would be pretty much a side-grade, only by then in 
today's netbook size and cost. =:^)  If it has a place for a nice big 
2560x1600 monitor, with of course external keyboard and mouse for heavy @ 
home use, that'd just about do it.

-- 
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

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Jesús Guerrero]

On Thu, August 27, 2009 18:27, Paul Hartman wrote:
> On Thu, Aug 27, 2009 at 11:03 AM, Sebastian
> Beßler<sebastian@darkmetatron.de> wrote:
>
>> Paul Hartman schrieb:
>>
>>> On Thu, Aug 27, 2009 at 8:16 AM, BRM<bm_witness@yahoo.com> wrote:
>>>
>>>> Not everyone upgrades their video card every 6 months.
>>>> Most probably get a video card upgrade only when they buy a new
>>>> computer; and most don't buy a new computer every other year either,
>>>> probably more like 4 years or so.
>>>
>>> You can get a GeForce 9600 for around USD$50, which comes near the
>>> performance of the famously-expensive 8800 series (or at least near
>>> enough for costing hundreds of dollars less), and has an H.264
>>> decoder so you can use vdpau with mplayer or mythtv to allow even very
>>> slow computers to play high-res video smoothly.
>>
>> Many mainboards from that time only have AGP not PCI-E and to get a
>> 9600
>> with AGP is not easy or even possible, so that is not really a option.
>
> I have an old Pentium 4 box which has a PCI-E video card. If a
> computer is so old it doesn't even have PCI-E, its owner probably wouldn't
> expect 3D desktop effects to work so well in the first place.

Just for the record, things like compiz work preferctly in an nvidia
6200, agp. They will work without a problem in an hd2600 which is a much
better card, agp as well. The cpu is a sempron 3000+, which works at a
clock rate of 1800 I think. You haven't researched much. AGP is not equal
to Geforce 2 mx or 3dfx, you know...

Being that said, I have zero interest in desktop effect. I don't even have
compositing enabled, It's useless stuff for me. So I really don't care
about this stuff. Just pointing out the error.

-- 
Jesús Guerrero

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

Jesús Guerrero posted on Fri, 28 Aug 2009 00:08:07 +0200 as excerpted:

> Just for the record, things like compiz work preferctly in an nvidia
> 6200, agp. They will work without a problem in an hd2600 which is a much
> better card, agp as well.

Hmm, I wasn't aware the Radeons (I assume you're talking about here, I 
don't even bother with nVidia any more and have no idea their model 
numbers) had AGP available beyond the r5xx (thru x1950) series.  Got a 
link?  But I hadn't finished researching and actually bought, either.



-- 
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

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Jesús Guerrero]

On Fri, August 28, 2009 01:52, Duncan wrote:
> Jesús Guerrero posted on Fri, 28 Aug 2009 00:08:07 +0200 as excerpted:
>
>
>> Just for the record, things like compiz work preferctly in an nvidia
>> 6200, agp. They will work without a problem in an hd2600 which is a much
>>  better card, agp as well.
>
> Hmm, I wasn't aware the Radeons (I assume you're talking about here, I
> don't even bother with nVidia any more and have no idea their model
> numbers) had AGP available beyond the r5xx (thru x1950) series.  Got a
> link?  But I hadn't finished researching and actually bought, either.

http://www.tigerdirect.com/applications/category/category_slc.asp?CatId=318&name=AGP%20Video%20Cards

The first thing I found in google, you can see there an nvidia geforce
7600, it's agp. The 7xxx is the last series of nvidia with agp support,
though in some parts it's quite difficult to find one.

You can also see an ati radeon 2400 there, I own one however I can't
say I am really happy with it. But that's another story and I don't want
to spoil the thread more than it already is.

My only point is there there are *lots* of agp cards that are more than
capable of doing desktop effects of any kind. The beryl/compiz stuff
was born much before pci-e was in our houses. :)

-- 
Jesús Guerrero

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

Jesús Guerrero posted on Fri, 28 Aug 2009 02:18:56 +0200 as excerpted:

> On Fri, August 28, 2009 01:52, Duncan wrote:
>> Jesús Guerrero posted on Fri, 28 Aug 2009 00:08:07 +0200 as excerpted:
>>
>>
>>> Just for the record, things like compiz work preferctly in an nvidia
>>> 6200, agp. They will work without a problem in an hd2600 which is a
>>> much
>>>  better card, agp as well.
>>
>> Hmm, I wasn't aware the Radeons (I assume you're talking about here, I
>> don't even bother with nVidia any more and have no idea their model
>> numbers) had AGP available beyond the r5xx (thru x1950) series.  Got a
>> link?  But I hadn't finished researching and actually bought, either.
> 
> http://www.tigerdirect.com/applications/category/category_slc.asp?
CatId=318&name=AGP%20Video%20Cards
> 
> The first thing I found in google, you can see there an nvidia geforce
> 7600, it's agp. The 7xxx is the last series of nvidia with agp support,
> though in some parts it's quite difficult to find one.

Well, the nVidia might be nice, but I asked specifically for Radeon (tho 
other well freedomware driver supported or headed that way card would 
work) as well as AGP, because Radeon is AFAIK the best freedomware 
supported hardware available.

But... (vv)

> You can also see an ati radeon 2400 there, I own one however I can't say
> I am really happy with it. But that's another story and I don't want to
> spoil the thread more than it already is.

hd2400, right?  I'll have to take a look, now that I know it's 
available.  That's r6xx I believe, and while freedomware support is still 
a bit rough, come about the end of the year or early next, it should be 
coming right into its own.

Plus at least the PCI-E versions I saw were substantially cheaper than 
the $150 x1950 I was looking at.  But while an r6xx chip, the x1950 is 
top of the r5xx line while the hd2400 is near the bottom of the r6xx 
line, so the x1950 may well be better performing.

> My only point is there there are *lots* of agp cards that are more than
> capable of doing desktop effects of any kind. The beryl/compiz stuff was
> born much before pci-e was in our houses. :)

Yes, but Intel is on-board-only, AFAIK, so out as far as an expansion 
card, nVidia freedomware drivers just aren't there yet and may never be 
without nVidia's cooperation at least on documentation (and they'd still 
be out for me, as they are NOT cooperating, and there's a reasonable 
alternative that is), Via has started to cooperate and got a big boost in 
freedomware points for hiring Herald Welte as their FLOSS community 
liason but is a good year behind AMD/ATI, Matrox seems to be out of the 
game now or at least it's been a very long time since I read about any 
new product... and the only one left is AMD/ATI with their Radeons.

Now, on the Radeons, thru the r5xx chips (thus thru x1950 cards) are well 
supported now, and the r6xx and r7xx are getting there but will be 
another few months.  But I (obviously mistakenly) thought the r5xx was as 
high as AGP went, so I thought the x1950 was the top of the line in terms 
of what I could upgrade to.

It may still be that the x1950 is my top option, but I know there's r6xx 
AGP cards now, something I didn't know before, and so at least have 
another option, and it may be I now have equal performance at better than 
that $150 the x1950 seems to run, or better performance at about the same 
price.  I have the extra option to research, now.

-- 
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

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Jesús Guerrero]

> Well, the nVidia might be nice, but I asked specifically for Radeon (tho
> other well freedomware driver supported or headed that way card would work)
> as well as AGP, because Radeon is AFAIK the best freedomware supported
> hardware available.
>
> But... (vv)

I think that yes, along with intel. Couldn't tell you what's better
supported. Expect trouble with r6xx based cards *right now*, though.
3d doesn't work, at least not officially. Work is being done, but not
quite ready for production.

If you need 3d acceleration with the open driver, then use an older
card, r5xx based.

>> You can also see an ati radeon 2400 there, I own one however I can't
>> say I am really happy with it. But that's another story and I don't want
>> to spoil the thread more than it already is.
>
> hd2400, right?  I'll have to take a look, now that I know it's available.
> That's r6xx I believe, and while freedomware support is still
> a bit rough, come about the end of the year or early next, it should be
> coming right into its own.

I own a 2400 and I can tell you it's a pain to
get radeon working with it. Not even 2d works ok (no dri, which means
not even 2d acceleration, very slow, and NO XVIDEO, which is a major
flaw). For some others it seems to work ok. It doesn't seem to work
too well with multihead, maybe my problems come because of that, I
don't really know.

As you say, the radeon/radeonhd driveris coming, slowly, but eventually
it will catch up, however, *right now*, if you plan to use OSS drivers
only, you are better with older hardware. They might work on some months,
but it could very well take more time, it just depends on how the thing
develops.


-- 
Jesús Guerrero

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Jesús Guerrero]

On Thu, August 27, 2009 17:49, Paul Hartman wrote:
> On Thu, Aug 27, 2009 at 8:16 AM, BRM<bm_witness@yahoo.com> wrote:
>
>> Not everyone upgrades their video card every 6 months.
>> Most probably get a video card upgrade only when they buy a new
>> computer; and most don't buy a new computer every other year either,
>> probably more like 4 years or so.
>
> You can get a GeForce 9600 for around USD$50, which comes near the
> performance of the famously-expensive 8800 series (or at least near enough
> for costing hundreds of dollars less), and has an H.264 decoder so you can
> use vdpau with mplayer or mythtv to allow even very slow computers to play
> high-res video smoothly. Many people spend that much to fill up their
> automobile or go out to to the movies or a dinner with the family. I don't
> think it's an incomprehensible amount of money to spend on something that
> will greatly improve performance on your computer for quite a long time,
> but I also understand that everyone has their own budget to live by,
> things are more expensive in some countries, and some people are not
> technically inclined or physically able to do things like changing a video
> card.

You also forgot that not everyone has a pci-e slot, which is the only way
to use these new cards. The rest of the mortals are limited to 7xxx series
at most, and only if they have the extreme luck of finding an agp based
card, which is an odyssey nowadays. Well, there's ati as well, up to 2600,
at least supports agp, if you are brave enough.
-- 
Jesús Guerrero

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Volker Armin Hemmann]

On Freitag 28 August 2009, Jesús Guerrero wrote:
> On Thu, August 27, 2009 17:49, Paul Hartman wrote:
> > On Thu, Aug 27, 2009 at 8:16 AM, BRM<bm_witness@yahoo.com> wrote:
> >> Not everyone upgrades their video card every 6 months.
> >> Most probably get a video card upgrade only when they buy a new
> >> computer; and most don't buy a new computer every other year either,
> >> probably more like 4 years or so.
> >
> > You can get a GeForce 9600 for around USD$50, which comes near the
> > performance of the famously-expensive 8800 series (or at least near
> > enough for costing hundreds of dollars less), and has an H.264 decoder so
> > you can use vdpau with mplayer or mythtv to allow even very slow
> > computers to play high-res video smoothly. Many people spend that much to
> > fill up their automobile or go out to to the movies or a dinner with the
> > family. I don't think it's an incomprehensible amount of money to spend
> > on something that will greatly improve performance on your computer for
> > quite a long time, but I also understand that everyone has their own
> > budget to live by, things are more expensive in some countries, and some
> > people are not technically inclined or physically able to do things like
> > changing a video card.
>
> You also forgot that not everyone has a pci-e slot, which is the only way
> to use these new cards. The rest of the mortals are limited to 7xxx series
> at most, and only if they have the extreme luck of finding an agp based
> card, which is an odyssey nowadays. Well, there's ati as well, up to 2600,
> at least supports agp, if you are brave enough.

agp goes up to hd4670 - but the cards are pretty expensive. There are also 
4650s, 3850, 3650, 3450. From nvidia you can still get 6200 or 5500 as agp 
versions. If you look around you might even find the occasional matrox card.

But they are all expensive compared to their pcie counterparts.

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Jesús Guerrero]

On Fri, August 28, 2009 00:37, Volker Armin Hemmann wrote:
> On Freitag 28 August 2009, Jesús Guerrero wrote:
>
>> On Thu, August 27, 2009 17:49, Paul Hartman wrote:
>>
>>> On Thu, Aug 27, 2009 at 8:16 AM, BRM<bm_witness@yahoo.com> wrote:
>>>
>>>> Not everyone upgrades their video card every 6 months.
>>>> Most probably get a video card upgrade only when they buy a new
>>>> computer; and most don't buy a new computer every other year either,
>>>>  probably more like 4 years or so.
>>>
>>> You can get a GeForce 9600 for around USD$50, which comes near the
>>> performance of the famously-expensive 8800 series (or at least near
>>> enough for costing hundreds of dollars less), and has an H.264
>>> decoder so you can use vdpau with mplayer or mythtv to allow even very
>>> slow computers to play high-res video smoothly. Many people spend that
>>> much to fill up their automobile or go out to to the movies or a
>>> dinner with the family. I don't think it's an incomprehensible amount
>>> of money to spend on something that will greatly improve performance
>>> on your computer for quite a long time, but I also understand that
>>> everyone has their own budget to live by, things are more expensive in
>>> some countries, and some people are not technically inclined or
>>> physically able to do things like changing a video card.
>>
>> You also forgot that not everyone has a pci-e slot, which is the only
>> way to use these new cards. The rest of the mortals are limited to 7xxx
>> series at most, and only if they have the extreme luck of finding an agp
>> based card, which is an odyssey nowadays. Well, there's ati as well, up
>> to 2600, at least supports agp, if you are brave enough.
>
> agp goes up to hd4670 - but the cards are pretty expensive. There are
> also 4650s, 3850, 3650, 3450. From nvidia you can still get 6200 or 5500
> as agp versions. If you look around you might even find the occasional
> matrox card.

I know nothing about matrox, however, even the hd2600 is a much better
card than the g gforce 6200, let alone previous nvidia models and later
ati ones.

> But they are all expensive compared to their pcie counterparts.

Sure, but to buy a new motherboard, with a new cpu and a new ram stick
plus the pcie card is more expensive. If you want the faster you can get
from agp, then you are gonna pay for it. If not, then you can find cheap
cards for like 30-50€ or so in the range of the 6200. All of which
will perfectly run this desktop effects thing. No doubt they'll lag a
bit with the heavier effects.

-- 
Jesús Guerrero

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

Volker Armin Hemmann posted on Tue, 25 Aug 2009 01:33:23 +0200 as
excerpted:

> On Montag 24 August 2009, Sebastian Beßler wrote:

>> 3) Screen-setup: I have to monitores connected to my pc static in xorg
>> as two seperated displays :0.0 and :0.1. If I start kde <4.4-svn I have
>> both screens on my main monitor and the second is just as good as dead.
>> There is a patch for this in svn (or is it git now?) and as much as I
>> can say by testing a few live-builds this point will be gone by next
>> release.
> 
> ok, sounds like a genuine stupid bug. Can't even fixed with krandrtray?

This one is a known kde4 issue, and earlier, they weren't planning to fix 
kde4 to do multiple X sessions like kde3 did.  From what I've read it was 
purely an accident that kde3 handled multiple sessions that way.

It's possible that may change, given the requests they've gotten, but I 
don't expect the devs to prioritize it, which practically speaking, means 
they'll take patches...

Meanwhile, kde4.3.0 still has issues with xinerama (what SB calls "big 
screen") mode in some cases (including mine), too.  It detects two 
monitors, but only sees one CRTC, apparently, and thus forces them into 
clone mode.  The systemsettings display applet preview shows just one 
screen, with the label for the second monitor overwriting that of the 
first, so the result is an almost unreadable combination of the two 
labels.  And the settings for each monitor are all there except for the 
position control that would allow you to set on-top-off, to-the-right-of, 
etc.  (I didn't even know what it was supposed to look like until someone 
else with the problem posted a screenshot to one of the kde lists I'm 
following, and another poster followed up with a screenshot of how it /
should/ look.)

But I've seen several mentions that the problem has been fixed in trunk, 
for 4.4, and the fix may or may not make it into 4.3.x.

Meanwhile, since kde3's display applet never worked right either for me, 
I've developed my own scripts to manage resolution changes here, calling 
xrander to do it.  As long as I don't open the kde display settings 
applet or run krandrtray and screw with it, I'm fine, but if I even so 
much as open the display settings applet, kde screws things up royally, 
and just running the xrander script doesn't fix that.  I have to screw 
around with plasma to get it back the way it's supposed to be, as well.

So for now, I just don't go there any more, and I'm fine.  But I'm 
looking forward to 4.4.0 or 4.3.x when that fix gets into the release, 
hoping I can actually manage displays using kde then, for the first time 
ever! =:^)

>> 4) Design: I have a very small design with two small bars at the bottom
>> and on the right side. I can't create a design in kde4.x so far that
>> consumes as few space on my monitor as i have it in kde 3.
> 
> but you know that you can make the plasma bar very small - and add a
> couple of them to the desktop?

4.3 might actually be able to do this now.  Each 4.X release has VASTLY 
improved plasma, so far, and in this area 4.2 was finally becoming semi-
usable and 4.3 is actually very reasonable, now.

If small is what you want, 4.3 really does allow small now.  I have one 
panel set as small as it'll allow, looks like 12 px high (horizonal 
panel).  IIRC the minimum in kicker was 24 px?

But I still find the panel settings widget clumsy and inefficient, 
compared to how kicker worked.

And while the panel settings widget at least works, the entirely 
automated panel plasmoid sizing is still simply broken in some regards.  
There really needs to be a way to force a plasmoid to only take up so 
much space in the direction of the orientation of the panel (width on a 
horizontally oriented panel, height on a vertically oriented one).  By 
that I mean, have /plasma/ force it, regardless of what ideas the 
plasmoid has about its size.  Some of the plasmoids simply hog space, and 
can't be forced smaller, without changing the size of the panel itself 
(height on a horizontally oriented panel, width on a vertical oriented 
panel).

If plasma could force it, the plasmoids would have to adapt.  If they 
didn't, they'd probably simply die out from disuse, as people found 
solutions that actually worked.

I was hoping the spacers introduced with 4.3.0 would correct the problem, 
and they would have if they could be arbitrarily placed, thereby limiting 
the area the plasmoids on either side had to work with, but the hogging 
plasmoid simply shoves over the spacer.

One way plasma could implement this while staying compatible with older 
plasmoids, would be to lie to them about the panel size, if it had to, 
thereby forcing them to adapt to what they believed was a smaller sized 
panel.

Another problem still existing in 4.3.0, is that if the install new 
widgets functionality is used (so the new widget appears in the list 
available to add), there's no GUI method to remove what has been 
installed (so it no longer appears in that list).  One must actually find 
the location in kde's configuration tree on-disk, and remove the offender 
there.  If it can be installed via GUI, it should be uninstallable via 
GUI as well.

And one of my big irritations is that there's no ksysguard plasmoid to 
replace the ksysguard kicker applet.  It's bugged.  IDR whether I filed 
the bug or just CCed an existing bug, adding my own request, but either 
way, there have been several folks add comments asking for it as well, 
since I did whichever.

Of course, ksysguard4 still has some serious bugs of its own, including 
the fact that it doesn't properly restore user set minimum and maximum 
settings on the fancy-plotters, if the user has turned off auto-ranging.  
That too is bugged.

Meanwhile, I've been working on setting up a superkaramba scheme that 
does what I want, but that's still on my list, I've not been able to do 
it yet.  (The other last big issue I had was khotkeys multi-key, but I 
solved that with my own script, as I described in a previous post.)  
Superkaramba is much more flexible than ksysguard in layout, etc, so it 
should be great when I get it setup, but it's a matter of actually having 
the time to do it.

Until then, I have to reset a half-dozen plotters to their proper ranges 
every time I restart kde or just ksysguard.  That sort of repetitive work 
is /exactly/ the sort of thing computers are supposed to be able to 
handle for us humans, so it's rather ironic that ksysguard is making me 
do it, instead of allowing me to tell it how I want it set and have it do 
it.
 
>> The fifth point on my list is that many of the functions and (3rd
>> party) kde programms I use day by day aren't there yet at all or only
>> with lack of functions and mostly in late alpha-state: k3b, amarok,
>> kdevelop, kvirc to just name a few.
> 
> I haven't found anything missing in k3b or amarok - and I don't use
> kdevelop or kvirc. What are you missing from k3b?

k3b I use in general, but haven't tried the kde4 version yet. (I have it 
merged, and ran it briefly to see how it looked, tho, and nothing lept 
out at me as lacking.)

But I finally got so fed up with amarok I found a different solution.  
They killed all the functionality I actually used, while adding a bunch 
of junk I'm not interested in.

Have they gotten the winamp/xmms skinnable mini-player back yet?  Last 
time I checked, they weren't interested in the idea.  What about 
visualizations?  That actually may be back in the kde4 version now, I 
don't know, but I had a lot more use for that then all the fancy main UI 
changes they did.  And I never /did/ use all that fancy scoring and etc. 
functionality.

It's fine if they don't do it.  It's just that our paths have obviously 
separated (not that they were ever really the same, but it was convenient 
to travel with them for a time).  Like the last ISP I left, they're free 
to develop the product as they wish, but I'm simply no longer interested 
in going where they were headed.  Thus, they can go their way and I'll go 
mine.  

Still, the thing that really had me fed up was somewhat different.  
That's the way they handled the transition to the MySQL backend.  Not 
only is that entirely unnecessary for the features I'm interested in (tho 
I'd have tolerated it if they had kept the features I actually used), but 
they demonstrated a COMPETE disregard for their amd64 users when they 
added it, as it was ENTIRELY broken on this arch at the time.  The 
library they were using wasn't designed for dynamic use, only static, and 
thus simply wouldn't function as a dynamic library on amd64 (at least not 
without affecting the performance of all the rest of the package, 
including the mysql app itself), as dynamic libs here require -FPIC, and 
at the time the only way to get that was to compile the entire package 
with it.

That was the last straw for me.  Not only were they dropping all the 
useful stuff (from my perspective) from their kde4 version, but 
demonstrating a total disregard for their amd64 users as they did, that 
was more than I was willing to take, and I decided there were simply 
better options available.

>> The last reason I stick with kde 3.5.10 for a while is that working
>> with kde 4.x just doesn't feel right. Switching to kde4 is like
>> switching to a completly different DE. KDE 4 isn't kde anymore, it is
>> something absolutly different that calls itself kde.
> 
> people said the same when going from 1.1 to 2.0 and 2.2 to 3.0....

Indeed.  I expected some adjustment time, and that's why I was running 
the live version before 4.0 came out, with the idea that by the time it 
was ready, I'd be ready too.

But I had no idea it would be 4.2 before it even got to the beta state 
this early-adopter likes to jump in at, 4.3 before it got to rc, and 
apparently 4.4 before it gets to actual normal X.0 release quality!

And /as/ such an early adopter, I had no idea I'd be feeling the clock 
ticking on the end of support and removal from my distribution on the 
actually generally usable version, before I could even do the usual beta 
testing I normally do with such important products.

> The only two things that I really disliked about kde 4.X is the new
> 'systemsettings' - I liked kcontrol. Very much. And akonadi creeping
> into everything.

akonadi is frustrating, for sure.  As is nepomuk, soprano, etc, at least 
here.

And I agree on kcontrol vs. system-settings, as well.  FWIW, you can 
change the system-setting menu entry (using kmenuedit), renaming it 
kcontrol, if you want, and you can use the qt --caption or the kde --
title option if you wish.  But the title changes back to System Settings 
as soon as you activate any of the applets.

Of course I'm using the tree view option they added back to it in 4.3, 
that was the way kcontrol3.

But as with kde3, I put the kcontrol/systemsettings menu widget on a 
panel (complete with its own keyboard shortcut, even), and seldom invoke 
the full kcontrol/systemsettings any more.  There's really no reason to, 
once you figure out what applet a particular setting is in, and you have 
your system setup in general the way you want it, so you're only doing a 
single change or two in a particular place, here or there.  But as with 
kde3, I still access the settings enough that the menu's worth having.

-- 
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

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Sebastian Beßler]

Duncan schrieb:

> Meanwhile, kde4.3.0 still has issues with xinerama (what SB calls
> "big screen") mode in some cases (including mine), too.

If I would mean xinerama I would say so. Maybe I am pedantic but
xinerama is only a deprecated extension of the X-server, that I never
had installed because I didn't need it here because I never even want to
stretch my desktop to more then one physical monitor or want to move
programms from one display to another by drag and drop. I see that it
can be usefull but that what I want is usefull and needed too.

> But I've seen several mentions that the problem has been fixed in
> trunk, for 4.4, and the fix may or may not make it into 4.3.x.

I tested this patch and for my setup without xinerama or xrandr it works
like I have it under kde3. One screen with kde on the monitor, one
screen only with the black X root window on the TV.
With that I wait for kde 4.4 (or 4.3.1 if it gets backported) to give
kde a fifth chance.

> 4.3 might actually be able to do this now.  Each 4.X release has
> VASTLY improved plasma, so far, and in this area 4.2 was finally
> becoming semi- usable and 4.3 is actually very reasonable, now. If
> small is what you want, 4.3 really does allow small now.  I have one 
> panel set as small as it'll allow, looks like 12 px high (horizonal 
> panel).  

As 4.3 is still unuseable for me because of the "two different sized
screens on one"-bug I mentioned before I can't test that right now and
have to wait for kde 4.4. But the live-builds I tried to test the patch
had the same problems with scaling icons on small bars.

> IIRC the minimum in kicker was 24 px?

Yes it is and 24px would be absolutly fine for me but here it didn't
work, as a lot of the icons don't scale if reduced to smaller than 40px.
They get cut and I have only have half icons.

> But I finally got so fed up with amarok I found a different solution.
>  They killed all the functionality I actually used, while adding a
> bunch of junk I'm not interested in.

That is exact my point. Hurray a lot of new fancy dingelings but lack of
needed and used functions like generic usb audioplayer support.

> Have they gotten the winamp/xmms skinnable mini-player back yet?

Not the last time I looked into it (a few days after 4.3 was out).

> And I never /did/ use all that fancy scoring and etc. functionality.

They put so much new stuff in there, why not a import function for the
old amarok 1.4 database? I mean one that works and not only imports 10
or so records.

> Thus, they can go their way and I'll go mine.

I would do that too, but there is no player that fits my needs as much
as it amarok 1.4 does and so I think that I use it even if I switch when
kde 4.4 is out. I have 8GB RAM so the bloat that comes with it can be
absorbed.

> I decided there were simply better options available.

Could you name a few?

What I miss in kde 4.x so far is the run command kicker applet that I
had in kde3 as my main way of starting apps. In kde4 I have to use the
shortcut to get krunner (is it the name?) and type it there. And I don't
like krunner. I don't want any suggestions, I know what I am about to
start, thank you.

Oh and I miss the weather applet, and the kworldclock background image
and… and… and…

Can't they just add a feature so that kde4 looks and feels and behaves
as kde3 did? Yes I know that it is a dream, but sometimes dreams really
come true.

Greetings

Sebastian

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Paul Hartman]

On Thu, Aug 27, 2009 at 1:20 PM, Sebastian
Beßler<sebastian@darkmetatron.de> wrote:
> Duncan schrieb:
>> But I finally got so fed up with amarok I found a different solution.
>>  They killed all the functionality I actually used, while adding a
>> bunch of junk I'm not interested in.
>
> That is exact my point. Hurray a lot of new fancy dingelings but lack of
> needed and used functions like generic usb audioplayer support.

Good news, generic USB support is coming back in latest Amarok 2 svn:

http://awainzin-foss.blogspot.com/2009/08/amarok-2-universal-mass-storage-device.html

> They put so much new stuff in there, why not a import function for the
> old amarok 1.4 database? I mean one that works and not only imports 10
> or so records.

They've allegedly fixed it in the current releases but I haven't tried
it. I never used any Amarok-metadata so when I went to 2.x I just
started fresh and had it scan my files again. There was supposedly a
workaround for the upgrade bug, if you let Amarok 2 build your
collection like new and THEN import, it would work properly. But
importing into a blank collection would only do a few records and
stop.

The biggest thing that annoyed me in Amarok 2 was the handling of
"Various Artists", which has been fixed, so I'm okay now. Latest SVN
versions let you edit metadata in the playlist view also, which many
people missed from 1.x series.

Handling of online streams is much better and more diverse in Amarok
2, so there is at least one thing it does better than 1.x. :)

> What I miss in kde 4.x so far is the run command kicker applet that I
> had in kde3 as my main way of starting apps. In kde4 I have to use the
> shortcut to get krunner (is it the name?) and type it there. And I don't
> like krunner. I don't want any suggestions, I know what I am about to
> start, thank you.

Maybe something like this:

http://www.kde-look.org/content/show.php?content=91495

> Oh and I miss the weather applet, and the kworldclock background image
> and… and… and…

I miss the old weather applet, too. The weather forecast and LCD
weather station don't show the same kind of info when docked into the
panel.

> Can't they just add a feature so that kde4 looks and feels and behaves
> as kde3 did? Yes I know that it is a dream, but sometimes dreams really
> come true.

A KDE3-style theme would used by a lot of people, for sure.  I still
use the Windows 95 "classic" look on WinXP computers :)

Re: [gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Sebastian Beßler]

Paul Hartman schrieb:

> Good news, generic USB support is coming back in latest Amarok 2 svn:

Yes I know and it is better then nothing but you always have to remember
to create the ".is_audio_player"-file and the syntax of the file if you
want a music-folder. But it is progress that I can see.

> They've allegedly fixed it in the current releases but I haven't tried
> it. I never used any Amarok-metadata so when I went to 2.x I just
> started fresh and had it scan my files again.

I tried to start from scratch and let it rescan my 14253 music files but
only a few hundred showed after scanning. So it was completely broken
for me. Maybe when kde 4.4 is out it is usable. Then I will try again.

> Maybe something like this:
> http://www.kde-look.org/content/show.php?content=91495

Yes, that looks very good. I really should use kde-look.org more often.

> A KDE3-style theme would used by a lot of people, for sure.  I still
> use the Windows 95 "classic" look on WinXP computers :)

A theme would help but there is more then only optical changes that I
like to adjust with that.

Greetings

Sebastian

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

Paul Hartman posted on Thu, 27 Aug 2009 14:04:22 -0500 as excerpted:

>> Oh and I miss the weather applet, and the kworldclock background image
>> and… and… and…
> 
> I miss the old weather applet, too. The weather forecast and LCD weather
> station don't show the same kind of info when docked into the panel.

The default weather stuff in kde4 stinks, IMO.  However, kde-look has 
quite a number of weather plasmoids available, some of which look great 
and provide a whole lot more info than kde3's setup did.

The one I'm using is "yaWP" (yet another Weather Plasmoid, IIRC).  Try 
looking it up.

FWIW, it's a bit much for me, but I've seen one guy mention that he now 
has a whole weather /activity/, with a whole bunch of different plasmoids 
all setup.  (With 4.3 you can assign activities to a specific desktop, or 
there's also the activity switcher plasmoid that can go in a panel or on 
each activity, thus avoiding the whole zoom-out, zoom-in thing, once it's 
setup at least.)

That too added to my switch-from-kde3 time, but I'd not have mentioned it 
had it not come up here, because for me, it's just the routine stuff one 
has to adjust going from one major version to another.  But yes, the good 
news is that there's all sorts of weather solutions now, some of which 
work very well, you just have to shop around kde-look for them.

-- 
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

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

szalkai posted on Mon, 24 Aug 2009 22:41:19 +0200 as excerpted:

> Now that this exciting little flamewar has finished, and everybody is
> friends again :), could you Duncan please give some examples of major
> breakage in KDE4?

Altho some of it's covered down-thread by others, I did promise it if any 
one asked, and you did, so below you'll see a bit of a list, some 
mentioned in the followups I've read so far, some not.

> I have been using it since 4.1.something and it is
> getting better and better.

Absolutely!  I've been trying it on and off since before 4.0 actually 
came out, and you're 100% correct, it *IS* getting better and better.  
But 4.0 was NOT release quality and at least KDE has allowed /that/ much, 
tho we still differ on where release quality actually looks to be 
achieved, and they had a LONG way to go.

Again, as noted previously, part of the problem is actually how 
exceedingly good kde 3.5. was, a point that's even more amazing when you 
consider the age of the technology involved.  Kde4 was pretty much a 
ground-up rewrite, and no matter HOW you slice and dice that, it WILL 
take awhile, especially when the previous version was as good as 3.5 was/
is.  I just wish they'd continue to properly support 3.5 until 4.5 or so, 
when I believe it'll finally be comparable, plus of course the new 
features 4.x has.  And that they'd have handled the whole transition 
better, but that can't be helped now, tho they /could/ still actually 
support 3.5 another year if they wanted to.

>  Also, it took me nowhere near 80 hours to
> switch from 3.5.10 to 4.

Well, as you'll see below, I depended on much in kde3 that simply hasn't 
made the transfer, yet, at least not in fully functional form.  That has 
been a HUGE problem, or rather, multiple problems, thus the 80 hours.

> I admit that I have a konsole with seven tabs open all the time, and do
> most of my work from there (and use firefox for browsing and thunderbird
> for emails), so I am not a KDE poweruser by far (while definitely a
> linux poweruser at least),

I'd say that anyone actually using Gentoo (not just surviving it, 
following rote directions) is a Linux power user by definition, at least 
by definition of comparison to the average user on most of the binary 
distributions.

That's not a putdown of the binary distributions, BTW.  There's 
absolutely a place for the Ubuntus of the world, and their users, and we 
were all newbies at one point.  But some of us at least don't stay 
newbies...

And Gentoo is suitable for newbies too, if they're willing to actually 
pay attention, read docs, and learn!

I know for a fact (from the postings on the docs list from the guy who 
developed and taught it) that Gentoo is used in at least one decently in-
depth high school and college level intro to computers and computer 
technology class.  He starts by explaining the basics of memory, etc, in 
a karate-kid/guru style format (the kid visits an old computer guru who 
starts teaching him what he knows).  By the middle of the second week
(in a semester class), they've covered the basics, and are getting into 
Gentoo.  The rest of the semester, they do the install, I think from 
stage-1, gradually bootstrapping the system over the weeks, with the 
function of each new package in the system level explained along with 
configuration, etc.  By the time they are done, they have a fully 
functional Gentoo system, AND know enough about the software components 
and how they fit together and work, to do a decent job of teaching it to 
those newbie Ubuntu users, given the chance! =:^)

Now I **WISH** that's how I was taught computers!  But there's at least 
/some/ folks getting that sort of quality instruction. =:^)

> but even 4.2 already seemed stable enough for
> me. Actually, the thing that made me switch in excitement was the
> promise of the semantic desktop stuff, not the eyecandy, but it has
> disappointed me so far.

Actually, the semantic desktop and etc weren't a big sell for me at all.  
Rather the opposite, in fact, as I do reasonably well with the 
organization I've developed over the years, and the semantic desktop, 
while nice in theory, is sort of like the locate command and database 
update that always seemed to be running at the most inconvenient times 
(and I don't have a set enough schedule to really schedule it at a better 
time, because what's better this week might be terrible next week, and 
merely tolerable the week after that), so I quickly decided I didn't need 
it and shut it off.  I don't think I ever merged it on Gentoo.  I've not 
missed it.

And I've kept as deactivated as possible all of the semantic desktop 
stuff too.  And if I /do/ forget where that file is, grep and find are my 
friends.  =:^)  Of course, they don't necessarily work so well for say 
image files... but then, neither does the semantic desktop, unless you've 
tagged them effectively, and that's what choosing a proper name and 
directory layout is all about, only without all the trouble.

At least it works that way for those who seem to groke computer style 
directory layouts and the like.  I do understand that not everybody 
does,and that the semantic desktop should really help the types of folks 
that download something, and then can't remember where they told they 
system to save it when they want to open it.  But that's just a problem 
I've never had, and the semantic desktop stuff seems, at least at this 
stage, to be more trouble than the hassle involved is worth.  Maybe after 
a few years of further development.  Not now.

> BTW Duncan, I do enjoy and appreciate your posts here.

Thanks, both to you and others.  I've said before and I'll say it again, 
that the reason I'm here is to help and at times be helped.  When that's 
no longer happening, I've no further interest in being here, and I'll 
find someplace else where I'm better able to contribute something 
worthwhile.  So I'm glad people are still finding my posts useful.


OK, to that list...

Hotkeys:  KDE bug 161009.  In kde3 I used hotkeys extremely extensively, 
probably launching 95% or more of my apps that way, etc.

Now, I have one of those Internet aka Multimedia style keyboards (a 
Logitech Cordless Desktop Pro, to be exact, it's also an ergonomic "wave" 
design -- I can type /hours/ on it, day in and day out, with no problems, 
but only a few minutes on a "straight" keyboard without PAIN), with a 
bunch of extra keys.  However, it's FAR from enough extra keys to 
dedicate a key per function I want to hotkey.  Thus, the way I had it 
arranged on kde3, while I had one hotkey to launch the (seldom used) 
kmenu, and another to use the (actually frequently used, but for 
different things) run dialog, now called krunner, most of those keys were 
setup as two-key menus with multiple functions.  I'd hit the key, say 
XF86HomePage, and kde3's hotkeys would popup a menu that listed all the 
second-level keys I'd setup, "w" for web browser, "m" for mail, "e" for 
text editor, etc.  Of course, the menu really didn't matter that much, as 
it was usually HomePage,W to launch the web browser, for example, in 
quick enough succession the menu may not have even fully displayed.  And 
I'm a touch-typist and know the hotkeys by position and touch, so I never 
had to look at the keyboard OR shift to the mouse OR use the several more 
key sequence that would have been necessary to launch it from the kmenu, 
even if I remembered that longer sequence to do so.

That's quite a productivity booster once someone's used to it, quickly 
becoming more of a necessity than a luxury.  I had similar menus for 
window functions, display resolution changes (since the old Ctrl-Alt-Num+/
Num- zooming sequences died and were buried as xorg switched to RandR 
technology, better for monitor hotplugging, but RIP Num+/- zooming!), 
etc, plus the dedicated single-function media keys for changing volume 
and play/stop/next/prev.  One of the nice things about it was that 
because those are non-ordinary "extra" keys, none of the sequences 
involving them interfered with any application built-in sequences using 
the more standard Ctrl/Alt/Shft/Meta keys, so those were still entirely 
free to be used by the applications themselves without any conflict or 
interference.

That functionality, multi-key global hotkeys it's called in the bug, is 
flat broken on kde4.  What's worse, the bug implies the problem is 
actually in a support library somewhere, perhaps a different part of kde 
(not khotkeys), more likely somewhere in a third party library.  Given 
kde's dependence on qt, I'd /guess/ it's a problem there.  Regardless, 
the functionality is broken, and looks likely to remain broken for the 
near future, at least, until someone either hacks a workaround into kde, 
or convinces whatever library upstream to provide the functionality.  
What I /don't/ understand is why kde3 could have it, then, unless they 
simply coded up their own solution there, and took the half-solution 
provided by the library instead, once it became available.

Anyway, given the circumstances, it's understandable that there's no kde4 
solution, but that doesn't help the folks that depended on that feature 
in kde3 to find a useful substitute for kde4.

Solution?  There are other hotkey programs available for Linux, tho many 
of them don't handle multi-key either.  One that actually DOES handle 
multikey is xbindkeys.  However, in it's "simple" mode it doesn't handle 
multi-key, and its "advanced" mode involves guile and scheme (lisp-like 
language) macros.  Basically, the first key triggered the macro, which 
then set up a countdown to timeout, waiting for the second key.  
Depending on which order keys were pressed and released, different 
actions were configured to be triggered by the macro.  So... I started 
studying guile and scheme, having never used a lisp-like language before, 
so I could groke what was going on and program it effectively to do what 
I wanted.  Of course, that's WAY more powerful than khotkeys, but it all 
takes time to learn, especially when you've not an EMACS devote and don't 
otherwise have any previous LISP experience...  You seeing where those 80 
hours might be going now?!

So, several hours after starting on that... actually, as with a lot of 
this, I got tired and slept the few hours shorter sleep I was getting 
much of the time during the several weeks I spent working on all this, as 
I was putting all the time possible into get kde4 working... then came 
back to it the next day...

Anyway, several hours into trying to groke guile and scheme, just as I 
was actually beginning to get the hang of things, I had an epiphany...

I realized that what was /actually/ happening was as I mentioned but 
glossed over above... that what xbindkeys was actually doing was a
single-key trigger of a /second/ program, the guile macro, which detected 
the second key (or timed out if none came), and triggered the programmed 
action accordingly!

Well, I don't know scheme or guile, tho it /was/ beginning to make sense 
by that point, but I *DO* know bash scripting well enough to write my own 
sysadmin scripts, hack on ebuilds, hack on the boot cycle initscript 
system, etc.  The epiphany was that **I** could do the SAME thing in what 
I already knew, bash, using kde4's more limited single-key hotkeys to 
launch my bash scripts, to do what the guile macros would have done for 
xbindkeys!

So then another sleepless nite of bash hacking later, after 16 hours of 
hacking or so, I had a set of scripts to do pretty much just that.  I had 
khotkeys setup to launch the starter script with one key.  The starter 
script then launched a second script in a konsole window, displayed in 
that window a hotkey menu read in from a data file and a prompt, waited 
for a timeout or a single key, detected what they key was (a second data 
file contained a lookup table mapping returned control-key sequences to 
text representations that could be easier entered in the corresponding 
line of the first data file, which had three columns, hotkey, 
description, command; part of that time was spent those sequences and 
setting up that second mapping table), checked for a corresponding line 
in the first table, and ran the corresponding command from that table.

I then setup a special konsole profile for the window to display that 
menu, setting it to turn off the tabs, scrollbar and menubar, etc.  
Further I setup a special window settings config (kwin profile) for that 
window, setting it to an appropriate size (different from my normal 
konsole windows), always-on-top, centered placement (I tried under-mouse 
but that didn't work so well as it cause the launched window to displace, 
the centered option didn't), etc.

Finally, after testing each shortcut sequence, (menu-launcher,app-
launcher, menu-launcher key set in khotkeys, app-launcher key set in the 
script datafile along with the command and a description, as I said), I 
unset the temporary assignments I'd set for them in khotkeys, and for 
kmenu entries I'd created in ordered to apply a hotkey, I deleted them 
too, thus cleaning up my kmenu apps menu substantially. =:^)

So now I have a working dual-key launcher again, this time partially 
implemented using my own scripting, and hopefully kde won't be pulling 
any MORE functionality out from under me so it should continue to work, 
at least thru the kde4 series. =:^)

That's ONE problem and solution. =:^)

The second problem was color settings.  There's some background here, as 
the LACK of a decent per-role color-setting app way back in GNOME 1, when 
even MICROS~1 could manage /that/, was the triggering factor in my 
original decision to choose KDE (then kde2.x) as my desktop environment 
of choice, way back in early 2002 shortly after I switched from 
MICROS~1.  Kde2 of course DID have that color choices app, much like it 
does today, while GNOME forced a user to either set an entire scheme at 
once, or hand-edit text config files, to get the same results KDE did 
with their nice GUI color settings applet.  Of course, as we now know in 
hindsight, that choice was the correct one, as Gnome got even /more/ anal 
about insisting they had the "One True Way" that simply MUST be correct, 
removing even more configuration functionality with Gnome2.  To be fair, 
I've not spent a whole lot of time (read none, the closest I get is GTK 
apps) on Gnome recently, and perhaps they've reversed that trend, but 
from what I've seen and heard, it hasn't changed substantially.  KDE is 
still the choice for power users that like to tweak their system.

Of course, that's part of my problem.  As any self-respecting power user, 
I had kde3 heavily customized, and was using and depending on 
functionality like multi-key hotkeys that's not mainstream, and that in 
many cases is still broken in kde4, or was in 4.2 anyway tho 4.3 is 
markedly better.

Anyway, back to colors.  I happen to have a low tolerance for "glaring" 
white backgrounds.  Further, the default muted grays that seem to be the 
corporate-safe defaults shipped by most distributions and environments 
make me almost physically nauseous!  As a result, I have STRONG 
preferences for a generally light text on dark background scheme that is 
none-the-less much more colorful than color-scheme default tend to be.

The /problem/ is that because dark on light is the default, it's also the 
all too frequently assumption made.  As anybody with such preferences can 
tell you, light text on a light background, because the author simply 
assumed a dark text default when he set the background, or the reverse, 
dark text on a dark background, because the author simply assumed a light 
background when she set the foreground, instead of consistently setting 
BOTH foreground and background whenever ONE is set, is an **ALL** too 
frequent problem on the web!  (FWIW, I use privoxy as a personal web 
proxy for that reason among others, with a filter scheme I've been 
tweaking for years, setup to darken light backgrounds and lighten dark 
foregrounds, without reducing to mono-color as enforcing such preferences 
at the browser CSS level seem to do.)

Well, the same set of problems occurs on the desktop.  It can take /
years/ of tweaking to get a reasonably colorful light foreground on a 
dark background scheme setup, one that deals well with all the curves 
various developers' wrong color scheme assumptions throw at you from time 
to time.

What's worse is that unlike those with an apparently more normal dark on 
light preference, light on dark schemes are around, but rather less 
frequent than dark on light schemes.  That makes it much harder to find a 
reasonably close to personal preferences match to form a base for further 
tweaking as needed.

I was thus naturally rather frustrated when I realized that kde4 had /no/ 
provision for even /trying/ to import kde3 color schemes, including the 
one I'd been tweaking for years to get "just right".  I was looking at 
not only quite some time to find a decent kde4 color scheme base to work 
from, but also the prospect of spending /years/ tweaking it a little here 
and a little there, until it again met my needs as well as the one I'd 
already spent /years/ tweaking for kde3.

As it happened, the kde dev that maintains the color control applet 
happened by the kde-general list after I'd posted this as one of the 
issues I was struggling with.  He and I now have a reasonably good 
working relationship, with mutual respect, I believe, and I and another 
user regular on the list have worked with him throwing ideas back and 
forth, etc.

The complicating factor for kde4 is that its color scheme is **FAR** 
richer than kde3's was, with six different role variants of several more 
base color roles than kde3 had.  There's thus no direct conversion 
possible.  However, it IS possible to do an indirect conversion, doing a 
passable first-guess at some of the new roles based on similar but 
multiplexed roles in the kde3 color scheme, with a warning for any kde3 
scheme that more tweaking will likely be necessary to get the best 
results.  I'm HAPPY to say that a kde3 color scheme importer and 
converter has been committed and should be part of kde4.4.  Whether it'll 
be backported to 4.3.x I'm not sure, but that's just /one/ of multiple 
bugs and wish-list items, the polish that has been so lacking in kde4 to 
date, that I KNOW are fixed for 4.4.

That was /my/ problem solved, but in the back and forth, we succeeded in 
coming up with a better UI for the color choices that are there, as 
well.  Take a look at the 4.3 color choices applet, in particular, the 
preview.  Can you truthfully say that it's obvious what those mysterious 
"a i ! = +" symbols are all about?  What about the two separate lines 
(altho that's a bit easier, normal vs selected text)?  I know /I/ didn't 
understand what those symbols were, tho the selected vs normal text was 
obvious.

Here's a hint.  Switch to the colors tab.  On the colors tab, select 
anything /other/ than the default "common colors".  See the word 
descriptions?  Now take a look at the line of symbols from the other tabs 
and from common colors on this tab that I typed above and see if it 
clicks.

CORRECT!  a=active, i=inactive, !=negative, ==neutral, +=positive.  
There's also hover.  Those are the role variants I mentioned above.  Some 
of that is set directly, some of it selected automatically based on 
chosen colors.  The display with the words is setup so that the lowest 
contrast matches of foreground to background are shown, and if any of 
those words are invisible due to inadequate contrast, it's because the 
person who designed whatever color scheme you are running, didn't 
properly understand how kde4's color schemes work.  FINALLY!  Finally 
there's a nice built-in tool allowing devs and color-scheme authors to 
see if any of their choices aren't going to work due to invalid 
assumptions or an improper understanding of kde's color roles!  Once how 
this works is well understood, it'll hopefully mean MUCH better designed 
color schemes, without those nasty but all too common "invisible writing" 
bugs.

OK, so if you're like me, that's entirely new information, and you 
understand far better what's going on in the color dialog and previews 
now.  So what was the problem?  Well, the problem was (and still is with 
4.3.0) that the present arrangement doesn't effectively convey all that 
information.  Granted, it's a really TOUGH thing to do -- effectively.  
We threw ideas back and forth for several rounds before we came up with 
something better, but all of those in the exchange agree with the new 
solution -- this one almost certainly 4.4 not 4.3 backported, as it 
involves string changes, and 4.3 was in string freeze for translation 
purposes by the time we worked this out.

BTW, the i18n (internationalization, i, 18-letters, n) issues were 
significant complications here as well.  Apparently, the descriptions are 
rather longer in certain other languages, and the dialog either ends up 
with horizontal scroll bars or too wide for small displays.  That's with 
things as they are, and our initial solutions were making it worse!

What we eventually came up with, after realizing that some of the other 
system-settings dialogs are longer (vertically) than the colors dialog, 
was splitting the lines, thus using more space vertically but less 
horizontally.  While it might add vertical scrolling in some cases, the 
colors dialog will still be shorter than a couple of the others, and 
vertical scrolling is FAR more acceptable than horizontal scrolling in 
any case.  This solved the problem he was already trying to tackle with 
the long translations, while also addressing the cryptic symbols issue a 
bit better! =:^)

Now THAT'S how user/developer communication is SUPPOSED to work! =:^)

Meanwhile, with the better understanding that gave me of how kde4's 
colors worked, I found a color scheme on kde-look that worked very well 
for me -- very close to as good as the kde3 scheme I had taken so long to 
tweak had worked there for me! =:^)  It's not the same, but if anything, 
I think it's even nicer than I'd have had even if the kde3 scheme /had/ 
been able to transfer perfectly. =:^)

All-in-all, this one turned out by far the best of any of the problems I 
had, all because one dev was willing to come visit the user groups and 
not too offended at a user desperately crying for help due to frustration 
with his applet and its limitations! =:^)

That's only two of my issues, but this is long enough, and that should 
give people an idea, anyway.  Very quickly, however, I'll mention that a 
couple of the others were performance and multi-monitor related, much as 
others are already posting.  But I'll cover those in replies to those 
posts, as I may be able to help others with them based on my own 
experience and knowledge now, having spent all that time desperately 
working on it, getting the system back to usable enough that I could 
actually be somewhat productive once again.

And, if I'm lucky, that colors dialog information will turn out to be as 
concretely useful to at least one other user here as it was to me!  After 
all, I /did/ say I'm here to help, otherwise it's not worth the bother.  
But I expect it'll be of use to someone, because it SURE was new and 
useful info to me. =:^)


-- 
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

Re: [gentoo-amd64] Heads-up: KDEers: Particularly kde3-ers,

[Bernhard Auzinger]

Am Sonntag, 23. August 2009 19:04:45 schrieb Volker Armin Hemmann:
> On Sonntag 23 August 2009, Duncan wrote:
> > Those of you kde-ers, particularly kde3-ers (aka stable kde-ers),
> > heads-up!
> >
> > If you aren't aware of the current gentoo kde (especially kde3)
> > situation, you *NEED* to subscribe to the gentoo-desktop list (normally
> > lower activity than here, so it shouldn't be a huge burden), AND check
> > the archives for the last couple months.
>
> bullshit
>
> > The short version:  kde3 is likely going to be masked, soon, apparently
> > very possibly before any kde4 is ever marked stable.  The current plan is
> > to leave kde3 in-tree but masked, probably until early next year, at
> > which point it'll move to an overlay, kde-sunset or similarly named,
> > where it'll be maintained primarily by interested users.
>
> maybe, you you don't have to be subscribed to -desktop to find that.
> Anyway, without an official announcement it is just a plan.
>
> <cut unimportant crap >
>
> > Of course, qt3 upon which kde3 depends is in similar or even worse shape
> > (except that it was in arguably better shape when it went unsupported, as
> > until then, people had been paid to keep it working, even if they'd have
> > otherwise preferred to be working on the newer versions), apparently not
> > supported any longer by its own (commercial FLOSS) upstream.
>
> and here we come to the real stuff. qt3 is planned to be removed from the
> tree. Nothing else.
>
> > Unfortunately, all this is complicated by the state of kde4, in many ways
> > a mirror image of kde3 -- specifically like a mirror image in that it's
> > similar, but nicely reversed.  kde4 is getting all sorts of developer
> > attention, but again despite what upstream says, it's anything /but/ as
> > stable and smoothly functional and polished as kde3 is.
>
> bullshit
>
> > I'm normally an
> > early adopter, running ~arch and in fact often unmasking and even
> > reaching into overlays for fresh versions, often beta or rc, sometimes
> > even live-vcs versions direct from the upstream repositories.
>
> you are also writing way too much.
>
> >4.3 (as every kde4 version so far) is markedly
> > better than the previous version, but there's still a LOT of broken
> > functionality, features still rapidly evolving, etc.
>
> extreme bullshit
>
> > kde4.3 therefore at what I'd normally consider the late-beta stage.
> > User's who actually used and depended on the previous version for
> > anything beyond basic functionality shouldn't be upgrading yet unless
> > they're prepared to spend HOURS, in this case, DAYS, even WEEKS,
>
> even more bullshit.
>
> emerge @kde4.3
>
> some hours later: perfectly  fine working kde 4.3. No bugs, stable, all
> funtionality needed there.
>
> So instead of talking you typical annoying much worded crap, could you
> please point out the problems with 4.3? Examples?
>
> > upgrading, finding fixes and workarounds for bugs, even switching to
> > alternative software solutions at times when the functionality simply
> > isn't there. I estimate I've spent about 80 hours on the upgrade and
> > reconfiguring, all told.
>
> nice. I spent maybe 3h. All told.
>
> > switch, and users WILL need to spend SOME time reconfiguring and
> > adapting, but perhaps 20-40 hours is reasonable, NOT 80!  80 hours, two
> > weeks of full-time 40-hour-week equivalent work, simply indicates how
> > immature and broken some aspects of the project still are,
>
> and more bullshit.
>
> So, name your examples.
>
> And I didn't even bother to read the rest.
>
> duncan, if I want to read a book, I buy a book, This is an INTERNATIONAL
> list. We are not living in nightmare land where everybody's first language
> is english.
> Reading your emails takes more time than installing kde.
>
> All you had said to this point could have been said in two simple sentences
> too:
>
> kde 3.5 is planned to go away into an overlay because qt3 is not supported
> anymore
> kde 4.X has still some problems.
>
> See? See the difference to you writings? Short, compact, same message. Oh,
> and of course I left out the bullshit.
>
> But no, you do have to write a freaking essay.
>
> In the future: keep it short.

In my opinion duncan is one of the people around here which make this list 
very useful and the information he is sharing within his emails is one of the 
reasons why I didn't unsubscribe yet.

I like duncans emails :).

Rgds
Bernhard

Re: [gentoo-amd64] Heads-up: KDEers: Particularly kde3-ers,

[Sebastian Beßler]

Bernhard Auzinger schrieb:

> In my opinion duncan is one of the people around here which make this list 
> very useful and the information he is sharing within his emails is one of the 
> reasons why I didn't unsubscribe yet.

I can second that. Duncans mails are one of the highlights here.

> I like duncans emails :).

Me too.

Greets

Sebastian Beßler

Re: [gentoo-amd64] Heads-up: KDEers: Particularly kde3-ers,

[Bogo Mipps]

On Tue, 25 Aug 2009, Sebastian Beßler wrote:
> Bernhard Auzinger schrieb:
> > In my opinion duncan is one of the people around here which make this
> > list very useful and the information he is sharing within his emails is
> > one of the reasons why I didn't unsubscribe yet.
>
> I can second that. Duncans mails are one of the highlights here.
>
> > I like duncans emails :).
>
> Me too.

And me - I even have a 'Duncan' archive on this box ... 


Best
Bogo

Re: [gentoo-amd64] Heads-up: KDEers: Particularly kde3-ers,

[Peter Humphrey]

On Sunday 23 August 2009 18:04:45 Volker Armin Hemmann wrote:

> Reading your emails takes more time than installing kde.

So do what I did a few years ago: put him in your kill file.

Peace.

-- 
Rgds
Peter.

[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

Peter Humphrey posted on Sun, 30 Aug 2009 23:16:13 +0100 as excerpted:

> On Sunday 23 August 2009 18:04:45 Volker Armin Hemmann wrote:
> 
>> Reading your emails takes more time than installing kde.
> 
> So do what I did a few years ago: put him in your kill file.

Indeed.  No need to get huffy about it.  If it bothers you that much, 
simply killfile it.  Let me assure you, /I'll/ not be offended.

That's what killfiles are for, after all. I've said it before and I'll 
say it again, I'm here to try to help people, and I believe this thread 
has demonstrated that my posts are helpful for /some/ users, anyway.  If 
for you I'm a hinderance, than far better for both of us that I /am/ in 
your killfile.

-- 
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

Re: [gentoo-amd64] Heads-up: KDEers: Particularly kde3-ers,

[Benny Pedersen]

On man 31 aug 2009 00:16:13 CEST, Peter Humphrey wrote
> On Sunday 23 August 2009 18:04:45 Volker Armin Hemmann wrote:
>> Reading your emails takes more time than installing kde.
> So do what I did a few years ago: put him in your kill file.

stop pay your isp for internet connect, stops all remaining problems aswell

if all mails on maillists was ebuilds that is stable, there was no  
more windows 7

-- 
xpoint