FVWM: fvwm2 vs fvwm3

[Ethan Raynor]

Hi everyone,

I've been using fvwm3 for a few months, and have realised that its
config file is the same as fvwm2.

On the fvwm2's github repo README, I note that it has been put in
maintenance mode and that use of fvwm3 is preferred.

I'm OK with that, but can anyone here tell me what the plan is with
fvwm3? If this version is going to depart from the config syntax of
fvwm2, is this something as a user, I should  be aware of?  If it is,
I'm wondering if I should switch back to fvwm2, unless some migration
path will be established?

Indeed, how well received is fvwm3 by the community?  If I check the
git log in fvwm2 compared to fvwm3, it seems that only Thomas plus a
few others contribute - is this a concern for the future of fvwm?  Is
the creation of fvwm3 even the right way to go?

To be clear, I'm not looking to incite a flamewar, I am curious about
this from my limited perspective as a user of fvwm.

Thanks,
Ethan

Re: FVWM: Move windows to a new desk preserving pages

[Ethan Raynor]

Hi Dominik,

On Mon, Mar 1, 2021 at 1:51 PM Dominik Vogt  wrote:
> Can you please be more precise?  You're mixing the terms page,
> desk and screen which are all differet things.  Could you give an
> example of the workflow?  It's hard for me to imagine what you're
> actually doig that could require to move all windows from oe
> desktop (page?) to another.  Why is it not good enough to make the
> windows on desk 1 sticky?

Mea culpa! i admit that i am confusing myself as well. Let me try once more.

I am using fvwm2 (2.6.9).

I have two monitors and the following config:

DesktopSize 3x3
DesktopName 0 Main
DesktopName 1 Dev
DesktopName 2 Bills
DesktopName 3 Chat

as i understand this, i now have four desktops, each with 9 pages on
them - this is what FvwmPager agrees with.

As i move between desks, i often try and stick to adding windows to
the correct desks so that i have some separation of work ("Dev" for
development, "Chat" for ms-teams, etc.)  This works well for me.

But sometimes I find that I want to shift the windows from, say, the
"Dev" desk to my other monitor which is free of any windows. so i
thought i had to do it like this:

all (desk 1) movetoscreen

where i first of all open fvwmconsole on screen2 (the one i want
windows from the Dev desktop to move from) and run the command.

This works - the windows from the Dev desktop are moved to screen2,
but they don't keep the page they were on, on the new screen - every
window is now on the same page on screen2. what i want is for the
windows on the Dev desk to move across to screen2, "mirroring" the
location/page they were on screen1 with, only now, on screen2.

Does this make any sense now? i hope it does - apologies if it isn't -
and i will try again to explain

thanks all for your time.
Ethan

Re: FVWM: Move windows to a new desk preserving pages

[Ethan Raynor]

hi Dominik,

On Mon, Mar 1, 2021 at 9:45 AM Dominik Vogt  wrote:
> What is the actual use case for this?

i quite often find myself wanting to move windows between desks to
suit my workflow.  what i would like is the ability to move windows as
they are on desk X to screen Y without them losing which page they are
on. so for example when i do this:

all (desk 2) movetoscreen

this does move all the windows on desk2 to the current screen but i
would ideally like those windows on desk2 to also keep the page they
are on. currently the above command moves all windows on desk 2 to the
current page on the screen i run it from - i don't want this.

thanks!
Ethan

FVWM: Move windows to a new desk preserving pages

[Ethan Raynor]

Hi,

I'm trying to understand how I can move all windows from desk X to
desk Y without losing where the windows on desk X are in terms of
their pages.

I know I can do something like:

All (Desk 1) MoveToDesk 2

But all this does is take every window on desk 1 (regardless of page)
and move those windows to desk 2.

How can I essentially "mirror" the windows on desk 1 so they are in
the same position/page on desk 2?

TIA,
Ethan

FVWM: multiple monitors with fvwm

[Ethan Raynor]

Hi everyone,

Can i please get some advise about how to make fvwm work well with
multiple monitors? i'm after the following:

- separate workspaces per monitor - this would allow monitor
independence from each other, which is important to me with lots of
graphics design
-
fvwmpager - i have a very big pager which i use to give an overview of
whats on my monitor. if this is per monitor i could see just what i
needed and would match the workflow of seperate monitors

- per-monitor colors - can i assign different desktops on different
monitors a different colorset scheme and have that applied when new
windows are created or windows are moved across? it would be nice if i
could give different window parts different colors as well

- drop-shadows on windows. i read about wayland a lot - is fvwm going
to support this? i think a lot of window managers are moving there

Thanks for any help you can give.

Ethan

Re: FVWM: RandR Support

[Ethan Raynor]

Hi,

