Re: About the Gnome Help browser
- From: Stephanos Piperoglou <sp249 cam ac uk>
- To: Cristian Gafton <gafton redhat com>
- cc: gnome-list gnome org
- Subject: Re: About the Gnome Help browser
- Date: Tue, 24 Feb 1998 21:57:14 +0000 (GMT)
On Tue, 24 Feb 1998, Cristian Gafton wrote:
> Unless you really want to make the file:// thing far smarter than it
> should really be and risk running into some ugly stuff and be beaten by
> our own limitations - just figure out that I have a foobar.1 file in a
> directory and I want to open it to see the man _source_, not the formatted
> crap, and file:// will only give me the formatted crap, because it is far
> smarter than it should really be. (I know one would have 'View source'
> thing, but that is not an universal answer - figure out other applications
> trying to display the source file in this browser...)
This would be very easily implemented if you seperated resource
identification, resource location and resource handling... You can choose
view or view source or edit (or compile, or compile & gzip, or add to whatis
for this filetype, for instance).
GNOME itself would handle this mechanism, but the help browser would make
the calls to it. So the /help browser/ would actually make a call specifying
that it wants a *view* action on that resource; the text editor would
obviously request it with an *edit* action. The filemanager would offer a
drop-down menu of actions /or/ a default action (which would probably be
view).
Sequence from within the hepl browser:
1. Help browser requests resource
2. System parses URI and uses the specified protocol to retrieve resource
3. System determines file type and tells the help browser what it is.
4. Help browser checks to see if this is the file type it expected and if
not, returns an error message, else gets the resource from the system and
displays it.
Sequence from within a file manager or generic resource locator/handler:
1. User enters URL (interactively - via icon representation of filesystem -
or manually)
2. System parses URL and retrieves, bla bla
3. System determines file type and possible actions
4. User chooses an action
5. App gets executed (or the system communicates with it if it is already
running).
-- Stephanos Piperoglou -- sp249@cam.ac.uk -------------------
All I want is a little love and a lot of money. In that order.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]