On Mon, 3 Nov 2008 14:39:05 +0100 (CET) Dave Andreoli <[EMAIL PROTECTED]> wrote:
> > ----- "Carsten Haitzler (The Rasterman)" <[EMAIL PROTECTED]> ha > scritto: > > > 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? > > The #2 is powerfull but will work only if E is running, and this is > bad for applications, that should work also outside E. > > I prefer the #1, put the config where everyone can look...what about > the defaults.list file ? ;) (it's not yet a fdo standard, but it's a > simple and clear way to store the info) I agree, we should follow the spec on this one as it will ease the burden on distributors who need to setup these types of options for all desktops. The proposed FDO specification needs some work, but hopefully becomes useful. We'll see :) > > > -- > > ------------- 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
