(*** This bug was imported into bugs.kde.org ***) Package: knode Version: 0.3.1 (KDE post 1.94 > 20000911) Severity: wishlist Currently Knode appears to do threading only via references so articles that have no refrences info end up in their own threads. The newsreader PAN (http://www.superpimp.org) attempts to take care of this by putting all articles with identical subjects (ignoring "Re:") into the same thread. This makes the article-list pane less cluttered and puts all of the related articles closer to each other for easier/quicker naviagation between articles. To describet this in more detail I'll call the final result a "pseudo-thread" and the threads done only via references "real-threads". All of the real-threads with identical subjects are gathered together and the root of one of these threads is choosen to be the root of the pseudo-thread; the roots of all the other real-threads are made to be children of the pseudo-thread root.
This problem is very obvious if you try to read the KDE mailing lists at news.uslinuxtraining.com. Evidently this mail->news gateway has no correct references which means that knode is completely unusable for reading KDE mailing lists on this news server. Most more evolved news readers look at references first but try to evaluate the title as well. Taking into account title changes like Re and (Was: OLDTITLE) is obviously also mandatory for a modern news reader
severity 11886 wishlist quit On Tuesday 19 February 2002 18:47 Moritz Moeller-Herrmann wrote: > This problem is very obvious if you try to read the KDE mailing > lists at news.uslinuxtraining.com. Evidently this mail->news gateway > has no correct references which means that knode is completely > unusable for reading KDE mailing lists on this news server. <snip> This is NOT a bug. It's a wish. If you want it so badly go implement=20 it and don't upgrade feature requests to bugs. Marc --=20 Marc Mutz <mutz@kde.org>
Any progress on this? I guess as kmail and knode share more and more code, this could be handled by the merge.
Volker Krause wrote: > On Tuesday 25 October 2005 00:55, Ingo Klöcker wrote: >> On Monday 24 October 2005 20:58, Andreas Gungl wrote: >> > The last modifications on the handling of message states have been >> > showing some problems based on the distributed logic dealing with the >> > state changes. So I've created a class intended to encapsulate the >> > state. However, I haven't changed any logic in the existing message >> > classes yet. >> > (See the attached patch.) >> > >> > Would it be okay to commit the new class and to start replacing the >> > existent source areas dealing with the state? >> >> Yes. >> >> > If yes, should I move >> > the new class and the corresponding enum into a file of it's own? >> >> Yes, please. >> >> A few things I saw while quickly glancing over the patch: >> - isHasAttachment() should be hasAttachment() >> - Why do we have the obviously mutually exclusive status >> KMMsgStatusHasAttach and KMMsgStatusHasNoAttach? This should be fixed >> and isHasNoAttachment() should not exist. >> - The setters need to accept a bool parameter. In particular, with your >> API it's not possible to unset the "forwarded" status and other status. >> For some of the setters the parameter might not make sense (like >> setRead() and setUnread()). >> - Make the member variable private. >> - Rename KMMsgStatus and KMMsgStatus* to something non-kmailish. Do we >> have to export the enum at all? >> - Ask Volker and the Akregator devs whether they could make use of this >> class in KNode/Akregator and, if yes, whether they need further status. > > This seems quite useful, especially if KMail and KNode would share the > same header view some day. As far as I can see it covers all status flags > used in KNode. If KNode shared Kmail's header view then it would inherit its more sophisticated threading support (ie includes subject), which would resolve this wish item.
Hello! Sorry to be the bearer of bad news, but this project has been unmaintained for many years so I am closing this bug.