Version: 3.4.1 (using KDE 3.4.1, compiled sources) Compiler: gcc version 3.4.2 [FreeBSD] 20040728 OS: FreeBSD (amd64) release 5.4-STABLE I have three screens configured -- :0.0, :0.1, :0.2. They all had different settings, with three clocks showing three different timezones, different applets running inside kicker's panels, etc. After upgrading from KDE-3.3.2 to 3.4.1 ALL settings for the screens :0.1 and :0.2 were lost -- reset to defaults. This is so blatant, that once this particular bug is solved, the testing procedure(s) ought to be revisited. Such things should not go through whatever QA there is :-)
after settings things up again, do the settings survive a log out and log in again? in other words, once you are using 3.4 do the settings stick? do you still have your 3.3 kicker setting files around for me to look at? and now for the lightening round! Q: how many KDE developers run dual head with SVN trunk? A: none that i know of! Q: how many kicker hackers use dual head? A: zero! Q: how many kicker bug triagers use dual head? A: zero! dual head is, IMHO, a fairly nasty hack and nobody actively tests that configuration during development. if you'd like to see dual better supported, the best thing you can do is get involved.
*** Bug 108966 has been marked as a duplicate of this bug. ***
*** Bug 108969 has been marked as a duplicate of this bug. ***
=after settings things up again, do the settings survive a log out =and log in again? in other words, once you are using 3.4 do the =settings stick? Do not know yet. They probably will persist... It certainly worked fine through KDE-3.2.x and 3.3.x. =do you still have your 3.3 kicker setting files around for me to look at? Which part of my ~/.kde would you like to see? I did not modify the kicker settings just yet -- if you ignore my fruitless attempts to rectify the kicker-size confusion (bug 108970). =dual head is, IMHO, a fairly nasty hack It is the greatest thing to happen to computer usability since, well, KDE-project inception ;-) =if you'd like to see dual better supported, the best thing you can do is get involved This is a very discouraging and quite unfortunate attitude...
> Do not know yet. They probably will persist let me know if you would ... > Which part of my ~/.kde would you like to see? I did not modify the kicker > settings just yet -- if you ignore my fruitless attempts to rectify the > kicker-size confusion (bug 108970). ~/.kde/share/config/*kicker* > It is the greatest thing to happen to computer usability since xinerama and those kinds of solutions, certainly (i love xinerama and got kicker working pretty flawlessly with it for 3.4) but dual head is not my friend. =) > This is a very discouraging and quite unfortunate attitude seeing as i don't have any multi-monitor systems around (and if i did they'd be doing xinerama) this is to be expected. open source works by people taking part in helping create solutions for the parts of the system that they have an interest in, for one reason or another. apparently virtually nobody who's willing to get their hands dirty runs dual head. i've actually asked around before. =/ so until someone who uses dual head gets struck with the spirit to take part ..... ... i suppose you can see that as a discouraging thing. or you could see it as an opportunity.
Created attachment 11778 [details] kickerrc (main)
Created attachment 11779 [details] kicker-screen-1rc
Created attachment 11780 [details] kicker-screen-2rc
Ok, all three of my kicker* files are now attached to this bug report... I noticed, that the time-stamp on each one is from _today_. Do they get overwritten even when I do not modify anything about kicker? =(i love xinerama and got kicker working pretty flawlessly =with it for 3.4) but dual head is not my friend. Tastes differ. I like being able to group different tasks -- including different buttons, applets, and menus in different kickers. I also like being able to set different backgrounds and place different items onto different Desktops. Those are subjective reasons, but when physical monitors are seriously different, joining them in Xinerama makes a lot less sense objectively. =or you could see it as an opportunity. Please, stop dropping these hints. I strongly suspect, I am contributing more to Open Source, than the VAST majority of KDE users (including KDE bug reports). Not that any of this should matter, of course -- a bug is a bug, and "I'm not going to fix it, because I find your setup to be oddball," is not a valid response :-( In your making Xinerama "work flawlessly for 3.4.1" you, evidently, introduced a regression, which bites non-Xinerama setups. A responsible programmer would find it and fix it. This is your code and you are in the best position to do it. Thank you.
=after settings things up again, do the settings survive a log out and log in again? Yes, they do. Thanks.
looking into it, this is a problem with the kicker-3.4-reverseLayout kconf_update ... it only gets applied to kickerrc. the fix would be to make it dual head aware and read all applicable kickerrc* files rather than rely on the stdin/stdout piping of kickerrc via kconf_update. > Do they get overwritten even when I do not modify anything about kicker recently used apps and various other bits of information are kept in those files, so yes they get written to from time to time. > A responsible programmer would find it and fix it oh please. that has got to be the lamest thing i've read all day. btw, i DID fix dual head regressions i introduced during the move to KConfigXT when they were reported. i am a responsible programmer, but i'm not your monkey. > In your making Xinerama "work flawlessly for 3.4.1" you, evidently, > introduced a regression erm.... no, the dual head management and xinerama support are completely separate. nice try though. > This is your code and you are in the best position to do it. and yet i don't care about dual head nearly enough to support it with my time and effort. my time doesn't grow on trees and i don't even HAVE a dual head set up to test on anymore. so find someone who does care and i'll gladly support their efforts by helping them through the code base, answering any questions they may have and triaging their patches. until then these issues will go largely unaddressed.
=and yet i don't care about dual head nearly enough to support it with my time and effort. Then why don't you make this position KNOWN to the wider audience? You are currently the only person, who gets to see the kicker bugs, which -- considering the above statement from you -- means, this component is largely abandoned. I'm adding some addresses to the CC, hoping, that one of these people will have more sense.
> Then why don't you make this position KNOWN to the wider audience? it's not a secret. it's been said many times, and not even just by me. there's a reply to a BR somewhere by coolo where he states the exact same thing. > You are currently the only person, who gets to see the kicker bugs nope, there are many who are on the general kde bugs-dist email list and bugs.kde.org itself is open to the public. > this component is largely abandoned multiscreen support in KDE in general is largely unattended to, yes. xinerama is much better supported, but that's because we have people maintaining that. what we need is people who use multiscreen and can test on it to step up. > I'm adding some addresses to the CC wow. do you know how utterly rude that is to those people whose addresses you added without their permission? the term is "spam". i'm removing them out of respect for their time; if they wish to add their addresses they can do so on their own. > that one of these people will have more sense and for some reason i keep replying to you with reason and calmness. this will be the last time as you've run me out of patience with your kindergarten attitude.
FYI, I am reading this. There are others as well.
=wow. do you know how utterly rude that is to those people whose =addresses you added without their permission? Why is it any more rude to add them "without permission" than e-mail them asking for permission? They can remove themselves -- something you should've done, BTW. =the term is "spam". No, it is not -- these were not random people -- I picked them from kicker's AUTHORS file. Talk about "kindergarten"...
That means nothing. "Author" isn't the same as "Maintainer". John Firebaugh and Matthias Ettrich haven't committed a single line of code to KDE in over a year, while Aaron has the final say on all kicker issues. Now, while this is a low priority for Aaron, if someone wishes to take over the problem and fix it, I'm sure he'll appreciate the patch.
=That means nothing. "Author" isn't the same as "Maintainer". Of course, it is not the same. But it is perfectly reasonable to expect one of the authors to be able (and, maybe, want) to fix the problem. So there was nothing rude nor spammy about my adding these people to the CC list. =if someone wishes to take over the problem and fix it Now that these people _know_ the problem exists (after my "rude" action), they may be able to do something...
> But it is perfectly reasonable to expect one of the authors to be able (and, > maybe, want) to fix the problem and what you've been told twice now is that, as reasonable as it may have seemed to you, this is not how it works. if they cared to keep up with these bugs they'd check them on b.k.o or subscribe to them via the mailing list. and the only reason i'm replying to this yet again is in hopes that you won't repeat this with other bug reports.
Can we close this bug report? I fail to see why this should be left open. I mean, is this really an issue with the KDE 3.5 series?
Closing then, no one seemed to care.
Is WORKSFORME really appropriate? My impression was, KDE developers simply don't use multiple screens -- preferring a Xinerama setup (which combines all their monitors into one screen). More like WONTFIX :-(