From kdepim-users Sun Jan 13 05:47:53 2008 From: Chris Gow Date: Sun, 13 Jan 2008 05:47:53 +0000 To: kdepim-users Subject: Re: [kdepim-users] kontact and kde4 Message-Id: <200801130047.54107.sniffy () rogers ! com> X-MARC-Message: https://marc.info/?l=kdepim-users&m=120020333117249 On Friday 11 January 2008 23:19:15 Roy J. Tellason wrote: > On Friday 11 January 2008 20:25, Douglas Almquist wrote: > (Snip) > > > Given the tone of this thread I assume this will be received as criticism > > by the programmers here. > > That seems to be the way of it, in my experience as well. > > > I really wish someone will consider what the performance of the Open > > Source programming community is doing to the competition (Microsoft): > > wonderful things. > > Indeed. > > > One cannot complain much to the programmer since there's only one. But > > if the OpenSource model is going to succeed there has to be some > > administrative direction given to products and packages based on business > > needs. > > Or at the very least some user input into the way things are going, rather > than things just happening based on decisions made elsewhere by folks I've > never heard of until after things get brought up in here. I believe there is some user input into how things are going. Just because *you* are not consulted in how some feature (or set of features) are developed does not mean the developers do not solicit input. If you want to know what's going to be added or what is being added to a piece of software, follow the development mailing list or the commit mailing list. > > > Should a business or a consumer choose the KDE platform if they've > > chosen to resource only a single programmer towards supporting a key > > package in a white-hot market space? [Smartphones / converged mobile > > telecom devices] How can the answer be anything but No? > > In my own case, it's kmail I have issues with. A program that I've been > using for some *years* now, and which has changed with successive OS > upgrades until I find it significantly less usable than I have all along. > > > > Secondly, this is open source software, NOT a "product". It's produced > > > largely by volunteers and doesn't cost you a nickel. > > What I'm spending on this stuff is _my time_, which is an irreplaceable > resource. I'd rather not waste it if at all possible. And yet this > version of the software does exactly that, way too often, and the > "feature" that's causing it is something I didn't want and which there > doesn't, as far as I've been able to determine, seem to be any way to > disable it. You (and the parent poster) seem to have this sense of entitlement. That the developers are here to serve you. Well they are not. Their time like yours is an irreplaceable resource. > > > > And it's not like Palm has ever been helpful to those of us running > > > PDAs and Linux. When you pop up with a new PDA model, which uses > > > software much different from its immediate predecessor product, you > > > shouldn't be surprised if it takes a while for volunteers to get access > > > to one, and create software for it. > > > > I'm truly ignorant of what support Palm gives the community and you're > > right, I would expect a delay of some kind for support for new products. > > I sympathize with your plight... you don't have anywhere near the > > support required to succeed in this marketspace. > > "Marketplace" as you're using it here I would tend to assume meaning a > community of users, as opposed to the more business-oriented use of the > term some interpretations might assume. This is where I believe you and the parent get it wrong. This environment is not a marketplace, its more of a co-operative. If you are willing to do some work, you will probably find that the developers are more willing to help you. I do not necessarily mean develop software, but in support, documentation (you've mentioned in a previous thread that the help was out of date), translation etc...In the case of the parent poster, perhaps he should contact Palm and tell them that he is attempting to use their product on a Linux system. > > > > All you ever had to do was search on the term Kpilot, and go to the > > > Kpilot website, where you can find the hardware section, as below. > > > http://cvs.codeyard.net/kpilot/hardware.php > > > > I'm unaware of that site and am puzzled why the single programmer > > responsible for this package wouldn't simply start the conversation with > > "I'm not supporting that hardware" or "we have no reports that the 700p > > will work with kpilot." Generally these mailing lists are the best > > place for up-2-date information. > > I started out with the help files that came with the software (which are > incomplete at times and often not up-to-date with current versions of the > software either), went through assorted web sites, to the kde mailing > list, and then ended up here, where when I post on my particular issues > instead of any pointers toward helping out I'm told I should be grateful > for all the hard work some folks are doing. That's not 100% accurate, you have been given pointers on occasion when you asked a question in a reasonable manner. For example, you asked how to disable the wallet from popping up (http://article.gmane.org/gmane.comp.kde.users.pim/8750) and were given an answer, you asked how you could get the source of kmail to fix/change some features you were (and still are apparently) less than pleased with and Ingo provided you with links (http://article.gmane.org/gmane.comp.kde.users.pim/11754). You are only asked to shut-up and be grateful when you come on this mailing list, pissed off and demanding that things be changed. Well, you know what? I can understand what you're experiencing. I run KDE on an older laptop (6 years old). Kmail does a number of things that frustrate the hell out of me too. But you know what? I don't complain, you know why? Not because I have any real sense of gratitude to any of the developers (I don't know them), but because as I said above this is co-operative. Until I start sharing some burden of developing kmail I do not have the right to complain. > > I'm looking in the source tree and the revision history, which might tell > me when I could expect some of the features that I most object to were put > in, is _several years_ out of date. I ask around in here, and after a > couple of attempts finally get a pointer to a web site that's supposed to > have more current info on it -- only what it turns out is that hte info on > the web site is the same as what I already have on hand with a > not-particularly-current distro's source files. No help at all, as the > way the file is put together is all entirely too cryptic and of no apparent > use to me whatsoever. I'm not sure what file you are referring to exactly, do you mean the change log? If you want to make changes to kmail, the best place to go to for assistance would be the kde-pim mailing list. All of the kmail developers are there and should be able to help you out. > > > Wouldn't it be helpful if the Kpilot software itself identified the model > > and informed the user of the likelihood of successful function. I > > suspect this feature would save hundreds of hours of support work on > > products that are not supposed to work in the first place. > > Wouldn't it also be helpful if, when such new features as the kmail > program automatically compacting all folders are added, the end user had > the option to disable it? I have a lot of archival folders on this setup, > which are only added to, and which *never* have any deletions done on > them, yet they are continually compacted by the software. A process that, > among other things, _WASTES MY TIME_, because when it gets going the > composer window that I'm _trying_ to use doesn't respond to what I'm doing > at all, until it's done. Whose machine is this, anyway? Who is it that > this software is supposed to be here for, if not the user at the keyboard? If you are that passionate about how kmail/kdepim is being developed, why are you not following the development of it closer? Why do you not have a separate user account that you can use to get up-to-date source copies of kmail and test the functionality as it is added? Why are you not supplying patches to the developers with this functionality? You ask who's machine it is, well its yours of course, you choose to install kmail, you choose to update kmail, you choose to keep with the latest released version of kmail. Have you asked your distribution how to get older versions of kmail? You ask who's the software is supposed to be here for, of course you are correct it is the user at the keyboard. But I can say with certainty that 100% of the kmail developers *are* kmail users. Obviously if they did not believe that a certain feature was worthwhile they would not _WASTE THEIR TIME_ developing it. > > There are other changes, which involve taking configuration options that > were formerly all in one place, and scattering them around to several > different places, some of which I didn't discover until quite some time > after I'd been using this version of the software. I do NOT consider this > an improvement, and yet I'm told that these changes were implemented > according to > some "usability people", folks that I've never heard of before, nor > since, nor has there been any communication there -- nobody asked me if I'd > be okay with these changes, nor have I ever been given the opportunity to > pass my opinion along. Of course they asked you. You have access to the latest source, you are free to get that source at any point in time and see what is going on. You then, as I have already mentioned, are free to fix the problem or at the very least let the developers know that there may be problems with the feature. > > > > You may indeed be a real user with a real problem. To people who are > > > basically here to help others, however, you give the impression of > > > acting like both ungrateful brat and a Microsoft Troll. If you're not, > > > please reconsider your petulance. > > > > Your name calling is not helpful to anyone. Everyone is an ungrateful > > brat who comes with anything but praise and/or money. We or you have a > > serious problem here... you're radically underresourced and you spend > > time in long-winded arguments when a quick "We don't support your > > hardware" should have sufficed. As you so aptly pointed out with a link > > to codeyard.net, in OpenSource initiatives information isn't centralized > > but spread out over what appears to be unrelated web sites. The > > uninitiated (non-programmer) shouldn't be expected to navigate to exactly > > the needed information. This is what email list servers are supposed to > > be for. > > You mean like this list is supposed to be here to support these products? Funny. Many people (including yourself) have gotten support here for issues. I might also add that in the two threads I posted above you did not even respond with a thanks, that solved the problem. The reason why I mention that is that it helps others who might have a similar problem know that the solution suggested is one that works. > > > This is why subject matter experts are so valuable to the community. I > > can only assume you enjoy this pompous pose of yours. What's the win in > > it for you, I wonder? > > I'll make one final point here. I've asked not once, but several times > now, what might be involved, what sorts of hassles I'm likely to run into, > if I choose to revert to an earlier version of the software, one that > still works the way I want it to. I've yet to see an answer. That sort of question is probably best asked on the kde-pim mailing list, not the user support mailing list. But I'll take a stab at it for you: The libraries for KDE3 are supposed to be backwards compatible for the entire KDE3 lifetime. That means theoretically you will be able to take kmail 1.0 (or whatever version was available at the beginning of KDE3) and compile it on KDE 3.5.8. The best option would be to create a development user (not your day-to-day user account), check out kdepim (not the trunk, one of the 3x branches), compile it, play with it for a little while to make sure nothing drastically bad happens to email and then copy it to your day-to-day account. But the best solution would be to get a source copy of the latest kmail, find and fix the problems you see in kmail and suggest them as patches back to the developers. I'm pretty sure you'll find that the developers would be willing to accept patches that improved the application for more users. > > I suppose that which version that turns out to be isn't going to be > answered either. > > And I further suppose that I won't get anywhere except on my own > initiative, spending way more time on what should be a simple issue than I > can afford, because I have to install what versions I have on hand until I > get to where I want to be with this, or spend endless hours poking around > in the source code, and compile the damn thing myself. > > Support? Not bloody apparent, to me. Well, what do you expect exactly? Do you expect volunteers, whose time is just as valuable to them as yours is to you, who have just as many responsibilities pressing for their time as you, to jump up and say 'yes, Roy you are right, we should do exactly what you say'. When you don't do anything other than occasionally come on to this mailing list with caustic emails stating that kmail is getting worse and worse and threatening to use another mail program? Really, Roy, what do you expect? And have you tried asking about getting an older version on your distribution's mailing list? As far as I can tell, you are using Slackware, have you tried asking if anybody has attempted what you are trying to do? The distribution would know better than the people here. They know how the application was compiled, what flags were used, what library versions were used. > > And I'm supposed to appreciate this? I'm supposed to be grateful for the > product? Yes. Yes you should, why? Because you choose this 'product'. No one has forced you to use it, no one has asked *anything* unreasonable of you. In fact other than myself, no one has suggested that you do *anything* other than show a modicum of respect to those who spend their free (unpaid) time working on the 'product'. > > I may just see what all else is out there, and not bother with it > altogether, if it comes down to that. Well, that is your choice of course, gnome has evolution and to a lesser extent thunderbird. If you don't mind text based interfaces there is always mutt. I'm not aware of any other KDE centric email clients other than kmail. You may want to research how evolution handles older hardware, and I'm not 100% sure how much new development is actually done for evo. As for t-bird, well some co-workers of mine use it, I can't stand it personally, but then I am used to some of kmail's features (keyboard shortcuts, good email threading). I have never used mutt, but from what I have heard its a pretty good mail client. > > There's little bloody support here! Well, that's your opinion. I see it differently. -- chris _______________________________________________ KDE PIM users mailing list kdepim-users@kde.org https://mail.kde.org/mailman/listinfo/kdepim-users