Table Of Contents
|1.||7 Sep 2003 - 9 Sep 2003||(7 posts)||kdesupport is dead, long live kdesupport?|
|2.||7 Sep 2003 - 8 Sep 2003||(12 posts)||konqueror/khtml state|
|3.||11 Sep 2003 - 13 Sep 2003||(6 posts)||Excessive KMail memory usage|
|4.||4 Sep 2003 - 6 Sep 2003||(10 posts)||Kmail use fixed font shortcut changed|
|5.||8 Sep 2003 - 9 Sep 2003||(15 posts)||Kpaint enhancements?|
|6.||4 Sep 2003||(5 posts)||Moving KPovModeller|
|7.||11 Sep 2003 - 16 Sep 2003||(20 posts)||kppp in kdebase|
|8.||1 Sep 2003 - 4 Sep 2003||(47 posts)||KWallet integration|
|9.||6 Sep 2003 - 7 Sep 2003||(6 posts)||Libkabc Performance|
|10.||10 Sep 2003 - 17 Sep 2003||(20 posts)||libkcal and KArm|
|11.||6 Sep 2003 - 14 Sep 2003||(24 posts)||Storage for KDE|
Hi, it's late again, I had a lot of work to do, etc. My priorities have been a little screwed up, and I'm trying to make that right. It's not easy.
I'll have a little treat towards the end for all you electronics-philes. And maybe if I manage to get something done with that microwave power transformer I just salvaged, I'll have a little treat for my enemies too.
Anyway, on with the show..
Mailing List Stats For This Week
We looked at 1683 posts in 7685K.
There were 378 different contributors. 204 posted more than once. 142 posted last week too.
The top posters of the week were:
1. kdesupport is dead, long live kdesupport?
7 Sep 2003 - 9 Sep 2003 (7 posts) Archive Link: "kdesupport is dead, long live kdesupport?"
People: Stephan Kulow, Daniel Stone, Reinhold Kainhofer, Rob Kaper, George Staikos
Stephan Kulow asked:
Has someone emotions connected to kdesupport? We had it in older releases already only for CVS users, but I don't have the feeling that many use it. I'd like to get rid of it for good.
George Staikos stated that he didn't even know if he needs what's in there, and made the point that it could be useful for non-linux systems where packages aren't always available. Stephan countered that nothing in there is needed by KDE and there are lots more libraries and tools that extend KDE that are not in kdesupport.
Rob Kaper said that he didn't think KDE needed to put resources into adding a more convenient way to offer depenencies, and that it's not KDE's goal to replace the responsibility of distributions. And Daniel Stone, in his typical Australian style, was much more blunt, saying, "Please just document the deps and kill kdesupport. "
Reinhold Kainhofer said KDE needs to build a list of dependencies.
Looks like the concensus among respondents is to ditch it with extreme prejudice.
2. konqueror/khtml state
7 Sep 2003 - 8 Sep 2003 (12 posts) Archive Link: "konqueror/khtml state"
People: James Michael Greenhalgh, George Staikos
Arnold Krille had a laundry list of problems with his KHTML build and kwallet. There was a "me-too", and George Staikos responded, with barely controlled patience, that kwallet is experimental code and under development, and it may be broken, and if you don't like it, then disable it.
Arnold Krille said fine, but how?
George Staikos told him to draw a pentagram and mutter "Oh great KDE god, show me the way to true enlightenment". No, actually, he said to install kdeutils and disable it with the kwallet kcm.
Arnold Krille said he didn't have enough disk space.
James Michael Greenhalgh showed him how to do it without kcm.
3. Excessive KMail memory usage
11 Sep 2003 - 13 Sep 2003 (6 posts) Archive Link: "excessive memory use"
People: Don Sanders, Dirk Mueller
JES (Edwin) noted that kmail was using a very large amount of memory, and wanted to know what part was doing it. Ingo Klö said that he noticed dramatic increases when he searched multiple folders for certain messages. To which Don Sanders wrote another book:
I need to do some profiling but there are a couple things that are concerning me, and that I'm looking into.
The first is in kmsearchpattern, previously there was a matches( DwString ) method that was called by kmfoldersearch. This method used mmap so that for searching except for complete message and body searching only the message headers ever had to be loaded from disk.
Now this method isn't used anymore and it means that for all searches the complete message has to be loaded from disk and parsed.
Another thing that is concerning me is something that isn't new at all, but for some reason it didn't really occur to me how much of a problem it is until recently. And that is the number of virtual methods in the message classes. I count 56 in KMMsgBase alone, and there are more in KMMsgInfo and KMMessage. This is bad news for a global search that opens all folders this means for my some 400,000 messages, at least 100MB of ram will be needed.
Now part of the problem here is that searching now opens all folders searched, where as previously only one folder was kept open at a time. But rather than try to minimize the number of open folders, I would prefer to make opening folders cheaper memory wise by fixing the problem with the message classes being so heavy. This will also have the additional benefit of making filtering cheaper memory wise also, since filtering keeps all folders accessed open.
I'm working on addressing both of these issues as part of the imap client side filtering and asynchronous filtering patch. But these kind of issues are meaning that it's taking me longer to finish than I had initially expected. Hopefully I'll have something ready in another 10 days, but it would be nice for me if no big changes are made to the message, and filtering classes in the next 10 days.
Dirk Mueller noted that virtual method tables are allocated per class, not per class instance. Don responded that he felt stupid. It was of course not clear who stupid was, and whether she went along with it.
4. Kmail use fixed font shortcut changed
4 Sep 2003 - 6 Sep 2003 (10 posts) Archive Link: "heads up: changing of default shortcut for "Used fix font""
People: Aaron Seigo, Ingo Klöcker, George Staikos, Don Sanders, Stephan Kulow
Aaron Seigo said:
unless someone speaks up in the next 48 hours, i'm going to be committing a change that removes 'x' as the default accelerator for "Used fix font". the new default will be no accelerator. the reason for this change is:
o this is a feature useful for those who recieve ascii-art, patches, etc. these are not your typical email users, but constitute a small and almost exclusively advanced set of users. they tend to know how to set up a shortcut.
o those who accidently press 'x' are usually not in the former category of users, and therefore have no idea what just happened to make their kmail reader window look completely crappy. nor do they often know how to set up custom shortcuts for such things.
o i'm growing weary of telling users on IRC, mailing lists, etc to press 'x' to "fix" their fonts in kmail, only to have them tell me what i already know: that it's a bad default. why? because:
o 'x' is awfully close to other common shortcuts. like "Cut". and it isn't well documented.
i hope that line of reasoning is exhaustive enough. silence is golden, but speak up if you have issues with this being changed. thanks =)
Ingo Klöcker replied:
Bah. If you think it's really necessary to remove this shortcut then go ahead.
While we are at it: There are some much more important shortcuts which should be changed. Proposal (press x for a nice tabular view ;-) ):
Action New Shortcut Old Shortcut Select All Messages Ctrl+A k Select Message Text Ctrl+Shift+A (?) Ctrl+A Move to Trash Delete d and Delete
- Typing "kde" in KMail can cause heart attacks. Several people at Nové Hrady told me that it has already happened to them (not the heart attack, but the "deletion" of all messages in the current folder). I have been convinced that single character shortcuts should not invoke "destructive" actions. Therefore I propose to remove the binding of 'd' to "Move to Trash".
- Ctrl+A is the standard shortcut to select all (text in editors, files in Konqueror). I think that Select All Messages is used more often than Select Message Text (which is IMO hardly useful because it also selects the header and all embedded text files). Therefore I propose to use Ctrl+A for Select All Messages instead of for Select Message Text.
Of course, Ingo should know better than to ask for comments on a KDE list.
George Staikos replied:
Unfortunately single key accels are really quick and useful in a mail app. However, you're right, they are dangerous. This is especially true in a sloppy focus environment.
I only ask that kmail developers can sit down and decide on new defaults once and for all. Changing accels in kmail is really painful. I think I use the mouse only for changing folders and moving email now.
Oh and one more thing, at least in 3.1 branch and the last time I tested head, hitting a single key that was not bound to a keystroke made it jump to the next folder that begins with that letter. That one is really annoying. It would be nice if that could be fixed.
Ingo replied that he didn't think that there are any other accels to change. He also gave George two hints: m to move messages, and Ctrl+Left/Right in combination with Ctrl+space to change folters.
Don voted for the changes except for changing d and Delete to just Delete. He also liked the idea of getting rid of the 'k' shortcut. He also thought fixing the "bug" that Groege mentioned probably makes sense.
Stephan Kulow replied that d is just too dangerous for the average user, and suggested putting it in profiles. He stated that no KDE application should hade single key shortcuts for destructive actions by default.
Don Sanders said that makes sense and revoked his objection.
Malte said he didn't know what the problem was about the unbound keys jumping to another folder. George responded that it's irritating when he's on imap on a slow connection. Malte conceded the point.
5. Kpaint enhancements?
8 Sep 2003 - 9 Sep 2003 (15 posts) Archive Link: "KPaint"
People: Michael Thaler, Dominique Devriese, Nicolas Goutte
Michael Thaler started by asking:
I was thinking about writing a little KDE paint application. Since I am new to KDE programming I cannot write an application from scratch and I was thinking of improving kpaint. I already read through the source and I understand most of it (I hope).
First of all, how can I compile just kpaint? I don't know how to use automake and I don't want to write my own Makefile. Is there a possibility to use the Makefile from kdegraphics and just tell it to only compile kpaint? There are two Makefiles in the kpaint-directory: Makefile.am Makefile.in. Can they be used to create a Makefile somehow?
Second, reading through the code, I saw that there is a manager-class that handles the drawing tools. Why is this necessary? Wouldn't it be more clean to just use KRadioAction to create the toolbar for the drawing tools? The advantage would be, that one can use XMLUI and that the code is easier to read. Is there some reason, why KRadioAction is not used?
I also think, the GUI can be improved considerably. First of all, I think it makes not much sense to set line properties etc. globally. It would be nicer to have a configuration dialoge for each tool to set line width, filled/not filled (e.g. for squares), rounded corners etc. We would get rid of at least two toolbar actions: Tool Properties and the Round Angle tool.
I think a fill-tool would also be very nice. I guess with the current approach of KPaint it is not possible, because we cannot read out pixels from QPixmap. I think, a solution would be to paint to QPixmap and also to QImage and read the pixels then from QImage. GPaint has a fill-tool, so maybe I will have a look, how they do it.
It would be also nice to have some tools to oilify the picture etc. like GPaint.
It would be nice if you can give me some hints how to setup a Makefile so that I can get started. I think I will set up my own CVS version, because I don't know if I get my inteded changes working and I don't know how much time I find for that. And I do not want to work on an official KDE application right now:-)
Dominique Devriese stated that he liked those ideas for improving KPaint. Nicolas Goutte asked him to consider helping out KOffice and Krita.
6. Moving KPovModeller
4 Sep 2003 (5 posts) Archive Link: "is it time to move kpovmodeller ?"
People: Joseph Skinner, Stephan Kulow
Joseph Skinner asked:
Back a while ago there was a call to move kpovmodeller to its own package. Is this a good time for that to be done.
The aguments at the time where that it was huge compared to anything else in the module and was ratehr specialised. As it is I can't see how any of these arguments are any less relevant now.
In my consideration it is past time that it was moved into its own package especially when you consider that it is over 2.5 times as big as the next biggest item in kdegraphics and is almost as big as the entire kdeutils package.
Nicholas Goutte noted that Stephan Kulow vetoed. Didn't get much farther than that.
7. kppp in kdebase
11 Sep 2003 - 16 Sep 2003 (20 posts) Archive Link: "kppp in kdebase"
Mikolaj Machows gave a bunch of reasons why he thought that kppp should be moved from kdenetwork to kdebase. Manuel Amador enthusiastically agreed. Most others disagreed, saying that kdebase is quite bloated already, and that a dial-up connection isn't quite common enough (who thought they'd hear THAT ten years ago!)
Concensus seemed to be that it's a bad idea.
8. KWallet integration
1 Sep 2003 - 4 Sep 2003 (47 posts) Archive Link: "KWallet integration"
People: Duncan Mac-Vicar, Tim Jansen, Waldo Bastian, Scott Wheeler, Martijn Klingens
Disclaimer: I contributed to this thread, but forgot about it :)
Duncan Mac-Vicar said:
Hi, I have seen the recent integration of KWallet for password managment. Kopete is already integrated with this technology.
What worries me is the current message. The first time you run Kopete it tries to retrieve the password from KWallet it display a very scary message like "Kopete is trying to open application KWallet" Allow Yes/No/Always.
I don't know how this works under the scenes but I think the message could be changed to something more descriptive and less "panic" like "Kopete needs to retrieve a password from KDE Password Manager".
Tim Jansen said:
IMHO this should be turned off completely by default. It does not add any additional security. If Kopete is malicious or the user has any other virus/ trojan horse running it will not help anyway, there are thousands of ways to get the passwords and the only thing that may prevent the attacker from doing this is the password encryption of the wallet.
If the user has a password for the wallet, just ask for it and say that kopete requested it. If there is no password or the user already entered it, there should be no feedback at all. The idea of KWallet should be to make the user's live easier, not to display dialogs that people will stop reading after a while anyway.
Martijn Klingens stated that the dialog is necessary, and that he agrees that the dialog can be made less intrusive, but he doesn't think it should be disabled completely by default. Waldo Bastian suggested a wording change.
Scott Wheeler said the kwallet messages were confusing him, and made the point that allowances need to be made for the fact that a large number of users won't practice safe computing.
This migrated to a discussion on general security practices and how kwallet fits with them.
9. Libkabc Performance
6 Sep 2003 - 7 Sep 2003 (6 posts) Archive Link: "libkabc as a performance issue..."
People: Zack Rusin
Reinhold Hainhofer noted that there were some very significant performance problems in libkabc. Several respondents noted that automaticSave is called even when it's not needed. Zack Rusin said:
I'm working on some very significant optimizations for kabc. This thing will stop being a problem. Pretty much everything in kabc is of linear complexity. I reduced most of the slow paths to either O(logn), or just O(1) when possible. I'll present the changes in a bit. I had a car accident and it slows me down a little bit.
10. libkcal and KArm
10 Sep 2003 - 17 Sep 2003 (20 posts) Archive Link: "libkcal and KArm"
People: Mark Bucciarelli, Reinhold Kainhofer, David Faure
Mark Bucciarelli said:
In order for 3.2 KArm to work properly, the infiinite loop when deleting and todo / event must be fixed. I am willing to help, but I'm not sure how to fix it. The best solution I could come up with was to decouple things and have an ical object signal that it was being deleted and have all interested parties react accordingly (I'm assuming signals and slots would work for this).
The other major libkcal issue is data loss when a user opens the same ics file with KOrganizer and KArm. File locking would be the simplest solution. Allowing multiple apps to open the same ics file at the same time is more user friendly. The first solution is in the 3.2 feature plan and IIRC so is the second.
Please keep me posted when either/both of these libkcal features are put into place so I can update KArm to use them.
Reinhold Kainhofer stated that he thought Cornelius fixed the infinite loop. The cvs thread covered previously made a second appearance at this point.
David Faure noted problems with KArm. Then replied to himself. Then Mark and David bounced back and forth. David won.
11. Storage for KDE
6 Sep 2003 - 14 Sep 2003 (24 posts) Archive Link: "Storage implementation in KDE"
People: Brian Ledbetter, Luke Chatburn, Tim Jansen
Brian Ledbetter said:
I saw this on Slashdot yesterday, and think that it would be fairly easy to develop something like this using KDE's kioslave interface.
I envision something similar to what Seth has created, with some additional features:
* The ability to connect to more than one database server, creating "data workgroups" of sorts. (Imagine this as being your workgroup file server, except it lives in a database)
storage://(user)@(server)/search/movies+by+speilberg storage://(user)@(server)/search/albums+by+Loudness Searches storage://(user)@(server)/file/id/664486430549 Direct file access by fileID. Would also provide access to other user's shared files, if permission is granted to (user). storage://(user)@(server)/allFiles/byName/ storage://(user)@(server)/allFiles/myFiles/ storage://(user)@(server)/allFiles/byType/doc/ storage://(user)@(server)/allFiles/byType/pdf/ Different ways of narrowing your search down, without actually having to search.
* The ability to connect to more than one type of database (Oracle would obviously be the best suited for large file stores, though PostgreSQL is certainly a distant second best)
* Some simple file browsing semantics, for cases in which the user doesn't know exactly what they are looking for.
* An offline file cache, so users can continue working even though the database server is not accessible.
Would anyone else be interested in creating something like this for DE? I think that something like this could be invaluable for enhancing KDE's reputation as a serious professional desktop solution. I certainly think we can make the user interface second-to-none! :)
David responded that it's an interesting concept that shouldn't be excluded from KDE options but questioned its usability in practice. He suggested instead mapping a filesystem API on top of a traditional database.
Gary Greene responded that that's what EA (Extended Attributes) are for.
Stefano Borini agreed. Luke Chatburn made the point that metadata based filesystems generally aren't user friendly and they don't scale well. in full:
I don't weigh in too often on these threads, but I'd like to make a few points (feel free to flame :) ).
In general, metadata based filesystems are not terribly user-friendly, worse, adding a database into the mix can produce a disaster.
First and most important point:
- Metadata does not scale well. It's like having a desk in an office and filling it with pieces of paper. It works fine if you have a limited quantity of pieces of paper, but for business and for regular home use over a period of time, you do need organisations. In the real world, this is in the form Room->Filing Cabinet/Box->Folder->Document. It's a normal heirarchical file system. That's not to say that a relational look-up can't help with a few things, but is can't be used for everything.
- Metadata searching is very, very expensive in processing terms and worse for larger document sets. Moreover, you limit yourself by I/O abilities.
- Using a database for metadata means that you have to have the service running constantly in the background. Security considerations should be inserted here. Moreover, it is taking up cycles and a very significant chunk of memory. The more files, the worse the footprint. SQL dbs are huge, really, especially when you add the interpretation stage for SQL on top of the myriad of different functions they have to perform. You could write a completely fresh, light-weight DB for this, if you liked, but it is hardly ideal, and we'd spend two or three years bug and security-fixing the thing.
- Namespace collisions. Every run across a problem where you had to work with documents with the same name, one for one purpose and one with a few changes for another, in another folder (clearly marked as the other purpose, hopefully!)? The system will have to display many results and offer a clear indication to the user where the file was contained. Moreover, often users will identify files based upon other files in the same location. Metadata can compensate for this, but it isn't easy.
- The user or applications must specify metadata for different files constantly and consistently. We can't get MIME types to always work effectively, so how do we get all applications to play nicely with this?
- Users are used to thinking in a heirarchical manner. They don't especially want to Google for their data and then have to manually sift through the results for the right one.
With all of that having been said (and there are ther arguments), I do agree that metadata can be valuable for augmenting existing search facilities. In order to do this effectively and within a reasonable time, however, it needs to be done at the filesystem level, not by a high-level system embedded in KDE. ReiserFS 4 should allow us to do these things with relatively little system slowdown, which is why I look forward to it so avidly. Smarter filesystems are the key, really, but not SQL database-based FSs.
I have been thinking that someone might float an idea like this for a while now, and it shouldn't surprise me that the Gnome folks decided to blink first and give it a go. It was evident as soon as Microsoft mooted it as a feature in Longhorn, and it was also evident that the problem was non-trivial and that there were a large number of very critical issues.
The point most worth making, however, is that Windows is stuck at a point where they seemingly can't develop further in application or DE usability/functionality and they're going for frills. To be frank, though, most users don't have a difficult time finding their files (assuming they understand the concepts of directories, however). They spend 99% of their time sitting staring at an application trying to do work of some kind. I believe that there is significant innovation taking place in other aspects of the KDE project and applications, and that efforts are better served focusing there. When Reiser 4 turns up, this stuff will be trivial to implement, but until then, it's duplication of that effort.
To be honest, there are a number of areas where genuine progress can be made to make a real difference, almost immediately. Merging of instant messaging with PIM components is a start. Some sort of development to the KDE Notes system to assign notes to any document in any application and when the same program opens the same document again, they get reopened would be a great improvement to workflow.
If you really want to try something radical, implement this idea I floated with the Slicker folks (they seem to be dead atm):
KDE is already very strong in network transparency, but adding in collections of documents, contacts, messages, services/web services and other data on a project basis would be a powerful productivity tool.
At the moment, metadata searching really isn't ready for primetime, and the benifits are dubious. Don't let me stop you, but beware! :)
Tim Jansen mentioned that authentication and permissions is a problem as well.
Stefano had some things to say in response, but that already was very long..
The rest of the comments really didn't come up with much new.
And for being late, here's the icing on the cake (uga). I've taken an interest in electronics lately, and I've been pointed by the nice people on #electronics to a really cool book:
Lessons in Electric Circuits (http://www.ibiblio.org/obp/electricCircuits/)
I learned a lot, and I bet you will too.
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.