xffm status and (small) request :)

edscott wilson garcia edscott at imp.mx
Thu Mar 6 15:30:04 CET 2003

El jue, 06-03-2003 a las 00:52, Olivier Fourdan escribió:
> For some reason, my messages don't show up in the list...
> --
> Hi Edscott,
> I'm wondering, what's the status of samba support in xffm ? And the
> general status of xffm, from your point of view.

That's coming next. It should be working in about a week or so (although
at first it will only go as far as the first releases of xfsamba).

> I have another question regarding mcs support in xffm. From the comments
> in the code, I wonder if the support is implemented as it should
> (especially, the "remote app" comment, as this is handled by mcs, no
> need for a local file) - As for preference menu, it should be removed
> all together and replaced by a call to mcs manager to show the mcs
> plugin (like xfce panel does). The goal of mcs is to have a centralized,
> host independent, common interface for all applications configuration. 

I understand this, but I'm faced with having to run xffm remotely on a
display where the ability to read its own local config file is necesary.
Some elements require different configuration, like the "use rsh" and
"use rsync". Example: say you are running xffm on a Beowulf computer
cluster. In this case, copying between cluster nodes should be done with
rsh and copying with computers outside the cluster with scp. Since the
copy method is determined by the xffm instance which receives the drop,
this is easily done with individual xffm configurations.

At the moment the configuration of all xffm instances are changed by the
mcs manager, if one is running (I kinda like that) so that a uniform
appearance can be acheived at the click of a button. 

The menus (main and popups) are still alpha and I will remove many of
the settings elements which do not requiere localization and have them
live with the mcs manager. For example, the "show main menu" has no need
to be in the xffm menus, since there is a rapid hide/show button always
present, but it is good to have it with the mcs-manager to hit all xffm
instances at once. And since the code for menus is shared for the plugin
and xffm, that means I will have to remove either "view" or
"preferences" menu. And I need a new name for the elements to be merged.
I'm thinking about "local settings" and "global settings" off the top of
my head but I'm open to all suggestions.

FWIW, the xffm-gui should be considered alpha whilst it requires the
glade files. The glade code generation is *terribly* inefficient and
will be totally removed, once all these rough edges are smoothed. Glade
just gives us the chance to play with the gui look with ease during this
development stage. 

> Other than that, I have a small request... Could you remove the "xfce"
> theme, it's really ugly and in fact, I'm trying to smoothly cut the CDE
> look from xfce (well, okay, it's my goal)... Or at least, default to
> gnome look.

Hey Joe, where are you! ;-) I admit the xfce-cde theme has some ugly
stuff which should be fixed, but I kinda like it (I got dizzy with all
the gnome bright colors). But I see no problem with changing the default
back to gnome. I'll do that later today.

> Hehehe, I know I'll be flamed for saying that... Maybe you could make
> that a separate package ?

The gnome icons are available as a separate package from gnome, and they
could be removed from the xffm tree (with some modifications), but this
would introduce a dependency to gnome. Rox icons are also available as a
separate package, as well as kde. This seems to point to doing the same
with the xfce-cde icons. Then if the user does not install any of the
above set of icons, he/she would be stuck with the "no_icons" theme.
Which is fine with me. What do you say? Would it be a good idea to leave
all icons out and depend upon external packages? (We would still need
the mime.xml files for each theme). I think it would be easier to add
the next icon theme (rox) this way.



More information about the Xfce4-dev mailing list