----- [EMAIL PROTECTED] ha scritto: > On Tue, 4 Nov 2008 11:01:10 +1100 > Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote: > > > On Mon, 3 Nov 2008 14:39:05 +0100 (CET) Dave Andreoli > <[EMAIL PROTECTED]> > > babbled: > > > > > > 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) > > > > technically - any app/desktop/wm could provide the same dbus > service... a > > stand-alone app could too. the problem with #1 is that if e decides > to change > > config, format, versioning, keys, break it etc. every app is stuck > catching up. > > putting it into a lib and formalising it sets the config in stone as > u cant go > > change it as u are going to break format/api. a very limited config > is > > possible, but i think it's a bit premature to go formalising this - > for e it is > > i think. also this means the config now can't use e's normal config > schemes. > > > > Hello, > I'll speak here as a future user of that API/lib. > I'm writing a *-commander(2-pane) style file manager in Ewl. > I've the basic operations ready: browsing/copy/delete/new dir/rename, > now I have to implement the open file operation. > I have wide range of posibilities: > 1. Implement my own api: > a. 100% custom way of matching executables to files > b. copy the code from efm > c. copy and adapt the patch in my app > (I don't like all three choices here. They are hard to implement. Do > something that has been done already. Breaks the integration in the > desktop. And all code should be redone N-time when there is a > specification). > 2. Try to convince you that any API/lib is better that no lib. > Here are the pros and cons of the API (as I sees them): > Pros: > Ease of use > No code duplication > If a spec is released all apps will be conformant to that spec. > If the spec requires an API change all apps should be fixed, > this way all will be conformant. > All apps in E will behave the same. > Cons: > Current apps should be ported to the API > The API might be to restrictive for some apps > > raster wrote: > > also this means the config now can't use e's normal config schemes. > I don't know what this schemes are used for, but that's a > problem, too. > Breaking the API will break all dependand on it. > > I'm not too concerned with the last one, because that won't happen > too > often anyway. And the requirements to the api are simple, so it will > be > a simple API. If the spec says that the implementation should be > different than the current one, or someone decide that the current > implementation can be improved in some way the API won't change > drastically (It's role is to abstract the implementation, after all). > > I hope that there will be made a decision that will be good for all of > us.
I think the best way is the simple API presented in the patch: EAPI const char* efreet_mime_default_application_get(const char *mime); EAPI void efreet_mime_default_application_set(const char *mime, const char *desktop); This api is so simple that I don't think is going to change in future. So the only problem ramain seems that this is not YET official FDO standard, and some people don't like to put it in efreet for this reason. IMO we can safetly place this in efreet with a note that say that is not official atm. Dave > > Best regards, > Teodor Petrov > > > p.s. Is there an EFL way to get the list of all mime type and a list > of all desktop files? > > > > > -- > > ------------- 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 > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, > Nevada. > The future of the web can't happen without you. Join us at MIX09 to > help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
