Discussion:
FVWM: Deprecating certain Fvwm* modules
Thomas Adam
2011-10-22 10:23:49 UTC
Permalink
Hello all,

This has been a while coming since 2.6.0 was released. But I said at the
time that since there was no longer ever going to be a split between
stable/unstable, and that there was only ever rolling-stable releases, that
there was now never any right time to make changes which have an impact.

This is one of them.

Currently, FVWM ships with a number of modules. Some of them are used a lot
in peoples' configs (such as FvwmButtons, FvwmEvent, etc.) and others are
not so much used -- and indeed some of them have just bitrot.
Unsurprisingly, that's due to confusion as to the need of the module, and in
some cases the language the module is supporting, because it's no longer the
"coolest" language to use, or has been pushed back because of another module
giving functionality.

So, here's a list of modules I wish to see deprecated, with reasons why:

* FvwmCommand
* FvwmConsole
* FvwmConsoleC.pl

These three are on a list to be removed, but the functionality to replace
them (notably getting FVWM to listen on a $DISPLAY socket, for instance)
just isn't there yet. So whilst I don't plan on deprecating them just yet,
I'm aware I'll need to at some point.

* FvwmCpp

This one has to go -- no one that I've seen in the years I've been using
FVWM actually has a configuration in CPP anymore. If they do, they've not
noticed it's been broken since FVWM 2.3.X, and no one has fixed that.

* FvwmDragWell

The use-case of this doesn't match any application anymore.

* FvwmIconBox

Replaced with IconBox style option, although not quite the same as having an
actual window managing icons (c.f. TWM)

* FvwmSave
* FvwmSaveDesk

These two are broken, and a very very poor choice of trying to be a session
manager. Use a session manager if you can with FVWM.

* FvwmTaskBar

This is a FvwmButtons module swallowing FvwmIconMan. People wanting mail
notification can use xbuffy, xbiff, or mail-notification.

* FvwmWharf

This is FvwmButtons.

* FvwmWinList

This is FvwmIconMan.

Note that I am not interested in someone suddenly jumping out of their front
door shouting: "I'll do it, I'll do it! I'll maintain this module." These
modules listed simply do not do their job to the way FVWM works anymore, and
worse yet, for some of these modules, the applications interacting with them
don't understand their requests. If people really did care that much, the
problems with these modules would have been addressed long ago were they in
use.

How do we deprecate these things? Slowly -- I am not about to commit
anything to remove them. There will be a long time in which one module is
deprecated, with there being a transition in FVWM to handle module
information for deprecated modules.

I will be writing a FvwmDeprecated module stub, and will point the
deprecated modules to it, as they're deprecated. This will do nothing more
than log the fact the module doesn't exist, perhaps using xmessage if it's
installed, etc. Then, over time, as people switch configs, the need for
this will go away. It won't be a permenant arrangement of FVWM, but will
need to be around for some time as people adjust their configs.
Furthermore, as modules are deprecated I will be personally providing
instructions on how to migrate from that module to another, where the
deprecated module has an equivalent functionality. Not all modules
(FvwmSave{,Desk} for instance will not.)

I won't be beginning work on this just yet -- maybe I'll start it over
Christmas.

Any questions, please ask.

-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
Harry portobello
2011-10-22 12:14:32 UTC
Permalink
Hi,
Post by Thomas Adam
Hello all,
This has been a while coming since 2.6.0 was released.  But I said at the
time that since there was no longer ever going to be a split between
stable/unstable, and that there was only ever rolling-stable releases, that
there was now never any right time to make changes which have an impact.
This is one of them.
Is this really the right thing to do? Really? How did you come up with
this list of depreciated modules to start with? What happens if
someone with a config theyve had for ages needs to use a module youve
depreciated? Will you personally have to provide the functions of that
module in some way?

Can you not just leave these modules alone?

Harry
John Latham
2011-10-22 13:04:52 UTC
Permalink
Post by Harry portobello
Is this really the right thing to do? Really? How did you come up with
this list of depreciated modules to start with? What happens if
someone with a config theyve had for ages needs to use a module youve
depreciated? Will you personally have to provide the functions of that
module in some way?
Can you not just leave these modules alone?
Harry
I believe Thomas has anticipated and answered all those questions in his post!
d***@verizon.net
2011-10-24 16:28:59 UTC
Permalink
Post by Harry portobello
Hi,
Post by Thomas Adam
Hello all,
This has been a while coming since 2.6.0 was released.  But I said at the
time that since there was no longer ever going to be a split between
stable/unstable, and that there was only ever rolling-stable releases, that
there was now never any right time to make changes which have an impact.
This is one of them.
Is this really the right thing to do? Really? How did you come up with
this list of depreciated modules to start with? What happens if
someone with a config theyve had for ages needs to use a module youve
depreciated? Will you personally have to provide the functions of that
module in some way?
Can you not just leave these modules alone?
Deprecating junk is a time honored Fvwm tradition.

Reducing the size of the code base helps developers.
As it is, Fvwm has grown so large that I can't keep up with
the complexity.

Anyway, Tom has done the right thing. He made a proposal and
now he's getting feedback.
--
Dan Espen
Harry portobello
2011-10-24 17:54:09 UTC
Permalink
Hullo,
Post by d***@verizon.net
Post by Harry portobello
Hi,
Post by Thomas Adam
Hello all,
This has been a while coming since 2.6.0 was released.  But I said at the
time that since there was no longer ever going to be a split between
stable/unstable, and that there was only ever rolling-stable releases, that
there was now never any right time to make changes which have an impact.
This is one of them.
Is this really the right thing to do? Really? How did you come up with
this list of depreciated modules to start with? What happens if
someone with a config theyve had for ages needs to use a module youve
depreciated? Will you personally have to provide the functions of that
module in some way?
Can you not just leave these modules alone?
Deprecating junk is a time honored Fvwm tradition.
Reducing the size of the code base helps developers.
As it is, Fvwm has grown so large that I can't keep up with
the complexity.
Anyway, Tom has done the right thing.  He made a proposal and
now he's getting feedback.
Maybe. But time honored traditions are grating - when functionality
already exists and is removed for no good reason. I like FvwmTaskBar
but won't get to use it again - instead I have to use two modules I
don't know anything about. There's no thought gone in to this and
will force users to learn things they didn't need to before. I am also
amazed that mail checking is now left up to the user when it's built
in to FvwmTaskBar already!

Can these modules not be archived and marked as unmaintained which
would still allow users to use them if they chose?

Please! More thought needed =)

Harry
Jaimos Skriletz
2011-10-24 18:49:20 UTC
Permalink
Post by Harry portobello
Hullo,
Post by d***@verizon.net
Post by Harry portobello
Hi,
Post by Thomas Adam
Hello all,
This has been a while coming since 2.6.0 was released.  But I said at the
time that since there was no longer ever going to be a split between
stable/unstable, and that there was only ever rolling-stable releases, that
there was now never any right time to make changes which have an impact.
This is one of them.
Is this really the right thing to do? Really? How did you come up with
this list of depreciated modules to start with? What happens if
someone with a config theyve had for ages needs to use a module youve
depreciated? Will you personally have to provide the functions of that
module in some way?
Can you not just leave these modules alone?
Deprecating junk is a time honored Fvwm tradition.
Reducing the size of the code base helps developers.
As it is, Fvwm has grown so large that I can't keep up with
the complexity.
Anyway, Tom has done the right thing.  He made a proposal and
now he's getting feedback.
Maybe. But time honored traditions are grating - when functionality
already exists and is removed for no good reason. I like FvwmTaskBar
but won't get to use it again - instead I have to use two modules I
don't know anything about. There's no thought gone in to this and
will force users to learn things they didn't need to before. I am also
amazed that mail checking is now left up to the user when it's built
in to FvwmTaskBar already!
Can these modules not be archived and marked as unmaintained which
would still allow users to use them if they chose?
Please! More thought needed =)
Functionality is not being removed. With FvwmButons + FvwmIconMan you have way more functionality than FvwmTaskBar. Since FvwmButtons + FvwmIconMan can do everything and more than FvwmTaskBar, there is no reason to keep and matain FvwmTaskBar.

