[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Default browser setting

> If the app lanching the uri don't suport http this might be hard. It's 
> not for sure your prefared ps viewer suports http ether. So lanching a 
> default browser might be the best way.

I meant "if the uri refers to a .ps file and I have a ps viewer which
knows to access to this uri I want to directly open it in this viewer
(instead of launching a browser which will propose me this very same
viewer...)". For many types, there won't be such viewers, so I agree
that it should fall back to the default browser in those cases.

> Idealy, that browser do (at least given the right command line togle) 
> automaticly lanch the right wiever for the file (using the mimetype 
> database), and don't open a window for itself unless it's viewing the 
> file nativly (and quit when it's job is done otherwise).

Ideally, you'd have a vfs library, which you could use in your
"open_this_uri" function to download the file locally and run a "local
viewer" if you don't have any viewer able to open the uri you are
interested in (for example a ps file on an http server).

> BTW, I saw a vfs working att the filesystem level, so opening 
> http://domain.com/toto.ps would mean opening a regular file att a given 
> mountpoint, for example /uri/http/domain.com/toto.ps - As it to userland 
> is a regular file, it can be feed directly to any viewer!!!

There also is one or two ugly LD_PRELOAD hacks to use gnome-vfs calls
instead of the standard unix calls to handle file operations. That way,
all standard unix tools get remote fs access capability for free (though
this was far from working perfectly iirc).


Attachment: signature.asc
Description: Ceci est une partie de message=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]