Dan Nicholson wrote:
> Looks good so far.
>
> On 5/14/07, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> Attached is a very early preview of the patch that updates xfce in the book.
>> Comments are welcome.
>>
>> I had to drop the "minimal" installation variant because of the optional
>> dependencies between xfce components, and because I want all clickable
>> buttons to work in the "minimal" installation.
>>
>> This cannot go in for the following reasons:
>>
>> 1) It is different from the LiveCD implementation and thus completely
>> untested
>
> What are the key differences? If there's not a big difference, I say
> put it in and we'll let people find the bugs. This is the development
> book, after all.
The key difference is that HAL is used on the CD (although not configured
correctly yet for shutting the computer down). And many updated versions of
external packages WRT the book (the most worrisome is D-BUS).
>> OTOH, I am not sure if I am able to maintain xfce in the book. Maybe it is
>> better to drop it instead of updating.
>
> I'll maintain it if needed. Why do you not think you can maintain it?
> Time? Differences with the Live CD? If it's because of differences
> with the LiveCD, then I say to ignore it and do your best. I trust
> your ability to map the differences, and it seems you have more
> experience than any of the other editors with xfce _because of_ the
> LiveCD. In my opinion.
OK, I accept this once someone runs through the updated instructions and
verifies that:
a) there are no build failures due to different package versions
b) HAL is not used for volume management
c) removes at least one "untested" note (gtk-doc would be the obvious first
choice).
>> + <para>Some of XFce components have optional dependencies on HAL. E.g.,
>> + <xref linkend="exo"/> and <xref linkend="Thunar"/> use HAL as a volume
>> + manager in order to mount removable media. However, in non-English
>> + environments, it is often needed to pass <quote>iocharset</quote>
>> + and <quote>codepage</quote> mount options. This is impossible, because
>> + mount options are hard-coded in the <command>exo-mount</command>
>> + program. Thus, it is recommended that you don't use the HAL dependency.
>> + Installation instructions below make sure that HAL is not used as a
>> + volume manager even if found.</para>
>
> This sucks (obviously). So, I started looking at the source of
> exo-mount and gnome-mount and how they interact with hal. In both
> cases, it seems they handle the case where the volume is in fstab by
> calling /bin/mount directly with the listed options. Otherwise, they
> use hal to do the mounting. So, it seems that if you need to pass more
> options such as iocharset, then you can add it to fstab. Here's the
> exo-mount code:
>
> /* check if the device appears in the fstab,
> * if so, we cannot use HAL to mount it.
> */
> #ifdef HAVE_HAL
> if (!exo_mount_fstab_contains (opt_device))
> {
> /* perform the requested operation */
> if (G_LIKELY (opt_unmount))
> exo_mount_hal_device_unmount (device, &err);
> else if (G_LIKELY (opt_eject))
> exo_mount_hal_device_eject (device, &err);
> else
> exo_mount_hal_device_mount (device, &err);
> }
> else
> #endif
> {
> /* perform the requested operation */
> if (G_LIKELY (opt_unmount))
> exo_mount_fstab_unmount (opt_device, &err);
> else if (G_LIKELY (opt_eject))
> exo_mount_fstab_eject (opt_device, &err);
> else
> exo_mount_fstab_mount (opt_device, &err);
> }
>
> So, it seems that if the device is listed in fstab, it will just pass
> over hal. Gnome-mount does something similar. HAL Mount() will ignore
> devices in fstab, but if the appropriate agent handles that case
> (gnome-mount, pmount, etc.) then we can have both. Could you see what
> happens with exo if you list a removable volume in fstab with extra
> mount options? I'll try with gnome-mount when I get home.
I will certainly try this when I recover from the illness. However, this
would likely mean that we compile with HAL but tell the user to avoid using
it. I must check whether there are any differences with the case when HAL is
completely disabled.
>> + <para><ulink url="http://www.galago-project.org/";>libnotify</ulink>
>> provides
>> + support for desktop notifications. The only source of such
>> notifications in
>> + XFce itself is <command>Thunar</command>, which (if compiled with HAL)
>> + notifies the user when it is safe to remove the media. However, HAL
>> + dependency is unwanted, as explained above. Additionally, in order to
>> + actually see the notifications, one needs to compile
>> + <ulink
>> url="http://goodies.xfce.org/projects/applications/notification-daemon-xfce";>notification-daemon-xfce</ulink>,
>> + which depends upon <ulink
>> url="http://www.chipx86.com/wiki/Libsexy";>libsexy</ulink>.</para>
>
> We should consider adding libnotify/libsexy/notification-daemon* to the book.
+1, assuming that the GNOME-based notification daemon also ends up in the book.
Maybe I should also place links to applications like xfmedia (xine-based
media player integrated with xfce), xfburn (CD burner) and other XFCE goodies.
BTW xfmedia, as well as gaim-libnotify plugin, is on the latest CD. Get a
preview: http://ums.usu.ru/~patrakov/test/lfslivecd-x86-6.3-pre2-r1887.iso
(this is not a release, thus not announcing on other lists).
If you have only one DVD-ROM drive, but at least 768 MB of RAM (or, 512 MB +
swap), you can boot the CD as "linux toram" and then play DVDs. Pass "linux
pata" to try new libata-based drivers for IDE controllers (warning: they
will rename disks from /dev/hda to /dev/sda and so on).
Many thanks for reviewing the text.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