FVWM is a small project and mataining multiple tools that do the same thing just takes up the developers time they could spend adding new functionality. The goal is not to remove any functionality, but provide it though a smaller set of well tested modules.

The point of Depericating is to give the users time to change their configs and learn the more accepted tool. Its not like this module is just going to disapear in the next release.

Last this is an opensource project, You can grab the source code and matain your own unmatained, unoffical FvwmTaskBar module as you suggested. Though taking the time to learn the other options you may find that not only can you achive your current config, have more flexablity.

jaimos
Thomas Adam
2011-10-25 08:11:26 UTC
Permalink
Post by Harry portobello
don't know anything about. There's no thought gone in to this and
will force users to learn things they didn't need to before. I am also
amazed that mail checking is now left up to the user when it's built
in to FvwmTaskBar already!
So your worry isn't so much that you'll have something which looks like
FvwmTaskBar, but that you won't be able to check your mail?

That's just tough, I'm afraid. That mail checker is all but useless with
today's email usage; it doesn't do IMAP for example, and even at the time
when it was written, tools which provide its equivalent functionality, such
as xbiff, xbuffy, etc., very much existed. They can always be used
instead.

But I'd argue that you'd want to use mail-notification or any of the other
mail monitoring applications instead.

In terms of FvwmTaskBar itself, that'll be nothing more than a generated set
of module lines which wrap around FvwmButtons; FvwmTaskBar itself will be
nothing more than a set of module-alias lines for FvwmButtons, where one of
its jobs is to swallow FvwmIconMan.

Now, if you wanted to put your mail checker where your postoffice is, get me
an alternative which is meaningful in terms of its replacement, and I'd
consider making such a component dynamically available in its config, should
it be present on the system. I'll be giving myself extra points for using
FvwmForm to wrap up the options for control graphically as well.

If you can't do that, then shut up and stop irritating me. You're not
contributing anything to this conversation except a lot of stale hot air.

-- Thomas Adam
Harry portobello
2011-10-26 14:27:46 UTC
Permalink
hullo,
Post by Thomas Adam
don't know anything about.  There's no thought gone in to this and
will force users to learn things they didn't need to before. I am also
amazed that mail checking is now left up to the user when it's built
in to FvwmTaskBar already!
So your worry isn't so much that you'll have something which looks like
FvwmTaskBar, but that you won't be able to check your mail?
not only mail but the hole idea of no longer having a tasbar with
these small features annoys when users like me are used to that.
Post by Thomas Adam
That's just tough, I'm afraid.  That mail checker is all but useless with
today's email usage; it doesn't do IMAP for example, and even at the time
when it was written, tools which provide its equivalent functionality, such
as xbiff, xbuffy, etc., very much existed.  They can always be used
instead.
But can they? Have you tried this? I've not seen anything to suggest
they can and how do you do this in a way which won't cripple the
taskbar without these things present on the machine. Plus this is not
an integrated taskbar anymore with all the functionality neatly kept
insider it - its relying on external tools.
Post by Thomas Adam
Now, if you wanted to put your mail checker where your postoffice is, get me
an alternative which is meaningful in terms of its replacement, and I'd
consider making such a component dynamically available in its config, should
it be present on the system.  I'll be giving myself extra points for using
FvwmForm to wrap up the options for control graphically as well.
Why not use the one from fvwmtaskbar? Or just keep fvwmtaskbar?
Post by Thomas Adam
If you can't do that, then shut up and stop irritating me.  You're not
contributing anything to this conversation except a lot of stale hot air.
Please tell me where I've offended you because I find this sentence very rude.

Thanks,

Harry
Bert Geens
2011-10-26 14:45:43 UTC
Permalink
Post by Harry portobello
hullo,
Post by Thomas Adam
don't know anything about.  There's no thought gone in to this and
will force users to learn things they didn't need to before. I am also
amazed that mail checking is now left up to the user when it's built
in to FvwmTaskBar already!
So your worry isn't so much that you'll have something which looks like
FvwmTaskBar, but that you won't be able to check your mail?
not only mail but the hole idea of no longer having a tasbar with
these small features annoys when users like me are used to that.
I'm sure someone(tm) can come up with an FvwmButtons config that looks
and acts like FvwmTaskBar.
Post by Harry portobello
Post by Thomas Adam
That's just tough, I'm afraid.  That mail checker is all but useless with
today's email usage; it doesn't do IMAP for example, and even at the time
when it was written, tools which provide its equivalent functionality, such
as xbiff, xbuffy, etc., very much existed.  They can always be used
instead.
But can they? Have you tried this? I've not seen anything to suggest
they can and how do you do this in a way which won't cripple the
taskbar without these things present on the machine. Plus this is not
an integrated taskbar anymore with all the functionality neatly kept
insider it - its relying on external tools.
I've not seen anything indicating they can't either. Also Fvwm's job is
not to check mail, one could argue that the feature should never have
made it into FvwmTaskBar to start with.
Post by Harry portobello
Post by Thomas Adam
Now, if you wanted to put your mail checker where your postoffice is, get me
an alternative which is meaningful in terms of its replacement, and I'd
consider making such a component dynamically available in its config, should
it be present on the system.  I'll be giving myself extra points for using
FvwmForm to wrap up the options for control graphically as well.
Why not use the one from fvwmtaskbar? Or just keep fvwmtaskbar?
Because FvwmTaskbar increases the maintenance burden for no added
benefit. It doesn't do anything (except checking mail I guess) that a
combination of other Fvwm modules can't do equally well, if not better.

Regards,

Bert
Harry portobello
2011-10-27 08:10:21 UTC
Permalink
Post by Bert Geens
I'm sure someone(tm) can come up with an FvwmButtons config that looks
and acts like FvwmTaskBar.
i'd want to review it so it is OK - how do i do that? so far
everything for fvwm is put in cvs without review which i think is bad.

Harry
Thomas Adam
2011-10-27 08:47:30 UTC
Permalink
Post by Harry portobello
Post by Bert Geens
I'm sure someone(tm) can come up with an FvwmButtons config that looks
and acts like FvwmTaskBar.
i'd want to review it so it is OK - how do i do that? so far
I'll send it to the list.
Post by Harry portobello
everything for fvwm is put in cvs without review which i think is bad.
You're mistaken.

Whilst there is no formal process for this, the way FVWM operates is
generally no different to other projects. So let me explain...

