discuss-gnustep
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]