Re: [Evolution-hackers] evolution .desktop file

[Mark McLoughlin <markmc redhat com>]

Hi Michael,
	So, each time I've come across issues with the way evolution seems to
version every path, filename etc. it installs I've never felt that I
understood the reason *why* evolution does this. What exactly is the
rationale?

	Let me make some random points, though:

  - Applications provide various consumable public interfaces just like 
    libraries provide an API and ABI. Some examples of those are:

      - The paths and basenames of its binaries: may be referenced by 
        scripts people write, hard-coded into apps, config files (like 
        manually created mime type associations), user created panel 
        launchers etc.

      - Command line options and format: again referenced by scripts, 
        apps etc.

      - The paths to and format of the app's config files: admins may
        have scripts which tweak the config files, other apps may try 
        and extract configuration items from them

      - The app's GConf keys, their format and behaviour: again, admins 
        would have scripts to modify them and other apps my try and 
        read or tweak them, but also a user's configuration needs to 
        keep working when moving back and forth between versions of the 
        app (think NFS homedir shared between two OS versions)

      - The basenames of its .desktop files: other apps might reference 
        the .desktop file if it they want to launch the app, and 
        .menu files will reference the .desktop file e.g. if you edited 
        your menu and disabled the evolution entry, the user's .menu 
        file might contain

           <Menu>
             <Name>Office</Name>
             <Exclude>
               <Filename>evolution.desktop</Filename>
             </Exclude>
           </Menu>

       - Icon names: might be use in manually created launchers, other 
         apps might reference them

    You could go on, but the point is that, like it or not, 
    applications present interfaces which people will consume. Changing 
    those interfaces will cause breakage.

    That doesn't mean that all these interfaces need to be completely 
    locked down and never changed like a stable ABI, but it does mean 
    that changing them will likely have consequences we may not have 
    anticipated.

    It'd be nice if we could figure out how stable each of these 
    interfaces should be and document that so people consuming the 
    interfaces would have some idea how likely they are to change, but 
    that takes work.

    Anyway - at best, consistently changing these interfaces every 
    release just seems very unhelpful.

  - We could label each of the interfaces above as "completely and 
    utterly unstable; do not use on pain of death" but users of those
    those interfaces do use them to provide real benefit to real users
    e.g.

      - We can put evolution's .desktop file on the default panel
        and it doesn't break when people don't upgrade evo and the 
        panel in lockstep

      - The launcher on the user's panel continues to work even when 
        you upgrade evo

      - Menu editing doesn't break unpredictably

      - We can launch evo when you double click on an entry in the
        clock applet's calendar

      - We can figure out what calendars to have in the clock applet's 
        calendar by reading Evolution's GConf key, thus sharing the 
        configuration with Evo

      - We can provide a GConf backend to pull user mail account data 
        from LDAP

      - Admins can configure Evo defaults with scripts and those 
        scripts keep working when they upgrade evo

  - I can't see anyone wanting parallel-installable applications, 
    barring developers and testers, perhaps. Real users won't ever
    want to have two versions of the same application and choose 
    between them. Developers and testers achieve that effect with all 
    other applications by installing them in different prefixes.

  - Even if users did want the app to be parallel-installable, does 
    anyone do it in practice (e.g. by packaging them in 
    parallel-installable manner). Does it ever get tested? Do we know 
    it actually works?

Cheers,
Mark.