Let's say you decided to send a patch or a series of patches to fix/augment
some functionality in FVWM (heh -- that's tickled me for some reason ;P)
which you wanted for inclusion in some future FVWM release, you'd have to
send them to fvwm-workers@ so that the people there who can commit patches
can at least see what they do.

That's the review stage. And certain people have done just that. They just
send the patches to myself rather than the list, although there's zero
difference between the two right now.

Unfortunately though, there are no other active developers who have the time
for such reviews -- and I am one of them. It's a lot of work just keeping
FVWM ticking over, and if you expected me to do that, *and* wait for review
of patches, then this project would have died out about two years ago.

As it happens (and is the case for anyone at FVWM with a commit-bit) they're
generally trusted enough to use their own judgement about what they commit
to CVS and when; the idea being that commits happen once the patches have
been tested, etc. And that's exactly what *I* do. The converse holds true
as well. There's been quite a few instances over my work on FVWM where
I've asked for review/testing -- just go and search the mailing-list
archives (both fvwm@ and fvwm-workers@) for things like "fvwm-convert-2.6"
and "{Icon,Title}Format" if you don't believe me.

Now, that's not to say that my own commits are not bug-free. But that's a
different matter, although I can only give you the same guarantee as I
stated above, that I announce certain features ahead of time such that those
who care get a chance to run it. I did that with the TitleFormat patch
series, for instance. No one reported anything to me (regardless of whether
that patch was tested) and I submitted it to CVS when I considered it
working fine.

When we move to Git though [1] this all becomes moot because features will
happen on topic branches which will allow -- no, wait -- force, review of
that topic before it's included in something we ship as a next release.
With CVS that's more difficult due to the workflow you're forced to follow.

So if you think FVWM is without review, you're wrong. It's just more likely
that no one is actively looking at review requests, cares, or has the time
to do any lengthly review. Wait for Git, then it will become more visible.

And before you ask -- yes, module deprecation work aside, I was always going
to be sending out review requests for functional testing, regression
testing, etc. FvwmTaskBar falls in to these categories. It's then up to
you to review it, of course.

Does that answer your question?

-- Thomas Adam

[1] Any day now... Ahem.
Harry portobello
2011-10-27 12:59:21 UTC
Permalink
Hi,
Post by Thomas Adam
Post by Harry portobello
Post by Bert Geens
I'm sure someone(tm) can come up with an FvwmButtons config that looks
and acts like FvwmTaskBar.
i'd want to review it so it is OK - how do i do that? so far
I'll send it to the list.
Thank you.
Post by Thomas Adam
Post by Harry portobello
everything for fvwm is put in cvs without review which i think is bad.
You're mistaken.
Whilst there is no formal process for this, the way FVWM operates is
generally no different to other projects.  So let me explain...
Let's say you decided to send a patch or a series of patches to fix/augment
some functionality in FVWM (heh -- that's tickled me for some reason ;P)
which you wanted for inclusion in some future FVWM release, you'd have to
can at least see what they do.
That's the review stage.  And certain people have done just that.  They just
send the patches to myself rather than the list, although there's zero
difference between the two right now.
This is a odd and makes me nervous that an important program which
fvwm is (is it FVWM or Fvwm or fvwm ????) might not be around because
theres no one left to work on it. This is why i feel review is even
more important - if noting else it will allow others to take part and
have their say.

Has no one audited fvwm yet? Is that something I can start? Do I start
with your changes most recent? Or is the code youve also not touched
on needed for review as well? Tough one to call.
Post by Thomas Adam
Unfortunately though, there are no other active developers who have the time
for such reviews -- and I am one of them.  It's a lot of work just keeping
FVWM ticking over, and if you expected me to do that, *and* wait for review
of patches, then this project would have died out about two years ago.
I understand and your work is probably appreciated. I am interested in
making sure your changes do not damage how fvwm functions at the
moment - that is very important because users rely on this
functionality. So you can understand why I get nervous when I read
these changes, cant you?
Post by Thomas Adam
As it happens (and is the case for anyone at FVWM with a commit-bit) they're
generally trusted enough to use their own judgement about what they commit
to CVS and when; the idea being that commits happen once the patches have
been tested, etc.  And that's exactly what *I* do.  The converse holds true
as well.   There's been quite a few instances over my work on FVWM where
I've asked for review/testing -- just go and search the mailing-list
and "{Icon,Title}Format" if you don't believe me.
i believe you - but this should be the rule and not the exception.
Post by Thomas Adam
Does that answer your question?
Almost. Thanks.

Harry
Thomas Adam
2011-10-27 14:25:04 UTC
Permalink
Post by Harry portobello
This is a odd and makes me nervous that an important program which
fvwm is (is it FVWM or Fvwm or fvwm ????) might not be around because
theres no one left to work on it. This is why i feel review is even
more important - if noting else it will allow others to take part and
have their say.
But that's currently achievable as-is. It requires someone with enough time
and gumption to get on and do it -- whatever "it" in this context might be,
or what the person interested in reviewing something is able to pass
judgement on or have an opinion about.

I do a lot of code-review both at work and on other open source projects,
for what it's worth. I even use Gerrit and other code-review systems to
facilitate this. And it's a very challenging thing to do. FVWM [1] is not
an easy program to necessarily understand without a decent grasp of XLib.
But thankfully a lot of those details have been ironed out long ago.
Post by Harry portobello
Has no one audited fvwm yet? Is that something I can start? Do I start
with your changes most recent? Or is the code youve also not touched
on needed for review as well? Tough one to call.
The way you've written this suggests you don't know what auditing is at all,
so I would suggest you wouldn't be the best person for this. (Hint:
auditing is nothing to do with most recent changes, it's about looking at
systems as a whole and identifying problems, etc.) However, this is not
stopping anyone from doing this if they want to. FVWM is open source, they
can do what they want with it. Of course, blindly running FVWM under
something like Valgrind and fixing the fall-out from that is _NOT_ auditing
-- so please do not get any ideas you can automate this easily. In my
experience, Valgrind is useful only as a tool to hint at; it has far too
many false-positives for certain legitimate constructs.
Post by Harry portobello
Post by Thomas Adam
Unfortunately though, there are no other active developers who have the time
for such reviews -- and I am one of them.  It's a lot of work just keeping
FVWM ticking over, and if you expected me to do that, *and* wait for review
of patches, then this project would have died out about two years ago.
I understand and your work is probably appreciated. I am interested in
making sure your changes do not damage how fvwm functions at the
moment - that is very important because users rely on this
functionality. So you can understand why I get nervous when I read
these changes, cant you?
This is functional testing, which I hope any user interested in this is
already doing.

I'd really like to go back to something useful and constructive now. Hope
that's OK.

-- Thomas Adam

[1] Officially, I do not care how FVWM is written, albeit as "FVWM", "Fvwm",
or "fvwm". We tried to standardise on this a few years ago, and whilst it
was bulldozed through to use "fvwm" in the documentation (with "Fvwm" being
acceptable for capitalisation where appropriate), I do not care how it's
written or referred to outside of that. But I am not saying "fvwm" is the
official way to write it, just because that's how it is in the
documentation. If I had my way, it would have been "FVWM", so the only
thing I can do now is be consistent with how it's already spelled. :P
d***@verizon.net
2011-10-27 13:23:13 UTC
Permalink
Post by Harry portobello
Post by Bert Geens
I'm sure someone(tm) can come up with an FvwmButtons config that looks
and acts like FvwmTaskBar.
i'd want to review it so it is OK - how do i do that? so far
Learn how to use CVS diff and review away. It's not hard.
Post by Harry portobello
everything for fvwm is put in cvs without review which i think is bad.
This is absurd.

First, anything put into CVS can be easily removed.
Second, Tom got commit privileges because he's shown he can be trusted.
Third, you have no idea how many of us review commits.

Please stop trying to poke holes in a process you haven't taken the time
to understand.

Tom's list of modules to be deprecated is not new.
We've wanted to remove FvwmTaskBar and replace it with a combination of
other modules for a long time now. Whether that will ever happen, I
have my doubts, but it's a good thing to try to make happen.

The mail notifier functionality in FvwmTaskBar can be accomplished using
FvwmButtons ability to swallow a "biff" type notifier.
--
Dan Espen
Harry portobello
2011-10-27 15:42:07 UTC
Permalink
hullo,
Post by Harry portobello
Post by Bert Geens
I'm sure someone(tm) can come up with an FvwmButtons config that looks
and acts like FvwmTaskBar.
i'd want to review it so it is OK - how do i do that? so far
Learn how to use CVS diff and review away.  It's not hard.
But it is hard - how to do it between revisions? Or know which branch
to use. Is this documented in fvwms case?
Post by Harry portobello
everything for fvwm is put in cvs without review which i think is bad.
This is absurd.
First, anything put into CVS can be easily removed.
Yes - but im saying it should never be put in to cvs to start with -
and you wouldnt need to do this if things were looked over first.
Second, Tom got commit privileges because he's shown he can be trusted.
Third, you have no idea how many of us review commits.
So how do you make sure theres consistency with features behaving as
they should and do to change? Weve already seen how bad this can be
with....... i think its titleformat not showing any number between
brackets if theres only one of them on the screen. to me this is a bad
thing - and should have been caught when it was tested. and then were
told that its a feature?!
Please stop trying to poke holes in a process you haven't taken the time
to understand.
i am trying to understand by asking these questions.
Tom's list of modules to be deprecated is not new.
is it tom or thomas? or thom?
We've wanted to remove FvwmTaskBar and replace it with a combination of
other modules for a long time now.  Whether that will ever happen, I
have my doubts, but it's a good thing to try to make happen.
but do it very carefuly, and with fvwm operating the way it does right
now, this is going to make jobs of reviewerrs harder - twice as hard -
as if things changed now so that no commits hapens direct to fvwm
without review first.

Harry
d***@verizon.net
2011-10-27 15:53:55 UTC
Permalink
Post by Harry portobello
hullo,
Post by Harry portobello
Post by Bert Geens
I'm sure someone(tm) can come up with an FvwmButtons config that looks
and acts like FvwmTaskBar.
i'd want to review it so it is OK - how do i do that? so far
Learn how to use CVS diff and review away.  It's not hard.
But it is hard - how to do it between revisions? Or know which branch
to use. Is this documented in fvwms case?
No it is _not_ hard.
Apparently you don't know how CVS works.

Check out the Developer section of the Fvwm (fvwm) web site.
All the basics for setting up and using CVS are there.
Anyone can do read only access.

There is only one branch active and you can do diffs by date so
you can easily see all changes from one day ago or one week ago.
Post by Harry portobello
Post by Harry portobello
everything for fvwm is put in cvs without review which i think is bad.
This is absurd.
First, anything put into CVS can be easily removed.
Yes - but im saying it should never be put in to cvs to start with -
and you wouldnt need to do this if things were looked over first.
Sorry, but you are just wrong.
It goes into CVS, we all see the changes, anyone can back out a change.
Submitting a change to the list as a diff is just extra work.
Post by Harry portobello
Second, Tom got commit privileges because he's shown he can be trusted.
Third, you have no idea how many of us review commits.
So how do you make sure theres consistency with features behaving as
they should and do to change? Weve already seen how bad this can be
with....... i think its titleformat not showing any number between
brackets if theres only one of them on the screen. to me this is a bad
thing - and should have been caught when it was tested. and then were
told that its a feature?!
You are making up imaginary problems.
Post by Harry portobello
Please stop trying to poke holes in a process you haven't taken the time
to understand.
i am trying to understand by asking these questions.
Good.
Post by Harry portobello
Tom's list of modules to be deprecated is not new.
is it tom or thomas? or thom?
Beats me. All I know for sure is I'm Dan.
Post by Harry portobello
We've wanted to remove FvwmTaskBar and replace it with a combination of
other modules for a long time now.  Whether that will ever happen, I
have my doubts, but it's a good thing to try to make happen.
but do it very carefuly, and with fvwm operating the way it does right
now, this is going to make jobs of reviewerrs harder - twice as hard -
as if things changed now so that no commits hapens direct to fvwm
without review first.
Nope. Wrong.
--
Dan Espen
Harry portobello
2011-10-27 20:31:55 UTC
Permalink
hi dan,
Post by d***@verizon.net
Post by Harry portobello
hullo,
Post by Harry portobello
Post by Bert Geens
I'm sure someone(tm) can come up with an FvwmButtons config that looks
and acts like FvwmTaskBar.
i'd want to review it so it is OK - how do i do that? so far
Learn how to use CVS diff and review away.  It's not hard.
But it is hard - how to do it between revisions? Or know which branch
to use. Is this documented in fvwms case?
No it is _not_ hard.
Apparently you don't know how CVS works.
you are right - i have not used cvs in the past. is there a good guide
for a good way to use it?
Post by d***@verizon.net
Check out the Developer section of the Fvwm (fvwm) web site.
All the basics for setting up and using CVS are there.
Anyone can do read only access.
i will try this but the Developer section does not list how to use cvs
in an effective way - and the docs are difficult to piece to gether
Post by d***@verizon.net
There is only one branch active and you can do diffs by date so
you can easily see all changes from one day ago or one week ago.
which branch?
Post by d***@verizon.net
Post by Harry portobello
Post by Harry portobello
everything for fvwm is put in cvs without review which i think is bad.
This is absurd.
First, anything put into CVS can be easily removed.
Yes - but im saying it should never be put in to cvs to start with  -
and you wouldnt need to do this if things were looked over first.
Sorry, but you are just wrong.
It goes into CVS, we all see the changes, anyone can back out a change.
Submitting a change to the list as a diff is just extra work.
so lets say i want to see the change in cvs from last week - how do i do that?
Post by d***@verizon.net
Post by Harry portobello
Second, Tom got commit privileges because he's shown he can be trusted.
Third, you have no idea how many of us review commits.
So how do you make sure theres consistency with features behaving as
they should and do to change? Weve already seen how bad this can be
with....... i think its titleformat not showing any number between
brackets if theres only one of them on the screen. to me this is a bad
thing - and should have been caught when it was tested. and then were
told that its a feature?!
You are making up imaginary problems.
no - i remember this -
http://www.mail-archive.com/***@fvwm.org/msg01900.html - you can not
say this is imagined. i'd like the old behavior to return - and if
this patch had review it would have been spotted.
Post by d***@verizon.net
Post by Harry portobello
but do it very carefuly, and with fvwm operating the way it does right
now, this is going to make jobs of reviewerrs harder - twice as hard -
as if things changed now so that no commits hapens direct to fvwm
without review first.
Nope.  Wrong.
how is this wrong?

Harry
d***@verizon.net
2011-10-27 21:01:21 UTC
Permalink
Post by Harry portobello
hi dan,
Post by d***@verizon.net
Post by Harry portobello
hullo,
Post by Harry portobello
Post by Bert Geens
I'm sure someone(tm) can come up with an FvwmButtons config that looks
and acts like FvwmTaskBar.
i'd want to review it so it is OK - how do i do that? so far
Learn how to use CVS diff and review away.  It's not hard.
But it is hard - how to do it between revisions? Or know which branch
to use. Is this documented in fvwms case?
No it is _not_ hard.
Apparently you don't know how CVS works.
you are right - i have not used cvs in the past. is there a good guide
for a good way to use it?
Plenty of online documentation for CVS.
Post by Harry portobello
Post by d***@verizon.net
Check out the Developer section of the Fvwm (fvwm) web site.
All the basics for setting up and using CVS are there.
Anyone can do read only access.
i will try this but the Developer section does not list how to use cvs
in an effective way - and the docs are difficult to piece to gether
Somehow we all figured out how to use CVS with the documentation
online. Either at the Fvwm site or other online CVS docs.
Post by Harry portobello
Post by d***@verizon.net
There is only one branch active and you can do diffs by date so
you can easily see all changes from one day ago or one week ago.
which branch?
Don't worry about branches, the only active branch is the current main
branch.
Post by Harry portobello
Post by d***@verizon.net
Post by Harry portobello
Post by Harry portobello
everything for fvwm is put in cvs without review which i think is bad.
This is absurd.
First, anything put into CVS can be easily removed.
Yes - but im saying it should never be put in to cvs to start with  -
and you wouldnt need to do this if things were looked over first.
Sorry, but you are just wrong.
It goes into CVS, we all see the changes, anyone can back out a change.
Submitting a change to the list as a diff is just extra work.
so lets say i want to see the change in cvs from last week - how do i do that?
After you've followed the instructions at the fvwm web site for checking
out a copy of the source, use this command to get diffs for the last week.

cvs diff -D 10/20/2011
Post by Harry portobello
Post by d***@verizon.net
Post by Harry portobello
Second, Tom got commit privileges because he's shown he can be trusted.
Third, you have no idea how many of us review commits.
So how do you make sure theres consistency with features behaving as
they should and do to change? Weve already seen how bad this can be
with....... i think its titleformat not showing any number between
brackets if theres only one of them on the screen. to me this is a bad
thing - and should have been caught when it was tested. and then were
told that its a feature?!
You are making up imaginary problems.
no - i remember this -
say this is imagined. i'd like the old behavior to return - and if
this patch had review it would have been spotted.
Not interested in looking. Oh, okay the %t. Still not interested.
Post by Harry portobello
Post by d***@verizon.net
Post by Harry portobello
but do it very carefuly, and with fvwm operating the way it does right
now, this is going to make jobs of reviewerrs harder - twice as hard -
as if things changed now so that no commits hapens direct to fvwm
without review first.
Nope.  Wrong.
how is this wrong?
Just showed you how to pull a diff.

I'm now in Tom's camp. Not interested in beating a dead horse.
--
Dan Espen
John Latham
2011-10-28 17:37:51 UTC
Permalink
Post by Harry portobello
So how do you make sure theres consistency with features behaving as
they should
By fixing bugs? E.g. Thomas' change to titleformat.
Post by Harry portobello
Weve already seen how bad this can be
with....... i think its titleformat not showing any number between
brackets if theres only one of them on the screen. to me this is a bad
thing
Hang on -- were you not arguing the exact opposite when you first chipped in
on that?
Harry portobello
2011-10-28 18:06:53 UTC
Permalink
Post by John Latham
Post by Harry portobello
So how do you make sure theres consistency with features behaving as
they should
By fixing bugs? E.g. Thomas' change to titleformat.
But this is not a bug fix
Post by John Latham
Post by Harry portobello
Weve already seen how bad this can be
with....... i think its titleformat not showing any number between
brackets if theres only one of them on the screen. to me this is a bad
thing
Hang on -- were you not arguing the exact opposite when you first chipped in
on that?
No, I want the old behavior back of no count for just 1 window

HARRY

Michelle Konzack
2011-10-27 17:19:56 UTC
Permalink
Hello Thomas Adam,
Post by Thomas Adam
That's just tough, I'm afraid. That mail checker is all but useless with
today's email usage; it doesn't do IMAP for example, and even at the time
when it was written, tools which provide its equivalent functionality, such
as xbiff, xbuffy, etc., very much existed. They can always be used
instead.
Right, this is something, which should be removed.

Some years ago I tried to make a box, where MiniIcons show up, if I
start HIDEN applications (can be defined from Name of Resource/Class),
but then had no time.

I like to see something Windows use in its taskbar...
Post by Thomas Adam
In terms of FvwmTaskBar itself, that'll be nothing more than a generated set
of module lines which wrap around FvwmButtons; FvwmTaskBar itself will be
nothing more than a set of module-alias lines for FvwmButtons, where one of
its jobs is to swallow FvwmIconMan.
Adam, Please can ypu provide a FvwmButtonPanel which allow UN/HIDING
using on Mouse-Over. I was never able to configure this... I have to
click every time on the FvwmButtonsPanel to let the FvwmButtons show up
and hide.

Note: I have FvwmButtonsPanel on the Left, Top and Right...

Thanks, Greetings and nice Day/Evening
Michelle Konzack
--
##################### Debian GNU/Linux Consultant ######################
Development of Intranet and Embedded Systems with Debian GNU/Linux
Internet Service Provider, Cloud Computing
<http://www.itsystems.tamay-dogan.net/>

***@tdnet Jabber ***@jabber.ccc.de
Owner Michelle Konzack

Gewerbe Strasse 3 Tel office: +49-176-86004575
77694 Kehl Tel mobil: +49-177-9351947
Germany Tel mobil: +33-6-61925193 (France)

USt-ID: DE 278 049 239

Linux-User #280138 with the Linux Counter, http://counter.li.org/
Thomas Adam
2011-10-27 20:17:53 UTC
Permalink
Post by Michelle Konzack
Hello Thomas Adam,
Post by Thomas Adam
That's just tough, I'm afraid. That mail checker is all but useless with
today's email usage; it doesn't do IMAP for example, and even at the time
when it was written, tools which provide its equivalent functionality, such
as xbiff, xbuffy, etc., very much existed. They can always be used
instead.
Right, this is something, which should be removed.
Some years ago I tried to make a box, where MiniIcons show up, if I
start HIDEN applications (can be defined from Name of Resource/Class),
but then had no time.
And just how do you define "HIDEN"? (c.f. "HIDDEN" - and even then, there's
no need to shout or otherwise capitalise such words). You can of course
achieve such things easily using a State definition or better yet just
setting WindowListSkip on such windows, and then asking the various modules
to honour that.
Post by Michelle Konzack
I like to see something Windows use in its taskbar...
You'll need to elaborate on this, since I don't know what this means.
Post by Michelle Konzack
Post by Thomas Adam
In terms of FvwmTaskBar itself, that'll be nothing more than a generated set
of module lines which wrap around FvwmButtons; FvwmTaskBar itself will be
nothing more than a set of module-alias lines for FvwmButtons, where one of
its jobs is to swallow FvwmIconMan.
Adam, Please can ypu provide a FvwmButtonPanel which allow UN/HIDING
My forename is Thomas, incidentally. Adam is my surname, and whilst in
certain cultures the act of using one's surname is considered polite, to me
it is not. Since this has also come up recently, I do _not_ like being
called Tom, and prefer Thomas in all instances, but will tolerate Tom over
being called Adam any day.
Post by Michelle Konzack
using on Mouse-Over. I was never able to configure this... I have to
click every time on the FvwmButtonsPanel to let the FvwmButtons show up
and hide.
Then you're doing this wrong and the answer to this is already in the FAQ,
FWIW.

When replying to this, or your other mail (to which I've also replied) --
pick the thread which best describes your points, since the questions you've
raised in this email are already answered by a different mail to you which
is most annoying.

-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
r***@cloudcabin.org
2011-10-25 09:07:18 UTC
Permalink
Post by Harry portobello
There's no thought gone in to this and
will force users to learn things they didn't need to before. I am also
amazed that mail checking is now left up to the user when it's built
in to FvwmTaskBar already!
fvwm and "don't need to learn" can't be used in one sentence. :)
Terry Poulin
2011-10-22 14:53:39 UTC
Permalink
This makes me happy that the only modules I use is FvwmCommand, which is
just for quick config tweak-testing without having to reach for the rat.

--
TerryP / Spidey01
Just Another Computer Geek.
Post by Thomas Adam
Hello all,
This has been a while coming since 2.6.0 was released. But I said at the
time that since there was no longer ever going to be a split between
stable/unstable, and that there was only ever rolling-stable releases, that
there was now never any right time to make changes which have an impact.
This is one of them.
Currently, FVWM ships with a number of modules. Some of them are used a lot
in peoples' configs (such as FvwmButtons, FvwmEvent, etc.) and others are
not so much used -- and indeed some of them have just bitrot.
Unsurprisingly, that's due to confusion as to the need of the module, and in
some cases the language the module is supporting, because it's no longer the
"coolest" language to use, or has been pushed back because of another module
giving functionality.
* FvwmCommand
* FvwmConsole
* FvwmConsoleC.pl
These three are on a list to be removed, but the functionality to replace
them (notably getting FVWM to listen on a $DISPLAY socket, for instance)
just isn't there yet. So whilst I don't plan on deprecating them just yet,
I'm aware I'll need to at some point.
* FvwmCpp
This one has to go -- no one that I've seen in the years I've been using
FVWM actually has a configuration in CPP anymore. If they do, they've not
noticed it's been broken since FVWM 2.3.X, and no one has fixed that.
* FvwmDragWell
The use-case of this doesn't match any application anymore.
* FvwmIconBox
Replaced with IconBox style option, although not quite the same as having an
actual window managing icons (c.f. TWM)
* FvwmSave
* FvwmSaveDesk
These two are broken, and a very very poor choice of trying to be a session
manager. Use a session manager if you can with FVWM.
* FvwmTaskBar
This is a FvwmButtons module swallowing FvwmIconMan. People wanting mail
notification can use xbuffy, xbiff, or mail-notification.
* FvwmWharf
This is FvwmButtons.
* FvwmWinList
This is FvwmIconMan.
Note that I am not interested in someone suddenly jumping out of their front
door shouting: "I'll do it, I'll do it! I'll maintain this module."
These
modules listed simply do not do their job to the way FVWM works anymore, and
worse yet, for some of these modules, the applications interacting with them
don't understand their requests. If people really did care that much, the
problems with these modules would have been addressed long ago were they in
use.
How do we deprecate these things? Slowly -- I am not about to commit
anything to remove them. There will be a long time in which one module is
deprecated, with there being a transition in FVWM to handle module
information for deprecated modules.
I will be writing a FvwmDeprecated module stub, and will point the
deprecated modules to it, as they're deprecated. This will do nothing more
than log the fact the module doesn't exist, perhaps using xmessage if it's
installed, etc. Then, over time, as people switch configs, the need for
this will go away. It won't be a permenant arrangement of FVWM, but will
need to be around for some time as people adjust their configs.
Furthermore, as modules are deprecated I will be personally providing
instructions on how to migrate from that module to another, where the
deprecated module has an equivalent functionality. Not all modules
(FvwmSave{,Desk} for instance will not.)
I won't be beginning work on this just yet -- maybe I'll start it over
Christmas.
Any questions, please ask.
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
d***@verizon.net
2011-10-22 15:01:43 UTC
Permalink
Post by Thomas Adam
* FvwmCpp
This one has to go -- no one that I've seen in the years I've been using
FVWM actually has a configuration in CPP anymore. If they do, they've not
noticed it's been broken since FVWM 2.3.X, and no one has fixed that.
I've been using FvwmCPP for quite a while now.
Maybe there is a better way I'm not aware of.

I have a series of different Fvwm Themes.
I read them like this:

Module FvwmCpp -I$FVWM_USERDIR .DecorCurrent

The pre-processor statements in the decors are usually testing
color depth and sometimes just short cutting:

#define BACK 21/B9/FD
#define FORE 22/59/E9
DestroyDecor recreate DecorVec
AddToDecor DecorVec
#if PLANES < 9
+ TitleStyle Centered ActiveUp (Solid cornflowerblue -- Raised) \\
Inactive (Solid Navy -- Flat) \\
ActiveDown (Solid dimgrey -- Sunk)
#else
/* edge mid-point center */
+ TitleStyle Centered ActiveUp (\\
SGradient 128 2 rgb:BACK 20 rgb:33/33/aa 70 rgb:FORE)\\
Inactive (\\
SGradient 128 2 rgb:BACK 50 rgb:44/44/aa 50 rgb:33/33/77)\\
ActiveDown (\\
SGradient 128 2 rgb:00/77/aa 30 rgb:44/88/aa 70 rgb:88/88/aa)
#endif


Anyway, if it's broken, I'm not aware of it.
--
Dan Espen
Thomas Adam
2011-10-23 10:36:14 UTC
Permalink
Post by d***@verizon.net
Post by Thomas Adam
* FvwmCpp
This one has to go -- no one that I've seen in the years I've been using
FVWM actually has a configuration in CPP anymore. If they do, they've not
noticed it's been broken since FVWM 2.3.X, and no one has fixed that.
I've been using FvwmCPP for quite a while now.
Maybe there is a better way I'm not aware of.
Well, you can use FvwmPerl for this, although the fact that you're not, and
that there's already one user of this is enough for me to maintain it for
those users. :)

Fair enough. I will fix it in due course.

-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
Thomas Adam
2011-10-24 09:35:09 UTC
Permalink
Post by Thomas Adam
Post by d***@verizon.net
Post by Thomas Adam
* FvwmCpp
This one has to go -- no one that I've seen in the years I've been using
FVWM actually has a configuration in CPP anymore. If they do, they've not
noticed it's been broken since FVWM 2.3.X, and no one has fixed that.
I've been using FvwmCPP for quite a while now.
Maybe there is a better way I'm not aware of.
Well, you can use FvwmPerl for this, although the fact that you're not, and
that there's already one user of this is enough for me to maintain it for
those users. :)
Fair enough. I will fix it in due course.
Even better is the fact that I've now got an amalgamated version of FvwmM4
[1] and FvwmCpp [2], given that they both do the same thing, except for the
interpolation. So this actually makes this easier to maintain overall. :)

