[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Application roles
From: |
Nicolas Roard |
Subject: |
Re: Application roles |
Date: |
Mon, 16 Feb 2004 04:54:26 -1100 |
On 2004-02-16 12:53:29 +0000 Raffael Herzog <herzog-lists@raffael.ch>
wrote:
I see a problem with such roles: How do we standardise them?
Currently,
? well, we need to standardise them, yes, but it just means that we'll
agree on a
set of services methods that a particular role should implement,
that's all...
GNUstep has a simple but well working concept of file types. In
Info-gnustep
you can also list three roles: NSViewer or NSEditor. NSNone is used
for
non-file-based tools like e.g. an IRC client. I think this is
basically
enough, although there definitely are cases where it gets difficult.
Let's
take three examples and see whether we can solve it with what we
already
have:
1. Text Editor
The user might want to use his default text editor for something,
e.g. in
GNUMail, when composing a message, he might want to use some menu
Edit->Open
in Text Editor.
Now we know the GNUstep type of plain text which is ".txt" and we
also know
the preferred application to handle these files. So this scenario can
be
solved by saving a temporary txt file and ask the Workspace to open
it with
the default application. Scenario solved without extending GNUstep.
That's a bit ugly, really :)
2. URLs
A difficult one. :) Let's assume the user clicks a URL in GNUMail to
open it
with whatever can handle that URL. for a http://... URL this would be
the web
browser, for a ftp:// URL, it would be GWNet.
GWorkspace 0.6.3 introduced a concept that can be used to solve this
scenario: There are URL handlers, i.e. GWNet determines the
application to be
used to open a URL by it's protocol part. Two handlers are already
provided:
FTP and SMB. More possible handlers are HTTP and HTTPS.
Here we need to extend GNUstep by not only mapping file types to
applications
but also mapping protocols to applications. Basically the same thing
as with
file types, just for protocols. In Info-gnustep.plist:
GSProtocols = (
{
GSIdentifiers = ( http );
GSName = "World Wide Web";
},
{
GSIdentifiers = ( https );
GSName = "World Wide Web (Encrypted)"
});
Like this, protocols can be mapped to applications without any need
for
application roles. The Cocoa API already provides an interface for
this:
[[NSWorkspace sharedWorkspace] openURL: @"http://www.gnustep.org/"]
-- it
just needs to be implemented.
Yes.
3. Mailing
Actually, I'd stick to services for this one. Standardisation is
needed
anyway, no matter whether application roles are introduced or we
simply
define some services a mail client should provide. Basically, IMO,
services
on a standardised basis are exactly the same as application roles as
you
described, just without adding anything to GNUstep. :)
But ... in my point of view, roles could be more than just default
applications
for dealing with a file type ! Particularly because we already have a
support
for these kind of things, as you noticed; The "URL opening" problem
isn't
really difficult to solve if we model it on the same idea as the
current NSViewer
plist entry (eg we could just have some NSURLViewer key ...) -- and
yes, I think
we need to code that, because it will be useful for many applications
(basically, all the apps that deal with internet, like browsers, im
client, etc.).
So, adapting the current NSViewer to URL is a good idea and would need
to
be done, yes (some volunteer ?). But what I'd like with roles isn't
just that -- In my opinion, roles are more for providing
inter-applications
services, like sending a mail, or a file through different methods, or
encrypting
something, etc.
More or less what could be provided with services in fact; so what
will be the
difference with services and roles ? well, standardisation (and
perhaps some kind
of method for a program to see what roles are present).
You could see them as services for programmers, not user :-)
The good thing is that it will lead to a better cooperation between
apps, and
personally, that's that sort of thing I'd like to have with an OO
desktop.
Also, I wonder if the mechanism used with roles could be extended to
not only
provides basic roles (Web Browser, FTP, whatever) and let the
environment
choose the right app among many, but also to provide some standard way
to
add value to the overall "programming" environment; For example, we
could have
a role "send file" but with different methods (by mail, by ftp, by im,
etc.), etc.
But yes, it's kinda like services, just more organized.
--
NIcolas Roard