Yes, I understand that I can use the xrandr command, but fvwm doesn't
do anything afterwards unless I restart it - something I want to
avoid. It also doesn't handle screen resolution changes realtime.

Ta!

On Thu, Feb 6, 2020 at 1:52 PM Tapia, Ron  wrote:
>
> Hi Ethan,
>
> FVWM2 and FVWM3 both support multiple displays. As far as supporting RandR, I 
> think that is the X server's job.
>
> I use the command "xrandr" to manipulate display configurations.
>
> Cheers,
>
> Ron
>
> ____
> From: Ethan Raynor 
> Sent: Wednesday, February 5, 2020 4:33 PM
> To: fvwm
> Subject: FVWM: RandR Support
>
> Hi,
>
> Does fvwm have XRandR support yet?
>
> What I'm hoping for is:
>
> 1. Independent monitors (desks per monitor)
> 2. rotation & reflection
>
> Is this possible in fvwm yet? many other WM's out there offer RandR support.
>
> Ta!
>

FVWM: RandR Support

[Ethan Raynor]

Hi,

Does fvwm have XRandR support yet?

What I'm hoping for is:

1. Independent monitors (desks per monitor)
2. rotation & reflection

Is this possible in fvwm yet? many other WM's out there offer RandR support.

Ta!

Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)

[Ethan Raynor]

Hi,

I can understand personal opinions - they're important and they happen
all the time with projects, I understand that. But I don't think it is
very fair to say I should not read it - when I won't know weather it's
there or not to start with. So I think just not having those
conversations is better.

Thanks again though.

Ethan

On Mon, Nov 14, 2016 at 1:03 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> Please don't top post on the fvwm lists.
>
> On Mon, Nov 14, 2016 at 12:44:47AM +0000, Ethan Raynor wrote:
>> it's those points i would like to see put elsewhere
>
> I've completely understood that it bothers you.  If you don't want
> to read it, don't.  This is an unavoidable part of public software
> development.
>
>> as that doesnt have much - if anything- to do with fvwm.
>
> Discussing the fvwm infrastructure and the personal opinions about
> it is completely on topic.  This list is not a place where
> politeness or political correctness is exspecially important.
>
>> or am i wrong?
>
> Ciao
>
> Dominik ^_^  ^_^
>
> --
>
> Dominik Vogt
>

Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)

[Ethan Raynor]

Hi,

Is it OK to request these sorts of conversations take place someplace
else? I did not know before that there's a lot of heated
conversations. I don't want to have to read these.

Please be considerate. Or agree on something and move on, may be?

Ethan


On Sun, Nov 13, 2016 at 1:43 AM, Dominik Vogt  wrote:
> On Sun, Nov 13, 2016 at 01:05:23AM +, Thomas Adam wrote:
>> On Thu, Oct 27, 2016 at 01:23:23AM +0100, Thomas Adam wrote:
>> > "Copying" was a bad choice of words.  With fvwm3, what I would suggest is
>> > taking the current fvwm2 repository (including all of its branches) and
>> > making that the basis for fvwm3.  That way, we can change it however we 
>> > like.
>> > We're then able to link fvwm2's repo in to easily backport changes using
>> > standard git commands, etc.  It's something I'd be happy to run through if
>> > that's required, or wanted.
>>
>> Controversially, I've gone ahead and created a fvwm3 repository [1].  It has
>> been set up as fvwm2 was; the only difference is there's no tags.  The master
>> branch is the same from fvwm2.
>>
>> I've aleady gone ahead and made fvwm3 rename key parts.  So for example, the
>> binary is currently called 'fvwm3' and the share prefix installs to
>> $PREFIX/share/fvwm3.
>
> Why on earth do we have to repeat the mistake of the past by
> putting the version number in the project name *again*?  Every
> other project manages backwards incompatible releases just fine,
> only fvwm changes its name with each major release.  This just
> complicates things, and helps nobody.  That's what configure's
> binary suffix is for.
>
>> I'm not necessarily expecting this to remain as-is for
>> too long, but it does mean that fvwm3 can be installed along side fvwm2.
>
>
>> 1.  How do I port fixes from fvwm3 -> fvwm2?
>>
>> You can do this with remotes.  From fvwm3's POV:
>>
>>   git remote add fvwm2 g...@github.com:fvwmorg/fvwm.git
>>   git fetch -n fvwm2
>>   git checkout -t origin/fvwm2 fvwm2-master
>>   git cherry-pick COMMIT1 COMMIT2
>>   git push
>>
>> This will also handle file rename cases.  So for example, fvwm/fvwm3.c would
>> map to fvwm/fvwm.c in fvwm2's repository, as git understands file renames.
>
> In the past couple of years I haven't been contributing that much,
> and I'm absolutely for having the sources in git.  But over the
> recent years, I've tested the initiol fvwm git repo, then switched
> to the mvwm repo, rewritten all the config files on various
> machines to switch to mvwm, in the mean time backported fixes from
> mvwm to fvwm (with some amount of merge conflicts), converted all
> the icons to a different format because mvwm required that,
> switched back to the fvwm repo, backported the parser branch to
> the fvwm repo (very annoying), rewritten the config from mvwm to
> fvwm yet again.  And I've got to rewrite it *again*, manage two
> different configs and fiddle with two repos in parallel, just to
> be able to install two versions in parallel, which is already
> possible (and if not, this needs to be fixed anyway).
>
> By the way, everybody else would call their versions fvwm-2 and
> fvwm-3, and that's what I'll do, starting now.
>
> Ciao
>
> Dominik ^_^  ^_^
>
> --
>
> Dominik Vogt
>

