Re: patch-ahoy: gnome_url_show stuff
- From: Alexander Larsson <alexl redhat com>
- To: Frank Worsley <fworsley shaw ca>
- Cc: GNOME Desktop List <desktop-devel-list gnome org>, Jonathan Blandford <jrb redhat com>
- Subject: Re: patch-ahoy: gnome_url_show stuff
- Date: Thu, 13 Mar 2003 12:04:01 -0500 (EST)
On Thu, 13 Mar 2003, Frank Worsley wrote:
> Hi Alex,
>
> > In general I'm uncertain of the usefulness of the component stuff. If
> > you're launching a uri from something that doesn't support component
> > embedding itself I think you almost always prefer an application to open
> > over a component in a generic shell (do we even have a usable shell for
> > this?). I guess if a component is all you have you'd prefer to use that
> > over nothing though.
>
> My reasoning is that (for consistency) if you have a component associated as
> the default action then the file should always open in the component, no
> matter what.
>
> This can be especially important if somebody writes a general component
> viewer application (as opposed to just using Nautilus) in the future which
> may make components feel more like applications or something like that.
I personally think this would be a pretty bad idea. In almost all cases
the custom UI of an application would be better for the user.
> Also important for the case where there is only a component and no
> application. Only example I can think off is the RPM view, I haven't tried
> it but I don't think it comes with an application.
For e.g. Red Hat we would want to rpms to come up in an rpm-install app.
> > Also, I'm not sure how this will interact with the work on the mime system
> > jrb is working on. We need to make sure to not introduce any new stuff
> > that uses things which may become deprecated soon.
>
> It would have been nice if you told me that when I originally posted about
> this. I hope all this work wasn't for nothing.
I'm not sure what sort of changes jonathans work will mean. Maybe it'll
mean no changes, maybe it affects the implementation.
> > +gnome_vfs_uri_new_with_unsupported (const gchar *text_uri)
> >
> > This is some pretty strange API, and a bit badly named to (*with*
> > unsupported?). Given the usage of it I think a function to extract the
> > schema from a text-uri would be better.
>
> Yes I couldn't think of a better name. Isn't it better to reuse the
> GnomeVFSURI code than to make another new function?
Well. You're exposing some API that will lead to all sort of brokenness if
people use it and then pass those uris into the wrong gnome-vfs
function. Not to mention that to do a full uri parse just to get the
schema is a lot more work.
> > eel.patch.1:
> > I don't think these changes are necessary. The way you use them in
> > nautilus seems wrong to me. Why would some part of the wait not count
> > towards opening the cancel dialog?
>
> Because there is two callbacks we are waiting for and the dialog may pop up
> while we are in the first callback. So if you hit cancel then nothing is
> going to happen.
>
> But actually, I guess that can't happen because it wont interrupt the
> running code to handle the timeout, right?
Right. We're all single-threaded here. The timeout can only happen if you
return to the mainloop.
> > Why would you ever want to not view the component in nautilus? I thought
> > the main idea for having components in the mime data was that then a
> > component-supporting browser could show these inline?
>
> Maybe because you want to use a special component viewer with a different
> interface or other features? I am not sure, but I thought it would be a good
> idea to provide that flexibility.
Sound pretty unimportant to me. I mean, we don't even have an app you
could use as a component-viewer. :)
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl redhat com alla lysator liu se
He's a one-legged voodoo stage actor in drag. She's a disco-crazy insomniac
college professor with the soul of a mighty warrior. They fight crime!
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]