(forgot to cc the mailing list)

On Wed, Jun 5, 2019 at 4:30 PM Ronald F. Guilmette
<r...@tristatelogic.com> wrote:
>
>
> In message <20190605213540.hmud7pziqi64a6i5@laptop.local>,
> Thomas Adam <tho...@fvwm.org> wrote:
>
> >> For me, 3c was in fact just a blank space.  I just now figured out why.  On
> >> FreeBSD, the xload command is in a separate package, all on its own, and 
> >> that
> >> package is *not* currently listed as dependency of the fvwm package.  (I 
> >> will
> >> be speakingt o the maintainer about this.)  As a result, my system was 
> >> running
> >
> >No sane maintainer is going to make xload a dependency of FVWM.  The point of
> >the default config here isn't to do that, but to provide some sane defaults
> >where possible.
>
> The default configuration assumes the presence of xload.
>

The default configuration does not assume the presence of xload. In
general the default config assumes a very minimal set of tools,
because fvwm is just a window manager, not a full desktop. It does not
assume what sort of apps you want to use. The default config is merely
meant to be a starting point and to show some of the capabilities of
fvwm. It is not meant to service all users nor turn fvwm into a
desktop that links fvwm (a window manager) with lots of external apps.

If you want more info about the RightPanel (or Panels in general) the
wiki can help, along with other docs. Maybe start here and then read
up on how to include xload in your panel.

https://fvwmforums.org/wiki/Panels/RightPanel/

> I will let the FreeBSD port maintainer decide if that means that xload should
> be listed as a prerequsite for fvwm.  I have an opinion on this, and you have
> one, and he may have a third.
>

The FreeBSD maintainer can decide to provide their own default config
if they wish, but this is not a discussion for the fvwm mailing list.
I see no reason the default config should support xload.

> >> In any case, I would like to suggest to the fvwm maintainers that they do 
> >> as
> >> I have done and substitute out the xload invocation in the default theme 
> >> and
> >> replace it, as I have done, with a digital xclock display of the current 
> >> date.
> >
> >No.  I think what you've done is to prove the point -- that being that you're
> >expected to use this config as a starting to point to make your own
> >modifications, which you're doing.
>
> As much as I admire all of the ornate and impressive complexity of fvwm, I
> never actually -wanted- to do any of this.  It has taken me a lot of hours,
> and none of what I have learned is applicable or useful to anything else
> that I am doing, or that I am at all likely to do in the future.
>
> No offense intended, but if there had been some other window manager that
> would give me multiple virutal desktops... a feature that I can no longer
> live without... and which didn't require a massive amount of unlearning
> and then re-learning (i.e. of basic usage conventions) then I would have
> used that instead.
>

Many window managers (and even desktops like gnome) provide support
for multiple virtual desktops. You may want to search around and find
one that more suits what you want. Fvwm will require one taking time
to learn how to configure it using the config file, because there are
just to many options to put into an GUI. Fvwm takes most a good
initial time investment, but once you have your config file, it will
keep working (I haven't had to update my config file in years except
for small tweaks).

There are also some desktops based off of fvwm, either fvwm-crytsal or
fvwm-nightshade. These both assume a bigger set of tools, provide some
gui configs and try to be more a full desktop. You may find they work
more to your liking as a lot more maybe configured for you. These are
not supported by the fvwm mailing list.

> I am not seeking to become an X wizard or a window manager wizard or anything
> else.  I just know enough to barely get by and that's all I have time for
> right now.  I have promises to keep, and many spammers to kill.
>
> >> I would really appreciate it if the maintainers would fix this self-evident
> >> bug.  It is most annoying.  The minimization/iconization process should not
> >> be hiding minimized window icons underneath the boxes created by the 
> >> default
> >> theme.  That's just wrong, and one would hope that there might be some 
> >> simple
> >> way to get the window minimization/iconization process to avoid doing this
> >> annoying and clearly wrong thing.
> >
> >This isn't a bug.
>
> I gather that you would prefer not to elaborate further on that assertion,
> but I will ask you to do so anyway.
>
> How exactly is hiding icons underneath something else... where they can't
> even be clicked on... a Good Thing?  I mean, you know, for a perfectly
> ordinary end-luser.

The default config does not use Icons (it sets Style * !Icon), and
then uses FvwmIconManager to manage them instead. As such no effort
has been put into the default config to configure the IconBox and how
the icons are placed on your desktop. If you want to use Icons, go
configure the IconBox and other Icon settings so they get positions on
your desktop where you want them.

jaimos

Reply via email to