1 files changed, 3 insertions, 3 deletions
diff --git a/tdecore/DESIGN.iconloading b/tdecore/DESIGN.iconloading
index bcfb13c95..a9e57afbd 100644
--- a/tdecore/DESIGN.iconloading
+++ b/tdecore/DESIGN.iconloading
@@ -58,7 +58,7 @@ can copy this pixmap:
    // p contains now 30x30 pixels of test.png.
 
 The only hard part is then to publish the icons in a way that applications 
-know what to copy. I'm thinking about a ksycoca-sort-of index that 
+know what to copy. I'm thinking about a tdesycoca-sort-of index that 
 applications can map and can use to do fast lookups with. This has no major 
 problems except for the race-condition that might exist when an icon is 
 removed. In that case you will remove it from the index first and then later 
@@ -79,7 +79,7 @@ sure that the index will no longer be used.
 
 I think the best way to distribute the index information is through the file 
 system but the update mechanism for this file should probably more complex 
-than the one used in ksycoca. Since ksycoca updates only happen once in a 
+than the one used in tdesycoca. Since tdesycoca updates only happen once in a 
 while, we can afford it to write out a whole new file. For icons this will 
 probably be more difficult since updates will be part of normal operation, if 
 the index file is rather large (no idea about that.. how much icons are in 
@@ -182,6 +182,6 @@ KDE 2.2: We deliver.
 <pmax> oh I see
 <Zogje> to answer you rfirst question: "won't the ipc be a bottleneck?" no, because you don't use ipc in the critical part (the icon loading)
 <pmax> yup I understand how it works now I think
-<Zogje> instead you access an index from disk which is quite fast (as fast as ksycoca)
+<Zogje> instead you access an index from disk which is quite fast (as fast as tdesycoca)
 <pmax> I think this will definitely speed things up on my machine since I have a relatively fast box with slow disks
 <Zogje> that's why I want to use the file-system instaed of X-properties