fvwm3 discussion continuing?

[Ethan Raynor]

Hey all,

I've had a few mail probs recently and wondered if the discusion about
fvwm3 is still happening?

If it is- what are the outcomes from any conversations?

Ethan

Re: Separate or common project infrastructure fvwm v2/v3.

[Ethan Raynor]

Hi,

On Thu, Oct 27, 2016 at 12:30 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:

I'm just a recent user of fvwm full time and haven't been around long
enough to appreciate many of the issues raised in this email. I can
see though that fvwm's history goes back a long way and that might
have a few reasons why these issues are being discused.

I want to address one point below on why I think a seperte git repo
for fvwm-3 is a good idea - as i do know about how project
organisations work.

>  * Switching git repository:  Given that the current amount of
>work going into version 2.x is very low, having both versions
>in the same repository is certainly manageable.  It's just more
>work for anybody who is interested in both repos (and getting
>access to github *is* very cumbersome compared to cvs access in
>the past).

Having that 'mental separation' of what "was" (if you'll permit me to
say that), and whar "is" makes clear to me. I can understand Thomas'
point - it does help - when you also consider that the code will
change and diverge. When you have a repository with code in it, if
it's going to be based off an existing code base, but change, then it
really does make sense to have a completely separate area for this.

If you don't - how will you manage branch names, and knowing where to
merge one thing to another? If fvwm-3 lives in the same repository,
switching between a fvwm2 branch and fvwm3 branch is hassle because
you'll have different .o files which will need to be cleared before
doing another build. What will you do about releases? If you do have
fvwm-3 and fvwm-2 in the same repo, the tagging will be a nightmare -
in fact, you'll struggle to do this in the same repo as tagging is
global in git, and is not done per branch.

So that to me suggests you'll have to have a separate repo for fvwm-3
if you want to do releases - since Github does these per tag, not
branch.

HTH,

Ethan Raynor

Re: FVWM: Fvwm Default Configuration

[Ethan Raynor]

On Wed, Oct 26, 2016 at 8:06 PM, Jaimos Skriletz
 wrote:
> Hello,

Howdy.

> I have put together a default configuration to go with Fvwm. The 
> configuration could use some testing. To test this config, use the 
> default-config branch on github.
>
> The default config will load if fvwm doesn't find any config file when 
> starting. There is a script in the built in menu to copy the config into 
> $FVWM_USERDIR or copy the default config from 
> $PREFIX/share/fvwm/default-config.

This looks interesting, Jaimos. I like the simple design, although I'm
not sure I like the colors but then you won't find enough colors to
please everyone - so might as well leave it be.

The panel on the right of the screen looks nice on wide-screen
monitors - but how will this look on laptops and smaller screens where
space is at a premium?

Functionally i couldn't break it - so that's good.

You mention the default config loads if theres no ~/.fvwm - i have
seen it load if i use "-f /tmp/doesnotexist" to fvwm - is this
intended?

Thanks for all your work - i love the comments in the file - it will
help me when i need to make changes!

Ethan

FVWM: fvwm3???

[Ethan Raynor]

Hi,

I was just browsing the fvwm git repository and saw that things have
been busy this weekend - I hope this means fvwm development is
happening again? It has been really slow for years - nothing
happening.

https://github.com/fvwmorg/fvwm/blob/ta/next/FVWM3.md

Does this mean fvwm2 is dead? Does fvwm3 exist yet? what's  happening with it?

Sounds like a plan though! Who's developing it?

Re: FVWM: [Draft] New Configuration Format

[Ethan Raynor]

On Mon, Sep 26, 2016 at 12:13 AM, Dan Espen  wrote:
> Sounds to me like you are not subscribed to fvwm-workers.
> If you care about things like the repository, you should subscribe.

ok - I will do this. How busy is the list?

> Read the various TODO files.

The only one I can see is this one -
https://github.com/fvwmorg/fvwm/blob/master/TODO.md

