----- "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) > -- > ------------- 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