-- Thomas Adam

[1] I'm always surprised at how much FvwmM4 is still used by FVWM users,
we've likely got AnotherLevel to thank for that. :)

[2] The names of each stay the same, they just become symlinks to a module
wrapper dealing with their respective configs.
Bert Geens
2011-10-24 17:18:20 UTC
Permalink
Post by Thomas Adam
Hello all,
This has been a while coming since 2.6.0 was released.  But I said at the
time that since there was no longer ever going to be a split between
stable/unstable, and that there was only ever rolling-stable releases, that
there was now never any right time to make changes which have an impact.
This is one of them.
Currently, FVWM ships with a number of modules.  Some of them are used a lot
in peoples' configs (such as FvwmButtons, FvwmEvent, etc.) and others are
not so much used -- and indeed some of them have just bitrot.
Unsurprisingly, that's due to confusion as to the need of the module, and in
some cases the language the module is supporting, because it's no longer the
"coolest" language to use, or has been pushed back because of another module
giving functionality.
* FvwmCommand
* FvwmConsole
These two are the only ones on the list I really care about, I use
FvwmCommand in my Emacs mode to just execute parts of my config
without having to copy/paste to FvwmConsole. But a more direct means
to access Fvwm without having to keep the terminal's shortcomings
(thinking mainly about maximum command length here) in mind would be
even more welcome.