i confess to not completely understanding the rationale for some of
the items there.

> I'd like to see improvements in the way parsing is done
> inside fvwm.  There is so much parsing code that does
> the same basic thing.  A table driven approach would
> be a big improvement.
>
> If the command syntax has to change to get there,
> I'd like to understand why.

well afaict the proposal is to rip up things more than that - why?

Ethan

Re: FVWM: [Draft] New Configuration Format

[Ethan Raynor]

On Sun, Sep 25, 2016 at 11:50 PM, Dan Espen  wrote:
> Yes, a number of people wanted git.
> No point in arguing against that.
> It's accepted that git out does CVS in functionality.

But I can't recall when on the fvwm lists the pros and cons of moving.
I know that github is considered the place to be - but I've also had
some nasty encounters with it when things go bad - and other places
like bitbucket have greater resiliance  - not to mention guaranteed
backups!!

> You've ruined your point about the config change by bringing in
> a bunch of irrelevant stuff.

Not exactly, Dan. The point i'm putting across to thomas and others is
the perception of the changes - they come out of no where with any
warning. That can be a bad thing

Ethan

Re: FVWM: [Draft] New Configuration Format

[Ethan Raynor]

On Fri, Sep 23, 2016 at 1:58 PM, Lucio Chiappetti
 wrote:
> On Fri, 23 Sep 2016, Thomas Adam wrote:
>
>> On Fri, Sep 23, 2016 at 12:42:14PM +0200, Lucio Chiappetti wrote:
>>>
>>> is <<< a perlism, or a typo for more customary << ?
>>
>>
>> In shell, <<< is a here-string.
>
>
> I wasn't aware of the distinction between here-documents and here-strings (I
> had to check https://en.wikipedia.org/wiki/Here_document), I've always used
> only the former.
>
>>> Does this apply to ANY occurrences which in your new scheme will use the
>>> backslash like the old AddToFunc followed by lots of + I lines ?
>>
>>
>> Yes.

I think this is a mistake. I've read through the doc you've put out
twice, and i cannot see any compelling reason to change things. For my
purposes, the expressiveness of what's there now is an asset we should
retain - look at your proposal...

function -n myfunc <

Re: FVWM: [Draft] New Configuration Format

[Ethan Raynor]

Hi,

I have been using fvwm for a while and I think that this idea of
changing the config format is ill thought out and silly. Why does this
need changing now after all these years? I can't see how you expect a
script to convert to this new format easily - its a very lofty goal.

Don't do this at all - go and do features or something people want.
Why do you always try and make these sweeping changes?

Ethan

On Mon, Sep 19, 2016 at 1:25 PM, Thomas Adam  wrote:
> On Mon, 19 Sep 2016 at 12:57 Ron Tapia  wrote:
>> What are the
>> shortcomings of the current configuration format that the new format
>> addresses?
>
> Have another read of that document, Ron.  FVWM is completely governed
> by how it reads in commands, and hence at the moment, each command is
> responsible for parsing its values.  There's been twenty years of this
> idea; organically growing out of control.  Adding or even changing
> existing options to commands is a nightmare; there's no state being
> kept between commands (which would be good), and hence there's a lot
> of the same sorts of information being gathered separately, leading to
> a lot of duplication at the code-level.
>
> Changing the format is a great way of getting a clean break, and being
> able to rationalise the commands we have now, and need; moving
> functionality into other commands in an extensible way, which will
> also reduce the code complexity somewhat.  You can't easily do this
> with the format we have now.  Dominik and I have given this a lot of
> thought[0] and to my mind, trying to keep with what we have is a lot
> of work, more so than changing it.
>
> None of this precludes what we have now in terms of preprocessing, and
> having other things produce a configuration file in a format FVWM can
> read in.  Indeed, there will be conversion scripts to handle the
> transition.
>
> So this is coming, albeit slowly, and right now what there is are just
> my ideas with the beginnings of an implementation to see what that
> looks like.
>
> People are welcome to comment on functionality, etc., with other suggestions.
>
> For the rest of you saying: "It's been that way for the last X years"
> need to wake up and realise that I will be making little changes as
> time goes on.  FVWM has laid stagnant for a long time, and it's about
> time someone stepped up to the plate and helped to modernise/improve
> things a little.  It's boring work, it's certainly not feature
> development, but if this work isn't started now, or thought about, you
> won't see much more happening with FVWM since all of these
> organically-grown problems need solving first.  That's why we're in
> the situation we are now---no one has wanted to do it, and what we
> have is one big mess.
>
> So wake up, people.  A change is on the horizon.  It won't happen
> overnight, but it does need to happen.
>
> -- Thomas Adam
>
> [0]  https://github.com/fvwmorg/fvwm/blob/master/docs/PARSING.md
>