[kontact] [Bug 432371] KMail: CRTL-Enter does not work if cursor in address-field
https://bugs.kde.org/show_bug.cgi?id=432371 Laurent Montel changed: What|Removed |Added Resolution|--- |INTENTIONAL CC||mon...@kde.org Status|REPORTED|RESOLVED --- Comment #1 from Laurent Montel --- nope it doesn't work before as I don't want to send by error and email as it's easy to press CTRL+ENTER. So it's a normal feature. Regards -- You are receiving this mail because: You are the assignee for the bug.
[akregator] [Bug 381423] Crash when adding RSS; crash every restart or launch
https://bugs.kde.org/show_bug.cgi?id=381423 Nate Graham changed: What|Removed |Added Status|NEEDSINFO |REPORTED CC||n...@kde.org Resolution|WAITINGFORINFO |--- -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 427091] Kmail gpg bad signature if From header contains non-ascii characters
https://bugs.kde.org/show_bug.cgi?id=427091 Sandro Knauß changed: What|Removed |Added Latest Commit|https://invent.kde.org/pim/ |https://invent.kde.org/pim/ |messagelib/commit/3a7114399 |messagelib/commit/c57eb4d95 |b105cbe159355f600b9d3e08ec1 |e67c8b28305c1c0c9e29179530f |0fcb|cd1d --- Comment #10 from Sandro Knauß --- Git commit c57eb4d95e67c8b28305c1c0c9e29179530fcd1d by Sandro Knauß. Committed on 01/02/2021 at 19:19. Pushed by knauss into branch 'release/20.08'. Fix[messagecomposer]: Do copy all mail headers instad of reference them. When dealing with encryption and protected headers it is enough to reference the headers in the messagepart, as the result is encrypted directly. This is different for Sign only and there may be jobs after signing that are changing the mail headers, so we need to copy all headers into the encapsulated part instead of referencing them. FIXED-IN: 5.16.1 M +55 -0messagecomposer/autotests/signjobtest.cpp M +2-0messagecomposer/autotests/signjobtest.h M +5-6messagecomposer/src/job/protectedheaders.cpp https://invent.kde.org/pim/messagelib/commit/c57eb4d95e67c8b28305c1c0c9e29179530fcd1d -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 431176] Message body not rendering
https://bugs.kde.org/show_bug.cgi?id=431176 Christoph Feck changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |WORKSFORME --- Comment #9 from Christoph Feck --- Thanks for the update; changing status. -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 387061] REGRESSION: Large messages don't display in the viewer pane (eg. New Tumbleweed snapshot 20171117 released!)
https://bugs.kde.org/show_bug.cgi?id=387061 --- Comment #47 from Wolfgang Bauer --- (In reply to RJVB from comment #45) > (In reply to Wolfgang Bauer from comment #44) > > > I do use QtWebKit with konqueror, and opening large OBS logs (which are just > > text files) do take a while. > > TBH, Konqueror is such a multipurpose tool that I have no idea what > backend/engine/kpart it uses for rendering pure text. I'm talking about opening a text file in the HTML renderer, whatever is the default. Konqueror can of course use other kparts to display files (katepart e.g.), but that's not the topic here. (In reply to Greg Rivers from comment #46) > From a user perspective, it's more than reasonable to expect KMail to > display large plain text messages as well as other common MUAs do. Rather > than using QtWebEngine to display plain text, shouldn't an efficient method > such as the one employed by "View Source" be used for all text/plain MIME > parts? I don't think so, no. Without a large rewrite anyway, as mentioned. KMail does add HTML stuff to an EMail even if it's just plain text, such as the header, links to attachments, and so on. -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 387061] REGRESSION: Large messages don't display in the viewer pane (eg. New Tumbleweed snapshot 20171117 released!)
https://bugs.kde.org/show_bug.cgi?id=387061 --- Comment #46 from Greg Rivers --- >From a user perspective, it's more than reasonable to expect KMail to display large plain text messages as well as other common MUAs do. Rather than using QtWebEngine to display plain text, shouldn't an efficient method such as the one employed by "View Source" be used for all text/plain MIME parts? -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 387061] REGRESSION: Large messages don't display in the viewer pane (eg. New Tumbleweed snapshot 20171117 released!)
https://bugs.kde.org/show_bug.cgi?id=387061 --- Comment #45 from RJVB --- (In reply to Wolfgang Bauer from comment #44) > I do use QtWebKit with konqueror, and opening large OBS logs (which are just > text files) do take a while. TBH, Konqueror is such a multipurpose tool that I have no idea what backend/engine/kpart it uses for rendering pure text. Actually, when I open /var/log/syslog I get a view that suggest very strongly that the Kate text editor kpart is used. That is, if I open the file from within Konqueror. If I try to start konqueror with a file it will start but open the file in the system handler (Kate for text files), very funny. > That's what I meant with a "large rewrite" amongst other things. > Please note that I'm not a kmail developer though. Neither am I, and you're right in assuming it could be more work than you'd expect. > I'm not sure though, nor if it frees the resources when you switch to a > different mail (I think it does). In my experience that doesn't always mean the resources are available immediately, for RAM at least. But I digress... -- You are receiving this mail because: You are the assignee for the bug.
[kleopatra] [Bug 422328] It is not possible to sign more than one file with Kleopatra without crashing the program
https://bugs.kde.org/show_bug.cgi?id=422328 Halla Rempt changed: What|Removed |Added Keywords|regression | -- You are receiving this mail because: You are on the CC list for the bug.
[kleopatra] [Bug 422328] It is not possible to sign more than one file with Kleopatra without crashing the program
https://bugs.kde.org/show_bug.cgi?id=422328 Halla Rempt changed: What|Removed |Added Keywords||regression CC||ha...@valdyas.org -- You are receiving this mail because: You are on the CC list for the bug.
[kmail2] [Bug 387061] REGRESSION: Large messages don't display in the viewer pane (eg. New Tumbleweed snapshot 20171117 released!)
https://bugs.kde.org/show_bug.cgi?id=387061 --- Comment #44 from Wolfgang Bauer --- (In reply to RJVB from comment #43) > > TBH, I think even QtWebKit would struggle with these large mails > > That would be simple to test in konqueror with the webkit backend, or > Otter-Browser, and the rebooted QtWebKit. Or in epiphany. > 1 caveat emptor: we don't actually know what clever tricks the web email > interface pulls. I do use QtWebKit with konqueror, and opening large OBS logs (which are just text files) do take a while. > > Anyway, this is kind of a different problem than comment#35 (or comment#0). > > I don't see how it could be fixed from the kmail side, except for not trying > > to display mails larger than a certain size at all. (or maybe just display > > it as plain text instead then, but that probably means a large rewrite of > > the code, and I'm not sure it's possible at all) > > - Don't dump the entire message into the rendering widget but use a paged > approach > - wrapper code can be written that connects to different backends. If you > don't want to support QtWebkit, fine, but there's also QTextBrowser which > should be sufficient even for simple HTML emails (it's what Qt's assistant > uses by default since whatever Qt version that obsoleted QtWebkit). I've > done a compile-time version of such wrapper code for KDevelop's help browser > (which supports both QWE and QWK). I think it should be possible at least to > chose between backends as a startup option. That's what I meant with a "large rewrite" amongst other things. Please note that I'm not a kmail developer though. > Out of curiosity: does that humongous QWE process exit when you close the > message view, or do you have to quit KMail to recuperate all that RAM? I think that the QWE process is reused. I'm not sure though, nor if it frees the resources when you switch to a different mail (I think it does). -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 387061] REGRESSION: Large messages don't display in the viewer pane (eg. New Tumbleweed snapshot 20171117 released!)
https://bugs.kde.org/show_bug.cgi?id=387061 --- Comment #43 from RJVB --- (In reply to Wolfgang Bauer from comment #42) > Have you tried in Chromium though? (which is what QtWebEngine is based upon) Current versions of Firefox tend to consume more memory than Chromium - in fact,I understand that the Firefox Quantum engine uses bits and pieces from all 3 open source web engines and picks the fastest one. > TBH, I think even QtWebKit would struggle with these large mails That would be simple to test in konqueror with the webkit backend, or Otter-Browser, and the rebooted QtWebKit. Or in epiphany. 1 caveat emptor: we don't actually know what clever tricks the web email interface pulls. > Anyway, this is kind of a different problem than comment#35 (or comment#0). > I don't see how it could be fixed from the kmail side, except for not trying > to display mails larger than a certain size at all. (or maybe just display > it as plain text instead then, but that probably means a large rewrite of > the code, and I'm not sure it's possible at all) - Don't dump the entire message into the rendering widget but use a paged approach - wrapper code can be written that connects to different backends. If you don't want to support QtWebkit, fine, but there's also QTextBrowser which should be sufficient even for simple HTML emails (it's what Qt's assistant uses by default since whatever Qt version that obsoleted QtWebkit). I've done a compile-time version of such wrapper code for KDevelop's help browser (which supports both QWE and QWK). I think it should be possible at least to chose between backends as a startup option. Out of curiosity: does that humongous QWE process exit when you close the message view, or do you have to quit KMail to recuperate all that RAM? -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 387061] REGRESSION: Large messages don't display in the viewer pane (eg. New Tumbleweed snapshot 20171117 released!)
https://bugs.kde.org/show_bug.cgi?id=387061 --- Comment #42 from Wolfgang Bauer --- (In reply to Attila from comment #41) > Firefox can display this e-mail within 2 seconds and I can scroll very > smooth through the content by dragging the scrollbar. Have you tried in Chromium though? (which is what QtWebEngine is based upon) TBH, I think even QtWebKit would struggle with these large mails, according to my experiences with OBS build logs... (KHTML served better in this regard, but that's completely dead now) Anyway, this is kind of a different problem than comment#35 (or comment#0). I don't see how it could be fixed from the kmail side, except for not trying to display mails larger than a certain size at all. (or maybe just display it as plain text instead then, but that probably means a large rewrite of the code, and I'm not sure it's possible at all) -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 431077] Failure to send email message from Kmail using Google SMTP
https://bugs.kde.org/show_bug.cgi?id=431077 Jebin changed: What|Removed |Added CC||jebin12...@gmail.com --- Comment #1 from Jebin --- I am facing the same issue as well. Same OS configuration as OP. -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 387061] REGRESSION: Large messages don't display in the viewer pane (eg. New Tumbleweed snapshot 20171117 released!)
https://bugs.kde.org/show_bug.cgi?id=387061 --- Comment #41 from Attila --- (In reply to RJVB from comment #39) > A pure text email of 35Mb is massive too, but eating around 4Gb of RAM for > that isn't just massive. That's what you meant, right, not 4Mb for > displaying just the part that fits in your window (which would seem > reasonable)? 4Gb, that's about 120 times the size of the email. Yes I mean 4.317.684 K (QtWebEngineProcess). > I knew KMail would become a powerkids' tool with the design decision to use > a full-fledged-browser-in-a-widget (QtWebEngine) for rendering everything > including pure text emails but I wasn't expecting this. Then again, I don't > usually get this kind of long letters by email so I have no idea how any > other MUA would handle them. I get this kind of long emails every day. This is the output from backup scripts executed by Cron. > If the account you got this email on has a web/browser interface it would be > interesting to estimate the resources an actual browser (GChrome or > Chromium) would use to display it, for comparison. Unfortunately this account doesn't have a Web-Interface, but I did a test on another account with Web-Interface. The plain text has a size of 20 MiB. In Comparison: QtWebEngineProcess (KMail) is eating 1.609.232 K. Firefox (Web-Interface) is eating 156.204 K. Firefox can display this e-mail within 2 seconds and I can scroll very smooth through the content by dragging the scrollbar. -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 432371] New: KMail: CRTL-Enter does not work if cursor in address-field
https://bugs.kde.org/show_bug.cgi?id=432371 Bug ID: 432371 Summary: KMail: CRTL-Enter does not work if cursor in address-field Product: kontact Version: 5.16.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: mail Assignee: kdepim-bugs@kde.org Reporter: axel.br...@gmx.de Target Milestone: --- SUMMARY the shortcode CRTL-Enter is frequently used as command to send a mail. This work if the cursor is in the text part of the mail (composer?), but not if it is in an address field. Not sure, but I seem to remember that this worked before, so this is a regression in 5.6.x Operating System: openSUSE Tumbleweed 20210126 KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2 -- You are receiving this mail because: You are the assignee for the bug.
