'Edit Source' should use default application for text/plain

[mhinsch]

When running 'Edit Source' from the menu the source text file is not opened in the system-wide (or the user's) default application for text/plain. Instead .desktop files in the 'applications' directory (local and system wide) are listed in reverse raw order and the first one to come up is picked.

Zim 0.47
Kubuntu karmic
Python 2.6.4
Gtk 2.18.3
Pygtk 2.16.0

[Michael Mulqueen (michael.mulqueen)]

Correct behaviour on Gnome would be to spawn gnome-open to load the file (therefore obeying your preferences). Annoyingly for me, I get Notepad opening (and I'm on Ubuntu!). Presumably there is a similar utility for KDE. Not sure what Windows or OSX has.

One way to easily patch this on Gnome would be to get gui/applications.py → get_default_application() to always return gnome-open (if running under Gnome). I doesn't make sense for Zim to handle choosing the default app itself when the system can do it flawlessly.

[Michael Mulqueen (michael.mulqueen)]

This should fix the problem. Not the prettiest thing ever, but it works.

[Jaap Karssenberg (jaap.karssenberg)]

Actually it is not correct that we just pick the first .desktop as described above. We look at the "defaults.list" files, which at the time of writing are the way gnome / xfce determine the default application for specific mimetypes. Only when these config files do not exist we fall back to just using the first text editor available. (Although I think gnome has a secondary mechanism for defaults when the user did not explicitly asign an application.)

So current implementation tries to be consistent with the gnome desktop. The problem is that there is no final freedesktop spec on how to do this.

Patching it to just use xdg-open does not solve this since it will fork a new process and can not be forced to run in the foreground. Ideally we want to block zim while editing the source. Also I do not think this is the correct way to do it. The correct way would be to have a common way for applications to obtain the user preferred applications.

Probably the only way out is to make it a user setting in zim, which is also a bit unsatisfactory.

[Michael Mulqueen (michael.mulqueen)]

Blocking zim while the spawned process is running cannot be
guaranteed. For example, if the process spawned is firefox or gedit
and multiple documents are open, then the process will either never
exit (because it is the first document opened and others are still
open afterwards) or immediately exit (because another document is
already open). I would therefore argue that relying on the process'
status to determine whether zim should allow input is a bad idea. I
don't know how possible it is, but a far better idea would be to
monitor the file in some way (check it every 10secs to see whether the
last modified date has changed?) but that would likely only work on
the assumption that it will only be saved once. Another approach would
be grey out the edit/view box in zim and put a button on top saying
"I've finished editing the source" and then reread the file once that
has been clicked -- it's the only fool proof way and it would allow
the use of xdg-open.

On Sun, Jul 18, 2010 at 10:02 PM, Jaap Karssenberg
<email address hidden> wrote:
> Actually it is not correct that we just pick the first .desktop as
> described above. We look at the "defaults.list" files, which at the time
> of writing are the way gnome / xfce determine the default application
> for specific mimetypes. Only when these config files do not exist we
> fall back to just using the first text editor available. (Although I
> think gnome has a secondary mechanism for defaults when the user did not
> explicitly asign an application.)
>
> So current implementation tries to be consistent with the gnome desktop.
> The problem is that there is no final freedesktop spec on how to do
> this.
>
> Patching it to just use xdg-open does not solve this since it will fork
> a new process and can not be forced to run in the foreground. Ideally we
> want to block zim while editing the source. Also I do not think this is
> the correct way to do it. The correct way would be to have a common way
> for applications to obtain the user preferred applications.
>
> Probably the only way out is to make it a user setting in zim, which is
> also a bit unsatisfactory.
>
> ** Changed in: zim
>       Status: New => Confirmed
>
> ** Changed in: zim
>   Importance: Undecided => Medium
>
> --
> 'Edit Source' should use default application for text/plain
> https://bugs.launchpad.net/bugs/592432
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[mhinsch (hinsch-martin)]

At least under Linux it is not difficult to monitor file status (inotify et al.) and it is also possible to find out which process currently has access to a file. No idea though whether this can be done portably.

[Michael Mulqueen (michael.mulqueen)]

Presumably though the monitoring of access only applies to
locked/currently being written/read files though rather than just any
old file that may be being displayed somewhere. Is that correct?

On Sun, Jul 18, 2010 at 11:58 PM, mhinsch <email address hidden> wrote:
> At least under Linux it is not difficult to monitor file status (inotify
> et al.) and it is also possible to find out which process currently has
> access to a file. No idea though whether this can be done portably.
>
> --
> 'Edit Source' should use default application for text/plain
> https://bugs.launchpad.net/bugs/592432
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Oliver Joos (oliver-joos)]

I confirm this bug for rev282 on Ubuntu 9.10.

Since I have wine installed this bug is even worse: zim tries to open "notepad" and then throws an exception (see attachment). So "Edit Source" does nothing now.

I tweaked a while with update-mime(-database) and update-desktop-database - no luck yet. But I learned: when I change the default application for txt-files in Gnome (by context menu - Properties - Open with) then the ordering changes on the line for text/plain in .local/share/applications/mimeapps.list! The default application (e.g. gedit) is always the first entry:

text/plain=gedit.desktop;scite.desktop;openoffice.org-writer.desktop;

Zim upto rev282 seems to use .local/share/applications/mimeinfo.cache, which is not affected by changing the default application in Gnome.

[Jaap Karssenberg (jaap.karssenberg)]

On Tue, Jul 20, 2010 at 1:41 PM, Oliver Joos <email address hidden> wrote:
> But I learned: when I change the default
> application for txt-files in Gnome (by context menu - Properties - Open
> with) then the ordering changes on the line for text/plain in
> .local/share/applications/mimeapps.list! The default application (e.g.
> gedit) is always the first entry:
>
> text/plain=gedit.desktop;scite.desktop;openoffice.org-writer.desktop;
>
> Zim upto rev282 seems to use .local/share/applications/mimeinfo.cache,
> which is not affected by changing the default application in Gnome.

Hmm, seems Gnome changed since I last checked this.... that's why we
need a spec for it :(

The mimeapps.list file is completely new for me. Zim checks
defaults.list which used to give the default applications followed by
mimeinfo.cache as a fallback. Will need to update this function to
support mimeapps as well. Might also be interesting to use this file
for populating the "Open With" menu for external files.

Overall I'm in favor of Micheal's suggestion to popup a dialog, then
we can let the default file_open function handle this (xdg-open on
linux, or os.openfile on windows).

-- Jaap

[Tobias Weber (towb)]

Why is this so different from the other helper applications? Even if the default text editor was easy to find, who says the user doesn't want to use a different one for Zim, maybe because it can highlight wiki syntax?

Waiting for user confirmation to end editing is a good idea, but can be annoying.

So I'd add a Source Editor selection to Preferences/Applications, with a checkbox "Returns immediately?".

The "Edit Source" menu item should also be deactivated when no editor is found/selected. Currently it silently fails in that case, because the error handling is broken ;)

File "zim/gui/__init__.py", line 1217, in _edit_file
    logger.exception('Error while running %s:', application.name)
AttributeError: 'NoneType' object has no attribute 'name'

[Tobias Weber (towb)]

The code for configurable helpers calls tryexec on desktop files, the code reading mimeinfo.cache does not.

This prevents shipping Zim with such a file in data/applications to set up sensible defaults in case there is no XDG environment, like on the Mac.

[Jaap Karssenberg (jaap.karssenberg)]

On Sun, Jul 25, 2010 at 8:28 PM, Tobias Weber <email address hidden> wrote:
> The code for configurable helpers calls tryexec on desktop files, the
> code reading mimeinfo.cache does not.
>
> This prevents shipping Zim with such a file in data/applications to set
> up sensible defaults in case there is no XDG environment, like on the
> Mac.

I'm sorry, but I fail to see the logic in this conclusion.

mimeinfo.cache is generated by the xdg tools from existing
application, these applications should be installed. We could double
check, but this is not required by the XDG specification.

-- Jaap

[Tobias Weber (towb)]

On 26.07.2010, at 16:03, Jaap Karssenberg wrote:

> So if I replace xdg-open by open on Mac and modify edit-source to call open_file instead of looking for the default app itself that would fix the problem wouldn't it ?

The automatic reload would be lost. bin/open (OS itself) as well as bin/edit (free TextWrangler) and bin/mate (popular TextMate) can all wait until the file is closed in the GUI.

[Michael Mulqueen (michael.mulqueen)]

On Mon, Jul 26, 2010 at 3:29 PM, Tobias Weber <email address hidden> wrote:

> The automatic reload would be lost. bin/open (OS itself) as well as
> bin/edit (free TextWrangler) and bin/mate (popular TextMate) can all
> wait until the file is closed in the GUI.
Automatic reload cannot be consistently achieved across the wide range
of operating systems and applications that people like to use (as
discussed above). How often do we all need to edit the source anyway
that we can't take the time to click an "I'm Done" button>

[Jaap Karssenberg (jaap.karssenberg)]

On Mon, Jul 26, 2010 at 6:24 PM, Michael Mulqueen
<email address hidden> wrote:
> On Mon, Jul 26, 2010 at 3:29 PM, Tobias Weber
> <email address hidden> wrote:
>
>> The automatic reload would be lost. bin/open (OS itself) as well as
>> bin/edit (free TextWrangler) and bin/mate (popular TextMate) can all
>> wait until the file is closed in the GUI.
> Automatic reload cannot be consistently achieved across the wide range
> of operating systems and applications that people like to use (as
> discussed above). How often do we all need to edit the source anyway
> that we can't take the time to click an "I'm Done" button>

We can make it a bit more sophisticated: pop the dialog and when the
application quits check the timestamp of the file, if it was modified
when the application quits close the dialog automatically, otherwise
wait for the user to press "done". But agreed, this might be overkill.

Combined with a preference to set the text editor (default to xdg-open
/ os.openfile / /usr/bin/open ) and we cover all cases I think.

-- Jaap

[Thomas Liebetraut (tommie-lie)]

How about showing (and editing) the source *inside* zim? There already is a text buffer, the "Edit source" menu could just toggle between the note's WYSIWYG-ish view and the bare sourcecode (with syntax highlighting ;-)).

[Jaap Karssenberg (jaap.karssenberg)]

On Tue, Jul 27, 2010 at 12:42 AM, Thomas Liebetraut
<email address hidden> wrote:
> How about showing (and editing) the source *inside* zim? There already
> is a text buffer, the "Edit source" menu could just toggle between the
> note's WYSIWYG-ish view and the bare sourcecode (with syntax
> highlighting ;-)).

