diff options
| author | Timothy Pearson <kb9vqf@pearsoncomputing.net> | 2013-01-26 13:17:21 -0600 |
|---|---|---|
| committer | Timothy Pearson <kb9vqf@pearsoncomputing.net> | 2013-01-26 13:17:21 -0600 |
| commit | dfe289850f068f19ba4a83ab4e7e22a7e09c13c9 (patch) | |
| tree | c297348a55df66c571de4525646e0b9762427353 /tdecore/DESIGN.iconloading | |
| parent | b7658a0d5eca24a9d37c6e04f88298ef02389db0 (diff) | |
| download | tdelibs-dfe289850f068f19ba4a83ab4e7e22a7e09c13c9.tar.gz tdelibs-dfe289850f068f19ba4a83ab4e7e22a7e09c13c9.zip | |
Rename a number of libraries and executables to avoid conflicts with KDE4
Diffstat (limited to 'tdecore/DESIGN.iconloading')
| -rw-r--r-- | tdecore/DESIGN.iconloading | 6 |
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 |