WARNING.
This change makes the current KDE-1.2 incompatible with KDE-1.1.1 !!

If you start an app linked to kfmlib-1.1.1, it will look for ~/.kde/share/apps/kfm/pid_0.0
but kfm (from KDE-1.2) will not write that file, but ~/.kde/share/apps/kfm/pid<HOSTNAME>_0.0
so nothing works.

It means one can't use KDE-1.2 base apps (kpanel, kfm) with KDE-1.1.1 libs
(which was the point about keeping binary compatilibity, right ?)

I just stumbled upon that problem, and I can tell you it's very annoying
when the panel can't start anything.

(I'm glad we know have krun to prevent those problems !!)

The question now is : do we want to revert this, in order to keep compatilibity
with 1.1.1 libs, or do we rely on anybody using kfm-1.2 to ALSO use kdelibs-1.2 ?

On Wed, Jun 02, 1999 at 10:40:12AM +0200, Matthias Hoelzer-Kluepfel wrote:
> Hi,
> 
> I just commited a fix to the KDE_1_1_BRANCH that deals with
> KFM deadlocks if you run KDE from several machines with NFS
> mounted homes.
> 
> The problem:
> 
> KFM generates a lock file like
> 
> .kde/share/apps/kfm/pid$DISPLAY
> 
> This works well if you start KDE with startx, but it fails if
> you run KDE via KDM, as KDM will set the $DISPLAY var to ":0"
> for the local display. I fixed it with explicitely prepending
> the local host name.
> 
> There are several places in KDEBASE where a function
> "displayName()" is used. For 1.1.2, I fixed them all. For 2.0,
> I think this function should go to the libs. My only question:
> 
> Where should I put this function? 
> 
> Bye,
> Matthias.

-- 
David FAURE
david.faure@insa-lyon.fr, faure@kde.org
http://www.insa-lyon.fr/People/AEDI/dfaure/index.html 
KDE, Making The Future of Computing Available Today