Re: (A)synchronous file operations & xdg-open

2009-07-02 Thread Jerry James
On Thu, Jul 2, 2009 at 12:47 PM, Colin Walters wrote:
> I think the easiest fix here is for the app not to delete the
> temporary file immediately after the helper exits.  Just write it in
> $TMPDIR and let tempreaper come along and eat it later.

I am an XEmacs developer, and I would like to fix this upstream.  We
may have users on systems with xdg-open but without tmpreaper.  I'll
take that discussion to the upstream list, however.  Thanks for the
suggestion.
-- 
Jerry James
http://www.jamezone.org/

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


Re: (A)synchronous file operations & xdg-open

2009-07-02 Thread Colin Walters
On Thu, Jul 2, 2009 at 2:30 PM, Jerry James wrote:
>
>
> I am more and more of the opinion that xdg-open is simply the wrong
> tool for viewing/editing temporary files.  It wasn't built for that
> use case, and the tools it invokes were not either.

I think the easiest fix here is for the app not to delete the
temporary file immediately after the helper exits.  Just write it in
$TMPDIR and let tempreaper come along and eat it later.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


Re: (A)synchronous file operations & xdg-open

2009-07-02 Thread Rahul Sundaram
On 07/03/2009 12:00 AM, Jerry James wrote:

> 
> I am more and more of the opinion that xdg-open is simply the wrong
> tool for viewing/editing temporary files.  It wasn't built for that
> use case, and the tools it invokes were not either.  I think we need
> something different altogether.  Should we go back to invoking
> $EDITOR, $VISUAL, etc.?

... or talk to the xdg-utils upstream developers and see if we can get a
new tool added that serves our purpose.

Rahul

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


Re: (A)synchronous file operations & xdg-open

2009-07-02 Thread Jerry James
On Thu, Jun 25, 2009 at 12:32 PM, Ville Skyttä wrote:
> IMO the latter is clearly preferable, and would be even a good default.  But
> then again, it might be too late to change the default as it could break stuff
> (even if the xdg-open man page doesn't document async/sync operation at the
> moment).  And I'm not sure if the tools xdg-open invokes have async/sync
> operation modes - at least some of them would quite probably need
> modifications as well.

So xdg-open currently invokes the following tools, depending on desktop:

KDE: kfmclient
GNOME: gnome-open
XFCE: exo-open

If the desktop is something else, it runs the first of these tools it
can find, checking in this order: mimeopen, run-mailcap, each element
of $BROWSER, htmlview, firefox, mozilla, netscape, links, lynx.

We already know that gnome-open operates in asynchronous mode.  In
https://bugzilla.redhat.com/show_bug.cgi?id=435107, Kevin Kofler says
that kfmclient is also asynchronous.  Does anybody know about
exo-open?

The desktop-agnostic tools are all aimed at displaying random URLs to
the user, and would not be appropriate for the "edit a temporary file"
use-case we're talking about.

I am more and more of the opinion that xdg-open is simply the wrong
tool for viewing/editing temporary files.  It wasn't built for that
use case, and the tools it invokes were not either.  I think we need
something different altogether.  Should we go back to invoking
$EDITOR, $VISUAL, etc.?
-- 
Jerry James
http://www.jamezone.org/

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


Re: (A)synchronous file operations & xdg-open

2009-06-25 Thread Ville Skyttä
On Thursday 25 June 2009, Jerry James wrote:
> It appears to me that we either need to split xdg-open into two tools,
> representing the two modes of operation, or else give xdg-open a
> command-line switch to demand synchronous operation.

IMO the latter is clearly preferable, and would be even a good default.  But 
then again, it might be too late to change the default as it could break stuff 
(even if the xdg-open man page doesn't document async/sync operation at the 
moment).  And I'm not sure if the tools xdg-open invokes have async/sync 
operation modes - at least some of them would quite probably need 
modifications as well.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


(A)synchronous file operations & xdg-open

2009-06-25 Thread Jerry James
This came up in https://bugzilla.redhat.com/show_bug.cgi?id=472402 but
is worth a more general discussion amongst the developer community, I
think.

The xdg-open tool is generally a good thing for the users, but at
least a couple of cases have arisen where it is not doing the right
thing.  The problem seems to be that there are two modes of operation
that are wanted.

(1) Launch a tool that can display a persistent URL.  This can be
asynchronous, since the object identified by the URL isn't going away.

(2) Launch a tool that can display or edit a temporary file.  This
must be synchronous, since the entity that created the temporary file
needs to read it after it is edited, and remove it in either case.

xdg-open is being used for both cases.  Some of the tools it invokes,
such as gnome-open, operate in mode 1 and some (kfmclient?) in mode 2.
 When a mode 1 tool is used in a situation that demands a mode 2 tool,
bad things happen (see also
https://bugzilla.redhat.com/show_bug.cgi?id=435107).

It appears to me that we either need to split xdg-open into two tools,
representing the two modes of operation, or else give xdg-open a
command-line switch to demand synchronous operation.  We also need to
figure out which tools it invokes that operate in mode 1 and find mode
2 equivalents for them.  What do you think?
-- 
Jerry James
http://www.jamezone.org/

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list