Re: [Utopia] KDE Volume Manager

[David Zeuthen <david fubar dk>]

On Fri, 2004-08-20 at 13:34 +0200, Jerome Lodewyck wrote:
> On Fri, 20 Aug 2004, David Zeuthen wrote:
> 
> > Hi,
> >
> > (side item: care to point me to some (generic perhaps?) instructions on
> > how to compile it? I'm staring at a configure.in.in and no autogen.sh
> > etc. Thanks.)
> 
> Actually, the CVS compiling intructions are in the README file. The
> INSTALL file is for releases. 

Oh, but Makefile.cvs is missing.

> However, compiling it requires some hacking
> in the dbus-qt bindings because they do not provide main loop integration
> (http://freedesktop.org/pipermail/dbus/2004-August/001449.html ). I will
> try to make a complete patch tomorrow.
> 

That would be cool, thanks.

> > > check for tracks and eventually play it. But for VCD, it is much more
> > > complicated since xine (I haven't checked other players) doesn't play
> > > mounted VCD's. So the steps are : mounting, checking for tracks,
> > > unmounting and playing. Quite tricky and lengthy. So a volume.disc.is_vcd
> > > would be much more convenient.
> > >
> >
> > Yup, we kind of discussed what the hal daemon should and shouldn't do on
> > the hal mailing list on freedesktop.org a while back. I think the
> > conclusion was that HAL should stay out of policy and only care about
> > presenting the device objects it sees in a somewhat abstract way with
> > minimal interference to the system (e.g. don't do any invasive polling
> > etc. that breaks existing software).
> 
> I agree. However, a non-ivasive polling for VCD would be nice... Is there
> a VCD expert on this list ?
> 

I'm no VCD expert at all, but

 http://www.disctronics.co.uk/technology/cd-rom/videocd.htm
 http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=004EdS

suggests that the data track is ISO9660 and the other tracks carry the
MPEG data. Perhaps it's as simple as this: to detect a VCD, simply mount
the data track and check the for the appropriate files. 

Btw, access to the disc, in Linux at least, isn't exclusive. My
understanding is that it should be possible to write a VCD player that
works even though the data track is mounted. But I've never really tried
that so I'm probably wrong. Oh well.

Now, the reason I'm not happy to have this in HAL is that it probably
requires reading stuff of the disc other than metadata (such as
filesystem type) and this is not something I'm keen on doing.

> > And since it involves policy (mounting/unmounting) I think kvm/gvm is
> > the right place in the stack to do this. It would be cool, however, to
> > share some of this code between gvm and gvm though; one thing to do
> > would be to stick it in a library libhal-volume (could have native Qt
> > bindings) and ship it with hal?
> >
> > Another reason for doing this is that we could share code (and, perhaps
> > more important, policy) for actually selecting the icons representing
> > the volume and the name representing the volume, see
> > http://freedesktop.org/~david/gnome-vfs-take3-1.png for how GNOME VFS
> > does this when built with --enable-hal. The result would be greater
> > integration between e.g. Konqueror and Nautilus and some standardisation
> > on the icon names. Heck, even fstab-sync could use this library for
> > creating mount point names.
> 
> I really like the idea of a shared naming policy. Furthermore, making a
> desktop independent library for this should be quite straightforward
> (except for internationalization). But for icons, this would require much
> prior work, since gnome and kde don't share icon names and icon set.
> 

Cool, I'll try to whack up a libhal-volume prototype, then we can take
it from there. I'll post it to the hal list on freedesktop.org, that's
more appropriate than here.

Regarding icons, yeah, we probably want to use the freedesktop.org icon
theme standard for the icons; so all we need to agree on is a set of
names; these are the names and icons proposed for GNOME VFS

 http://freedesktop.org/~david/gnome-vfs-take3-2.png

but, yeah, it will take some time and sweat. Until that happens, I
suppose one way around this is to keep N sets of icon names in the
libhal-volume library and have the user give a parameter to the init()
function. Eventually we can introduce a new parameter called
FDO_NAMING_SCHEME or something.

Internationalization; that's a tough one, but I think that the GNOME and
KDE translators are at least working together on the shared MIME stuff.

David