Since the c5cbf887baa8f4ffb0b205b2c69d031efd9a2367 commit of Terminal this summer, the terminal widget now always use exo_execute_preferred_application_on_screen() instead of gtk_show_uri() to open URIs to fix inconsistencies with links and mailto: references.
However, since the category parameter is set to WebBrowser in this case, file:// URIs which where recognized by gtk_show_uri() as local files and handled by MIME-associated apps such as image browsers or text editors are now always opened in the exo preferred web browser (Firefox).
This make advanced operations such as directly starting a slideshow or editing a source file much less direct than before from a terminal widget and requires the user to manually copy/paste the URI to the appropriate tool.
Could a fallback to the old method using gtk_show_uri() be implemented for these URIs, since the exo alternative doesn't appear to provide a "use MIME-associated application instead" category?
Since the c5cbf887baa8f4f fb0b205b2c69d03 1efd9a2367 commit of Terminal this summer, the terminal widget now always use exo_execute_ preferred_ application_ on_screen( ) instead of gtk_show_uri() to open URIs to fix inconsistencies with links and mailto: references.
However, since the category parameter is set to WebBrowser in this case, file:// URIs which where recognized by gtk_show_uri() as local files and handled by MIME-associated apps such as image browsers or text editors are now always opened in the exo preferred web browser (Firefox).
This make advanced operations such as directly starting a slideshow or editing a source file much less direct than before from a terminal widget and requires the user to manually copy/paste the URI to the appropriate tool.
Could a fallback to the old method using gtk_show_uri() be implemented for these URIs, since the exo alternative doesn't appear to provide a "use MIME-associated application instead" category?
Regards,