[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Application roles
From: |
Raffael Herzog |
Subject: |
Re: Application roles |
Date: |
Mon, 16 Feb 2004 13:53:29 +0100 |
User-agent: |
Opera7.23/Linux M2 build 518 |
On Sun, 15 Feb 2004 19:21:57 +0100, Stefan Urbanek <stefan@agentfarms.net>
wrote:
Today on #gnustep was a discussion about presenting applications to the
users in some nicer way. Besides idea of providing 'Display name' in
application information plists, I had an idea of 'Application Roles'
that I would like to share and hear your comments.
What is an application role? Nothing more and nothing less than a short
(one-two words) description what application does: 'Mailer', 'Web
Browser', 'Text Editor'. Each developer should provide this role in a
.plist and Workplace.app (GWorkspace) should display all application in
one of the following ways:
Mozilla.app, Firebird.app, Opera.app (as it does currently) - honestly,
would you know what those applications do? So what about using 'role'
definition when displaying application name:
Web Browser - Mozilla
Web Browser - Firebird
...
Or for users with single variant just: 'Web Browser'
I see a problem with such roles: How do we standardise them? Currently,
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.
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.
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. :)
cu,
Raffi
--
The difference between theory and practice is that in theory, there is no
difference, but in practice, there is.
Raffael Herzog - herzog@raffael.ch - www.raffael.ch - ICQ #67961355
- Application roles, Stefan Urbanek, 2004/02/15
- Re: Application roles,
Raffael Herzog <=
- Message not available