Either way, just a heads up to make sure FvwmCommand isn't brushed
aside as being unused :)

Kind regards,

Bert Geens
Jaimos Skriletz
2011-10-24 18:40:43 UTC
Permalink
Post by Bert Geens
Post by Thomas Adam
Hello all,
This has been a while coming since 2.6.0 was released.  But I said at the
time that since there was no longer ever going to be a split between
stable/unstable, and that there was only ever rolling-stable releases, that
there was now never any right time to make changes which have an impact.
This is one of them.
Currently, FVWM ships with a number of modules.  Some of them are used a lot
in peoples' configs (such as FvwmButtons, FvwmEvent, etc.) and others are
not so much used -- and indeed some of them have just bitrot.
Unsurprisingly, that's due to confusion as to the need of the module, and in
some cases the language the module is supporting, because it's no longer the
"coolest" language to use, or has been pushed back because of another module
giving functionality.
* FvwmCommand
* FvwmConsole
These three are on a list to be removed, but the functionality to replace
them (notably getting FVWM to listen on a $DISPLAY socket, for instance)
just isn't there yet. So whilst I don't plan on deprecating them just yet,
I'm aware I'll need to at some point.
These two are the only ones on the list I really care about, I use
FvwmCommand in my Emacs mode to just execute parts of my config
without having to copy/paste to FvwmConsole. But a more direct means
to access Fvwm without having to keep the terminal's shortcomings
(thinking mainly about maximum command length here) in mind would be
even more welcome.
Either way, just a heads up to make sure FvwmCommand isn't brushed
aside as being unused :)
They are just being flagged as future depricated. The goal is to allow FVWM to listen on a socket for commands in which can be sent from consoles, scripts, etc. Once this new behavior is added to FVWM, they will be depericated as their functionality will be done though the socket.

