On Tue, 28 Oct 2008 23:06:58 +0100 (CET) Dave Andreoli <[EMAIL PROTECTED]> babbled:
> > ----- "Nick Hughart" <[EMAIL PROTECTED]> ha scritto: > > > This is not yet an fdo specification so I'm not going to put it in > > just > > yet. It seems to have promise and is a fairly simple format, but for > > > > now we have our own methods of choosing default applications and it is > > > > similar to how they choose as well (given the user is not making this > > > > file on their own). > > > > When opening a file in EFM, if that mimetype has not been opened > > previously you will be given a list of apps that support that mimetype > > > > and a list of all apps as well just in case. Once you have chosen an > > > > app, EFM remembers this and will use that app until you pick a > > different > > app by using Open With. So for now we have our own methods of doing > > this, but if it does become a specification it may be good to adopt > > this > > as it would help with those doing packaging and distribution. > > Where EFM store the user preference, is it possible to others to access > this data? > I think we need a centralised way to keep this information, or the user > need to choose a preferred application for every apps/module that need > to open a filemanager or a browser. > I know this is not a standard yet. But this doesn't mean we can't have > our method to storing this user preference. > > I have also done a module that add a configuration dialog to set your > preferred apps. Its very simple, but it make no sense if there are > not a shared place to store the informations. > Don't you think this is a must have module?? > > So IMHO we need to define witch is the E way to store the mime/application > associations, and have the code in some lib (maybe not efreet for now). > In this way we can have all the apps/module work the same way and we > can also change the lib to fit a final freedesktop standard without > touching modules. > If we don't do this now all the apps/modules will do the associations > in a different way and when the fdo standard will become a reality we > need to redo everything. well within e it's easy - there are calls to find this info, but outside of e + modules it's buried deep in e's own config somewhere. now how do we want to do this? 1. config everyone cal look at OR 2. "opening service". e.g. a dbus call- u send an array (list) of file paths and say "open them please" - e will open them for you. this way you also recycle the exec method and child process tracking etc. if the target file is a directory - it opens a directory window, etc. is #2 perhaps not better? -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
