[Nautilus-list] Re: [GNOME VFS] start-here: etc. vfs method

[Maciej Stachowiak <mjs noisehavoc org>]

On 20Sep2001 10:24PM (-0400), Havoc Pennington wrote:
> 
> Maciej Stachowiak <mjs noisehavoc org> writes: 
> > Maybe we should consider putting the desktop method code in
> > Nautilus. The other gnome-vfs module strongly tied to the GUI, the
> > help module, is in Nautilus. I am not sure how useful this stuff is
> > outside of Nautilus.
> 
> I think the panel should use programs: to get the programs menu.

Sounds reasonable. Perhaps we should move the help: module into
gnome-vfs as well, then.

> > What's with all these doc changes? Are they are relevant part of your
> > patch?
> 
> No, but they should be committed (the changes are what happens when
> you run gtk-doc, which would typically be done with each commit to the
> module).

Since you didn't change any public headers (as far as I could tell), I
was surprised that there were doc changes. Maybe you are using a
different version of gtk-doc than other gnome-vfs developers. If so,
will that confuse our versions of gtk-doc, or result in
gtk-doc-version-dependent things being changed back and forth?

No objections to checking this in otherwise.

 
> > > +	result = (* parent_method->open) (parent_method,
> > > +					  method_handle,
> > > +					  file_uri,
> > > +					  mode,
> > > +					  context);
> > 
> > Maybe it would be better to call regular gnome-vfs operations on file:
> > URIs rather than trying to invoke the file method functions
> > directly. The library-level operations sometimes do extra work in
> > addition to the method function, or fill in default implementations of
> > NULL operations.
> 
> OK, I have no idea. When you say "maybe" does this mean "you think so"
> or "you don't know either"?

I mean I think it should, but I don't want to be pushy about it in
case you have a good reason for doing it that way.
 
> It does appear to work as-is, but I don't know if there are corner
> cases.

I think it's fine to commit as-is, put a FIXME and fix it later.
 
> > > +typedef enum
> > > +{
> > > +	SCHEME_FAVORITES,
> > > +	SCHEME_PREFERENCES,
> > > +	SCHEME_STARTHERE,
> > > +	SCHEME_SYSCONFIG,
> > > +	SCHEME_SERVERCONFIG,
> > > +	SCHEME_PROGRAMS
> > > +} SchemeID;
> > 
> > How about putting underscores in these in cases where the
> > corresponding URI has a hyphen, and making them patch otherwise? So
> > "SCHEME_START_HERE", "SCHEME_SYSTEM_SETTINGS",
> > "SCHEME_SERVER_SETTINGS".
> 
> Sure.
> 
> > > +typedef struct _SchemeDesc SchemeDesc;
> > > +
> > 
> > 
> > Would you mind using "Description" instead of "Desc"?
> 
> Nope.
> 
> > > +		case SCHEME_STARTHERE:
> > > +			schemes[i].directories[0] = g_strdup ("/etc/X11/starthere");
> > 
> > This should be relative to sysconfdir rather than hardcoded.
> 
> Yup.
>  
> > Same for these three. Maybe there should even be a path variable for
> > thse things, since Nautilus installs the starthere directory and it
> > might not be installed in the same prefix as gnome-vfs (not an issue
> > if this code is put in Nautilus instead).
> 
> GNOME doesn't work if you mix various prefixes anyhow, though we
> probably shouldn't contribute to the problem. ;-)
> 
> > > +static GnomeVFSURI*
> > > +file_uri_to_desktop_uri (GnomeVFSURI *file_uri)
> > > +{
> > > +	/* FIXME we would need to implement this if
> > > +	 * we wanted find_directory to work.
> > > +	 */
> > > +	return NULL;
> > > +}
> > > +
> > 
> > Either this should be implemented or it should be removed and the
> > non-workingness of find-directory should be made explicit in
> > find-directory itself. Come to think of it, I'm not sure we need to
> > translate back - nothing in the docs find_directory claims it needs to
> > return a URI of the same scheme. Why not just return the untranslated
> > URI?
> 
> Sounds fine to me. 
> 
> Havoc