Both FvwmComand and FvwmConsole are used a lot, so the goal is to replace them with a more verstile tool. They won't be removed until this tool is functional, been tested in many situations and people have had plenty of time to change their configs.

jaimos
John Latham
2011-10-24 20:18:34 UTC
Permalink
Both FvwmComand and FvwmConsole are used a lot, so the goal is to replace=
them with a more verstile tool. They won't be removed until this tool is=
functional, been tested in many situations and people have had plenty of=
time to change their configs.
As I thought, thanks.

One thing to point out though, for FvwmCommand it's not just configs that
would be affected, but *software* built to run on fvwm. There may be an
argument for providing a compat script, called FvwmCommand, to use the new
module, when the old one is deleted. But I expect you would in any case have
thought of that when the time comes! ;-)
jaimos
Thanks, John
Jaimos Skriletz
2011-10-24 21:49:09 UTC
Permalink
Post by John Latham
Both FvwmComand and FvwmConsole are used a lot, so the goal is to replace=
them with a more verstile tool. They won't be removed until this tool is=
functional, been tested in many situations and people have had plenty of=
time to change their configs.
As I thought, thanks.
One thing to point out though, for FvwmCommand it's not just configs that
would be affected, but *software* built to run on fvwm. There may be an
argument for providing a compat script, called FvwmCommand, to use the new
module, when the old one is deleted. But I expect you would in any case have
thought of that when the time comes! ;-)
Yes, ensuring FVWM doesn't break other software should be a consideration. But in this case it may only need to have FvwmCommand as a wrapper so it can be used in shellscipts (etc) in the same way. The difference is it won't be a Module running ontop of FVWM, it will just be a wrapper that sends the command to the socket.

