bugGNU Octave - Bugs: bug #44368, Opening an Octave file via a...


bug #44368: Opening an Octave file via a desktop application does not open file on Octave editor

Submitter:  Carnë Draug <carandraug>
Submitted:  Wed 25 Feb 2015 03:50:29 PM UTC
Category:  GUI Severity:  1 - Wish
Priority:  5 - Normal Item Group:  Feature Request
Status:  Postponed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Wed 28 Mar 2018 06:26:06 PM UTC, comment #7: 

> On GNU/Linux desktops, a single .desktop file has to serve both purposes of "how to run this program" and "how to use this program to open a file". Typically this is just "program-name" vs "program-name file-name", but in our case we want the latter to open the file in the editor.

It has occurred to me that maybe it is possible to have this by having the 'Desktop Entry' not registered with any mime type which then would show up on the applications menu. And then have a separate 'Desktop Action' that would open the text editor, and only have that action register mime types.

The Desktop entry specification is not very clear whether this should work, and I can't test it at the moment, but sounds like it might. This would only work with recent systems since 'Desktop Action' was only added to the specs on version 1.1 (2017-12-24).

Carnë Draug <carandraug>
Group Member
Wed 28 Mar 2018 05:31:15 PM UTC, comment #6: 

The primary issue with moving forward on this bug is that users may want the main Application launcher for Octave to start Octave as it does now, on the command window. At the same time, users may want to be able to double click on a file in the file browser and have it be opened in Octave with the file editor tab open, as opposed to running the file as a script.

On GNU/Linux desktops, a single .desktop file has to serve both purposes of "how to run this program" and "how to use this program to open a file". Typically this is just "program-name" vs "program-name file-name", but in our case we want the latter to open the file in the editor.

One way forward might be to register dbus API calls with Octave. If the user invokes some dbus method to open a file in the editor, and Octave isn't already running, an instance of Octave would start first to handle the dbus function call. See bug #42603 for this specific bug.

But mainly, we need a single command line to put in the Exec entry of a desktop file that means "run Octave normally with the command window open" and at the same time means "run Octave and open the given file in a new file editor tab when given a file argument".

I do not think we want "octave foo.m" to mean "run foo.m as a script", but "octave --gui foo.m" to mean open foo.m in the file editor.

And I do not think "octave --gui --persist --eval "edit '%f'" is a solution because that will always open a new editor window and set focus to the editor as opposed to the command window.

Mike Miller <mtmiller>
Group Member
Fri 05 Jun 2015 10:44:08 AM UTC, comment #5: 

See patch on duplicated bug #44880

Carnë Draug <carandraug>
Group Member
Thu 26 Feb 2015 10:06:48 PM UTC, comment #4: 

On my system, running octave --force-gui --persist --eval 'edit ""' will open the GUI on the text editor tab without throwing any error.  Seems handy that edit() without any arguments opens a new instance of the text editor (this is not a feature of the GUI, on Octave 3.8 using another text editor, edit() without any arguments opened my editor with a new empty buffer.

Carnë Draug <carandraug>
Group Member
Thu 26 Feb 2015 07:31:16 PM UTC, comment #3: 

I mean the default behavior of running Octave with no arguments,

  • no filenames - open Octave with the command window

The workaround of doing --eval "edit %1" breaks that behavior.

So I thought there would still be a need for a .desktop entry file for just running Octave as a program, not to edit a file, right?

I was thinking the .desktop file we have now would be the main one that would show up in the normal application menu, and a second .desktop file would be used for file associations and open the editor with the given file arguments. This would have the NoDisplay=true attribute set so it doesn't show up in menus and is only used for file type associations.

Or is there any way to reduce all of those options to a single .desktop file? Or did I miss something?

Mike Miller <mtmiller>
Group Member
Thu 26 Feb 2015 06:46:38 PM UTC, comment #2: 

If there was an --editor option, the behaviour could be

  • no filenames - open GUI on the editor
  • single filenames - open that files
  • multiple filenames - open all those files

and there would be no need for two desktop entries.

I think the workaround mentioned already solves the first two cases.

The only thing is, what happens if the user has defined an editor on their octaverc ? I tried to do it, and it still opened the file on the Octave GUI editor which is weird for me. Shouldn't my editor preferences be kept, specially since I am setting them myself and not relying on defaulting to emacs?

Carnë Draug <carandraug>
Group Member
Thu 26 Feb 2015 05:52:49 AM UTC, comment #1: 

I think this would probably best be done with multiple .desktop entries. On my Debian system I have /usr/share/applications/org.gnome.Software.desktop and /usr/share/applications/gnome-software-local-file.desktop. These both run the same program, but one without a file argument and one with. And only the latter has a MIME type listed to register a file association.

And like you said, we could either use the current workaround as the command line to open a file in the editor or make a new command-line option to edit a file.

Mike Miller <mtmiller>
Group Member
Wed 25 Feb 2015 03:50:29 PM UTC, original submission:  

During installation, Octave "registers" as being able to handle Octave and Matlab files.

This means that double click on a file with MIME type text/x-octave and text/x-matlab will open on Octave session.  However, this will only execute the file not open it on the Octave GUI editor which is probably what a user wants. With the octave program now being both a language and an IDE, an "--edit" option would be useful to do this.

Bug #42603 (GUI: allow opening an m-file in the editor of a running instance) is related to this issue.  They solve the problem related on this bug by having desktop applications opening files with 'octave --force-gui --persist --eval "edit %1"'

The same workaround can be used by having the following line on http://hg.savannah.gnu.org/hgweb/octave/file/bf511802add7/etc/icons/octave.desktop.in

Exec=/usr/local/bin/octave --force-gui --persist --eval "edit %f"

Or should we really get an --editor flag that could maybe even accept multiple files?

Carnë Draug <carandraug>
Group Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by carandraug (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.


    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-03-28 mtmiller Severity3 - Normal 1 - Wish
        StatusNone Postponed
    2016-09-27 mtmiller Dependencies- bugs #49054 is dependent
    2015-06-05 carandraug Dependencies- bugs #44880 is dependent
    2015-02-26 mtmiller Item GroupNone Feature Request

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code