[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: RFC: new KPanel application menu
From:       Stephan Kulow <coolo () max ! tat ! physik ! uni-tuebingen ! de>
Date:       1999-07-13 11:45:35
[Download RAW message or body]

Pietro Iglio wrote:
> 
> At 12.35 13/07/99 +0200, Stephan Kulow <coolo@kde.org> wrote:
> >
> >Well, I think, copying these files is _completly_ unacceptable. In our
> >university (just as an example) we have 380 users. My current
> >KDEDIR/share/apps
> >has 291 kbyte in 167 files (wow - there aren't even core files :). This
> >would
> >mean 110MByte just that the user sees the global entries.
> 
> Well, this could be solved with a copy-on-write strategy:
> 
> - if a file is not in the personal dir, but is in any global dir,
>   then the file appears in the menu;
> 
> - when the user changes/moves a desktop file, a copy is created in the
>   personal folder;
> 
> - if the user deletes a file that is in any global dir, a corresponding
>   desktop file is created with an entry "Deleted=yes" (so that the file is
>   not added to the menu);
> 
> Are you satisfied with that?
Yes, and why do you need the two levels for then? 
> 
> About the 110Mb for desktop file: can you tell me the size in percentage
> respect to the total size of .kde folders? I'm afraid that you already
> need huge hard drives to host 380 users...
Well, my current .kde has 116KByte with 72KByte taken from kregistry.
291kb
plus for almost no gain is nothing I can really see good things in :)

BTW: a much can be gained in .kde size when Kconfig wouldn't save
entries
there when they're the same as in the global config.
> 
> >I can't see how this would be harder. I think, Waldo already proposed a
> >way to handle this.
> 
> I have to look at the details, first.
> 
Sure.

Greetings, Stephan

-- 
As long as Linux remains a religion of freeware fanatics,
Microsoft have nothing to worry about.  
                       By Michael Surkan, PC Week Online

[prev in list] [next in list] [prev in thread] [next in thread]