Brian J. Tarricone wrote:
nf2 wrote:
Donald Straney wrote:
I think a GUI for handlers would definitely help the user. For instance
i do a lot of PHP programming directly on the webserver. For editing i
use JEdit (because it works transparently over FTP). For copying files i
use Nautilus. The problem is that it's intransparent when my desktop is
connected to the FTP server. So i get annoying connection errors,
because the FTP-server only allowes a certain number of concurrent
connections. If the protocol handler had a GUI i could monitor
connections and disconnect with a mouseclick.
That sounds like an "unbreak my software" GUI. The real solution is to
fix the VFS layer to be better about a) caching and reusing connections
so as not to create an unnecessary number of them, b) handling errors
like that internally without bothering the user by disconnecting unused
connections or reusing an existing one, and c) being smarter about
knowing when a connection is really not being used and disconnecting it.
Of course it should do that. Thats why the protocol handlers should run
as one (multithreaded) instance per vfs resource: To be able to handle
smart connection management for multiple clients. But that's only one
part of the problem. The second part of the problem - i think - is the
lack of user-interface and "controlability" in an completely transparent
vfs. There is no smart way of knowing for how long an FTP server should
stay connected. It's also impossible to say when an archive that has
been opened for writing should be repacked and stored.
I have to say I agree with the other posters: most of this belongs much
lower than user application level.
Yes - and no. It's true that the interface to the vfs system should be
below the application and desktop layer (and not inside desktops like
now). That's the idea behind libvio. Everything vfs related should go
through the same low-level interface. But that doesn't mean that
protocol-handlers have to be gui-less.
Perhaps it is misleading to call them applications, but they could be
"almost" like applications: Launchable executables which bring their own
gui. With the limitation that you can only launch one of them at a time
for a certain resource ([EMAIL PROTECTED]) - and with support for auto-launching.
This is a bit unorthodox, but it would give protocol-handlers complete
freedom about the toolkit they use, the language they are written in,
how they interact with the user and it would make them desktop
independent regarding where and how they store their configuration,
passwords,...
It seems that users find it easy to understand the model of "old
fashioned" applications like gftp, winscp, file-roller: It supports the
kind of modular thinking users have about their computer: "i install and
run a certain gui-application for a certain task - and i close it when
i'm done." Furthermore those applications have a rich gui, give lots of
feedback, they allow monitoring activity etc...
I think it would be interesting to be able to combine this (successfull)
model with the ambition of KIO/Gnome-VFS to give all applications and
filemanagers on a desktop direct access to network resources,
archives,... :-)
norbert
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