jaimos
Thomas Adam
2011-10-25 08:04:51 UTC
Permalink
Post by Jaimos Skriletz
Post by John Latham
Both FvwmComand and FvwmConsole are used a lot, so the goal is to replace=
them with a more verstile tool. They won't be removed until this tool is=
functional, been tested in many situations and people have had plenty of=
time to change their configs.
As I thought, thanks.
One thing to point out though, for FvwmCommand it's not just configs that
would be affected, but *software* built to run on fvwm. There may be an
argument for providing a compat script, called FvwmCommand, to use the new
module, when the old one is deleted. But I expect you would in any case have
thought of that when the time comes! ;-)
Yes, ensuring FVWM doesn't break other software should be a consideration.
But in this case it may only need to have FvwmCommand as a wrapper so it
can be used in shellscipts (etc) in the same way. The difference is it
won't be a Module running ontop of FVWM, it will just be a wrapper that
sends the command to the socket.
But it *will* be a module.

Grr...

-- Thomas Adam
John Latham
2011-10-24 20:06:42 UTC
Permalink
Post by Bert Geens
Post by Thomas Adam
* FvwmCommand
* FvwmConsole
These two are the only ones on the list I really care about, I use
FvwmCommand in my Emacs mode to just execute parts of my config
without having to copy/paste to FvwmConsole. But a more direct means
to access Fvwm without having to keep the terminal's shortcomings
(thinking mainly about maximum command length here) in mind would be
even more welcome.
Either way, just a heads up to make sure FvwmCommand isn't brushed
aside as being unused :)
My interpretation was that Thomas is aware these are used, hence the `wait
until there is a replacment' intention. But you've now made me wonder so,...
;-)

Thomas: I use FvwmCommand alot. E.g. in my pdf lecture slides I can click on a
`button' which invokes a shell script, that uses FvwmCommand to change
desktop, sets up windows for a demo; waits for those windows to be closed and
uses FvwmCommand again to put me back on the desk where acroread is running.

Keep up the good work -- it is much appreciated!

Thanks, John
Thomas Adam
2011-10-25 08:03:57 UTC
Permalink
Post by John Latham
Post by Bert Geens
Post by Thomas Adam
* FvwmCommand
* FvwmConsole
These two are the only ones on the list I really care about, I use
FvwmCommand in my Emacs mode to just execute parts of my config
without having to copy/paste to FvwmConsole. But a more direct means
to access Fvwm without having to keep the terminal's shortcomings
(thinking mainly about maximum command length here) in mind would be
even more welcome.
Either way, just a heads up to make sure FvwmCommand isn't brushed
aside as being unused :)
My interpretation was that Thomas is aware these are used, hence the `wait
until there is a replacment' intention. But you've now made me wonder so,...
;-)
Yes -- there is nothing to be worrying about.
Post by John Latham
Thomas: I use FvwmCommand alot. E.g. in my pdf lecture slides I can click on a
`button' which invokes a shell script, that uses FvwmCommand to change
desktop, sets up windows for a demo; waits for those windows to be closed and
uses FvwmCommand again to put me back on the desk where acroread is running.
It's perfectly simple: FvwmCommand goes away along with FvwmCommandS.
FvwmConsole becomes a wrapper around something to talk to a domain socket,
which itself will become FvwmCommand. Hence to get FvwmConsole's equivalent
functionality it will be launchable from a terminal and still have readline
support, etc.

But please -- can we just stop worrying about this? This has bugger all to
do with my original email and it annoys me this has even come up as an issue
when I've already stated that it's on my list of things to do, but until I
write the required components, it's all moot [1]

-- Thomas Adam

