I package RapidSVN, a GUI application which acts as an interface to a Subversion repository. Although it has quite a lot of functionality built-in, it relies on external software to perform some functions, in particular:
- a text editor e.g. gedit - a diff viewer of some sort (ideally graphical e.g. meld) - a graphical directory browser (e.g. nautilus)
Currently, these require manual configuration by the user. It would be nice if they worked "out of the box" and respected the user's normal desktop preferences (including respecting different desktop environments - GNOME/KDE/other etc.). I'm not aware of a "clean" way of doing this. Is there any generic command which means "run the user's preferred text editor for the current environment"? Any other bright ideas about how this might be achieved or partially achieved?
Bug #459909 refers to this problem.
Thanks for any input,
Tim
Tim Jackson wrote:
I package RapidSVN, a GUI application which acts as an interface to a Subversion repository. Although it has quite a lot of functionality built-in, it relies on external software to perform some functions, in particular:
- a text editor e.g. gedit
- a diff viewer of some sort (ideally graphical e.g. meld)
- a graphical directory browser (e.g. nautilus)
Currently, these require manual configuration by the user. It would be nice if they worked "out of the box" and respected the user's normal desktop preferences (including respecting different desktop environments
- GNOME/KDE/other etc.). I'm not aware of a "clean" way of doing this.
Is there any generic command which means "run the user's preferred text editor for the current environment"? Any other bright ideas about how this might be achieved or partially achieved?
You could consider using xdg-open (from xdg-utils), which is a command-line utility for this kind of thing. It's purpose is to open files/urls using the default app of the current desktop environment (kde, gnome, whatever).
-- Rex
On Thu, Aug 28, 2008 at 09:32:16AM -0500, Rex Dieter wrote:
Tim Jackson wrote:
I package RapidSVN, a GUI application which acts as an interface to a Subversion repository. Although it has quite a lot of functionality built-in, it relies on external software to perform some functions, in particular:
- a text editor e.g. gedit
- a diff viewer of some sort (ideally graphical e.g. meld)
- a graphical directory browser (e.g. nautilus)
You could consider using xdg-open (from xdg-utils), which is a command-line utility for this kind of thing. It's purpose is to open files/urls using the default app of the current desktop environment (kde, gnome, whatever).
I am not sure that it covers what is wanted here. With xdg-open, it is likely that on text an editor is opened, but it could also be a viewer. For the diff I don't know. But for directory browsing, I am not sure that it will work, on my system, it uses kdesvn because it registered MimeType=inode/directory;
Maybe it is just that inode/directory should be reserved for directory browsers, and text for editors and not viewers.
-- Pat
Patrice Dumas wrote:
On Thu, Aug 28, 2008 at 09:32:16AM -0500, Rex Dieter wrote:
Tim Jackson wrote:
I package RapidSVN, a GUI application which acts as an interface to a Subversion repository. Although it has quite a lot of functionality built-in, it relies on external software to perform some functions, in particular:
- a text editor e.g. gedit
- a diff viewer of some sort (ideally graphical e.g. meld)
- a graphical directory browser (e.g. nautilus)
You could consider using xdg-open (from xdg-utils), which is a command-line utility for this kind of thing. It's purpose is to open files/urls using the default app of the current desktop environment (kde, gnome, whatever).
I am not sure that it covers what is wanted here. With xdg-open, it is likely that on text an editor is opened, but it could also be a viewer. For the diff I don't know. But for directory browsing, I am not sure that it will work, on my system, it uses kdesvn because it registered MimeType=inode/directory;
Maybe it is just that inode/directory should be reserved for directory browsers, and text for editors and not viewers.
Correct, use of any sort of "default" app, assumes that mimetypes for the opened targets are configured properly.
-- Rex
On Thu, Aug 28, 2008 at 09:46:15AM -0500, Rex Dieter wrote:
Patrice Dumas wrote:
I am not sure that it covers what is wanted here. With xdg-open, it is likely that on text an editor is opened, but it could also be a viewer. For the diff I don't know. But for directory browsing, I am not sure that it will work, on my system, it uses kdesvn because it registered MimeType=inode/directory;
Maybe it is just that inode/directory should be reserved for directory browsers, and text for editors and not viewers.
Correct, use of any sort of "default" app, assumes that mimetypes for the opened targets are configured properly.
But for text, you cannot know if a viewer or an editor is the right one. The most common mimetype seems to be text/plain and it cannot convey this information. I think that in the mailcap format there was such a distinction possible, but I am not sure that it exists for freedesktop stuff.
Regarding the inode/directory mimetype, it isn't obvious that kdesvn isn't right. Point is that here there is an action that is wanted in addition to a object type, and xdg-open can only do the somewhat fuzzy action of 'opening'. Maybe we don't need more and consider that the action really associated with opening is in fact set by the application we choose to associate with the mimetype. Put more clearly if we want that 'opening' a text/plain file stands for 'editing' a text/plain file we should just make sure that all the apps associated with text/plain are editors and not viewers.
-- Pat
On Thu, Aug 28, 2008 at 04:57:06PM +0200, Patrice Dumas wrote:
On Thu, Aug 28, 2008 at 09:46:15AM -0500, Rex Dieter wrote:
Patrice Dumas wrote:
I am not sure that it covers what is wanted here. With xdg-open, it is likely that on text an editor is opened, but it could also be a viewer. For the diff I don't know. But for directory browsing, I am not sure that it will work, on my system, it uses kdesvn because it registered MimeType=inode/directory;
Maybe it is just that inode/directory should be reserved for directory browsers, and text for editors and not viewers.
Correct, use of any sort of "default" app, assumes that mimetypes for the opened targets are configured properly.
But for text, you cannot know if a viewer or an editor is the right one. The most common mimetype seems to be text/plain and it cannot convey this information. I think that in the mailcap format there was such a distinction possible, but I am not sure that it exists for freedesktop stuff.
Regarding the inode/directory mimetype, it isn't obvious that kdesvn isn't right. Point is that here there is an action that is wanted in addition to a object type, and xdg-open can only do the somewhat fuzzy action of 'opening'. Maybe we don't need more and consider that the action really associated with opening is in fact set by the application we choose to associate with the mimetype. Put more clearly if we want that 'opening' a text/plain file stands for 'editing' a text/plain file we should just make sure that all the apps associated with text/plain are editors and not viewers.
xdg-open seems to be geared towards reading/viewing instead of editing. At least the documenation stated for example that
xdg-open /tmp/foobar.png
Opens the PNG image file /tmp/foobar.png in the user's default image viewing application.
E.g. it would probably not open in gimp, but in some lightweight png viewer.
Maybe xdg-open needs two modes, read-only and editing?
On Thu, Aug 28, 2008 at 11:16:05AM -0500, Rex Dieter wrote:
Axel Thimm wrote:
Maybe xdg-open needs two modes, read-only and editing?
Add a third one as "ask user which one of the N editors/viewers to use, if there are more than one registered" (e.g. not only the preferred one, see also below).
I'd argue this is a problem better solved one level higher, via mimetypes (somehow).
You mean that apps register as png/viewer-only and png/editor for example? Actually mimetypes are for describing the data only, so the extra information for the applications ability to view/edit would have to be encoded differently.
But still if a file browser just sees some file (say a png file) and one double clicks on it, if it just starts xdg-open it will not be able to pass on what the user wants to do, view or edit.
Windows (TM) seems to have a default of "open as in viewing" and a non-default (with Shift?) as "open as in editing". I think there is even an "ask the user which ones of the 100 png viewer to use". Anyone know how OS X solves this?
On Thu, Aug 28, 2008 at 09:59:41PM +0300, Axel Thimm wrote:
On Thu, Aug 28, 2008 at 11:16:05AM -0500, Rex Dieter wrote:
Axel Thimm wrote:
Maybe xdg-open needs two modes, read-only and editing?
Add a third one as "ask user which one of the N editors/viewers to use, if there are more than one registered" (e.g. not only the preferred one, see also below).
I'd argue this is a problem better solved one level higher, via mimetypes (somehow).
You mean that apps register as png/viewer-only and png/editor for example? Actually mimetypes are for describing the data only, so the extra information for the applications ability to view/edit would have to be encoded differently.
But still if a file browser just sees some file (say a png file) and one double clicks on it, if it just starts xdg-open it will not be able to pass on what the user wants to do, view or edit.
Windows (TM) seems to have a default of "open as in viewing" and a non-default (with Shift?) as "open as in editing". I think there is even an "ask the user which ones of the 100 png viewer to use". Anyone know how OS X solves this?
BTW looks like gnome has this already sorted out:
http://developer.gnome.org/doc/whitepapers/SystemConfig/mime-info.html
applications register with two different keys: view/open. There are even fm-view/fm-open for file managers and even a convert-to-ascii variant.
Maybe xgd has similar functionality?
Axel Thimm wrote:
Maybe xdg-open needs two modes, read-only and editing?
Sounds like it to me. I filed a bug upstream:
https://bugs.freedesktop.org/show_bug.cgi?id=17339
Tim
Rex Dieter wrote:
You could consider using xdg-open (from xdg-utils), which is a command-line utility for this kind of thing. It's purpose is to open files/urls using the default app of the current desktop environment (kde, gnome, whatever).
Thanks Rex, that looks like exactly what I needed.
Tim
packaging@lists.fedoraproject.org
-
Axel Thimm -
Patrice Dumas -
Rex Dieter -
Tim Jackson