On Tuesday 16 September 2003 07:43, Helio Chissini de Castro wrote:
> Ok, the problem is not so simple really.
> To solve this problem, we need attack applications as well.

  Sure but I think the solution will be in kdelibs still... somewhere.

> Today we can't identify version/release from applications. There aren't any
> identification that the /usr app is older than /usr/local.

   You don't want to keep the version in every associated file though...

> If we have an basic info, like version with release date ( developer could
> be released same app version with lot of bug fixes, so date makes sense ),
> and so doesn't matter how many apps you identify in kdedirs. This can be
> very usefull even for test, if we add a configuration dialog, that can
> choose wich one must read or not, and even for KIOSK, preventing user to
> see and use such application.
> For a new installed app, system can warn user about two or more versions of
> this application are in the system and choose wich one must use.
>
> But, as i said in the beginning:
> - Apps need have a proper unique id ( like kdebeuf space )
> - There must be a way to recover their version-date or whatever time based
> id to identify which is he new one or not.

   Is it sufficient to do this in the .desktop file?
  
> - User confusion - Regular users will be very confused about this
> behaviour, and maybe can't easily understand that the old application,
> which can have many of personal data already, must be disabled and suddenly
> lost your personal data, since new app is installed on new dir. This CAN
> happen today because not all apps are handling the right rc update, and
> sometime there aren't a better way to fix it than remove rc file.

   Regular users are already quite confused about applications that can't find 
plugins and rc files.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/