Re: [E-devel] Efreet mime default application patch
- [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=100url=/ ___ 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
Re: [E-devel] Efreet mime default application patch
On Sat, 6 Dec 2008 20:47:08 +0100 (CET) Dave Andreoli [EMAIL PROTECTED] babbled: 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. a few things with the patch though. 1.: oopsie in patch +snprintf(buf, sizeof(buf), %sapplications/defaults.list, dir); should be %s/app... 2.: i see no api to list all mime + app to be used 3.: i see no way to just specify a command (as opposed to a .desktop file). this changes part of efm so we need to write new .desktops for custom commands or need to drop that feature. i'm actually in favor of .desktop only - but making it easier in the ui to create new custom command .desktop files (that don't show up in menus, but can be in a special category of their own and browsed, deleted, edited and created like any other .desktop). 4. i see no way to delete an entry in the mime apps list from the api 5. i see no way to maintain a preference list - ie list the most recently used or preferred app .desktops. example: i install mplayer and prefer it to open .avi files - i tell efm once and it saves this. so it keeps using it. now i uninstall mplayer - i'd like to to go back to my previous app (let's say xine) for playing. so as such i think what you want here is not a single entry but a list per file type - if we are to make this generic for everyone to use, it'd better cover a very very very wide range of uses. also entries should be marked as sticky or floating. sticky == the list order may change based on usage patterns (eg if i start running mplayer much more than xine - maybe it auto-re-orders the list), and others may be dont care how much i use apps. ALWAYS open .avi with m player!. for example. maybe for some you want to also limit list length (length of 1 is the current simple 1 .desktop per mime type case and as there are no other entries - it cant be re-ordered and fall back to previously used mime type handlers). so as such - this api needs some work imho. the standard not yet a standard imho is too simplistic and already will have usability problems (eg in the uninstall case). admittedly in that case you could just pop up the well app doesnt exit - ask what app you want to use now again, but it's not as nice as maintaining a list of preferences. 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=100url=/ ___ 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 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] -- SF.Net email is Sponsored by MIX09,
Re: [E-devel] Efreet mime default application patch
- Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] ha scritto: On Sat, 6 Dec 2008 20:47:08 +0100 (CET) Dave Andreoli [EMAIL PROTECTED] babbled: 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. a few things with the patch though. 1.: oopsie in patch +snprintf(buf, sizeof(buf), %sapplications/defaults.list, dir); should be %s/app... yep, thanks for spotting 2.: i see no api to list all mime + app to be used You mean the list of all know associations? why you need all the list? 3.: i see no way to just specify a command (as opposed to a .desktop file). this changes part of efm so we need to write new .desktops for custom commands or need to drop that feature. i'm actually in favor of .desktop only - but making it easier in the ui to create new custom command .desktop files (that don't show up in menus, but can be in a special category of their own and browsed, deleted, edited and created like any other .desktop). Indeed, only .desktop and a good way to manage customs created. I will work on this 4. i see no way to delete an entry in the mime apps list from the api we can pass NULL to efreet_mime_default_application_set()...don't remember if this is implemented in the patch. 5. i see no way to maintain a preference list - ie list the most recently used or preferred app .desktops. example: i install mplayer and prefer it to open .avi files - i tell efm once and it saves this. so it keeps using it. now i uninstall mplayer - i'd like to to go back to my previous app (let's say xine) for playing. so as such i think what you want here is not a single entry but a list per file type - if we are to make this generic for everyone to use, it'd better cover a very very very wide range of uses. also entries should be marked as sticky or floating. sticky == the list order may change based on usage patterns (eg if i start running mplayer much more than xine - maybe it auto-re-orders the list), and others may be dont care how much i use apps. ALWAYS open .avi with m player!. for example. maybe for some you want to also limit list length (length of 1 is the current simple 1 .desktop per mime type case and as there are no other entries - it cant be re-ordered and fall back to previously used mime type handlers). IMO the list of preference could be used, but inside the API, not exposed. So that when you call application_get() the implementation choose the best one and return only the right .desktop If we return more than one options than apps can do different things, and this is not consistent. so as such - this api needs some work imho. the standard not yet a standard imho is too simplistic and already will have usability problems (eg in the uninstall case). admittedly in that case you could just pop up the well app doesnt exit - ask what app you want to use now again, but it's not as nice as maintaining a list of preferences. 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=100url=/ ___ 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
Re: [E-devel] Efreet mime default application patch
On Sun, 7 Dec 2008 05:16:05 +0100 (CET) Dave Andreoli [EMAIL PROTECTED] babbled: - Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] ha scritto: On Sat, 6 Dec 2008 20:47:08 +0100 (CET) Dave Andreoli [EMAIL PROTECTED] babbled: 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. a few things with the patch though. 1.: oopsie in patch +snprintf(buf, sizeof(buf), %sapplications/defaults.list, dir); should be %s/app... yep, thanks for spotting 2.: i see no api to list all mime + app to be used You mean the list of all know associations? why you need all the list? the ability later to have a config ui for it. :) i.e. list associations. 3.: i see no way to just specify a command (as opposed to a .desktop file). this changes part of efm so we need to write new .desktops for custom commands or need to drop that feature. i'm actually in favor of .desktop only - but making it easier in the ui to create new custom command .desktop files (that don't show up in menus, but can be in a special category of their own and browsed, deleted, edited and created like any other .desktop). Indeed, only .desktop and a good way to manage customs created. I will work on this cool. 4. i see no way to delete an entry in the mime apps list from the api we can pass NULL to efreet_mime_default_application_set()...don't remember if this is implemented in the patch. it isn't as best i see. :) 5. i see no way to maintain a preference list - ie list the most recently used or preferred app .desktops. example: i install mplayer and prefer it to open .avi files - i tell efm once and it saves this. so it keeps using it. now i uninstall mplayer - i'd like to to go back to my previous app (let's say xine) for playing. so as such i think what you want here is not a single entry but a list per file type - if we are to make this generic for everyone to use, it'd better cover a very very very wide range of uses. also entries should be marked as sticky or floating. sticky == the list order may change based on usage patterns (eg if i start running mplayer much more than xine - maybe it auto-re-orders the list), and others may be dont care how much i use apps. ALWAYS open .avi with m player!. for example. maybe for some you want to also limit list length (length of 1 is the current simple 1 .desktop per mime type case and as there are no other entries - it cant be re-ordered and fall back to previously used mime type handlers). IMO the list of preference could be used, but inside the API, not exposed. So that when you call application_get() the implementation choose the best one and return only the right .desktop If we return more than one options than apps can do different things, and this is not consistent. so.. let's say i want the ui to auto-cahnge the default tool once you use another enough. example: i have mplayer set as my avi viewer, but now i start running xine a lot for videos - from the cmd-line or ibar or menus. i'd like e to notice my relative shift in usage paterns and maybe auto-flip the preference ordering :) so as such - this api needs some work imho. the standard not yet a standard imho is too simplistic and already will have usability problems (eg in the uninstall case). admittedly in that case you could just pop up the well app doesnt exit - ask what app you want to use now again, but it's not as nice as maintaining a list of preferences. 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net
Re: [E-devel] Efreet mime default application patch
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. 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=100url=/ ___ 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
Re: [E-devel] Efreet mime default application patch
[EMAIL PROTECTED] wrote: p.s. Is there an EFL way to get the list of all mime type and a list of all desktop files? Don't think there is, but it should be easy to add efreet_util_desktop_list() to efreet_utils.c for desktops. I don't know the mime system. Sebastian -- 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
Re: [E-devel] Efreet mime default application patch
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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efreet mime default application patch
- 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efreet mime default application patch
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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efreet mime default application patch
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. -- - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efreet mime default application patch
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. I agree here, thus why I didn't bother applying this patch yet. I want to make sure there is a specification set before we do anything. They may end up using dbus or they may keep it simple. I really think dbus is complete overkill for matching mimetypes to applications though. No need to have a daemon running that is going to sit idle 99.9% of the time. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efreet mime default application patch
- 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. Regards Dave Dave Andreoli wrote: ...and the attachment ;) the patch is to be applied in the main efreet directory. Dave - Dave Andreoli [EMAIL PROTECTED] ha scritto: Hi all This is a relly small patch that add 2 functions to Efreet_Mime. EAPI const char* efreet_mime_default_application_get(const char *mime) EAPI void efreet_mime_default_application_set(const char *mime, const char *desktop) The _get function take a mime-type (as 'text/html') and return the name of the desktop file (as 'Firefox.desktop') that should be used to open the given mime-type. The information is readed from the $XDG_DATA_DIRS/applications/defaults.list file, first the user preference file is checked than the system wide. The second one set the preference in the user defaults.list file. With this functions all the applications that use efreet can know witch is the default program to use to open a given mime-type. Hope you like it Dave - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Efreet mime default application patch
Hi all This is a relly small patch that add 2 functions to Efreet_Mime. EAPI const char* efreet_mime_default_application_get(const char *mime) EAPI void efreet_mime_default_application_set(const char *mime, const char *desktop) The _get function take a mime-type (as 'text/html') and return the name of the desktop file (as 'Firefox.desktop') that should be used to open the given mime-type. The information is readed from the $XDG_DATA_DIRS/applications/defaults.list file, first the user preference file is checked than the system wide. The second one set the preference in the user defaults.list file. With this functions all the applications that use efreet can know witch is the default program to use to open a given mime-type. Hope you like it Dave - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efreet mime default application patch
...and the attachment ;)
the patch is to be applied in the main efreet directory.
Dave
- Dave Andreoli [EMAIL PROTECTED] ha scritto:
Hi all
This is a relly small patch that add 2 functions to Efreet_Mime.
EAPI const char*
efreet_mime_default_application_get(const char *mime)
EAPI void
efreet_mime_default_application_set(const char *mime, const char
*desktop)
The _get function take a mime-type (as 'text/html') and return the
name of the desktop file (as 'Firefox.desktop') that should be
used to open the given mime-type. The information is readed from
the $XDG_DATA_DIRS/applications/defaults.list file, first the
user preference file is checked than the system wide.
The second one set the preference in the user defaults.list file.
With this functions all the applications that use efreet can know
witch
is the default program to use to open a given mime-type.
Hope you like it
Dave
-
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=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Index: src/lib/efreet_mime.c
===
--- src/lib/efreet_mime.c (revisione 37249)
+++ src/lib/efreet_mime.c (copia locale)
@@ -86,6 +86,7 @@
static int efreet_mime_glob_match(const char *str, const char *glob);
static int efreet_mime_glob_case_match(char *str, const char *glob);
static int efreet_mime_endian_check(void);
+static const char*efreet_mime_default_get(const char *file, const char *mime);
static void efreet_mime_monitor_add(const char *file);
static void efreet_mime_cb_update_file(void *data,
@@ -317,6 +318,69 @@
}
/**
+ * @param mime: The mime type to check (ex. 'text/html' or 'x-directory/normal')
+ * @return Returns The name of the .desktop file to use to open the given mime type. Remember to free the value with eina_strinshare_del()
+ * @brief Retreive the application to use to open a give mime type
+ */
+EAPI const char*
+efreet_mime_default_application_get(const char *mime)
+{
+Ecore_List *dirs;
+char *dir;
+char buf[PATH_MAX];
+const char *ret = NULL;
+
+if (!mime) return NULL;
+
+//Search user defaults.list file
+snprintf(buf, sizeof(buf), %s/applications/defaults.list, efreet_data_home_get());
+if ((ret = efreet_mime_default_get(buf, mime)))
+return ret;
+
+//Search system defaults.list file
+dirs = efreet_data_dirs_get();
+if (dirs)
+{
+ecore_list_first_goto(dirs);
+while ((dir = ecore_list_next(dirs)))
+{
+snprintf(buf, sizeof(buf), %sapplications/defaults.list, dir);
+ret = efreet_mime_default_get(buf, mime);
+if (ret)
+break;
+}
+}
+
+ return ret;
+}
+
+/**
+ * @param mime: The mime type to set (ex. 'text/html' or 'x-directory/normal')
+ * @param desktop: The name of the desktop file to use as default (ex. 'Thunar.desktop')
+ * @brief Set the default application to use to open a give mime type
+ */
+EAPI void
+efreet_mime_default_application_set(const char *mime, const char *desktop)
+{
+Efreet_Ini *ini = NULL;
+char buf[PATH_MAX];
+
+if (!mime || !desktop)
+return;
+
+//Always use the user defaults.list file
+snprintf(buf, sizeof(buf), %s/applications/defaults.list, efreet_data_home_get());
+ini = efreet_ini_new(buf);
+if (!ini)
+return;
+
+efreet_ini_section_set(ini, Default Applications);
+efreet_ini_string_set(ini, mime, desktop);
+efreet_ini_save(ini, buf);
+efreet_ini_free(ini);
+}
+
+/**
* @internal
* @return Returns the endianess
* @brief Retreive the endianess of the machine
@@ -1227,3 +1291,29 @@
if (!fnmatch(str, tglob, 0)) return 1;
return 0;
}
+/**
+ * @internal
+ * @param file: The full path to a defaults.list file
+ * @param mime: The mime type to search for
+ * @return Returns a newly allocated string with the name of the .desktop file
+ * @brief Search the given defaults.desktop file for mime
+ */
+static const char*
+efreet_mime_default_get(const char *file, const char *mime)
+{
+Efreet_Ini *ini = NULL;
+const char *str, *ret = NULL;
+
+if (! file || !mime || !ecore_file_can_read(file))
+return NULL;
+
+ini = efreet_ini_new(file);
+if (!ini) return NULL;
+
+efreet_ini_section_set(ini, Default Applications);
+if ((str = efreet_ini_string_get(ini, mime)))
+ret = eina_stringshare_add(str);
+
+efreet_ini_free(ini);
+return ret;
+}
Index:
Re: [E-devel] Efreet mime default application patch
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. Dave Andreoli wrote: ...and the attachment ;) the patch is to be applied in the main efreet directory. Dave - Dave Andreoli [EMAIL PROTECTED] ha scritto: Hi all This is a relly small patch that add 2 functions to Efreet_Mime. EAPI const char* efreet_mime_default_application_get(const char *mime) EAPI void efreet_mime_default_application_set(const char *mime, const char *desktop) The _get function take a mime-type (as 'text/html') and return the name of the desktop file (as 'Firefox.desktop') that should be used to open the given mime-type. The information is readed from the $XDG_DATA_DIRS/applications/defaults.list file, first the user preference file is checked than the system wide. The second one set the preference in the user defaults.list file. With this functions all the applications that use efreet can know witch is the default program to use to open a given mime-type. Hope you like it Dave - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