[1] This isn't directed at just you, John, but everyone else who has has a
worrying fit about this.
Thomas Adam
2011-10-25 09:03:58 UTC
Permalink
Post by John Latham
Thomas: I use FvwmCommand alot. E.g. in my pdf lecture slides I can click on a
`button' which invokes a shell script, that uses FvwmCommand to change
desktop, sets up windows for a demo; waits for those windows to be closed and
uses FvwmCommand again to put me back on the desk where acroread is running.
Oh, and out of curiosity, I wonder why you're using FvwmCommand here for
this, when I bet I could write something using FvwmEvent and PipeRead,
depending on what it actually does...

FvwmCommand's use should actually be very very specific -- and using it to
communicate with FVWM when you're already inside FVWM is batty; it's like us
having a conversation face-to-face with one another via a page-boy in the
room. So I'd be interested to see how you're using it, and how I can
suggest a cleaner way.

-- Thomas Adam
John Latham
2011-10-25 10:34:47 UTC
Permalink
Post by Thomas Adam
Post by John Latham
Thomas: I use FvwmCommand alot. E.g. in my pdf lecture slides I can click on a
`button' which invokes a shell script, that uses FvwmCommand to change
desktop, sets up windows for a demo; waits for those windows to be closed and
uses FvwmCommand again to put me back on the desk where acroread is running.
Oh, and out of curiosity, I wonder why you're using FvwmCommand here for
this, when I bet I could write something using FvwmEvent and PipeRead,
depending on what it actually does...
FvwmCommand's use should actually be very very specific -- and using it to
communicate with FVWM when you're already inside FVWM is batty; it's like us
having a conversation face-to-face with one another via a page-boy in the
room.
Love the analogy!
Post by Thomas Adam
So I'd be interested to see how you're using it, and how I can
suggest a cleaner way.
I should have made it clearer, sorry. In my example above, the `button' I
click on is part of the pdf document I'm using as a lecture/presentation via
acroread in fullscreen mode. So, in effect, I'm getting acroread to change
desktop for me. (The button is sourced as a LaTeX shadowbox around a href to
the shell script.)
Post by Thomas Adam
-- Thomas Adam
Thanks, John
Thomas Adam
2011-10-25 10:38:28 UTC
Permalink
Post by John Latham
Post by Thomas Adam
Post by John Latham
Thomas: I use FvwmCommand alot. E.g. in my pdf lecture slides I can click on a
`button' which invokes a shell script, that uses FvwmCommand to change
desktop, sets up windows for a demo; waits for those windows to be closed and
uses FvwmCommand again to put me back on the desk where acroread is running.
Oh, and out of curiosity, I wonder why you're using FvwmCommand here for
this, when I bet I could write something using FvwmEvent and PipeRead,
depending on what it actually does...
FvwmCommand's use should actually be very very specific -- and using it to
communicate with FVWM when you're already inside FVWM is batty; it's like us
having a conversation face-to-face with one another via a page-boy in the
room.
Love the analogy!
Post by Thomas Adam
So I'd be interested to see how you're using it, and how I can
suggest a cleaner way.
I should have made it clearer, sorry. In my example above, the `button' I
click on is part of the pdf document I'm using as a lecture/presentation via
acroread in fullscreen mode. So, in effect, I'm getting acroread to change
desktop for me. (The button is sourced as a LaTeX shadowbox around a href to
the shell script.)
Ah, that makes more sense, thanks. :)

-- Thomas Adam
Thomas Adam
2011-10-25 08:20:44 UTC
Permalink
I gave my reasons, but I never said how. Perhaps that's more important to
some (which confuses me, since implementation aside, why the hell would you
care?) so here it is, in-line with my original email.
Post by Thomas Adam
* FvwmCommand
* FvwmConsole
* FvwmConsoleC.pl
These three are on a list to be removed, but the functionality to replace
them (notably getting FVWM to listen on a $DISPLAY socket, for instance)
just isn't there yet. So whilst I don't plan on deprecating them just yet,
I'm aware I'll need to at some point.
Oh look, I've already said how. But for those who missed it: FvwmConsole
and FvwmCommandS and FvwmConsoleC.pl will be the ones dying, or otherwise
replaced; FvwmCommandS and FvwmConsoleC.pl will die, and FvwmConsole is
nothng more than a wrapper around FvwmCommand or whatever it is eventually
called. Most likely FvwmCommand so as not to break as many configs as I
can.
Post by Thomas Adam
* FvwmCpp
This one has to go -- no one that I've seen in the years I've been using
FVWM actually has a configuration in CPP anymore. If they do, they've not
noticed it's been broken since FVWM 2.3.X, and no one has fixed that.
Redacted, since merging this with FvwmM4 is now the most logical thing to
do, with very little effort, reducing the code and allowing for any other
language potentially to preprocess data if I do this properly.
Post by Thomas Adam
* FvwmDragWell
The use-case of this doesn't match any application anymore.
* FvwmIconBox
Replaced with IconBox style option, although not quite the same as having an
actual window managing icons (c.f. TWM)
This one is really important, and I'm surprised no one has picked up on
this. There is no direct window anymore to manage icons, but with the style
option of IconBox, you can place groups of icons around on the screen. I'm
taking this to be all the required functionality from this module as-needed.
Post by Thomas Adam
* FvwmSave
* FvwmSaveDesk
These two are broken, and a very very poor choice of trying to be a session
manager. Use a session manager if you can with FVWM.
* FvwmTaskBar
This is a FvwmButtons module swallowing FvwmIconMan. People wanting mail
notification can use xbuffy, xbiff, or mail-notification.
Seems I did mention how mail checking would be done; but note that given the
all too dynamic nature of this, I will probably very strongly end up writing
a little FvwmForm to manage various facets of FvwmTaskBar's replacement.

-- Thomas Adam
Michelle Konzack
2011-10-27 17:10:24 UTC
Permalink
Hello Thomas Adam,
Post by Thomas Adam
* FvwmCommand
* FvwmConsole
* FvwmConsoleC.pl
These three are on a list to be removed, but the functionality to replace
them (notably getting FVWM to listen on a $DISPLAY socket, for instance)
just isn't there yet. So whilst I don't plan on deprecating them just yet,
I'm aware I'll need to at some point.
Removeing is not a very good option for, because I use it all the day...
Post by Thomas Adam
* FvwmTaskBar
This is a FvwmButtons module swallowing FvwmIconMan. People wanting mail
notification can use xbuffy, xbiff, or mail-notification.
Ehm, FvwmTaskBar and FvwmButtons are slightly differnt, because if I
configure a button Panel it does not unhide automaticaly on "Mouse-Over"

Also if to click to fast on the Panel, it stuck in the middle and does
not more restore. You have to use xkill to kill the FvwmButtons and
then it restarts automaticaly from scratch.

FvwmTaskBar is a fixed part of my Desktops and the ones configured at my
customers-
Post by Thomas Adam
* FvwmWinList
This is FvwmIconMan.
Hmmm, FvwmWinList ist part of m config since MANY years and evne in the
latest version, noting is broken
Post by Thomas Adam
These
modules listed simply do not do their job to the way FVWM works anymore, and
Can you explain ths better? Here it works as I expect
Post by Thomas Adam
I won't be beginning work on this just yet -- maybe I'll start it over
Christmas.
;-)
Post by Thomas Adam
Any questions, please ask.
-- Thomas Adam
Thanks, Greetings and nice Day/Evening
Michelle Konzack
--
##################### Debian GNU/Linux Consultant ######################
Development of Intranet and Embedded Systems with Debian GNU/Linux
Internet Service Provider, Cloud Computing
<http://www.itsystems.tamay-dogan.net/>

***@tdnet Jabber ***@jabber.ccc.de
Owner Michelle Konzack

Gewerbe Strasse 3 Tel office: +49-176-86004575
77694 Kehl Tel mobil: +49-177-9351947
Germany Tel mobil: +33-6-61925193 (France)

USt-ID: DE 278 049 239

Linux-User #280138 with the Linux Counter, http://counter.li.org/
Thomas Adam
2011-10-27 20:12:53 UTC
Permalink
Post by Michelle Konzack
Hello Thomas Adam,
Post by Thomas Adam
* FvwmCommand
* FvwmConsole
* FvwmConsoleC.pl
These three are on a list to be removed, but the functionality to replace
them (notably getting FVWM to listen on a $DISPLAY socket, for instance)
just isn't there yet. So whilst I don't plan on deprecating them just yet,
I'm aware I'll need to at some point.
Removeing is not a very good option for, because I use it all the day...
I'm done explaining and justifying this -- removing isn't something I'm
doing, but unifying *is*. If this isn't clear from my previous replies on
this, you'll have to start asking specific questions, because quite frankly
I don't know how to make my stance on this any clearer.
Post by Michelle Konzack
Post by Thomas Adam
* FvwmTaskBar
This is a FvwmButtons module swallowing FvwmIconMan. People wanting mail
notification can use xbuffy, xbiff, or mail-notification.
Ehm, FvwmTaskBar and FvwmButtons are slightly differnt, because if I
configure a button Panel it does not unhide automaticaly on "Mouse-Over"
You're quite correct. FvwmTaskBar and FvwmButtons are completely different.
If you had said "Ehm, FvwmTaskBar and FvwmIconMan are slightly different", I
might have understood more what you were saying. But you didn't -- so is
this what you meant to say, or do you have an additional point which you've
not been able to communicate?

But note again that I am not interesting in comparing like-for-like
functionality of FvwmTaskBar and FvwmIconMan. There is nothing that
FvwmTaskBar does which FvwmIconMan does not do -- albeit with additional
help from other modules, which I'll touch on in reply to your concern
regarding autohiding. As far as the core functionality is concerned,
FvwmTaskBar displays a list of windows. FvwmWinList displays a list of
windows. FvwmIconMan displays a list of windows. FvwmIconMan (albeit now a
poor choice of name when it doesn't just manage iconified windows at all!)
wins against all three.

Now, as for autohide, I am not as stupid as to not suggest FvwmButtons as an
overriding container for housing both FvwmIconMan and various other tools I
deem fit to count as a direct replacement for FvwmTaskBar. Using
FvwmButtons here allows for me to have a common point of reference in terms
of a window name to be able to manipulate it however I see fit. This would
be more challenging were it not swallowed in FvwmButtons due to the fact
that I'd be considering disparate applications as unique, especially in
terms of autohiding. As for how autohiding is done, there's at least three
ways I can think of -- the one I will plump for will be FvwmEvent. But you
need not likely concern yourself with *how* that's achieved, just that
autohiding will still be possible with the FvwmTaskBar replacement.
Post by Michelle Konzack
Also if to click to fast on the Panel, it stuck in the middle and does
not more restore. You have to use xkill to kill the FvwmButtons and
then it restarts automaticaly from scratch.
Irrelevant and something you'd need to mention to me *in context* of your
FvwmButtons configuration for me to determine what your problem is. But
this has *nothing* to do with anything I've mentioned above.
Post by Michelle Konzack
FvwmTaskBar is a fixed part of my Desktops and the ones configured at my
customers-
I know that. Do not think me as stupid as to not have realised that
replacing it is not necessarily a trivial thing.
Post by Michelle Konzack
Post by Thomas Adam
* FvwmWinList
This is FvwmIconMan.
Hmmm, FvwmWinList ist part of m config since MANY years and evne in the
latest version, noting is broken
Then you won't notice anything wrong with my replacing it with FvwmIconMan
when it's a case of translating geometry settings and colour definitions,
will you?

All of this, by the way, is utterly moot until I produce something of
substance for you all to see. Since code speaks louder than words, just
wait to see what I come up with -- and I am serious about that point, BTW.
Then you can quibble over minutiae in the time-honoured tradition.

What say you?

-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
Loading...