KMail Complexity - and a little Patience
Summary This article considers some problems I had when I tried to set up and use the latest version of what I still consider is a superb email client: KMail. My experiences suggest to me that KMail is no longer primarily directed at the single, stand-alone user and instead it has been changed into a complex, integrated and interdependent package (composed of KMail, KWallet, Akonadi and Nepomuk) which the KDE KMail team has developed for use in large scale, multi-user, business and/or government networks. I also believe this increased KMail complexity makes it less suitable for use by the stand-alone user who requires a simple, dedicated email client without any other imposed software, and I suggest that Thunderbird has become a better option for that purpose. A "KMail - Light" is suggested as another alternative. Attention is also drawn to another far less important but still extensively used KDE4 package, the patience card-game software which I believe has been degraded due to over-development. Ridcully. Introduction As many LXer readers know, my preferred OS/DE package is KDE running on openSUSE and I have rarely employed anything else since I began to use Linux seriously in 2000. So far, openSUSE remains (in my opinion) as well engineered as its SuSE predecessor. I also think KDE has progressed in a mostly positive direction, although I use only a tiny part of the software package functions. I found KDE4 very complex after the comparative simplicity of KDE3.5, but the folder view of KDE4 gives me a desktop that resembles KDE3.5 and so, with some "tweaks", my "comfort zone" remains. Apart from file management, my normal daily requirements are rather simple: email, web browsing, document preparation and finally, the playing of movies and a few simple games. Not much is it ? However, each of the first three items is crucial to my daily work. Browsing is done with Chrome or Firefox as the occasion demands, while document preparation is done with either Libre Office or Apache Open Office (with occasional drops into Microsoft Office running on Crossover Office - when I check a .doc(x) document). Movies are played with either VLC or Xine and the games are simple: mostly freecell or other card patience games. All of these are done on an HP Compaq 6710b dual core laptop which is certainly now showing its years (the "A" is totally worn off the surface of the key on the keyboard), but I prefer its excellent screen dimensions. KMail and its Changes The remaining requirement is email, and for the past 12-13 years my email needs have been more than adequately met using KMail. In KDE3.5, KMail was a relatively simple and stand-alone piece of very good software for composing/sending/receiving emails (and attachments) and the displays were intuitive. It's installation and setup were straightforward. You could use the account wizard to set the package up, but in later years my familiarity meant that I rarely did and I inserted my mail server address, email address, user name and password using the menu system. KMail was simple, fast and very effective. Other "tweaks" allowed you to set the displays to your liking, the length of the script line (out to at least 200 characters), printing parameters, composing templates, and so forth. Because no database software was involved, you could also "mass-copy" all your previous emails across to their location in .kde during an upgrade. As a stand-alone client, KMail stored your ISP server access password in its own internal location......Never, in all my years of usage of this earlier version of KMail, have I ever felt that my server account password was insecure through saving it within KMail itself, nor have I any evidence to show that my password may have been compromised. My use of KMail was strictly that of an email client and I have never used or needed the services of the Kontact software. KMail began to alter once KDE4 was implemented. At first these changes were minimal and you could disregard them up to, and including, the release of openSUSE 11.4 which came with KDE4.6 and version 1.13.6 of KMail. Certainly, the Akonadi system had now been implemented and the Nepomuk file sharing system was present, but you could cheerfully ignore Akonadi and disable Nepomuk without any problems, and finally, you could STILL store your password inside KMail. KMail 1.13.6 remained a superb email client, simple to install and set up, the settings were inserted in the usual way and the software continued to operate (more or less) in its traditional "stand-alone" manner. That changed considerably with the next version release of KMail in openSUSE 12.1 . It is for the above reason I am still running openSUSE 11.4, as my only operating system, under the Evergreen project, and the included KMail 1.13.6 runs simply and easily. However, Evergreen support for openSUSE 11.4 will end at the middle of this year, and so it has become imperative that when I upgrade to openSUSE 13.1, I will still have an email client that gives me the same simple operational abilities as my present version of KMail. I'd even make a heartfelt plea to the Evergreen group to continue to support openSUSE 11.4 for another year purely because openSUSE 11.4 is such a good, reliable version of the OS, KMail works very acceptably as far as I am concerned, and KDE4.6 is relatively simple and effective. Wizards Both my present version (1.13.6) of KMail and the latest version (4.11.3) use "wizards" to help you set the program up when you start it for the first time. These wizards are very useful to a newcomer and they can also be accessed via the menu bar if it is wished to set up additional accounts. The wizard in my present KMail 1.13.6 is very straight forward to use and there are no hidden traps. From my very frustrating experiences, the wizard for KMail 4.11.3 is also "apparently simple" provided you have KWallet enabled - and that is a very nasty hidden trap. The first time I tried to use a later version's wizard (in openSUSE 12.1), I had previously disabled KWallet because I could not see why I needed the security software as a single user and I was unaware that the KMail developers had set a mandatory dependency upon KWallet if it was wished to store the ISP server account password permanently. This led me into all kinds of Catch22 problems with the wizard, the account settings and KWallet itself, but the upshot was that I found that my password could no longer be stored in KMail and to my knowledge, that remains the present situation. I have discussed KWallet's apparent security and its mandatory aspects for KMail at a later point in this article. Changes to KMail's Internal Settings To show how KMail has altered in its internal account settings, I have provided three images that show a data window called the "Modify Account - KMail" window in the earlier versions of KMail and the "POP3 Account Settings" window in the later versions. To reach it, the following menu selections are made but as will be seen, the later version of KMail changes its displays when the Accounts step is reached: Menu Bar - Settings - Configure KMail - Accounts - Receiving tab - Modify. KMail 1.13.6 The image shows that the server Account name (my ISP is Bigpond) is inserted as well as its incoming address, the user's login name is inserted (blanked out with x's to preserve anonymity) and the password to the server has been accepted and stored by KMail. If the POP settings tab is selected, the only thing required is to ensure that the box that allows messages to remain on the server is ticked or not (depending on your requirements) and for the Security tab, the appropriate buttons are "None" and "Clear text".  You also need to put the Outgoing mail server address in the outgoing box accessed by the Sending tab, but that is identical to the Incoming mail server address shown in the image below. And that is all that is required. Once these very simple procedures are completed, KMail can send and receive emails. If required, this particular menu tree and sub-window set can be used to set up new accounts rather than going through the wizard and my experiences are that it is extremely fast and simple to do so. KMail 4.11.3 The same set of menu procedural steps also commences in openSUSE 13.1 with KDE 4.11.13 and running KMail 4.11.3, but the procedures diverge once the "Accounts" step is reached. Instead of the above window showing the user account information, a very different window ("Setup for Sending and Receiving Messages") is reached which indicates there are two incoming accounts active because that is the title of the Receiving sub-window tab; the first account is at Bigpond and the second at a "KMail Folder" destination. The next image shows this sub-window.  When I captured the above image, I was using an offline test machine, and by sheer accident I believe this has allowed me to understand the significance of the "green button" that sits on the KMail Folders line and which would normally also appear in the same location on the Bigpond line. The presence/absence of the green buttons indicates whether that the relevant server or filing system is either on line and/or ready - or not. It says much for the increased complexity of this version of KMail that prior to this image the buttons meant nothing to me, because my computer was always "on-line" when I was working with KMail in an attempt to set it up and so both buttons merely indicated "Ready". To a newcomer, those two lines would be very confusing, and they certainly were to me.....From past experience, the KMail setup should only have a single incoming account dedicated to the user's ISP - in my case, Bigpond. So the obvious question arose: What is meant by the fact that "KMail Folders" is designated as an "Incoming account" ? Originally, I was unable to understand how my own computer filing system had become an "Incoming account", let alone why I needed to know my own computer filing system was "Ready" because it had to be ready if my computer was operating. However, given the "Offline/Ready" evidence of the green buttons, I believe I now know the reasons for this situation and it requires a paradigm shift from "stand-alone" concepts to networked concepts. If you select the KMail Folders line and then "Modify", you will get a very small window which displays an editable and therefore changeable location of the KMail Folder files. This makes no sense to a stand-alone user, because it is NOT an account - it is simply a filing location for KMail's email files on the user's own computer and why would you want to shift the files internally in the first place ? However, it does make sense from a multi-user/networking position. Suppose that KMail is running on a networked computer and the location of the KMail Folder files is on the principal server of that network or at least on the computer of another member of the network. The KMail Folder location will then have to be altered to match that new location and now it is quite possible for that new location to be "offline" while Bigpond is "online" - or vice versa. Assuming this hypothesis to be true, it begins to suggest that KMail has now been redeveloped for large-scale, multi-user networks, not single users, and that KMail is no longer a simple and elegant "stand-alone" email client but instead an integrated networking email package of considerable complexity with its main development objective being to provide multi-user support on a network. To continue a setup via this procedure, the next step is to select the Bigpond line and then "Modify". If you do that, you will get the window in the following image. I have deliberately left the background windows in place so that an exact idea of where the user is on the menu tree can be easily obtained but, as can be seen, a window that is "similar" to the earlier version of KMail has now been reached.  The Effects of KWallet There is however, one very large difference: the Password area has been greyed out and it is thus impossible to store the ISP password in KMail. This is because this latest version of KMail now has mandatory dependency on a totally separate software package: KWallet, and there is no other option if you wish to store an ISP/server password. Unless you use KWallet, KMail will insist that you insert your password each time you log onto the ISP/server that holds your emails in order to receive them. The first time I managed to get this later version of KMail actually sending and receiving, I became very frustrated at the way I had to constantly insert my password to obtain any inwards email transmissions, purely because it had been unnecessary in the past. I should like to record that somewhere in either 2011 or 2012, I managed to contact the KMail team and had limited correspondence with one of the members. I suggested that there was no reason to change this particular aspect of the password for KMail and that it should be a choice of the user as to whether or not they used KWallet or inserted a password as usual at this location on the entry window. I was told very bluntly that this aspect had been changed and there was no possibility that the original easy method of storing the password in KMail would be restored to the software package. The team member gave me no reasons for their decision to make KWallet mandatory for all users who wished to store their ISP/server access password. Whilst at the time I was very irritated at what I saw as a removal of choice (and the abrupt dismissal without reason by the KMail team member), the answer I was given makes complete sense if you consider the situation from a multi-user, networking perspective, not a stand-alone perspective. Mandatory use of KWallet is, I think, security overkill on a grand scale for a stand-alone user, but for a multi-user network, it makes complete sense, and again one is left with the impression that KMail's principal development direction is aimed at such a multi-user network. When I last managed to run KWallet in a test mode, I inserted the KMail ISP password into the Wallet, but I then set the Wallet password to a single Enter/Return key stroke in both the first and second entry locations. This meant that KWallet automatically opened for KMail when Receive Mail was requested and of course, I totally nullified KWallet security by my pursuit of ease of use. Another problem was that KWallet seemed to link itself into my web browsers. I began to find that unless I used the "open KWallet" method described above, the browsers were beginning to demand passwords from KWallet at various points of operation and that is something that has never happened to my computer use previously. As a "stand-alone" user, I personally found KMail's dependency on KWallet overly complex, clumsy, very frustrating to use and intrusive on my daily work. Akonadi and Nepomuk Whenever this later version of KMail is now started, there is a fleeting information window which indicates that the Akonadi/Personal Information Manager is starting. If Akonadi is turned off, my experience thus far is that KMail then refuses to start because it is so closely integrated with and dependent upon the Akonadi software. The services offered by Akonadi, as far as I am able to assess, are all involved with Kontact and its attributes of a calendar, diary and personal contacts. I have never used Kontact and never will, and while its services might be useful to a stand-alone user, I think they would be more or less indispensable to users on a large-scale, multi-user network. Unlike earlier versions of KMail, I also found that this latest version of KMail complains and warns you of difficulties if you turn off Nepomuk (the desktop data sharing program) which is also involved with the calendar and diary structures. While this is only "oblique evidence", cumulatively I once more am led to the feeling that the direction of KMail's development design has leaned very strongly towards the needs of the networked user. Conclusions and a Solution The most frustrating part of all of this is that when considered strictly on its own, the KMail software package remains superb as an email client. If it wasn't for the introduced dependencies, the complexity of KWallet and password storage, and finally Akonadi and Nepomuk and their associated integration into KMail, I'd be delighted to remain on this exceptionally good email client. I'd also like it stressed that I am in no way against the development of KMail for the use of multi-user networks, it's a great idea. Conversely, I am somewhat dismayed because I think that for the stand-alone user, KMail has been made over-complex and more difficult to use with it's associated software packages and excessive security requirements. Personally, I do not wish to leave KMail, but I am no longer comfortable with its operational processes as a stand-alone user. My current perception is that KMail is no longer a piece of software dedicated to easy reception and transmission of emails by a "stand-alone" individual; instead, KMail has become an integrated, business package with attached data base software and security measures that are designed to facilitate the diary, calendar and personal contacts of a person who is part of a large, multi-user, computer network . KMail is now aimed at such places as government, education and commercial enterprise. Well, right or wrong, that's how I see it anyway. I would very much like to see a separate and simpler version of KMail (KMail Light ?) which is able to run wholly by itself as a stand-alone email client without any other software package dependencies and I invite the KMail development team to re-consider the simple, stand-alone elegance of KMail in its earlier versions up to and including version 1.13.6. Any extras should be "add-ons" made by choice of the user. Note that I do not imply that version 1.13.6 is perfect, it isn't, and there are some small things that need fixing, like where each directory folder opens, but these problems are relatively trivial. The solution I am very strongly leaning towards is Thunderbird. It has a wizard that allows the software to be set up and running within two minutes - I have trialled the wizard setup. Thunderbird's layout can be structured to resemble KMail virtually completely, and it saves its password internally (the same system rejected by the KMail developers) so that no "Catch22 situations arise with KWallet". In any event, Thunderbird is wholly independent of KWallet, Akonadi and Nepomuk, all of which can be disabled without affecting any aspect of its operations. My experience so far is that Thunderbird so closely provides/resembles the layout, operations, simplicity, speed and intuitive nature of the earlier, stand-alone versions of KMail that there will be no difficulty at all in using Thunderbird as an alternative email client and I candidly admit that the Thunderbird option looks very attractive. Currently, I'd be happy to suggest KMail as a good email client for a multi-user network; but I cannot and would not recommend the present versions of KMail to anyone who requires a simple, stand alone, email client, solely dedicated to email transmission and reception - because in my personal view, KMail no longer fits that description. I would however, even from the brief trials I have given to the software, suggest that Thunderbird be considered for that purpose. In the Introduction, I mentioned in the second paragraph that one of the things I enjoy is playing card patience games. (Oh, alright, I also have Shisen-Sho and Mahjong solitaire - what utter decadence ! And I must admit, the KDE4 versions are very, very good.) The first game I enjoy is Freecell and I prefer the Redmond version which I have running in Wine.....But the other game set I really like is the KDE patience package which comprises a large group of solitaire games including Freecell, Klondike, Simple Simon and Spider. In my opinion the patience package currently found in KDE4 ("kpat") has now been degraded by over-development. The patience package that I prefer came with KDE3.5. The card decks are crisply displayed, and the in-game animations are minimal; the cards are dealt almost instantly (to any columns being built) as and when required. When a number of cards reach a column, the column simply remains static on a plain green background and if you want a larger playing area because you cannot see some of the cards, you drag the boundaries of the software window or you scroll....Experience showed that rarely happened. It's "hint" services to see what optional moves are available during a game are also excellent and relevant to the state of the particular game being played. The Degradation of "kpat" The latest versions of patience that come with KDE4 are now "developed" to the point where using them is a "turn-off", not a "turn-on". If you distribute a number of cards to a column, the column wiggles and readjusts itself as regards its length, and you find yourself irritated and distracted as you watch these maneuvres. Dealing a new set of cards during a game is distracting when the cards "ooze"out in a fan over the playing area, and thus far I have found no way to speed up this slow process and make a new deal instant. The game seems to emphasise slowness, not speed. The display crispness of the original game's card decks also seems to have been lost with the latest kpat card decks appearing to me to be slightly "blurred". The "hint" services supplied by the KDE4 patience package seem to have lost the accuracy of the earlier KDE3.5 version and often they appear irrelevant to your proposed moves. Whatever, even though you can get the same card deck and background as the KDE3.5 patience software, I do not like the "kpat" patience package as it is presented with KDE4. Cue Gallop fanfare from "The William Tell Overture" at this point. http://www.youtube.com/watch?v=4JC8_vuFaRw OpenSUSE Cavalry to the Rescue However.......openSUSE has apparently realised that others feel the same way as I do, and in the latest openSUSE 13.1 repository you will find in the games section, a listing for the card games of KDE3.5 (as well as the KDE4 version). Select the KDE3.5 package and all the necessary library adjustments required to play this earlier version of patience will be made and the package installed on your computer. Now that's really nice for me (and others of my style of thought), but it should spell something out to the KDE4 patience developers: "Additional complexity is not always the way to go; why break something if it is working perfectly ?". The KDE3.5 patience package remains superb, and for sheer pleasure of playing a game with a crisp, clear and simple display, this earlier patience package beats the KDE4 "kpat" package very solidly as far as I am concerned. Try it and see. (Note: Always start it from the Application Launcher Menu where under Games, it will be clearly shown as the KDE3 Patience card game. If you don't, you will end up with the unwanted KDE4 package, if it is installed. Once I have the KDE3 package installed, I always remove the KDE4 "kpat" package - it's redundant - and then you can put a starting icon on the desktop if that's your pleasure.) A very cynical thought for the day. The average person says: "If it ain't broke, don't fix it." The software developer says: "If it ain't broke, add 'improvements' until it is !" Funny........but I think I may have just described exactly that. |
|
| Subject | Topic Starter | Replies | Views | Last Post |
|---|---|---|---|---|
| kmail | nmset | 51 | 9,757 | Jul 18, 2014 6:33 AM |
You cannot post until you login.