--- seventh guardian <[EMAIL PROTECTED]> wrote:
> But the thing I missed most since I left kde or xfce was some of the
> standardization: the xdg specifications (from freedesktop.org). The
> main things I miss:
Well, there already *is* standardisation amongst where fvwm places its
files. It does conform to the (more widely and more meaningful) FSH
standard as to where, within the hierarchy, its files should be placed.
That alone is important enough.
The problem that I have with the XDG specifications is that they're
based around a desktop environment, primarily. FVWM is not such a
program, it's a window manager.
> -The configurations stay in one place (usually ~/.config/prog_name/)
> and doesnt fill up the home dir.
Doesn't fill up one's $HOME? What do you mean by that, exactly? FVWM
already honours ~/.fvwm/ as a starting directory. This does not "fill
up" $HOME, anymore than ~/.config does in that regard. If your point
was meant that it doesn't use "~/" as the top-level directory, then
it's
a moot one, given ~/.fvwm is honoured by default.
> -The menu specifications: installed apps put their menu entries in
one
> place.
This is where I start to disagree with the XDG. Their "ideals" are
still DE-focused, borrowing heavily on KDE and GNOME for a botched
inspiration as to what should be "standard". I'm more for the question
of: "If we standardise everything, what benefit does this have to
FVWM?".
Consider this for a moment. If KDE and GNOME, and Fluxbox, and
$SOME_OTHER_WM_OR_DE completely standardised their file formats and
locations of files, does this make life any easier? Perhaps from a
neat
and tidy location perspective, but where I see drawbacks, are
portability. FVWM has very powerful scripting capabilities and
pre-processing powers that would not be able to do, if the file formats
had to be the same -- not without re-writing the way FVWM has to parse
its files.
Plus, FVWM does _not_ require that menu entries are in separate files
--
one can have them all within their fvwm2rc file, if one wishes -- and I
certainly prefer that. Why should everything be the same? The
flexibility and difference between these things is what makes things
more appealing.
> -The autostart dir (not standardized at the time, will be an
official
> standard in a few days)
Again, I always thought this contrite when one can do this in so many
different ways, via ~/.x{session,initrc}, a session manager, etc. In
fact, using "autostart" as a standard might well inhibit how session
managers work -- as they might well start loading more instances of a
said application.
>From an FVWM perspective though, it's completely superfluous to adhere
to this "standard" -- why do you think "StartFunction" exists?
> -The trash dir management.
This again is a desktop environment concept -- which FVWM *is not*.
Trash directory management seems to suggest some sort of file
management
which is inherent in KDE, GNOME, and other DEs. If you want this sort
of thing, I suggest you look at (and use) Rox-Filer [1].
> On the other hand, it's a nice feeling to be able to control
> everything from the setup scripts.
There you are, see? :) That's what I'm saying -- the difference is
what makes it appealing.
> So what I started doing was to adapt what I could of fvwm to the
> standards, while keeping the benefit of it's freedom of
configuration:
> for instance, I moved ~/.fvwm/ to ~/.config/fvwm/.
> (I keep a simlink from the old place to the new one, for now, because
> it doesn't work otherwise.) Also, I started writting a trash
See the "-f" flag, to FVWM. Of course, FVWM does honour
"$FVWM_USERDIR"
which you could easily change to wherever you want to point your
configuration files. But IMO, it's a falsehood to your own testimony
--
a fake, if you will. It doesn't add anymore functionality at this
current point in time -- because FVWM lacks the ability of "trash dir
management" and reading menu files in a separate file in some separate
location.
> management library following the xdg specs, so that trash management
> wrappers can be built around it.
Again, I disagree with this, entirely. It won't work -- FVWM is *not*
a
desktop environment -- it does not have a built-in file manager.
> So what I propose is to make fvwm try to follow these standards,
while
> not compromising our freedom of choice:
So far, it's looking grim.
>
> ** The base directory spec: move ~/.fvwm/ to $XDG_CONFIG_HOME/fvwm/
> (defaults to ~/.config/fvwm/)
See above, $FVWM_USERDIR.
> This could easilly be implemented and would benefit everyone, by
> uncluttering the home dir. If the devs don't mind, it could be used
> instead of ~/.fvwm/ ..
Benefit whom, exactly? And could you please explain what you mean with
this "cluttering" effect? Dot files are part of UNIX since its
creation. They serve a good purpose, and don't clutter anything up
(hint: /bin/ls $HOME) -- no dot files shown there.
>
> ** The autostart spec (currently a draft): have a
> $XDG_CONFIG_HOME/autostart/ dir, a place where .desktop files could
be
> placed to autostart programs.
See above.
> Yes, autostarting can be made from the fvwm config file. But it's
only
> used by fvwm, and having a desktop-independent place to do it would
be
> nice. Also, that would allow to make changes easilly without messing
> with the config files (good for newbies :P).
Personally, I feel that newbies should embrace FVWM by learning how
*it*
does things. It doesn't do it any different from other WMs. It has
config files, a man page, and idomatic way of doing things. I have
already mentioned how you can "autostart" files independant of FVWM.
> In order to make it easy on the main code, there could be an external
> program availiable in a "standardization package" that one could exec
> from the config to do that. Clean and easy, also if someone doesn't
> like it, he doesn't use it.
Which begs the question why bother doing it at all? If the choice is
there, it would be a real PITA -- not to mention augment the core FVWM
code to adhere to Yet Another Standard. Don't get me wrong, there are
a
lot of standards I *do* agree with. FVWM is already fully
EWMH-compliant, and it (by definition) conforms to the ICCCM. But I
have problems with the XDG. It's making an assumption and an
implication that KDE, GNOME, etc, etc, etc *should* conform to various
file locations, etc. Why should they? Where's the benefit? If you
think it's so that you can change an "exec $TODAYS_WM_PLEASE" in
~/.xsession, then fine. But that's lazy. It's also restrictive.
> ** The menu spec: have a $XDG_CONFIG_HOME/menu/ where installed apps
> put their menus items in.
Again, see somewhere way above, why I disagree with this.
> The same way as before, there could be an external program to make
> fvwm menu entries from the dir items. We could put them in a submenu
> like "all apps" or something. Then we wouldn't need to edit the
config
> or to use the console every time we install a new app.
Debian already does this in the form of "menu.hook" files. There's a
spec for it on the Debian website (see the 'menu' package for more
details.) Gentoo have a very slow, but similarly-evolving idea.
> This doesn't replace the "user created" menus, but allows us to find
> in a submenu a specific app we don't use that much, or something like
> that. We still can manually create easy-to-find entries for our
> favourite apps.. Also like before, one could opt to use it in the
> config or not.
Swings and roundabouts. There's a hundred ways you could do this for
FVWM.
> ** The trash dir spec.
>
> Ok, not so much we could do related to fvwm :P but some desklets
could
> implement it :)
How? Again, "desklet" is a desktop environment phrase, and it makes me
chringe. :) In order for it to work you would need to make a program
aware a file had been deleted -- but more importantly, it would have to
be done *only* via this said program to work. "rm ~/foofile" from
within a console would just delete it. No trash directory there.
Again, see "Rox-Filer". Nothing to do with FVWM.
> ********
>
> Other xdg compliant add-ons could be made according to the user
needs.
Oh, you mean like a user writing a module using FvwmPerl?
> None of them forces the user to use them, and none of them requires
> the direct intervention of the fvwm dev team, except the first one..
> If they don't mind either changing the config dir or adding another
> one, following the spec, it would be nice.
But it would require "direct intervention". It would require changes in
the way FVWM reads its files, and the format they're in. A ".desktop"
file reminds me of Windows .ini files. Yuck. Since these .desktop
files would have to be read a startup, *and* they're in a format alien
to FVWM, this means one of two things:
* FVWM's internal structure and config file parsing is changed
or:
* These .desktop files are preprocessed into a format FVWM can
understand.
Of course, my own opinion is that we should say: "Sod it", and make
the
$USER of FVWM aware of why one has a "StartFunction". But as we're
looking at this seriously, I don't have that luxury. The first option,
I'd be inclined to ignore -- it's a lot of work for a gain for no real
advantage whatsoever.
The second option is doable, but it would require that one writes a
module (FvwmPerl?) that would preprocess these files. But this has a
drawback, both in terms of speed, and in the file format needed before
preprocessing were to take place.
> I'll eventually make some addons for my personal use, by my pace, but
> once finished they will be released under gpl :) If any of you want
to
> join the effort please feel free to do so.
The question is: "Do we really need it?" You can turn FVWM into a
pseudo-desktop-environment easily enough -- run nautilus, or Rox-Filer,
or somesuch. Consider also the compatability issues there'd be if the
config locations were changed.
The freedesktop people have some good ideas. Their thoughts about EWMH
is one such example. But as far as the XDG is concerned; I think it's
a waste of time.
-- Thomas Adam
[1] http://rox.sf.net
"The Linux Weekend Mechanic" -- http://linuxgazette.net
"TAG Editor" -- http://linuxgazette.net
"<shrug> We'll just save up your sins, Thomas, and punish
you for all of them at once when you get better. The
experience will probably kill you. :)"
-- Benjamin A. Okopnik (Linux Gazette Technical Editor)
___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail
http://uk.messenger.yahoo.com
