From owner-freebsd-questions@FreeBSD.ORG Wed Dec 31 05:07:55 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D353CE70 for ; Wed, 31 Dec 2014 05:07:55 +0000 (UTC) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 62ABD2658 for ; Wed, 31 Dec 2014 05:07:55 +0000 (UTC) Received: from r56.edvax.de (port-92-195-39-170.dynamic.qsc.de [92.195.39.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx02.qsc.de (Postfix) with ESMTPS id 1BB8A276BC; Wed, 31 Dec 2014 06:07:52 +0100 (CET) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id sBV57qsL002415; Wed, 31 Dec 2014 06:07:52 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Wed, 31 Dec 2014 06:07:52 +0100 From: Polytropon To: Warren Block Subject: Re: Xwindow advise needed Message-Id: <20141231060752.26b5a326.freebsd@edvax.de> In-Reply-To: References: <55358.128.135.70.2.1419874589.squirrel@cosmo.uchicago.edu> <20141229235045.b8156cdf.freebsd@edvax.de> <20141231044147.fe7a9983.freebsd@edvax.de> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 05:07:55 -0000 On Tue, 30 Dec 2014 21:15:55 -0700 (MST), Warren Block wrote: > On Wed, 31 Dec 2014, Polytropon wrote: > > > The problem is not the automounter itself. It's its > > integration with the GUI elements, in two ways: > > > > 1st, when the automounter mounts a device which has > > been appearing, either by a label or by a device name, > > this new mountpoint must be "picked up" by the GUI > > and be shown on the desktop. > > > > 2nd, there must be a desktop action to unmount the > > device, and for those which support it, eject it. > > At one point, I wrote my own automounter. xfce or Thunar can add menu > entries, and I added one for unmount. The Gnome 2 system I had installed also had functions for unmounting, but it simply didn't work (even though permissions were set up as per the instructions, the permission was denied). So the system mounted media, but never unmounted it through the GUI. > > Just to add a short note about automounting in general: > > While this is a useful feature for most _personal_ desktop > > computer usage, there might be situations where it can > > cause immense trouble, like people stealing data, or > > putting (incriminating) data on your system. It's also > > dangerous when you attach a device that you want to > > perform forensic analysis or data recovery on - one > > stupid write, and you're out of luck. That's why I'd > > like to see a more differentiated approach in _any_ of > > the desktop environments supporting mounts: > > > > a) signal the appearing of a new device to the user, > > who can then select to mount it or just to leave > > it as is; or > > > > b) automatically mount a new device and show an icon > > shortcut to the mountpoint. > > The first could work for all users, really. I'd say so, too, but some users expect "more". :-) The basic concept within GUIs is that a process will monitor a directory for new entries, such as /media, and when a new entry is being created as a mountpoint, for example /media/THE_LABEL_OF_THE_DVD or /media/da0, an icon shortcut will be displayed, together with a context menu entry to unmount. For Gtk-based environments, I think FAM (libfam, gio-fam-backend) is the "file alternation monitor" that's being used. Do you remember how XFCE (capital letters -> version 3) did this? They had a xfmount wrapper which would simply perform "mount " according to /etc/fstab and then open a file browser with ; when the file browser was closed, the xfumount wrapper would be called, executing "umount ". This of course required you to make sure the mount points existed and you had to add the menu entries manually. For a "static system", it was a good solution, but for today's systems with the many possibilities of what to attach especially to USB, this doesn't work anymore. I also remember that automounting _did_ work in Gnome 1 and many versions of KDE, even before HAL and DBUS did even exist... > > The user should be able to select which policy to apply. > > For optical media, _blank_ optical media, it gets even > > more funny, let alone music CDs... :-) > > file(1) can be used to detect many kinds of filesystems and binaries. > It could be used to at least suggest mounting or playing options. I think this magic is somehow included in Gnome. If I remember correctly, a right click with "open media player" or "play with How important this is really depends on the user. Some would say that a > GUI for wireless/wired network configuration would be more useful. For those who use their computer connected to the same wired interface every day, the importance may vary, but I agree that a nice replacement for wpagui (I think that was its name, didn't investigate further, didn't work as expected) would be a good addition. As I said, Lumina folks seem to try to get all the parts neccessary for a good desktop environment togehter, native and working on FreeBSD. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...