KIconLoader Followup

Luke Alan Sandell kdespam at luketopia.net
Tue Jun 7 03:08:46 CEST 2005


First, I would like to thank everyone who responded to my previous post. I
never expected so many responses so quickly. Since I composed that message
it has been revealed to me that Google is only allowing 200 participants in
their program (forgive me, I was not even aware of the program until it was
announced on dot.kde.org). In practical terms, this means that if I want to
actually have my proposal accepted, it will have to be something a little
more earth-shattering than a cache for KIconLoader. To this end, I have
sent a proposal to bounties at kde.org, being graphical editors for kcfg and
kxmlgui, though even this seems to have limited usefulness. All this means
that I will no longer plan on doing anything with the icon loader per se.

However, while we're discussing this, let me put in my $0.02. I have read
over the replies, and there seems to be two recurring themes. This is not
just an issue for KIconLoader; I see other classes that could potentially
share data across applications, such as KStandardDirs.

1. Shared memory _cannot_ be used, because it needs to be synchronized. If
individual processes handle the synchronization, there is the prospect of
desktop-wide deadlock if one of them crashes during a data access (can you
say "Windows"?). Therefore, some sort of "server" must be used to
synchronize accesses, even if it is as simple as a dcop service. 

2. A problem with sharing data between applications is that even if
applications use the same data 99.9% of the time, there is always the
possibility of an application doing something differently (adding a icon
path, for instance). For this reason, if data sharing is to take place
between applications, the class that facilitates the sharing must
distinguish between application and system-wide data, hiding the former in
the individual application but sharing the latter.

Now, what there really needs to be is a set of classes for sharing data (not
memory) between applications, because no library developer is going to want
to explicitly create a client/server every time (s)he wants to share
something. Perhaps that is something I could run with...

Regards,
Luke Sandell



More information about the Kde-optimize mailing list