Re: Volume handling proposal
- From: Alexander Larsson <alexl redhat com>
- To: Ken Deeter <ktdeeter alumni princeton edu>
- Cc: nautilus-list gnome org
- Subject: Re: Volume handling proposal
- Date: 18 Sep 2003 10:39:33 +0200
On Wed, 2003-09-17 at 22:48, Ken Deeter wrote:
>
> Sorry about the last mail. I guess it just a bit too late at night, and
> my ssh:// wasn't working ;-)
> vs.
>
> >
> > Well, this mail is mostly about the user interface, exactly what VFS is
> > used underneath it isn't really the important part, although the
> > implementation notes part does use gnome-vfs. If we can agree on the
> > behaviour we want for the desktop we can implement that over any VFS
> > implementation we want.
> >
>
> Yes. At least the discussion on this list should I think strictly stick
> to discussing the interface. Maybe I did misread your email, but you did
> call it "volume handling" instead of "volume handling UI" ;-)
Heh. Yeah. A lot of people thought it was about the sound card volume. I
guess it wasn't that clear...
> > I'm on the freedesktop project, and there is discussions about a shared
> > VFS layer. But I think you severely misjudge the difficulty in doing
> > that. Most other freedesktop standards are about file-formats. Here we
> > have to share API/ABI, code freeze dates, codebase etc. For the near
> > future, gnome-vfs is what we have, so thats what the initial
> > implementation will use.
> >
>
> I probably do misjudge the difficulty. Is it a difficulty in terms of
> technicalities or interms of politics? At the same time, I guess it
> feels like saying, well we should never work on the kernel cuz its too
> hard to get it right and it doesn't fit the gtk or qt model. I think the
> point is that with this kind of thing although it is hard to do, the
> benefits likely outweigh the costs.
Well, its a combination. There is a technical issue, but there is also a
political/personal issue in that people have spent a lot of time and
energy into their stack, and don't want to have something that doesn't
fit there (thereby making their stack worse) just because of cross
desktop support.
To some degree these problems are possible to overcome, but it will
require a lot of work and politics.
> > I don't claim that the concept is unique to OS X, that would be stupid
> > and irrelevant. But the implementation that is closest to what I
> > proposed is in OS X, so its a good thing to refer to.
> >
>
> You mean UI implementation right?
Yeah.
> > The problem is that to develop stuff you want to use a stack of software
> > that makes devlopment easier, and in your model this stack is in the
> > [gtk] and [qt..] parts. This means the lower level software is really
> > hard to write and integrates poorly with the development stack that
> > applications then use.
> >
>
> I'm not sure about the 'harder to write' with respect to technical difficulty..
> I do agree that its less integrated.. but isn't it usually the case that
> a lower level system components don't worry too much about integrating well with the
> applications that sit on top of it? I'm not saying ignore UI concerns
> but, I think there is a difference in saying 'let's write GTK well so that
> it intergrates well with the system' and 'lets write the system well so
> it integrates with GTK'.. sure if the latter is possible its great, but just
> beacuse it might not be.. I don't know if its not worth doing then.
When I say 'integrate' I don't really mean graphically. Its more like
wether it fits/works in the system. For instance, callbacks and events
should use the native (glib or Qt) mainloop. Objects should be
QObjects/GObjects with the callback system uses in that stack
(signals/slots in Qt and signal emission in gnome). The more lower level
you get the less important these are, but a vfs backend has things like
asynchronous I/O (needs a mainloop) and authentication callbacks
(callbacks).
I guess that to do this in an acceptable way for both desktops it would
have to be a two-layer thing where there is a really really simple core
doing the I/O, using a higher-level library for integration with the
app, and there would be two implementations of the higher-level library.
Anyway, as you say, this discussion doesn't really belong here.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl redhat com alla lysator liu se
He's a leather-clad flyboy waffle chef from a doomed world. She's a
warm-hearted renegade museum curator with a birthmark shaped like Liberty's
torch. They fight crime!
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]