Re: FVWM: [Draft] New Configuration Format
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 >
Re: FVWM: [Draft] New Configuration Format
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
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
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
FVWM: fvwm3???
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: Fvwm Default Configuration
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: 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!
Re: FVWM: RandR Support
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: multiple monitors with fvwm
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
FVWM: Move windows to a new desk preserving pages
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
Re: FVWM: Move windows to a new desk preserving pages
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
Re: FVWM: Move windows to a new desk preserving pages
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
FVWM: fvwm2 vs fvwm3
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
