Re: RE : GSMBrowser.

[Stefan Urbanek]

On 2003-02-05 10:57:35 +0100 Peter Cooper <comrade@obverse.com.au> wrote:

> > Sounds very nice and interesting ... but It is the second file browser in
> > gnustep.
>
> As long as drag-and-drop work fairly well, it's a very useful tool.

Yes, nice app.

> > IMO, wouldn't it better to have something like a bundle in order to use
> > GSMBrowser abilities in GWorkspace ? rather than use 2 different
> > applications ?
>
> Actually, it would be nicer to have this functionality available
> throughout the system, which probably means something like a fairly
> standardised way of mapping new mechanisms for file access into GS base.

What about using URLs? You can have samba://foo/bar, cvs://, file://, or even 
mail://mailbox/message_id where mailbox is abstract mailbox defined by GNUmail 
for example. URL is more general than file reference. From programmers poit of 
view initWithURL should be prefered instead of initWithFile:


> Preferences panels would be needed for most of these kinds of extensions,
> at least to provide parameters for mapping these additional directory trees 
> into the hierarchy. In some cases, you might even get away with using
> legacy userland tools to provide underlying transport (like in GSMBrowser
> today).

UNIX idea of single file tree is not bad, but i think that URLs have their 
advantages too. You can have several DO servers or apps handling various URL 
types, like SMBBrowser for samba://, GWorkspace for file// or Teminal.app for 
telnet:// . Each application/tool can handle its own preferences and will 
provide its specific functionality. Moreover, URL handlers can be 
user-configurable.

> Tools and applications that use native file access capabilities wouldn't
> behave correctly, of course, but well-behaved GNUstep apps would experience
> a fairly seamless ability to browse, open and save files in whatever storage
> systems were put in place, if they used methods in NSFileHandle, NSFileManager,
> and so on.

Regarding to using native file access... I think that plain file reference as 
it is widely used now should be soon or later deprecated in the favor of more 
general URL. For this, some decent way of URL chooser (like open/save panel) is 
needed... or just using Workspace for the functionality of URL chooser panels.

> It would be very nice to be able to use the Workspace to browse to a
> SMB server, as well as an arbitrary FTP server, or a CVS space or a
> database-backed content management system and simply use my favourite
> apps to edit in-place, or at least to view in-place. It then frees application 
> developers (thinking ProjectCenter for example) from having
> to implement complex additional functionality (CVS) into their software,
> when that functionality might be usefully used by many different apps.

I agree. What about various subclasses of NSFileManager like SambaFileManager, 
FTPFileManage or CVSFileManager implemented as DO servers or applications? 
There should be one server for NSFileManager functionality and one for 
NSWorkspace's openURL:. They can be in one app or separate...

> But what is the best way of actually adding this kind of functionality?

By using URLs we do not have to muckle with file system hierarchy and tools. 
Moreover, it will be users choice for tools for handling url types. What about 
some user condigurable DO server/broger which will provide information about 
url handlers (other DO servers)? One will ask for object that can handle samba 
url types and will get SMBBrowser or any other tool...

GNUstep with its advantage of cooperating objects can do all this. It can do 
more than using programs for processing text output using pipes...

Just thinking...

Stefan Urbanek