What are the objectives for Xfce 4.4?
erikharrison at gmail.com
Tue Feb 1 21:54:10 CET 2005
On Tue, 01 Feb 2005 20:50:40 +0100, Benedikt Meurer
<benedikt.meurer at unix-ag.uni-siegen.de> wrote:
> Brian J. Tarricone wrote:
> >> * xffm to be replaced by a smaller, simpler, more basic file manager.
> > Actually, I'd like to see no file manager in the core whatsoever.
> Thats what I'm trying to tell for a long time: Have no 3rd party apps in
> > Well,
> > sorta. I think we should have a really stripped-down file view widget
> > with file-management capabilities in libxfcegui4 (or if it ends up being
> > to large, perhaps its own library). Xfdesktop can optionally create an
> > instance of this widget (by dlopen()ing it if its in its own library)
> > for the desktop, and a separate file manager binary could do something
> > similar, and implement a configuration interface and a host of other
> > nifty things. But this file manager need not be in the core.
> > I'm really *really* against folding desktop management duties into the
> > file manager a la nautilus. It just doesn't make sense, IMHO, and makes
> > it difficult for users to a) use Xfce's file manager with a different
> > DE, or b) use Xfce with a different file manager. I'm actually
> > surprised that was suggested, as it seems like quite the opposite of
> > modularity.
> I really *klemmer* this idea. I don't see why a file manager shouldn't
> be desktop-independent, or why it should reduce Xfce's modularity, but I
> see that such a `file view widget library' will surely become a
> maintaince problem.
I think that, really, the 2.6 icon view does this already. The fd.o
spec gives us a "standard" way to get an icon theme which would match
various compliant file managers, apps install .desktop files which
point to their icon, etc. So, really, xfdesktop can make a solid
effort to match exisiting look and feel without us having to maintain
a seperate widget, if we make 2.6 the target GTK version.
The danger is what happens when I double click on those objects on my
desktop that aren't executables? That could probably be solved by
invoking a single standard command which then does the hardwork of
integrating with the user's chosen filemanger (since there isn't a
fd.o standard yet for defining prefered apps for MIME types). Such a
command for Rox or Xffm would be pretty easy to write, since they
allow "xffm document.txt" to open in mousepad or whatever.
Another integration snag is what happens when you right click on an
object on the desktop? That's harder to solve, but frankly, I want to
do filemanagement type things on those objects - change permissions,
delete them, blah blah. Is the xfdesktop a view of a folder (ala
Nautilus) or a virtual space (ala Rox). I prefer the former, but the
later might solve the integration question (since they aren't really
Anyone got any thoughts on this?
> > -b
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
CAPS LOCK: ITS LIKE THE CRUISE CONTROL FOR AWESOME
More information about the Xfce4-dev