Version: (using KDE KDE 3.2.92) Installed from: RedHat RPMs OS: Linux Now that Kmail has the ability to compose HTML email, it seems it should also have the ability to reply to HTML email that has been received, with the same formatting. Presently, when I click on 'Reply' to an email that I've received that has been HTML formatted, the Reply window loses the HTML formatting and is just plain text. I do have the option of changing my reply to HTML of course, but in the meantime, I've lost all the HTML format of the original email.
I suppose that might be true, I have no idea. But I do know that Evolution is able to do this with all HTML email (leaving the HTML formatting when replying) as is of course, many other MTU's :)
Yes, that would be a great feature. It includes the ability to reply a html message without loosing formatting, or to forward it. Maybe it could be an option...
*** This bug has been confirmed by popular vote. ***
Actually, I had to switch to Thunderbird at work because people complained that I break HTML messages when replying to them. Very bad, since I have to give up on Kontact, too :-(
I am about to have to do the same as comment #5 for similar reasons. It's becoming less and less of a "feature" and more and more a "must" since Kontact (kmail) doesn't even include the text message in a reply if it was originally seen as text.
The ability to do this is absolutely vital in a business setting. I get a lot of mail with tables or information formatted specifically to convey business relationships - responding to these is a huge source of frustration and a source of many many complaints from my business colleagues. This is a useability necessaity for kmail in the business world where clear summary (formatted) information transmission is a vital and frequent part of the normal business day. I really like kmail aside from this enormous problem - I'd really prefer not to switch back to evolution (which in this area is 100% useable). I'd love to see this tool step up to the bigger role it cold play in the business world. gene/
I agree gene. I don't know why this doesn't seem to be a priority with Kmail development. It is the one single most frustrating thing about Kmail, which is otherwise an awesome application.
I confirm this, it's very important for business work. Kontact is the best PIM software, but this bug it's really a problem for working world.
Please can the developers comment - its been nearly 2 years. The reality is this is vital if kmail is to be the mailer of choice in todays modern & commercial world. It'd be very very nice to know its coming - or not - please don't make me use evo! thanks/ g
Guys - any movement here? This is a realy kamil killer .... ;-(
And I need typing lesson!! I meant of course, its a kmail killer for many and certainly in a business setting.
Any chance of being able to keep formatted email? Any dev care to comment - please? It is a big blue blot on an otherwise terrific tool. Real world scenario - a few days back. I can find no way to do this in kmail - if there is please enlighten us, I'd really love to know how to do this without using evolution or thunderbird. Send first draft (formatted) of our budget - cc self - managers edit and send back or offer suggestions. Reply to mail so I can edit and send again with changes - repeat until finalized - then send to larger group. kmail - cannot be done. period. Each time the mail comes back or I need to update I have to re enter the formatting .. very very very very very very frustrating. Really appreciate any help. I think fixing this longstanding bug would go a long way. Thanks for any help you can offer, gene
It's very interesting to see how people abuse mail with all kind of crap :( Use attachments if you really feel like sending documents forth and back and waste bandwidth and space. Alternatively use systems that were made for working as a team, mail is NOT a collaborative working tool.
Stefan, this is the most ridiculous attempt to justify a missing/incomplete feature I've seen in a long time... =mail is NOT a collaborative working tool. Pathetic...
This is the real world guys ... please don't be abusive. I work in a large corporate environment. Don't assume that your way of working is necessarily applicable to everyone. Try and be open minded. And lets keep this polite - and yes - mail is a collaberative tool for some - sorry if you don't believe it - it is - even if you don't like it. It is not considered abuse in the business world of which I am a member. It is however considered rude to destroy the format in replying to an email. The world has evolved and pure text email is not the only source of communication. Formatted mail is a reality. Sorry if you don't like it but it is. kmail even supports it - just not completely. Attachments definitely have a place - I agree especially when the data gets beyond a page or so. Further, you will note, that every other mail product, outlook, evolution and thunderbird all support this. As an aside, I'd much appreciate polite, clear and unemotional comments please. And insults have no place here either - please try and remain professional even when your views differ from others. Thanks/
I allow myself to intervene in the discussion, because I agree partially with Stefan Gehn. Indeed, better tools exist to make a collaborative document (open office, wiki...). Nevertheless, it is very practical to use the HTML in the work to be able to format ahead the key points thanks to the HTML. For example, the numbered lists and the tables are also very useful to make a fast synthesis. Yes, I can do that with open office, but that would be faster if I could do that directly in Kmail. Moreover, that which receives my e-mail can read it directly, without needing to open another software. It seems normal that the recipient can modify e-mail in HTML to add comments. I think that Kontact will never replace Outlook in the companies if it has this type of limitations. Do the developers of Kmail prefer that is Evolution or thunderbird that the companies prefer ?
Remember too that we need to respond to emails as well - from the boss, other managers, colleagues in the firm as well as customers. We cannot simply tell the entire world to use another means to communicate. We need to deal with others if we are to succeed. Telling your customers to send a potential transaction a different way will not endear you to them. Taking time and money to reformat your reply makes no sense either. Outlook is in widespread use as was mentioned above. Its a fact whether we like it or not. I sincerely hope that kmail will grow to realize its potential.
Guys, this discussion is pointless. KMail will eventually get this functionality. Currently this functionality doesn't exist due to a combination of technical reasons (the text editor we are currently using does support only a very limited subset of HTML) and organizational (don't know a better word) reasons (lack of developers who have the time and are willing to work on this). And FWIW, if somebody really wants to have a feature added to a Free Software project he can simply contract someone to implement this feature. The German BSI did this already several times in the past. And they even did it the right way because they demanded that the new features are put into the official releases and not just in some special in-house versions.
Hi all. I think KMail is a great tool, but the lack of this feature is a deal-breaker for me. I know a lot of people are against the whole idea of HTML e-mail, but the fact is that the issue has already been decided outside of the Linux/UNIX world: HTML e-mail is here to stay. So KMail ought to have first-class support for it.
Hi all. I have chosen Evolution in the work for this problem of HTML. I go many years being working with Kmail at my house and in the work i have not been able to use it.
Ok, we have understand that it's difficult to implement this into Kmail. But, for KDE4, with new Qt4 and kdelibs4, do you think that a new solution will be possible easily ?
Doesn't matter - if KMail doesn't handle HTML properly and easily, it won't be used. The rest of it can be elegant, fast, robust, magic even, - but no HTML, no users.
I must agree. IMHO, KMail can't be a serious contender for use in a business setting without this. And by the way, Evolution doesn't handle HTML particularly well, either, so if KMail did, it would be a real differentiator.
Ok, I think that everybody understands the business problem. But somebody of KDE_PIM could say if a solution will be found with KDE4 ? A bounty must be created to implement this ? What do you need to implement this ? Thanks for your response.
A simple suggestion.... if the "Use External Composer" option was fixed JUST A BIT it would at least let people like me USE kmail reasonably.... all that needs to be done is... a) Have a checkbox there that says you prefer to edit the HTML version if it exists b) Save the HTML version of the email for the external editor if it exists and the checkbox is checked c) If the HTML version is edited in (b), then when the composer exits send the result as HTML Mimetype. This results in VERY small changes to the KMail codebase, doesn't need anything to do with a new editor, etc. And all the user has to do is put 'kword %f' in the editor box. I know it is highly likely any other change will never be done in the 3.X stream since everyone is now working on KDE 4.0... but if the history of this bug (and what I see in KMail's SVN) is any indication, nothing else is going to be done to get this working anytime soon... so maybe this is a simple option... I may make a patch to enable this if people think it would be useful.
Jason, I'd sure appreciate a patch to make this work! You'd have to explain to me how to apply the patch - but I'd sure be happy with this working.
There has been recent discussion on the KDE-PIM mailing list about replacing the embedded composer widget with a more robust HTML editor via a KPart. This would address a lot of current limitations including, I think, this one. Unfortunately, it's not a small chunk of work because no suitable KPart exists today. Your suggestion might be a good interim workaround.
On 9 Mar 2007 22:48:24 -0000, Rob Hasselbaum <rhasselbaum@comcast.net> wrote: >Unfortunately, it's not a small chunk of work because no suitable KPart exists today. What about the Quanta VPL editor?
Quanta is not a KPart component. I asked devs on the Quanta mailing list if there were any plans to package it as such in the future, and the answer was, basically, no. (More precisely, there are plans to componentize it, but not as a standalone KPart. It will be tied to the KDevelop infrastructure.) So its not a viable option unless someone steps up to do that work and maintain it.
This brings up an obvious question: Presumably this is mainly an issue for those who correspond with Outlook users. Does Outlook even use compliant HTML ? Internet Explorer doesn't conform to neither W3C standards nor javascript... does Outlook ? Even if Kmail was fully HTML compliant, would Outlook emails work correctly ? (I doubt it, even if you ignore the embedded Office Docoument BS) We could end up with a fully HTML compliant kmail that still won't be able to play with standards trashing MS apps. 2 CENTS: We use kmail exclusively at our company, and I don't see non-HTML an issue. HTML email is a security risk, therefore our IT department, with mgmt support, refuses to use it. We use plain text. IF we need complex formatting, we send PDFs, via OpenOffice's 'Email via PDF' functionality. PDF far exceeds the "quality" of any HTML email and is easily read on every OS platform. None of our suppliers or customers, small or extremely large have complained. In fact, some have said they now prefer PDF attachments. This IMO is more "i don't like to think or change" on the part of other email users If IT decisions in more companies were actually made by IT staff, HTML email would be gone.
fuuther to my comment #31 If a document need revisions we use an actual attached editable document. Why anyone would use HTML email for a task like that is beyond me. Use the tool actually designed for the job at hand.
Thanks for your comment spinner. It would appear however that there are cases where responding to HTML email is a feature that would be very much appreciated. I won't bore you with all the reasons for using HTML email. But I can assure you that there are reasons, beyond you or not. I doubt that HTML email is any less secure than opening up an HTML attachment for editing. As far as standards are concerned - Evolution has the ability to reply to Outlook email composed with HTML.
It's a straw man to think that Kmail's HTML problem is primarily the result of corresponding with MS Outlook users. Kmail's problem is completely independent of MS Outlook. Even two Kmail users cannot properly correspond with each other using HTML because Kmail removes their HTML formatting each time they hit "Reply."
On Monday 04 February 2008 19:47:42 spinner@shaw.ca wrote: > Presumably this is mainly an issue for those who correspond with Outlook users. Does Outlook even use compliant HTML ? It can and does. Wouldn't it be useful for you to actually get some FACTS rather than "..doubt it." > Internet Explorer doesn't conform to neither W3C standards nor javascript... does Outlook ? > Even if Kmail was fully HTML compliant, would Outlook emails work correctly ? Yes. > (I doubt it, even if you ignore the embedded Office Docoument BS) > > We could end up with a fully HTML compliant kmail that still won't be able to play with standards trashing MS apps. > This is not a concern. Thunderbird, Evolution, and whatever MY CUSTOMERS use does just fine with HTML. > > > 2 CENTS: We use kmail exclusively at our company, and I don't see non-HTML an issue. Well, in the REAL WORLD our customers use it and it is very helpful in sending messages which deal with content where the formatting helps convey meaning. The fact that you don't understand the need, and cannot get your mind wrapped around it doesn't make it any less an issue. Stop pretending you are in a position to judge others. > HTML email is a security risk, therefore our IT department, with mgmt support, refuses to use it. What??? Maybe if you are using Windows and Outlook, but is KMail so fragile that HTML will break it? If so, let me know and I can get everyone onto Thunderbird ASAP. If your IT department things HTML email is a security risk, perhaps they should take a quickie course on firewall and proxyserver configuration. > We use plain text. IF we need complex formatting, we send PDFs, via OpenOffice's 'Email via PDF' functionality. > PDF far exceeds the "quality" of any HTML email and is easily read on every OS platform. Yes, it does, but it is a pain to edit, in-line quote and you cannot cut-and-paste it very well (adds a CR-LF at the end of each line) > > None of our suppliers or customers, small or extremely large have complained. > In fact, some have said they now prefer PDF attachments. > > This IMO is more "i don't like to think or change" on the part of other email users > If IT decisions in more companies were actually made by IT staff, HTML email would be gone. So would all those pesky customers as well. Please, get a clue. Your world is obviously very insular. If this is the attitude of KMail then I hope someone starts another KDE native e-mail ASAP.
Can we just get over this discussion about whether somebody thinks it is a good idea or not? Reading the above posts, it boils down to the following: Is there a need for this? Check. Comments illustrate that this function is used in many businesses, and can be considered necessary for corresponding with clients (mine included). Is it possible? Check. Other mail clients (open and otherwise) already support it. So can we please move on to a more productive talk, mainly on HOW to implement it in a useful way?
Folks, it's not the we (the developers) are fanatically against this, it's simply that no one has had the time or inclination to implement it. It's always the same problem, someone has to do the fscking work. Throwing peanutes, from however lofty a gallery, arguing either way, yelling and screaming, endless threads in this bug, on slashdot or your living room will have absolutely no effect whatsoever. Here are the options for getting this implemented: 1) implement it yourself 2) find someone to implement it for you, by motivating them with a) cookies b) something you do for the community in return c) money The resources for 2) a) and b) are very limited, as there are currently only 2 or 3 non-paid developers working on KMail in their spare time. 1) has currently the most chance of success. For 2) c) you can post to the kdepim@kde.org or kmail-devel@kde.org development lists and ask for quotes, there are companies (like mine) who will be happy to help you out as time permits. Note that I would much prefer you do 1) or manage to get us a new contributor by 2) a) or b).
On Monday 04 February 2008 22:33:53 Ask wrote: [bugs.kde.org quoted mail] If there is a real desire to avoid any sort of hidden surprises, it may be an acceptable compromise to limit what tags are used at first, and plan to evaluate additional features as users request them. For example, list and font related tags are likely high priority. They are also unlikely to cause a kernel panic. Maybe start there (i.e. preserve font, font size, italics, bold, underline as well as lists) and work on preserving some other aspect of formating later.
Also note that Ingo (until this week maintainer of KMail) said exactly the same thing in comment #19 more than a year ago. Apparently that fell on deaf ears as well.
Till, it was actually ME that paid someone to implement the ability for Kmail to compose HTML messages in the first place. I forget what I paid exactly - it was back in 2004 or 2003. I'd be more than willing to contribute something to having this particular "bug" fixed as well.. but Ingo's comment that you refer to above stated that it was coming... and pointed out what was needed to make it happen... the editor seemed to me to be the biggest challenge - what's the point in implementing it if the text editor is going to be changed anyhow? I'm no programmer - so I can't implement it. But, I am a supporter of KDE, have used it, have promoted it, have convinced others to switch to Linux and KDE, and have financially supported both KDE and paid for the HTML composing ability - and when I paid for that, believed that it would also mean being able to reply to HTML email without losing the formatting. That was 5 fusking years ago! By all means, if someone can state outright that the new editor will be such and such, and then someone comes along and says, "OK, to implement this feature will be x amount of dollars," damn - i'd be willing to donate something toward that.. and hopefully others who find this feature valuable would too. But... what's there to donate to, when we don't even know if the present editor is going to be replaced, or if it has been, or what?? It's very easy for some to say, "implement it yourself or pay for the implementation..." and I understand that KDE is worked on mostly on a volunteer basis... but for fusk sakes - I HAVE donated.. I HAVE supported... so maybe someone from Kmail can tell me what to do next in order to get this feature implemented.
I really wish kmail had this simple feature. KDE has no other mail client and for most(non technical users) simple text mailing is not good enough. Perhaps we should start a fund raising account for this feature to get implemented. I would contribute to this as perhaps would many. Gnome has two programs that can do this and little things like this make Gnome more human friendly than KDE in my opinion.
= But... what's there to donate to, when we don't even know if the present = editor is going to be replaced, or if it has been, or what?? Worse. What's there to donate to, when every once in a while some yahoo comes out to question the need for the feature to begin with? The bug has 627 votes already. If that's not enough of a motivation and money is routinely, then just "resign" and concentrate on your paying jobs...
"Worse. What's there to donate to, when every once in a while some yahoo comes out to question the need for the feature to begin with? " Well, don't ya know that having a GUI to send email is a security risk? I mean.. everyone should just know how to send email from a command line, dontcha know?? And of course, asking Sendmail to add a "feature" of a milter.. well.. sheesh, that's just not what Sendmail is supposed to do.. want a milter? Go create your own! Adding new features is a security risk! Hey..did you know that REAL IT people don't want and won't allow Quanta? I mean.. HTML is just.. well.. HTML.. and anything more on a website other than HTML.. well .. if it were the IT guys in charge, it just wouldn't be allowed, ya know? Who needs PHP or Flash, or Java, when HTML can do the job of simply displaying websites? Gosh, adding PHP might be a security vulnerability! Can't have that now, can we? Like seriously.. the html protocol was never originally designed for stuff that folks have dreamt up today! Get a life, would ya!!??!! If my IT guys had their way, PHP would be totally disabled! HTML provides EVERYTHING anyone actually NEEDS, ya know? Requesting extra features and modules in Apache is.. well.. you know.. a security vulnerability! If IT guys had their way, it would just do what it was originally supposed to do.. and that's it!! / sarcasm off Yahoos indeed.
Laurent Montel is working on an improved editor for KDE 4.1, I don't know enough about it yet to judge whether that will make html replies possible or not, but maybe you can ask him. Edwin Schepers is also doing work on html editing in general, html signatures, etc. He's a good person to ask. Post to the mailing lists, this is a bug tracker. @Ian: I did not mean to belittle your contribution or tell you to shut up. Unlike nearly everyone else in this thread you have, as you said, actually done something about it. I was merely pointing out that there is no need to convince the developers, we've been convinced for years, it's the peanut gallery who's still arguing against this feature. @mi+kde@aldan.algebra.com: A major reason why I and many of my colleagues at KDAB for example still contribute to KDE is because it is part of our day job to do payed KDE development. Without that, we would surely have "resigned" already, for lack of time, not motivation. Payed development is an option, for those features or bugs that the volunteers don't care to implement, that's all. I won't "resign" from kdepim simply because I'm paid for part of my work. I do continue to do unpaid work in KDE, but I can damn well chose what to spend that time on, and it's not this feature. There's several mountains of work to do in porting to KDE4 alone, so I'm focused on that, in my spare time, since right now we want to get something usable out with 4.1.
>We use plain text. IF we need complex formatting, we send PDFs, via >OpenOffice's 'Email via PDF' functionality. My God! What a thought! Making email with the ability to "attach" documents! Why, isn't that a security risk? I mean.. shouldn't we just expect email to do what it was originally meant to do and use protocols such as FTP to exchange documents? What a risky feature! To have the ability to attach a document to an email! If those really really sharp IT guys had their way, there's no way we'd allow folk to attach documents and send files via the SMTP protocol! Just not what SMTP was made for!
Can you guys lower your tones and calm down a bit, please?
" @Ian: I did not mean to belittle your contribution or tell you to shut up. Unlike nearly everyone else in this thread you have, as you said, actually done something about it. I was merely pointing out that there is no need to convince the developers, we've been convinced for years, it's the peanut gallery who's still arguing against this feature." Fine. And hopefully you understand my frustration when people respond to this (and other bugs) with.. "implement yourself, or donate..." I mean.. I have... and I've done other things as well.. but.. this bug has been going on for almost five years!! So.. what WOULD it cost? I'd be willing to donate something - but is anyone willing to come up with an estimate of time, and a price, and then I'd be willing to even assist in fundraising efforts... but without even knowing if it's possible - especially with Ingo's comment of about three or four years ago, that this feature was going to happen.. but it's an issue of the editor being used... I mean.. simply asking someone to implement or donate or pay .. is a bit ridiculous. And as has been pointed out, this "bug" or feature request is not exactly some "way out there" request as far as what people have expressed an interest in and also compared to what other similar applications ARE able to do. So does it rely on a new editor, which was going to happen anyway, announced four years ago.. or what? Like.. it was about four years ago that Ingo said it would eventually be implemented. So.. does that mean another four years or more from now? And what specifically can be done to move it along? Donate to who? Where? How much? No one knows!
> Can you guys lower your tones and calm down a bit, please? I am very calm. Perhaps you should read the messages, and imagine they are being written in a whisper instead of whatever other projections you might have in your mind.
Again, this is a bug tracker, please move this discussion to the mailing lists.
Couldn't KMail use embedded KHTML/KWrite, the same way Konqueror does? KHTML to display and KWrite to reply?
In reply to Marcus Harrison, this bug is about replying to HTML email with the same format as what it was received. If I recall correctly, you could display HTML e-mails fine, it's when you reply to them that you lose any formatting in the main e-mail. KWrite is only a plain text editor and I don't think that anyone would be happy with having to write their own HTML tags manually instead of just selecting text and clicking a nice "Bold" button. Tables and font colors would be an even more difficult thing. I would love to switch to Kmail, but until they provide this basic functionality, I'm sticking wtih Thunderbird.
I saw something about KDEs Mailody client having full html support and that these changes could be used in Kmail. Check it out: http://www.omat.nl/drupal/full-html-support-mailody If this is true then kde4 kontact could have proper html support? I wish so...! I wish the devs would do this it would make so many more people use the software(I still do...)
Is this voting thing a big farce ? I don't think anybody at KDE really care about what you guys have to say. Does anybody ever look at the votes or the bug at all ?
I think patches make a bigger impression than votes.
This is a core feature that any user can expect from a 21st century email client. It saddens me to see that some developers in the Linux 'community' show a behaviour similar to the behaviour of the ones they try to be a good alternative to. Who is KDE writing software for - the users or the developers ? Are you coding to make a great product or to play power games ? In any case, I will have to walk away from KMail until this is fixed, as I really don't feel like bearing the justified laughters of business partners when I have to explain to them that Linux/KDE is the reason I am sending them something that almost looks like a text blob. Please reconsider this, guys, how hard can it be to fix ?
Agreed :) Apparently Mailody can reply/compose html so surely this can be imported into kmail?
Any chance any of the KMail developers actually read this??? Oh, I guess not, so if Mailody doesn't meet my needs, I will just be switching to Thunderbird(Enigmail) or Claws and having to suck it up and deal with the ugly-ass and poorly designed GTK+ UI (esp. file chooser until I can get KGtk working right). Hey, KMail developers (those left on earth with us pitiful mortals): hate to be the reason why people are switching from KDE to GNOOME but right now that is YOU! Go ahead, and tell us pathetic users why we don't need HTML forwarding all you want, but you are ivory towering yourselves into irrelevance. Damn your eyes! Get a ticket on the clue train soon and catch up with those who actually try to use your software to do things in that nebulous "real world"
yes, we hear you. and you aren't helping the situation. we definitely want to provide this feature. lack of manpower is the only reason we don't have better html support.
Kevin, I actually agree with much of what you have said. However, being abusive is not very constructive ;-) We have to remember that much of FOSS development is done on a voluntary basis so if developers choose to work on something else then that is their prerogative. As a user, I am very grateful to the developers for giving me an alternative to MS domination. I haven't got the technical ability to program but I can, and do, help by requesting features, identifying bugs and supporting other users. However, I realise that the "community" are under no obligation to provide me with exactly the features I require. I can always choose another application! So, if you are able to program then I am sure the KDE team would welcome your help.
Allright, of course a volunteer developer is free to choose what he wants to work on. But developers not willing to implement features their users need are sure to lose these users. I have to agree, this bug voting is useless, at least for kmail. For sure there has work been done on kmail, just that it was done on other things than bugs or features voted for here. So maybe this HTML support is to big a task for the manpower available. But then the first priority should be trying to find more developers.
On Wed, Jul 9, 2008 at 6:02 AM, Allen Winter <winter@kde.org> wrote: [bugs.kde.org quoted mail] Good, at least GMail's web UI is working. > > and you aren't helping the situation. Sorry, I am a physician working on treating patients and using information technology to lower costs, improve care, and contribute to biomedical research. I am not about to stop that just to try and pick up C++ again. Why are people working on useless eye candy for KDE 4.0 when we don't have a finished email application. It is not my job to help--my efforts to the greater good, or to the open source community are in health care domain. > > > we definitely want to provide this feature. lack of manpower is the only > reason we don't have better html support. That is NOT the impression that I, or another large group of KMail users has been given by the development team. We have been told time and time again that we shouldn't use HTML, or that we should send it as an attachment, or that HTML is a security risk, or a hundred reasons why HTML markup is stripped from the message or why spell checking cannot work in HTML, or other BS. <br><br><div class="gmail_quote">On Wed, Jul 9, 2008 at 6:02 AM, Allen Winter <<a href="mailto:winter@kde.org">winter@kde.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d">------- You are receiving this mail because: -------<br> You are a voter for the bug, or are watching someone who is.<br> <br> <a href="http://bugs.kde.org/show_bug.cgi?id=86423" target="_blank">http://bugs.kde.org/show_bug.cgi?id=86423</a><br> <br> <br> <br> <br> </div>------- Additional Comments From winter kde org 2008-07-09 14:02 -------<br> yes, we hear you.<br> </blockquote><div><br>Good, at least GMail's web UI is working.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br> and you aren't helping the situation.</blockquote><div><br>Sorry, I am a physician working on treating patients and using information technology to lower costs, improve care, and contribute to biomedical research. I am not about to stop that just to try and pick up C++ again. Why are people working on useless eye candy for KDE 4.0 when we don't have a finished email application. <br> <br>It is not my job to help--my efforts to the greater good, or to the open source community are in health care domain. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <br> <br> we definitely want to provide this feature. lack of manpower is the only reason we don't have better html support.</blockquote><div><br>That is NOT the impression that I, or another large group of KMail users has been given by the development team. We have been told time and time again that we shouldn't use HTML, or that we should send it as an attachment, or that HTML is a security risk, or a hundred reasons why HTML markup is stripped from the message or why spell checking cannot work in HTML, or other BS. <br> <br></div></div><br><br clear="all"><br>-- <br>Kevin M. Coonan, M.D.<br><a href="mailto:kevin.coonan@gmail.com">kevin.coonan@gmail.com</a>
Is there an update for this? I thought that with Kmail/KDE4, it would be possible to use the KPart from Mailody as the editor. Has this been done? Or is native support being done? I realise that there may be manpower issues, but is there any update at all on this. Are we any closer, even by 1 line of code, than we were on the 2nd August 2004 when this issue got raised? I hear you with the manpower issue, but still, a giant amount of work has been done porting to QT4, it must have had quite a few devs come out of the woodwork to work on it lately. I thought that might be a catalyst for this.
Why don't we put this feature in programs like Google SoC? I guess atleast students interested in doing this can take this up. Just my 2 cents
As the current KMail maintainer, let me clarify a few things: > I thought that with Kmail/KDE4, it would be possible to use the KPart from Mailody Not correct. Neither does Mailody provide a KPart, nor does KMail support embedding KParts in the composer (see bug 59481). However, KMail and Mailody share some infrastructure, namely KRichTextWidget and the signature editor, which brought improved HTML suppor to both apps (HTML signatures and links, for example). There biggest reason why Mailody has support for replying to HTML messages is that is was way easier to implement in Mailody. First of all, Mailody doesn't support templates, which complicate things. Secondly, the KMail code for replying to a message sadly became complicated during the years. > Why don't we put this feature in programs like Google SoC? See http://techbase.kde.org/index.php?title=Projects/Summer_of_Code/2008/Ideas#KMail Either I put it there too late or no one was interested. Will try again next year if the HTML support doesn't get better in the meantime. >Are we any closer, even by 1 line of code, than we were on the 2nd August 2004 when this issue got raised? Yes, the underlying infrastructure has much improved. See above why this is still not possible. > I hear you with the manpower issue, but still, a giant amount of work has been done porting to QT4, it must have had quite a few devs come out of the woodwork to work on it lately. I thought that might be a catalyst for this. Indeed, much work has been spent to port KMail to Qt4/KDE4. The problem is that this was done only by few people, leaving not much time for features. The port actually introduced many bugs and regressions which needed to be tracked down and fixed, which takes much time. > [...] or why spell checking cannot work in HTML This is fixed in the KDE4 version. > Why are people working on useless eye candy for KDE 4.0 when we don't have a finished email application. Everybody works on what they like to work on. Nobody is getting paid for it. People developing desktop shells would not magically switch to developing a mail application, why should they? Moreover, there'd been an outcry if KDE 4.1 had HTML reply support, but not support for moving applets on the panel because the Plasma developers worked on KMail instead... > Good, at least GMail's web UI is working. No, it adds HTML garbage to your comment on the web interface. Don't use HTML for replying to bugzilla messages. And to the numerous comments claiming that HTML support is not wanted in KMail: I don't know where you get that from, it is not true. Ingo, the previous maintainer, stated in comment #19 that he is not against HTML, and I'm not either (in fact HTML support is a bit improved in KDE4). And again, lack of time of the involved developers is a major reason why this bug isn't done yet. And this discussion is indeed pointless. Please don't leave further comments ranting about this, it will achive nothing but spam the people who voted for this. In fact, I'll ignore all further comments. If you have patches, and we'd welcome every help, please contact the kdepim mailing list.
I'm going to throw my comment in the ring. One thing I'd really like to see is - not only the ability to reply to html email inline without throwing all the HTML codes around - the ability to switch between html, plaintext and rich text on the fly in an email session. I'll attach a screen of Outlook 2003, which I use at work (along with Evolution) that does allow for HTML > Plain Text > Rich Text switching on the fly.
*** Bug 121849 has been marked as a duplicate of this bug. ***
On paper, different fonts (bold, colors etc.) are essential to make information easy to read. This is also the case on web pages and in e-mails. Not being able to reply with same HTML format keeps me and many more from using Kmail & Kontact.
Why is the bug tagged NEW? It dates back to 2nd of August 2004. Why is the priority set to NOR? It's the third most highly voted bug of Kmail/Kontact (after the freeze of the UI when checking mail and the IMAP IDLE support). Why is severity set to wishlist? It strips a reply from all formating and often makes it unreadable. This bug is Major (major loss of function). What are the chances of having this bug fixed in the foreseeable future? Is a bugfix scheduled for KDE 4.2 or 4.3? It would be nice to have - in 2009 - a linux replacement of Outlook 2000.
Rapster: hear hear! Oh wonderful, KDE devs: Please, please, please make this a priority!
Guys, guys, give it up! As Rapster says, this bug, despite all the votes, is not seen as significant by the KDE devs. In fact, reading between the lines it is clear that there is a religious objection to full HTML in email which no amount of user whingeing will overcome. This, plus the fact that this would be tricky to implement (since the current HTML implementation can't handle embedded images, including them in replies would be a significant change) tells me that this this enhancement will never be implemented. If you can't live with it, change to a different mail client.
@Fred Jones: already switched to Thunderbird. Thing is Kmail is a great solution and I love KDE in all other respects. HTML email is necessary for me to work. I switched when someone tried to convince me that email wasn't for sending images and that plaintext was the only way to go ... at least not all the devs are that hard-line (or clueless about business, whichever way you want to look at it).
I did switch to Thunderbird as well. I am not happy with Thunderbird. The UI is not as intuitive as KMail, the opening of attachments is horrendously slow, the integration with exiting KDE apps to open attachments is non-existent, the look and feel is the horrible GNOME-style, including the non-user-friendly open/save dialog boxes, and the fonts are difficult to setup. On top of that - just to get the base functionality I have in KMail, I am forced to install and configure a ton of plugins, and finally it doesn't allow me to switch between RTF, Plain Text and HTML (as Outlook 2003/7 does). Even then, things (like reply-to list and proper quoting) don't work as well as in KMail. However, it does support HTML email replies and forwarding. I really wish I could use KMail. KDE has some great HTML apps - Konqueror, Quanta - so the knowledge from those should be easily ported to KMail. This isn't the days of Elm.
I wish so too. This is a rather big problem with KDE and KDE distros as a whole. Its difficult to give KDE Distro to a normal user as there is no native KDE mail application that can simply reply and follow an html email conversation with other people. Its a real pitty there is only one email application for KDE. I love Kontact and Kmail but just wish there was some sort of plan of requirements from the Dev's to implement this feature that so many users want. Even if there was a fund raiser "award" for this feature, I don't know anything to get this implemented. I wish I knew how to code and write this in ;)
Do you people realize how many people are on the CC list of this bug and get mail notifications because of your not so usefull comments? Please re-read comment 64, in particular: > Please don't leave further comments ranting about this, it will achive nothing but spam the people who voted for this. In fact, I'll ignore all further comments.
With your kind permission: the easiest and fastest way to stop this discussion is by replying to above Comment #68. (HTML link to the comment was deleted due to a Kmail bug # 86423 ;-) Particularly: Is there a schedule for the bugfix? I very much appreciate the excellent and unpaid work of you guys. If I knew how to code I would be more than glad to contribute. (Unfortunately I'm only an economist working in the environmental movement.)
> With your kind permission: the easiest and fastest way to stop this discussion is by replying to above Comment #68. I don't believe that, but here you go: > Why is the bug tagged NEW? Because there is only UNCONFIRMED and NEW, and it is not UNCONFIRMED. NEW really means CONFIRMED in the bug tracker. > Why is the priority set to NOR? Because we usually don't use the priority system. Believe me, I know this bug is important. > Why is severity set to wishlist? Because it is only a bug when some code doesn't work as it should. Since there is actually no code to preserve the HTML structure, this is a wish. I know this is a very developer-centric way, but this makes it easier for us to deal with it. > What are the chances of having this bug fixed in the foreseeable future? Is a bugfix scheduled for KDE 4.2 or 4.3? Definitly not 4.2, that is feature-frozen already. I hope I can find time to do something about it before 4.3
Thomas, On behalf of all of us complaining here, thank you very much for your kind reply. It is reassuring to know that the devs are interested in seeing this resolved. Congratulations on all you've done with KDE 4. I look forward to what happens next (especially if it includes this feature :) ).
For those with C++ and Qt knowledge who are interested in joining the summer of code project: I've just added a "HTML improvements" idea to our ideas wiki page, see http://techbase.kde.org/Projects/Summer_of_Code/2009/Ideas#Project:_Improvments_in_KMail.27s_HTML_support .
Created attachment 31641 [details] HTML reply By far not ready. Just to let you know I'm busy with this (occasionally). If you want to take it over for the SoC, let me know. I'll send you the latest diff.
From my own personal point of view, I just don't see any reason to bother working on this feature until KMail has a proper full-fledged HTML composer (based on WebKit/KHTML contentEditable), like Mailody has. The current composer arch. is so extremely limited that it is never going to be able to properly preserve most formatting anyway.
> From my own personal point of view, I just don't see any reason to bother working on this feature until KMail has a proper full-fledged HTML composer (based on WebKit/KHTML contentEditable), like Mailody has. > The current composer arch. is so extremely limited that it is never going to be able to properly preserve most formatting anyway. If you want to troll, go somewhere else. Also, Mailody's composer is _not_ based on KHTML/Webkit, get your facts straight.
> If you want to troll, go somewhere else. I am not trolling, I am making a legitamate point. Everyone keeps harping on and on about this bug, but the fact is, the current composer can not even handle HTML properly enough to re-create the stuff attempting to be preserved anyway! IE, 25% of the emails I receive have HTML tables in them. The current composer can not create tables. 75% of the emails I receive have images in the signature. The current composer can not insert inline images. I know that the QTextEdit control *supports* tables and images, but the composer, does not. So, maybe a hack can be found that would preserve the formatting, but you would not be able to edit it to, for example, add your own image. Without editing capacity, preserving the reply in a half-OK state is not useful. As such - this bug *depends* on getting a new composer in KMail. This is a fact, it is indisputable. > Also, Mailody's composer is _not_ based on KHTML/Webkit I stand corrected. Sadly this is even more disappointing :( I had assumed as a new/recent project it would be using a decent editing widget....
FYI: I replied to Edwin by private mail. Also, I know I shouldn't participate in this useless debate, but again I need to get some facts from Jason straight: - The composer _does_ support inline images, coming with KDE 4.3 (thanks to Edwin!) - HTML tables are indeed not editable right now. That would require adding some actions to KRichTextWidget, which is perfectly possible and certainly much easier than rewriting the composer in Webkit/KHTML. Also, please see bug 46411 for this.
The QtWebKit HTML editor looks very nice: http://labs.trolltech.com/blogs/2009/03/12/wysiwyg-html-editor/ http://ariya.blogspot.com/2009/03/i-can-see-its-coming-like-serenade-of.html
*** Bug 162901 has been marked as a duplicate of this bug. ***
(In reply to comment #85) > *** Bug 162901 has been marked as a duplicate of this bug. *** Hi Edwin, are here any news about HTML support in "Re" messages? Is anybody working on this? What are the plans? For some of us it is mos annoying "feature" in Kmail. Thanks
*** Bug 206124 has been marked as a duplicate of this bug. ***
Hi Tomas, it's been a time since I worked on it. The patch is somewhat usable but not for everyday use. I will merge it with the latest version and update a patch.
Thanks Edwin, it's last piece for usage of KMail in business environment. Without it I'm limited to cooperate with me colleagues in e-mail threads because I'm ruining their formating in e-mail history. Let's release it so we can test it and possibly improve it. Many thanks (In reply to comment #88) > Hi Tomas, it's been a time since I worked on it. The patch is somewhat usable > but not for everyday use. I will merge it with the latest version and update a > patch.
What is the progress of the integration of the patch? This is a major feature that KMail lacks.
Wow, this has been lingering for how long? I keep getting updates on - what should be - a simple fix to a glaring deficiency in functionality. In any case, for those who want, you can get much of the same functionality in Thunderbird. Not as elegant, but at least it handles emails correctly.
(In reply to comment #91) > Wow, this has been lingering for how long? I keep getting updates on - what > should be - a simple fix to a glaring deficiency in functionality. > > In any case, for those who want, you can get much of the same functionality in > Thunderbird. Not as elegant, but at least it handles emails correctly. Yes I've switched to Zimbra as it is not going to be fixed in this century. Development is waiting for WYSIWYG HTML editor being developed by Qt/Nokia team or anybody. There is something available at http://labs.trolltech.com/blogs/2009/03/12/wysiwyg-html-editor/ since Match 2009, but kmail developers don't like this feature or it is not priority for them despite is voted as one of the most wanted feature. Guys if you are working in Outlookish company, switch to Zimbra. It has HTML support, Kmail will never have.
(In reply to comment #92) > Yes I've switched to Zimbra as it is not going to be fixed in this century. > Development is waiting for WYSIWYG HTML editor being developed by Qt/Nokia team > or anybody. There is something available at > http://labs.trolltech.com/blogs/2009/03/12/wysiwyg-html-editor/ > since Match 2009, but kmail developers don't like this feature or it is not > priority for them despite is voted as one of the most wanted feature. It can't solely be this, as KDE already has great WYSIWYG HTML capabilities, and has for some time, via WebKit. Just log into your GMail or go to a site like http://developer.yahoo.com/yui/examples/editor/flickr_editor.html . It is pretty simple to wrap stuff like this into a QWidget.
> > It can't solely be this, as KDE already has great WYSIWYG HTML capabilities, > and has for some time, via WebKit. Just log into your GMail or go to a site > like http://developer.yahoo.com/yui/examples/editor/flickr_editor.html . It is > pretty simple to wrap stuff like this into a QWidget. It looks simple, but is not priority as I wrote. We are on 7th place in most wanted features. Things like HTML Re or Fingerprint logon aren't in KDE yet while in Gnome are for years.
Disappointed ...
(In reply to comment #94) > It looks simple, but is not priority as I wrote. We are on 7th place in most > wanted features. Things like HTML Re or Fingerprint logon aren't in KDE yet > while in Gnome are for years. This has been posted for years - this was requested in 2004. One day.... perhaps.... I'm still waiting.
I guess it is much more important to have a Twitter widget on the desktop than a functional e-mail client.
Everyone who seeks success in his doing must hear the wishes of his/her customers or users of his/her achievements and results. Being a volunteer does not free you from the need to fulfil those wishes. Yes, we need the behaviour of this software so that it contains all the basic or usual business needs. We cannot use this software anymore without a bad feeling of being understood as IT illiterate. But on the contrary we would all like to believe that we are on the edge of development! Please listen to us as we are the only ones who truly love this software. Knock, knock to your minds, maintainers and developers! If you lose us you lose everything.
There are lots of demands, needs, and consumers posting recently and not many contributors and community members. We can all sit and squawk like hungry chicks or we can contribute to the solution. Demanding and complaining isn't very constructive. Why not set up a bounty, learn to fix it yourself, get together a petition, find out what's really stopping progress etc.. You'll get what you want faster that way I reckon.
El Martes 08 Diciembre 2009 17:13:54 jack escribió: > --- Comment #99 from jack <samtuke hotmail com> 2009-12-08 17:13:50 --- > Why not set up a bounty, learn to fix it yourself, get together a petition, > find out what's really stopping progress etc.. You'll get what you want faster > that way I reckon. > That may be an option -and very reasonable- for programmers, but for users who are economists, history students, musicians; in short: for all those who have a non-computer related job or studies it's inviable; so, unless KDE wants to be a computer geeks DE instead an universal one, I think there's some truth to be taken into account in those comments that say Twitter plasmoids (or similar "cute" apps) should be secondary.
(In reply to comment #100) > That may be an option -and very reasonable- for programmers, but for users who > are economists, history students, musicians; in short: for all those who have a > non-computer related job or studies it's inviable; so, unless KDE wants to be a > computer geeks DE instead an universal one, I think there's some truth to be > taken into account in those comments that say Twitter plasmoids (or similar > "cute" apps) should be secondary. Anyone can offer a bounty (i.e. money). You don't have to be a programmer to do that. It's a typical misconception among some users of open source software that developers somehow owe you something. They do not. But it is well within your power to offer incentives to developers in the form of money or something else of value. Or, if you're a programmer, contribute a patch. Either alternative is better than demanding action.
> Anyone can offer a bounty (i.e. money). You don't have to be a programmer to do > that. Not true. Unless there will be a developer who will actually say something like: "OK, I will do it for 200USD" a bounty will never work. There are several types of OpenSource developers and with the exception freelancers none of them will or can accept money for fixing a bug/implementing a feature. > It's a typical misconception among some users of open source software that > developers somehow owe you something. Of course they don't but once you have a product (OpenSource or not) there are certain quality levels that are expected. The problem with OpenSource is that OpenSource developers will rather spend 48 hour writing excuses why they can't implement feature ABC then implement it in 2 hours. > They do not. But it is well within your > power to offer incentives to developers in the form of money or something else > of value. Or, if you're a programmer, contribute a patch. ROFL, good joke :-D Probably never tried that did you? Btw. I'm an OpenSource developer, success rate of patches is pretty much zero once they actually do change something. I don't care because I have no problem with maintaining a fork.
i feel i have to start this: 20€ from me for the one - or shared among those - who realizes a working patch against trunk until the first of june 2010. everybody - join in and show whats it worth for you
El Martes 08 Diciembre 2009 17:58:54 Rob Hasselbaum escribió: > Anyone can offer a bounty (i.e. money). You don't have to be a programmer to do > that. > > It's a typical misconception among some users of open source software that > developers somehow owe you something. Donations received by many projects aren't grown from soil. And no, I understand these scarce donations can not be considered like hiring devs who receive them, so of course devs don't owe anything to users. But again, if they are trying to make a widely used desktop environment they should pay some attention to certain reasonable claims from real world users and not just statements form computer science students or even experienced programmers who affirm html mails are evil just because in their strait world text mails are enough. I think eyecandy and some not too important plasmoids can wait, and manpower be concentrated on important things like Nepomuk, Akonadi or making Kmail a serious emaill client which can be used in enterprise environments (and I'm sure companies would make better donations than private users... if apps were just useful); but I am not thinking developers owe it to me because I once donated some euros; it's just a feature most users who use mail for work think any modern mail composer should have.
20€ from me too
£50 from me, and £50 from my employer as matching funds, if Simon Bühler's bounty is achieved.
El Martes 08 Diciembre 2009 18:17:33 Simon Bühler escribió: > --- Comment #103 from Simon Bühler <simon aktionspotential de> 2009-12-08 18:17:28 --- > i feel i have to start this: > > 20€ from me for the one - or shared among those - who realizes a working patch > against trunk until the first of june 2010. > > everybody - join in and show whats it worth for you Haha, nice, Simon; but I don't think it works that way. You donate your money to a project and devs do whatever they want; you can't request determinate implementations, at least wasn't able when I donated. As Rob Hasselbaum has said, incentives are not contracts nor developers owe anything to users even if donated some money, and I think it's in general a correct attitude, if not software libre development would be a messy auction where best paid ideas would be the only to be developed, to the detriment of other important projects which aren't seen so atractive by the majority. Anyway, I don't want to look stingy, hehe. 20 € more from me for Kmail being able to efficaciousy reply in HTML and efficaciously compose HTML mails (I'm not sure this is a good practice, though).
Not to insult anyone, but this bounty-talk is silly. Money sure can speed-up an open-source project, but in this case the speed of development is not the problem. The problem is absence of ANY development. It has been 5 years since the feature was requested -- tons of features were added to KDE within that time, most of them for free. Because developers wanted to do them and the architects approved of them. This feature's trouble is with the subtle ideological resistance. Stefan Gehn's comment #14 is the rare explicit statement on the matter, but it is quite apparent, that other decision-makers feel similarly and may even consider one of their own, who finally implements it, to be a "sell-out". Our measly 20-200-1000 dollars/euros aren't going to change their minds very much -- the bug already has thousands of votes, so there is no question, they know, the users want it. Even if we collect enough pledges to hire a developer just for that, chances are, his work will not be accepted by the KDE-project under some pretext or another, and the separate patches would have to be maintained separately. The pretexts wouldn't be dishonest: every new feature violates existing balance in some way, so it has to add valuable functionality to justify it. Clearly, this feature is not perceived as beneficial -- nay, it is viewed as DETRIMENTAL -- and thus it will be sincerely rejected. I'd love for this opinion of mine to turn into a self-defeating prophecy, but -- after all these years -- I'm not particularly hopeful...
http://pledgie.com/campaigns/7325 I think that bounties are a good idea for this bug. Clearly doing nothing is not going to help the situation, and pledging money is a good way of showing that users care about the problem and are prepared to support patch. I started a pledgie campaign to allow people to formally pledge funds. Being unable to find anyone else to provide a paypal account to act as the recipient I have used my own, from which I will obviously pass funds on to whoever is decided to have succeeded in implementing a patch if indeed anyone does. See the link at the top for more info.
I said I didn't want to reply to this again, but oh well, I have to clarify something. I'd like to address comment 108, in which the author says things like "subtle ideological resistance", "decision-makers [..] may even consider one of their own, who finally implements it, to be a \"sell-out\"" and "it is viewed as DETRIMENTAL". This is simply not true. As I've said before in comment 64: I'd like better HTML support in KMail. In fact, I have worked on some minor stuff like inline images for HTML myself. I don't know any developer who is opposed to better HTML support. I know I'm repeating myself: We consider better HTML support good. The only reason it is not implemented is that I had no time to do that myself, so far, and no one else came up with a complete patch yet. Right now, I'm most busy with the Akonadi port of KMail, which does indeed have greater priority, there is a _lot_ to do to make KMail work properly with Akonadi. That said, the plan in the back of my head was always to refactor the template parser and then add HTML support to it. Maybe I can come to this during the Akonadi port at some point. Money certainly helps shifting the priorities :) But don't get your hopes up, it mainly depends on available time. Also, the composer wouldn't use the WebKit editor, that is too much work. Instead if would use QTextEdit, which means same HTML format preserving as Mailody has, nothing fancy. Porting the whole composer to a WebKit editor would really be much work. At this point, KMail is feature-frozen, so any new feature has to be developed in the Akonadi ports branch. KMail 2 (based on Akonadi) is expected/hoped to be released with KDE 4.5.
(In reply to comment #110) > I said I didn't want to reply to this again, but oh well, I have to clarify > something. --- Thanks, Thomas. I fully understand the time constraints and do appreciate the time spent on the issue by fellow developers. I am eagerly awaiting a solution - an embedded solution is KDE would be well received - no mater what branch it comes from.
(In reply to comment #110) > This is simply not true. As I've said before in comment 64: I'd like better > HTML support in KMail. I'm very glad to be wrong on this. > Also, the composer wouldn't use the WebKit editor, that is too much work. > Instead if would use QTextEdit, which means same HTML format preserving as > Mailody has, nothing fancy. The "nothing fancy" promise is disappointing. It is the 21st century, the minimal goal should be to allow e-mailing anything, that can be written, drawn, or painted on a piece of paper and stuffed into an envelope. An external attachment should not be required for anything, where a physical equivalent does not require a parcel-box, so to speak. No need for everything at once -- I'll be happy with gradual progress. But I'm wary of forswearing "fancy"... Thanks for listening.
Hey Thomas We all appreciate all your work for Kmail. I have just one problem with your priorities. Who has required porting Kmail to Akonadi? How much votes do you have for this and why is this higher priority than HTML support? It looks like you are building skyscraper on 5th avenue but people in Bronx still don't have roof on their houses. (In reply to comment #110) > I said I didn't want to reply to this again, but oh well, I have to clarify > something. > > I'd like to address comment 108, in which the author says things like "subtle > ideological resistance", "decision-makers [..] may even consider one of their > own, who finally implements it, to be a \"sell-out\"" and "it is viewed as > DETRIMENTAL". > > This is simply not true. As I've said before in comment 64: I'd like better > HTML support in KMail. In fact, I have worked on some minor stuff like inline > images for HTML myself. I don't know any developer who is opposed to better > HTML support. > > I know I'm repeating myself: We consider better HTML support good. The only > reason it is not implemented is that I had no time to do that myself, so far, > and no one else came up with a complete patch yet. > > Right now, I'm most busy with the Akonadi port of KMail, which does indeed have > greater priority, there is a _lot_ to do to make KMail work properly with > Akonadi. > > That said, the plan in the back of my head was always to refactor the template > parser and then add HTML support to it. Maybe I can come to this during the > Akonadi port at some point. Money certainly helps shifting the priorities :) > But don't get your hopes up, it mainly depends on available time. > > Also, the composer wouldn't use the WebKit editor, that is too much work. > Instead if would use QTextEdit, which means same HTML format preserving as > Mailody has, nothing fancy. Porting the whole composer to a WebKit editor would > really be much work. > > At this point, KMail is feature-frozen, so any new feature has to be developed > in the Akonadi ports branch. KMail 2 (based on Akonadi) is expected/hoped to be > released with KDE 4.5.
There are 2 things I perceive to be vital for KDE & Kontact/KMail in the enterprise: - editable HTML mail forwards & replies - ability to work as an Exchange client, with full support for mail, contacts, and appointments (IMAP only does mail, requires co-operation from the exchange admin to enable it, and Exchange contacts nor calendar work) (and frustratingly, my KMail IMAP sessions always get stale after a while) Exchange support relies on getting OpenChange ready (See http://www.kdedevelopers.org/node/4107 ) and getting it fully integrated in Akonadi which also isn't done yet. Kontact/KMail will support Exchange thanks to Akonadi, so getting KMail ready for that is certainly a task I wouldn't like to see Thomas or others others being pulled away from. What I think would make everybody happy: - If KMail could get HTML support with QTextEdit with reasonably little work, that would be *fantastic* if you ask me. "nothing fancy" sounds way better than "absolutely nothing at all" and then this wish/bug can be done away with. Fancy stuff isn't necessary, as long as what should work, works without tarnishing KMail's reputation by crashing or something like that - Next, the Akonadi skyscraper on 5th avenue without people on your back moaning about bug 86423 - Finally, once KMail/Akonadi is in "maintenance mode", who knows if there's now time for a WebKit composer? Personally, I always have too much stuff to do. Some things take a week, some take two months. But usually I have to multitask and as a result some tasks take years to complete. Had I taken a week out for task 1, I'd have enjoyed the fruits of that week while working on all the other stuff after that. Life just isn't sequential. In the end, it's all up to the devs. Thanks for all the effort put into this fine and promising platform.
I am the original reporter of this bug. It was reported back in 2004 - so I certainly can understand the frustration of those who like me, have wished and hoped for this "feature" to be implemented in Kmail. Regarding folks putting money toward getting the bug fixed: Well... here's the problem with that - prior to this bug being reported, I paid out of my own pocket to a developer to write a patch that would enable Kmail to even simply compose email in HTML. At the time, I was of the understanding that this would also allow replies to HTML email similar to how Evolution is able to. However, it did not - all it did was enable HTML composed email. But now I see there appears to even be a regression in that in that when there is a reason for me to compose email in HTML, it is not received correctly by other email readers. So for me personally, it is quite frustrating to have paid out of my own pocket for HTML ability, find out it is not quite what I expected, and then see it regress. I'm not a developer. I wish I was. But my other business efforts have supported KDE through donations over the years, on top of the feature I specifically paid for, so I believe I do not have to simply read some folks saying "Pay for it.. develop it yourself.. blah blah..." I have supported KDE for years - both through giving it publicity, recommending it to others, showing others how to use it - AND through my donations! So it is very disconcerting to read some folks replies to this, admonishing them to provide a patch, etc. Do you want us non-programmers to use the KDE desktop and associated apps or not? I for one won't be donating any more to KDE until this bug is corrected, and the self grandiose comments from some in regard to "Provide your own patch" cease. I can't provide a patch, but I HAVE done other things when I can, including throwing bucks and support to the KDE project. So please to those of you that keep asking for us non-programmers to provide a patch - give it a rest.
It is clear that by the time KMail gets proper HTML support - meaning *full* composing, replying and so on - it will have become irrelevant. Objectively, KMail is dead, even though it doesn't know it yet. It pains me to say it, because excepting the two major problems (HTML and IMAP), it is the best e-mail client I have used. May I suggest that instead of waging a lost battle, some serious effort is made to integrate Thunderbird better in KDE. KWallet, KGPG support and so on. That would be the constructive thing to do.
I must point out that in my (fairly extensive) experience with failed projects - they almost always prioritise technical integration over the user needs. So we will wind up having a fantastic integrated solution for very few people. Also, I agree that this resistance to HTML is partly (maybe wholly) driven by a geek purity meme; I think HTML is viewed as something nasty corporations use. After 3 or 4 years I am now investigating Zimbra and other clients. If I adopt that, I probably won't come back - integration or not. It is a great, great pity - and I feel great reluctance to do it. But I must move on.
I cannot agree more with the last comments from John and Tzvetan. We lost this battle and I believe we lost this war. It is not the problem that somebody compares me with a hungry chick who can only squawk but it is the whole attitude which is the base for the only logical conclusion: we are not important and never will be, we are just a burden. Most of the people here share a passionate support for KMail, Kontact etc. Some of us are also donators. But what are we facing here? Thank you Ian for sharing your experience with donations with us. The system of donations is clearly flawed. Who cares for Akonadi at this very moment? The system of priorities is clearly flawed, two. This project has unfortunately no future. I am sorry to admit that. It hurts and it also means a lot of work to migrate and switch to another solution but it seems unavoidable. I think the final curtain is down and behind it one can built whatever he wants we won't take care because it is not meant for us. Anyway, thank you for the past work.
hmm, with all these financial contributions, I might better spend my free time to get my old patch working ... On this world, you can buy (almost) everything with money. So I'm sure one can buy html reply support.
20 EUROS from me too. This feature would make a great difference to KDE. Its KDE's only KDE based mail client(mailody lacks some basic mail things like POP I think). KDE struggles with basics, such as web browser that can render all pages, html support in mail, decent network manager but excels in the advance things. If only KDE devs could try focus on more basic things KDE would excel further.
(In reply to comment #120) I can totally agree with this comment. KDE has a good concept, but it lacks some very basic features that make KDE hard to use sometimes. On the other side KDE introduces many features I could happily live without for some time. I know it's a question of priorities set by each developer, but why not to build a proper base for a house and then we can focus on furniture? If things move forward in a "short" time I will donate too.
(In reply to comment #119) > hmm, with all these financial contributions, I might better spend my free time > to get my old patch working ... > On this world, you can buy (almost) everything with money. So I'm sure one can > buy html reply support. Ok. So what's your price exactly, and will you provide updates as necessary? Perhaps there is enough of us that will donate to this to cover what you think it is worth to revisit your old patch and get it working.
It would be hard to hold individuals accountable for certain deliverables (not suggesting in any way that the end product would be anything less than outstanding) You could optionally try TheKompany http://www.thekompany.com/home/ They have done a lot of QT stuff, and I bought some apps from them for my Zaurus paperweight
(In reply to comment #110) > Also, the composer wouldn't use the WebKit editor, that is too much work. > Instead if would use QTextEdit, which means same HTML format preserving as > Mailody has, nothing fancy. Porting the whole composer to a WebKit editor > would really be much work. ... I have to disgaree with this approach. Like I said in many comments, QTextEdit is just *FAR* too limited to offer proper HTML support. I mean, we are talking about a widget that is basically almost 10 years old here, it has hardly changed since QT 3.0, how can it possibly be expected to compete with the editors of Thunderbird and Outlook, which use modern web browser rendering engines? The idea that it is "too much work" to move to Webkit for editing, is solely because of the horrible API design of the KMail composer - no other reason. I know this because I have tried to do this port myself. The Komposer API is a huge mess, none of it is properly abstracted - this is why it is nearly impossible to move outside of QTextEdit. The editor widget should have absolutely no knowledge or care about the widget that is being used for the editing. Spending any amount of time further working on adding features using the QTextEdit engine as a base, is a complete waste of effort IMO. If it was made a priority to do, Komposer could be re-done from scratch in a month or two, I have absolutely no doubt. It is really *NOT* that difficult a component to make - heck you can implement these Webkit based composers IN JAVASCRIPT in a couple of hours of work! Heck I could (and probably would) do it myself, if I thought my change would be approved and checked into SVN. But for some reason everyone on the KMail team is stuck in the past and insisting on QTextEdit instead of Webkit.
Jason, the final paragraph of your comment confirms my suspicions on this matter. Even if someone DID do this work, the idea of full HTML support in email will not get past the KMail "editorial board", for the reasons of principle mentioned before. So the whole donations thing is irrelevant.
Ah, a technical discussion now, that is much better :) Replying to Jason's comment 124 now. It is not true that the QTextEdit class didn't change since Qt 3.0. It got a major overwork for Qt 4, which includes the QTextDocument and QTextEdit separation, and much work on the layouting. It actually was completely rewritten and the framework is called Scribe. The HTML subset supported by QTextEdit can be found at http://doc.trolltech.com/4.6/richtext-html-subset.html. However, I agree that QTextEdit's HTML support is very limited when compared to WebKit, and having a full WebKit editor is better. What I'd like to see at the same time is porting the KMail reader from KHTML to WebKit as well, since loading two HTML rendering engines is too much (especially when running GDB). Regardless of having a WebKit based editor (which would be preferable) or a QTextEdit based one, the basic work needed to be done before that is still the same: Change the template parser to create multipart/alternative messages that include the original HTML when replying or forwarding. Once that is done, the HTML support is there. The composer already supports editing HTML messages, try right-clicking one and choosing "Edit Message". The issue is just that the template parser doesn't provide multipart/alternative messages when replying/forwarding (and that QTextEdit's HTML support is limited, of course). When I said a WebKit based composer is too much work, I meant it is too much work for _me_. That just means _I_ will not work on that, but I would be glad if somebody else does that. However, don't underestimate the work that needs to be done for this, QTextEdit and the derived classes have quite many features that need to be implemented in the WebKit based editor as well. Mostly little things like quote coloring, paste/drop support, spellchecking, many cursor-based operations, etc, but this adds up, and this is why I said it is too much work (for me). The normal non-HTML editing features in the WebKit-based editor need to be as good as they are currently. I am pretty sure this can not just be done "in a couple of hours of work". > The idea that it is "too much work" to move to Webkit for editing, is solely > because of the horrible API design of the KMail composer - no other reason. I > know this because I have tried to do this port myself. The Komposer API is a > huge mess, none of it is properly abstracted - this is why it is nearly > impossible to move outside of QTextEdit. Hmm, I wouldn't say the composer has horrible API design that makes moving to a WebKit-based editor much of a problem. True, KMComposeWin is a big scary class, but the actual editor is in a separate class, KMComposerEditor, which (indirectly) inherits from QTextEdit. Could be that it was worse in KDE3 times, I remember some nasty "KEdit" classes there. One last thing I want to add: If anybody wants to work on this, please do it in the akonadi-ports branch (branches/work/akonadi-ports), which has the KMail that will become KMail 2. KMail 1 from trunk is basically frozen for new features at this point. > Who cares for Akonadi at this very moment? I do. Akonadi will solve many of the old standing KMail problems like flaky online IMAP support, blocking GUI while filtering POP3 mails (yes, that bug has even more votes than this bug here, just not as many noisy comments), various storage-related crashes, index corruption problems, and many others. > But for some reason everyone on the KMail team is stuck in the past and > insisting on QTextEdit instead of Webkit. > Even if someone DID do this work, the idea of full HTML support in > email will not get past the KMail "editorial board" I really don't know where you get these ideas. I only said it is too much work, which I have clarified above. So again, for the last time: Nobody in the KMail team is against improved HTML support. There is no secret conspiracy going on to keep HTML support out of KMail. I'd personally love to see full HTML support in KMail 2. Together with the improved IMAP support, better searching/tagging and lots of other stuff that Akonadi provides, it will make KMail rock! Bah, I wanted to keep away from this bug report, but now I've found myself commenting here again...
Given these new comments, maybe I will try to investigate further doing some of this work over the holiday break and into the first quarter.
Hi all. I'm glad to see this bug report is active again. I love KDE, I try to use a KDE application for everything I can. I'm the only one using KMail in my work, everybody else is using TBird, and I'm very tired of my partners complaining about I break every thread I reply to with "My email client" :-) So, for a KDE lover like me, it is a lot easier to help improving KMail than replacing it with another application. You can count me in for helping in whatever you think I can help. I'm an Eclipse RCP developer, but it's time to dig up the C++ developer inside and start contributing to the platform I love. Gaston.
*** Bug 185594 has been marked as a duplicate of this bug. ***
Qt 4.5! QWebkit has now updated editing features, making it into the rich text editor we want. We can do the following: 1.: Add an selection option which editor you want: Katepart for plain text reply (for people like the author of comment 15), QWebkit+Katepart for perfectionist’s HTML reply (like thunderbird) or only QWebkit for HTML reply of those not able or willing to code HTML (like gmail). 2.: If option 1 is set, the reply will be the classic “> cited message [lienebreak] your plain text message” 3.: If option 2 is set, the reply-window will have 2 Tabs: [Rich text] (using QWebkit) and [HTML source] (using Katepart). The cited message (=the innerHTML of the body of the message you reply to) will be wrapped into a <blockquote class="old-mail"> tag styled to have a colored (or grey) border on the left (right for arabic & co). When you switch to the [HTML source] tab, the innerHTML of the <body> of your mail will be available for direct edit. When you swich back to the [Rich text] tab, the innerHTML of the <body> will be updated. piece of cake PS: i will prototype it in python, since i can’t code cpp PPS: this comment would be more lucid if formatted with HTML ;)
sorry for spamming, but of course i meant we should add the only-plain-text-kthxbye option for people like the author of _comment 14_, instead of his critic and selecting the third of my proposed options would delete the two tabs and only make the rich-text-editor available here a video of the features of the wysiwyg-text editor features of QWebkit: http://labs.qt.nokia.com/blogs/2009/03/12/wysiwyg-html-editor/
OK, so it seems hat we have Akonadi implemented - 4.4.3. Can we start with HTML engine finally?
FYI: This same bug has finally been fixed in Thunderbird, so kmail appears to be the last holdout.
I wouldn't compare Kmail's HTML possibilities with Thuderbird because it's same as comparing Khtml and Firefox.
(In reply to comment #134) > I wouldn't compare Kmail's HTML possibilities with Thuderbird because it's same > as comparing Khtml and Firefox. Right, there should not be comparison, but there can be "healthy" competition. J
This is really holding me back from using this great email client.
I've already switched to Thunderbird because this is never going to be in Kmail. Just imagine there is demand at least for 5 years and nothing changed. Deep regret to Kmail.
I've given up as well, running Outlook under wine. what a pity
Guys don't give up. I still have hope. One day this feature will definitely be implemented and that time it'll be the best choice for email client.
On Thu, 26 Aug 2010 07:09:07 pm Ruchir Brahmbhatt wrote: > Guys don't give up. I still have hope. One day this feature will definitely be > implemented and that time it'll be the best choice for email client. Sorry, this is never going to be done. A recent thread at kdepim-users@kde.org produced the usual arguments that it was evil, should never be allowed, highly dangerous etc (but with no statistics of course). More importantly, an attempt to get people to offer $100 or so to fund the change only got three offers. The devs then sent a message that not one of them was interested in doing it - no doubt influenced by all the merchants of doom. So, if you need this in your lifetime - go and find an email client that will support it. KMail won't - so probably won't last anyway. Shame - but there you are. Regards, johnM
I too believe now that Kmail will, sadly, never have this feature. I suspect that it's been losing users in large numbers because of this failing, which also makes working on it less attractive. But the biggest threat is online mail services like Google Mail. I confess I started to use Gmail when frustration with the Kmail thing got too much. I now can do all the things i coudn't with Kmail, and more significantly, I can access my mail - including full mail archive - everywhere (including on my mobile phone), whereas before I had to be at home to search old emails. I think, for private users at least, that the future for local mail clients is gloomy.
If it's not going to be fixed, why then some god-developer (we are sooo thankful to them for being so concerned of our security) descends from its own olympus and mark this bug as WONTFIX? (In reply to comment #140) > On Thu, 26 Aug 2010 07:09:07 pm Ruchir Brahmbhatt wrote: > > Guys don't give up. I still have hope. One day this feature will definitely be > > implemented and that time it'll be the best choice for email client. > Sorry, this is never going to be done. > A recent thread at kdepim-users@kde.org produced the usual arguments that it > was evil, should never be allowed, highly dangerous etc (but with no statistics > of course). > More importantly, an attempt to get people to offer $100 or so to fund the > change only got three offers. > The devs then sent a message that not one of them was interested in doing it - > no doubt influenced by all the merchants of doom. > So, if you need this in your lifetime - go and find an email client that will > support it. > KMail won't - so probably won't last anyway. > Shame - but there you are. > Regards, > johnM
I'm afraid I've given up too. Been using kmail since 2004 and the lack of this feature stops me working effectively with all the Outlook users in my company. Bit of a joke since it's obviously in demand. I don't buy the security excuse BS, other clients pull off this feature no problem with default hiding of images/remote assets. Anyway, I now have a linux desktop at work, and a windows laptop - just for Outlook.
I've switched to thunderbird couple of days ago. Running on qt-curve I'm quite happy with it. The decision came since I cannot start Kmail due to failed Akonadi after KDE upgrade. In my opinion, Akonadi is impossible to troubleshoot for normal users, well, maybe it is, but I've lost last remains of patience with it. I'm afraid kmail is gonna lose huge portion of users because of Akonadi and HTML stuff. I wish good luck to developers in making the application better, it deserves it.
Thunderbird fixed this exact same bug very recently. So, that may be a good alternative for many of us.
On Thu, 2010-08-26 at 11:26 +0200, John Murphy wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 > > > > > > --- Comment #140 from John Murphy <murphyjj bigpond net au> 2010-08-26 11:26:46 --- > On Thu, 26 Aug 2010 07:09:07 pm Ruchir Brahmbhatt wrote: > > Guys don't give up. I still have hope. One day this feature will definitely be > > implemented and that time it'll be the best choice for email client. > Sorry, this is never going to be done. > A recent thread at kdepim-users@kde.org produced the usual arguments that it > was evil, should never be allowed, highly dangerous etc (but with no statistics > of course). > More importantly, an attempt to get people to offer $100 or so to fund the > change only got three offers. > The devs then sent a message that not one of them was interested in doing it - > no doubt influenced by all the merchants of doom. > So, if you need this in your lifetime - go and find an email client that will > support it. > KMail won't - so probably won't last anyway. > Shame - but there you are. > Regards, > johnM > That's interesting. We just paid a bounty many, many times that size to fix all kinds of other issues in Kontact for Zimbra interoperability including implementing CardDAV, CalDAV, fixing the time zone issues, piles of fixes. This was all done by the Trinity project which is maintaining and fixing KDE3 for those who feel KDE4 is not quite ready or have other reasons not to upgrade (http://trinity.pearsoncomputing.net). We would be interested in supporting an effort to fix this in Trinity. I would hope with a working implementation in KDE3, it would be trivial to port to KDE4 along with CardDAV and CalDAV. Is anyone interested in chipping in with us?
I don't have very deep pockets. But I am willing to add $40 to the pot if *anyone* would show *any* interest in actually accomplishing this. I know my contribution by itself amounts to just about nothing but if I and 50 others did the same it could add up fairly quickly. The trouble is, I just don't believe that those who develop kmail are really interested in doing this. I have waited too long with no hope in sight. This "bug" has almost 2,500 votes which says to me it is something highly desired by the community. I do not believe that the developers are not skilled enough to do it. I am daily in awe of their skills. I just think they don't *want* to do it and so it is likely to never get done. While this disappoints me I must say that this is the world we have opted into. In an open source, volunteer driven development environment, those of us who are not developers must hope that our desires are shared by those that do develop. When they are not, we must seek solutions elsewhere, Kmail has potential to operate in a corporate environment. Until it grows up it will be relegated to the microcosmic world of the hobbyist. Perhaps the audience for this program *is* the hobbyist and it is *I* who am in the wrong place with wrong expectations. Either way, I want this and am willing to support it to the best of my financial abilities. It is admittedly not much in the scheme of things but with friends it could be. If there were only interest...
I am missing this feature, too. And I would happily join with my $40 as well if there was a chance it would change something.
me too
Last time, it was april when I picked up this issue again. Compiling the kde modules was impossible to me then because my system crashed because of it (https://bugzilla.redhat.com/show_bug.cgi?id=580208). When I find the time, I'll install a new fedora and give it another try.
On Fri, 2010-08-27 at 10:59 +0200, Jakub Benda wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 > > > Jakub Benda <albandil@atlas.cz> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |albandil@atlas.cz > > > > > --- Comment #148 from Jakub Benda <albandil atlas cz> 2010-08-27 10:59:19 --- > I am missing this feature, too. And I would happily join with my $40 as well if > there was a chance it would change something. > I have asked Tim Pearson of the Trinity project (http://trinity.pearsoncomputing.net) if he is interested in doing this work and how much it would cost. I've not yet heard back from him - John
My $40 are also on the table. I do not want to enter into the debate about the merits and perils of using HTML in emails, nor do I know much about its security issues. I can live without HTML reply enabled in Kmail, but some recipients expect my replies in this format. Even developers who do not like HTML in messages might have an interest in seing this feature implemented, as this would make Kmail more attractive for end-users thus increasing usage and popularity of the mail programme. Why not setting no HTML as default and giving notice to users who activate the feature? I have read someplace that te current version of Thunderbird has found a solution to the security problems, so that seems possible after all.
I paid for the original HTML capabilities some years ago, to be implemented. As I've written previously, I'm willing to "donate" toward getting this bug resolved and will commit $40.00 as well. Problem I have though is that I had expected based on my understanding on what I was paying for originally, was that this bug wouldn't have even been necessary.
My opinions about HTML mail have mostly been posted by others here, so I won't add to them, but I'd love to contribute to a bounty to fix this, as it's the main thing keeping me from exclusively using this otherwise excellent email client when I'm on Linux. So, here's another $40, if we can get something official set up.
On Sun, 2010-08-29 at 00:29 +0200, Pete wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 > > > Pete <particlese@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |particlese@gmail.com > > > > > --- Comment #154 from Pete <particlese gmail com> 2010-08-29 00:29:00 --- > My opinions about HTML mail have mostly been posted by others here, so I won't > add to them, but I'd love to contribute to a bounty to fix this, as it's the > main thing keeping me from exclusively using this otherwise excellent email > client when I'm on Linux. > So, here's another $40, if we can get something official set up. > I have a bounty price from Tim Pearson and it is fairly high because of the need to create a new widget. I've asked him to review the bug report and take a look at the various suggestions and options to see if it will reduce the cost. I'll post the price when I have final word from him - John
Even if it is actually implemented will the developers accept it? Implementing a patch is pretty much useless unless the upstream is willing to accept it. The willingness seems to be the main issue here.
On Sun, 2010-08-29 at 02:03 +0200, Simon Toth wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 > > > > > > --- Comment #156 from Simon Toth <Happy Cerberus gmail com> 2010-08-29 02:03:40 --- > Even if it is actually implemented will the developers accept it? Implementing > a patch is pretty much useless unless the upstream is willing to accept it. > > The willingness seems to be the main issue here. > Trinity is its own version of the KDE3 desktop since KDE3 is no longer being maintained so it will have no problem going in there. KDE4 will be another matter. The devs have said they have no objection just no time. Several times, they have suggested that someone write a patch. I do hope if someone takes the time and others provide the funds, that the devs will gladly accept the contribution they themselves suggested someone make! - John
On Sun, 2010-08-29 at 02:03 +0200, Simon Toth wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 Well we have a bounty amount and a bounty hunter. Tim Pearson of the Trinity project (http://trinity.pearsoncomputing.net) has said he would do the work for $1500 (US). When I asked if he could review the bug report and see if the information would help trim the cost, he replied: "I was already aware of the bug report you linked to, and I consider the fact that KMail 4 is *still* missing this feature as a rather bad omen. I am concerned a large rewrite of the editor is in order, and after this CalDAV/CardDAV project I don't have much confidence in the ease of extension of any part of kdepim. Hopefully enough people are still interested to get the project started!" I can verify his concerns. The bounty we posted for Zimbra integration including CalDAV/CardDAV was originally $300. We voluntarily increased that to almost as large as this bounty and I'm sure Tim's time was worth much more than we paid (and, no, we are not making it up together on this job - Tim and I have no financial or business connection other than I paid a large bounty to him for Kontact/Zimbra integration patches). So now we have a few practical details to make this happen. First, we need a rough spec for the work. Is it as simple as: "The final patch will enable KMail running in KDE4 and the Trinity version of KDE3 to reply to HTML email in HTML format including editing in HTML format by simply choosing to reply when the email which is being replied to is displayed in HTML mode. If the email is being displayed in text, the reply will initially be in text but with an option to edit and send the reply as HTML. Patches to KDE4 will be submitted upstream." Or do we need something more specific including HTML standards, which html tags should be supported, something about css support, etc? Would someone care to write it? I am no HTML expert. We then need to coordinate the bounty until the pledges (no money sent) equal at least $1500. I would be willing to do that. You can send your pledge amounts to me at jsullivan (we'll break this up) at (to thwart the spammers) pacifera (I'm sure you know) dot (what to do) com. I've suggested to Tim that payment be in thirds - one third before work begins, one third when the first patch is delivered, one third on final sign-off (bugs fixed). Tim is comfortable with this. Coming to consensus on sign-off can be a bit tricky. I would hope we will all be civil and fair. The tricky part is actually transferring the money. I have a vested financial interest in this patch as we would like it for our clients. I have also worked with Tim before so he knows I pay the bills in good faith and he is comfortable with me functioning as the fund coordinator. If others are not, I quite understand but someone needs to do it. Tim is uncomfortable with people sending money to him directly because he is concerned about deadbeats not paying the final third. He also thinks it unfair for him to collect all they money up front as that is a lot of trust to place in an unknown entity. That's why he prefers the funds be escrowed by a third party with a financial interest in the final patch. We also need to account for those who do not make good on their pledges. I will pledge $100. I will also pledge to make up any shortfall for up to another $100. I would suggest we pull the trigger when the pledge amount hits $1600. If we only collect $1400 of it, I'll make up the $100 difference. If we hit $1500, we'll pay that. If we collect the full $1600, we'll pay that all to Tim as an extra thank you for his work. Thoughts? Comments? Insults? - John
(In reply to comment #158) > > Thoughts? Comments? Insults? - John How about appreciation? Is it possible to get a page on the KDE or Trinity site where we could make our pledges, have them publicly listed (anonymously or not) along with a progress report on how we are doing? The link could be added to this bug and promoted. Seems like a very achievable goal. I am more than willing to trust you to escrow the funds. I am a trusting fellow and besides, I believe your online reputation is worth more than $1,500. That and if I lose my $40, I will be ticked-off but not devastated. I also trust that you have chosen wisely in selecting a programmer to implement this. The statement of work is both broad and specific enough to meet my need and give him some latitude in implementation. My only comment here is that he may have underestimated the required effort. It is hard to be optimistic after having waited for so long... but what is that I see... There, at the end of the tunnel... is that a light?
I also think a more formal way of making pledges would be good. Since I'm not accustomed to this method of donation, it would certainly make me more comfortable with making the pledge (though I remain committed either way), and being able to see the progress towards an actual quoted bounty may encourage more people to sign up. Along the same lines, how will the real transactions be made? Also, thank you very much for organizing this, John!
On Mon, 2010-08-30 at 06:20 +0200, Pete wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 > I've forwarded Paul Lemmon's email to Tim to see what he has to say. It seems quite reasonable. I had planned to keep the pledge amounts in a spreadsheet with names, amounts, email addresses, etc. I could privately communicate with the individuals about bank details for checks or transfers. I was planning to regularly update this bug with the tally. I suspect it will take a while. At $40 a piece, we'll need 40 sponsors. I certainly don't mind a more formal structure but also have no experience in doing this. I had set up the Open Source Development Corp. (www.opensourcedevel.com) many years ago to do just this sort of thing but it did not gain traction and I closed the bank account long ago. If anyone has specific suggestions for a more formal structure, I'm certainly interested to hear them as long as they do not impose an inordinate overhead as my company is in startup mode and time is in very short supply. Thanks - John
How about using chipin.com.
You can count me in for 50 on this - my only worry is what has already been noted: if it works in Trinity/KDE3 and can be shown to work in KDE4, will it be included in next KDE4 kde-pim release? To get this included in the coming "transfer to akonadi"-release would be perfect
On Mon, 2010-08-30 at 09:13 +0200, Ruchir Brahmbhatt wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 > > > > > > --- Comment #162 from Ruchir Brahmbhatt <ruchir brahmbhatt ecosmob com> 2010-08-30 09:13:26 --- > How about using chipin.com. > That looks very interesting. I suppose they make their money by holding on to ours until the goal is reached or expired. I did read the terms of use and privacy policy and a quick Internet search turned up no complaints. I'm not sure the benefits in our case are worth the limitations. The contributions can only be made via PayPal or credit/debit cards and, in the latter case, only from the United States. It does not remove the trust issue in that the funds eventually wind up in my PayPal account anyway. However, it does require that we send the funds in up front. They hold on to them until we reach the goal amount or the date expires. If the date expires without meeting the amount, the funds are returned to the contributors. Given that it may take quite a while to reach the amount, they could be sitting on our contributions for months. I was not planning to take any money up front. I was anticipating logging pledges and, when we had the pledge amount, then collecting funds via any source including checks and bank transfers. As I think about it, I do not have credit card facilities. I suppose that could be set up through PayPal. Thoughts? Comments? Insults? Thanks - John
Taking money up front eliminates the worry about people not following through on their pledges. And have an online widget like chipin (which I was about to suggest as well) makes it easier for everyone to keep track of and also possibly extends the reach beyond this email list. On 08/30/2010 11:06 AM, John A. Sullivan III wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 > > > > > > --- Comment #164 from John A. Sullivan III<jsullivan opensourcedevel com> 2010-08-30 10:05:42 --- > On Mon, 2010-08-30 at 09:13 +0200, Ruchir Brahmbhatt wrote: > >> https://bugs.kde.org/show_bug.cgi?id=86423 >> >> >> >> >> >> --- Comment #162 from Ruchir Brahmbhatt<ruchir brahmbhatt ecosmob com> 2010-08-30 09:13:26 --- >> How about using chipin.com. >> >> > That looks very interesting. I suppose they make their money by holding > on to ours until the goal is reached or expired. I did read the terms > of use and privacy policy and a quick Internet search turned up no > complaints. > > I'm not sure the benefits in our case are worth the limitations. The > contributions can only be made via PayPal or credit/debit cards and, in > the latter case, only from the United States. It does not remove the > trust issue in that the funds eventually wind up in my PayPal account > anyway. However, it does require that we send the funds in up front. > They hold on to them until we reach the goal amount or the date expires. > If the date expires without meeting the amount, the funds are returned > to the contributors. Given that it may take quite a while to reach the > amount, they could be sitting on our contributions for months. > > I was not planning to take any money up front. I was anticipating > logging pledges and, when we had the pledge amount, then collecting > funds via any source including checks and bank transfers. As I think > about it, I do not have credit card facilities. I suppose that could be > set up through PayPal. > > Thoughts? Comments? Insults? Thanks - John > >
Some time ago there was a "pledgie" for Krita which was highly successful: http://krita.org/index.php&option=com_content&id=20 http://pledgie.com/campaigns/7221 IIRC the money was collected up front, something I'd have more faith in as well. A Paypal account was used. Greetings, Pascal
On Mon, 2010-08-30 at 11:27 +0200, Jay wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 > I've left the previous comments in place to make this specific discussion a little easier to follow. I'll bottom post the response below - John > > > > > --- Comment #165 from Jay <cassano jay gmail com> 2010-08-30 11:26:53 --- > Taking money up front eliminates the worry about people not following > through on their pledges. And have an online widget like chipin (which I > was about to suggest as well) makes it easier for everyone to keep track > of and also possibly extends the reach beyond this email list. > > On 08/30/2010 11:06 AM, John A. Sullivan III wrote: > > https://bugs.kde.org/show_bug.cgi?id=86423 > > > > > > > > > > > > --- Comment #164 from John A. Sullivan III<jsullivan opensourcedevel com> 2010-08-30 10:05:42 --- > > On Mon, 2010-08-30 at 09:13 +0200, Ruchir Brahmbhatt wrote: > > > >> https://bugs.kde.org/show_bug.cgi?id=86423 > >> > >> > >> > >> > >> > >> --- Comment #162 from Ruchir Brahmbhatt<ruchir brahmbhatt ecosmob com> 2010-08-30 09:13:26 --- > >> How about using chipin.com. > >> > >> > > That looks very interesting. I suppose they make their money by holding > > on to ours until the goal is reached or expired. I did read the terms > > of use and privacy policy and a quick Internet search turned up no > > complaints. > > > > I'm not sure the benefits in our case are worth the limitations. The > > contributions can only be made via PayPal or credit/debit cards and, in > > the latter case, only from the United States. It does not remove the > > trust issue in that the funds eventually wind up in my PayPal account > > anyway. However, it does require that we send the funds in up front. > > They hold on to them until we reach the goal amount or the date expires. > > If the date expires without meeting the amount, the funds are returned > > to the contributors. Given that it may take quite a while to reach the > > amount, they could be sitting on our contributions for months. > > > > I was not planning to take any money up front. I was anticipating > > logging pledges and, when we had the pledge amount, then collecting > > funds via any source including checks and bank transfers. As I think > > about it, I do not have credit card facilities. I suppose that could be > > set up through PayPal. > > > > Thoughts? Comments? Insults? Thanks - John > > > > > That's two people who have suggested Chipin and three who have said they prefer to pay upfront. Given that, I'm prepared to go that route. Does anyone object? Here are my concerns about the Chipin approach: 1) It will only accept PayPal outside the US/Canada? Is that a problem for anyone? 2) It will only accept PayPal and credit/debit cards inside the US/Canada. Is that a problem for anyone? 3) It will tie up our money immediately - I agree that may actually be a good thing rather than bad. If I do not hear any objections in the next 24 hours, I'll proceed with Chipin. To be fully disclosing, I do not have a PayPal account for the main business, Pacifera, and I closed the bank account for Open Source Development Corp. ages ago so I will set it up to be paid to a small charitable site I had set up with PayPal for www.spiritualoutreach.com. Thanks - John
If googled arround and also found: http://www.kickstarter.com http://pledgie.com pledgebank.org About the work to be done itself, it might be wise to check if the affected parts have been rewritten during KDE3 -> KDE4 transition. If this is the case, it might be difficult und need more time, to patch both.
Being just a silent voter until now, I would like to just make this one comment because I feel it is important but overlooked. Having sw development experience myself, there is one aspect that shouldn't be forgotten, and that is the quality of the proposed solution. Care needs to be taken for this work to be made maintainable, extensible and portable. Unfortunately, one prevailing theme I noticed from all the development-oriented comments is that this feature is very hard to add due to KMail 1.x architecture. I'm afraid that if this work ends up providing HTML quote/compose support to KMail 1.x, it will not be easily applicable to 2.x. I suggest that an additional requirement be made to the bounty, something in the lines of: "The implemented feature should be based on an externally maintained editor component, and provide documented interfaces for inclusion into other software. The documentation should also include a context diagram illustrating outside interfaces and internal class/component relations. Finally, at least one example (a simple step-by-step guide without actual implementation) on how to add new capabilities to the solution should be included". I feel this will guarantee that the work done now will be usable for years to come and easily extensible, while I'm also aware that it might considerably raise the valuation and give more headaches to Tim, or whomever else that decides to take up the bounty. Even if this final valuation ends up being twice or 3x the amount of the initial one, believe me it would not be unrealistic and would be worth it. That said, if you add the requirement to the bounty along the lines I suggested above, I'm willing to support this effort with US$50 initially, and another US$50 if the bounty pot ends up being short of the requested amount, and I'm willing to reserve the initial amount upfront through chipin (via PayPal).
On Tue, 2010-08-31 at 08:12 +0200, Tin Blaskovic wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 > <snip> Sorry to take so long to get back to this. Several of you have emailed me privately as requested to pledge toward the bounty. Here is where we stand. Tim is subscribing to the bug so he can respond directly. I'm not sure if he has done that yet. Tim has suggested that we finalize the spec before starting to collect pledges in case something in the spec has a significant impact on the bounty. He has set up a page to record the spec as well as the pledges at http://trinity.pearsoncomputing.net/ - click on Requests for Enhancement. Speaking of impacting the bounty, Tim's environment is specifically KDE3 as Trinity is a maintained fork of KDE3. He does not have a KDE4 build environment and building one just for this project would add significantly to the cost. Does anyone have a KDE4 build environment that could be used for this project? Regarding forward usability, Tim proposed the following design which, in my programming ignorance, would seem to facilitate forward compatibility: "My initial thought was to create a widget that accepts HTML input from the parent program, allows the user to edit the HTML/insert images/etc., then outputs the edited HTML to the parent program. It would probably also have to pass some (QImage?) pointers to any inline image files via a QPtrList or similar to the parent program. This should ensure that the KMail changes needed are trivial, with most of the code contained within the new editor widget. I was planning to include some doxygen commenting in the external API of the new widget" Once the spec is finalized, we can use Chipin to collect the pledges. Thanks - John
I wish I was be able to formulate more specific requirements, it would certainly be the fairest towards Tim or any other developer that takes up the challenge. Since my primary interest in supporting this effort would be to see the functionality getting included in future KDE4+ releases, I suppose the only ones that are qualified enough to pass judgment on that are core kmail developers who know the direction that kmail is headed, and whatever they conclude I would agree on. Therefore (and please keep in mind this only affects my pledge, others decide for themselves but I believe that these suggestions are to the benefit of everyone), I can propose only the following criteria for the specification (as specific as I can make them): 1. the component must be able to fully preserve original/quoted message formatting and content on output 2. the component should allow for basic text input and formatting (i.e. font, size, color, decoration) and image insertion, both in quoted text and in reply text 3. the component should be accepted into current kmail source tree and made available through official kdepim releases A question for Tim - are you planning on using webkit editor (already mentioned several times in this discussion) or do you plan to write your own? IMHO, it should be easier to use an already existing component. Also, doxygen comments are always useful, but a short techbase page would also be very welcome for others who decide to continue the work on the component.
On Mon, 2010-09-06 at 15:14 +0200, Tin Blaskovic wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 > > > > > > --- Comment #171 from Tin Blaskovic <tin blaskovic gmail com> 2010-09-06 15:13:59 --- > I wish I was be able to formulate more specific requirements, it would > certainly be the fairest towards Tim or any other developer that takes up the > challenge. Since my primary interest in supporting this effort would be to see > the functionality getting included in future KDE4+ releases, I suppose the only > ones that are qualified enough to pass judgment on that are core kmail > developers who know the direction that kmail is headed, and whatever they > conclude I would agree on. One of the original maintainers has volunteered to be an information resource for the work. I hope that indicates the KDE devs are supporting of the endeavor. <snip> > 3. the component should be accepted into current kmail source tree and made > available through official kdepim releases I think this one is going to be outside of our control. I think it would behoove us to seek guidance and guidelines to do the best we can to make it acceptable. <snip>
If it means anything, I am the original reporter of this bug. Previous to reporting this bug, I had complaints about the total lack of HTML ability in Kmail - I have clients who use HTML as their way of using bold or colours in replies instead of the standard > and >> and >>>'s. It was frustrating to me that I could not reply to an email in the same way a client had responded to mine. I brought up the issue and someone emailed me privately and asked if I was willing to pay for HTML ability in Kmail. They quoted me a price, and I paid for it. And then, HTML was available in Kmail - except it was useless because it did not work for replies to HTML email. So, I'm leery. I'm willing to contribute money - as I have for HTML ability in the first place and to other KDE development in general - but - if I'm going to do it again, it has to work. It has to work going forward too. I'm willing to contribute - but I need to hear from a lead developer that there is going to be cooperation - that further development on Kmail will absolutely include any HTML abilities that I'm paying for. What I paid for several years ago is now broken even more than what I thought I was paying for. I'm not paying for something again, that I have no reassurances will not break again in the future. The spec has to say that the KDE developvers will view the patch as important, and future development will include this patch, and not break it, or will fix it to comply with any future releases so that it is a standard in Kmail. They can't just introduce some new feature or change, and break this patch and go "uh oh.... oh well..." If we can get some idea from a lead KDE developer that this is important to them, and a committment that if done, it will remain an important integral part, then I will commit some bucks to this.
On Mon, 2010-09-06 at 18:28 +0200, Ian wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 I've just heard back from Tim. He has not yet subscribed to this bug as he is swamped getting Trinity (KDE) 3.5.12 out the door. He said he will need to wait until early next month. In the meantime, I think it would be wise for anyone with input to contribute to the spec page he put up. I referenced it a couple of comments ago - John
(In reply to comment #173) > So, I'm leery. I'm willing to contribute money - as I have for HTML ability in > the first place and to other KDE development in general - but - if I'm going to > do it again, it has to work. It has to work going forward too. Those who really wish this to happen could enter an official contract with KDAB. After all, it's among their businesses to develop Kontact for enterprise customers and they pretty much maintain KMail these days.
On Thu, 2010-09-30 at 11:01 +0200, Markus S. wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 > > > > > > --- Comment #175 from Markus S. <markus s kdemail net> 2010-09-30 11:00:11 --- > (In reply to comment #173) > > > So, I'm leery. I'm willing to contribute money - as I have for HTML ability in > > the first place and to other KDE development in general - but - if I'm going to > > do it again, it has to work. It has to work going forward too. > > Those who really wish this to happen could enter an official contract with > KDAB. After all, it's among their businesses to develop Kontact for enterprise > customers and they pretty much maintain KMail these days. > Trinity 3.5.12 should be released tomorrow. That means they can now turn their attention to this project and we can get it started in earnest - John
Hi, Tim Pearson here from the Trinity project as promised. I have added a page at this address http://trinity.pearsoncomputing.net/crfe/ in order to be able to iron out the required specifications, and to track the progress on these two RFEs. I have decided to split the entire KMail HTML project into two parts. The first would be to get full HTML support functional in the Trinity project, as that is the environment that I am most familiar with, and there are a significant number of corporate users of that environment. This would use Webkit; a full proposed specification is available on the page previously mentioned. The second phase would be to port those changes to KDE4 and get it accepted upstream. When the first phase is built, cross-toolkit compatibility will be kept in mind so that KDE4 can use the code from that phase without heavy modifications. The threshold bounty amounts currently shown on that page will fluctuate as requirements are added or removed; if you want to see it done for less cost then remove some of the requirements from the specification(s). I have left the KDE4 specification almost empty; I would like individuals who are more familiar with the KDE4 development process and cycle to list any requirements and/or barriers to getting the new editor accepted into upstream. Let me know what you think!
On Mon, 2010-10-04 at 19:33 +0200, Timothy Pearson wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 <snip> Hi, Tim. You can count me in on the Trinity bounty for $100. Are you still looking for someone with a KDE4 build environment to help on the KDE4 portion? I don't have such an environment but perhaps another interested party does. Thanks - John
I was expecting to see a reference to the www.chipin.com site where I could make my contribution. Have we abandoned that line of thought?
I guess that would be up for discussion still; any thoughts John?
On Mon, 2010-10-04 at 23:22 +0200, Paul Lemmons wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 > > <snip> That's still in the plan as far as I know. I'll be hopping back into this to help Tim organize the bounty now that he is ready. However, I think the first step is to finalize the spec as it can have a dramatic affect on the final bounty size. Once we have a solid spec and bounty, we can set up chipin. Thanks - John
Works for me!
And count me in for $50 for the KDE3 Trinity bounty. The kdesvn-build script (now kdesrc-build) made it really easy for me to fiddle around with and compile modifications to a KDE4 game. (At least under an existing user-geared KDE4 environment.) I don't know if it will suit your needs for the phase 1 portability considerations or even phase 2, but it may be worth a look. Here's its homepage: http://kdesvn-build.kde.org/ Thanks for doing this, or at least giving it the chance to be funded. -Pete
On Fri, 2010-10-08 at 04:47 +0200, Pete wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 <snip> I've noticed that there has been very little activity on the specification. At some point, I would imagine we will need to close the spec and begin collecting pledges on chipin. If you are interested, please visit http://trinity.pearsoncomputing.net and click on the RFE link on the left panel (if the left panel does not paint properly, please for a refresh as it may be incorrectly cached). The page contains instructions for signing up for an account with rights to edit the spec. Thanks - John
Looks like the specs are locked and loaded... when do we pull the trigger?
On Fri, 2010-10-22 at 18:49 +0200, Paul Lemmons wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 <snip> I'm awaiting the final word from Tim - John
As the specification is now finalized, the KDE3/Trinity bounty amount on this page http://trinity.pearsoncomputing.net/crfe/ is now finalized as well. Let's see how much can actually be collected, and if it comes up short then we can discuss what to trim from the specification for now. As mentioned before, I am considering completion of the KDE3/Trinity version as a prerequisite for the KDE4 version; as such, the KDE4 specification has NOT been finalized and is still open.
On Fri, 2010-10-22 at 19:28 +0200, Timothy Pearson wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 > > > > > > --- Comment #187 from Timothy Pearson <kb9vqf pearsoncomputing net> 2010-10-22 19:28:12 --- > As the specification is now finalized, the KDE3/Trinity bounty amount on this > page > http://trinity.pearsoncomputing.net/crfe/ > is now finalized as well. Let's see how much can actually be collected, and if > it comes up short then we can discuss what to trim from the specification for > now. > > As mentioned before, I am considering completion of the KDE3/Trinity version as > a prerequisite for the KDE4 version; as such, the KDE4 specification has NOT > been finalized and is still open. > Before I set this up on chipin, I would like to make sure most people are happy with that ordering. Are we fine to proceed with securing the KDE3/Trinity bounty and product without finalizing the KDE4 specification? If so, I'll set it up on chipin.com. Thanks - John
It's OK like that for me. Denis
Maybe my question is a bit naive, but how do we ensure that the features are supported after they have been developed? I would assume that HTML support won't be perfect right from the start, and perhabs after some time more features will be requested, or it would have to be ported to newer versions of KDE not yet out, so no specifications can be worked out at this point of time. Pascal
I don't see the KDE4 specs being much different than the KDE3 specs. It is enough for me that there would be a commitment to get it ported to KDE4 intact. I would also hope that there would be an effort to get the code accepted by the KDE4 community so that it would become part of the general distribution. That said I am OK to get the ball rolling with the KDE4 spec still nebulous.
Go for it, in my humble opinion kmail is unusable today and that makes kontact irrevelant for my needs.
On Fri, 2010-10-22 at 21:53 +0200, Paul Lemmons wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 > > > > > > --- Comment #191 from Paul Lemmons <paul lemmons name> 2010-10-22 21:52:43 --- > I don't see the KDE4 specs being much different than the KDE3 specs. It is > enough for me that there would be a commitment to get it ported to KDE4 intact. > I would also hope that there would be an effort to get the code accepted by the > KDE4 community so that it would become part of the general distribution. > > That said I am OK to get the ball rolling with the KDE4 spec still nebulous. > I'm delighted to see that the feedback so far has been unanimously positive. So that there are no surprises, I do want to remind everyone that the KDE4 port is a separate bounty. I'll wait for the weekend to pass to gain any additional feedback and, if the vast majority is still positive, I'll get chipin going on Monday. Thanks - John
I looked at the specs and would like to add or include (from an earlier posting): 1. the component must be able to fully preserve original/quoted message formatting and content on output 2. the component should allow for basic text input and formatting (i.e. font, size, color, decoration) and image insertion, both in quoted text and in reply text 3. the component should be accepted into current kmail source tree and made available through official kdepim releases
Created attachment 52797 [details] Fake UI with fake conversation about useful features While the backbone is being worked on, I’d like to talk about the frontend, too. This draft is most likely neither complete nor good, but the features they talk about should be in the there in the end: * standards-compliant preset buttons, which add <strong> instead of <b>, <em> instead of <i>, <span class="color_red"> instead of <font color="red">/<span style="color: red;">, … * ability to add scripted buttons and dropdown-lists, reorder them, and so on * ability to switch between visual editing and source-code editing without loss of function (buttons should work on both) * minimal ui
If you waste your time with a KDE3 version, at least apply the resulting patch to /branches/kdepim/enterprise/ which is the only actually supported KDE3 PIM branch out there. Maybe work with some KDAB/Kollab dude to mentor.
I would argue that the waste of time comes from the KDE4 version. Then again, I actually *use* the computer for heavy duty physics and engineering work. Please, let's keep the KDE3/KDE4 argument out of this bug report. Both have their strong and weak points, and eventually the choice comes down to simple user preference. As a user of the KDE3 version, and the person doing the work, I want to see that version completed first. If that is not acceptable, then you may want to find someone else who is willing to handle this RFE.
I am not interested in the KFE3 version, I use KDE4 with the exception of kontact because of Kmail. Fixing KDE3 does not help nor interest me. Bob
me neither, but this is not supposed to become a flamewar. markus s. seems to think otherwise by using rage-inducing terminology like “wasting your time”. i, too, think that a kde 4 version of this is needed more desperately (since kde3 usage already is lower than the one of kde4 and must be shrinking because of the latter is gaining functionality), but i don’t accuse someone who wants to code this for ‘wasting his time’. instead, i don’t participate in the fundraising until we can see the kde4 version on the horizon. 2010/10/24 bob coulter <bob@coulter.org> > https://bugs.kde.org/show_bug.cgi?id=86423 > --- Comment #198 from bob coulter <bob coulter org> 2010-10-24 23:09:42 > --- > I am not interested in the KFE3 version, I use KDE4 with the exception of > kontact because of Kmail. Fixing KDE3 does not help nor interest me. Bob > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are a voter for the bug. > You are on the CC list for the bug. >
My main motivation was to tell that any work on KDE3 PIM apps in the enterprise branch together with one of its maintainers. BTW, Comment #188 asked if everybody was happy giving the classic KMail priority. I'm not happy with that. Don't bitch if answers to a question are not what you want to hear.
If a version for KDE3 is what it takes to eventually get support for KDE4 out, I'm all for it. In the end the KDE4 version may even turn out better because of better knowledge about the pitfalls encountered doing KDE3 first. (Disclaimer: I'm not familiar with the code) Markus would like to see that any of this work would end up in a PIM branch that still receives some loving after the project is finished, which does not sound unreasonable. Let's keep the flames out and think about what we all really want: an even better KMail experience. Regards, Pascal
On Mon, 2010-10-25 at 08:23 +0200, Pascal Vandeputte wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 <snip> Yes, indeed. These are the issues I wanted to surface to avoid any surprises or disappointments. The KDE solution is viable on an ongoing basis as it is not limited to the existing KDE3 or KOLAB versions but is part of Trinity which is an ongoing development of KDE3 for current distribution versions, e.g., the latest Debian and Ubuntu. Thus, it does have a future all on its own as Trinity - a successor to KDE3. However, I know that many of those who are interested in this solution are not using Trinity but KDE4 and will probably stay on KDE4. Porting the solution to KDE4 is part of the plan however, it is a separate project and a separate bounty. So what does all that mean practically? If all goes perfectly well: 1) We will raise the $2500 bounty for the requisite first step - the Trinty/KDE3 version 2) Tim will complete the Trinity/KDE3 implementation. 3) We will raise the $1000 bounty for the KDE4 port 4) Someone will assist with a build environment for KDE4 since Tim does not have one 5) Tim will complete the KDE4 port 6) The KDE developers will accept the patch. They have said they are willing to include this functionality if someone else writes it; they just do not have the resources to do so themselves. However, what happens if we miss step #3 or the KDE developers reject the solution in step #6? I will be very happy because I need the patch for Trinity. I'm concerned about accidentally abandoning the KDE4 users after taking their funds to accomplish step #2. May we please have some discussion on this point - not a debate - just a discussion to make sure no one is accidentally hurt. Thanks - John
hi all, good to see some movement here in the first place - i'm still in with my money even though the time rushed and first thoughts about the 2010 christmas gifts are approaching ... a few comments: * i'm not interested in a kde3 version but in a patch against current kmail trunk. it's ok for me if a kde3 version is done as a intermediate milestone so both projects do profit from the efforts but the bounty should clearly state a kde4 version as the expected outcome. Here i'd like to hear from a kmail dev if something changed drastically in Kmail2/Qt 4.7 which would make a transition kde3-kmail -> kde4-kmail2 more complex than a direct kmail2 approach, thanks. * i hope a kmail2 dev could support/mentor Tim in this second phase (if Tim wants) so the integration into trunk / migration to qt4 goes along smooth.
On Mon, 2010-10-25 at 11:54 +0200, Simon Bühler wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 <snip> Hi, all. This is becoming a bit complicated because we have two very distinct needs wrapped up in one project. As long as we are patient with each other, I'm sure we can work through it. Let me state the issues as I see them and a proposed solution. It will be a little complex but I think it will work. We have the developer of the patch and several key bounty contributors who need the KDE3 version and are happy to see the KDE4 version but KDE4 is not a requirement. We have many other bounty contributors (perhaps the majority) for whom the patch is useless unless it works for KDE4. In the current offer, because of the needs and environment capabilities of the developer (to whom I extend great thanks for being willing to do this), the KDE3 project is a pre-requisite to the KDE4 project. The danger is KDE4 users contributing to the bounty for the KDE3 project because it is prerequisite and then there not being enough funds to meet the second bounty for the KDE4 port. In which case, they will not have a usable return on their investment. So how do we try to please everyone and, more importantly, keep from accidentally defrauding anyone? Here's a proposal: 1) We finalize and close the KDE4 spec so we know what the bounty is. I think Tim was hesitant to do that because of not really knowing what is involved until the KDE3 patch is done but I think we'll have to take our best guess. 2) We set up the KDE3 bounty on chipin and those who need the KDE3 patch commit their contributions. 3) We do NOT set up the KDE4 bounty on chipin (I'll explain why in a minute) but those who need the KDE4 patch send their pledge (not their money) to Tim who will post the results on the Trinity RFE site. 4) Once the KDE4 bounty is hit (I suspect it will be reached before the KDE3 bounty), remaining KDE4 contributors send their pledges to the KDE3 chipin bounty since the KDE4 patch will not be released without it. This is why we do not want to put the KDE4 pledges on chipin because once the amount is reached, the funds are disbursed but we do not want to release the KDE4 bounty until the KDE3 bounty is also met since we can't have one without the other. 5) Once the KDE3 bounty is hit, Tim commences work and releases the KDE3. 6) Now that work can proceed on the KDE4 AND we have sufficient pledges to fund it, we setup the KDE4 bounty on chipin, collect it, and do the patch. I think that will work. If you followed me, no need to read further. If I've confused you, let me explain it another way. We probably have more contributors to the KDE4 bounty than the KDE3 bounty. The KDE3 bounty is bigger than the KDE4 bounty and is a prerequisite. So let's have KDE4 contributors first fill the KDE4 bucket to make sure they're not left without a viable patch for their money at the end of the project. Once we've filled the KDE4 bucket, KDE4 users start filling the KDE3 bucket since it is a prerequisite to the KDE4 project. Once we have both buckets full, we can safely begin work without risk of accidentally defrauding the KDE4 users. If we happen to fill the KDE3 bucket first, then problem solved (at least the problem of potentially defrauding the KDE4 users). Sorry for the complexity but I want to ensure we are all working together and not accidentally at cross purposes. Please send your feedback. If there is no great objection, then we should proceed with step #1 - finalizing and closing the KDE4 spec. Thanks - John
Sounds like a smart approach, thanks John. I'm a KDE4 customer and happy with the approach.
On Sun, 2010-10-31 at 03:14 +0100, Diego Tognola wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 There has been very little feedback on the proposed way to proceed so I assume all are fine with it as we need to get going. Tim, the next step would be yours. Are you able to close the KDE4 spec and finalize the bounty? Thanks - John
*** Bug 254531 has been marked as a duplicate of this bug. ***
FYI, I added this to the list of Google Summer of Code ideas again, see http://community.kde.org/GSoC/2011/Ideas#Project:_Improved_HTML_support_in_KMail. So if someone here is a student and motivated, go for it! I am willing to mentor this.
Average non-techie user here. As I have no coding experience whatsoever in this environment, my thinking here may be completely off base, and I will be happy to be enlightened by those who actually know what they are talking about. Anyway: I'm not sure I understand exactly why this feature would be so complicated to implement. An email comes to you in HTML format, and Kmail displays it as such. You hit "Reply," and the composer accepts HTML formatting and displays your formatted text as you enter it. Kmail should not have to actually do anything extra to *get* the inserted Reply text into HTML format; it came in that way, and is just being inserted into an editor already capable of understanding and displaying HTML on the fly. Kmail must be actively *doing* something extra to convert the original HTML into plain text, invoking routines that strip out the tags and replace them with * and / and whatnot. Is it really such a big deal to just stop the program from doing that, and instead of doing the extra work to process the existing HTML into plain text, just have it insert what it *already has* into your reply? Ideally with a checkbox that lets you strip the HTML or not at your discretion? It doesn't seem to me like it would involve any major start-from-scratch code rewrite or anything. But like I say, this is coming just from my own ignorance of what might be involved. Add me to the roster of users who really like Kmail/Kontact, but quite honestly can't use it because of this issue.
(In reply to comment #209) It is complicated, because you must be able to edit the inserted text you are replying to. So you need editor which can transform user GUI actions to HTML code and in addition this editor must understand standardize HTML and Microsoft (Outlook + Word) HTML like Zimbra or Thuderbird do. For example: embedded images, tables, fonts and colors inside tables/cells, bullets, ... Anyway use Thunderbird. It is not so perfect as Outlook (in terms of functionality) as it has some bugs and missing some functionality, but is better as Kmail.
(In reply to comment #210) I would be satisfied if the program could just display to the sender his original message withouth misformatting it. The ability to edit the original message is not essential for me...
(In reply to comment #211) > (In reply to comment #210) > I would be satisfied if the program could just display to the sender his > original message withouth misformatting it. The ability to edit the original > message is not essential for me... +1 from me - this could likely mean knocking off 90% of the hassle with 10% of the effort ?
(In reply to comment #212) > +1 from me - this could likely mean knocking off 90% of the hassle with 10% of > the effort ? maybe it seems like that, but i am sorry for having to disappoint you: the reply message is a html document, so you have two ways of inserting another: merging the latter into the further or an iframe. while the iframe solution would indeed be a way to preserve the other message in 100%, it is impossible or at least impractical (you have to store the additional documents somewhere) the merging solution, however, is what this bug is about in the first place: as soon as you can merge in another message in a reliable way, you can edit it anyway. so sorry, no quick'n'dirty solution here.
It's so bizarre that this problem is still not picked up; that the only activity still is ... *discussing it*!! Whatever happened to the pledgies? (see: http://pledgie.com/campaigns/7325 ). I though this was finally going to be implemented? In my opinion this is a never ending discussion. KMail was, and still is, a beautiful mail client, but I'm getting a really strong vibe that it's bleeding to its death. Developers can be very stubborn and on the other hand users are getting more and more programs to choose from; I've given up and moved on to 'greener pastures'. It still is *very funny* to see the discussion flame up every once in a while....!
On Thu, 2011-03-10 at 16:53 +0100, G.Gavranovic wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 > > > > > > --- Comment #214 from G. Gavranovic <gabrijel gavro nl> 2011-03-10 16:53:42 --- > It's so bizarre that this problem is still not picked up; that the only > activity still is ... *discussing it*!! > Whatever happened to the pledgies? (see: http://pledgie.com/campaigns/7325 ). > I though this was finally going to be implemented? > > In my opinion this is a never ending discussion. KMail was, and still is, a > beautiful mail client, but I'm getting a really strong vibe that it's > bleeding to its death. Developers can be very stubborn and on the other hand > users are getting more and more programs to choose from; I've given up and > moved on to 'greener pastures'. > > It still is *very funny* to see the discussion flame up every once in a > while....! > I checked with Tim Pearson from the Trinity project (KDE3 fork - http://trinity.pearsoncomputing.net) who was interested in doing the work but he is up to his eyeballs with a new release and a port to cmake. It might come alive again after that. We left off that we needed to finalize the KDE4 spec. Once that was done and published we would start collecting the pledges. The issue was the split between those who need it for KDE3 and those who need it for KDE4. We need to fill the KDE3 pledge as a dependency for the KDE4 version (by virtue of who is doing the work and the way they would implement - not a technical dependency). If both fill, we will have both versions which is the goal. It is a fairly substantial project. As someone else commented early, no quick fixes here. Thanks - John
(In reply to comment #215) > We need to > fill the KDE3 pledge as a dependency for the KDE4 version (by virtue of > who is doing the work and the way they would implement - not a technical > dependency). If both fill, we will have both versions which is the goal. > It is a fairly substantial project. As someone else commented early, no > quick fixes here. Thanks - John So, it seems this will take a very long time to fix (if it's ever fixed at all). When the KDE3 port is finished we'll probably be on KDE 5 or 6, and most users will probably have switched to better email clients/pim suites. I don't get this never-ending love affair some people have with KDE3, which causes the whole KDE project to be left in 1995, compared to other desktop environments, when it comes to email/pim. The conclusion to draw from this is that, either a new, more open-minded team takes over kmail and implements the functionality users want and expect (as showed by the number of votes on most kmail bugs and wishes), or a new pim suite for KDE is developed. If neither of these happen, users will move on to 'greener pastures' as G. Gavranovic mentioned. Count me in that group of people.
I think there should be just one bounty and it should be for the kde4 version. Very little people are interested in the kde3 version. There should be one large bounty and it should include whatever amount of money is required to make both the kde3 and kde4 versions for the developer. There shouldn't be two bounties because then we will likely land up with a kde 3 version and that's as far as it would get.
On Sat, 2011-03-12 at 14:28 +0100, Divan Santana wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 <snip> I should clarify the points raised. They have been discussed in detail earlier on but this thread has grown long. First of all, KDE3 is alive and well in the Trinity project. There are a number of production installations which do not feel KDE4 is ready for production usage. This is not the place to have that debate. Some feel it is, some feel it is not. We cannot judge another's environment unless we are in it. The bucket system was set up to accommodate both and prevent taking advantage of either "camp." The idea was for contributors to contribute to whichever bucket they preferred. If the KDE4 bucket filled before the KDE3 bucket, as we suspect will happen, all funds then flow to the KDE3 bucket since it is the dependent project. If the KDE3 bucket never fills, the project, at least from that developer dies. What we wanted to avoid was KDE4 users paying into the KDE3 development and then there not being enough left over for the KDE4 port. Similarly, we did not want KDE3 users stymied if there was enough contribution to do the KDE3 project but not enough for KDE4. Hence the dual bucket approach. Thanks - John
That sounds like a logical approach. KDE 3.5.10 was a very functional desktop, and I am not sure I am any more functional w/ 4.6 (maybe less since I keep playing around with it). One thing that would help a lot of us is understanding the implications of running KDE 3.5 software under 4.6 and vice-versa. But, even in KDE 4.6 it still does not work! Do we have an ETA of when this will be done? Thanks Kevin Kevin M. Coonan, MD Bethesda, MD kevin.coonan {GMail, Skype} Omnes homines liberi aequique dignitate atque juribus nascuntur. Ratione conscientiaque praediti sunt et alii erga alios cum fraternitate se gerere debent. All human beings are born free and equal in dignity and rights. They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood. Article I. Universal Declaration of Human Rights. 1948-12-10, Paris, France On Saturday, March 12, 2011 16:14:42 John A. Sullivan III wrote: > https://bugs.kde.org/show_bug.cgi?id=86423 > > > > > > --- Comment #218 from John A. Sullivan III <jsullivan opensourcedevel com> > 2011-03-12 22:14:31 --- > > On Sat, 2011-03-12 at 14:28 +0100, Divan Santana wrote: > > https://bugs.kde.org/show_bug.cgi?id=86423 > > <snip> > I should clarify the points raised. They have been discussed in detail > earlier on but this thread has grown long. > > First of all, KDE3 is alive and well in the Trinity project. There are > a number of production installations which do not feel KDE4 is ready for > production usage. This is not the place to have that debate. Some feel > it is, some feel it is not. We cannot judge another's environment > unless we are in it. > > The bucket system was set up to accommodate both and prevent taking > advantage of either "camp." The idea was for contributors to contribute > to whichever bucket they preferred. If the KDE4 bucket filled before > the KDE3 bucket, as we suspect will happen, all funds then flow to the > KDE3 bucket since it is the dependent project. If the KDE3 bucket never > fills, the project, at least from that developer dies. What we wanted > to avoid was KDE4 users paying into the KDE3 development and then there > not being enough left over for the KDE4 port. Similarly, we did not > want KDE3 users stymied if there was enough contribution to do the KDE3 > project but not enough for KDE4. Hence the dual bucket approach. > Thanks - John
<snip> Actually, Trinity made massive improvements to KDEPIM including fixing the longstanding timezone problems and implementing complete caldav and carddav libraries to the point we are largely interoperative with Zimbra. Trinity is designed so that it can run in parallel with KDE4, e.g., it installs under /opt/trinity and uses ~/.trinity for user settings. Right now, the work is in a bit of limbo because Trinity is all hands to the pump on a port to cmake and getting their next release out the door.
Good news, I hope. Found this relating to KDE-PIM and Google Summer of Code: http://community.kde.org/GSoC/2011/Ideas#KDE_PIM note point 2, Project: Improved HTML support in KMail at least the devs are aware of this weakness though they obviously do not consider themselves having time to address it at this moment
Well, thanks to the devs (Thomas and Sudhendu) who are tackling this, and to Google for picking up the tab. This feature should make quite a difference in enterprise adoption of kmail, in my experience - being able to top quote and forward without losing the format is simply a must in such environments. The progress (and there is quite some progress already) can already be tracked at: https://projects.kde.org/projects/kde/kdepim/repository/show?rev=htmlreplies
Here's a piece of good news :) http://sudhendu.in/node/12
(In reply to comment #223) > Here's a piece of good news :) http://sudhendu.in/node/12 It looks fantastic!
That's great!
This seems finally finished as per below progress. http://sudhendu.in/node/13 Just needs some more flexibility such that html/plantext can be selected per mail/reply also. I wish this makes it in kde 4.8 at least.
The SOC branch was merged into master with this commit: http://commits.kde.org/kdepim/04ab0b7d525aa7fddc8ba69847add244931ed3dc This means the work done will be available in kdepim 4.8. If you build kdepim from git, please test and report issues using the kdepim product and messagecomposer component
Bugzilla comment check
tried it and found two bugs : bug 285357 and bug 285359
(In reply to comment #227) > The SOC branch was merged into master with this commit: > http://commits.kde.org/kdepim/04ab0b7d525aa7fddc8ba69847add244931ed3dc > > This means the work done will be available in kdepim 4.8. > > If you build kdepim from git, please test and report issues using the kdepim > product and messagecomposer component Is html/text configurable globally only or we can select per email also? It would be nice to have this option per email also.
(In reply to comment #230) > Is html/text configurable globally only or we can select per email also? It > would be nice to have this option per email also. It is configured globally with the option to use a different template to force either plain or html replies. It is also possible to switch when inside the composer.
(In reply to comment #231) > It is configured globally with the option to use a different template to force > either plain or html replies. It is also possible to switch when inside the > composer. That's cool. Looking forward for kde 4.8 :)
Switching this to kmail2 product
Wow, thanks for your great work! Finally, Sudhendu Kumar realized this long-requested feature in this year's GSoC. And as it is based on WebKit, it is not even limited to a small HTML subset as Mailody is (using QTextEdit). Maybe Sudhendu or one of the project lead could write a small post about what has been done and what is left - that'd be awesome. While this initial implementation obviously leaves numerous bugs to be subsequently fixed, I'd propose to finally mark this huge ticket FIXED in 4.8, and post issues with the new implementation on separate tickets!
yes I am closing this. there are already several bugs reported pertaining to this new feature in 4.8.
In the time frame it took to ship a fix to this bug, I repeatedly made love to fifteen different girls. And I am NOT a womanizer. Great job, KDEPIM team :-) LOL. For the record, I am a KMail user. No hate, please.
Manuel, can you post how to reproduce that behavior?
I would have to get releases from all implicit nondisclosure agreements I've entered into :-S
Ivan: Don't worry. Manuel's behavior is indeed likely to lead to reproduction. "Amador" indeed -- that's a very appropriate name :-)
Let's keep this on topic please...
I don't understand how this bug is marked as fixed. It clearly isn't replying in the SAME format as it was received. Even for basic formatting replies look completely different inserting extra line breaks all over the place. In mail view border-radius works, in reply it doesn't. Fonts are all messed up - sizes, colors, boldness being different from the original message. I have really wanted to switch to kmail, but this bug is a show-stopper and has been for years now. It's close, but I definitely wouldn't mark this as fixed.
I agree - although KMail does an acceptable job for me, sometimes the changed e-mail contents is still very important and I end up using some other e-mail clients (even Roundcube webmail) for this purpose. One more thing that frequently happens is that HTML-tables lose borders in KMail compositor.
"One more thing that frequently happens is that HTML-tables lose borders in KMail compositor." ? it doesn't import table border format correctly ?
As Allen said, this is already covered by a number of more specific bug reports. Plus Laurent currently works on a new composereditor-ng, so we should probably wait how this turns out and then file specific bug reports against it.