Re: FVWM: Document mime type compliance?

2020-01-06 Thread Dominik Vogt
On Mon, Jan 06, 2020 at 04:04:49PM -0600, Brian wrote:
>
> Thanks for replying.  The following is the functions called, so not the
> one you reference.
>
> #Function FvwmMenuDirectory
> DestroyFunc FuncFvwmMenuDirectory
> AddToFunction FuncFvwmMenuDirectory
> + I PipeRead '/usr/bin/fvwm-menu-directory --title "%d" --dir "$0"'
>
> Which as I said makes a Documents directory directly in the main menu
> and then displays the files and directories as if they were a submenu of
> "Documents".
>
> The trouble I run into is that every file clicked on opens in vi,
> directories open the next level down directory, and what I need is for
> the files to open according to the mime type with the proper
> application.
>
> Dominik,
> The man page suggest that you and Mikhael originally wrote this little
> script.  Is there a config I've forgotten so that files will properly
> open by mime type?

It is really just a showcase for generating menus on the fly.  Any
additional logic like opening files needs to be done outside fvwm.
It was never intended to integrate a general file handler into
fvwm.

> For example I see in the man for fvwm-menu-directory a --exec-app
> [command] which maybe means I need to include the app to run on a file,
> but would that work for each mime type?  Maybe there is another
> FvwmFunction which needs to be referenced to add mime type calls?
> Maybe I'm using the wrong function even?

Looking at the --help output, I imagine that the option
--exec-file=xdg-open should do what you want.  (xdg-open starts
the application defined by the mime type with the given file;
don't ask me about syntax details.)

Ciao

Dominik ^_^  ^_^

--

Dominik Vogt



Re: FVWM: Document mime type compliance?

2020-01-06 Thread Peter Holm
I will  try it out. Thank you.
/Peter Holm

2020-01-06 14:18 GMT+01:00, Stefan Blachmann :
> On 1/6/20, Mark Nejedlo  wrote:
>>  If you want different actions based on the
>> extension, you'll need to write a more sophisticated script that is
>> extension aware to use in the place of fvwm_make_directory_menu.sh.
>
> This might be what you want: https://github.com/kernschmelze/meowpurr
>
> It is a full-blown freedesktop standards supporting application and
> file browser for FVWM using MissingMenuFunction.
>
> It of course supports file extensions according to freedesktop
> specifications and the like, with very comfortable OpenWith menus etc
> etc. It memorizes the applications you prefer for particular file
> types, too, etc etc.
>
> It is still WIP - the freedesktop specification for recent opened
> files thing is still not finished (when it works, it gives a complete
> "Recent" menu not only for apps, but for files not opened by  the
> file/app browser, but inside other applications, too. There are also
> still a few minor bugs.
>
> Right now, I have no time to work on that, as it works fine for what I
> need.
> If others are interested in that stuff, it would motivate me to finish
> the uncompleted parts.
>
> So I'd suggest to play around with it... if you have any questions, just
> ask.
>
> Have fun,
> Stefan
>
>


-- 
Med vänlig hälsning / With kind regards
 /Peter Holm



Re: FVWM: Document mime type compliance?

2020-01-06 Thread Stefan Blachmann
On 1/6/20, Mark Nejedlo  wrote:
>  If you want different actions based on the
> extension, you'll need to write a more sophisticated script that is
> extension aware to use in the place of fvwm_make_directory_menu.sh.

This might be what you want: https://github.com/kernschmelze/meowpurr

It is a full-blown freedesktop standards supporting application and
file browser for FVWM using MissingMenuFunction.

It of course supports file extensions according to freedesktop
specifications and the like, with very comfortable OpenWith menus etc
etc. It memorizes the applications you prefer for particular file
types, too, etc etc.

It is still WIP - the freedesktop specification for recent opened
files thing is still not finished (when it works, it gives a complete
"Recent" menu not only for apps, but for files not opened by  the
file/app browser, but inside other applications, too. There are also
still a few minor bugs.

Right now, I have no time to work on that, as it works fine for what I need.
If others are interested in that stuff, it would motivate me to finish
the uncompleted parts.

So I'd suggest to play around with it... if you have any questions, just ask.

Have fun,
Stefan



Re: FVWM: Document mime type compliance?

2020-01-05 Thread Mark Nejedlo
On Sun, Jan 5, 2020, at 10:19 PM, Brian wrote:
> A while back I added the following to my config.
> 
> AddToMenu DOCMenu "Documents" Title
> + MissingSubmenuFunction FuncFVWMMenuDIrectory
> + "Documents" Popup /home/brian/Documents
> 
> With the hope that it would pull up a llst of documents in my home
> documents directory and then easily select a document
> and open it. Well the function does pull up the list of
> documents/directories and opens subdirectories and files, but all the
> documents open in "vi" and not in the application designated by the
> file extension type ie .pdf, .ods, .doc, or .jpg. 

You didn't include the definition of FuncFVWMMenuDIrectory or the (presumably) 
script it points at, which is what does the heavy lifting for 
MissingSubmenuFunction.

Speculating wildly, if you are using fvwm_make_directory_menu.sh from the FVWM 
distribution in FuncFVWMMenuDIrectory, you are always getting vi because that 
is what fvwm_make_directory_menu.sh puts as the application to run for all 
non-directory files.  If you want different actions based on the extension, 
you'll need to write a more sophisticated script that is extension aware to use 
in the place of fvwm_make_directory_menu.sh.

Mark