kdedirs design

[Helio Chissini de Castro]

On Monday 15 September 2003 22:56, George Staikos wrote:
>    Does anyone have a suggestion for kdedirs design to avoid the following
> problem?
>
>   - User installs KDE in /usr
>   - User installs ksomeapp in /usr
>   - User installs new version of ksomeapp from source in /usr/local and
> forgets about the one in /usr
>   - User wonders why features are missing from the application and plugins
> don't work
>
>    The problem is that KDE picks up the files in /usr first.  Can we
> reliably detect this situation and warn/error out if the app is installed
> twice?  Can we make the bin path correlate with the "primary" source for
> data (.rc files, etc)?  Another suggestion?

Ok, the problem is not so simple really.
To solve this problem, we need attack applications as well.
Today we can't identify version/release from applications. There aren't any 
identification that the /usr app is older than /usr/local.
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.

If we can find an easy way to do this, like change all apps automatically, all 
the work will be under kdedirs handling and add this new features..
This will enable user have how many application version installed on system he 
choose.

But ( always have a but ), there some problems associated:
- Overhead to tell the system every time you run the application the new dir 
base of it, and of course, avoid as an example,  that this application loads 
the correct part needed, like a khtml part, because you can have a khtml part 
on many dirs, and app don't really know abou this, just kdedirs management.
- Old applications come fomr pre 3.2 release will not embrace this feature, 
and can cause some problems, if we decide that need use this ones. This can 
be easily solved as decidind that just apps >= 3.2 kde release will be 
accepted.
- 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.

Ok, to start, this is my 2c.

-- 
Helio Castro
KDE Developer
Development Conectiva S.A.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030916/40aa184a/attachment.sig>