Not impossible, but that is a different feature request. I like to
have the external editor option - if only because an embedded mode
will never be as feature rich as my preferred text editor.

-- Jaap

[Michael Mulqueen (michael.mulqueen)]

I completely agree Jaap. I tend to use Edit Source when I need to fix
something or do something complex and when I'm doing that, I want the
Swiss army knife that is my text editor. Also, I think this fits with
the UNIX philosophy of 1 programme, 1 task (which is common sense
really - delegate to specialists).

On Tue, Jul 27, 2010 at 9:53 AM, Jaap Karssenberg
<email address hidden> wrote:
> On Tue, Jul 27, 2010 at 12:42 AM, Thomas Liebetraut
> <email address hidden> wrote:
>> How about showing (and editing) the source *inside* zim? There already
>> is a text buffer, the "Edit source" menu could just toggle between the
>> note's WYSIWYG-ish view and the bare sourcecode (with syntax
>> highlighting ;-)).
>
> Not impossible, but that is a different feature request. I like to
> have the external editor option - if only because an embedded mode
> will never be as feature rich as my preferred text editor.
>
> -- Jaap
>
> --
> 'Edit Source' should use default application for text/plain
> https://bugs.launchpad.net/bugs/592432
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Jaap Karssenberg (jaap.karssenberg)]

Added dialog to block GUI while external application is running and added preference for text editor (although we need the fix for bug #533170 in order for this setting to be useful).

Fixed in rev296.

[Oliver Joos (oliver-joos)]

Thanks! With rev296 it works for me, even with setting 'Default (xdg)' and wine installed (see my comment #7).
I like the busy-dialog, also because closing it refreshes the edited page.

[Jaap Karssenberg (jaap.karssenberg)]

Released in 0.49